Google Cloud ロンドンゾーンで大規模障害が発生
2026年10月20日午前6時8分（UTC）より、Google Cloudのロンドンリージョン「europe-west2」の可用性ゾーンの一つである「europe-west-2-b」で大規模なサービス中断が発生しています。この障害は西ヨーロッパ全域のGoogle Cloudユーザーに影響を及ぼしており、現時点では復旧の目処が立っていません（The Register）。
Google Cloudのステータスページによると、「europe-west2リージョンで複数のGoogle Cloudサービスがエラーの増加と断続的なネットワーク障害を経験しています」とのことです。
本来、可用性ゾーンはハードウェア障害やリージョン全体の障害からサービスを保護するために設計されていますが、今回のケースでは単一ゾーンの障害が広範囲な影響を及ぼしています。これは、高可用性設計の重要性を改めて浮き彫りにする事象だと感じます。
影響を受ける主要サービスと顧客
Google Cloudが影響を認めているサービスは以下の通りです（The Register）。
- BigQuery Data TransferService
- Cloud Filestore
- Cloud Run
- Google App Engine
- Google Cloud NetApp Volumes
- Google Kubernetes Engine (GKE)
- Managed Service for Apache Kafka
また、今回の障害は多数の企業に波及しており、Lloyds Bank、HSBC、Royal Mail、Revolutなどの金融機関や物流企業が影響を受けていると報告されています（Down Detector）。Revolutは、顧客の資金やデータは安全であることを確認しつつ、サービスの中断について謝罪しています（Revolut Xアカウント）。
RedditなどのSNSでは、「単一ゾーンが停止し、HA（高可用性）ではないサービスが影響を受けている典型的なケースだ」といったコメントが見られます（Reddit）。
Google Cloudの対応と推奨される回避策
Google Cloudのエンジニアリングチームは問題の調査を継続しており、影響を受けた顧客に対しては謝罪を表明しています。当初、Googleは回避策はないとしていましたが、後にステータスページを更新し、「もし可能であれば、影響を受けているワークロードを別の利用可能なロケーションに移行する」ことを推奨しました（The Register）。
しかし、広範囲に影響が及んでいる中で、迅速なワークロード移行がどこまで現実的かは疑問が残ります。特に、データベースなどのステートフルなサービスを別のリージョンやゾーンに移行するのは、短時間では難しい作業だと考えられます。
エンジニア目線で見ると：単一障害点対策の重要性とCloud Runの分散性
今回のGoogle Cloudロンドンゾーンの障害は、クラウドサービスにおける単一障害点（Single Point of Failure: SPOF）対策の重要性を改めて浮き彫りにしました。通常、複数のアベイラビリティゾーンに分散してデプロイすることで高可用性を確保しますが、今回のケースでは「europe-west-2-b」ゾーン内のサービスが広範囲に影響を受けているため、ゾーンレベルでの障害耐性設計が不十分だった可能性も考えられます。特に、GKEやBigQuery Data TransferServiceなどが影響を受けていることから、コントロールプレーンや内部ネットワークインフラに問題があったのかもしれないと感じます。
自分の個人プロダクトでもCloud Runをよく使っていますが、Cloud Runは自動的に複数のゾーンに分散配置されるはずなので、この障害で「Cloud Runが影響を受けている」というのは少し意外に感じました。もしCloud Runのコントロールプレーンや、特定のデータプレーンに集中する問題だとすれば、Cloud Runの分散性の恩恵を受けにくいケースも存在する、ということではないでしょうか。今後の公式発表で詳しい原因が明らかになることを注視したいです。
また、異なるリージョンへのフェイルオーバー戦略が迅速に実行できるか、定期的なDR（災害復旧）テストの重要性を再認識させられました。Pythonで書かれた自作スクリプトを動かしているCloud Runサービスも、念のため別リージョンへのデプロイを検討してみたくなります。
