先週、AWSの障害がいくつかの大規模サイトを襲った。どうすればサービス停止を避けられるのだろうか。スケールする以外にもフェールオーバーを実現する方法はある。
AWS Service Health Dashboardによれば、米東海岸リージョンのAvailability Zone(北バージニア)で稼働するEC2、EMR、RDS、Elastic Beanstalkが6月29日午後7時25分から6月30日午後3時までダウンした。これにより、多くの企業のサービスやウェブサイトが影響を受けた。その中には、Netflix、Instagram、Pinterest、Herokuも含まれている。Amazonの報告によれば、原因は“北バージニアを襲った激しい雷雨が引き起こした”停電だと言う。この激しい雷雨が原因でアメリカ東部では停電が発生していた。また、13人が死亡し、300万人が停電の影響を受けた。
停電に加えて、大規模な電圧ノイズが2つのデータセンターを襲った。データセンターは発電機を切り替えなければならなかったが、1つの発電機が正常に動作しなかった。この動作不良が原因で、データセンターは電源を喪失した。UPSも使い尽くしてしまっていた。電源はすぐに回復したが、サービスをすべて復旧するのには時間がかかった。InmarのバイスプレジデントであるMike Kavis氏はなぜ復旧に時間がかかったのかを説明している。“Amazonの待機系の電源は起動しましたが、すべてのサービスが正常にフェイルオーバーしませんでした。”その結果、AWSが復旧するまで仮想サーバの一部がオフラインになった。このケースに対する顧客の対処法が、アプリケーションが正常に動作し続けるか、機能停止になってしまうかを決めるのだが、多くのサイトはダウンしてしまった。
このような障害を考察することはダウンタイムを防ぐ方法を考える上で重要だ。Kavis氏のブログによれば、氏の会社は2009年から5回AWSの障害に見舞われているが、サービスが落ちたことはない。複数のゾーンとリージョンを使っているからだ。
Amazonは各ゾーンで99.95%のSLAを保証しています。また、ひとつのリージョン内の複数のゾーンでダウンが発生したことはありませんし、複数のリージョンでダウンが発生したこともありません。原則として彼らはサービス提供時間を100%保証しています。複数ゾーンと複数リージョンの利点を活用した設計をするのは我々利用者の義務です。…
私たちのサーバやプラットフォームはいつか障害が起きることを想定しています。その想定の下、複数のゾーンで冗長構成にしたリソースを使ってトランザクションを処理できるよう設計しています。言い換えれば、ゾーンで障害が発生することを想定して、ひとつのゾーンに依存しないプラットフォーム設計をしているのです。
しかし、複数のゾーンを利用するだけでは不十分だとKavis氏は言う。
AWSの障害を経験することで私が気付いたのは、RDSサービスはAWSで障害が発生するときは必ずダウンするということです。….
私たちが手動でMySQLを管理していることも、AWSの障害発生時に正常にサービスを提供できる理由のひとつです。RDSに頼っていたら、障害に巻き込まれていたでしょう。では、AWSの顧客はRDSを使うべきではないのでしょうか。いいえ。私たちも極端に高いSLAを求められないサービスではRDSを利用しています。
Kavis氏によれば先週の障害の影響を受けた企業の中には、“高い拡張性を備えた環境の中で、今まで見たことがない、とても印象的で先進的なアーキテクチャを採用していた”企業もあった。しかし、彼らは動作可能時間と拡張性を交換してしまった。
SLAがない無料のソーシャルメディアサイトは数百万の同時利用ユーザに対応するために、1、2時間サービスが停止してしまうリスクを負ってでも、拡張性に積極的に投資しているのでしょう。彼らにとっては、AWSの障害のような発生頻度が低い事象に注力するよりも、押し寄せるトラフィックに対応する投資をする方がいいのかもしれません。Facebookに写真を投稿できないからといって、誰も死にませんから。
常にサイトやサービスを維持する必要があるのなら、スケールする以外の方法でフェールオーバーを設計する必要がある。Kavis氏が言うように、“理解しなければならないのは、自前のデータセンターを持っているバージニアにある多くの企業も今回の災害でサービスがダウンしたということです。今もダウンしているサービスもあります。停電は発生します。クラウドでもクラウドでなくても障害は起きます。結局、障害は避けられないのです。このような障害を想定して設計をすることでサービスが維持できるのです。”