クラウドコンピューティングと災害復旧：ハイパースケーラーの隠れたリスク

2025年10月20日深夜、AWSの最重要リージョンであるUS East-1が停止し、インターネットの半分のサービスがダウンしました。DynamoDBにおけるDNS競合状態が引き金となり、EC2インスタンスの障害、S3バケットへのアクセス不能、広範なサービス停止へと拡大しました。SnapchatやAsanaといったアプリはもちろん、一部の銀行システムや政府システムまでもが、約15時間にわたり機能停止に陥った。大小さまざまな企業が生産性、収益、顧客の信頼を失いました。

AWSは最終的に問題を「修正」したが、被害は既に発生していました。IT部門、自動化チーム、事業継続チームにとって、これは単なる一時的な障害ではなかった。システム的なリスクに対する警鐘でした。

その9日後、世界第2位のクラウドプロバイダーであるAzureも重大な障害に見舞われた。今度は別の人的ミス（設定変更とも呼ばれる）が原因で、Microsoft 365、Xbox、主要航空会社のチェックインポータルを含むサービスが停止しまた。

結局のところ、最も成熟したグローバルハイパースケーラーであるAWSとAzureでさえ数時間に及ぶサービス停止が発生するならば、それらに依存する我々にとってそれは何を意味するのか？

この一連の出来事から得られた一つの良い点は、長年続いてきた災害復旧に関するいくつかの神話が、ついに終焉を迎えたことです。

神話その1：マルチAZは「十分」である

AWSのスナップショットとS3バックアップは、複数のアベイラビリティゾーン（AZ）に複製され、最大99.99999%の信頼性を実現するため、高い耐久性を備えています。これは素晴らしいことですが、多くの組織は、単一リージョン内のAZにワークロードを分散させるだけで耐障害性が確保されると考えていました。

East-1の障害は、この考えが誤りであることを証明しました。リージョン全体が障害を起こすと、その内部のすべてのAZが停止し、最善のアーキテクチャで構築されたデプロイメントでさえも到達不能になります。

複数のAZにまたがるスナップショットとS3バックアップの使用は依然としてベストプラクティスですが、それは解決策の一部に過ぎません。真の保護には、リージョン災害から守るためのリージョン間およびアカウント間のレプリケーションが必要です。

神話その2：DR（災害復旧）の見直し時期——マルチクラウドが答え

大規模なシステム障害のたびに、反射的な反応はいつも同じです：「すべてを再構築しよう。マルチクラウドに移行する時だ」と

確かに、それは魅力的に思える。復旧作業の約80％は単純で、削除された数ファイルや主要インスタンスの復元です。こうした作業は手動またはサードパーティツールで対応できる。しかし10月20日の事象は、全てが同時に機能停止した際の手動復旧がいかに脆弱かを露呈しました。

現実問題として、マルチクラウドバックアップやクロスクラウドDRは即効性のある解決策ではない。複数のコンソール管理、急峻な学習曲線、新たなコンプライアンス監査、予測不能なデータ転送コストなど、膨大な複雑性を伴います。

より賢明で実用的なアプローチは、現在のクラウド環境を維持しつつ、クロスリージョンレプリケーション（リージョン全体の障害対策）とクロスアカウントDR（マルウェアやランサムウェア対策）で戦略を強化することです。これは多くのチームが認識している以上にシンプルで制御しやすく、はるかに費用対効果が高い手法です。同時に、大規模なリージョン障害時でもデータとワークロードの可用性を維持できます。

神話その3：クロスリージョンおよびクロスアカウントDRは高すぎる

ITチームが複製レイヤーの追加を躊躇する最大の理由はコストでしょう。

しかしクロスリージョンDRはクラウド費用を倍増させるわけではありません。ITチームは利益重視のCFOや経営陣にこの点を明確に伝える必要があります。増分バックアップと階層型ストレージ（例：AWS S3 Glacier、AWS Intelligent-Tiering、Azure Blob）を活用することで、クロスリージョンDRのコストは通常、クラウド総支出のわずか5～15%に収まります。

これは、グローバルSaaSアプリケーション、銀行システム、または重要なビジネスサービスにおいて、たった1時間のダウンタイムが発生した場合の損失額と比較すれば、誤差の範囲に過ぎません。

神話その4：SaaS型DRツールが救ってくれる

AWSの障害発生時、多くのチームは直感的にSaaS型災害復旧ツールにログインし、システムの復旧を開始しました。しかし問題は？そのSaaSツール自体もダウンしていたのです。DRソリューションが同じ外部インフラに依存している場合、地域的な障害が発生すると無力化されてしまいます。

これが、Infrastructure-as-a-Service（IaaS）DRツールが不可欠な理由です。バックアップサーバーが自社環境に設置され、すべてのバックアップに直接アクセスできる場合、外部サービスへの依存は発生しません。他者のシステムが復旧するのを待つことなく、いつでもあらゆるものを復元できます。復旧ツールは、必要な時にいつでも利用可能です。

神話その5：DR計画の構築には数か月が必要

インフラ全体を一から作り直す必要はありません。停電時にパニックに陥った企業もあれば、そうならなかった企業も多数存在します。その違いは？冷静さを保った企業は、地域別の復旧手順書を用意していました。重要なデータは自動的に地域やアカウント間で複製されており、停電が発生した際には単に計画を実行しただけです。

すぐに実践できる4つの具体的な手順：

1.退屈になるまでテストする。15分で復旧した企業は必ずしも最も洗練されていたわけではない——単に最も準備が整っていただけだ。筋肉記憶が確立されていたからこそ、迅速に復旧できたのである。

2. SaaSではなくIaaSベースのDRツールを活用する。これにより、復旧インフラが障害発生地域に依存しなくなる。

3. ネットワークスタック全体を復旧対象とする。サーバーの性能は接続する仮想ケーブルの性能に依存する。サブネット、ルーティングテーブル、セキュリティグループ、ロードバランサーなど、基本的に全てのネットワーク設定を複製・準備しておくことで、設定エラーによるフェイルオーバーの停滞を防ぐ。

5. テストを自動化する。リソースを優先順位付けし、訓練をスケジュールし、成功の完全な可視化のためのレポートを生成するDR訓練とテストツールを活用する。

障害発生後の実践的な教訓

クラウドバックアップと災害復旧は、近所の道路が舗装工事中だと考えてみてください。工事で一時的に道路が封鎖された場合、わざわざ迂回路を新設する必要があるでしょうか？ それとも、車両が通行できる明確な経路を確保し、交通が迅速に再開される保証さえあれば十分ではないでしょうか。

AWSの障害は偶然ではない。ハイパースケーラーの利便性にはシステム的な脆弱性が伴うという事実を改めて認識させる出来事だった。結局のところ、回復力の責任はプロバイダーではなくあなた自身にある。問題はAWSやAzure、GCPが障害を起こすかどうかではなく、障害発生時に15時間も待てる余裕が自社にあるかどうかだ。

編集後記

Azure対応　移行・連携・データ保護 特集ページ

AWS対応　移行・データ保護 特集ページ

関連トピックス:

• VMware の障害復旧機能[HA(High Availability)、FT(Fault Tolerance)]の概要
• クロスクラウド・ディザスターリカバリー(DR)： クラウドコンピューティングの新時代
• 究極の災害復旧でのチェックリスト10ステップ
• VMware HAクラスタのホスト障害時の状況を簡単にシミュレーション
• Windowsストレージ・スペース(Storage Spaces):Windows Server用シンプロビジョニング
• CDP(Continuous Data Protection)について
• DynamoDBのバックアップと復元のための8つのベストプラクティス
• RAID5やRAID6はストレージのパフォーマンスと容量にどのような影響を与えるか