Google Cloud は2025年6月12日、近年記憶にない最も重大な障害の一つを経験し、約3時間にわたって複数の Google Cloud および Workspace 製品に影響を与えた。この障害は太平洋時間午前10時49分に始まり、基本的なプログラミングエラーと不適切なデプロイメント手法の組み合わせが原因で発生した。多くの技術コミュニティは、 Google ほどの企業にしては驚くほど素人的なミスだと指摘している。
インシデントタイムライン:
- 開始時刻: 2025年6月12日 太平洋時間午前10時49分
- 継続時間: 合計3時間
- 根本原因特定: インシデント開始から10分以内
- Red Button 展開: インシデント開始から25分
- Red Button ロールアウト完了: インシデント開始から42分
- 完全復旧 ( us-central-1 ): 2時間40分
根本原因：防げたはずの一連のミス
この障害は、グローバルなサービス中断に発展した3つの根本的な問題から生じた。まず、 Google は適切なフィーチャーフラグ保護なしに Service Control システムに新機能をデプロイしたため、段階的にロールアウトされるのではなく数秒でグローバルに展開されてしまった。次に、空白フィールドを含むポリシーデータが Spanner データベースに挿入された際、コードがヌル値を適切に処理できず、ヌルポインタ参照エラーが発生してサービスバイナリがクラッシュした。最後に、システムが復旧を試みた際、適切な再試行メカニズムと指数バックオフの欠如により、サンダリングハード効果が発生し、基盤インフラストラクチャが過負荷状態になった。
技術コミュニティは特にこれらのミスを批判しており、複雑な分散システムの問題ではなく基本的なエンジニアリングの失敗を表していると指摘している。多くの開発者は、ヌルポインタ例外、不適切なエラーハンドリング、再試行ポリシーの欠如は、適切なテストとコードレビュープロセスによって発見されるべき教科書的な問題だと指摘した。
精査される Google のエンジニアリング基準
この事件は、 Google のエンジニアリング基準が時間とともに低下しているかどうかについて激しい議論を引き起こした。批評家たちは、 Google が文字通りサイトリライアビリティエンジニアリング（SRE）の教科書を書いたにもかかわらず、自社の出版物で概説されている多くの実践に従わなかったという皮肉を指摘した。この障害は、段階的ロールアウト、適切なエラーハンドリング、包括的テスト、フェイルセーフメカニズムを含む複数の基本原則に違反していた。
「これは本当に素人レベルの問題だ：NPE、エラーハンドリングなし、指数バックオフなし、テストカバレッジなし、ステージング環境でのテストなし、段階的ロールアウトなし、フェイルデッドリー。私は彼らの SRE の本を読んだが、これらすべてがそこに書かれている。」
一部の業界観測者は、最近の Google でのレイオフと企業文化の変化が、適切な安全対策なしに機能を本番環境に急いで投入することに寄与した可能性があると示唆した。他の人々は、この事件がトップティアの技術企業でさえ基本的なプログラミングミスから免れないことを明らかにし、 FAANG 企業がエンジニアリング excellence の頂点を表すという認識に疑問を投げかけていると主張した。
再び現れた10億ドルのミス
この障害の中心にあったヌルポインタ参照エラーは、コンピュータ科学者の Tony Hoare が有名に自身の10億ドルのミスと呼んだもの、つまりヌル参照の発明を表している。 Rust のような現代のプログラミング言語は、型システムを通じてそのようなエラーを防ぐように設計されており、重要なインフラストラクチャをメモリセーフな言語で書き直すべきかどうかについて新たな議論を呼んでいる。
しかし、コミュニティは主にプログラミング言語の選択が主要な問題ではないことに同意した。真の問題は、適切な検証なしにテストされていないコードパスをグローバルに展開することを許可したデプロイメントプロセスだった。ヌルポインタの問題が適切に処理されていたとしても、設定変更の即座のグローバル複製は、あらゆるバグが即座にすべてのユーザーに影響を与える可能性がある危険な状況を作り出していた。
影響を受けた Google Cloud 製品: Identity and Access Management 、 Cloud Build 、 Cloud Key Management Service 、 Google Cloud Storage 、 Cloud Monitoring 、 Google Cloud Dataproc 、 Cloud Security Command Center 、 Artifact Registry 、 Resource Manager API 、 Dataproc Metastore 、 VMware Engine 、 Dataplex 、 Migrate to Virtual Machines 、 Google BigQuery 、 Google Cloud Deploy 、 Filestore 、 Media CDN 、 Cloud Asset Inventory 、 Disks/Local SSD 、 Google Cloud NetApp Volumes 、 Looker (Google Cloud Core) 、 Secret Manager 、 Cloud Functions 、 Traffic Director
学んだ教訓と今後の道筋
Google の対応には、完全にクラッシュするのではなくオープンに失敗するように Service Control アーキテクチャをモジュール化する、すべての重要な変更にフィーチャーフラグ保護を強制する、ヌルデータ処理のようなエッジケースを捉えるためのテスト手法を改善するなど、実装予定の包括的な改善リストが含まれていた。また、検証と問題検出の時間を確保するために、グローバルデータ複製を遅くすることも約束した。
この事件は、最も洗練された技術企業でさえ基本的なエンジニアリングミスの犠牲になり得ることを思い出させるものとなった。 Google の詳細な事後分析と改善への取り組みは称賛に値するが、この障害は間違いなく顧客の信頼を損ない、多数のサービスレベル合意に違反した可能性が高く、 Google とその顧客の両方に数百万米ドルの収益損失とペナルティをもたらした可能性がある。
参考: Service Health