Google Cloud は 10 月 22 日、ステータスページで europe-west2（ロンドン）リージョンの障害に関する暫定報告を公開しました。障害は米国太平洋時間 10 月 19 日 23:00（英国夏時間 10 月 20 日 07:00）から米国太平洋時間 10 月 20 日 05:10（英国夏時間 13:10）まで、合計 6 時間 10 分続きました。当社のノードは欧州にはありませんが、この報告書は見落とされがちな点、つまり 1 つのリージョン内の「複数のアベイラビリティゾーン」で何を守れて何を守れないのかを、はっきり示しています。
経緯：電力網の途絶からゾーン全体の停電まで
- 米国太平洋時間 22:53（英国夏時間 06:53）、アベイラビリティゾーン europe-west2-b を収容する施設で電力網の途絶が発生しました。設計どおり負荷は UPS のバッテリーに移り、同時に構内のディーゼル発電機が起動手順に入りました。
- 発電機を制御する PLC（プログラマブルロジックコントローラー）は、主系・予備系とも自動起動と切り替えを開始できず、発電機が負荷を引き受けることはありませんでした。23:00 から UPS のバッテリーが尽き始め、このゾーンの物理サーバー、ネットワークスイッチ、ローカルストレージが電源を失いました。
- 電力網からの供給が戻ると、現地のエンジニアは 1 時間以内に安定した商用電源を復旧し、その後、発電機の自動制御装置をリセットしてテストしました。Google はインフラを段階的に再起動し、ゾーン b へのトラフィックを少しずつ戻しました。
- 大半のサービスは最初の 5 時間 29 分（英国夏時間 12:29 まで）で回復しました。Compute Engine は回復に時間がかかり、新しい VM の作成が再開したのは 12:46、13:10 には 99% を超える VM が正常な状態に戻りました。
電源を失っていないゾーン a と c まで影響を受けた理由
報告書は 2 つの原因を挙げています。1 つ目は、ゾーン b のワークロードがゾーン a と c に殺到して残りの容量を使い果たしたことで、キュー待ち、データベースのフェイルオーバーの遅延、断続的な 500 / 503 エラーが発生しました。2 つ目は、一部のサービスのコントロールプレーンがゾーンをまたいだ同期的な検証を行っていたことで、その検証が依存するコンポーネントが電源を失ったゾーン b にあったため、API 呼び出しがタイムアウトしました。報告書が予期せぬ影響を受けたとして挙げた製品には、BigQuery、Looker、Compute Engine、GKE、リージョン Persistent Disk、Cloud SQL があります。ゾーン b だけに置かれていたリソースには、そもそもアクセスできませんでした。再発防止策を含む最終報告はまだ公開されていません。
もう一つ細かい点があります。当夜のステータスページの最初の更新では開始時刻が米国太平洋時間 23:08 とされていましたが、これは実際には Google の監視がアラートを出した時刻で、暫定報告では 23:00 を開始としています。クラウド事業者のステータスページを読むときは、最初のいくつかの更新が後の報告で訂正されることを想定しておきましょう。
VPS 1 台、あるいは数台の運用に生かせること
- バックアップは別の地域に置く。同じ施設や同じリージョンにあるバックアップは、施設全体が停電すると元のデータと一緒にアクセスできなくなります。VPS のバックアップ方法を参照してください。
- 重要なサービスには 2 つ目の地域にもマシンを用意する。小さなコールドスタンバイでも構いません。DNS レコードの TTL を短くしておけば、何かあったときに切り替えられます。DNS 入門と低遅延のデータセンターノードの選び方を参照してください。
- 依存関係を書き出す。ゾーン a と c が問題を起こしたのは、依存していたものがゾーン b にあったからです。自分のサービスの依存関係の洗い出し方は2026 年上半期の障害の主役は「依存リスク」を、9 月末の Azure の 2 件の障害についてはその振り返りのまとめをご覧ください。
2026 年 11 月 7 日追記：Google Cloud は 11 月 4 日に最終的なインシデント報告を公開しました。主な影響は 6 時間 8 分とされ、発電機が起動しなかったのは、保守中で商用電源が 1 系統だけになっていたうえ、制御装置の電圧低下の検知がもう一方の系統の開いた遮断器の上流にあり、健全な電源があると判断したためでした。詳しくは続報をご覧ください。