日本語での要約2011年5月9日4月21日から23日のあいだ、Foursquare、Quora、Herokuなど多くのサービスに影響を与えたAmazonクラウドの大規模障害。このとき実際にどのような障害が発生していて、どう対応したのか、詳しい日本語での資料がAmazonから公開されています。(参考和訳)この資料は非常に詳細に記されているため、短時間で内容を把握できるものではありません。そこで本記事では資料からポイントを引用し、要約してみました。以下からの記事はあくまで独自に内容を要約したものです。正確な情報は原文をご覧ください。読み込み、書き込み操作が行えなくなる、という現象でした。障害の影響は一部アベイラビリティゾーンを超えて、米国東リージョン全体に渡っていました。アベイラビリティゾーンとは、Amazonクラウドのデータセンターの区画で、あるアベイラビリティゾーンでの障害がほかのアベイラビリティゾーンに影響を及ぼすことは基本的にないはずでした。EBSの仕組み資料では、障害を理解するに当たり、簡単にEBSの仕組みに触れています。EBSは、複数のEBSノードから構成される「EBSクラスター」と、EBSに対するリクエストを適切なEBSクラスターに伝える「EBSコントロール・プレーン」から構成されます。EBSクラスター内のノードは、耐久性や可用性の向上のためピア・ツー・ピア構成になっていて、つねに高速にレプリカを取り合っています。EBSコントロール・プレーンは、可用性と耐障害性のために、アベイラビリティ・ゾーンをまたがって分散されています。ネットワークの設定変更が障害の引き金に障害の引き金になったのは、ネットワーク設定の変更でした。米国東リージョンの単一のアベイラビリティ・ゾーンにおいて、通常の拡張作業の一環としてネットワーク設定の変更が行われました。このとき、間違ってトラフィックが容量の小さな予備のネットワークへルーティングされてしまいました。予備のネットワークはそのトラフィックに耐えられず、またプライマリネットワークのトラフィックは失われたため、この変更の影響を受けたEBSクラスターではノード間の通信が行えなくなりました。ネットワーク設定の間違いはすぐに元に戻されたようです。影響を受けたEBSの状態は元に戻りませんでした。その後、誤ったトラフィック移行作業がロールバックされ、ネットワーク接続が回復しましたが、これらのノードが一斉に、再ミラーリングを行うための容量をEBSクラスター内で検索し始めました。ネットワークの回復と同時に発生した多数のノードによるレプリケーション先を探す動作が、次の問題を引き起こしていきます。通常であれば、この検索自体は数ミリ秒で完了します。クラスター内の未使用領域があっという間に使い果たされてしまい、多くのノードがスタック状態のままになり、クラスター内で使用できる容量を繰り返し探し続けることになりました。これにより、多数のEBSボリュームが実質的にスタックした状態になったとのこと。13%のボリュームがスタックしていました。EBSクラスターの障害を深刻にした要因が、2つ挙げられています。ノードが新しいノードを発見するのに失敗しているあいだ、十分な間隔を置かずに何度も検索を継続したこと。非常に低い確率ながらノードが同時に大量のレプリケーションを処理する際に競合状態が発生し、ノードを停止させてしまうバグがあった。これによりさらにノードのスタックが増え、再ミラーリング要求が発生する悪循環となった。EBSコントロール・プレーンに影響が飛び火EBSクラスターで発生した問題は、次にEBSコントロール・プレーンにも影響を及ぼし始めます。APIリクエストがどんどんキューイングされていきました。コントロール・プレーンはAPIリクエストを処理することができなくなり、リージョン内の別アベイラビリティ・ゾーンに対するAPIコールも失敗するようになりました。EBSコントロール・プレーンはアベイラビリティゾーンにまたがって分散していたため、その影響が別のアベイラビリティゾーンにも出始めます。APIリクエストの発行を無効にします。Volumeリクエスト以外のAPIに関する遅延やエラー発生率は正常値に復帰しました。状況は落ち着くかに見えましたが、再び状況は悪化します。時点までに、リージョン内でEBSのAPIコールのエラー発生率と遅延が再び上昇しました。理由は、前述のバグによって多数のEBSノードが停止し続けたため、EBSコントロール・プレーンが適切なノードを探すための処理がどんどん増えていき、それが処理能力の低下を引き起こしたためです。APIコールの実行がいったん止められました。EBSチームは障害の発生しているEBSクラスターとEBSコントロール・プレーンの間のすべての通信を遮断する作業を開始しました。APIコールの遅延とエラー発生率は正常に復帰しました。これによって4月21日の正午までに、障害が発生したアベイライビリティゾーン以外はほぼ正常に復帰しました。APIコールの実行が止められたアベイラビリティゾーンを復旧させる作業となります。12:04PM(PDT)、(略)この時点で我々は、リカバリー処理に焦点を絞りました。13%のボリュームがスタック状態であり、EBSのAPIその特定のアベイラビリティ・ゾーンで利用不可となっていました。問題は、多数のEBSボリュームが、停止したボリュームの代わりとなる新たなレプリカを作成しようとしていたことでした。それに対処することが優先事項となります。優先事項は、ストレージ容量を追加し、スタックしたボリュームが新たなレプリカを作成できる容量を作ることでした。単純に容量を追加できるわけではありませんでした。課題は2つありました。1つ目はノードに障害が発生すると、EBSクラスタは全てのデータレプリカの再ミラーリング処理が終わるまでこのノードを再利用することはありません。障害が発生したノードは、あとで修復できるように自動的に再利用されないようになっています。そこで、物理的に新たなEBSノードを追加する必要があり、それに時間がかかったとのこと。2つ目はノード間で新たな容量を参照するための通信を抑えこむために修正したところ(上記ステップでクラスタを安定させるために行ったのですが)、新しい容量をクラスタに追加するのに困難が生じました。既存のサーバーに新たな負荷を与えないようにしながら、EBSチームはネゴシエーション処理を新規ビルドしたサーバーに適用させるため慎重に修正を加え処理をさせる必要がありました。した措置により、復旧作業が進んでいきました。02:00AM(PDT)、EBSチームは大量の新たな容量を追加することに成功しレプリケーションのバックログの作業を開始。4月22日の昼過ぎには、ほぼ復旧状態へ。(PDT)、9時間に渡ってEBSボリューム復旧が行われ、障害の発生したアベイラビリティ・ゾーンの全体の2.2%以外が復旧しました。翌日、最終的にEBSへのAPIアクセスが利用可能となりました。PM(PDT)、障害の発生したアベイラビリティ・ゾーンのEBSへのAPIアクセスが利用可能となりました。アベイラビリティゾーンの分散は実際には有効だったAmazonは当然ながら今回の障害で学んだことを今後の防止策として活かすとしています。その主なものとして以下のようなものがあがっています。大量のリカバリー処理に対応できるよう、これまでの容量プランニングと監視を修正する。EBSノードにおけるリトライのロジックを修正し、再ミラーリングのストームを防ぐEBSノードが競合状態になるバグを修正する。今回の障害は複数のアベイラビリティゾーンに及んだとはいえ、その影響は小さく、複数のアベイラビリティゾーンへの分散は実際には有効に機能したと説明しています。結果的に、マルチプル・アベイラビリティ・ゾーンの利点を生かしているアプリケーションを構築されているお客様にこの障害による甚大な可用性の被害は出ておりません。(略)私共の監視システムではEBSコントロール・プレーン分及びボリュームでの再ミラーリングのストームは明らかに該当アベイラビリティ・ゾーン内だけで影響を及ぼしており、同一リージョン内の残りのアベイラビリティ・ゾーン内にある既存EBSボリュームに対しての大きな影響はありませんでした。実際に障害が別のアベイライビリティゾーンに影響したのは、0.07%以下だったと。正常なアベイラビリティ・ゾーンにおいて我々の想定よりもやや多い”スタック”したボリュームが発見されましたが、それでも極めて少ない数です。0.07%以下でした。今後さらにアベイラビリティゾーンの独立性を完全にするとともに、顧客にも複数のアベイラビリティゾーンを利用しやすい環境を提供していくと結ばれています。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。2.7サポートを発表Google、Lookerの買収完了を発表。Enterprise、BtoBスタートアップ向け支援プログラムで無料提供と発表。Networksの買収を正式発表。Terminal」機能確定版リリース。コマンドラインからIssueやプルリクなど実行可能に。usPublickeyについて/運営者についてお問い合わせ広告についてプライバシーポリシ。