2019年8月23日に発生したAWS東京リージョンの大規模障害について

先週の金曜日（8月23日）にAWS東京リージョンで大規模な障害がありました。まあ、皆さん話題にしていますし、数多くニュースでも取り上げられているので今更感はありますが、忘れないようにこのブログでも触れておきたいと思います。

原因についてはAWSのレポートに纏められていますので、抜粋していきたいと思います。
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要　AWS

日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発生しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。日本時間 15:21 に冷却装置は復旧し、室温が通常状態に戻り始めました。室温が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。日本時間 18:30 までに影響を受けた EC2 インスタンスと EBS ボリュームの大部分は回復しました。少数の EC2 インスタンスと EBS ボリュームは、電源の喪失と過大な熱量の影響を受けたハードウェアホスト上で動作していました。これらのインスタンスとボリュームの復旧には時間がかかり、一部につきましては基盤のハードウェアの障害によりリタイアが必要でした。 

私に近い環境（変な表現ですが）で障害に気付き出したのは13時半近くだったと記憶しているのですが、障害はその1時間前から発生していたようです。しかし、冷却システムの障害ってまあ聞かないことはないのですが、あまりデータセンタで発生しているのに遭遇したことはないんですよね。電源装置障害はありますが。。。
あくまで推測ですが、超大手のクラウド環境だと冷却システムも高度化していて、逆に障害が発生しやすいのかもしれません。普通のハウジング環境とかだと、単純に冷やしているだけですもんね。

さて、この25日に出たレポートは最後の方でこう締めくくられています。

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

これがちょっと違うんじゃない？ということで、色々なところで話題になっていました。ALBを使ってマルチAZ構成にしている環境とか、マルチAZ構成のRDSでも正常に動作しなくなり、長時間復旧できない状態が続いた環境があったからです。つまり、今回の障害はAWS推奨のマルチAZ構成でも可用性を担保できなかったのに、単一AZ障害だったからマルチAZにすれば大丈夫、というレポートはおかしくない？ということです。

それを受けてかは分かりませんが、28日にレポートが更新されます。

2019年8月28日(日本時間)更新:

最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。AWS では、個別の問題についての詳細な情報を、影響を受けたお客様に直接、共有を行う予定です。

マルチAZ構成でもダメだった環境もあるよ、ということを正式に認めるレポートに変わりました。しかし、マルチAZ構成でも影響を受けたユーザについては個別対応するといった内容になっているため、その他のユーザには詳細はAWSからは公表しないようです。取り敢えず、現時点ではですが。

とは言いつつ、これほど大きな影響が出た障害ですし、シェアを1番持っているサービスなわけですから、今後更なる障害についての情報はどこからか出てくると思います。そして、そのうちAWSから正式に今回の障害を踏まえてのサービス改修や、可用性設計に関するベストプラクティスが出てくるでしょう。それをまた、（言い方は悪いですが）信者たちが喝采するのです。
例えばマイクロソフトがAzureで同じ障害を起こすとそんな味方は出てこないと思うので、このAWS特有のユーザ文化については個人的になんとも言えない気持ちになります。が、AWSは大規模な障害が発生してもそうやって成長してきたので、これがAWSという文化圏なんだ、という理解をしています。それはまあ、それでありなんでしょうね。

なんにせよ、今回障害に遭われた方、AWSの中の方々、お疲れさまでした。
因みに私は障害当日、AWS利用のお客様ではなく、全然違うIaaSを利用されているお客様から「今回のAWS障害を踏まえてどうすれば良いですか？」という質問を頂き、回答にかなり頭を悩ませたことだけ付け加えておきます。「障害発生は完全になくすことはできないので、システムが利用できない場合のオペレーション（コンティンジェンシープラン）を事前にしっかり決めておく、ということは必ず必要ですよね。」といったニュアンスのことを、個別の事情を加味して回答しておきました。。。

関連ニュース
AWS障害、“マルチAZ”なら大丈夫だったのか？　インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」 　ITmedia　2019年08月28日
AWS障害、複数のアベイラビリティゾーン利用でも影響　AWSが説明を修正　ITmedia　2019年08月29日