AWS の障害報告書 (COE) から学ぶ分散システムの教訓 - 過去の大規模障害が変えた設計原則
AWS が公開した Correction of Errors (COE) と障害報告書から、S3 障害、us-east-1 の DNS 障害、Kinesis 障害など過去の大規模インシデントの根本原因と、それが AWS の設計原則をどう変えたかを解説します。
AWS が障害を公開する文化的背景
AWS は大規模障害が発生した際、Post-Event Summary (障害後サマリー) を公開しています。社内では Correction of Errors (COE) と呼ばれるこの文書は、障害の時系列、根本原因、影響範囲、再発防止策を詳細に記述したものです。多くの企業が障害情報を最小限の開示にとどめる中、AWS が詳細な障害報告書を公開するのは、Amazon のリーダーシッププリンシプルの一つ「Customer Obsession」(顧客への執着) に基づいています。障害の原因を隠すことは短期的には企業イメージを守りますが、長期的には顧客の信頼を損ないます。AWS は障害の透明性が信頼構築に不可欠だと考えており、この姿勢は業界全体の障害報告文化に影響を与えました。Google の SRE チームが公開するポストモーテムや、Cloudflare の詳細な障害報告も、AWS の透明性に触発された面があります。
2017 年 S3 障害 - タイプミスがインターネットの半分を止めた日
2017 年 2 月 28 日、us-east-1 リージョンの S3 で約 4 時間にわたる大規模障害が発生しました。この障害は、S3 の課金システムのデバッグ作業中に、オペレーターが意図した以上のサーバーを停止するコマンドを実行したことが原因でした。具体的には、少数のサーバーを停止するつもりが、入力ミスにより S3 のインデックスサブシステム (オブジェクトのメタデータを管理するシステム) と配置サブシステム (データの物理的な配置を管理するシステム) の大部分が停止しました。S3 は us-east-1 で最も広く利用されているサービスの一つであり、S3 に依存する無数のサービスやウェブサイトが連鎖的に影響を受けました。皮肉なことに、AWS の Service Health Dashboard 自体も S3 に依存していたため、障害状況の表示すら正常に機能しませんでした。この障害から AWS が得た教訓は複数あります。第 1 に、大規模な変更操作にはレートリミットを設ける (一度に停止できるサーバー数に上限を設定する)。第 2 に、Service Health Dashboard を S3 に依存しない構成に変更する。第 3 に、インデックスサブシステムの再起動手順を最適化し、復旧時間を短縮する。これらの改善は、その後の S3 の運用に反映されています。
2020 年 Kinesis 障害 - フロントエンドサーバーの増設が引き起こした連鎖障害
2020 年 11 月 25 日、us-east-1 で Kinesis Data Streams の障害が発生し、CloudWatch、Lambda、Cognito、API Gateway など多数のサービスに波及しました。根本原因は、Kinesis のフロントエンドサーバーの増設でした。Kinesis のフロントエンドサーバーは、各サーバーが他のすべてのフロントエンドサーバーとの間でスレッドを維持する設計になっていました。サーバー数が増えると、各サーバーが維持するスレッド数が二次関数的に増加します。この日、定期的なキャパシティ増設でフロントエンドサーバーが追加された際、スレッド数が OS のスレッド上限に達し、新しい接続を受け付けられなくなりました。この障害が広範囲に波及したのは、CloudWatch が内部的に Kinesis を使用していたためです。CloudWatch が機能しなくなると、他のサービスのメトリクス収集とアラームが停止し、障害の検知と対応が遅れるという二次被害が発生しました。この障害から得られた教訓は、サービス間の依存関係の管理と、コントロールプレーンの障害がデータプレーンに波及しない設計の重要性です。AWS はこの後、Kinesis のフロントエンドアーキテクチャをスレッドモデルからイベント駆動モデルに変更しました。
2021 年 us-east-1 ネットワーク障害 - 内部ネットワークの輻輳が教えたこと
2021 年 12 月 7 日、us-east-1 で約 5 時間にわたるネットワーク障害が発生しました。AWS の内部ネットワークデバイスの自動スケーリングシステムに潜在的なバグがあり、通常よりも多くのトラフィックが内部ネットワークに流入した際に、ネットワークデバイスが過負荷状態に陥りました。この障害の特徴は、AWS のコンソール自体がアクセス困難になったことです。AWS マネジメントコンソールは us-east-1 でホストされているため、コンソール経由でのリソース管理や障害状況の確認ができなくなりました。CLI や SDK を使用した API 呼び出しも、内部ネットワークの輻輳により遅延やタイムアウトが発生しました。この障害は、「コントロールプレーンとデータプレーンの分離」という設計原則の重要性を改めて示しました。データプレーン (実際のデータの読み書き) はコントロールプレーン (リソースの作成・変更・削除) よりも高い可用性が求められます。AWS はこの障害後、コントロールプレーンの障害がデータプレーンに波及しないよう、内部ネットワークの分離を強化しました。ユーザー側の教訓としては、マルチリージョン設計の重要性と、AWS コンソールに依存しない運用手順 (CLI スクリプトの事前準備) の必要性が挙げられます。
障害から導かれた AWS の設計原則
過去の障害から AWS が体系化した設計原則は、AWS Well-Architected Framework の信頼性の柱に反映されています。第 1 に「Blast Radius の最小化」です。障害の影響範囲を限定するために、サービスをセル (Cell) と呼ばれる独立した単位に分割し、1 つのセルの障害が他のセルに波及しない設計にします。DynamoDB は各パーティションが独立したセルとして動作しており、1 つのパーティションの障害がテーブル全体に影響しません。第 2 に「Static Stability」(静的安定性) です。依存するサービスが障害を起こしても、既存の動作を継続できる設計です。たとえば、Auto Scaling が障害を起こしても、既に起動しているインスタンスは影響を受けません。第 3 に「Shuffle Sharding」です。顧客をランダムにシャードに割り当てることで、1 つの顧客の異常なトラフィックが他の顧客に影響する確率を最小化します。これらの原則は、AWS 自身の障害経験から蒸留されたものであり、ユーザーが自身のシステムを設計する際にも適用できる普遍的な知見です。分散システムの設計原則を体系的に学ぶには、専門書籍 (Amazon)が参考になります。