クラウド障害は避けられない それでも“事業を止めないシステム”を構築するには：IaaSの大規模障害の影響を抑えるには【後編】
ユーザー企業がどれだけ気を付けていても、クラウドサービスの障害は避けられない。クラウドサービスを利用中の企業が障害の影響を抑えるための事前準備として、何に取り組むべきなのか。
Amazon Web Services（AWS）は2025年10月20日（米国時間）に、米国のus-east-1リージョン（地域データセンター）を中心とした大規模障害を起こした。この障害によって、Snapのショート動画共有サービス「Snapchat」やZoom Video Communicationsの「Zoom」、McDonald'sのモバイル注文といったサービスが一時的に利用できなくなった。AWSを直接契約していないが、AWSインフラで稼働するAPIや決済システムなどを利用中の企業にも影響を及ぼした。
こうした大規模障害のリスクを抱えているのはAWSだけではない。世界のクラウド市場は主にAWSとMicrosoft、Googleが主導しており、これらのサービスで障害が発生すると世界中のシステムに影響が及ぶ可能性がある。専門家が推奨する対策とは。
ベンダーロックインのリスク
併せて読みたいお薦め記事
連載：IaaSの大規模障害の影響を抑えるには
AWSの大規模システム障害の原因と影響
ベンダーロックインは一般的に、単一ベンダーのサービスや技術を使うことで、専有APIや特有のデータフォーマットに依存することになり、スイッチングコスト（サービスを移行することに掛かるコスト）が上昇することや他ベンダーのサービスとの連携が難しくなることを指していた。しかし2025年10月のAWS障害はベンダーロックインの別の側面である、「信頼性の集中」によるリスクを明らかにした。単一ベンダーのクラウドサービスで社内システムの大部分をホストしている場合、そのベンダーの可用性が組織全体の可用性の上限となる。
「今回の障害で、AWSを使用していない企業でも、ソフトウェアの相互関係がいかに絡み合っているかを思い知らされた」と、調査会社Constellation Researchの副社長で主任アナリストであるチラグ・メータ氏は述べた。「間接的な依存関係にあるシステムでも、企業の事業停止を引き起こす可能性がある」と同氏は話す。
これは物理的なサプライチェーンが集中するリスクと類似している。単一の供給元に依存する製造業者は、その供給元が失敗すると生産停止に直面する。単一のクラウドインフラを利用する組織は、ベンダーで問題が生じ、データの流れが止まったときのサービスの中断に脆弱（ぜいじゃく）だ。
The Aspen Instituteでエグゼクティブ・ディレクターを務めるベッツィー・クーパー氏は次のように説明する。「企業はシステム障害に対して、原因が社内外のどちらで発生したのかが重要ではないことを認識する必要がある。重要なのは、どのように迅速に解決し、サービスを復旧させるかだ」
クラウドサービスの大規模障害に対処するための事前準備
AWSで2025年10月に発生した大規模障害は、クラウドのレジリエンス（回復力）を強化するには、ベンダーが提供する可用性に頼るのではなく、自社のITインフラの構成とガバナンスに関する慎重な意思決定が必要であることを明らかにした。ITリーダーは、クラウドサービスで自社のデータを扱うときに、以下の分野に取り組む必要がある。
可視性
組織は、重要なアプリケーションやSaaS（Software as a Service）の依存関係、使用中のクラウドサービスのリージョンをマッピングする必要がある。ITコンサルティング会社Northdoorでクラウドプラクティスリードを務めるドミニク・グリーン氏は、クラウドサービスや社外のサービスと自社のデータの相互関係を理解するために、データの流れのマッピングを徹底することが、サプライチェーンに隠された単一障害点を特定するために不可欠だと説明する。
メータ氏は可視性をソフトウェアの監査のための重要な要素と見なしている。「クラウドインフラに直接または間接的に関わる全ての重要なアプリケーションとデータフロー、他社が管理するサービスを特定することが重要だ」と同氏は述べる。
多様化
重要なシステムには、クラウドインフラの構築に複数のリージョンを組み合わせるマルチリージョンや、複数のクラウドサービスを組み合わせるマルチクラウド戦略を視野に入れる必要がある。コンサルティング会社FTI Consultingのサイバーセキュリティプラクティス部門でシニアマネージングディレクターを務めるトッド・レナー氏はITリーダーに対し、自社にとって重要なアプリケーションを特定し、複数のクラウドベンダーを利用して冗長性の確保やフェイルオーバー手法の実装を検討するよう提案している。
ガバナンス
クラウドサービスのリスク対策は、取締役会で取り上げる議題のレベルに引き上げるべきだとグリーン氏は話す。同氏は、取締役会に対して単一のサービスや場所への依存を減らすために、マルチリージョンまたはマルチクラウド戦略の実施を義務付け、定期的なフェイルオーバーテストを実施することを推奨している。
レナー氏は、経営層の関与の重要性を強調する。CEOや取締役会、場合によっては投資家に対し、単一のクラウドベンダーを使用するリスクと費用や、複数のクラウドベンダー、オンプレミスホスティング、複数のコロケーションの使用に関する情報を提供する必要があると述べている。
コミュニケーション
クラウドサービスをはじめとした利用中の社外システムの障害に備えて、危機対応プロトコル（手順）を策定することが重要だ。自社のシステムが停止した際に影響を受けた顧客向けのコミュニケーション手法や、システムのステータスの確認方法、ITベンダーの障害に対する責任範囲などを明確にする必要がある。
訓練
クラウドサービス障害に備えて問題への対処方法を準備したら、それをテストする。レナー氏は、架空のシナリオを使い、特定の問題にどう対処すべきかを議論するテーブルトップ演習（TTX：机上演習）を通して、リハーサルを実施することを勧めている。
クラウドインフラのレジリエンスを高める
クラウド市場はAWSとMicrosoft、Googleに需要が集中している。そのため、これからも一つのリージョンで発生した障害が複数のユーザー企業に同時に影響を与えることは免れないだろう。2025年10月のクラウド障害はAWSで発生したが、メータ氏はこれがAzureやGoogle Cloudでも同様に発生し得たと指摘する。
「教訓はクラウドを離れることではなく、失敗を前提に設計し、絶え間なくテストし、レジリエンスを取締役会レベルの議論にすることだ」とメータ氏は話す。障害は消え去ることはなく、将来的にも再び発生する可能性が高い。障害を防ぐことは貴重な目標であるが、レジリエンスを高めることはさらに重要だという。
「どのような準備を整えても、クラウドサービスの障害を必ず防ぐための合理的な方法はない。従ってユーザー企業は社外システムの障害に備えて、できるだけスムーズに事業を継続させるための計画を立てる必要がある」（クーパー氏）
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。