この記事は新野淳一氏のブログ「Publickey」に掲載された「AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず」(2019年8月26日掲載)を、ITmediaNEWS編集部で一部編集し、転載したものです。
2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは日本語での詳しい報告を公開しました。
報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。これにより、緊急時の手動操作にも冷却制御システムの一部が反応しないなどでサーバが過熱し、障害に至ったと説明されています。
報告によると、障害は日本時間2019年8月23日金曜日の昼過ぎに発生。影響範囲は仮想マシンを提供するAmazonEC2とブロックストレージを提供するAmazonEBSのそれぞれ一部。以下、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ボリュームは、電源の喪失と過大な熱量の影響を受けたハードウェアホスト上で動作していました。これらのインスタンスとボリュームの復旧には時間がかかり、一部につきましては基盤のハードウェアの障害によりリタイアが必要でした。
また、今回公開された報告には含まれていませんが、この障害はAmazonRDSにも影響していました。AmazonRDSでは障害発生のタイミングはほぼ同時ながら、解消まで約10時間かかっています。
下記情報は記事執筆時点でAWSヘルスダッシュボードのRSSの中に残っていますが、いずれ消えてしまうはずです。
日本時間2019年8月23日12:36から22:05にかけて、東京リージョンの単一のアベイラビリティゾーンで一部のRDSインスタンスに接続性の問題が発生しました。現在、この問題は解消しており、サービスは正常稼働しております。詳細はこちらをご覧ください。
この障害の詳細情報へのリンク先も今回の大規模障害の報告ページになっています。
つまり8月23日金曜日の午後の大規模障害の範囲はAmazonEC2、EBSだけでなく、少なくともAWSがマネージドサービスで提供しているAmazonRDSにも広がっていたことになります。ただし障害の範囲は1つのアベイラビリティゾーン内だったとされています。
(ほかにもこの障害との関係は未確認ながら、同時間帯にAWSのマネジメントコンソールが利用できなくなった、AmazonELBでエラーが発生した、といった利用者の声もあがっています)。
AWSからの報告では、今回の障害は単一のアベイラビリティゾーン内で起きたことであり、他のアベイラビリティゾーンには影響していないとのこと。
この度の事象発生時、異なるアベイラビリティゾーンのEC2インスタンスやEBSボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客さまは、事象発生中も可用性を確保できている状況でした。
そのためマルチアベイラビリティゾーン構成にしておくことで可用性を保つことができたと説明されています。
アプリケーションで最大の可用性を必要とされるお客さまには、この複数アベイラビリティゾーンのアーキテクチャにのっとってアプリケーションを稼働させることを引き続き推奨します(お客さまにとって高可用性に課題を生じ得る全てのアプリケーションのコンポーネントは、この耐障害性を実現する方法の下で稼働させることを強く推奨します)。
障害を引き起こしたサーバのオーバーヒートの原因となったのは、データセンターの冷却制御システムにバグがあったためだと説明されています。
制御システムには、ファン、冷却装置、温度センサーなどのサードパーティー製デバイスとの通信を可能にするサードパーティー製のコードが含まれていて、直接または組み込みプログラマブルロジックコントローラーー(PLC)を介して通信し、実際のデバイスと通信します。
今回の障害の直前に、データセンター制御システムの一部に変更が行われました。そしてデータセンター内の複数の制御システムのあいだで、あらためて相互に情報交換が行われるはずでした。
しかしそこにバグがあり、制御システムが落ちます。
サードパーティー製の制御システムにおけるロジックのバグにより、この情報交換が制御システムとデータセンターのデバイス間で過度に発生し、最終的には制御システムが応答しなくなりました。
このときフェイルセーフ機能が発動して最大冷却モードに入るはずが、ごく一部でこれに失敗します。
AWSのデータセンターは、データセンターの制御システムに障害が発生した場合、制御システムの機能が回復するまで冷却システムが最大冷却モードになるよう設計されています。これはデータセンターのほとんどで正常に機能していましたが、データセンターのごく一部で冷却システムがこの安全な冷却構成に正しく移行できず停止しました。
そこでオペレーターが冷却システムのモードを変更し、パージモード(解放モード)にするも、これにも失敗します。
追加の安全策として、AWSのデータセンターオペレーターは、通常ではデータセンター制御システムを迂回することで冷却システムを「パージ」モードにすることで故障に際しての熱風を素早く排出します。運用チームは、影響のあるデータセンターのエリアでパージをアクティブにしようとしましたが、これも失敗しました。
ここに至り、オーバーヒートによるサーバの停止が発生しはじめます。
そこでオペレーターは手動で機器を操作して最大冷却モードにしようとしますが、これにも一部で失敗。
この状況を改善されるためにはオペレーターは影響を受ける全ての機器を手動で調査してリセットし、最大冷却モードにする必要がありました。これらの対応時に一部のエアハンドリングユニットを制御するPLCも応答しないことが見つかりました。
失敗の原因であるプログラマブルロジックコントローラーをリセットすることで、ようやく冷却に成功。データセンターの室温が低下しはじめました。
これらのPLCはリセットする必要があり、またこの障害によりデフォルトの冷却モードと「パージ」モードが正常に動作していないことが確認できました。これらのコントローラーがリセットされると、影響のあったデータセンターのエリアへ冷却が行われ室温が低下し始めました。
AWSはサードパーティーと協力して制御システムやPLCのバグなどについて調査を進めているとのこと。
また今回のようなバグが再び起きたとしても、速やかに対応できるようにオペレーターをトレーニング。
万が一事象が再現しても対策が取れるよう、オペレーターにこの度の事象の検知方法と復旧方法のトレーニングを実施しました。これにより、もし同様の事象が発生しても、お客さまへの影響が発生する前に、システムのリセットが可能になっております。
さらに、操作に失敗したパージモードを改良すると。
その他にも、「パージ」モードがPLCを完全にバイパスできるよう、空調システムを制御する方法を変更するよう作業を進めております。これは、最新のデータセンターで使用している方法で、これにより「パージ」モードがPLCが応答がなくなった際でも機能するようにできる、より確実な方法となっています。
冷却システムが原因での大規模な障害は、2017年4月にMicrosoftAzure東日本リージョンでも発生しています。
(関連記事:Azureの東日本リージョンが7時間にわたってダウン。原因はデータセンターの冷房が失われ自動シャットダウン。日本のリージョンはこの1カ月で三回目の障害)
また、今回のAWSの障害は東京リージョンにおけるはじめての大規模障害といえるでしょう。
オンプレミスであってもクラウドであっても何らかの障害から逃れることはできません。今回のAWSの大規模障害は東京リージョンで発生したこともあり、国内のクラウド利用者にとって、障害が発生する前提でシステムをどう構築するのか、あるいは障害をどこまで許容する設計や運用にするのか、ということをあらためて考えさせる機会になったのではないでしょうか。
Copyright © ITmedia, Inc. All Rights Reserved.
Special
PR