Amazon 2011年4月の障害
古い話だけどこちらも。publickeyの記事より。2011年4月21日から23日にかけて生じた大規模障害。こちらがamazonからの発表。EBSの構成について詳しく書かれていて非常に興味深い。あんまり関係ないけど、このページすっごく読みにくい。改行幅が小さすぎ、英語向けに調整されたスタイルシートをそのまま使ってるんじゃないか？1行の文字数が多すぎ。
症状
アメリカ東部のリージョンで、EBS(Elastic Block Store)へのアクセスができなくなった。このEBSというのは、普通のコンピュータで言うところのHDDなので、アクセス出来ないとEC2のインスタンスが全然動かない、ということになる。
EBSの構造
- EBSは、プライマリとセカンダリの2系統のネットワークで接続された多数のEBSノードから構成されている。
- EBSでは、データは複数のノードにレプリケーションされる。データはプライマリ・レプリカに対して書き込まれる。書き込みは即座に他のノードのレプリカに反映される。
- レプリカとの通信がとれなくなると、プライマリ・レプリカを持つノードはクラスタ上の別の領域を確保して新たにレプリカを作成する。この動作中はレプリカがない状態になるので、書き込みは不可となる。
- リージョン全体のEBSを管理するコントロール・プレーンと呼ばれるサービスがある。このサービスはすべてのAZにまたがって存在する。
何が起こったか
- プライマリネットワークのルーティングを変更しようとして誤ってセカンダリネットワークにルーティングしてしまった。セカンダリは容量が少なく、すぐにパンクした。その結果特定のノード群に対するネットワーク接続が、プライマリ、セカンダリの双方で途絶した。このネットワーク障害はすぐに復旧されたが、EBS内部ではすでにドミノが倒れ始めていた。
- レプリカを失ったノード群は、新たにレプリカを作成するために検索を開始した。通常はすぐに終わる動作だが、大量の検索リクエストが発生したため輻輳した。多くのノードはレプリカを見つけることができずスタックした。また、リクエストを連続して行う仕様だったためネットワークへの負荷は増大した。
- EBSに依存した他のサービス、たとえばRDSなども当然スタックした。
所感
わずかなオペレーションミスがトリガーとなり、障害が拡大していくのは悪夢のようだ。複雑に相互に依存したシステムはいきものみたい。こういう種類のシステムを設計するには、全く違う方法論が必要なんじゃないだろうか。
