2019-09-24Organization2019/8/23のAWS東京リージョン大規模障害の経過と原因まとめsellAWS,EC2,RDS,elb,workspaces2019/8/23に発生したAWS東京リージョンの大規模障害の経過と、現在確認すべき内容、今後の教訓などをまとめてみました。今回の障害の経過を受け、記事を整理いたしました。応答しないことが発覚。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンの一部のインスタンスに影響する接続の問題を調査しています。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、一部のインスタンスが損なわれ、一部のEBSボリュームのパフォーマンスが低下していることを確認できます。APIでは、エラー率とレイテンシが増加しています。この問題の解決に取り組んでいます。根本原因を特定し、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内のインスタンスの障害と低下したEBSボリュームのパフォーマンスの回復に取り組んでいます。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、インスタンスの障害および低下したEBSボリュームパフォーマンスの回復が見られ始めています。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンスの障害やEBSボリュームのパフォーマンスの低下について、リカバリが進行中です。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。パフォーマンスが低下したEC2インスタンスとEBSボリュームの大部分は、現在回復しています。この問題の影響を受ける残りのEC2インスタンスとEBSボリュームの復旧に引き続き取り組みます。この問題は、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2インスタンスとEBSボリュームに影響します。サーバのオーバーヒートが発生しました。ボリュームのパフォーマンスの劣化が発生しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。冷却装置は復旧し、室温が通常状態に戻り始めました。温度が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。ボリュームは回復しました。ボリュームの回復に取り組んでいます。ホスト上に残されています。ボリュームの回復のための作業を継続しています。ボリュームのリプレースを推奨します。後ほどお客様個別にお知らせすることを予定しています。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンの一部のインスタンスに影響する接続の問題を調査しています。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内のインスタンス接続の問題の根本原因を特定し、復旧に向けて取り組んでいます。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内のインスタンス接続の問題の回復が見られ始めています。影響を受けるすべてのインスタンスの復旧に向けて引き続き取り組んでいます。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でインスタンス接続の問題の復旧が引き続き見られ、影響を受けるすべてのインスタンスの復旧に取り組んでいます。インスタンス接続の問題の大部分は現在回復しています。AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内の残りのインスタンス接続の問題の復旧に引き続き取り組みます。12時36分から22時5分の間、一部のRDSインスタンスでは、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で接続の問題が発生しました。問題は解決され、サービスは正常に動作しています。一部、AWSのサービス復旧後も影響を受け続けているアカウントがあります。Dashboardや個別メールで、下記の案内が出ておりますので、対応が必要です。スナップショットからのボリューム復元が出来る場合は対応、出来ない場合AMIからのリストアを試みることになります。vol-XXXXXXXXXXXXXXXXX」8月23日12時36分から、過熱によるAP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2サーバーのごく一部のシャットダウン。これにより、アベイラビリティーゾーンの影響を受けるエリアのリソースのEC2インスタンスとEBSボリュームが損なわれました。ボリュームは障害のあるEBSボリュームの1つでした。過熱の原因は、制御システムの障害であり、影響を受けたアベイラビリティーゾーンの一部で複数の冗長冷却システムが故障しました。15時21分に復旧し、影響を受けた地域の温度は通常に戻り始めました。温度が正常に戻ると、影響を受けたインスタンスの電力が回復し、自動化システムがEBSボリュームの回復を試みました。ボリュームを回復する前に、ボリュームの基になるEBSサーバーでハードウェア障害が発生しました。ボリュームを回復しようとすると、ボリュームは回復不能であると判断されました。vol-XXXXXXXXXXXXXXXXX最新のEBSスナップショットまたは別のバックアップからボリュームを復元できる場合は、悪影響のあるボリュームをバックアップから作成された新しいボリュームに置き換えることをお勧めします。ご不便をおかけしましたことをお詫び申し上げます。Volume」メールの日本語訳(Google翻訳)複数のコンポーネントの障害が原因でボリュームに障害が発生し、ボリュームを回復できませんでした。EBSボリュームは、複数の物理ドライブによるバックアップを含む信頼性のために設計されていますが、冗長性を復元する前に複数のコンポーネントの同時障害が発生すると、耐久性リスクにさらされます。耐久性の期待値を公開しています。vol-XXXXXXXXXXXXXXXXX次の手順を使用して、ボリュームのスナップショットからデータを復元できます。http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.htmlご不便をおかけしましたことをお詫び申し上げます。ボリュームのデータは通常、複数のストレージノード上で冗長化されてホストされています。システムは自動的にボリュームのデータを代替のセカンダリストレージノードに複製します。このプロセスが完了するまで、ボリュームデータの冗長性は縮退状態となります。ボリュームで冗長性が失われました。ボリュームの残りのコピーをホストしているストレージノードがオフラインとなりました。ボリュームは復旧不可能と判断されました。サーバーに許可するアルゴリズムの再検討を進めております。ボリュームと交換することを推奨いたします。お客様にはご不便をおかけしておりますこと、お詫び申し上げます。お問い合わせください。(Google翻訳)8月23日(日本時間)、東京(AP-NORTHEAST-1)リージョンの単一のアベイラビリティーゾーンで冷却障害が発生し、「影響を受けるリソース」タブにリストされている1つ以上のボリュームにアクセスできなくなりました。冷却障害により、ボリュームを保存する1つ以上のストレージサーバーでハードウェア障害が発生しました。ハードウェア障害の解決に取り組んでいます。最新のスナップショットからボリュームを復元できる場合は、復元することをお勧めします。ハードウェア障害の性質を考えると、影響を受けるサーバーの障害のあるコンポーネントを交換するために作業するため、復旧が長くなることが予想されます。Recoveryが実行された場合、おそらくホストの障害が継続していたがゆえに復旧に失敗し、その後EC2がrunning以外の状態になっていることがあるようです。EC2を手動で再度Startする対応が必要となります。(Google翻訳)アカウントに関する重要なお知らせがあります(AWSアカウントID:XXXXXXXXXXXX)。ap-northeast-1リージョンのEC2インスタンスの1つがシステムステータスチェックに失敗しました。Recoveryが設定されましたが、復旧に失敗しました。インスタンスIDは次のとおりです。EC2は引き続き根本的な根本原因の修正を試みます。これが起こったのですか?自動回復が失敗する一般的な理由は次のとおりです。1.交換ハードウェアの一時的な容量不足。2.インスタンスにインスタンスストアをアタッチしました。これは、自動インスタンスリカバリのサポートされていない構成です。Dashboardイベントがあります。最新のサービス可用性情報については、http://status.aws.amazon.comを参照してください。4.インスタンスは、3回の回復試行の1日の最大許容値に達しました。あなたは何する必要があるの?インスタンスのシステムステータスチェックの失敗が続く場合は、手動で停止および開始することをお勧めします。ハードウェアの劣化がシステムステータスチェックの失敗の根本原因であると判断された場合、インスタンスはその後廃止される可能性があります。Recoveryの詳細については、http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.htmlをご覧ください。http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html8/25に発表されたAWS公式のパブリックメッセージで詳細な原因が判明AWSの公式サイトで、今回の障害に関連し、パブリックメッセージが公開されました。サーバのオーバーヒートが発生しました。ボリュームのパフォーマンスの劣化が発生しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。冷却装置は復旧し、室温が通常状態に戻り始めました。室温が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。ボリュームは回復しました。ボリュームは、電源の喪失と過大な熱量の影響を受けたハードウェアホスト上で動作していました。これらのインスタンスとボリュームの復旧には時間がかかり、一部につきましては基盤のハードウェアの障害によりリタイアが必要でした。東京リージョンで実行した場合に、エラー率の上昇が発生しました。インスタンスの起動は正常に動作しておりました。グループからのインスタンスの新規起動も阻害しました。グループの問題を解決しました。ボリュームのスナップショットの作成も、この期間にエラー率の上昇が発生しました。今回の事象はデータセンターで使用されるいくつかの冷却システムの制御と最適化に使用されるデータセンター制御システムの障害によって引き起こされました。制御システムは、高可用性を実現するために複数のホストで実行されます。この制御システムには、ファン、冷却装置、温度センサーなどのサードパーティ製デバイスとの通信を可能にするサードパーティ製のコードが含まれていて、直接または組み込みプログラマブルロジックコントローラ(PLC)を介して通信し、実際のデバイスと通信します。つを外す処理を行なっていました。情報を交換する必要があります。サードパーティ製の制御システムにおけるロジックのバグにより、この情報交換が制御システムとデータセンターのデバイス間で過度に発生し、最終的には制御システムが応答しなくなりました。データセンターは、データセンターの制御システムに障害が発生した場合、制御システムの機能が回復するまで冷却システムが最大冷却モードになるよう設計されています。これはデータセンターのほとんどで正常に機能していましたが、データセンターのごく一部で冷却システムがこの安全な冷却構成に正しく移行できず停止しました。データセンターオペレータは、通常ではデータセンター制御システムを迂回することで冷却システムを「パージ」モードにすることで故障に際しての熱風を素早く排出します。運用チームは、影響のあるデータセンターのエリアでパージをアクティブにしようとしましたが、これも失敗しました。この時点で、データセンターの影響を受けるエリアの温度が上昇し始め、サーバーが熱くなりすぎ、サーバーの電源が停止し始めました。データセンター制御システムが利用できなかったため、データセンターオペレータはデータセンターの状態と冷却システムの状態に対する可視性が最小限に限定されていました。この状況を改善されるためにはオペレータは影響を受けるすべての機器を手動で調査してリセットし、最大冷却モードにする必要がありました。応答しないことが見つかりました。リセットする必要があり、またこの障害によりデフォルトの冷却モードと「パージ」モードが正常に動作していないことが確認できました。これらのコントローラがリセットされると、影響のあったデータセンターのエリアへ冷却が行われ室温が低下し始めました。両面を引き起こしたバグ、並びにバグによる影響の詳細な調査を進めております。平行して、事象の再発を防ぐため、バグを引き起こした制御システムのフェイルオーバーモードを無効にしました。万が一事象が再現しても対策が取れるよう、オペレータにこの度の事象の検知方法と復旧方法のトレーニングを実施しました。これにより、もし同様の事象が発生しても、お客様への影響が発生する前に、システムのリセットが可能になっております。完全にバイパスできるよう、空調システムを制御する方法を変更するよう作業を進めております。応答がなくなった際でも機能するように出来る、より確実な方法となっています。ボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨します(お客様にとって高可用性に課題を生じ得る全てのアプリケーションのコンポーネントは、この耐障害性を実現する方法の下で稼働させることを強く推奨します)。この度の事象により、ご迷惑をおかけしましたことを心よりお詫び申し上げます。サービスがお客様ビジネスに極めて重要である点を理解しております。完全ではないオペレーションには決して満足することはありません。サービスの向上に努めてまいります。ElastiCache、Workspaces、ALB、WAF等の他サービスでも影響が及んでいたとの記述が追記されました。最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。等)にも影響がありました。個別の問題についての詳細な情報を、影響を受けたお客様に直接、共有を行う予定です。殆どの場合、インスタンスは基盤となる新しいホストコンピュータが起動したときに移行されます。ヘルプリクエストを投稿してください。含めて、既に行った手順について説明してください。サポートプランを契約している場合は、サポートセンターでサポートケースを作成できます。ヘルプリクエストを投稿してください。含めて、既に行った手順について説明してください。サポートプランを契約している場合は、サポートセンターでサポートケースを作成できます。障害の状況をどうやって確認していたかサーバ監視そりゃそうです。Dashboard公式の案内所です。ここを見て経過を追う必要があります。リアルタイム速報ユーザの反応は、どんな速報よりも早いので、いち早く障害のヤバさ(影響の広さ)を知ることができました。https://search.yahoo.co.jp/realtime/search;_ylt=A7dPSClMa19dfEcAxeGJBtF7?p=AWS&fr=top_ga1_sa&ei=UTF-8どうやって、この手の障害から身を守るかサーバは複数AZに跨ぎ冗長構成にすることが基本となります。複数AZにしさえすれば良いというものではなく、監視/検知の仕組みを導入し、異常にすぐ気づける仕組みを作ることが大事です。自動復旧に頼ることはもちろんですが、現状はどうしても完全には対応しきれずに、手動で対応しなければならない場面もあるため、そのためにも監視/検知を怠るべきではありません。仕組みは考えておくなど。今回のAWSの障害は「NHKニュース7」でも放送されたようです。