Google CloudのDR用ストレッチクラスタが障害点になった一夜

このインシデントの舞台はGoogle Cloud VMware Engine（GCVE、Google Cloud上でVMware vSphere基盤をマネージドサービスとして提供する仕組み）。影響を受けたのは、DR（Disaster Recovery、災害復旧。ある拠点が止まっても別拠点で処理を継続する仕組み）目的でストレッチクラスタ（複数のアベイラビリティーゾーンにまたがる単一の仮想化クラスタ構成）を組んでいた運用チームだ。2026年7月14日から15日にかけて、シドニー（australia-southeast1）、メルボルン（australia-southeast2）、フランクフルト（europe-west3）の3リージョンで、Googleが実施したゾーン間ネットワークの設定更新が引き金となり、各リージョンのストレッチクラスタでゾーン間通信が分断された[1][2]。コンピュートとストレージは正常に稼働し続けたが、対象サイトの仮想マシン（VM）には外部から到達できなくなった[1][3]。冗長化のために組んだ構成そのものが、設定変更の影響を受けて機能不全に陥った点が今回の核心である。VMware基盤をGoogle Cloud上で運用し、DRやマルチAZ構成を可用性設計の柱に据えているチームにとって、この事例は「冗長化した構成ほど設定変更の影響範囲が読みにくくなる」という逆説を突きつける。

予備知識

• GCVE（Google Cloud VMware Engine）: Google Cloud上でVMware vSphere環境をマネージドサービスとして提供する仕組み
• ストレッチクラスタ: 複数のアベイラビリティーゾーンにまたがって構成される単一の仮想化クラスタ
• DR（災害復旧）: 一部拠点が停止しても別拠点で処理を継続させるための設計・仕組み
• witnessアプライアンス: クラスタが分断した際にどちらのサイトを正系とするか判定する第三拠点の仲裁装置

クラウド／ネットワーク／障害

Cloudflare大西洋光ファイバー切断が示す「設定ミスではない障害」の教訓

2026年6月22日、CDN大手Cloudflareのネットワークが劣化し、X、Reddit、Microsoft Teams、Zoomなど数多くのサービスで遅延やタイムアウトが発生した[1][2]。原因は設定変更のミスではなく、北米[…]

GCVEのストレッチクラスタで何が起きたのか

2026年7月14日、Googleが実施したGCVEのゾーン間ネットワーク設定更新が、シドニー・メルボルン・フランクフルトの3リージョンでそれぞれ稼働していたストレッチクラスタの通信を分断した。障害は米国太平洋時間7月14日午前10時ごろ（日本時間15日午前2時ごろ）に発生し、公開インシデントとして状況が報告されたのは同日午後1時24分ごろ（日本時間同日午前5時24分ごろ）だった[1][2]。復旧が確認されたのは協定世界時7月15日午前4時46分（日本時間同日午後1時46分）で、発生から復旧まで約11時間46分を要した[3][4]。この間、コンピュートとストレージそのものは稼働を続け、VM自体も停止していなかった。ゾーン間の通信が失われた結果、影響を受けたサイトのVMには外部から到達できず、書き込み可能なデータへのアクセスも失われた[1][4]。ストレッチクラスタを組んでいない単体ゾーン構成のGCVE環境は、この障害の影響を受けていない[1]。

クラウド／障害

Azure OpenAI障害が示すリトライ増幅の落とし穴

Azure OpenAI Service（マイクロソフトのクラウド上でOpenAI系モデルを推論APIとして提供するPaaS層のAIサービス）で、2026年5月29日、欧州のスウェーデン中部と豪州東部を中心に約7時間45分にわたる障[…]

原因はどこにあったのか

原因は、Googleがゾーン間ネットワークに適用した設定更新にある。この一文が今回の障害の全体像を要約している。更新によりゾーン間の通信で断続的な障害が生じ、BGP（Border Gateway Protocol、経路情報を交換するルーティングプロトコル）セッションのフラッピング（接続の確立と切断を短時間で繰り返す不安定な状態）が発生した[4]。あわせて、クラスタとwitnessアプライアンスとの間のネットワーク接続も失われた[3][4]。witnessアプライアンスは、2つのゾーン間の通信が途切れた際にどちらのサイトを正系として扱うか判定する第三拠点の仲裁役を担う。この接続喪失により、ゾーン間の同期に問題が生じ、影響サイトのVMが孤立した[4]。Googleは原因を直近のネットワーク設定更新と特定し、最後に正常だった設定への切り戻し（ロールバック）によって障害を収束させた[1][2][3]。

障害

交渉最大の障害は「信頼の欠如」――プロスポーツ労使紛争に学ぶ克服法｜MBAファシリテーション＆ネゴシエーション Day6

MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]

検知から復旧までの時間軸を見る

障害発生から公開報告までに約3時間24分、報告から復旧完了までにさらに約8時間22分を要し、合計で約11時間46分の障害時間になった[3][4]。この内訳は、複数リージョンにまたがる分断状況の切り分けと、設定変更のロールバックという復旧手段の確定に時間がかかったことを示している。単一ゾーンの障害であれば、自動フェイルオーバーで数分から数十分程度に収まるケースもある。ストレッチクラスタは複数ゾーンにまたがる構成であるがゆえに、原因調査そのものが複雑になりやすい。障害発生がシドニー・メルボルン時間で深夜3時ごろだったことも、初動対応の速度に影響した可能性がある。

なぜストレッチクラスタが単一障害点になったのか

ストレッチクラスタはDRのために複数ゾーンへ可用性を分散させる構成だが、今回はそのゾーン間ネットワークという共有の依存関係が、逆に単一障害点になった。単体ゾーン構成であればゾーン間ネットワークに依存しないため、この種の設定変更の影響を受けない。ストレッチクラスタは可用性を高めるはずの設計でありながら、ゾーン間接続とwitnessという新たな依存を追加し、変更管理の対象範囲を広げてもいた。

表の最終行が示すとおり、可用性を高めるための構成が、変更管理の対象範囲としては最も脆い部分になっていた。冗長化された構成部分ほど、設定変更前の影響範囲確認とフォールバック検証を厚くする必要がある。

よくある質問（FAQ）

ストレッチクラスタとは何か

複数のアベイラビリティーゾーンにまたがって構成される単一の仮想化クラスタで、一方のゾーンが停止してももう一方で処理を継続できるよう設計された可用性向上の仕組みである。

今回の障害でデータは失われたか

報道されている範囲では、コンピュートとストレージのサービス自体は稼働を継続しており、データ喪失の報告はない。影響は主にゾーン間ネットワークの分断によるVMの到達不能と書き込み不可に限られる[1][4]。

同様の障害を防ぐには何をすればよいか

ゾーン間ネットワークやwitness接続など、DR構成が新たに追加する依存関係を洗い出したうえで、その経路が分断した場合のフォールバック手順を平常時に検証しておくことが有効である。設定変更の影響範囲評価には、冗長化構成そのものへの影響も含める必要がある。

まとめ

今回の障害の核心は、DRのために組んだストレッチクラスタが、ゾーン間ネットワークという共有依存を通じて自らを単一障害点にしてしまった点にある。コンピュートとストレージは正常でも、経路が一つ分断されただけでVMへの到達性が失われた。運用担当者は、DRやマルチAZ構成を導入する際、追加される依存関係（ゾーン間経路・witness接続など）を可用性設計の対象として洗い出し、その経路が分断した場合のフォールバック検証を平常時の運用計画に組み込む価値がある。冗長化は設定変更の影響範囲を単純化しない。むしろ広げる可能性がある前提で、変更管理のプロセスを見直す機会にしたい。

出典