2025年6月12日(米国時間)、Google Cloud Platform(GCP)で発生した大規模障害について、Googleは13日、詳細なインシデントレポートを公開しました。今回の障害は、GCPのみならず、Google Workspace、さらには一部のCloudflareサービスや他の外部プラットフォームにも影響を及ぼしました。
何が起きたのか?
障害は6月12日10:49(PDT)頃に発生。GoogleのAPI管理基盤である「Service Control」に関する不具合が原因で、APIリクエストが一斉に503エラーを返す事態に陥りました。
この不具合は、5月29日にService Controlへ追加された新機能が関係しており、特定のポリシーデータに空白フィールドが存在したことから、Service Controlのバイナリがクラッシュループに陥るという重大なエラーに繋がったと説明されています。
なぜ検知できなかったのか?
新機能はコード内に”レッドボタン”と呼ばれる緊急停止機能が用意されていたものの、フィーチャーフラグによる段階的展開や、エラー処理が不十分だったため、本番環境で初めてクラッシュが発生する結果となりました。
APIクォータポリシーの変更がSpannerテーブルに書き込まれた瞬間に、全世界のデータセンターへ同期され、Service Controlが全地域で順次クラッシュ。最大で3時間近く、複数サービスが利用不能となる前例のない障害となりました。
復旧まで経緯
インシデント発生から2分でSREチームが対応を開始、10分以内に原因が特定され、25分後にはレッドボタンが稼働。40分以内に多くのリージョンで復旧が始まりました。
ただし、us-central1(アイオワ)ではService ControlのリスタートがSpannerへの負荷集中を引き起こし、ランダムなエクスポネンシャルバックオフ処理が未実装だったことから復旧に約2時間40分を要しました。
システム障害の影響範囲
GCPではCompute Engine、Cloud SQL、BigQuery、Vertex AI、Cloud Storageなど基幹プロダクトを含む60を超えるサービスが影響を受けました。
また、Google Workspace製品でもGmail、Googleカレンダー、ドライブ、Meet、Chatなどが断続的にエラーを返しました。外部ではCloudflare、Spotify、Discord、Snapchatなども影響を受け、障害は全世界的な広がりを見せました。
Googleの対応と今後の対策
Googleは、障害を受けて以下の改善計画を発表しました:
- Service Controlのアーキテクチャをモジュール化し、障害発生時でもAPIリクエストを処理可能に
- グローバル同期データの検証体制強化
- すべてのクリティカルバイナリにフィーチャーフラグの導入を義務化
- 無効データのエラー処理強化とテスト体制の見直し
- 全システムでランダムなバックオフ処理の導入
- 障害時でも機能する監視・通知インフラの整備
Cloudflareにも波及
Cloudflareも自身のWorkers KVがGoogle Cloudに依存していたため、構成・認証・配信に関する複数プロダクトで障害が発生。CloudflareはKVストレージのR2移行を計画しており、外部依存を減らす方針を表明しました。
総括
今回の障害は、クラウドサービスが広範にわたってインフラとして社会に浸透している現代において、単一システムの不具合がグローバルに波及するリスクを改めて示す出来事となりました。
Googleは「企業の信頼に応えられなかった」として深く謝罪するとともに、再発防止策とシステムの堅牢化を迅速に進める姿勢を打ち出しています。
クラウドを活用する企業にとっても、依存先の可視化、フェイルオーバー設計、マルチクラウド戦略の重要性が一層明確になったと言えるでしょう。
参照
https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW






