AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず

2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは日本語での詳しい報告を公開しました。

報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。これにより、緊急時の手動操作にも冷却制御システムの一部が反応しないなどでサーバが過熱し、障害に至ったと説明されています。

8月23日午後に約6時間の障害。EC2だけでなくRDSも

報告によると、障害は日本時間2019年8月23日金曜日の昼過ぎに発生。影響範囲は仮想マシンを提供するAmazon EC2とブロックストレージを提供するAmazon EBSのそれぞれ一部。以下、AWSの報告を引用します。

日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発生しました。

障害の原因は冷却制御システムのバグによってサーバがオーバーヒートしたため。その冷却制御システムは、障害発生から約3時間後の15時21分に復旧します。

冷却制御システムの復旧によってデータセンターの室温が低下し、影響を受けたEC2インスタンスとEBSボリュームの大部分が回復したのは、障害発生から6時間後の18時半頃。一部についてはさらに復旧に時間がかかっています。

日本時間 18:30 までに影響を受けた EC2 インスタンスと EBS ボリュームの大部分は回復しました。少数の EC2 インスタンスと EBS ボリュームは、電源の喪失と過大な熱量の影響を受けたハードウェアホスト上で動作していました。これらのインスタンスとボリュームの復旧には時間がかかり、一部につきましては基盤のハードウェアの障害によりリタイアが必要でした。

マネージドサービスのAmazon RDSも同時に障害

また、今回公開された報告には含まれていませんが、この障害はAmazon RDSにも影響していました。Amazon RDSでは障害発生のタイミングはほぼ同時ながら、解消まで約10時間かかっています。

下記情報は記事執筆時点でAWSヘルスダッシュボードのRSSの中に残っていますが、いずれ消えてしまうはずです。

日本時間 2019年8月23日 12:36 から 22:05 にかけて、東京リージョンの単一のアベイラビリティゾーンで一部の RDS インスタンスに接続性の問題が発生しました。現在、この問題は解消しており、サービスは正常稼働しております。詳細はこちらをご覧ください。

この障害の詳細情報へのリンク先も今回の大規模障害の報告ページになっています。

つまり8月23日金曜日の午後の大規模障害の範囲はAmazon EC2、EBSだけでなく、少なくともAWSがマネージドサービスで提供しているAmazon RDSにも広がっていたことになります。ただし障害の範囲は1つのアベイラビリティゾーン内だったとされています。

（ほかにもこの障害との関係は未確認ながら、同時間帯にAWSのマネージメントコンソールが利用できなくなった、Amazon ELBでエラーが発生した、といった利用者の声もあがっています）。

単一のアベイラビリティゾーン内だけで発生した障害だったと報告

AWSからの報告では、今回の障害は単一のアベイラビリティゾーン内で起きたことであり、他のアベイラビリティゾーンには影響していないとのこと。

この度の事象発生時、異なるアベイラビリティゾーンの EC2 インスタンスや EBS ボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。

そのためマルチアベイラビリティゾーン構成にしておくことで可用性を保つことができたと説明されています。

アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨します（お客様にとって高可用性に課題を生じ得る全てのアプリケーションのコンポーネントは、この耐障害性を実現する方法の下で稼働させることを強く推奨します）。

制御システムのバグでフェイルセール失敗、手動操作も失敗

障害を引き起こしたサーバのオーバーヒートの原因となったのは、データセンターの冷却制御システにバグがあったためだと説明されています。

制御システムには、ファン、冷却装置、温度センサーなどのサードパーティ製デバイスとの通信を可能にするサードパーティ製のコードが含まれていて、直接または組み込みプログラマブルロジックコントローラ（PLC）を介して通信し、実際のデバイスと通信します。

今回の障害の直前に、データセンター制御システムの一部に変更が行われました。そしてデータセンター内の複数の制御システムのあいだで、あらためて相互に情報交換が行われるはずでした。

しかしそこにバグがあり、制御システムが落ちます。

サードパーティ製の制御システムにおけるロジックのバグにより、この情報交換が制御システムとデータセンターのデバイス間で過度に発生し、最終的には制御システムが応答しなくなりました。

このときフェイルセーフ機能が発動して最大冷却モードに入るはずが、ごく一部でこれに失敗します。

AWS のデータセンターは、データセンターの制御システムに障害が発生した場合、制御システムの機能が回復するまで冷却システムが最大冷却モードになるよう設計されています。これはデータセンターのほとんどで正常に機能していましたが、データセンターのごく一部で冷却システムがこの安全な冷却構成に正しく移行できず停止しました。

そこでオペレータが冷却システムのモードを変更し、パージモード（解放モード）にするも、これにも失敗します。

追加の安全策として、AWS のデータセンターオペレータは、通常ではデータセンター制御システムを迂回することで冷却システムを「パージ」モードにすることで故障に際しての熱風を素早く排出します。運用チームは、影響のあるデータセンターのエリアでパージをアクティブにしようとしましたが、これも失敗しました。

ここに至り、オーバーヒートによるサーバの停止が発生しはじめます。

そこでオペレータは手動で機器を操作して最大冷却モードにしようとしますが、これにも一部で失敗。

この状況を改善されるためにはオペレータは影響を受けるすべての機器を手動で調査してリセットし、最大冷却モードにする必要がありました。これらの対応時に一部のエアハンドリングユニットを制御する PLC も応答しないことが見つかりました。

失敗の原因であるプログラマブルロジックコントローラをリセットすることで、ようやく冷却に成功。データセンターの室温が低下しはじめました。

これらの PLC はリセットする必要があり、またこの障害によりデフォルトの冷却モードと「パージ」モードが正常に動作していないことが確認できました。これらのコントローラがリセットされると、影響のあったデータセンターのエリアへ冷却が行われ室温が低下し始めました。

原因のバグについて調査中。オペレータは対応訓練を済ませる

AWSはサードパーティと協力して制御システムやPLCのバグなどについて調査を進めているとのこと。

また今回のようなバグが再び起きたとしても、速やかに対応できるようにオペレータをトレーニング。

万が一事象が再現しても対策が取れるよう、オペレータにこの度の事象の検知方法と復旧方法のトレーニングを実施しました。これにより、もし同様の事象が発生しても、お客様への影響が発生する前に、システムのリセットが可能になっております。

さらに、操作に失敗したパージモードを改良すると。

その他にも、「パージ」モードが PLC を完全にバイパスできるよう、空調システムを制御する方法を変更するよう作業を進めております。これは、最新のデータセンターで使用している方法で、これにより「パージ」モードが PLC が応答がなくなった際でも機能するように出来る、より確実な方法となっています。

冷却システムが原因での大規模な障害は、2017年4月にMicrosoft Azure東日本リージョンでも発生しています。

• Azureの東日本リージョンが7時間にわたってダウン。原因はデータセンターの冷房が失われ自動シャットダウン。日本のリージョンはこの1カ月で三回目の障害

また、今回のAWSの障害は東京リージョンにおけるはじめての大規模障害といえるでしょう。

オンプレミスであってもクラウドであっても何らかの障害から逃れることはできません。今回のAWSの大規模障害は東京リージョンで発生したこともあり、国内のクラウド利用者にとって、障害が発生する前提でシステムをどう構築するのか、あるいは障害をどこまで許容する設計や運用にするのか、ということをあらためて考えさせる機会になったのではないでしょうか。