Amazonは、先週ウェブ上で最も人気のあるサービスのいくつかをオフラインにしたクラウド障害について、エッセイほどの長さの説明を掲載しました。要約すると、システムアップグレード中の人為的ミスにより、Elastic Block Service（EBS）の冗長バックアップネットワークが誤って米国東部リージョンのネットワークトラフィック全体を占有し、過負荷状態を引き起こし、システムを混乱させたようです。
サービス復旧に向けた長い戦いの末、Amazonはデータの大半を復旧できたものの、0.07%については「お客様に安定した状態で復旧できなかった」と発表しました。ユーザーには10日間の利用クレジットが付与されますが、対象となるかどうかはAmazon Web Services（AWS）のコントロールパネルで確認する必要があります。弁護士に相談するだけでなく、AWSの利用規約も確認しているユーザーも少なくないでしょう。
ソフトウェアのバグも一因でした。通常のEBSの使用状況では発生しにくいものの、発生した障害の数が膨大だったため、このバグは深刻な問題となりました。Amazonはまた、他のより深刻な警報が鳴っているのと同時に他の問題が発生したことを検知できるほど、自社の警告システムが「きめ細やか」ではなかったと述べています。
Amazonはこの障害を「再ミラーリング・ストーム」と呼んでいる。EBSは基本的にElastic Compute Cloud（EC2）のストレージコンポーネントであり、ユーザーはEC2を使用することでAmazonのクラウドサービスでコンピューティング能力を利用できる。
EBSは2つのネットワークを介して動作します。プライマリネットワークと、バックアップと相互通信に使用される低速のセカンダリネットワークです。どちらもノードを含むクラスターで構成され、各ノードは独立したストレージユニットとして機能します。
データの整合性を保つため、ノードには常に2つのコピーが存在します。これは再ミラーリングと呼ばれます。重要なのは、片方のノードがバックアップ先のパートナーノードを見つけられない場合、代わりのノードが見つかるまで試行を続行し、成功するまで試行を続行するということです。同様に、新しいノードも有効なパートナーノードを作成する必要があり、成功するまで試行を続行します。
定期的なシステムアップグレード中に、米国東部リージョンのすべてのネットワークトラフィックが誤ってセカンダリネットワークに送信されたようです。セカンダリネットワークは速度が遅く、容量も低いため、このトラフィックを処理できませんでした。エラーに気づき、変更はロールバックされましたが、その時点でセカンダリネットワークはほぼ満杯になっており、プライマリネットワークの一部のノードは再ミラーリングを正常に実行できませんでした。再ミラーリングができない場合、ノードはバックアップが完了するまですべてのデータアクセスを停止します。このプロセスは通常は数ミリ秒で完了しますが、Amazonのエンジニアがシステムの修復に苦戦したため、数日かかることが判明しました。
発生した再ミラーリングの嵐により、EC2の日常的な使用時に通常発生する新規ノードの作成が困難になりました。実際、多数の新規ノード作成リクエストが発生し、処理不能となったため、EBS制御システムも部分的に利用できなくなりました。
その後、Amazonのエンジニアは新規ノード作成機能を無効化し、実質的にEBS（ひいてはEC2）にブレーキをかけました。おそらくこの瞬間に多くのウェブサイトやサービスがオフラインになったのでしょう。状況は改善し始めましたが、そこでソフトウェアのバグが発生しました。多数のEBSノードが同時に再ミラーリングのリクエストをクローズすると、リクエストが失敗してしまうのです。通常、この問題は顕在化することはありませんでした。これほど多くのノードが同時にリクエストをクローズする状況はこれまでなかったからです。
その結果、さらに多くのノードが再ミラーリングを試行し、状況はさらに悪化しました。EBS制御システムに再び悪影響が出ました。
EBSは障害が発生したと判断されたノードを信頼しないように設定されていたため、問題の解決は困難を極めました。そのため、Amazonのエンジニアは、需要を満たすために新しいストレージを物理的に設置して接続する必要がありました。需要は既存ボリュームの約13%に上り、おそらく膨大なストレージ容量です。さらに、彼らはさらなる障害を回避するためにシステムを再構成していましたが、このことが新しいハードウェアのオンライン化を非常に困難にしました。
システムの再プログラミングが行われ、最終的にはすべてが正常に戻り始めました。危機発生時にはスナップショットが作成されており、Amazonのエンジニアはそのうち2.2%を手動で復元する必要がありました。最終的には、データの1.04%をフォレンジックによる復元が必要になりました（アーカイブからファイルを手動で抽出・復元する必要があったと推測します）。そして、最終的に、ファイルの0.07%は復元できませんでした。それほど多くないように思えるかもしれませんが、Amazon Web Servicesがインターネットを動かすストリームトレインであることを考えると、かなり大量のデータであると考えられます。
もちろん、Amazonは全面的な改善を約束しました。今回の事態のきっかけとなったエラーを回避するための監査プロセスから、復旧の迅速化まで、あらゆる改善策が講じられています。謝罪も行われましたが、驚くほど短く、一部の人が望むほど卑屈なものではないかもしれません。この段階では、AWSのエンジニアは皆、数日の休暇を取りたいと思っているのではないでしょうか。
私も、今回の停電は異常事態だと予想していた一人です。どこかで天災が関係しているのではないかと考えていました。もしかしたら、カモメが換気パイプに落ちてサーバーを爆発させたのかもしれません。
残念ながら、どうやら私の考えは間違っていたようです。事前に予測できたはずの明らかな障害がいくつかあり、Amazon Web Servicesを利用するすべての人の信頼を失墜させるでしょう。結局のところ、「もしも」と問う人は誰もいなかったのです。
Amazon Web Servicesは依然として最も安価でアクセスしやすいサービスの一つであるため、今のところ誰も諦めようとは思っていません。しかし、Amazonは今後数ヶ月、数年にわたり、大規模なクラウド障害が単なる過去の出来事になるまで、清廉潔白を保たなければならないでしょう。
