Amazon は先日，米国東部リージョンのアベイラビリティゾーンで発生したサービス障害に関する詳細な 報告書 を発表した。その分析や論評，今回の出来事から学ぶべき教訓 などの話題で，オンラインメディアは持ちきりだ。
今回の Amazon EC2 障害の 時間的経緯 の中で Eric Kidd 氏は，AWS のサービス中断に関連する一連の出来事について，外部的な視点から概説している。すべてが始まったのは 2011年4月21日 PDT(太平洋夏時間) 午前１時頃，Heroku がサービス機能に関する大量のエラーを出力し始めた時だ。障害は 4月24日 PDT 午後 7:30 頃，すべての RDS データベースがオンライン復帰したことを Amazon が発表するまで，ほぼ４日間続いた。その間，一部ユーザに対するサービスが停止，ないしは断続的に停止した。
いったい何が起きたのだろう？ 障害発生の８日後，Amazon は，今回のサービス停止についての詳細な報告書 を発表した。事の起こりは 4月21日 PDT 12:47，"米国東部リージョン内にあるアベイラビリティゾーンのひとつで，通常のスケーリング作業であるネットワークの変更" を，"プライマリネットワークの容量を増強するために" 実施したことだ。作業のために，プライマリネットワーク内のネットワークトラフィックを，別のルータに移動させる必要があった。ところがこの時に誤って，低レベルトラフィック側のネットワークに属するルータに分岐してしまったのだ。このルータがトラフィックを扱いきれず，そのために "影響のあるアベイラビリティゾーンに属する EBS ノードの多数がクラスタ上の他の EBS ノードから完全に分離され"，"関連するノードそれぞれが完全に切り離された状態になった。"
トラフィックはすぐに適切なルータに戻されたが，すでに多数の EBS ノードがデータのミラーリングに必要なサーバ領域の取得を始めていた。大量のノードがフリースペースを同時に検索し始めたため，EBS クラスタの使用可能領域がすぐに使い尽くされて，影響のあったアベイラビリティゾーンのボリュームの 13% が "stuck" 状態になった。このためクラスタはそれ以降，EBS コントロールプレーン – EBS クラスタを管理する – に対する新たな "Create Volume" API リクエストをサービスできなくなった。これらの API コールはタイムアウトが長いため，外部からのボリューム関連の要求処理用にアロケートされるスレッドプール内のスレッドが枯渇する結果となった。コントロールプレーンがリージョン内の複数のアベイラビリティゾーンに分散されていることからスレッドの枯渇は他のゾーンにも伝播し，結果的にますます多くのノードが，コンテントのレプリケートに必要なフリースペースを確保できなくなった。そして早朝の１時間で "stuck" が競合状態(race condition)に達したのだ。AWS チームは障害を起こした EBS クラスタとコントロールプレーン間の通信を切断し，リージョン内の他のクラスタが stuck 状態になるのを防止した上で，影響を受けたボリュームが領域のミラーリングにおいて "hungry" 以下になるようなフィックスを実行して対処した。
Amazon の報告によると，障害はひとつのアベイラビリティゾーン内で発生していて，ディグレードした EBS クラスタは同日正午には安定し，新たな EBS ベースの EC2 インスタンスがローンチ可能になった。しかし多数のエラーが引き続き発生していたため，次には "オンラインのストレージ容量を追加して，"stuck" 状態のボリュームで新たなレプリカ生成に必要なスペースを獲得できるようにする" ことが優先された。レースコンディションの再発生を防ぐために，ミラーリング容量の追加はゆっくりと始められた。その後24時間の内に影響を受けた EBS クラスタ内のボリュームの 97.8% が完全にレプリケートされ，stuck 状態のボリュームは 2.2% となった。クラスタとコントロールプレーン間の通信も再開する必要があったが，膨大なオペレーションがバックログに堆積していたため，それらを開放するのにさらに24時間を要した。その後でチームは，stuck していた最後の 2.2% のボリュームに対して適切な機能を再設定することができた。最終的には "ユーザに対して正常状態に回復することができなかったのは，対象アベイラビリティゾーンのボリュームの 0.07% だった。" つまりデータの一部が失われたのだ。0.07% が何 GB に当たるのか，報告書には記載されていない。トラブルを起こした EBS クラスタにより，いくつかの RDS サービスが影響を受けた。それらは週末を通してレストアされたが，最終的にひとつの AZ データベースインスタンスの 0.4% が，消失した EBS データへの依存性のために復旧できなかった。
Amazon は将来的な再発防止のために，今回の経験で学んだことをシステムに反映するとともに，ストレージ容量の増強を実施する，としている。
クラスタにおいて今後，再ミラーリングが頻発する状況の発生を防止するために，多数の修正を実施する予定です。また予備容量を追加することで，機能の低下した EBS クラスタが多数の再ミラーリング要求をより迅速に吸収できるようにして，再ミラーリング処理の集中を回避します。今回の経験から，大規模なリカバリ処理に多くの容量が必要であることが確認されましたので，データ容量に関する計画の見直しを行い，大規模障害時に必要な予備容量の追加と確保を実施します。すでにバッファ容量の大幅な増加に着手していますので，数週間内には必要な領域を準備できると考えています。
Amazon はさらに，障害防止策としてユーザが異なるアベイラビリティゾーンを容易に利用できるようにする，としている。しかし一方で，連続性のあるサービスを提供する最良の手段としては，複数のリージョンを並行使用する方法を推奨する。リージョンは完全に分離されていて，相互に独立しているからだ。
Amazon は影響を受けた全ユーザに対して，"影響を受けたアベイラビリティゾーン内で実行されていた EBS ボリューム，EC2 インスタンス，RDS データベースインスタンス利用量の 100% に相当するクレジットを 10 日分" 提供する予定だ。そして報告書は，AWS ユーザに対する謝罪のことばで締め括られている。
メディアはこぞって，このクラウドで始めて発生した障害の記事を書き立てている。Jason Bloomberg 氏が結論としているのは，多くの 教訓 だ。
- 100% 信頼できるものは存在しない。 事実として，IT の世界に 100% なものはない – 100% バグフリーなコード，クラッシュに対して 100% 安全なシステム，100% の強度を持つセキュリティは存在しないのだ。Amazon がサイコロを振ってゾロ目が出たからといって，パブリッククラウドの信頼性が障害発生以前に比べて，いく分でも低下したことにはならない。高可用性 IT インフラストラクチャの構築は，株式市場への投資と同じである。リスク低減のための最良の手段は分散なのだ。卵が手に入った？ それならバスケットを増やせばよい。
- 再び同じ問題が起こるとは考え難い。 Amazon にはとてつもなく優秀なクラウド専門家たちがいて，ほとんどの問題に対処できるクラウドアーキテクチャを構築済みである，と考えることに支障はない。それゆえ今回の問題については非常に特殊で，複雑な事象が複合したのだ，と見なしておけば十分だ。このような特殊な状況が二度と起きないように，彼ら専門家が今回の出来事の原因を徹底的に調査していることについても疑いはない。
- 未知の事象というのは，定義上も本質的に予測不能である。 今回の障害のような特別な事象の組合せの再現が考え難くても，まったく予想できない別の問題が将来的に発生する可能性までは否定できない。しかしこのような問題は，パブリッククラウドに再び影響を与える可能性があるだけでなく，プライベートやハイブリッド，あるいはコミュニティクラウドでも十分に起こり得るものだ。言い換えるなら，パブリッククラウドを見限ってより安全と思われるプライベートクラウド方向に逃げ込んでも，事態は何も変わらない，ということだ。
- Amazon が学ぶべき最も重要な教訓は，信頼性 (reliability) よりも視認性 (visibility) に関する部分である。Amazon クラウドサービスの最大の弱点は，ユーザに対して視認性が提供されていないことだ。この "カーテンの裏側は気にしないでください" 的な態度が，以前に ZapFlash でも議論した，Amazon のクラウド抽象化のサポート手法の一部分になっている。しかし今回はこれが，同社とユーザにとって仇になった。Amazon が成功を積み重ねるためには着物 (kimono) をもう少し開いて，不都合な部分のある内部インフラストラクチャ管理に関しても，ある程度の視認性をユーザに提供しなければならない。
RightScale 社のブログにも Amazon EC2 障害解析 に関する記事がポストされている。そこでは今回得た教訓と合わせて，サービス障害時における Amazon のコミュニケーション方法が不適切であった点を取り上げている。
- 最初のステータスメッセージ投稿までに 40分も費やさないこと！
- "instances/volumes/… のごく一部" といった表現ではなく，実際の比率を提供すること！ 私たちのように多数のサーバ／ボリュームを使用する場合には 1% なのか 25% なのかが重要である。それによって対策が異なるのだ。
- "影響を受けたアベイラビリティゾーン" や "複数のアベイラビリティゾーン" という表現をせず，個々のゾーンの名称を公表し，名称で示すこと (ゾーン 1a がアカウント毎に異なる物理ゾーンを指していることは承知しているので，各ゾーンを特定できるような第２の名称を設定する必要がある)。
- 個別のステータス情報を提供すること – Eメール (あるいは他の手段) を使用して，ユーザそれぞれにインスタンスとボリュームについての情報を伝えること。CPU ロードのような情報の入手を期待しているのではなく，ここで言っているのは，例えば "以下のボリューム (idで提示) は現在復旧作業中で，数時間内に使用可能になります。以下のボリュームについては，別途手作業による対応が必要です。…" というような情報だ。これがあればユーザは，何をすべきかを選択し，計画を立てることができる。
- 予測すること！ 最初の事象が発生してから "影響を受けるアベイラビリティゾーン" のボリュームが割り出されるまで，相当な時間を要している。Amazon は問題が拡散していることを知っていたのだから，全ユーザに警告することができたはずだ。例えば "障害が引き続き拡大中ですので，影響のあるアベイラビリティゾーン[sic]で稼働するすべてのサーバとボリュームを，別のゾーンあるいは領域へ移動するようにお願いします。"，というようにである。
- オーバービューを提供すること！ 影響を受けている機能と対応が完了した機能について，個々の状態一覧を随時リストアップするべきだ。メッセージ内容の検索や各機能の状態に関する推測をユーザに強いてはならない。
- 準備段階のものでよいから，謝罪や背景情報をブログにポストすることはできないのか？ いつもは日に何回もツィートしている AWS のツィータから，この時は何もなかった。この24時間に起きた出来事について，何らかの 発言があって然るべきではないか！ どのように問題に対処したかということより，Amazon がこの問題をどう考えているかという点が，ユーザの知りたい部分なのではないか ???
サイト "High Scalability" では，Amazon の障害に関連する重要記事 の長大なリストを編集している。紹介されているのは，いくつかの企業の体験談や関連するフォーラムへのリンク，問題の所在 – Amazon なのか，あるいはユーザなのか –，得られた教訓などだ。
最大のクラウドプロバイダとそのユーザを襲った今回の不幸な出来事によって，人々がクラウドへの展開に躊躇するようになることは確実だ。また産業界全体に対して，技術的に優秀なシステムがいかに脆弱になり得るか，という強力なメッセージを送ることにもなる。加えて，信頼性と回復力を求める戦いは終わっていない，決して終わることはない，ということがもし忘れられているとすれば，その事実を改めて突き付けてもいるのだ。