ハクソク

世界を動かす技術を、日本語で。

Google Cloud インシデントレポート – 2025年6月13日

2025年6月14日原文(status.cloud.google.com)

概要

  • 2025年6月12日、Google CloudおよびGoogle WorkspaceのAPIで 大規模な障害 が発生
  • 外部APIリクエスト で503エラーが増加し、グローバルに影響
  • 原因は Service Controlの新機能 におけるエラーハンドリング不足
  • us-central1 など一部リージョンでは復旧に時間を要した
  • Googleは 再発防止策 と詳細なインシデントレポートの公開を約束

2025年6月12日 Google Cloud 障害インシデント概要

  • 発生日時 ：2025年6月12日 10:49 PDT
  • 影響範囲 ：Google Cloud、Google Workspace、Google Security Operationsの多くのプロダクト
  • 主な症状 ：外部APIリクエストでの 503エラー増加、一部サービスのUIアクセス障害
  • 影響地域 ：グローバル（特にus-central1で長引く影響）

インシデントの原因

  • Service Control に新機能追加時、 適切なエラーハンドリング や フィーチャーフラグ が不十分
  • 無効なポリシーデータ （空欄フィールド含む）がSpannerテーブルに挿入され、グローバルに即時複製
  • nullポインタ例外 によりService Controlバイナリがクラッシュループ
  • エンジニアが2分以内にトリアージ、10分で原因特定、25分で「レッドボタン」による回避策展開
  • 復旧の遅れ ：us-central1ではService Control再起動による「ハード効果」でインフラ過負荷、完全復旧まで約2時間40分

影響サービス一覧（一部抜粋）

  • Google Cloud ：IAM, Cloud Build, KMS, Cloud Storage, BigQuery, Cloud Spanner, Cloud Functions, Cloud SQL, Cloud Logging, Cloud Monitoring, Vertex AI, Dataproc, Cloud Run, Cloud DNS, Cloud Pub/Sub, Cloud Composerなど
  • Google Workspace ：Gmail, Google Drive, Google Calendar, Google Meet, Google Docs, Google Chat, Google Voice, AppSheet, Google Tasks, Google Cloud Search
  • Google Security Operations ：全般

復旧状況と顧客影響

  • 既存のIaaS・ストリーミングリソース には影響なし
  • 大半のリージョンは 2時間以内に回復、us-central1は最大3時間
  • 一部サービスでは 1時間程度の残留影響、ごく一部はそれ以上

障害の技術的詳細

  • Service Control は各APIリクエストの認可・ポリシーチェック・クォータ確認を担当
  • 新機能追加 時のコードパスはローリングアウト中に発火せず、 本番ポリシー変更時に初めて障害発生
  • フィーチャーフラグ未活用 ・ エラーハンドリング未実装 が主因
  • ランダム化指数バックオフ 未実装により、再起動時にインフラ過負荷

今後の対応策

  • Service Controlのアーキテクチャをモジュール化 し、障害時もAPIリクエストをサービス可能に
  • グローバル複製データを消費する全システムの監査、段階的なレプリケーションと検証体制の強化
  • 重要バイナリのフィーチャーフラグ保護 とデフォルト無効化の徹底
  • 静的解析・テストの強化、エラー時はフェイルオープン設計へ
  • 指数バックオフの全システム適用、負荷集中の防止
  • 外部コミュニケーション体制の改善、主要な監視・通知基盤の冗長化

コミュニケーションと今後のレポート

  • Cloud Service Health への初報は障害発生約1時間後（自身の障害のため遅延）
  • 一部顧客の監視インフラも障害でダウン、インシデント認知遅延
  • 詳細なインシデントレポート を数日内に公開予定
  • 顧客は Google Cloud Support または Google Workspace Support 経由で個別問い合わせ可能

まとめと再発防止への誓約

  • 信頼回復と再発防止策の徹底
  • API管理基盤の堅牢化、異常データによるサービス停止の防止
  • メタデータのグローバル伝播前の検証・監視強化
  • 包括的なエラーハンドリングとテスト の拡充

Vertex AI Online Prediction 障害状況

  • 復旧完了 ：2025年6月12日 18:18 PDT時点で完全復旧
  • 一部リージョン（europe-west1, asia-southeast1） では復旧遅延、19:45 PDTまでに正常化見込み
  • 影響 ：Model Gardenの一部モデルで 5xxエラー増加
  • エンジニアによる段階的な復旧作業、残る影響はごく一部

Personalized Service Health／Cloud Dataflow 障害状況

  • Personalized Service Health ：復旧済み
  • Cloud Dataflow ：us-central1でのみバックログ遅延発生、順次解消中

顧客へのメッセージ

  • Google Cloudを信頼いただく全ての顧客 への深い謝罪
  • 今後数日以内に詳細な根本原因・対応策を公開
  • 影響が記載内容以外にも及ぶ場合 はサポート窓口へ連絡推奨

Hackerたちの意見

適切なエラーハンドリングがなかったせいで、ヌルポインタが原因でバイナリがクラッシュしたんだ。今頃はもう兆ドルのミスになってるよね？

└

今年のためにどれだけのSLAを作ったんだろうね。

└

そんなことを防げる言語があればいいのにね /s

グーグルのポストモーテムは本当に驚かされる。社内から外部まで見てきたけど、詳細さがすごいんだよね。問題は、彼らは絶対に同じミスを繰り返さないってこと。学んで、正しいプロトコルやエラーハンドリングを導入して、さらに堅牢なシステムを作るんだ。でも、グーグルの規模だと、常に何かがうまくいかないことがある。大事なのは、それが顧客やユーザー、他のシステムに影響を与えないようにどう対処するかってこと。正直、これは内部にいないと見えないし、チームごとに見るものが全然違うこともある。宇宙の中で最も複雑なシステムに近づいているかもしれない。人間としてはこれ以上のものは作れないから。もしかしたらAGIはできるかもしれないけど、私たちには無理だね。

└

私の理解では、ダウンタイムは数回のミスによって引き起こされたんだ。1) 同時に全ての場所で行われたグローバルな機能リリース 2) ヌルポインタの逆参照 3) サンダリングハード問題を引き起こした適切なリトライポリシーの欠如 これらは業界で働いている人なら誰でも何度も見たことがある、絶対に標準的なミスだよ。新しいことは何もないし、変な分散システムのロジックもない、グーグルのスケールでもない、ただのルーキーのミスばかりだね。

└

でも、これは一連のジュニアレベルのミスだね。

  • nullデータを適切に扱ってない
  • 適切にテストしてない
  • 新しいものがテストされていることを示すテストカバレッジがない
  • デプロイ後に本番環境のサブセットで動作確認をしてないから、全体に押し出す前にちゃんと動くか確認できてない この業界の基準は年々下がってるけど、ここまでひどいとは。10年前にGoogleの顧客として、もっと重要じゃないものをやってたら、向こうの人たちはみんなニヤニヤしながら笑ってたと思うよ、正当な理由でね。
└

そうだね、いくつかには当てはまるけど、これは違う。これは大きな恥だよ。マウンテンビューのアマチュアの時間だね。

└

このエラーは、キャッチされていないヌルポインタの問題だった。Googleのような規模と品質の会社が、この手のエラーで大部分のシステムをダウンさせるっていうのは、深刻な問題の後に適切な対策を実施していないことを示唆してるよね。

└

彼らは二度と同じミスを繰り返さないだろう。機能フラグなしで変更を展開して、クライアントに指数バックオフを実装せず、サーバーに負荷分散も実装しなかった。これは、何年も前のGoogle SRE本に書いてあることだよ。

└

これは文字通り、何度も繰り返されてきた同じミスだよ。もちろん、また繰り返されるだろう。「新機能は慎重に展開されるが、新しいデータによって引き起こされるまで潜在的なバグが残る」というのが、ほとんどのグローバルな障害を要約できる。要するに、完璧な人間なんていないってこと。もちろん、FAANGの障害についてのスレッドでのアームチェアHNコメント者を除いてね。

これは本当にアマチュアレベルの話だね。NPE、エラーハンドリングなし、指数バックオフなし、テストカバレッジなし、ステージングでのテストなし、段階的なロールアウトなし、致命的な失敗。彼らのSRE本を読んだけど、こういうことは全部書いてあるよね。https://sre.google/sre-book/table-of-contents/ https://google.github.io/building-secure-and-reliable-system... 基準が緩んだのか、それとも本はただのマーケティングだったのか。

└

誰か金曜日にプロダクションにプッシュしたのか？

Hacker Newsで議論の続きを見る