Amazonクラウドの大規模障害、そのときに内部で何が起きていたのか？ 日本語での要約

4月21日から23日のあいだ、Foursquare、Quora、Herokuなど多くのサービスに影響を与えたAmazonクラウドの大規模障害。このとき実際にどのような障害が発生していて、どう対応したのか、詳しい日本語での資料がAmazonから公開されています。

この資料は非常に詳細に記されているため、短時間で内容を把握できるものではありません。そこで本記事では資料からポイントを引用し、要約してみました。

以下からの記事はあくまで独自に内容を要約したものです。正確な情報は原文をご覧ください。

今回発生した障害とは何だったのか？

今回発生した障害を手短にまとめると、米国東 (US East) リージョンにおける一部のアベイラビリティゾーンにおいて、Amazon Elastic Block Store (EBS) で読み込み、書き込み操作が行えなくなる、という現象でした。

そして障害の影響は一部アベイラビリティゾーンを超えて、米国東リージョン全体に渡っていました。

アベイラビリティゾーンとは、Amazonクラウドのデータセンターの区画で、あるアベイラビリティゾーンでの障害がほかのアベイラビリティゾーンに影響を及ぼすことは基本的にないはずでした。

EBSの仕組み

資料では、障害を理解するに当たり、簡単にEBSの仕組みに触れています。

EBSは、複数のEBSノードから構成される「EBSクラスター」と、EBSに対するリクエストを適切なEBSクラスターに伝える「EBSコントロール・プレーン」から構成されます。

EBSクラスター内のノードは、耐久性や可用性の向上のためピア・ツー・ピア構成になっていて、つねに高速にレプリカを取り合っています。EBSコントロール・プレーンは、可用性と耐障害性のために、アベイラビリティ・ゾーンをまたがって分散されています。

ネットワークの設定変更が障害の引き金に

障害の引き金になったのは、ネットワーク設定の変更でした。

4月21日 12:47AM (PDT) に、米国東リージョンの単一のアベイラビリティ・ゾーンにおいて、通常の拡張作業の一環としてネットワーク設定の変更が行われました。

このとき、間違ってトラフィックが容量の小さな予備のネットワークへルーティングされてしまいました。予備のネットワークはそのトラフィックに耐えられず、またプライマリネットワークのトラフィックは失われたため、この変更の影響を受けたEBSクラスターではノード間の通信が行えなくなりました。

ネットワーク設定の間違いはすぐに元に戻されたようです。しかし影響を受けたEBSの状態は元に戻りませんでした。

その後、誤ったトラフィック移行作業がロールバックされ、ネットワーク接続が回復しましたが、これらのノードが一斉に、再ミラーリングを行うための容量をEBSクラスター内で検索し始めました。

ネットワークの回復と同時に発生した多数のノードによるレプリケーション先を探す動作が、次の問題を引き起こしていきます。

通常であれば、この検索自体は数ミリ秒で完了します。今回は、大量のボリュームが同時に影響を受けたため、EBS クラスター内の未使用領域があっという間に使い果たされてしまい、多くのノードがスタック状態のままになり、クラスター内で使用できる容量を繰り返し探し続けることになりました。

これにより、多数のEBSボリュームが実質的にスタックした状態になったとのこと。

この時点で、影響を受けたアベイラビリティ・ゾーン内における 13%のボリュームがスタックしていました。

EBSクラスターの障害を深刻にした要因が、2つ挙げられています。

• ノードが新しいノードを発見するのに失敗しているあいだ、十分な間隔を置かずに何度も検索を継続したこと。
• 非常に低い確率ながらノードが同時に大量のレプリケーションを処理する際に競合状態が発生し、ノードを停止させてしまうバグがあった。これによりさらにノードのスタックが増え、再ミラーリング要求が発生する悪循環となった。

EBSコントロール・プレーンに影響が飛び火

EBSクラスターで発生した問題は、次にEBSコントロール・プレーンにも影響を及ぼし始めます。多数のEBSクラスターが容量を使い果たしてスタックした結果、EBSコントロール・プレーンには処理待ちのCreate Volume APIリクエストがどんどんキューイングされていきました。

キューイングされた大量のリクエストによってスレッドが使い果たされてしまうと、EBS コントロール・プレーンはAPIリクエストを処理することができなくなり、リージョン内の別アベイラビリティ・ゾーンに対するAPIコールも失敗するようになりました。

EBSコントロール・プレーンはアベイラビリティゾーンにまたがって分散していたため、その影響が別のアベイラビリティゾーンにも出始めます。

ネットワーク構成の設定ミスから約2時間後、EBSコントロール・プレーンの問題を除くべく、Creative Volume APIリクエストの発行を無効にします。

4月21日 2:40AM(PDT) に、障害が発生していたアベイラビリティ・ゾーンで新しく発行されたCreate Volumeリクエストを無効にする変更を行い、2:50AMまでの時点で、Create Volumeリクエスト以外のAPIに関する遅延やエラー発生率は正常値に復帰しました。

いったん状況は落ち着くかに見えましたが、再び状況は悪化します。

5:30AM (PDT) の時点までに、リージョン内でEBSのAPIコールのエラー発生率と遅延が再び上昇しました。

理由は、前述のバグによって多数のEBSノードが停止し続けたため、EBSコントロール・プレーンが適切なノードを探すための処理がどんどん増えていき、それが処理能力の低下を引き起こしたためです。

そこで、障害が発生したアベイラビリティゾーン内のEBS APIコールの実行がいったん止められました。

8:20 AM (PDT) に、EBSチームは障害の発生しているEBSクラスターとEBSコントロール・プレーンの間のすべての通信を遮断する作業を開始しました。この作業によって当該アベイラビリティ・ゾーン内でのEBS APIコールが全て実行されなくなりましたが、リージョン内の別アベイラビリティ・ゾーンについてはEBS APIコールの遅延とエラー発生率は正常に復帰しました。

これによって4月21日の正午までに、障害が発生したアベイライビリティゾーン以外はほぼ正常に復帰しました。

復旧へ向かうが、2つの課題が

ここからは、障害によりEBS APIコールの実行が止められたアベイラビリティゾーンを復旧させる作業となります。

4月21日 12:04PM（PDT）、（略）この時点で我々は、リカバリー処理に焦点を絞りました。障害が発生したアベイラビリティ・ゾーン内のおよそ 13％のボリュームがスタック状態であり、EBSのAPIその特定のアベイラビリティ・ゾーンで利用不可となっていました。

問題は、多数のEBSボリュームが、停止したボリュームの代わりとなる新たなレプリカを作成しようとしていたことでした。それに対処することが優先事項となります。

優先事項は、ストレージ容量を追加し、スタックしたボリュームが新たなレプリカを作成できる容量を作ることでした。

しかし、単純に容量を追加できるわけではありませんでした。課題は2つありました。

1つ目はノードに障害が発生すると、EBSクラスタは全てのデータレプリカの再ミラーリング処理が終わるまでこのノードを再利用することはありません。

障害が発生したノードは、あとで修復できるように自動的に再利用されないようになっています。そこで、物理的に新たなEBSノードを追加する必要があり、それに時間がかかったとのこと。

2つ目はノード間で新たな容量を参照するための通信を抑えこむために修正したところ（上記ステップでクラスタを安定させるために行ったのですが）、新しい容量をクラスタに追加するのに困難が生じました。既存のサーバーに新たな負荷を与えないようにしながら、EBSチームはネゴシエーション処理を新規ビルドしたサーバーに適用させるため慎重に修正を加え処理をさせる必要がありました。

こうした措置により、復旧作業が進んでいきました。

4月22日 02:00AM（PDT）、EBSチームは大量の新たな容量を追加することに成功しレプリケーションのバックログの作業を開始。

4月22日の昼過ぎには、ほぼ復旧状態へ。

4月22日 12：30PM （PDT）、9時間に渡ってEBSボリューム復旧が行われ、障害の発生したアベイラビリティ・ゾーンの全体の2.2％以外が復旧しました。

そして翌日、最終的にEBSへのAPIアクセスが利用可能となりました。

4月23 日 6:15 PM（PDT）、障害の発生したアベイラビリティ・ゾーンのEBSへのAPIアクセスが利用可能となりました。

アベイラビリティゾーンの分散は実際には有効だった

Amazonは当然ながら今回の障害で学んだことを今後の防止策として活かすとしています。その主なものとして以下のようなものがあがっています。

• 大量のリカバリー処理に対応できるよう、これまでの容量プランニングと監視を修正する。
• EBSノードにおけるリトライのロジックを修正し、再ミラーリングのストームを防ぐ
• EBSノードが競合状態になるバグを修正する。

また、今回の障害は複数のアベイラビリティゾーンに及んだとはいえ、その影響は小さく、複数のアベイラビリティゾーンへの分散は実際には有効に機能したと説明しています。

結果的に、マルチプル・アベイラビリティ・ゾーンの利点を生かしているアプリケーションを構築されているお客様にこの障害による甚大な可用性の被害は出ておりません。

（略）

私共の監視システムではEBSコントロール・プレーン分及びボリュームでの再ミラーリングのストームは明らかに該当アベイラビリティ・ゾーン内だけで影響を及ぼしており、同一リージョン内の残りのアベイラビリティ・ゾーン内にある既存EBSボリュームに対しての大きな影響はありませんでした。

実際に障害が別のアベイライビリティゾーンに影響したのは、0.07％以下だったと。

正常なアベイラビリティ・ゾーンにおいて我々の想定よりもやや多い”スタック”したボリュームが発見されましたが、それでも極めて少ない数です。言い換えますと、該当リージョン内の影響のあったアベイラビリティ・ゾーン以外における、”スタック”したボリュームのパーセンテージのピークは 0.07%以下でした。

今後さらにアベイラビリティゾーンの独立性を完全にするとともに、顧客にも複数のアベイラビリティゾーンを利用しやすい環境を提供していくと結ばれています。

関連記事

• Amazonクラウドの大規模障害を経て、これからは「データセンターはいつか落ちる」ことがサービス設計の前提となる