要約

  • 2011年4月21日、AWS米国東部リージョンの一つのAZで、EBSの主ネットワークのトラフィックが容量の小さい複製ネットワークへ誤って移された。接続回復後、多数のノードが同時に複製を探し、不十分なバックオフと競合状態が再ミラーリング要求を増幅した。長時間のボリューム作成処理はリージョンの制御面にあるスレッドを占有し、限定的ながら直接影響AZの外にもAPI障害を広げた。

  • AWSは、安定化時に影響AZ内のボリューム約13%が停止状態にあり、最終的に同じ分母の0.07%を整合した状態へ復元できなかったと報告した。二つの比率は別の局面を表し、リージョン全体へ一般化できない。RDSの一部Multi-AZ構成では自動フェイルオーバーが働かず、Herokuなど下流サービスにも影響が出た。

  • 教訓は、冗長化だけでなく、同時修復を抑えるバックオフ、十分な復旧容量、共有制御面の隔離、段階別の復旧可視性を保証対象にすることだ。AWSが発表した是正策は原因連鎖に対応するが、この資料集合は実装完了を独立検証していない。特定個人や法的違反を断定せず、プロバイダーと顧客それぞれの制御可能範囲を分けて評価する必要がある。

障害の輪郭を正確に置く

2011年4月21日に始まった出来事は、「AWS全体が世界規模で停止した」とまとめられるものではない。直接の中心はAWS米国東部リージョンの一つのAvailability Zone（AZ）であり、同じリージョンの別の場所にも、限定された時間帯にEBS APIのエラーや遅延が及んだ。影響範囲を広げて語れば重大さは強調できるが、原因と責任の所在はかえって見えにくくなる。

AWSの事後説明によると、発端は太平洋夏時間4月21日午前0時47分のネットワーク容量変更だった。本来プライマリーネットワーク側で扱うべきトラフィックが、容量の小さい複製用ネットワークへ誤って移され、多数のEBSノードが実効的な接続を失った。これは引き金である。しかし、長期化と広がりを説明するには、接続が戻った後に何が起きたかを見る必要がある。

2011年当時の構造と二つの経路

当時のEBSは、AZ内に閉じた複製ストレージクラスタを持ち、リージョン単位のコントロールプレーンがそれらを調整していた。ノード間には高帯域の主経路と、容量がより小さい複製用の予備経路があった。この構成は通常時の障害に備えるものだが、予備経路が主経路の負荷を一斉に引き受ける前提ではなかった。

ここで重要なのは、経路変更の誤りだけを「根本原因」として終わらせないことだ。誤った変更がなくてもよい設計だった、という意味ではない。むしろ問うべきは、一つの操作ミスがなぜ大量のノード隔離へ進み、さらに復旧処理が容量を食い尽くすまで拡大できたのかである。引き金、寄与条件、増幅機構を分けなければ、再発防止策も一つの操作手順だけに偏る。

接続回復が再ミラーリングの嵐を呼んだ

接続を回復したノードは、失った複製を探し、データ保護状態を戻そうとした。個々の動作は合理的でも、多数のノードが同時に相手を探すと、空き容量への需要が急増する。AWSは、不十分なバックオフと、発生確率は低いものの競合状態が存在したことを説明している。これらが重なり、再ミラーリング要求が連鎖する「嵐」になった。

この局面では、冗長化は静的な複製数では測れない。修復に使える帯域、空きディスク、処理枠、要求を遅らせる制御、そして同時回復の上限が必要になる。通常時に二重化されていても、最大規模の復旧需要を吸収できなければ、保護機構は障害時に追加負荷へ転じる。復旧能力は余剰ではなく、冗長化を実際に機能させる制御である。

AZ内の障害がリージョン制御面へ波及した理由

影響はストレージノードだけにとどまらなかった。長時間完了しないボリューム作成呼び出しが、リージョンのコントロールプレーンにあるスレッドプールを占有した。その結果、直接影響を受けたAZの外でもEBS APIのエラーと遅延が発生した。物理的な障害領域が限定されていても、共有制御資源が飽和すれば、管理面を通じて影響が広がる。

したがって、AZ分離を評価するときはデータ配置だけでは足りない。キュー、スレッド、タイムアウト、負荷遮断、テレメトリーといった制御面の資源が、障害領域をまたいでどのように共有されるかも確認しなければならない。AWSは劣化したクラスタの隔離とスロットリングによって負荷を下げたが、その必要性自体が、共有制御面の隔離が継続性の境界を左右することを示している。

数日に及んだ段階的な復旧

AWSによれば、クラスタが安定した時点で、影響を受けたAZ内のEBSボリュームのおよそ13%が停止状態にあった。その後は物理容量の追加、複製の再構築、滞留処理の解消、残存案件の手動対応が続いた。サービスの一部が戻った時刻と、すべてのデータ整合性判断が終わった時刻は同じではない。

さらにAWSは、同じ「影響を受けたAZ内のボリューム」を分母として、0.07%を整合した状態に復元できなかったと報告した。13%と0.07%は異なる局面を表す別の指標であり、米国東部リージョン全体やAWS全体へ一般化してはならない。公開資料からは、失われたバイト数、レコード数、影響顧客数、経済損失の総額は確定できない。

復旧報告には少なくとも三つの状態が必要だ。APIが応答すること、アプリケーションが業務を再開できること、データが整合した状態にあることだ。「稼働中」という単一表示では、その差を利用者が判断できない。残件数、処理速度、データ整合性の確認方法、手動案件の境界を示すことが、復旧を説明可能にする。

RDSと下流サービスが示した依存関係

RDSはデータベースとログの保存にEBSを利用していた。AWSの説明では、一部のMulti-AZインスタンスで、それまで遭遇していなかった条件により自動フェイルオーバーが働かず、手動介入が必要になった。複数AZ構成は重要な対策だが、共有する保存層や制御面、切替条件まで無条件に独立させるものではない。

下流ではHerokuが広範なアプリケーション障害を直接報告し、当時の報道はReddit、Foursquare、Quoraなど複数の公開サービスへの影響を伝えた。ただし、名前が挙がった各サービスに同じ故障経路、停止時間、復旧品質、データ結果があったとは限らない。これらの資料が裏付けるのはクラウド依存の波及であり、被害者数の完全な一覧ではない。

誰が何を制御できたのか

プロバイダー側には、ネットワーク変更、復旧容量、バックオフ、競合状態、スレッドプール、負荷遮断、AZ隔離、復旧の可視性を設計・運用する権限と情報があった。したがって、これらの制御が既知の障害規模に耐えられるかを試し、利用者が判断できる粒度で状態を伝える責任はAWS側にある。一方、公開資料は特定の個人の過失、承認違反、法令違反、契約違反を立証していない。組織の制御責任と、根拠のない個人非難は区別すべきだ。

顧客側にも、依存関係の把握、バックアップ、復元試験、アプリケーションの縮退動作、切替手順、許容停止時間と許容データ損失の定義という役割がある。ただし、顧客が備えるべきだという事実は、プロバイダーの設計責任を消さない。逆に、プロバイダーの障害が顧客側のすべての事業継続判断を代行するわけでもない。責任共有は、被害を相手へ転嫁する言葉ではなく、各主体が持つ権限、情報、資源、準備時間を明示する枠組みである。

発表された是正策と検証の境界

AWSは、復旧用容量バッファの拡大、より積極的なバックオフ、競合状態の修正、タイムアウトと負荷遮断の改善、AZ隔離の強化、復旧制御の自動化、Multi-AZ関連ツールの改善、より頻繁な情報発信を発表した。これらは原因連鎖の各所に対応しており、単一のネットワーク変更手順だけを直すより広い。

ただし、この閉じた資料集合は、発表後に各対策がいつ、どの範囲で、どの試験により完了したかを独立に検証していない。発表は是正意図の証拠であり、実装完了や現在のAWS構成の証拠ではない。2011年当時の構造と顧客向け機能を、現在の事実として扱うこともできない。

現在にも残る保証上の問い

この事例から導ける実務的な問いは明確だ。最大何台が同時に修復へ入り、どの資源が最初に飽和するのか。バックオフにはジッターと上限があるか。劣化したクラスタは共有制御面から自動隔離されるか。物理容量の追加を待たずに安全な縮退運転へ移れるか。API回復、業務回復、データ整合性回復を別々に測れるか。未復旧案件を利用者が資源単位で確認できるか。

復旧試験は、単一ノードの故障だけでなく、多数のノードが同時に保護状態を失う状況を含む必要がある。定常負荷の下で十分だった予備容量が、修復トラフィックと利用者要求の競合下でも十分かを測る。さらに、テストの合否だけでなく、想定した分母、到達した上限、遮断が作動した時点、残った未知を記録する。それが「冗長化している」という説明を、検証可能な保証へ変える。

2011年のEBS障害が残した核心は、復旧が平常運転の後処理ではないという点にある。復旧のための容量と制御が設計され、障害領域が管理面でも隔離され、完了状態が測定されて初めて、冗長化は説明責任を果たせる。原因を一つの変更ミスへ縮めず、増幅条件と制御権限を追うことが、同種障害を減らすための出発点となる。

出典