AWS東京リージョンのAZ(apne1-az1)障害時の当ブログで発生していたことの記録

2021/02/20 2021/02/23

日本時間2/19 23:01頃より、東京リージョン、特定AZの1つでEC2インスタンスへの接続性とEBSボリュームのパフォーマンス低下が、冷却システム障害の温度上昇により発生していたそうです。
私、酔って寝ておりました。

以下の記録はすべて日本時間です。

どうもこういう状態になっていたようです。
「私のアカウントのAZ」と書いているのは、AWSアカウントによって「apne1-az1」というアベイラビリティゾーンを示す固有IDと、操作で使う「ap-northeast-1c」の紐付けが違うからです。

AZを確認

私は、VPCのサブネット一覧で確認しました。

私のブログ管理のアカウントでは、ap-northeast-1cが対象でした。

ひとまずブログにアクセス

いきなり「504 ERROR The request could not be satisfied.」でした。
他ブラウザからも試してみます。

CSSが読み込めなかったり不安定ですね。

一次対応

すでに復旧済の時間でしたので、念の為の対応です。

ALBから対象AZのサブネットを外しました。

オートスケーリンググループからも一応外しました。

ALBの設定変更をしたのが功を奏したのか、とりあえずはブログにアクセスできるようになりました。
ひとまず復旧完了ということで。

CloudWatchダッシュボードを確認

関係ありそうなメトリクスを見てみます。

T3インスタンスのCPUクレジット残高がぐんっと下がっているタイミングでEC2インスタンスのうちの一つがヘルスチェックに失敗してシャットダウンされて、新たなインスタンスが起動したようです。
時間的には障害復旧した後の時間でしたので、もしかしたら不安定になったインスタンス上のアプリケーションで問題が発生してしまって、このタイミングヘルスチェックに失敗したのかもしれません。

オートスケーリンググループのアクティビティログでも、ヘルスチェックに

そして該当時間にヘルシーホストカウントも下がっています。

該当時間あたりから5xxエラーが出初めています。

対象の8:30ぐらいを拡大して確認してみると、apne1-az1のインスタンスがシャットダウンして、apne1-az2に新しいインスタンスが起動しはじめたことがわかります。
ここから5xxエラーが発生しているということは、apne1-az2で新規で起動したEC2インスタンス上のアプリケーションが不安定な状態になってしまったということでしょうか。
とりあえず、このインスタンスを終了して、取り替えて復旧完了です。

以下は参考記録です。

オートスケーリンググループのアクティビティログ

オートスケーリングでは、t3.nanoとt3a.nanoを指定しています。
どうも、インスタンスタイプとAZの関係もあって、余分に起動したインスタンスがシャットダウンしたみたいです。
ALBでスティッキーセッションも使用していますし、CloudFrontも使っているしで、新たに起動したEC2インスタンス上のアプリケーションに整合性のない中途半端なリクエストが実行されてしまって不安定になったとか考えられそうな気が。
これも調査しないとなんともですが。

08:34 インスタンスがヘルスチェックに失敗して終了。
Successful Terminating EC2 instance: i-id03
At 2021-02-19T23:34:59Z an instance was taken out of service in response to an EC2 health check indicating it has been terminated or stopped.

08:35 ap-northeast-1cでt3a.nanoは起動できないので起動失敗。
Failed Launching a new EC2 instance. Status Reason: Could not launch Spot Instances. InvalidFleetConfiguration – Your requested instance type (t3a.nano) is not supported in your requested Availability Zone (ap-northeast-1c). Launching EC2 instance failed.
At 2021-02-19T23:35:19Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 1 to 2.

08:36 ap-northeast-1aでEC2インスタンスが起動
Successful Launching a new EC2 instance: i-id04
At 2021-02-19T23:36:38Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 1 to 2.

08:37 AZ同士のインスタンス数のバランスをとるために希望する数が2のところ3つ目を起動しようとしている
At 2021-02-19T23:37:18Z instances were launched to balance instances in zones ap-northeast-1a with other zones resulting in more than desired number of instances in the group. At 2021-02-19T23:38:37Z availability zones ap-northeast-1a had 2 instances respectively. An instance was launched to aid in balancing the group’s zones.

08:38 3つ目のインスタンスがap-northeast-1dで起動
Successful Launching a new EC2 instance: i-id02
At 2021-02-19T23:38:37Z instances were launched to balance instances in zones ap-northeast-1a with other zones resulting in more than desired number of instances in the group.

08:40 ap-northeast-1aに2つのインスタンスが起動している
At 2021-02-19T23:40:55Z availability zones ap-northeast-1a had 2 instances respectively. An instance was launched to aid in balancing the group’s zones.

08:41 余分に起動したインスタンスを削除
Successful Terminating EC2 instance: i-id01
At 2021-02-19T23:40:55Z instances were launched to balance instances in zones ap-northeast-1a with other zones resulting in more than desired number of instances in the group.
At 2021-02-19T23:41:35Z an instance was taken out of service in response to a difference between desired and actual capacity, shrinking the capacity from 3 to 2. At 2021-02-19T23:41:35Z instance i-id01 was selected for termination.

AWS Service Health DashboardでのEC2の障害情報

00:09
東京リージョンapne1-az1において、インスタンスに影響を及ぼす接続性の問題が発生しており、対応中。

00:58
apne1-az1一部で、周囲の温度が上昇している状況を確認。
一部EC2インスタンスで、接続性の問題または温度上昇の影響に伴い、電源が切れている問題が発生。
影響により、一部EBSボリュームにてパフォーマンスが低下。
東京リージョンその他アベイラビリティゾーンは、この問題の影響を受けていない。

01:40
温度の上昇は、当該セクション内の冷却システムへの電力の損失によって発生。
これまでに冷却システムの1つを正常に復旧。
引き続き温度を通常レベルに復元し、影響を受けたEC2インスタンスとEBSボリュームの回復に取り組み中。
EC2およびEBS APIを含むその他のシステムは、影響を受けたアベイラビリティーゾーン内で正常に動作。
影響のあったEC2インスタンスおよびEBSボリュームは、影響を受けたAZ、または他のAZで再起動を試みることができる。

02:43
当該セクション内のいくつかの冷却ユニットの電力はすでに復元しており、温度が低下し始めていることを確認。
残りのオフラインの冷却ユニットは引き続き作業を続け、温度を通常レベルに戻します。
温度が回復次第、影響を受けるEC2インスタンスとEBSボリュームが回復します。

03:42
影響を受けていた冷却ユニットの多くの電源が回復。
室温は通常のレベルに近い状況まで戻り、ネットワーク、EC2およびEBSボリュームの回復処理を開始。
ネットワークはすでに回復し、EC2とEBSボリュームの回復処理に着手。
回復処理が始まると再起動が発生するため、インスタンスでアクションをとっていただく場合あり。
EBSボリュームに関しましては、ボリュームが回復するにつれ、degraded I/Oパフォーマンスが通常に戻る。
”stopping” もしくは ”shutting-down” のまま止まってしまっているインスタンスに関しましては、回復処理が進むにつれ、 ”stopped” もしくは “terminated” に戻る。

04:26
影響を受けていた冷却サブシステムの電源が回復。
現在、室温は通常レベルで運用。
大部分の ES2 インスタンスと EBS ボリュームが復旧。
残りのインスタンスとボリュームの復旧作業に引き続き取り組み中。

05:09
影響を受けた一部の区画の室温は安定し、通常のレベルに戻る。
多くのEC2インスタンス、EBSボリュームは回復済み。
残りの少数のボリュームの復旧作業中。

05:54
引き続き影響を受けたすべてのインスタンスとボリュームの復旧に取り組み、Personal Health Dashboard を通じて、現在も影響を受けているお客様に対し通知を行う。
即時の復旧が必要な場合は、影響を受けているインスタンスまたはボリュームを置き換えていただくことを推奨。

AWS Service Health DashboardでのELBの障害情報

02:20
東京リージョンでの、ELB APIエラー率の上昇について調査中。
既存のALBへの接続には影響なし。

02:27
02:00から02:18にかけて東京リージョンにおいて APIエラーレートの増加を確認。
すでに問題は復旧し、通常通り動作。

まとめ

AWSのAZ障害が直接影響したかどうかはわかりませんが、新規でのEC2インスタンス起動時のアプリケーションの問題がありそうだなということがわかりました。
今回は、NGINXやPHP-FPMのログには何もなかったので、別のログも対象にして調査したほうがいいかもしれません。
一定期間対象のログを増やしてみて確認してみたいと思います。
エラー原因を取り除ければいいのですが、まずは原因がわかれば、ヘルスチェックではカスタムコードを使っているのでここに追加したいと思います。
ALBのヘルスチェックでPHPとMySQL接続をチェック

追記

その後、とあるタイミングでEC2インスタンスが再作成されたときに、5xx Errorが発生していました。
ターゲットグループを見ると2つのインスタンスがHealthyにはなっているものの、数回に一回のアクセスで504のエラーになったりします。
そして、2つのインスタンスのうち、1つはカスタムメトリクスとCloudWatch Logsが出力されず、Systems Managerにも接続できませんでした。
ヘルスチェックには合格しているものの、アプリケーションが求めているヘルシーではないということですね。
そしてこれは設定漏れでしたが、ヘルスチェックの猶予期間が0秒になってました。
処理の軽いhealthcheck.phpは正常に200を返して、WordPressはまだ準備が終わってないままアクセスが発生してプロセスに影響を与えていたと想定します。

以下の設定変更をしました。