Google Cloud の大規模ダウン：6月12日に発生した API 障害について詳述する

Google Massive Cloud Outage Linked to API Management System

2025/06/16 CyberSecurityNews — 2025年6月12日に Google Cloud は、近年における最大規模の障害を引き起こした。その API 管理システムに発生した重大な障害により、世界中で数十のサービスが、最大で７時間にわたって停止した。このインシデントは、API の承認と割り当てポリシーを管理する Service Control バイナリで発生した、null ポインタへの例外処理が原因となり、Google Cloud Platform と Google Workspace を利用する数百万人のユーザーに、影響を与えたものである。

バイナリ・クラッシュが世界的な障害の原因

この障害の原因となったのは、Google の Service Control システムである。具体的にいうと、API リクエストの承認と、同社のインフラ全体にわたる割り当てポリシーの適用を担う、リージョン・サービスに起因する。

2025年5月29日に同社のエンジニアが、追加の割り当てポリシー・チェックを行うための新機能をデプロイしたが、そのコードには、適切なエラー処理と機能フラグの保護が欠けていたという。

この問題は、Service Control がポリシー・データとして使用している Regional Spanner テーブルに、意図しない空白フィールドを含む、ポリシー変更が挿入されたことに端を発している。その割当管理はグローバルに行われるため、この破損したメタ・データが数秒で世界中に複製されてしまった。

これらの空白フィールドを Service Control が処理する際に、保護されていないコード・パスがトリガーされ、NULL ポインタ例外処理が発生し、すべてのリージョンが同時にバイナリ・クラッシュ・ループに陥った。

Google のインシデント・レポートには、「この変更の問題は、適切なエラー処理が行われず、機能フラグも保護されていなかったことにある。それにより、NULL ポインタでバイナリがクラッシュした」と記されている。

Google のサイト信頼性エンジニアリング・チームは、問題の発生から 10分ほどで根本的な原因を特定し、40分以内に Red Button キル・スイッチを導入し、問題のあるサービス・パスを無効化した。

大半のリージョンは２時間ほどで回復したが、us-central1 リージョンでは、この問題の解消に長時間を要した。

そして、この主要リージョンで Service Control タスクが再開されたことで、基盤となる Spanner インフラに集団効果が生じ、データベースへの同時リクエストによる過負荷の状態が生じた。

Google のエンジニアが発見したのは、この連鎖的な障害を防ぐための適切なランダム指数バックオフ・メカニズムが、Service Control に欠けていたことだ。同社にとって必要になったのは、過負荷状態のインフラストラクチャ負荷を軽減するために、タスク作成を抑制し、トラフィックをマルチリージョン・データベースにルーティングすることだった。

この長時間にわたる復旧プロセスにおいて、数多くの企業のデジタル運用の基盤となる、Google Compute Engine／BigQuery／Cloud Storage などの重要なサービスに影響が生じた。

緩和策

広範囲にわたる障害を収束した Google は、同様のインシデントを防ぐための広範な修復策を策定した。

同社は、システムの完全な修復が完了するまでの措置として、Service Control スタックに対する、すべての変更と手動によるポリシー・プッシュを直ちに凍結した。

今後のための主な改善点として挙げられたのは、Service Control のアーキテクチャをモジュール化し、クローズドではなくフェール・オープンにすることで、個々のチェックが失敗した場合であっても、API リクエストを処理できるようにすることだ。

さらに Google は、複製されたデータをグローバルで使用する、すべてのシステムを監査し、すべての重要なバイナリ変更に対して、機能フラグ保護を適用することを約束した。

このインシデントは、Gmail／Google Drive／Google Meet／App Engine／Cloud Functions／Vertex AI などの、Google Cloud および Workspace における 60を超えるサービスに影響を与えるものとなった。

この障害の発生中に、ユーザーが被ったのは、API およびユーザー・インターフェイスでの断続的なアクセスだったが、Google が強調していたのは、既存のストリーミングおよび Infrastructure as a Service (IaaS) のリソースの継続的な稼働だった。

Google Cloud のグローバル・インフラが、繊細な仕組みの上に成り立っていることが、この記事から読み取れますね。Service Control のような中核的なシステムに、小さなバグが入り込むだけで、グローバルでの障害につながることに、少し驚きました。日本での被害はどうだったのでしょうか？ 同じようなことが繰り返されないよう、お願いしたいです。よろしければ、カテゴリ Cloud を、ご参照ください。