Go to Qiita Advent Calendar 2024 Top
LoginSignup
367
252

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@nasuvitz(Kiminori Yokoi)inTIS株式会社

2019/8/23のAWS東京リージョン大規模障害の経過と原因まとめ

Last updated at Posted at 2019-08-23

2019/8/23に発生したAWS東京リージョンの大規模障害の経過と、現在確認すべき内容、今後の教訓などをまとめてみました。

9/24 16:00更新: 今回の障害の経過を受け、記事を整理いたしました。

#障害の経過

  • 8/23 12:36頃より特定AZにおけるネットワークコネクティビティの障害が発生
  • 8/23 20:18頃、EC2は大規模障害から回復との発表あり
  • 8/23 22:19頃、RDSも22:05頃までに同様に回復との発表あり
  • サービス障害発生時間は8/23 12:36〜22:05 (約9時間半)
  • 8/24 14:00以降、本障害の影響でEBSボリュームが回復不能となったアカウントに対し、個別のメールやPersonal Health Dashboardで通知あり
  • 8/25 8:00以降、本障害の影響でEBSボリュームが回復不能となったアカウントに対し、個別に続報あり
    • 注: メールが来ていなくても、Personal Health Dashboardに通知が来ている場合があるということですので、各自、確認が必要
  • 8/25 16:00頃にAWSが公式にパブリックメッセージを公開 (19:00頃に日本語訳も公開)
  • 8/28 AWSが公式のパブリックメッセージを更新
  • 9/6 16:00以降および9/7 11:00以降、本障害の影響でEBSボリュームが回復不能となったアカウントに対し、個別に続報あり (現時点で回復不能なEBSボリュームが放置されていたアカウントに限る?)
  • 影響が残ったAWSアカウントでは、以下「AWSのサービス復旧後も状況が改善しない場合に試した作業」に記す対応を検討し、実施することとなった

#影響範囲と原因

  • 東京リージョン(AP-NORTHEAST-1)の単一のアベイラビリティゾーン(AZ)で、一定の割合のEC2サーバのオーバーヒートが発生
    • 注: EC2サーバとはEC2インスタンスではなく、EC2が稼働するホストサーバのことを指す
  • この結果、当該アベイラビリティゾーンのEC2インスタンス及びEBSボリュームのパフォーマンスの劣化が発生
  • オーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因
  • 少数の EC2 インスタンスと EBS ボリュームは、電源の喪失と過大な熱量の影響を受けたハードウェアホスト上で動作
  • これらのインスタンスとボリュームの復旧には時間がかかり、一部は基盤のハードウェアの障害によりリタイアが必要となった
  • 影響の発生したアベイラビリティゾーンでの EC2 インスタンスの起動、および冪等性トークン（複数のインスタンスを起動させる危険なく、インスタンスの起動をリトライする機能）を使用して RunInstance API を東京リージョンで実行した場合に、エラー率の上昇が発生
  • 冪等性トークンを使用する Auto Scaling グループからのインスタンスの新規起動も阻害
  • 影響の発生した EBS ボリュームのスナップショットの作成も、エラー率の上昇が発生
  • 今回の事象はデータセンターで使用されるいくつかの冷却システムの制御と最適化に使用されるデータセンター制御システムの障害によって引き起こされた
  • 制御システムには、ファン、冷却装置、温度センサーなどのサードパーティ製デバイスとの通信を可能にするサードパーティ製のコードが含まれている
  • 今回の事象発生の直前に、データセンター制御システムは、制御ホスト群から制御ホストの 1 つを外す処理
  • サードパーティ製の制御システムにおけるロジックのバグにより、制御システムとデータセンターのデバイス間で情報交換が過度に発生し、最終的には制御システムが応答しなくなった
  • 制御システムに障害が発生した場合、制御システムの機能が回復するまで冷却システムが最大冷却モードになるよう設計
  • データセンターのごく一部で冷却システムがこの安全な冷却構成に正しく移行できず停止
  • 追加の安全策として、AWS のデータセンターオペレータは、通常ではデータセンター制御システムを迂回することで冷却システムを「パージ」モードにすることで故障に際しての熱風を素早く排出
  • 運用チームは、影響のあるデータセンターのエリアでパージをアクティブにしようとしたが、これも失敗
  • データセンターの影響を受けるエリアの温度が上昇し始め、サーバーが熱くなりすぎ、サーバーの電源が停止
  • この状況を改善されるためにはオペレータは影響を受けるすべての機器を手動で調査してリセットし、最大冷却モードにした
  • これらの対応時に一部のエアハンドリングユニットを制御する PLC も応答しないことが発覚。PLC をリセットする必要があり、またこの障害によりデフォルトの冷却モードと「パージ」モードが正常に動作していないことが確認
  • PLCをリセットし、冷却装置が稼働し、復旧に至っていった
  • RDS、 Redshift、 ElastiCache、Workspaces、ALB、WAF等、障害が起きたAZで動く他サービスも影響を受けた

#Service Health Dashboard 更新状況まとめ (Google翻訳で日本語化)

EC2 [RESOLVED]

13:18 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンの一部のインスタンスに影響する接続の問題を調査しています。

13:47 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、一部のインスタンスが損なわれ、一部のEBSボリュームのパフォーマンスが低下していることを確認できます。 一部のEC2 APIでは、エラー率とレイテンシが増加しています。 この問題の解決に取り組んでいます。

14:27 根本原因を特定し、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内のインスタンスの障害と低下したEBSボリュームのパフォーマンスの回復に取り組んでいます。

15:40 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、インスタンスの障害および低下したEBSボリュームパフォーマンスの回復が見られ始めています。 影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。

17:54 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンスの障害やEBSボリュームのパフォーマンスの低下について、リカバリが進行中です。 影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。

18:39 パフォーマンスが低下したEC2インスタンスとEBSボリュームの大部分は、現在回復しています。 この問題の影響を受ける残りのEC2インスタンスとEBSボリュームの復旧に引き続き取り組みます。 この問題は、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2インスタンスとEBSボリュームに影響します。

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 インスタンスはお客様側での作業が必要になる可能性がある為、 後ほどお客様個別にお知らせすることを予定しています。
(Service Health Dashboardに日本語訳が掲載されました)

##RDS [RESOLVED]
14:22 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンの一部のインスタンスに影響する接続の問題を調査しています。

15:25 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内のインスタンス接続の問題の根本原因を特定し、復旧に向けて取り組んでいます。

16:01 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内のインスタンス接続の問題の回復が見られ始めています。 影響を受けるすべてのインスタンスの復旧に向けて引き続き取り組んでいます。

18:16 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でインスタンス接続の問題の復旧が引き続き見られ、影響を受けるすべてのインスタンスの復旧に取り組んでいます。

20:46 インスタンス接続の問題の大部分は現在回復しています。 AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内の残りのインスタンス接続の問題の復旧に引き続き取り組みます。

22:19 12時36分から22時5分の間、一部のRDSインスタンスでは、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で接続の問題が発生しました。 問題は解決され、サービスは正常に動作しています。

#Service Health Dashboard 更新状況まとめ (原文)

EC2 [RESOLVED]

9:18 PM PDT We are investigating connectivity issues affecting some instances in a single Availability Zone in the AP-NORTHEAST-1 Region.

9:47 PM PDT We can confirm that some instances are impaired and some EBS volumes are experiencing degraded performance within a single Availability Zone in the AP-NORTHEAST-1 Region. Some EC2 APIs are also experiencing increased error rates and latencies. We are working to resolve the issue.

10:27 PM PDT We have identified the root cause and are working toward recovery for the instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST-1 Region.

11:40 PM PDT We are starting to see recovery for instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST-1 Region. We continue to work towards recovery for all affected instances and EBS volumes.

Aug 23, 1:54 AM PDT Recovery is in progress for instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST-1 Region. We continue to work towards recovery for all affected instances and EBS volumes.

Aug 23, 2:39 AM PDT The majority of impaired EC2 instances and EBS volumes experiencing degraded performance have now recovered. We continue to work on recovery for the remaining EC2 instances and EBS volumes that are affected by this issue. This issue affects EC2 instances and EBS volumes in a single Availability Zone in the AP-NORTHEAST-1 Region.

Aug 23, 4:18 AM PDT Beginning at 8:36 PM PDT a small percentage of EC2 servers in a single Availability Zone in the AP-NORTHEAST-1 Region shutdown due to overheating. This resulted in impaired EC2 instances and degraded EBS volume performance for resources in the affected area of the Availability Zone. The overheating was caused by a control system failure that caused multiple, redundant cooling systems to fail in parts of the affected Availability Zone. The chillers were restored at 11:21 PM PDT and temperatures in the affected areas began to return to normal. As temperatures returned to normal, power was restored to the affected instances. By 2:30 AM PDT, the vast majority of instances and volumes had recovered. We have been working to recover the remaining instances and volumes. A small number of remaining instances and volumes are hosted on hardware which was adversely affected by the loss of power. We continue to work to recover all affected instances and volumes. For immediate recovery, we recommend replacing any remaining affected instances or volumes if possible. Some of the affected instances may require action from customers and we will be reaching out to those customers with next steps.

RDS [RESOLVED]

10:22 PM PDT We are investigating connectivity issues affecting some instances in a single Availability Zone in the AP-NORTHEAST-1 Region.

11:25 PM PDT We have identified the root cause of instance connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region and are working toward recovery.

Aug 23, 12:01 AM PDT We are starting to see recovery for instance connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region. We continue to work towards recovery for all affected instances.

Aug 23, 2:16 AM PDT We continue to see recovery for instance connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region and are working towards recovery for all affected instances.

Aug 23, 4:46 AM PDT The majority of instance connectivity issues have now recovered. We continue to work on recovery for the remaining instance connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region.

Aug 23, 6:19 AM PDT Between August 22 8:36 PM and August 23 6:05 AM PDT, some RDS instances experienced connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region. The issue has been resolved and the service is operating normally.

個別に送付された、一部EBSが回復不能となったアカウントに対するAWSからの通知

一部、AWSのサービス復旧後も影響を受け続けているアカウントがあります。
これらのアカウントでは、各アカウントのPersonal Health Dashboardや個別メールで、下記の案内が出ておりますので、対応が必要です。
スナップショットからのボリューム復元が出来る場合は対応、出来ない場合AMIからのリストアを試みることになります。(後述参照)
##8/24のAWSからの個別メール通知
###メールの日本語訳(Google翻訳)
タイトルは「Your Amazon EBS Volume vol-XXXXXXXXXXXXXXXXX」

8月23日12時36分から、過熱によるAP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2サーバーのごく一部のシャットダウン。これにより、アベイラビリティーゾーンの影響を受けるエリアのリソースのEC2インスタンスとEBSボリュームが損なわれました。ボリュームは障害のあるEBSボリュームの1つでした。過熱の原因は、制御システムの障害であり、影響を受けたアベイラビリティーゾーンの一部で複数の冗長冷却システムが故障しました。15時21分に復旧し、影響を受けた地域の温度は通常に戻り始めました。温度が正常に戻ると、影響を受けたインスタンスの電力が回復し、自動化システムがEBSボリュームの回復を試みました。ただし、ボリュームを回復する前に、ボリュームの基になるEBSサーバーでハードウェア障害が発生しました。さらにボリュームを回復しようとすると、ボリュームは回復不能であると判断されました。

アカウント番号: XXXXXXXXXXXX
影響を受けているリソースID : vol-XXXXXXXXXXXXXXXXX

最新のEBSスナップショットまたは別のバックアップからボリュームを復元できる場合は、悪影響のあるボリュームをバックアップから作成された新しいボリュームに置き換えることをお勧めします。

ご不便をおかけしましたことをお詫び申し上げます。この問題に関してさらに質問やコメントがある場合は、http://aws.amazon.com/support にご連絡ください。

###メールの原文

Beginning August 22 8:36 PM PDT a small percentage of EC2 servers in a single Availability Zone in the AP-NORTHEAST-1 Region shutdown due to overheating. This resulted in impaired EC2 instances and EBS volumes for resources in the affected area of the Availability Zone. Your volume was one of the impaired EBS volumes. The overheating was caused by a control system failure that caused multiple, redundant cooling systems to fail in parts of the affected Availability Zone. The chillers were restored at 11:21 PM PDT and temperatures in the affected areas began to return to normal. As temperatures returned to normal, power was restored to the affected instances and our automated systems attempted to recover your EBS volume. However, before your volume could be recovered, the EBS servers underlying your volume experienced a hardware failure. After further attempts to recover the volume, the volume was determined to be unrecoverable.

Account Number: XXXXXXXXXXXX
Impacted Resource Identifier: vol-XXXXXXXXXXXXXXXXX

If you have the ability to restore your volume from a recent EBS snapshot or another backup, we recommend that you replace the adversely impacted volume with a new volume created from a backup.

We apologize for the inconvenience this may have caused you. If you have any further questions or comments regarding this matter, please contact us at:
http://aws.amazon.com/support

Sincerely,
Amazon Web Services

8/25に送信された続報

タイトルは「Your Amazon EBS Volume」

###メールの日本語訳(Google翻訳)

**複数のコンポーネントの障害が原因でボリュームに障害が発生し、ボリュームを回復できませんでした。**EBSボリュームは、複数の物理ドライブによるバックアップを含む信頼性のために設計されていますが、冗長性を復元する前に複数のコンポーネントの同時障害が発生すると、耐久性リスクにさらされます。 EBSの詳細ページ（http://aws.amazon.com/ebs/details） で耐久性の期待値を公開しています。

アカウント番号: XXXXXXXXXXXX
リージョン: ap-northeast-1
影響を受けたリソースのID: vol-XXXXXXXXXXXXXXXXX

次の手順を使用して、ボリュームのスナップショットからデータを復元できます。 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html

ご不便をおかけしましたことをお詫び申し上げます。 この問題に関してさらに質問やコメントがある場合は、http://aws.amazon.com/support にご連絡ください。

###メールの原文

Dear Amazon Web Services Customer,

Your volume experienced a failure due to multiple component failures and we were unable to recover it. Although EBS volumes are designed for reliability, including being backed by multiple physical drives, we are still exposed to durability risks when multiple concurrent component failures occur before we are able to restore redundancy. We publish our durability expectations on the EBS detail page here (http://aws.amazon.com/ebs/details).

Account Number: XXXXXXXXXXXX

Region: ap-northeast-1

Impacted Resource Identifier: vol-XXXXXXXXXXXXXXXXX

You may use the following instructions to restore your data from a volume snapshot. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html

We apologize for the inconvenience this may have caused you. If you have any further questions or comments regarding this matter, please contact us at: http://aws.amazon.com/support.

Sincerely,
Amazon Customer Support

##9/6～9/7に通知された続報
タイトルは「回復不能な EBS ボリューム (AP-NORTHEAST-1) | Unrecoverable EBS Volumes in AP-NORTHEAST-1」

###メールの日本語訳

Hello,

EBS ボリュームのデータは通常、複数のストレージノード上で冗長化されてホストされています。ストレージノードのコンポーネントで問題が発生した場合、 EBS システムは自動的にボリュームのデータを代替のセカンダリストレージノードに複製します。このプロセスが完了するまで、ボリュームデータの冗長性は縮退状態となります。日本時間 2019年8月23日 12:36 に発生した空調システムの問題により、いくつかの EBS ボリュームで冗長性が失われました。 EBS システムは自動的に冗長性の回復を試みましたが、これが完了する前にお客様の EBS ボリュームの残りのコピーをホストしているストレージノードがオフラインとなりました。 AWS では引き続き EBS ボリュームの復旧を試みたものの、対象となる EBS ボリュームは復旧不可能と判断されました。 AWS ではこのような稀に発生しうる電源に関するイベントを異なる形で扱うことができないかという観点で、冗長性の縮退した状態へ EBS ボリュームを遷移させることを EBS サーバーに許可するアルゴリズムの再検討を進めております。

下記は影響を受けたお客様の EBS ボリュームの一覧です:
vol-XXXXXXXXXXXXXXXXX

お客様のボリュームを最近の EBS スナップショットないしはその他のバックアップから復元できるのであれば、影響を受けた EBS ボリュームをバックアップから作成した新しい EBS ボリュームと交換することを推奨いたします。

お客様にはご不便をおかけしておりますこと、お詫び申し上げます。本件に関して質問やコメントがございましたら、 https://aws.amazon.com/support よりお問い合わせください。

###メールの原文

Data for EBS volumes is normally redundantly hosted on multiple storage nodes. When a component in a storage node fails, EBS systems automatically replicates volume data on a replacement secondary storage node. Until this process completes, volume data has reduced redundancy. At 8:36 PM PDT August 22, a cooling event caused some volumes to lose redundancy. EBS systems automatically attempted to restore redundancy, but before that could complete, the storage nodes hosting the remaining copies of your volumes went off-line. After further attempts to recover the volume, the volume was determined to be unrecoverable. We are reviewing the algorithms that permit EBS servers to transition a volume into a reduced redundancy mode to see if they should be modified to handle these rare power events differently.

Below is a list of your affected EBS Volumes:
vol-XXXXXXXXXXXXXXXXX

If you have the ability to restore your volume from a recent EBS snapshot or another backup, we recommend that you replace the adversely impacted volume with a new volume created from a backup.

We apologize for the inconvenience this may have caused you. If you have any further questions or comments regarding this matter, please contact us at: https://aws.amazon.com/support

Sincerely,
Amazon Web Services

##8/24に通知されたPersonal Health Dashboard

Personal Health Dashboardの日本語訳 (Google翻訳)

8月23日(日本時間)、東京（AP-NORTHEAST-1）リージョンの単一のアベイラビリティーゾーンで冷却障害が発生し、「影響を受けるリソース」タブにリストされている1つ以上のボリュームにアクセスできなくなりました。冷却障害により、ボリュームを保存する1つ以上のストレージサーバーでハードウェア障害が発生しました。ハードウェア障害の解決に取り組んでいます。ただし、最新のスナップショットからボリュームを復元できる場合は、復元することをお勧めします。ハードウェア障害の性質を考えると、影響を受けるサーバーの障害のあるコンポーネントを交換するために作業するため、復旧が長くなることが予想されます。

Personal Health Dashboardの原文

On August 22 we experienced a cooling failure in a single Availability Zone in the Tokyo (AP-NORTHEAST-1) Region, which has caused one or more of your volumes listed in the 'Affected Resources' tab, to be inaccessible. The cooling failure resulted in hardware failure on one or more storage servers that store your volume(s). We are working to resolve the hardware failures; however, if you have the ability to restore your volume(s) from a recent snapshot, we recommend that you do so. Given the nature of the hardware failures, we anticipate that recovery will be prolonged as we work to replace the failed components in the affected servers.

障害発生中にAuto Recoveryが失敗したアカウントに対するAWSからの個別報知メール

障害が発生していた時間中に、EC2のAuto Recoveryが実行された場合、おそらくホストの障害が継続していたがゆえに復旧に失敗し、その後EC2がrunning以外の状態になっていることがあるようです。
EC2を手動で再度Startする対応が必要となります。

タイトルは「[Auto Recovery] Amazon EC2 instance recovery: Failure」

##メールの日本語訳 (Google翻訳)

アカウントに関する重要なお知らせがあります（AWSアカウントID：XXXXXXXXXXXX）。 ap-northeast-1リージョンのEC2インスタンスの1つがシステムステータスチェックに失敗しました。インスタンスはAuto Recoveryが設定されましたが、復旧に失敗しました。インスタンスIDは次のとおりです。
i-XXXXXXXXXXXXXXXXX

インスタンスは実行状態のままになり、Amazon EC2は引き続き根本的な根本原因の修正を試みます。

なぜこれが起こったのですか？
自動回復が失敗する一般的な理由は次のとおりです。
1.交換ハードウェアの一時的な容量不足。
2.インスタンスにインスタンスストアをアタッチしました。これは、自動インスタンスリカバリのサポートされていない構成です。
3.復旧プロセスの正常な実行を妨げる進行中のService Health Dashboardイベントがあります。最新のサービス可用性情報については、http：//status.aws.amazon.comを参照してください。
4.インスタンスは、3回の回復試行の1日の最大許容値に達しました。

インスタンスリカバリエラーのトラブルシューティングの詳細については、http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstanceRecovery.html をご覧ください。

あなたは何する必要があるの？
インスタンスのシステムステータスチェックの失敗が続く場合は、手動で停止および開始することをお勧めします。詳細については、http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html を参照してください。ハードウェアの劣化がシステムステータスチェックの失敗の根本原因であると判断された場合、インスタンスはその後廃止される可能性があります。

EC2 Auto Recoveryの詳細については、http：//docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.htmlをご覧ください。

##メールの原文

We have important news about your account (AWS Account ID: XXXXXXXXXXXX). One of your EC2 instances in the ap-northeast-1 region has failed a System status check. The instance was configured for Auto Recovery but the recovery attempt failed. The Instance ID is:
i-XXXXXXXXXXXXX

Your instance will remain in the running state and Amazon EC2 will continue to try and remediate the underlying root cause.

Why did this happen?
Common reasons for Auto Recovery failure include:

  1. Temporary insufficient capacity of replacement hardware.
  2. You have attached an instance store to the instance, which is an unsupported configuration for automatic instance recovery.
  3. There is an ongoing Service Health Dashboard event that prevented the recovery process from successfully executing. Please refer to http://status.aws.amazon.com for the latest service availability information.
  4. Your instance has reached the maximum daily allowance of three recovery attempts.

You can learn more about troubleshooting instance recovery failures here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstanceRecovery.html

What do you need to do?
If the instance System status check failure persists, we recommend that you perform a manual stop and start. Please refer to http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html for more information. Your instance may subsequently be retired if a hardware degradation is determined to be the root cause for the System status check failure.

You can learn more about EC2 Auto Recovery here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html

8/25に発表されたAWS公式のパブリックメッセージで詳細な原因が判明

AWSの公式サイトで、今回の障害に関連し、パブリックメッセージが公開されました。
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要

日本時間 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 サービスの向上に努めてまいります。

8/28に追記されたAWS公式のパブリックメッセージで、EC2とEBS以外の影響についても公式に言及

当初発表されたパブリックメッセージでは、EC2とEBSのみに言及がありましたが、8/28にはRDS、 Redshift、 ElastiCache、Workspaces、ALB、WAF等の他サービスでも影響が及んでいたとの記述が追記されました。
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要

最初の事象概要で言及した通り、今回のイベントは、東京リージョンの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のサービス復旧後も状況が改善しない場合に試した作業

  • まず自身のアカウントに影響が残存していないかどうか、必ずPersonal Health Dashboardで確認
  • Personal Health DashboardでEBSボリュームの案内が来ている場合、その性質の切り分けにより以下の復旧を検討
    • EBS ボリュームがルートボリュームである場合
      • 事象
        • EC2インスタンスは Pending のままの状態
        • AMI 取得、スナップショット取得は失敗する可能性大
        • EC2インスタンスの停止が Stopping のままの状態、またはStopped になる場合もあり
      • 対応策
        • バックアップで AMI を取得しているのであれば、AMI から新規インスタンス作成
        • 業務影響が大きいものであれば、バックアップからの復旧を優先
        • ロストと判断されたボリュームについては、AWS側でも復旧ができない
    • EBS ボリュームがデータ用のボリュームである場合
      • 事象
        • EC2インスタンスは Pending のまま
        • 該当の EBS ボリュームのスナップショットや EBS ボリュームを含んだ形でのAMIは失敗
        • EC2インスタンスの停止が Stopping のままの状態。またはStopped になる場合もあり
      • 対応策
        • EC2 インスタンスを停止させてデータ用の EBS ボリュームをデタッチし、その後 EC2 インスタンスを起動して正常に起動するか確認
        • 問題のデータ用の EBS ボリュームは、スナップショットがあればリストアして復旧
  • WorkSpacesの起動がうまく行っていない(UNHEALTHY等)の場合、以下を試みる
  • WorkSpacesがREBOOTINGのまま動かずに「削除」以外選択できなくなっている場合、手の施しようがないため、AWSサポートに問い合わせて確認および再構築の依頼が必要
    • ステータスがREBOOTINGからUNHEALTYに変われば、再構築が選択可能 (変化するまでは長時間におよぶ模様)
    • ステータスがREBOOTINGのまま続くようであればAWSサポートに再構築を依頼
  • 障害が発生していた時間中に、EC2のAuto Recoveryが実行され、失敗している場合には、ルートアカウント宛にメールが送付されており、対応が必要
    • EC2がStoppedのままとなっている場合、手動でEC2をStartして復旧する
  • EC2のステータスがStoppingまたはPendingの場合は、一度手動でEC2をStopし、再度Startを試みる
    • Stop→Startすると、EC2は別のホストに移って起動され、不具合から抜け出せる可能性があるため
    • 参考: https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Stop_Start.html
    • 引用: 殆どの場合、インスタンスは基盤となる新しいホストコンピュータが起動したときに移行されます。
    • Stopの操作をしてもEC2が停止しない場合、もう一度StopすることでForcefully Stopを試みる
    • Forcefully Stopもできない場合、手の施しようがないため、AWSサポートに相談
      • 参考: https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/TroubleshootingInstancesStopping.html
      • 引用: 10 分が経過してもインスタンスが停止しない場合は、Amazon EC2 forum にヘルプリクエストを投稿してください。迅速な解決のために、インスタンス ID を含めて、既に行った手順について説明してください。また、サポートプランを契約している場合は、サポートセンターでサポートケースを作成できます。
  • EC2でさらに問題が継続している場合、以下の方法が取れる場合には試す （各サーバの中身や構成の話にも関わるため、必ずしもリカバリが成功することを保証するものではないが参考まで）
    • AMIなどのバックアップがある場合、リストアを実施
    • バックアップが存在しない場合、AMIを取得（AMI取得に失敗する可能性があるが、その場合にはAMI 取得をリトライする）
    • リトライを継続しても AMI取得ができない場合、古いAMIやAMI以外からリストアできないか確認
    • AMI取得が完了した場合、AMIからインスタンスを起動
    • IPが変わってはいけないEC2(1個目のENIのIPを変更したくない)の場合、AMIから同一IPでインスタンスを起動する場合に、まず既存EC2のTerminateが必要
      • ステータスがShutting-downのまま動かないなどでTerminateできない場合、手の施しようがないため、AWSサポートに相談
        • 参考: https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/TroubleshootingInstancesShuttingDown.html
        • 引用: インスタンスの終了処理が停止していると考えられ、すでに数時間以上経過している場合は、Amazon EC2 forum にヘルプリクエストを投稿してください。迅速な解決のために、インスタンス ID を含めて、既に行った手順について説明してください。また、サポートプランを契約している場合は、サポートセンターでサポートケースを作成できます。

障害の状況をどうやって確認していたか

サーバ監視

そりゃそうです。まずはここで分かります。

AWS Service Health Dashboard

公式の案内所です。とにかくここを見て経過を追う必要があります。
https://status.aws.amazon.com/

Yahoo! リアルタイム速報

ユーザの反応は、どんな速報よりも早いので、いち早く障害のヤバさ(影響の広さ)を知ることができました。
https://search.yahoo.co.jp/realtime/search;_ylt=A7dPSClMa19dfEcAxeGJBtF7?p=AWS&fr=top_ga1_sa&ei=UTF-8

#どうやって、この手の障害から身を守るか
サーバは複数AZに跨ぎ冗長構成にすることが基本となります。
また、単に複数AZにしさえすれば良いというものではなく、監視/検知の仕組みを導入し、異常にすぐ気づける仕組みを作ることが大事です。
自動復旧に頼ることはもちろんですが、現状はどうしても完全には対応しきれずに、手動で対応しなければならない場面もあるため、そのためにも監視/検知を怠るべきではありません。

  • 監視できるものは全て監視する
  • VPC、EC2も可能な限り冗長構成にする
    • VPC内のSubnetは、2つ以上のAZで分ける
    • 複数AZでAuto Scalingが組めれば組む
    • サービスを止めたくないならば、レスポンス低下したりコスト発生しても複数AZで組む
    • 複数AZに構築する場合、Active/Activeなら2倍以上のコストがかかる
    • 今回は東京リージョン全域の障害ではなかったが、コストが出せるなら、全域障害を見越し、大阪リージョンとの間でDR構成を検討する
  • 万が一のリストア時を考えバックアップを取っておく
    • AWS Backupを活用する
    • AMIからのリストアができるようにAMIも定期取得しておく
  • RDSはMulti-AZにする
    • コストはシングル構成の2倍
  • リトライ (再送等) の仕組みは考えておく

など。

その他

今回のAWSの障害は「NHKニュース7」でも放送されたようです。
アマゾン運営のウェブサービス「ＡＷＳ」の障害おおむね復旧

367
252
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
367
252

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?