2021/2/20に発生したAWS障害と自社での対応

4 min read読了の目安(約4200字

これなに

2020/2/20深夜に発生したAWS障害で自社で開発しているサービスにも少しだけ影響があったので調べてみた

そもそもの原因

以下は AWS Service Health Dashboardからの抜粋です
※英訳、日本語訳両方あると見づらかったので英訳については省いています。

[RESOLVED] インスタンスの障害について
7:09 AM PST (12:09AM JST)現在、東京リージョン AP-NORTHEAST-1 のひとつのアベイラビリティゾーン apne1-az1 において、インスタンスに影響を及ぼす接続性の問題が発生しており、対応を行っております。
7:58 AM PST (12:58AM JST)現在、東京リージョン AP-NORTHEAST-1 における一つのアベイラビリティゾーン(apne1-az1)の一部で、周囲の温度が上昇している状況を確認いたしました。影響を受けているアベイラビリティーゾーンの一部 EC2 インスタンスでは、接続性の問題または温度上昇の影響に伴い、電源が切れている問題が発生しております。当該問題の影響により、一部 EBS ボリュームにてパフォーマンスが低下しております。本問題の根本原因を特定し、現在解決に向けて対応しております。東京リージョン AP-NORTHEAST-1 におけるその他アベイラビリティゾーンは、この問題の影響を受けておりません。
8:40 AM PST (1:40AM JST)AP-NORTHEAST-1 リージョンのうちの 1 つのアベイラビリティーゾーン (apne1-az1) のある一部の区画での温度上昇に対処するために引き続き取り組んでいます。温度の上昇は、当該セクション内の冷却システムへの電力の損失によって発生しました。引き続き、電源の回復に取り組んでおりこれまでに冷却システムの 1つを正常に復旧させました。引き続き温度を通常レベルに復元し、影響を受けた EC2 インスタンスと EBS ボリュームの回復に取り組んでまいります。EC2 および EBS API を含むその他のシステムは、影響を受けたアベイラビリティーゾーン内で正常に動作しています。影響のあった EC2 インスタンスおよび EBS ボリュームをお持ちのお客様は、影響を受けたアベイラビリティーゾーン、または AP-NORTHEAST-1 リージョン内のその別のアベイラビリティーゾーンで再起動を試みることができます。
9:43 AM PST (2:43AM JST)AP-NORTHEAST-1 リージョンのうちの 1 つのアベイラビリティーゾーン (apne1-az1) のある一部の区画での温度上昇に対処するために引き続き取り組んでいます。温度の上昇は当該セクション内の冷却装置への電力損失によって発生しました。当該セクション内のいくつかの冷却ユニットの電力はすでに復元しており、温度が低下し始めていることを確認しております。残りのオフラインの冷却ユニットは引き続き作業を続け、温度を通常レベルに戻します。温度が回復次第、影響を受ける EC2 インスタンスと EBS ボリュームが回復します。EC2 および EBS API を含むその他のシステムは、影響を受けるアベイラビリティーゾーン内で正常に動作しています。影響を受けた EC2 インスタンスおよび EBS ボリュームをお持ちのお客様は、影響を受けたアベイラビリティーゾーン、または AP-NORTHEAST-1 リージョン内の別のアベイラビリティーゾーンでインスタンスの再作成を試みることができます。
10:42 AM PST (3:42AM JST)AP-NORTHEAST-1 リージョンのうちの 1 つのアベイラビリティーゾーン (apne1-az1) のある一部の区画で影響を受けていた冷却ユニットの多くの電源が回復しました。室温は通常のレベルに近い状況まで戻り、ネットワーク、EC2 および EBS ボリュームの回復処理を開始しています。ネットワークはすでに回復し、EC2とEBSボリューム の回復処理に着手しております。回復処理が始まると再起動が発生するため、お客様にはお使いのインスタンスでアクションをとっていただく場合がございます。EBSボリュームに関しましては、ボリュームが回復するにつれ、degraded I/Oパフォーマンスが通常に戻ります。 ”stopping” もしくは ”shutting-down” のまま止まってしまっているインスタンスに関しましては、回復処理が進むにつれ、 ”stopped” もしくは “terminated” に戻ります。
11:26 AM PST (4:26AM JST) AP-NORTHEAST-1 リージョンのうちの 1 つのアベイラビリティーゾーン (apne1-az1) で影響を受けていた冷却サブシステムの電源が回復しました。現在、室温は通常レベルで運用されています。大部分の ES2 インスタンスと EBS ボリュームが復旧しておりますが、残りのインスタンスとボリュームの復旧作業に引き続き取り組んでいます。
12:09 PM PST (5:09AM JST)アベイラビリティゾーン (apne1-az1) で影響を受けた一部の区画の室温は安定し、通常のレベルに戻りました。多くの EC2インスタンスは回復済みとなっております。多くの EBSボリュームも回復済みですが、残りの少数のボリュームの復旧作業に引き続き取り組んでおります。
12:54 PM PST (5:54AM JST)日本時間 02/19 11:01 PM から、AP-NORTHEAST-1 リージョンのうちの1つのアベイラビリティーゾーンの一部の区画で室温の上昇を確認いたしました。日本時間 02/19 11:03 PM から、室温が上昇した結果として、一部の EC2インスタンスが影響を受け、一部のEBSボリュームではパフォーマンスが低下しました。根本的な原因は、影響を受けたアベイラビリティーゾーンのセクション内の冷却システムへの電力の喪失であり、すでに回復済みです。日本時間 02/20 03:30 AM までに、電力は冷却システム内のほとんどのユニットで復旧し、室温は通常のレベルに戻りました。日本時間 02/20 04:00 AM までに、EC2 インスタンスと EBS ボリュームの回復が始まり、日本時間 02/20 05:30 AM 時点で、影響を受けた EC2 インスタンスと EBS ボリュームの大部分は通常通り動作しております。一部のインスタンスとボリュームは、イベントによって影響を受けたハードウェア上でホストされていました。引き続き影響を受けたすべてのインスタンスとボリュームの復旧に取り組み、Personal Health Dashboard を通じて、現在も影響を受けているお客様に対し通知を行います。即時の復旧が必要な場合は、影響を受けているインスタンスまたはボリュームを置き換えていただくことをお勧めします。

すごく雑にまとめると以下のような感じみたいです
1.apne1-az1の一部の区画で冷却システムへの電力の損失が発生
2.そのため温度上昇の影響に伴い、EC2インスタンスとEBSボリュームのパフォーマンスが低下

自社ではこんな対応でした

2021/2/19の23時14分にアラートが上がり携帯電話に電話が掛かってくる。
アラート内容を確認すると自社サービスの3台のアプリケーションサーバのうち1台がヘルスチェックで失敗したとの内容。
実際にサービスにアクセスしに行くとhtmlは表示されるがcssが全くあたっていない状態だったり500エラーだったりと不安定。
EC2の状態を確認しにいくとCPU使用率が異常に高い状態だったので、プロセスの状況を確認しようとsshで接続しようにもタイムアウトでログインできない状態なのでEC2を停止。
が、停止中のままステータスが変更されなかったのでロードバランサのターゲットグループから該当のインスタンスを外し行こうか迷っていたところ、DataDog側で該当のインスタンスがdownしたという通知が来たのでサービスを確認しにいくと安定してサービスが表示されるようになっていた。
あとは、落としたEC2を起動させてサービスを立ち上げて終わりと思っていたが相変わらずEC2の状況は停止中のまま、おかしいなと思いAWS Statusを確認しにいくもオールグリーンで問題なし。
一応Twitterを確認しとおくかと検索したところ複数のサービスがエラーになっていると阿鼻叫喚のツイートだらけ。
しばらく様子見をしていたところAWS Statusで障害に変わっており、該当のインスタンスの詳細にもEBSボリュームに影響がある旨のメッセージが表示されるようになっていたので後はAWS側で障害回復するのをまってEC2のインスタンスの起動とサービスを立ち上げて作業完了となりました。

Twitterやら他の方が書かれた記事を見ていると、EC2が不安定ながらも稼働していた事で対応や発見が遅れてしまったみたいです。
他にもマルチAZで組んでし自動で切り替える設定もしていたけど駄目だったという内容もあって、自社のEC2は上手く落とせた事でそれ以上の作業が発生せずに対応が出来て運がよかったなという感じです。

まとめ

冷却システム関連の障害は2019年8月23日にも似たような障害が発生しており、おそらく今後も発生しうる問題だと思います。
また今回のように不安定ながらも稼働しつづけるような場合だと予め設定したおいた内容も上手く動作しない可能性もありえるので復旧手順をきちんと確立しておきたいです。
AWSの障害とは関係ないですが、先日自社サービスのリリース時にDBのロックとテーブル定義の更新待ちになり一時サービスが利用できない状況なってしまったので、障害全般を素早く復旧できる手順、仕組み、体制をつくるフェーズになってきたんだとなと思っています。
いつでも利用できるサービスづくりを頑張っていきたいです。