AWSのこれまでの障害と対策
AWSは、多くのサービスを全世界のリージョンより提供しています。可用性や信頼性には十分な配慮がされていますが、すべてのハードウェアやソフトウェア、ネットワークなどを常に稼働させるため、個別に障害が発生する場合があります。
2023年6月13日にバージニア北部で発生した障害では、米国を中心に障害が発生したほか日本でもデジタル家電が動作しないなど、多くの影響を世界的に与えたことがニュースで報じられました。このように、他のリージョンの障害においても利用者は注意深く見ておくのが良いでしょう。
ここでは、AWSのこれまでの障害と対策を見ていきます。
【参考】：バージニア北部 (US-EAST-1) リージョンでの AWS Lambda サービスイベントについての概要
障害発生時の情報を確認するには
障害はそれぞれのIT機器に生じる場合から、大規模な電源障害やネットワーク障害など、影響範囲が小規模なものから広範囲に影響を生じさせる場合まで多岐にわたります。
大規模な問題や、重大な障害が発生した場合、AWSは問題が解決した後、障害報告のためにポストイベントサマリ （PES、Post-Event Summary） を公開することをコミットしています。
この情報は、最低5年は公開され、問題の影響範囲や問題の原因となった要因、対処の方法などが記載されています。
東京リージョンで発生したAmazon EC2とAmazon EBSの大規模な障害の場合
2019年8月23日午後から、東京リージョンでAmazon EC2のインスタンスに接続できない状況が生じました。この障害では、郵便局やドコモの一部サービス、ユニクロや東急ハンズなどの商取引サイト、各企業の公式サイト、PyaPayやファミペイなどの電子決済サービスなど多くの影響を与えました。
障害は、単一のアベイラビリティゾーンで生じたオーバーヒートによるものです。オーバーヒートによって一定数のEC2サーバが停止し、EC2インスタンスやEBSボリュームへのパフォーマンス低下を引き起こしました。
このオーバーヒートは、空調設備の管理システムの障害が原因で、15時過ぎに冷却装置が復旧すると徐々に影響を受けたインスタンスの電源が回復していきました。約6時間後には大部分が復旧し、全体復旧には約9時間半かかっています。
この障害では、同一アベイラビリティゾーンのEC2インスタンス起動の増加やリトライによってエラー率も上昇し、Auto Scalingも問題も引き起こしました。
根本原因は、冷却システムの制御とデータセンターの制御システムの障害によるものです。サードパーティ製デバイスと通信するコードのロジックの不具合が、制御システムの無応答を引き起こし、冷却システムの維持機能が動作しなかったことが原因です。
【参考】：AWS: 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
東京リージョンで発生したAWS Direct Connectの大規模な障害の場合
2021年9月2日早朝に、東京リージョンで大規模な障害が発生しました。この障害では、三菱UFJ銀行やみずほ銀行のスマホアプリ、ネット証券のウェブサイト、au Payなどの電子決済サービスが影響を受けました。
同時に、日本航空や全日空、羽田空港の貨物輸送やチェックインシステムへの障害などで大きな混乱が生じました。
障害はAWS Direct Connectのロケーションで発生したもので、顧客のVirtual Private Cloud（VPC）を収容する東京リージョンのデータセンターネットワークへのネットワークパス上で、ネットワークデバイスの一部に障害が発生したことが原因と報告されています。
本来は自動的に切り離すべきデバイスを手動操作したことから、別のネットワークデバイスでも同様の障害が発生し、ネットワークの輻輳（ふくそう）によって被害が拡大しました。
障害発生のトリガーとなったのは、数カ月前に導入された新しいプロトコルが、これまでと異なるトラフィックパターンを生じさせ、相互作用により障害が生じたと報告されています。
障害発生から復旧までおよそ6時間程度を要しましたが、この新しいプロトコルは無効化され、事象の再発はなく、以前の安定状態を取り戻しました。
これらの経緯と対処方法は、障害発生から数日で一般公開されており、社会インフラとなるクラウドサービスでは情報公開の迅速性があらためて求められる事態と認識されています。
【参考】：AWS: 東京リージョン(AP-NORTHEAST-1)で発生したAWS Direct Connectの事象についてのサマリー
AWSの障害ステータスを確認する
AWSの現在の障害ステータスを確認するには、「AWS Health Dashboard」を用います。AWS Health Dashboardは、世界中のAWSサービスの稼働状況をリアルタイムで報告します。最新の健全性ステータスを表示するとともに、過去12か月間のサービス稼働履歴を確認することができます。
ここでは、AWS Health Dashboardを使って障害ステータスを確認する方法について解説していきます。
【参考】：AWS Docs: AWS Health のドキュメント 【参考】：AWS Docs: AWS Health の概要 【参考】：AWS Docs: AWS Health ダッシュボード — サービスの状態
AWSのサービスの状態を確認する
AWSのサービスの状態を確認するには、「AWS Health Dashboard」で「サービスの状態」を開きます。ここでは、AWSに発生した広域の問題を、地域別、サービス別に確認することができます。
もし、未解決の問題があれば、ここに表示がされます。過去の履歴も残っており、確認することができます。
【参考】：AWS: サービスの状態
アカウントの状態を確認する
アカウントの状態を確認するには、「AWS Health Dashboard」で「アカウントの状態」を開きます。アカウントや組織に影響するイベントが表示されます。この場合も、未解決の問題と最近の問題、スケジュールされた変更などが、イベント、影響を受けるリソースとともに表示されます。
【参考】：AWS Health Dashboard: アカウントの状態
Xの情報を確認する
各クラウドサービス事業者は、X（旧Twitter）を通じて公式情報を発信しています。最新の情報を手に入れるには、手っ取り早い方法です。
【参考】：X: AWS公式 アマゾン ウェブ サービス ジャパン
ところが、障害情報となるとなかなか公式サイトでは情報が公開されません。非公式ながら、Xのawsstatusjp_allが全リージョンの障害情報、awsstatusjpが国内リージョンに関連する障害情報を提供しています。合わせてGCP、Azure、GitHubの情報も提供しています。
非公式サイトの情報ですので、これらを参考にしつつ最終的には公式サイトの情報で確認するのが良いでしょう。
【参考】：X: AWS障害情報(国内リージョン関連のみ) 【参考】：X: AWS障害情報(全リージョン) 【参考】：X: GCP障害情報(全リージョン) 【参考】：X: Azure障害情報(全リージョン) 【参考】：X: GitHub障害情報
障害に強い仕組みを作るには
障害に強い仕組みを作るために、AWSでは「AWS Well-Architected」の設計手法を推奨しています。システムはどんなものでも永久に動作し続けるわけではありませんので、何らかの問題が生じた場合でも堅牢性を高めておく必要があります。
強固なシステムをつくるためには、アーキテクチャを評価して高い安全性、性能、障害耐性、効率性を高めておくべきです。障害発生を想定して、フェイルオーバーやMulti-AZ構成などを検討しておくと良いでしょう。
【参考】：AWS Well-Architected
AWSの障害にも強いアーキテクチャを導入しましょう
単一のアベイラビリティゾーンにサービスを集中させたり、冗長化を検討しなかったりすると事例にある東京リージョンのような障害が発生した場合は、ひとたまりもありません。そのため、サービスの分散化や冗長化など、多くのリスクを検討し、事前に対策しておくと良いでしょう。
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから
