AWSの大規模障害とは？過去事例と今からできる対処法を徹底解説！
AWSは世界各国で数百万以上､日本でも数十万を超えるユーザーが利用するクラウドサービスです。国内の多くの企業が提供するサービスや金融・行政機関のシステムにも、広く導入されています。そのAWSで大規模な障害が発生した事例は過去に数度存在し、いずれも広範囲に影響を及ぼしました。
「AWSで大規模障害が起こるとどんなことになる？」
「過去のAWSの大規模障害にはどんな事例がある？」
「大規模障害に備えるにはどんな対策が必要？」
こういった疑問に答えるため、本記事ではAWSの大規模障害の概要、過去の大規模障害の事例、大規模障害が発生する原因、発生する影響、障害の対策を解説していきます。
AWSを導入していて、大規模障害の事例について知りたいという方は、この記事を読めばAWSの障害に関する網羅的な知識を得ることができます。大規模障害の事例をもとに原因や対策を理解して、今後のAWS利用に役立てましょう。
AWSで発生する大規模障害とは
AWSの障害は、AWS側で管理しているネットワークやハードウェアに何かしらの要因で故障やトラブルがあった場合に発生します。AWSは高い可用性を保証しており、想定されるあらゆる障害に対応できるよう対策が施されています。しかし、インターネット上のシステムである以上はさまざまな要因で障害が発生するのが前提です。AWSの障害管理に関するドキュメントでも、冒頭で以下のように記述されています。
障害は発生するものであり、最終的にはすべてが時間の経過とともにフェイルオーバーします。つまり、ルーターからハードディスクまで、TCP パケットを破壊するオペレーティングシステムからメモリユニットまで、そして一時的なエラーから永続的な障害まで、どれもが対象となるのです。これは、最高品質のハードウェアを使用しているか、最低料金のコンポーネントを使用しているかにかかわらず、当たり前のことです – Werner Vogels、CTO – Amazon.com
ー引用元：AWS Well-Architected フレームワーク「信頼性の柱障害管理」
大規模障害はこのAWSの障害の中でも、とりわけ影響を及ぼした範囲が大きい場合の呼称です。複数のシステムが正常に使用できない状態となり、企業の提供するサービスも停止する場合があります。
実際に発生したAWSの大規模障害
ここからは実際に発生したAWSの大規模障害を、事例ごとに紹介していきます。いずれも影響範囲が大きく、IT関連メディアで「大規模障害」として報じられた事例です。
また、紹介する事例のほとんどは、日本企業の使用するサービスに影響を及ぼしたか、東京リージョンで発生した大規模障害となっています。この記事を読む多くの方にとって、日本の東京リージョンの大規模障害が最も身近な事例ではないでしょうか。過去の事例を参考に、身近なシステムに起こりうる大規模障害について考えてみましょう。
2023年6月：AWS Lambda の潜在的トラブル
この事例は北バージニア（US-EAST-1）リージョンで発生した大規模障害です。
北バージニア（US-EAST-1）リージョンでは、AWSにおいて基礎的な操作やサービスの実行・命令を行うためのサービスが稼働しています。そのため利用しているシステムが設置されているリージョンでなくても、障害による影響が発生しうるリージョンです。実際にこの事例でも、国内に影響が及んでいます。
2023年6月13日に北バージニアリージョンで、AWS Lambda の関数呼び出しについて、エラー率とレイテンシーが増加しました。結果、Lambda と連携していた他のAWSサービスでも、エラー率・レイテンシーが増加しました。Lambda側にはトラフィックの増加に伴い、自動的に追加のコンピューティング容量を確保する機能が存在します。しかし、この事例では到達したことのない容量しきい値を超過したことで、潜在的なソフトウェア欠陥が引き起こされたことが原因と発表されています。
この障害でニューヨーク地下鉄や米新聞ボストン・グローブのホームページに影響が出た他、日本国内でもスマート家電の動作に影響があり「家の証明がつかない」といった声が挙がりました。
約4時間後に影響を受けた全てのサービスで、完全な回復が確認されています。
2021年9月：ネットワークデバイスの異常
こちらは東京リージョンで発生した大規模障害の事例です。
2021年9月2日に東京リージョンで、AWS Direct Connect上の接続トラブルとパケットロスが発生しました。顧客のVirtual Private Cloud（VPC）が存在する東京リージョンのデータセンターネットワークへのパス上で、ネットワークデバイスの一部に障害が発生したことが原因と発表されています。
この障害で銀行系スマホアプリや電子決済サービスの他、航空会社のチェックインシステムに障害が発生しました。
約6時間後にAWS Direct Connectの動作が復旧し、通常の動作に戻りました。
2019年8月：空調設備システムの異常
こちらも前項と同様に、東京リージョンで発生した大規模障害の事例です。
2019年8月23日に東京リージョンの単一のアベイラビリティゾーンで、オーバーヒートにより一部のEC2サーバーが停止しました。原因は該当のアベイラビリティゾーンの空調設備管理システムの障害でした。冷却に使用する空調設備が機能せず、オーバーヒートにつながったと報告されています。
この障害では郵便局や一部のショッピングサイトの他、電子決済サービスなども利用システムが停止する事態となりました。
約3時間後に冷却装置が復旧し、障害発生から約6時間後に大部分のEC2インスタンスとEBSボリュームが復旧しました。
2016年6月：停電によるシャットダウン
この事例はシドニーリージョンで発生した大規模障害です。日本国内のサービスに影響があったという報告は特にありません。しかし後述する大規模障害の原因のうち、国内でも起こりうる「天災」による事例のため紹介します。
2016年6月4日にシドニーリージョンがある地域の悪天候によって、Amazonの電力会社が管理する変電所が停電しました。この影響でAWS関連施設への電力供給が完全に停止し、多数のインスタンスに影響が及びました。
本来であればAWSの施設は、複数の電源により冗長性を持っており、災害時に停電しても電源が維持されます。しかし、この大規模障害では公共電力に異常に長い電圧低下が発生し、正常に電源を切り替えることができませんでした。結果として、非常用の電源にアクセスできなかったインスタンスがシャットダウンしました。
公共電力は停電から約1時間20分後に、各種サービスのインスタンスはそこから約1時間の間に80%が自動的に復旧しました。一部のインスタンスは、AWSの対応チームが手動で復旧させたと報告されています。
大規模障害が発生する代表的な4つの原因
AWSで大規模障害が発生する原因は多岐に渡ります。とはいえ、それぞれの原因を分類すると、代表的な原因を絞って考え対策することが可能です。
ここからは、大規模障害が発生する原因として代表的なものを4つご紹介します。
人為的なミス
障害の一部は、人為的なミスによって発生します。原因となるミスはAWS側のチームメンバーによるものである場合と、システムを管理している利用者側によるものである場合がある点に注意が必要です。いずれの場合でも、多くのミスはシステムの構築やメンテナンスの際に発生します。例えば、システムのメンテナンス時に入力したコマンドの一部に誤りがあり、サーバーが停止した場合などがこのケースに該当します。大規模障害に関してはAWS側に起因する場合がほとんどです。
想定外の過負荷
システムの想定を超えた過負荷が掛かった場合にも、障害が発生します。AWSではオートスケーリングといった機能によって、過負荷対策が施されているのが基本です。しかしその対策による許容量を超えて過負荷があった場合、システムが対応しきれずエラーを起こしダウンする可能性があります。過負荷によって中断されたアクセスや処理は、システムの復旧後に修復できる場合とできない場合があります。このため大規模障害で広い影響範囲がこの状態となった際には、障害そのものの解決からシステムの復旧までに長時間を要することが見込まれます。
サーバー冷却装置の故障
2019年8月に東京リージョンで発生した事例の原因が、このサーバー冷却装置の故障でした。サーバールームには、高温となったサーバーを冷却するために必ず冷却装置が設置されています。その冷却装置が故障することでサーバーはオーバーヒートを起こし、正常に機能できなくなります。これによって引き起こされるのが、インスタンスの停止による大規模障害です。
AWSには責任共有モデルと呼ばれる、AWS側と利用者側で責任を共有する考え方がありますが、これによるとサーバー本体のようなハードウェアはAWS側の管理です。そのため冷却装置の故障に対して、利用者側でできる対策はリスク分散やバックアップとなります。
天災
2016年6月にシドニーリージョンで発生した事例の原因が、悪天候による停電でした。
リージョン単位の障害の原因となる天災は、悪天候の他にも地震や火災、洪水などが含まれます。サーバーそのものの損壊やシドニーリージョンのような停電によって、サーバーが機能できない状況に陥った場合に大規模障害につながります。
地域単位の災害による障害となるため、復旧に時間を要する場合がある点に注意が必要です。
大規模障害で発生する影響
大規模障害によって利用しているシステムや提供するサービスに影響が発生すれば、さまざまなビジネスリスクが発生します。想定される障害の影響を把握しておくことで、対策を検討して被害を最小限に抑えましょう。
システムにアクセスできなくなる
AWSで障害が発生しサーバーがダウンするかトラフィックが不通になった場合、システムへアクセスできなくなります。システムを利用していたアプリケーションなどがあれば、それらも稼働が停止します。
システムにアクセスできないのは、管理者だけでなくユーザーも同様です。AWSを利用したオンラインショップや予約サービスなどがアクセス不可となれば、そのダウンタイム分の損失が発生します。WEBサイトが表示されない、決済が利用できないといった状態が長引かないように対策が必要です。
データが破損・消失する
AWSの障害が発生した際にデータの送受信や保存が行われていた場合、完了前のデータが破損する恐れがあります。障害から復旧しても発生前の状態に戻せず、大規模なロールバック（データの巻き戻し）が発生すると、膨大な対応工数が発生します。運が悪ければデータ自体が消失して、復元できない状態となる可能性もあるため対策が必須です。定期的なバックアップを外部に保管して、復元が可能な状態を保ちましょう。
データを保存するデータベースに障害があり、一時的にデータが参照できなくなっているパターンもあります。この場合、表示できないだけでデータ自体は消失していないため、焦ってロールバックや復元を進めないように注意が必要です。原因の切り分けと確認を行ってから、対応を進めましょう。
顧客からの評価が下がる
顧客が利用するシステムやアプリケーションが停止すれば、顧客からの評価が下がる可能性があります。特に対象となる顧客が企業で、業務に利用するシステムを提供している場合に注意が必要です。設計や要件定義の段階で、顧客とダウンタイムの取り決めをしていても、実際に発生すれば早急な回復が求められます。ダウンタイムが長引けば、顧客の業務やビジネスそのものに影響が出てしまい、悪い評価へとつながります。長期的に築いてきた評価やイメージが悪くなれば、その後の自社の信頼性にも悪影響です。
顧客の離脱や企業価値低下を防ぐために、事前の対策と発生時の迅速な対応が求められます。
復旧や経過観察にコストが生じる
実際に障害が発生した際、復旧対応は急務です。担当者がシステムの状態を確認し、原因の切り分けと対策を講じるのには、当然人件費が発生します。また、障害の発生が営業時間内とは限りません。営業時間外に長時間の対応を必要とする場合もあります。
また、本格的な復旧に専門家の協力や外部の診断を経る必要があるケースもあり、それらのコストも考慮しなくてはなりません。
復旧後もデータの修復や設計の見直しにコストが発生し、継続してシステム監視も必要です。システムが完全に復旧したといえる段階まで、大きなコストが発生すると考えた方が良いでしょう。
AWSの障害対策5選
AWSの大規模障害は利用者であるこちらに原因が無くても、発生する可能性があります。そのことを前提として、発生した場合でも可能な限り提供するサービスやシステムが停止しないように対策を取らなければなりません。
ここからは主な障害対策として有効なものを5つピックアップして紹介していきます。
サービスやシステムの可用性を高めるために、以下を参考に障害対策を見直してみましょう。
障害を前提に設計する（Design for Failure）
前述の通りAWSの障害は、「発生するもの」として考えるべき課題です。そこで、障害を前提に設計をすることで被害を最小限に抑える方法が対策として有効です。AWSのベストプラクティスにおいても、システムの稼働が常に継続できる高い可用性を備えた構成が推奨されています。ここでいう「高い可用性」は、システムに障害が生じにくく、発生してもダウンタイムの短い状態を意味する表現です。
具体的にはインスタンスの冗長化や、複数のアベイラビリティゾーンにまたがった構成によって高可用性を実現します。AWSの一部がダウンしても、稼働し続けられるシステムを設計しましょう。
リスク分散を考慮して運用する
構築するシステムを1つのアベイラビリティゾーンやVPCにまとめると、そのゾーンがダウンした時点でシステムが停止してしまいます。そこでシステム内のリソースを複数のアベイラビリティゾーンに分散配置するなど、リスク分散を考慮して設計・運用する対策が重要です。
ただし、一部のリージョンに障害が発生した場合、アベイラビリティゾーンを分けていてもバックアップごと利用できなくなる可能性があります。そこで、S3やEBSなどに保存されたデータのバックアップ先に別のリージョンを選ぶ方法も有効です。この方法であればリージョン単位の障害にあっても、バックアップしたデータからすぐに復旧が可能になります。
障害発生に対応するための設定を行う
AWS上の障害発生を常に監視するために人的リソースを割くのは現実的ではありません。そこで、AWSのリソースを監視できるサービスを利用して、監視および異常発生時の通知を行えるよう設定をしておきましょう。
具体的に利用できるサービスとして「Amazon CloudWatch」「Amazon Simple Notification Service（Amazon SNS）」があります。
Amazon CloudWatch は、AWS上のリソースをリアルタイムで監視してメトリクスを収集できるサービスです。特定のサービスやメトリクスの動きに対して基準となるしきい値を設定すれば、そこを超過した時に通知を送信できます。例えば、システムに利用しているEC2インスタンスのCPU使用率が80％を超えたときに通知を出せば、過負荷を確認して追加のインスタンスを起動するか検討できます。この通知に使うサービスが、Amazon SNSです。
詳細設計の段階で異常検知用にこれらを導入して、障害に迅速に対応できるようにしておきましょう。また、これらの設定は必ず設計書や仕様書に記載を残すことをおすすめします。後からCloudWatch上の設定だけ見た場合に「何を通知しているのか」がわかりづらいケースがあり、担当者が変わると混乱を招くケースがあるためです。
障害発生試験を行う
障害が発生した際に迅速な対応ができるように、定期的に障害発生試験を行うのが対策として有効です。システムの構造に合わせた障害のシナリオを用意して、実際に対応を確認したり、復旧手順のテストを行います。
AWSでは障害発生試験に利用できるサービスとしてAWS Fault Injection Service (AWS FIS) があります。このサービスでは、EC2インスタンスの停止やRDS（データベース）の再起動など、いくつかの障害を疑似的に起こすことができます。障害発生に対するシステムの動きや応答を確認しつつ、担当者の訓練も実施することが可能です。
火災に備えた避難訓練のイメージで、定期的に担当する部署やチームで実施しましょう。
障害に関する情報を定期的に集める
障害に早期に対応するための方法として、定期的に障害情報を収集するのが有効です。障害情報の収集にはいくつかの方法があります。
主な方法は以下の通りです。
①AWS Health Dashboard
AWS Health Dashboard は、AWS上のすべてのサービスのリアルタイムな状態を確認できるサービスです。発生している障害情報が表示されるほか、過去12か月間のサービス中断も確認できます。
利用しているサービスにしぼった確認やフィルタリング機能もあるため、必要な範囲に応じてサービスの状態を確認したい時に有用です。
②Post-Event Summary
AWS公式から提供されている大規模障害のサマリーです。大規模障害のあとに詳しい発生時刻や原因、経緯や解決の流れが詳細に記載されています。
欠点として、問題の解決後に公開される情報である点が挙げられます。リアルタイムに発生している障害を確認する方法にはならないため、過去にあった障害の事例を参考にしたい場合や、障害が解消されたことの再確認に利用しましょう。
③Downdetector
サードパーティーではありますが、幅広いサービスの障害情報を収集・提供しているサービスです。世界中の数千のサービスの状況を、リアルタイムに取得できます。AWSの他に、Microsoft365やGoogle、国内の各種携帯キャリア、金融機関などのオンラインサービスが確認可能です。
SNSと個人からの報告を自動的に収集することで障害を判断する仕組みとなっています。これにより迅速な情報が届く一方で、誤検知が含まれる可能性があるのが欠点です。
まとめ
AWSの大規模障害は発生すれば影響範囲が広いため、システムやサービスにAWSを利用している企業は原因や過去の事例を把握しておかなくてはなりません。特に東京リージョンで大規模障害が発生すれば、大きなビジネスリスクです。前もって対策を行い、リスクを最小限とすることが望ましい運用と言えるでしょう。
本記事では、AWSの大規模障害の概要、過去の大規模障害の事例、大規模障害が発生する原因、発生する影響、障害の対策について解説してきました。
今後AWSの大規模障害に備える上で、この記事がご覧になったあなたの参考になれば幸いです。
この記事をシェア
