クリスマスのAWS障害で学んだ事：Netflixの受けた影響をそれを防止する方法 (RightScaleの宣伝でもあります）

by Brian Adler @ RightScale

クリスマスイブ、さらに翌日のクリスマス当日にかけて、AWSはUS東海岸地域でのELB(Elastic Load Balancing)サービスの一時的な中断が事象として起きました。ELBオペレーションのほんの一部が影響を受けただけに留まっていたが、この地域全体でELBがらみの操作に遅れが生じる、等の影響が出ていた事が報告されている。AWS本体がこの障害に関して出した報告はここにあります。

この報告によると、AWSのユーザのかなりの数が影響を受けた事が示唆されます。実際には、各ユーザの受けた影響はELBの利用依存度によってまちまちであった様です。影響を受けた会社の中で、Netflix社が含まれていたようで、彼らの事後報告、さらにこの障害に関する所見がここで記載されています。

クラウドプラットホームベンダー固有のソリューションに頼るな

毎度の事であるが、この障害に関する業界内での議論において、マルチリージョン（複数のリージョンでシステムを分散/多重化させる）ソリューションを採用する事の重要性が、Netflixを含めた、ベンダー間で議論されている。RightScaleでは、こういった障害対応のためにマルチリージョンでシステム構築を行う事を推奨してますが、現実的にマルチリージョン対応するのはコストや管理工数面で難しい、という現実も理解してます。以前にこの課題に対してWhite Paperを書いており、是非その内容を参考ににしてもらいたい。リンクはここ。

RightScaleの顧客の多くは単一のリージョンで稼働しており、ベンダー特定のツールを使う事を避けるようにアドバイスするように心がけています。よく見えない、ベンダーへの依存状態が発生しないようにするためです。

ところで、今回起きたAWS障害はUS東海岸全体に影響を及ぼしたが、結果的にはELBという単一のサービスで起きた問題に過ぎないのです。もしウェブサイトが別のロードバランシング技術（HAProxy、Nginx、等）を使用していたら、今回の障害では全く影響を受けなかったはずです。このような対策手法は別のブログ記事で説明してます。

http://saas-technology.blogspot.com/2012/12/cloud-2013-rightscale.html

特に、項目＃９の、"クラウドロックインに注意”という項目がポイントです。

ベンダー特定の運用ツールやアプライアンスは、一時的にアプリケーションの運用効率を向上する事が可能になりますが、同じベンダーの提供する他のツールとの連携も強いケースが多いために、障害発生時にも想定以上の問題が発生する可能性が高くなります。クラウドベンダーに依存しないツールを利用する事により、特定のクラウドプラットホームに縛られない、クラウド依存度の無いアプリケーション運用が可能になり、結果的に障害対応に強いシステム運用が可能になるはずです。マルチクラウドもメリットは特定のクラウドの障害に対応するソリューションになるだけではなく、コストの最適化にも寄与します（より安いクラウドへの移行が可能になります）。

ELBというのは、正にベンダー固有のツールそのものです。もちろん、システムのセットアップ時にELBの存在は非常に便利ですが、問題はこのツールが他のクラウドから利用出来ない、という制限のみならず、障害が起きた時にシステム全体にその影響が及ぶ、という事であります。今回の障害は、ELBに対するマニュアル操作が原因による障害、という事で報告されているが、ELB運用全体のかなり局所化された部分での障害であったにも関わらず、ELB運用全体に影響を及ぼした、という事がやはり問題なのです。

疎結合によるコンポーネント構成の良さ

我々がクラウドアーキテクチャを提唱する時の強調するのは、クラウドシステム構成を疎結合されたコンポーネントで構成する事です。今回のAWSのELBでの障害は、独立した単独サービスコンポーネントが起こした問題のように見えるが、実際にはELBはAWSのインフラと深く関係を持ったものであり、ここでの障害は、他のコンポーネントにも影響を与える可能性は非常に高い、と評価しています。Netflix社は、クラウド自動化に関して非常に多岐に渡る工夫をしており、特にオープンソフトウェアの利用に関してはAsgard等、画期的なものもある。しかしながら、AWS固有のコンポーネントの利用に関しては以前から疑問を持ってはいました。

今回の障害の根本的な原因を分析するにあたり、GigaOmは非常に興味深い分析を行っており、また、Netflix社のこの障害に対する対応についても詳しく記述している。注目すべきは、問題は元々自動化されていた操作をエンジニアがマニュアル操作をしたために起きた、という事に起因しており、これはRightScaleでも強く提唱している、管理操作の徹底的な自動化の推奨にも同期する要件であります。

どんな自動化プロセスも、その立ち上げ時に人為的な操作によってスタートさせられる訳であるが、この操作も、アクセス権管理、ログ記録/監査、の機能によって管理されるべきであります。マニュアル操作は、（基本的に不完全である）人間が行う以上、必ずエラーが伴うものであり、自動化されたシステムによる修正、トラブル防止の機能に依存する事が重要です。

高可用性、耐久性の高いシステムがゴールであるべき

今回のAWS障害は、クラウドの”ベストプラクティス”、がどうあるべきか、という事を改めて認識するよい機会である、と考えるようにしている。システムの運用設計を行う際に、様々なショートカットが講じられるが、最初は小さく、局所化された障害であると思われる事が、その機能に依存する他のサービスコンポーネントに順次影響を及ぼし、最終的に大きな障害につながる、という事が見えた事例である、と言える。

システムの可用性、耐久性を確保、強化出来るコンポーネントは市場に数多く存在します。それらをどのように組み合わせるか、という事に関しては、様々な事例、そして実際に組み合わせる実証試験を行う事によって最善の選択を行う事が出来る、と考えます。特に、クラウドプラットホームと独立した、アクセス管理ツール、ログ管理ツール、システム監査ツール、等はRightScaleでサーバテンプレートとして数多く準備しており、様々な組み合わせを非常に安く、簡単に行う事ができる事が可能です。

特に、RightScaleのフリーエディション（無償版）を利用する事によって、コストをかけずにクラウドアーキテクチャの設計を行う事が出来ますので是非利用してみてください。