アマゾンが詳細な経緯と対策を発表

Amazon Web Servicesの障害はなぜ起こったのか

2011/04/30

　米Amazon Web Services（AWS）は米国時間4月29日午後、同社のブロックストレージサービス「Amazon Elastic Block Store（EBS）」および、リレーショナルデータベースサービスの「Amazon Relational Database Service（RDS）」における約4日間にわたる障害につき、詳細な経過報告と対策を発表した。これによると、障害のきっかけはネットワークの構成変更作業におけるミスだった。同社は今回の障害が複数のAvailability Zone（AZ）に影響を与えた理由も説明した。

AWSが発表した今回の障害に関する説明（英語）

　EBSはAWSの仮想サーバサービスであるAmazon EC2のインスタンスから、仮想ディスクとして使える永続ストレージサービス。実態としてはディスクを備えたノード（コンピュータ）の集合体をクラスタとして構成、単一AZ内で複数のEBSクラスタを運用しているという。個々のEBSボリュームは、必ず同一EBSクラスタ内の複数のEBSノードに複製されることで、冗長性を確保する仕組みになっている。各EBSノードには、複数のEBSボリュームが維持されている。

　すべてのEBSノードは、2種類のネットワークに接続されている。1つは高速なメインネットワークで、EBSノード間の通信、Amazon EC2インスタンスとの通信、EBSを制御するEBSコントロールプレーン・サービスのすべてがこのネットワークを利用する。もう1種類は低速な予備ネットワークで、主にEBSノード間の通信で、メインネットワークがオーバーフローしてしまった場合の追加帯域として利用することを目的としている。

AWSのステータスダッシュボード。EBSの障害は4月21日に発生し、24日に事実上終息した

ネットワーク拡張のための作業でヒューマンエラー

　今回の障害は、「US EAST 1」リージョン内の特定AZで発生した（他のAZへの影響については後述する）。このAZでは、21日にメインネットワークの拡張作業が行われた。この際に、メインネットワークのために冗長接続されている2台のルータを流れるトラフィックを、1台に集約しようとして、誤って予備ネットワークに接続してしまったのだという（この部分の説明が不明瞭だが、すべてのトラフィックが予備ネットワークにルーティングされてしまったようだ）。

　追記（5月1日）：記事初出時にはメインネットワークが冗長化されており、この2経路の冗長ネットワークを流れるトラフィックを1経路に集約しようとしたと記述しましたが、報告を再度読みなおしたところ、ネットワークではなく、メインネットワークに接続するルータが2台の冗長接続構成となっており、この2台に流れていたトラフィックを1台に集約しようとしたところ、予備ネットワークに接続してしまったということのようです。修正してお詫びいたします。AWSは、この作業ミスによって通信不能となったのは、一部のEBSクラスタのみだとしていますが、なぜ一部なのかについては説明がありません

　低速な予備ネットワークは、膨大なトラフィックに耐えられず、特にあるEBSクラスタでは、EBSノード間の通信が事実上不能になった。EBSにおけるボリューム冗長性確保のメカニズムでは、既存のレプリカに対する複製の試みが一定時間失敗すると、既存レプリカをあきらめ、積極的にEBSクラスタ内に空きスペースを見つけて新たなレプリカを作成しようとする。障害の起こったEBSクラスタでは、EBSノード間の通信不能により、すべてのEBSノードが新たなレプリカを作成するモードに移行してしまった。

　AWSがネットワークの構成ミスに気づき、ネットワーク接続を回復した際、多数のEBSノードが同時に空きスペースを探してレプリカを作成しようと試み始めた。空きスペースは急速に枯渇し、多くのEBSノードは見つからない空きスペースを探し続けることになってしまった。また、EBSノード上のコードにバグがあり、複製リクエストの競合によってレースコンディションが発生し、クラッシュするEBSノードが次第に増加したという。

複数のAvailability Zoneが影響を受けた理由

　ここまでは、単一のAvailability Zone（AZ）に閉じた話だ。なぜ複数のAZに影響が波及したのか。AWSは、上述のEBSノードによる膨大な複製リクエストの継続が、他のAZへの影響につながったと説明する。

　これはEBSのコントロールプレーン・プロセスが、複数のAZを対象としたサービスを実行していることから来ているという。EBSのコントロールプレーン・プロセスは、EBSボリュームを管理し、Amazon EC2インスタンスとの関連付けを行っている。Amazon EC2インスタンスは、EBSのコントロールプレーン・プロセスに、自分が読み書きを行うべきプライマリ・レプリカはどれなのかを常時教えてもらうようになっている。

　空きディスクスペースを探しながら見つからないEBSノードは、EBS APIリクエストに応えられない状態になった。応答待ちのリクエストはEBSコントロールプレーン・プロセスのスレッドプールに蓄積される。create volumeをはじめとするEBSリクエストには、比較的長いタイムアウト時間が設定されており、すぐにEBSコントロールプレーンのスレッドが枯渇してしまった。このため、他のAZにおけるEBS APIリクエストへの応答も困難になったという。上記のレースコンディションを原因としたEBSノードのダウンが増加すると、さらにEBSコントロールプレーンとのやりとりが増加し、リージョン全体にわたってエラーが増加した。

　ここでAWSは、問題のEBSクラスタとEBSコントロールプレーン・プロセスの間のやり取りを遮断した。その後、他のAZへの影響が減少していったという。

EBSボリュームの復旧プロセス

　AWSは次に、このEBSクラスタの復旧作業に入った。ディスクスペース不足を解消するため、別のロケーションから搬入したコンピュータによる新たなEBSノードを追加、こうして十分なディスクスペースを確保したうえで、EBSノードによる再複製をひと通り終わらせた。一方でいったん遮断したEBSコントロールプレーンとの通信を、再びオーバーフローが起こらないように徐々に再開させた。AWSは、他のAZへの影響を最小化するため、障害の発生したAZだけのためのコントロールプレーンのインスタンスも追加したという。

　上記のプロセスでも復旧できなかったEBSボリュームは、障害の発生したボリューム全体の2.2％だったという。このうち、障害発生後にAmazon S3に対してAWSが行ったスナップショットを使って復旧できたデータがあり、最終的には0.07％が復旧できなかったという。

　Amazon RDSはストレージとしてEBSを使っている。このため、RDSを利用しているユーザーは、そのデータが障害の発生したEBSクラスタにあった場合には、自動的に影響を受けたことになる。単一のAZのみに依存する「Single-AZデプロイメント」のインスタンスは、45％が今回の障害の影響を受けたという。RDSでは別のAZにスタンバイ・レプリカを作成する「Multi-AZデプロイメント」を採用しているユーザーのほとんどは、自動フェイルオーバによってアプリケーションの運用を継続できたという。2.5％のDBインスタンスについてはフェイルオーバが働かず、その一部についてはバグが絡んでいるため、修正を行うとしている。

Availability Zoneを今後どう使うか

　もともとAZという単位が設けられている理由は、サービスの一部で起こった障害を、広く伝播させないためだ。同社はAmazon EC2の紹介ページで、AZについて、次のように説明している。

　「Availability Zoneは他のAvailability Zoneにおける障害から隔離されるように設計された別個のロケーションであり、同一リージョンの他のAvailaility Zoneとの、安価で低遅延のネットワーク接続を提供する。別個のAvailability Zoneでインスタンスを起動することにより、単一のロケーションにおける障害からあなたのアプリケーションを保護することができる」

　しかし今回は、同一リージョンの全AZを対象に提供されているEBSコントロールプレーンが応答不能となったことで、複数のAZにEBSへのアクセス不能状態が広がったことになる。これは、AZ間での障害隔離効果が不十分であることを意味するのではないか。AWSでは今回、次のように、AZ間で共通のAPIを提供していることの意味を説明した。

　「複数のリージョン間でデータを移動したければ、われわれがユーザーのためにリージョン間のデータの複製を行うことはないため、あなたがこれを行わなければならない。各リージョンについて、別個のAPIセットを使う必要もある。リージョンは可用性向上のための強力な構成要素となれる。しかし、それを活用するには、アプリケーション構築者側の努力が要求される。当社は、リージョン内でAvailability Zoneを提供し、耐障害性の高いアプリケーションを容易に構築できるようにしている。Availability Zoneは物理的、論理的に分離されたインフラで、相互に高い独立性を保ちながらも、高速・低遅延なネットワーク接続性と、容易なデータ複製手法、そして一貫した管理APIセットを提供する。例えば、あるリージョン内で取得したEBSのスナップショットを、どのAvailability Zoneにもリストアできるし、同一のAPIを使ってEC2やEBSのリソースをプログラムで操作できる。われわれは、ユーザーが耐障害性の高いアプリケーションを容易に構築できるように、こうした疎結合を提供している」

　今回の障害で、たしかにEBSコントロールプレーン・プロセスへの過重負荷により、他のASにも影響はあったが、他のAZでアクセス不能になったEBSボリュームの比率は0.07％に過ぎなかったとAWSは記している。そのうえで、EBS制御におけるAZ間の独立性を高める努力が必要だと認めている。AWSでは、3つの対策を実施するという。

　第1に、即座にEBSコントロールプレーンにおいて今回発生したスレッド枯渇を防ぐため、タイムアウト・ロジックを改善するという。第2に、EBSコントロールプレーンがAZをより意識し、容量オーバー時に負荷をよりインテリジェントに低減できるようにする。第3に、EBSコントロールプレーン・サービスをEBSクラスタ単位のサービスに移行するよう検討するとしている。

　AWSはさらに、複数AZの活用を、これまでよりも強力に推進していくと説明した。まず、Amazon VPCを含むすべてのサービスで、Multi-AZデプロイメントに対応する。また、あるAZ全体がダウンしてもアプリケーションが影響を受けないようにするための、アプリケーション設計・運用のためのより使いやすいツールを提供したいという。さらに同社は、5月2日に開始する無償Webセミナーの最初のトピックに、高可用性アプリケーションの設計を含めるという。

　AWSは社内の運用ツールを強化するとともに、顧客との十分なコミュニケーションを確保できるように努力するとも説明した。具体的にはWebを通じてより頻繁に状況と見通しを示す。また、今回のような事態が発生した際に、開発者サポート・チームの役割を拡大できる体制づくりに着手したという。加えて、ユーザーが自身のリソースに障害の影響を受けているかどうかをAPIで確認できるようなツールを提供する考えという。

　AWSは、今回の障害が発生したAZでEBSボリュームあるいはRDSインスタンスを動作させていたユーザーに対し、EBSボリューム、EC2インスタンス、RDSインスタンスの利用料の100％を10日分クレジットする（請求から値引く）ことを発表した。