Amazon EC2で大規模障害というニュースを紹介しましたが、障害の原因が判明した模様。

「Amazon EC2」の大規模障害はネットワーク障害が発端 – japan.internet.com

この障害は、米国バージニア州北部にある AWS のデータセンターで起きた。まず、ネットワークに関するエラーが発生し、これにともないクラウド ストレージ サービス「Elastic Block Store（EBS）」で大量のミラーリング処理が動き出した。その結果、Amazon EC2 を利用している仮想サーバーなどで接続に問題が起きたり、遅延が発生したりした。内部的に EBS を使うクラウド対応データベース サービス「Amazon Relational Database Service（RDS）」にも影響が出た

ネットワークに関するエラーの詳細がいまいち分かりませんが、最近は「クラウド」というキーワードが独り歩きしているようで、「クラウドを使っていれば障害は起きないし、起きたとしてもすぐに復旧する」と話していた方を思い出したが、クラウドであってもやっぱり障害は発生するんですよと。

「クラウド環境であっても、障害は発生するものだ」という前提で考えることは重要で、「障害回数をどれだけ減らせるかではなく、障害が発生したときにどれだけ早く復旧させるか」を考えて準備しておくことが重要ですね。

今回のAWSの障害は約10時間の通信断だったのですが、事前に「障害が発生したときにどれだけ早く復旧させるか」を考えて準備されていた方がいらっしゃたようで、1時間程度で復旧させたようです。

youRoomにおいて発生した 2011/4/21 のAWSの障害について技術的な観点から – mat_akiの日記

「どれだけ頑張ってもバグは発生する。0にするよりもどれだけ早く直せるかを考える」という方針です。インフラも同じく「障害は発生する。どれだけ早く復旧するか」なのです。バグを0にする・障害を0にすることは、ほぼ不可能であり実現しようとすると非常にコスト・手間がかかります。といっても、決して品質に対して手を抜くということをやる訳ではありません。過剰に品質にこだわることを捨てているのです。その保証として対応できるスピードを用意しておくのです。

対応方法を拝見すると、まさにクラウドならではのリカバリ方法だなぁと感心することしきり。
ぜひ見習いたいものですね。

追記

AWSの障害をキックに発生した、Herokuの障害レポートを和訳された方がいらっしゃいました。
クラウドの運用手法の向上に、大変参考になりますので、リンクを張っておきます。

AWSの障害に起因したHerokuの障害について、Heorkuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、… – Sooey

運用ノウハウとして勉強になるのはもちろん、非常に簡潔な障害レポートの書き方ですねぁ。
そっちも参考になります。

追記

詳細な原因がAWSから発表されたようです。

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

これによると、障害のきっかけはネットワークの構成変更作業におけるミスだった。同社は今回の障害が複数のAvailability Zone（AZ）に影響を与えた理由も説明した。

オチは人為的なミスだったようですね。

メインネットワークに接続するルータが2台の冗長接続構成となっており、この2台に流れていたトラフィックを1台に集約しようとしたところ、予備ネットワークに接続してしまったということのようです。

オペレータがすぐに異変に気づいて、ネットワークの回復を行ったようですが、多数のEBSノードが同時に空きスペースを探してレプリカを作成しようと試み、空きスペースが急速に枯渇しサービス不能に陥ったようです。

この記事を読むと、かなりの部分で自動化されていたことも原因の1つのように感じました。
それぞれのシステムが自動的に最適化を実施したことで、システム全体でサービス不能に陥ってしまったようです。
自動化はOPEX低減には必須ですが、全体最適を考慮しながら個別最適を施すことが重要だと感じました。

[24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 安井 真伸,横川 和哉,ひろせ まさあき,伊藤 直也,田中 慎司,勝見 祐己 技術評論社 売り上げランキング : 5200 Amazonで詳しく見る