[8/28 最新の障害報告追加] AWS 東京リージョンで発生したシステム障害についてのまとめ

AWS東京リージョンで発生したシステム障害について、普段AWSに触れることがない人でも理解できるようにまとめてみました。アップデートがあり次第更新予定です。

• 8/25 障害の詳細についてのAWSからのメッセージを追記
• 8/28 追加の障害報告についてのAWSからのメッセージを追記

起こった事象

AWSの東京リージョンにおける単一アベイラビリティゾーン(AZ)に存在する一部のEC2、EBS、RDSにおいて接続できない問題が発生しました。また当該事象が起こったタイミングでAWSのマネジメントコンソール(管理操作画面)への接続もしづらい状況が続きました。

リージョン、アベイラビリティゾーンについて

AWSクラウドは現在22の地理的リージョンにある69のアベイラビリティゾーンで運用されています。例えば、米国東部（バージニア北部）リージョンやアジアパシフィック (シンガポール)などが存在します。そして各リージョンには、複数のアベイラビリティーゾーンが存在し、それぞれのアベイラビリティゾーンは物理的に離れた位置に存在します。つまり、アベイラビリティゾーンとはデータセンタを指し、リージョンとはそのデータセンタ群が存在する国または地域を指す と考えて問題ないと思います。

例えば東京リージョンには、ap-northeast-1a / ap-northeast-1c / ap-northeast-1d という3つのアベイラビリティゾーンが存在するため、東京近郊に3つのデータセンタが存在するということになります。(具体的な場所については公開されていない)

障害が発生したサービスについて

EC2とはAWSにおける仮想サーバのサービス でAWSにおける最もメジャーなサービスと言っていいと思います。また EBSはEC2のディスク(OSやデータの領域に主に利用される)にあたるサービス で、RDSはリレーショナルデータベースサービスです。

またEC2を利用してサーバを構築する際に、要件に応じて任意のリージョン、アベイラビリティゾーンを選択します。例えば、Webサービスにおいてユーザが日本メインの場合は、Webサービスのユーザとサーバの距離を物理的に近づけレイテンシ(遅延時間)を最小にすることを目的に東京リージョンを選択します。またアベイラビリティゾーンの選択については、可用性(システムが継続して稼働できる能力)を高めるためや負荷分散のために複数のサーバを複数のアベイラビリティゾーンで運用したりします。

つまり？

これらの前提知識から起こった事象について読み解くと、AWSクラウドが運用されている世界各地のロケーションのうち、東京における４つのデータセンタのうち１つのデータセンタに存在する仮想サーバ、ディスク、データベースが使えなくなったということです。

原因について

空調設備の管理システム障害により、EC2サーバのオーバーヒートによってパフォーマンスの劣化や電源の停止によって障害が発生した模様です。

影響を受けたサービス

AWS 東京リージョンで発生した大規模障害についてまとめてみた に本AWSの障害による影響を受けたとみられるサービスの一覧がまとまっています。複数のアベイラビリティゾーンに分散してリソースを配置することで、単一のアベイラビリティゾーンの障害の影響を少なくすることはできますが、単純に考えると障害によりサーバリソースが少なくなることで、リクエストが捌けなくなったり、コストとの兼ね合いから冗長化をしていなかったり、影響を受けたサービスの要因は様々な理由が考えれると思います。

責任の所在について

AWSには 責任共有モデル においてAWSとAWS利用者の責任分担を表明しており、今回はハードウェアが原因の障害であり普通に考えるとAWS側に責任があると考えられます。しかし今回発生した障害は単一のアベイラビリティゾーンにおけるものであり、アーキテクチャの設計やサービスの設定で回避できる問題であったと考えらえるので、AWS利用者側の責任になるのではないかと考えます。

タイムライン

Service Health Dashboard より抜粋。（Google翻訳を利用しています。)

EC2

インスタンスの接続性について

日本時間	情報
8/23 13:18	AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのいくつかのインスタンスに影響する接続の問題を調査しています。
8/23 13:47	一部のインスタンスが損なわれ、一部のEBSボリュームでAP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内のパフォーマンスが低下していることを確認できます。一部のEC2 APIでは、エラー率とレイテンシが増加しています。この問題の解決に取り組んでいます。
8/23 14:27	根本原因を特定し、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンス障害とEBSボリュームのパフォーマンス低下の回復に取り組んでいます。
8/23 15:40	AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、インスタンスの障害とEBSボリュームのパフォーマンスの低下が回復し始めています。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。
8/23 17:54	AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンスの障害やEBSボリュームのパフォーマンスの低下のために、PDTリカバリが進行中です。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。
8/23 18:39	パフォーマンスが低下したEC2インスタンスとEBSボリュームの大部分が回復しました。この問題の影響を受ける残りのEC2インスタンスとEBSボリュームの復旧に引き続き取り組みます。この問題は、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2インスタンスとEBSボリュームに影響します。
8/23 20:18	2019年8月23日 12:36 より、AP-NORTHEAST-1 の単一のアベイラビリティゾーンで、一定の割合の EC2 サーバのオーバーヒートが発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンス及び EBS ボリュームのパフォーマンスの劣化が発生しました。 このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。日本時間 15:21 に冷却装置は復旧し、室温が通常状態に戻り始めました。温度が通常状態戻ったことで、影響を受けたインスタンスの電源が回復しました。日本時間 18:30 より大部分の EC2 インスタンスと EBS ボリュームは回復しました。 我々は残りの EC2 インスタンスと EBS ボリュームの回復に取り組んでいます。少数の EC2 インスタンスと EBS ボリュームが電源が落ちたハードウェア ホスト上に残されています。我々は影響をうけた全ての EC2 インスタンスと EBS ボリュームの回復のための作業を継続しています。 早期回復の為、可能な場合残された影響を受けている EC2 インスタンスと EBS ボリュームのリプレースを推奨します。いくつかの影響をうけた EC2 インスタンスはお客様側での作業が必要になる可能性がある為、 後ほどお客様個別にお知らせすることを予定しています。

RDS

インスタンスの接続性について

日本時間	情報
8/23 14:22	AWSでは、現在、東京リージョンの1つのアベイラビリティゾーンで発生している、複数インスタンスに対する接続性の問題について調査を進めております。
8/23 15:25	AWSでは、東京リージョンの1つのアベイラビリティゾーンで発生しているインスタンスの接続性の問題について原因を特定し、現在復旧に向けて対応を進めております。
8/23 16:01	AWSでは、現在、東京リージョンの1つのアベイラビリティゾーンで発生しているインスタンスの接続性の問題ついて、復旧を開始しております。影響を受けている全てのインスタンスの復旧に向け、対応を継続いたします。
8/23 18:16	AWSでは、現在、東京リージョンの1つのアベイラビリティゾーンで接続性の問題が生じている全てのインスタンスの復旧に向け、対応を進めております。
8/23 22:19	日本時間 2019年8月23日 12:36 から 22:05 にかけて、東京リージョンの単一のアベイラビリティゾーンで一部の RDS インスタンスに接続性の問題が発生しました。現在、この問題は解消しており、サービスは正常稼働しております。

AWSより詳細の障害報告

東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 より抜粋。

2019年8月25日(日本時間)初版:

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

EC2 インスタンスと EBS ボリュームへの影響に加えて、EC2 RunInstances API にも影響が発生しました。日本時間 2019年8月23日 13:21 に、影響の発生したアベイラビリティゾーンでの EC2 インスタンスの起動、および冪等性トークン（複数のインスタンスを起動させる危険なく、インスタンスの起動をリトライする機能）を使用して RunInstance API を東京リージョンで実行した場合に、エラー率の上昇が発生しました。その他の EC2 API や冪等性トークンを使用しない EC2 インスタンスの起動は正常に動作しておりました。この問題は、冪等性トークンを使用する Auto Scaling グループからのインスタンスの新規起動も阻害しました。日本時間 14:51 に、エンジニアは、冪等性トークンと Auto Scaling グループの問題を解決しました。影響の発生したアベイラビリティゾーンでの、新しい EC2 インスタンスの起動は、EC2 コントロールプレーンサブシステムのリストアが完了した日本時間 16:05 まで継続しました。影響の発生した EBS ボリュームのスナップショットの作成も、この期間にエラー率の上昇が発生しました。

今回の事象はデータセンターで使用されるいくつかの冷却システムの制御と最適化に使用されるデータセンター制御システムの障害によって引き起こされました。制御システムは、高可用性を実現するために複数のホストで実行されます。この制御システムには、ファン、冷却装置、温度センサーなどのサードパーティ製デバイスとの通信を可能にするサードパーティ製のコードが含まれていて、直接または組み込みプログラマブルロジックコントローラ（PLC）を介して通信し、実際のデバイスと通信します。今回の事象発生の直前に、データセンター制御システムは、制御ホスト群から制御ホストの 1 つを外す処理を行なっていました。このようなフェイルオーバーの間、新しい制御ホストがデータセンターの最新状況を保持する為に、制御システムは、他の制御システムおよび制御するデータセンター機器 (データセンター全体の冷却装置および温度センサーなど) と情報を交換する必要があります。サードパーティ製の制御システムにおけるロジックのバグにより、この情報交換が制御システムとデータセンターのデバイス間で過度に発生し、最終的には制御システムが応答しなくなりました。AWS のデータセンターは、データセンターの制御システムに障害が発生した場合、制御システムの機能が回復するまで冷却システムが最大冷却モードになるよう設計されています。これはデータセンターのほとんどで正常に機能していましたが、データセンターのごく一部で冷却システムがこの安全な冷却構成に正しく移行できず停止しました。追加の安全策として、AWS のデータセンターオペレータは、通常ではデータセンター制御システムを迂回することで冷却システムを「パージ」モードにすることで故障に際しての熱風を素早く排出します。運用チームは、影響のあるデータセンターのエリアでパージをアクティブにしようとしましたが、これも失敗しました。この時点で、データセンターの影響を受けるエリアの温度が上昇し始め、サーバーが熱くなりすぎ、サーバーの電源が停止し始めました。データセンター制御システムが利用できなかったため、データセンターオペレータはデータセンターの状態と冷却システムの状態に対する可視性が最小限に限定されていました。この状況を改善されるためにはオペレータは影響を受けるすべての機器を手動で調査してリセットし、最大冷却モードにする必要がありました。これらの対応時に一部のエアハンドリングユニットを制御する PLC も応答しないことが見つかりました。これらの PLC はリセットする必要があり、またこの障害によりデフォルトの冷却モードと「パージ」モードが正常に動作していないことが確認できました。これらのコントローラがリセットされると、影響のあったデータセンターのエリアへ冷却が行われ室温が低下し始めました。

現在も、サードパーティのベンダーと協力し、制御システムと応答がなくなった PLC の両面を引き起こしたバグ、並びにバグによる影響の詳細な調査を進めております。平行して、事象の再発を防ぐため、バグを引き起こした制御システムのフェイルオーバーモードを無効にしました。また、もし万が一事象が再現しても対策が取れるよう、オペレータにこの度の事象の検知方法と復旧方法のトレーニングを実施しました。これにより、もし同様の事象が発生しても、お客様への影響が発生する前に、システムのリセットが可能になっております。その他にも、「パージ」モードが PLC を完全にバイパスできるよう、空調システムを制御する方法を変更するよう作業を進めております。これは、最新のデータセンターで使用している方法で、これにより「パージ」モードが PLC が応答がなくなった際でも機能するように出来る、より確実な方法となっています。

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

この度の事象により、ご迷惑をおかけしましたことを心よりお詫び申し上げます。AWS サービスがお客様ビジネスに極めて重要である点を理解しております。AWS は完全ではないオペレーションには決して満足することはありません。この度の事象から学ぶために出来得る全てを遂行し、AWS サービスの向上に努めてまいります。

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 では、個別の問題についての詳細な情報を、影響を受けたお客様に直接、共有を行う予定です。

AWSの障害に関する記事まとめ

今回の障害に関するブログ記事を参考になった点とともに以下にまとめます。

• AWS 東京リージョンで発生した大規模障害についてまとめてみた
  • 障害報告があったサービス一覧がとてもよくまとまっています
• AWS での AZ 障害に対する冗長化と障害対策のポイント
  • AZ名とAZIDの結びつきがAWSアカウントによって異なるなど
• AWS東京リージョン障害に思うこと
  • Multi AZでも復旧するのに時間がかかった仮説について
• AWS障害で本当に知っておくべきことと考慮すべきこと
  • 今回の障害における責任共有モデルに関する説明
• AWSの大規模障害でMultiAZでも突然ALB（ELB）が特定条件で500エラーを返しはじめたという話
  • タイトルの通りです
• AWSのAZ障害で影響を受けた・受けなかったの設計の違い。サーバレス最高！
  • AZ障害が様々なサービスの障害に繋がった原因について、サーバレスアーキテクチャで構成することで障害の影響を受けなかったことなど
• AWSのService Health Dashboardに表示される障害対応状況をSlackで受け取る方法
  • AWSにおける障害の状況をSlackの通知で受け取るための設定方法
• AWS障害(2019/08/23日本時間13時頃発生)に詫び石(返金)はあるのか？
  • SLA によると、今回の障害に関する返金等は無いとの結論です
• AWS障害発生→停止・メンテナンスをアナウンスしたサービスまとめ
  • 停止したサービスやアプリのまとめです
• AWS障害が発生した場合に確認するページやサイトまとめ
  • AWSで障害が発生した場合に確認するページやサイトについてまとまっています
• 2019/8/23のAWS東京リージョン大規模障害の経過まとめ
  • サービス復旧後も影響を受け続けているアカウントへの個別メールの内容など
• 障害から学ぶクラウドの正しい歩き方について考える
  • 稼働率 99.99% くらいを目指していくために必要な事について
• AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか
  • 自社のサービスはどれだけのダウンタイムを許容するのかという判断の重要性、カオスエンジニアリングについてなど
• AWSのAZ(アベイラビリティーゾーン)とは？AZ障害が起きたときどうすればよいのか
  • ストレージサーバの写真など、データセンタのイメージがつきやすいです