2025/11/17 17:07 When AWS was down, we were not
ロボ子、大変なのじゃ！またAWSで障害が発生したみたいだぞ！
まあ、博士。今回はどのリージョンで、どんなサービスに影響があったんですか？
us-east-1、つまりバージニア北部リージョンじゃ。DynamoDBのDNSに問題が発生して、Disney+とかLyftとか、名だたるサービスが影響を受けたらしいぞ。
それは広範囲に影響が出ていますね。Authressもus-east-1で限定的なインフラを運用しているとのことですが、影響はなかったんですか？
Authressは大丈夫だったみたいじゃな。しかし、CloudFrontとかCertificate Managerとか、重要なサービスがus-east-1にコントロールプレーンがあるのは怖いぞ。
Authressは99.999%のSLAを目指しているんですよね。年間で5分15秒以下のダウンタイムというのは、かなり厳しい目標ですね。
そうなんじゃ。Authressは認証とか認可とか、重要な機能を提供しているから、ダウンタイムは顧客のアプリケーションに直結するからの。
記事によると、単一リージョンでの構成では信頼性の要件を満たせないとのことですが、具体的にどういうことですか？
AmazonのCTOも言ってるように「すべては常に故障する」んじゃ。HTTPルーター、コンピューティング、データベース、どれか一つでも壊れたらアウトじゃ。
AWSのSLAも5ナインを下回ることがあるんですね。AWSのSLAを鵜呑みにするだけでは、Authressの目標は達成できないと。
そう、だからサードパーティのコンポーネントを使うときは、故障率をちゃんと考慮しないといけないのじゃ。リトライも有効だけど、回数には限界があるし、リトライハンドラー自体も信用しすぎちゃダメ。
90%の信頼性のコンポーネントを使う場合、5回以上のリトライが必要になるんですね。でも、リトライハンドラーの信頼性が99.9995%だと、2回までしかリトライできないと。
そういうことじゃ。だから、コンポーネントの信頼性は最低でも99.7%は欲しいところじゃな。
インフラ全体の故障も考慮する必要があるんですね。データベース、コンピューティング、ネットワークなど、どこで問題が起きてもおかしくないと。
そうじゃ。リージョン全体のダウンを宣言して、別のリージョンにフェイルオーバーする必要があるんじゃ。Authressは世界中に6つの主要リージョンを持ってるから、複数のバックアップリージョンが必要になるぞ。
DNS動的ルーティングを使って、Route 53のヘルスチェックとフェイルオーバールーティングポリシーを使うんですね。ヘルスチェックは両方のリージョンを検証して、DNSルーターに結果を報告すると。
そうそう。カスタムのヘルスチェックエンドポイントを構築して、データベースやビジネスロジックも検証するんじゃ。
エッジ最適化アーキテクチャを採用して、CloudFrontとLambda@Edgeを使うのも有効なんですね。CloudFrontがリクエストをローカルで利用可能なコンピューティングリージョンにルーティングすると。
データベースに問題が発生したら、隣接するリージョンのデータベースにフェイルオーバーするんじゃ。DynamoDBのグローバルテーブルを使って、認証設定を複製するのも良いぞ。
アプリケーションレベルの故障も考慮する必要があるんですね。コードのバグは避けられないから、インシデントレスポンスと自動修復を実装すると。
デプロイ前に十分なテストを実施して、テストカバレッジじゃなくてテスト価値に焦点を当てるんじゃ。デプロイされた本番コードに対して検証テストを実施して、データの整合性を確認するのも大事じゃ。
インクリメンタルロールアウトを利用して、インシデントの影響を軽減するんですね。顧客を個別のバケットに分割して、順次デプロイすると。
そうじゃ。問題が発生したら、ロールアウトを停止して、影響を最小限に抑えるんじゃ。
AIを使って異常検知をするのも有効なんですね。ビジネスに焦点を当てたメトリック（認証率）を使って、意味のあるインシデントを特定すると。
CloudWatchメトリックを使って、認証率の異常を検知するんじゃ。インシデントの特定は主観的な視点に基づくから、顧客の視点との整合性が重要になるぞ。
顧客からのインシデント報告を容易にして、エンジニアリングチームに直接送信するんですね。顧客サポートをSLAのライフラインとみなして、顧客にカスタムメトリックを提供するのも良いですね。
Authressはマルチテナントソリューションだから、リソースの枯渇を防ぐ必要があるんじゃ。テナント内およびテナント間のリソース枯渇から保護するために、レート制限を実装するぞ。
AWS WAFを使って、悪意のあるリクエストをブロックするんですね。AWSマネージドIPレピュテーションリストを使って、既知の悪意のあるIPアドレスをブロックすると。
高リクエストレート（2,000 RPS以上）は即座に終了させるんじゃ。WAFメトリックのカウントに基づいてアラートを作成して、小規模な攻撃を早期に検知するのも大事じゃな。
ブロックされたリクエストをログに記録して、パターンをクエリしてルールを更新するんですね。今回の記事から得られる教訓は「すべては常に故障する」「DNSは依然として単一障害点となる可能性がある」「Infrastructure as Code（IaC）には課題がある」ですね。
そうじゃな。これらの対策を講じても、5ナインのSLAが保証されるわけではないけど、Authressはこれらの対策を防御として使用しているんじゃ。
今回の記事はとても勉強になりました。ところで博士、5ナインを達成するために、お風呂は1日に何回入れば良いんですか？
ロボ子、それは関係ないぞ！清潔なのは良いことじゃが、5ナインはもっと技術的な話じゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
