AWS東京リージョンの障害を回避するインフラ構成とは？

WS東京リージョンの大規模障害で多数のサービスに影響がでました。
今回の障害はなぜ起きたのか？そして回避策はなかったのか？
AWSからも公式メッセージがでたので、検証してみます。

今回の障害は東京リージョンの1つのゾーンで発生した障害です。
これはインフラ構成によっては回避できる事案です。

では、どの様にすればサービス停止を回避できたのでしょうか？
以下詳細に検証していきます。

目次

1. AWS東京リージョンの障害の原因と影響
2. EC2をマルチAZとマルチリージョンにする
3. DBはAuroraを使う
4. 責任の所在について

1. AWS東京リージョンの障害の原因と影響

今回の東京リージョンの障害の原因は冷却システムの不具合でした。
冷却システムが動かなくなり、サーバーがオーバーヒートしてしまいました。

その影響で、EC2(サーバー機能)とRDS(データベース)が使えなくなりました。

東京リージョンの1つのゾーンで広範囲のサーバーに影響範囲が広がり、
多数のサービス、アプリ、ゲームに影響がでて一時サービス停止を余儀なくされました。

2. EC2をマルチAZとマルチリージョンにする

ではどのような構成にすれば、今回の障害が起きても、
サービス停止を回避できたのでしょうか？

AWSのデータセンターにはリージョンとゾーンという概念があります。
リージョンは東京、大阪、オレゴン、台湾などのエリア別、国別の場所。
ゾーンは東京リージョンの範囲内の独立した別の場所の事です。

東京リージョンには複数のゾーンが存在します。

今回は東京リージョンの1つのゾーンで起きた障害なので、
複数箇所のゾーンにEC2をおいて、分散しておけば良かったのです。

しかしそれだけではなく、マルチリージョンといって、
大阪リージョンにもEC2を分散しておくとより安全でした。

3．DBはAuroraを使う

東京リージョンのRDSの障害を回避するにはどうすれば良かったのでしょうか？

ゲームや、Webサービスで一番大切なデータはユーザーのデータです。
なぜなら、課金して買ったダイヤやレベル、ユーザの投稿内容、フォロアー情報
などが消えたり、不整合を起こして使えなくなってはいけないのです。

それに、なるべくEC2と地理的に近いゾーンに置いて、
すこしでもアクセス速度を速くする必要があります。

なので殆どの国内向けゲームとWebサービスのRDSが、
東京リージョンに集中していました。

今回の障害でも回避を難しくしたのはこのRDSの障害だったでしょう。
AWSのRDSのドキュメントにはこのように記載されています。

AWS リージョン間でのリソースのレプリケーションは自動的に実行されないため、ユーザーが特に指定して行う必要があります。
Amazon は、アベイラビリティーの高い最新のデータセンターを運用しています。しかし、非常にまれですが、同じ場所にあるインスタンスすべての可用性に影響する障害が発生することもあります。もし、すべてのインスタンスを 1 か所でホストしている場合、そのような障害が起きたとき、インスタンスがすべて利用できなくなります。

まさに今回の障害がその非常にまれなパターンに当てはまるでしょう。

ではどの様に回避すれば良かったのか？

結論はAurora(高性能のセキュリティ、可用性、信頼性があるデータベース)を
最初から選択すべきでした。

可用性というのは、複数箇所に分散していて、障害に強い性能の事です。

結果論ですが、東京リージョンのRDSを使っている時点で、
今回の障害は回避不可能でした。

なぜならデータベースはEC2のように複数リージョンに分散して、
データの整合性と速度を保つのは非常に難しく、通常そんな事はしません。

じゃあ、高可用性 (マルチAZ)で複数ゾーンにまたいで
設置するれば良いという意見もありますよね？

しかし今回の障害では、マルチAZでもレプリケーションに失敗した報告がありました。

なので、完全に回避するにはAuroraの高可用性マネージドサービスDBを使えば良かったのです。

4. 責任の所在について

AWSでは「責任共有モデル」といって、AWSと利用者の責任を共有して分担するモデルがあります
今回の障害はハード側でサーバーのオーバーヒートというAWS側の果たすべき責任です。
しかしながら、東京リージョンの一部のゾーンの障害です。
利用者側の責任でマルチゾーンなどの構成を組む事で、回避できた障害でもあります。

[東京リージョン(AP-NORTHEAST-1)で発生したAmazon EC2とAmazonEBSの事象概要]（https://aws.amazon.com/jp/message/56489/）

この度の事象発生時、異なるアベイラビリティゾーンの EC2 インスタンスや EBS ボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨します（お客様にとって高可用性に課題を生じ得る全てのアプリケーションのコンポーネントは、この耐障害性を実現する方法の下で稼働させることを強く推奨します）。

AWS側のアナウンスでも、最大限の可用性を考慮してインフラ構成を組んでねって言ってます。

Amazonの利用規約でもサービスレベルアグリーメント（SLA)を設定しています。

EC2ではマルチAZ構成で99.99％ です。
0.01%は落ちるかもしれないけど、
ゆるしてねってAmazonは規約で決めています。

月で計算すると、24時間 × 30日 × 0.01% = 4.32分です。

RDSのSLAはマルチAZで99.95％でした。
月で計算すると、24時間 × 30日 × 0.05% = 3.6時間です。

RDSはマルチAZでも使えなかったとしても
復旧まで9.5時間でしたので、これもSLAの範囲超えてるかも？？

保証対象になった企業いたのかな？

オーバーヒートと一部基盤破棄する規模の物理障害を
9.5時間で完全復旧させてしまうのは、かなり手早い復旧でしたね。

まとめ

今回の東京リージョンの大規模障害は本当にレアケースで、
多大な影響範囲でしたよね。

対応したインフラエンジニアの方々はかなり焦ったのではないでしょうか？

今回学んだのはAWSでも落ちるときは落ちるんですね。
なのでマルチAZ、マルチリージョンで冗長構成にしましょうって事ですね。

そしてDBはAurora一択ですね。
Auroraと同じような冗長構成を自分で組むとコストが５倍かかります。
それとそもそも難しすぎて、同じ冗長構成を普通は組めません。
おとなしくAuroraに課金して安心、安全をお金で買いましょう。

以上、AWS東京リージョンの障害についてでした。