1つのポリシーですべてのリージョン：Google Cloud とグローバルコントロールプレーンの説明責任

要約

• 2025年6月12日、クォータポリシー内の意図しない空白フィールドが、ほぼ同時に Google Cloud のリージョナル Service Control データストアに到達した。以前にデプロイされたコードパスには、適切なエラーハンドリングと機能フラグ保護の両方が欠けていた。ポリシーの処理により、全リージョンで Service Control バイナリがクラッシュした。多くの Google Cloud、Google Workspace、Google Security Operations API が503エラーを返した。既存のストリーミングおよびインフラストラクチャ・アズ・ア・サービスのリソースは概ねサービスを継続できたが、サービスの検査、変更、スケーリング、または復旧に必要な管理および API パスは広範囲に障害が発生した。
• 直接のバグは限定的だったが、説明責任の失敗はアーキテクチャ上のものだった。Google はリージョン分散型のサービスインスタンスと段階的なバイナリロールアウトを備えていたが、トリガーとなるポリシーは数秒以内にグローバルに複製された。そのため、キルメカニズムはロールアウトが提供するはずだったリージョナルラーニングを迂回した。さらに、復旧では、再起動タスクにランダム化された指数バックオフが欠けていたため、大規模リージョンで Spanner に対するハード効果が発生した。また、パブリック Cloud Service Health インフラも影響を受けた環境に依存していたため、Google の最初の通知は約1時間遅れた。
• 以前のインシデントは異なる原因を示しているが、論理的独立性に関する繰り返しの疑問を示している。2019年6月には、メンテナンス自動化が複数の物理ロケーションでネットワークコントロールプレーンクラスターをデスケジュールし、BGP ルートが撤回され、診断に必要なツールが輻輳したネットワークを競合した。2021年2月には、ピアリングクォータ変更中にトリガーされた潜在的なバグがグローバルネットワークプログラミングをブロックした。2021年3月には、無効なルートが既知のベンダー欠陥を露呈し、一部の Cloud Interconnect ロケーションでルーターベンダーの多様性が不足していた。これらは繰り返し発生するソフトウェア欠陥ではなく、コモンモード封じ込め、変更権限、ネットワーク復旧、真実の可視性の繰り返しのテストである。
• Google は、グローバルに複製されたデータの検証、コントロールプレーン機能の分離、安全な場所での fail-static または fail-open の動作の維持、インシデント通信の独立性の確保、そして約束された改善が完了したことの証明を行う責任がある。顧客はこれらのプラットフォームコントロールを修復することはできないが、どの運用がコントロールプレーン API に依存しているかを特定し、プロバイダの外部から監視し、縮退モードをテストし、名目上のリンクを数えるのではなくルートとプロバイダの多様性を購入する責任がある。マルチリージョンデプロイメントは多くのリスクを低減するが、それ自体ではグローバルポリシープレーンや共有バックボーンから逃れることはできない。

障害はすべての場所で同時に行われた制御判断だった

クラウドリージョンは想像しやすい。建物、電力、冷却、ファイバー、機械、そして物理的な障害を分離するためのゾーンがある。コントロールプレーンは見えにくい。リソースを作成してよいか、どのポリシーが適用されるか、ルートをどのようにプログラムするか、API リクエストがクォータ内か、トラフィックをどこに送るかを決定する権限である。アプリケーションは、その権限が一時的に利用できない場合でも、既存の作業を処理し続けることができるが、新しいインスタンス、設定変更、資格情報の決定、ルート更新、またはコントロールプレーン自体を必要とするフェイルオーバーが必要になると、脆弱になる。

その区別が、2025年6月12日のインシデントがなぜ全面インフラ停止未満でありながら、通常の API 問題以上であったかを説明している。Google の完全な Service Control インシデントレポートによれば、既存のストリーミングおよび IaaS リソースは一次障害の直接的な影響を受けなかった。しかし、Identity and Access Management、Cloud Storage、BigQuery、Cloud Run、Cloud DNS、Cloud Load Balancing、Hybrid Connectivity、Network Connectivity Center、Spanner、モニタリング製品、コンソール、および複数の AI サービスを含む多くの製品で外部 API エラーが発生した。既にプログラムされた状態からサービスを継続する能力は、プラットフォームに何かを決定してもらったり変更したりする能力よりも生き残った。

メカニズムは Google の公開説明で異常に明確だった。5月29日、新しい Service Control 機能（追加のクォータポリシーチェック用）がリージョンごとにリリースされた。バイナリロールアウトは、失敗するコードパスが後続のポリシー変更を必要としたため、欠陥を露呈せずに完了した。この機能は特定のプロジェクトに対して段階的に有効にできるフラグで保護されておらず、無効なデータの処理により null 値がプロセスをクラッシュさせる可能性があった。6月12日午前10時45分（太平洋時間）頃、意図しない空白フィールドを含むクォータポリシーが、Service Control が使用するリージョナル Spanner テーブルに書き込まれた。クォータメタデータはほぼ即時の整合性でグローバルに移動するように設計されていたため、データは数秒以内に全リージョンに出現した。各リージョナル Service Control デプロイメントは同じ入力に遭遇し、クラッシュループに入った。

これは冗長性が欠如していたケースではなかった。リージョナルサービスインスタンスとリージョナルデータストアは存在していた。また、単にエンジニアが誤ったボタンを押しただけでもなかった。本番システムは構造的に安全でないポリシーデータを受け入れ、重要なパスに防御的なエラーハンドリングが欠け、機能が独立して制御されたアクティベーションパスなしですべてのリージョンに到達し、伝搬システムは検証システムよりも高速だった。アーキテクチャは1つの無効な論理オブジェクトをグローバルイベントに変換した。

このインシデントを不正なポリシーによる障害と呼ぶのは正確だが不完全である。ポリシーは引き金だった。より大きな原因は、それに付与された権限の大きさと、受け入れ、複製、解釈、サービス間の封じ込めの欠如だった。問われるべきは、なぜ空白フィールドが存在したかだけではない。なぜ単一のポリシーが、1つのリージョン、1つのプロジェクトコホート、または1つのシャドウバリデータがそれを拒否する時間がある前に、すべての場所で実行可能な障害状態になり得たのかである。

短い引き金が長く不均一な復旧を生み出した

Google のタイムラインには2つの非常に異なるストーリーが含まれている。検出と診断は迅速だった。完全な復旧はそうではなかった。

us-central1 の遅い経路はリスク分析の中心である。Service Control タスクが再起動するにつれて、それらの下にある Spanner テーブルに集中需要がかかった。タスクには、同期リトライを防ぐために必要なランダム化指数バックオフが欠けていた。Google はタスク作成を抑制し、トラフィックをマルチリージョンデータベースにルーティングする必要があった。言い換えれば、最初の障害はグローバルデータの安全でない解釈であり、2番目は共有依存関係に過負荷をかける復旧動作だった。

Google 自身の SRE 文献は長い間この危険性を説明してきた。カスケード障害への対処に関する章は、リトライと再起動がどのようにバックエンドの過負荷を維持するか、そしてランダム化指数バックオフ、グレースフルデグラデーション、および制御された負荷遮断がどのように局所的な容量問題がカスケードになるのを防ぐかを説明している。2025年のレポートは、そのバックオフについてシステムを監査することを明示的に約束している。重要なのは、Google が本の一文に従わなかったことではない。再起動人口がリージョナルで、バッキングデータがグローバルであった重要なサービスに、分散システムの既知の危険クラスが残っていたことである。

したがって、復旧計画はランブックの段落としてではなく、本番アーキテクチャとして評価されるべきである。安全に無効化できるシステムには、それ自身の依存関係が理解されているキルメカニズムが必要である。一緒にクラッシュする可能性のあるフリートには、再起動ガバナー、アドミッションコントロール、ジッタ、およびテスト済みの最大復旧率が必要である。フリート復旧を吸収することが期待されるデータストアには、予約容量または縮退読み取りパスが必要である。イベント中にエンジニアがマルチリージョンデータベースにルーティングしなければならない場合、そのルートはインシデント前にリハーサルされ、観測可能で、過負荷を他の場所に移動させないという証拠が必要である。

ロングテールは顧客コミュニケーションにも重要である。Google の予備報告書は3時間のグローバルイベントを説明していたが、インシデントページは午後6時18分まで製品復旧をリストし続けた。一部の製品では API サービス復旧後にバックログがあった。一次ウィンドウ中にリクエストが失敗した顧客は、リトライ、キューに入れられたジョブ、部分的なワークフロー、古いキャッシュ、または復旧に時間がかかるサードパーティサービスを持っている可能性がある。プロバイダのグリーンステートは顧客の調整の開始であり、すべてのビジネスプロセスが完全であることの証明ではない。

リージョナルデプロイメントはリージョナルラーニングを生み出さなかった

プログレッシブデリバリーは距離を証拠に変えることになっている。変更は小規模な人口に届き、オペレーターがその動作を観察し、その後初めてさらに移動する。Google は新しい Service Control コードに対してリージョンごとのバイナリロールアウトを使用したが、デプロイメントは後に失敗したコードパスを一度も実行しなかった。アクティブ化するポリシーは異なる配布メカニズムに従い、クォータ状態を数秒でグローバルにするように最適化されていた。コードは段階的だったが、コードの意味は段階的ではなかった。

これは微妙だが結果的に重要な変更管理の失敗である。チームはしばしばバイナリ、構成、スキーマ、ポリシー、データを別々のオブジェクトとしてレビューする。しかし、本番動作はそれらの組み合わせから生じる。休止機能は、構成値がそれをすべての場所で目覚めさせるまで、すべてのリージョナルゲートを通過できる。スキーマは書き込み側には有効でも、古い読み取り側には無効である可能性がある。グローバルに複製されたポリシーはリージョナルカナリアを無意味にすることができる。緊急ボタンは存在しても、効果を発揮するために壊れたコントロールプレーンに依存している可能性がある。

Google の現在のインフラストラクチャガイダンスはこのリスクを認識している。信頼性のビルディングブロックガイドは、グローバルリソースはゾーンおよびリージョンのインフラストラクチャインシデントに対して回復力があるが、重要な構成エラーがグローバルスコープを持つ場合、単一障害点になる可能性があると述べている。変更の注意深い制御と、非常に要求の厳しいワークロードに対してはリージョナルな多層防御フォールバックを推奨している。付属の管理と監視ガイダンスは、プログレッシブデプロイメントとグローバルリソースへの追加の精査をアドバイスしている。2025年のインシデントはプロバイダ内部に同じ論理を適用している：グローバルリーチは物理的障害に対する信頼性の利点であり、悪い論理状態に対する爆風半径の危険でもある。

完全な改善には結合されたリリースモデルが必要である。バイナリ、ポリシースキーマ、ポリシー値、データストア複製、リーダーバージョン、フォールバック動作、緊急制御は1つの変更面として扱われるべきである。新しいリーダーは古い値、新しい値、欠落値、破損値を安全に受け入れるべきである。新しいポリシーは権威的になる前にシャドウリードされるべきである。アクティベーションは内部プロジェクトまたは境界のあるリージョンから開始し、クラッシュ、レイテンシ、またはエラーしきい値で自動停止するべきである。複製は、最終的なビジネス状態がグローバルに一貫していなければならない場合でも、検出間隔を保持するのに十分な増分であるべきである。

それはすべてのグローバルポリシーがゆっくりと不整合になるべきという意味ではない。クォータと認可の決定にはタイムリーで一貫した状態が必要になる場合がある。設計上の問題は、検証を権限から分離できるかどうかである。候補ポリシーは不活性なデータとして複製され、プロダクションライクなトラフィックに対して解析・評価され、チェックが成功した後にのみ有効になることができる。リージョンは新しいオブジェクトが無効な場合に最後に正常だったポリシーを保持できる。リーダーは破損と正当な拒否を区別できる。グローバル一貫性は段階的安全性と相反するものではなく、単に迅速な複製以上のものを必要とする。

フェイルオープンはビジネスと安全性の決定であり、スローガンではない

Google は Service Control をモジュール化し、影響を受けるポリシー機能を分離してフェイルオープンできるようにすることを約束した。それは意味のある修正であるが、「フェイルオープン」というフレーズには境界が必要である。クォータチェック、認証決定、課金制御、および悪用防止制御は、利用できない場合に同じ結果をもたらさない。

低リスクのクォータチェックの場合、一時的な寛容なサービスはすべての顧客 API リクエストを拒否するよりも安全かもしれない。プロバイダは後で使用量を調整し、プロジェクトごとのエクスポージャーを制限し、コア可用性を維持できる。認証チェックの場合、盲目的にリクエストを許可するとダウンタイムよりも悪いセキュリティインシデントが発生する可能性がある。リソース作成の場合、最近のポリシーの境界のあるローカルキャッシュは、普遍的な拒否または普遍的な許可よりも安全かもしれない。正しい縮退動作は、コントロールの目的、信頼された状態の鮮度、アクションの可逆性、および詐欺、データ損失、または制御不能な支出の可能性に依存する。

Google のサービスインフラストラクチャアーキテクチャは、管理、制御、データプレーンを分離しながら、プラットフォーム機能の幅広さを示している：認証、認可、クォータ、レート制限、監査、課金、ロギング、モニタリング。その幅広さこそが、モジュール式障害動作が重要な理由である。1つのパーサーまたはポリシーパスが、すべてのタイプの決定を同じ503応答に変えることができてはならない。

説明責任のある設計は、機密性の高い実装詳細ではなく原則を公開するだろう。どのクラスのチェックが最後に正常だったデータを使用するか？どれが一時的にフェイルオープンできるか？セキュリティ結果が支配するためどれがフェイルクローズドするか？縮退サービス中にどのハードリミットが残るか？例外的な使用量はどのように調整されるか？顧客は規制されたワークロードに対してより厳格な動作を選択できるか？プラットフォームは無効なプロバイダポリシーと正当な顧客クォータ拒否をどのように区別するか？

これはテストも変える。良いポリシーが正しい答えを返すことを確認するだけでは十分ではない。テストは空白フィールド、不明なフィールド、古いバージョン、部分的な複製、破損したオブジェクト、利用できないデータストア、遅い読み取り、および競合するポリシーを注入するべきである。1つのモジュールが無関係なセーフガードをバイパスせずにバイパスできることを証明するべきである。縮退動作中の顧客可視動作を測定し、復旧が拒否された変更や重複した変更を予測不能に再生しないことを検証するべきである。

ステータスシステムはそれが説明するはずだった障害を共有した

約1時間の間、顧客は公開 Cloud Service Health インシデントレポートを受け取らなかった。なぜなら、そのインフラ自体がダウンしていたからである。一部の顧客は Google Cloud 上でモニタリングも実行していたため、サービスとそのサービスの証拠の両方が同時に失敗した。障害は本番だけでなく、認識論的制御、すなわち何が起こっているかを知り、フェイルオーバーするかどうかを決定し、状況をユーザーに説明する能力を損なった。

これは前例がなかったわけではない。2020年12月14日の Google のグローバル認証障害中、インシデントレポートによれば、Cloud Support の内部ツールが影響を受け、顧客はコンソールでサポートケースを作成または表示できず、ダッシュボードコミュニケーションは主要な影響が終わるまで遅れた。そのイベントは、自動化されたクォータ管理が集中アイデンティティシステムの容量を削減したことに起因する。既存のネットワークデータプレーン構成は運用を維持したが、認証サービス、API アクセス、コンソール、および多くの内部ツールは維持しなかった。メカニズムは2025年とは異なるが、繰り返しの懸念は、アイデンティティ、サポート、モニタリング、コミュニケーションが診断対象のサービスと運命を共有できることである。

Google はその後、より明示的なコミュニケーションモデルを文書化した。インシデントコミュニケーションガイダンスは、プロジェクトコンテキストを使用し、アラートや API と統合できる Personalized Service Health と、パブリック Cloud Service Health ダッシュボードを区別している。同じガイダンスは、Personalized Service Health が IAM などのサービスに依存することを認め、パーソナライズされたシステムが利用できない場合のフォールバックとしてパブリックダッシュボードと RSS フィードを推奨している。それは健全なアドバイスであるが、2025年6月はパブリックチャネルも運用独立を必要とすることを示している。

プロバイダの義務は、外部から到達可能で、独立して電源が供給され管理された公開パスを、事前に承認されたインシデントテンプレートとインシデントコマンドからの帯域外入力を備えて維持することである。通常のコンソール、顧客アイデンティティプレーン、プライマリモニタリングスタック、または調査中のコントロールサービスを必要とすべきではない。最初の通知には根本原因を含める必要はない。観測された症状、既知の範囲、開始時刻、コントロールプレーン操作または既存のワークロードが影響を受けているかどうか、利用可能な回避策、および次の更新時刻を述べるべきである。

顧客には並行した義務がある。Google の Personalized Service Health 統合ガイドは、サービスが特定のアプリケーションにとってすべての製品が重要であるかどうか、または1つの依存関係が失敗したときにアプリケーションが継続するかどうかを知ることができないと明示的に述べている。オペレーターは独自のユーザージャーニーチェック、アプリケーションメトリクス、ネットワークテレメトリー、ビジネスプロセスアラームを必要とする。少なくとも1つのパスは Google Cloud の外部で実行され、Google アイデンティティに依存しないインシデントチャネルに配信されるべきである。プロバイダステータスは確証であり、最初で唯一の検出器ではない。

この分離にはガバナンス上の理由がある。ステータスページの遅延は顧客の行動を変える。チームは自分たちのデプロイメントの調査に時間を浪費し、危険なロールバックを発行し、壊れたコントロールプレーンにスケールインし、確認を待っている間にフェイルオーバーを延期するかもしれない。サポートの沈黙は、下流のプロバイダが憶測を公開することにもつながる。したがって、コミュニケーションの可用性は、エンジニアリング作業が開始された後の礼儀ではなく、測定可能な検出および公開目標を持つリスクコントロールである。

既存のワークロードはそれらを救うためのアクションよりもよく生き残った

2025年のレポートの、既存のストリーミングおよび IaaS リソースは影響を受けなかったという声明は注意深く読むべきである。それはデータプレーンの一部と管理パスの間の有用な分離を示している。しかし、それは現在実行中の仮想マシンが稼働し続けたという理由だけでアプリケーションが安全であったことを意味するものではない。

クラウドシステムは動的である。オートスケーラーはインスタンスを作成する。オーケストレーターは不健全なノードを置き換える。デプロイメントシステムはアーティファクトを取得し、API コールを発行する。データベースはフェイルオーバーする。証明書とトークンはローテーションする。サーバーレスサービスは、一見単純なリクエストの背後でプロバイダのコントロールパスを呼び出す。インシデント対応者はファイアウォールルール、ロードバランサー、DNS、ルート、クォータ、および権限を変更する。静的なデータプレーンは転送を続けることができるが、その周りのビジネスプロセスは適応する能力を失う。

2021年2月のネットワーキング障害はその境界を具体的に示している。Google のネットワークプログラミング障害に関するインシデントレポートは、グローバルネットワークコントロールプレーンがピアリングクォータ変更に関連する操作を再処理したときに潜在的なバグがトリガーされたと述べている。新規、更新、削除、または移行された VM およびネットワークエンドポイントは正しくプログラムできなかったが、多くの変更されていないインスタンスは動作を継続した。Google はグローバルにライブマイグレーションを一時停止した。約1,000の GKE クラスターがノードまたはクラスターをプロビジョニングできない影響を受け、一部のインスタンス作成とロードバランサー更新が非常に高い割合で失敗した。正常な既存サーバーは、新しいネットワークサーバーを必要とするオートスケーリンググループを助けなかった。

これが災害復旧のコントロールプレーンパラドックスである。復旧計画のアクションは、通常のサービス提供よりもテストが少なく、コントロールプレーンに依存することが多い。ランブックは「2番目のリージョンに容量を作成する」または「ロードバランサーを切り替える」と言うかもしれないが、それらは API 操作である。最初の障害がリソース作成またはグローバルロードバランサー更新を損なう場合、復旧ステップは要求されたときに正確に利用できなくなる。

Google の災害復旧アーキテクチャガイドは、データプレーンアクションとコントロールプレーン更新を区別し、サービス固有の回復力を説明している。信頼性の高いインフラストラクチャ設計ガイドは、新しいロードバランサーの作成など、障害時に非データプレーンアクションへの依存を回避または最小化することを推奨している。実用的な教訓は、復旧パスを事前にプロビジョニングすることである。容量は仮想的ではなくウォームであることができる。リージョナルエンドポイントはグローバルフロントエンドが失敗する前に存在できる。DNS レコード、資格情報、ルート、イメージ、ランブックは、直前の管理操作なしで利用可能にできる。

各復旧ステップについて、オペレーターは必要な API、アイデンティティプロバイダ、ネットワークパス、DNS リゾルバ、アーティファクトストア、シークレット、および人間の承認を名前で指定できるべきである。次に、それらの依存関係を一度に1つずつ削除してエクササイズを行うべきである。コンソール、IAM、Service Control、グローバルネットワークプログラミング、およびプライマリリージョンがすべて正常である場合にのみ成功する計画は、拡張手順であり、災害復旧ではない。

2019年の障害は物理的分離が1つの自動化境界を共有できることを示した

2019年6月2日、米国の複数リージョンでの Google Cloud プロジェクトが3時間以上にわたって高いパケット損失を経験した。一部の Google サービスはユーザーを影響を受けていないリージョンに完全にリダイレクトできなかった。ネットワークインシデントレポートは、複数の障害が組み合わさって大規模障害になったことを説明している：ネットワークコントロールプレーンジョブがメンテナンスイベントのために停止するように構成されていた。複数のクラスタ管理インスタンスが同じまれなイベントタイプの対象となった。ソフトウェアのバグにより、自動化が異なる物理ロケーションにある場合でも独立したソフトウェアクラスターをデスケジュールできた。

ネットワークは最初、コントロールプレーンなしで「フェイルスタティック」モードで継続した。数分後、影響を受けたロケーション間の BGP ルートが撤回され、ネットワーク容量が減少し、一部のリージョンにアクセスできなくなった。輻輳したネットワークでの診断ツールの失敗が調査を遅らせた。エンジニアがコントロールプレーンインスタンスを復旧させたとき、構成を再構築して再配布する必要があり、復旧が延長された。

2025年との顕著な構造的類似性がある。2019年には、物理ロケーションと複数のクラスタマネージャーが存在したが、1つのメンテナンス抽象化がそれらを一緒に選択した。2025年には、リージョナル Service Control インスタンスが存在したが、1つのグローバルポリシーがそれらに一緒に到達した。両方のインシデントには、短すぎるか依存しすぎていることが証明された安全期間が含まれていた：2019年はフェイルスタティックルーティング、2025年は緊急ボタンバイパス。両方とも、障害を理解または伝えるために使用されるツールを損なった。両方の復旧パスは、縮退条件下で制御状態を再構築または再配布する必要があった。

原因は互換性がない。2019年のインシデントはネットワーク制御とメンテナンス自動化の失敗であり、2025年のインシデントはポリシーデータと API 制御の失敗である。説明責任はそれらを「Google のまた別の障害」と平坦化すべきではない。比較の価値は、組織が、名目上独立したコンポーネントが依然として管理ドメイン、伝播メカニズム、緊急ツール、または復旧依存関係を共有していることを繰り返し発見するかどうかをテストすることである。

Google の2019年のコミットメントには、問題のあるメンテナンスリクエストの拒否、ローカルコントロールプレーン構成の永続化、フェイルスタティックネットワーク動作の期間延長、緊急ツールの強化、および災害復旧テストの拡大が含まれていた。現在の説明責任の問題は、それらのアクションが無関係の2025年の null ポインタを防いだかどうかではない。その背後にあるガバナンス方法が標準になったかどうかである：共通権限のマッピング、安全な状態の永続化、一次障害ドメイン外の緊急制御の維持、および壊滅的な相関障害のテスト。改善プログラムは、その制御パターンがポストモーテムを書いたチームを超えて移動する場合にのみ制度的価値を持つ。

ピアリングとトランジットの多様性は回線数ではなく運命に関する

クラウドの可用性はネットワークを通じて顧客に届く。ワークロードはリージョン内で正常であっても、エッジ、バックボーンルート、ピアリングセッション、トランジットプロバイダ、DNS パス、またはハイブリッドインターコネクトが失敗したため、ユーザーが到達できない可能性がある。逆に、2つのアクセス回線は注文書では多様に見えても、1つのメトロ、1つのプロバイダ、1つのルーターモデル、1つの Google エッジ、または1つの制御システムに収束する可能性がある。

Google の2021年3月17日のバックボーンインシデントレポートはその違いを示している。新しいルーターの接続により、特定のルーターの役割が受け取るルートが変更された。それらのルートは特定のルーターモデルの既知の欠陥を露呈し、ルーティングプロセスが失敗した。自動リダイレクションはより広範なカスケードのリスクを低減したが、収束中にパケット損失を生み出した。手動緩和により別の輻輳期間が発生し、一部の Cloud Interconnect ロケーションではルーターベンダーの冗長性が不十分だったため、影響が長期化した。地域間のプライベート IP トラフィック、パブリック IP トラフィック、ロードバランサー、VPN トンネル、外部接続が異なる割合で影響を受けた。

これが、レジリエンスレビューが「リンクが2つある」を超えなければならない理由である。レビューは、各ファイバーパスの所有者、使用する建物とエッジ可用性ドメイン、それを終端するルーターベンダーとソフトウェアトレイン、BGP セッションを制御する Cloud Router、ルートの再収束方法、フェイルオーバー容量が全負荷を運べるかどうか、両方のパスが同じプロバイダコントロールプレーンに依存しているかどうかを尋ねるべきである。実際のルート変更を観察し、計画的な撤回を実行し、トポロジ図を証拠として受け入れてはならない。

Google の Cloud Interconnect 概要は、99.9%および99.99%の構成を提供し、単一接続にはアップタイム SLA がないことを説明している。Partner Interconnect ガイダンスは、推奨される99.99%トポロジのために、2つのメトロとエッジ可用性ドメインにわたる4つの VLAN アタッチメントを要求している。また、Google のネットワーク外のプロバイダセグメントはそれ自身の保証を必要とすることも指摘している。複数のサービスプロバイダを使用することで可用性は向上する可能性があるが、それはそれらの基盤となるパスが実際に分離されており、フェイルオーバー中に十分な容量がある場合に限る。

クラウド内のピアリングはデフォルトではトランジットではない。Google の VPC ネットワークピアリングドキュメントは、ピアリングは非トランジットであると述べている：ネットワーク A が B とピアリングし、A が C ともピアリングする場合、B が C への接続を得るわけではない。その制約は有用な封じ込め境界になり得るが、中央 VPC が自動的にトランジットハブとして機能すると想定するチームを驚かせる。障害時には、アドバタイズされたトポロジがかつてサポートされていなかったため、即席の復旧ルートが失敗する可能性がある。トランジットが必要な場合は、明示的に設計し、ルート交換、ポリシー、容量、セキュリティ検査、障害動作をエンドツーエンドでテストする必要がある。

インターネットトランジットにも同じ精度が求められる。2つの ISP を介したパブリックアクセスは、それでも共通のピアリングロケーションで Google のネットワークに入る可能性がある。プライベートインターコネクトとインターネット VPN はより良い管理多様性を提供するかもしれないが、両方とも Google のバックボーンまたは同じ顧客アイデンティティと DNS に依存する可能性がある。2番目のクラウドは、アプリケーション、データ、アイデンティティ、デプロイメントツール、可観測性、DNS フェイルオーバーが独立して動作できる場合にのみ、プロバイダ集中を低減できる。ロゴの数はアーキテクチャではない。

マルチリージョンは間違ったクラスの障害に対する強力な保護である

マルチリージョン設計は依然として価値がある。それは停電、局所的な容量喪失、ゾーンハードウェア障害、および多くのリージョナルソフトウェア問題から保護できる。誤りは複数リージョンを使用することではなく、フレーズを独立性の完全なステートメントとして扱うことである。

2019年のネットワークイベントは、コントロールプレーン自動化境界が物理ロケーションを横断したため、複数のリージョンに影響を与えた。2021年のピアリングクォータインシデントは、関連するコントローラーと VPC リソースがグローバルスコープを持っていたため、ネットワークプログラミングにグローバルに影響を与えた。2025年の Service Control イベントは、ポリシープレーンがグローバルだったため、すべてのリージョンに影響を与えた。それぞれのケースで、影響を受けた管理ドメイン内のより多くのアプリケーションレプリカが共通原因を除去できなかった。

Google の信頼性ドキュメントは、ロケーションスコープとアプリケーション信頼性の有用な区別をしている。グローバルリソースはリージョナルインフラストラクチャ障害に対して高い回復力を持つことができるが、構成によっては単一障害点にもなり得る。マルチリージョンリソースは1つのリージョンの喪失から生き残ることができるが、グローバルアイデンティティ、API 管理、ネットワーク制御、またはグローバルフロントエンドに依存し続ける。顧客は地理と権限の両方をマークする依存関係グラフを必要とする。

そのグラフには少なくとも5つのレイヤーを含めるべきである。第一は実行：プロセスとデータが実際に実行される場所。第二は制御：リソースを作成、ルーティング、認可、スケーリング、フェイルオーバーする API。第三はアクセス：ユーザーとオペレーターを接続する DNS、ピアリング、トランジット、インターコネクト、VPN、バックボーンパス。第四は観測：ログ、メトリクス、ステータスフィード、ページング、サポートが存在する場所。第五は復旧：運用を復元するために必要なリポジトリ、資格情報、人間、外部サービス。

依存関係は、同じ信頼できるイベントがプライマリと一緒にそれを無効にできない場合にのみ独立している。1つの無効なグローバルポリシーによって制御される2つのリージョンは、そのイベントに対して独立していない。同じアイデンティティシステムを通じて配信される2つのモニタリングスタックは、認証障害に対して独立していない。同じルーターソフトウェア上の2つの回線は、関連するベンダー欠陥に対して独立していない。別のクラウドのウォームサービスは、唯一の DNS 制御、アーティファクトリポジトリ、またはオペレーターログインが Google Cloud にある場合、独立していない。

この分析が、すべての小規模ワークロードが3つのプロバイダにわたって運用することを要求する高価な要求になるべきではない。コントロールは比例する必要がある。公開情報サイトは数時間のダウンタイムを受け入れ、外部のステータスページを維持するかもしれない。支払い認証サービスは、事前にプロビジョニングされた容量、独立したトランジット、外部モニタリング、テスト済みのセカンダリプロバイダを必要とするかもしれない。説明責任のある行為は、どの依存関係が共通のままであるかを知り、結果を価格設定し、ビジネスオーナーから明示的な承認を得ることである。

Cloudflare は1つのプロバイダインシデントを別のプロバイダの依存関係レッスンに変えた

2025年6月のイベントは、特に有益な方法で企業境界を越えた。Cloudflare の独自の障害レポートによれば、Workers KV は部分的にサードパーティのクラウドプロバイダに依存していた。その依存関係が失敗したとき、Workers KV は利用不能になり、それを使用する広範な Cloudflare 製品セット（Access、Gateway、WARP、Turnstile、Images、Stream、ダッシュボードの一部、およびその他のサービス）が影響を受けた。Cloudflare のコア CDN およびセキュリティサービスは一律にダウンしたわけではなかったが、その依存関係により、別のプロバイダの名前で販売された製品を通じて Google Cloud のコントロールプレーン障害が見えるようになった。

これはアウトソーシングが本質的に無責任であるという証拠ではない。プロバイダは互いにサービスを購入するのが賢明である。これは、依存関係の商業的距離がその運用上の結果を減少させないという証拠である。顧客はインフラストラクチャに Google Cloud を、エッジセキュリティに Cloudflare を購入することで多様化したと信じるかもしれないが、Cloudflare の制御サービスは Google Cloud に依存する可能性がある。結果として得られるチェーンは、Google Cloud から Workers KV、Access、そして顧客のオペレーターログインに至る可能性がある。開示とテストがなければ、顧客はセカンダリコントロールがプライマリ障害ドメインを共有していることを見ることができない。

Cloudflare は説明責任の部分を受け入れた。そのレポートは、どのサービスが Workers KV に依存しているかを説明し、コアサービスが最初にサードパーティストレージパスからフェイルオーバーしなかったことに言及し、重要な製品の依存関係を削減または除去するための作業を概説した。Google は上流のプラットフォーム障害に対して責任を負い続ける。Cloudflare は、重要な内部サービスが適切な継続性なしにそれに依存できると決定した責任を負い続ける。エンドカスタマーは、自社システムへのアクセスに緊急時ルートがあるかどうかを評価する責任を負い続ける。これらの義務は同時に発生し、相互排他的ではない。

現代の AP 通信の報道は、人気のオンラインサービス全体で目に見える混乱と数万人のユーザー報告を記録した。そのような報道は公的なリーチを示すのに有用であるが、障害報告の数は影響を受けた人々、リクエスト、または財務損失の国勢調査ではない。より強力な証拠は、プロバイダの技術報告書と顧客の取引データから得られる。説明責任は、過小評価と見世物の両方に抵抗すべきである：正確なグローバル損失総額が利用できない場合でも、広範な依存関係カスケードは重要である。

したがって、契約とアーキテクチャレビューは、プロバイダに制御、アイデンティティ、構成、ステータス、および復旧機能に関する重要な第4者依存関係を特定するよう求めるべきである。上流のイベントが原因である場合の通知義務を指定し、顧客が影響を調整できるようにログを保存し、プロバイダがテスト済みの代替手段を持っているかどうかを定義するべきである。顧客はセキュリティおよび商業上の理由から完全なサプライヤマップを受け取れないかもしれないが、クラウド、アイデンティティプラットフォーム、ネットワークキャリア、および地理的コントロールプレーンによる集中を理解するのに十分な保証を受け取るべきである。

SLA クレジットは依存関係が許容可能であることを証明しない

サービスレベル契約は、測定可能なコミットメントと救済策を定義するので有用である。それらは完全なリスク評価ではない。月間アップタイムパーセンテージは時間を平均し、多くの場合特定の製品または構成されたトポロジに適用される。顧客構成、サードパーティセグメント、クォータ、プレビュー機能、または対象サービスの外部の障害を除外する可能性がある。救済策は通常、将来の支出に対するクレジットであり、逸失収益、緊急労働、規制上のエクスポージャー、または顧客のユーザーへの損害に対する補償ではない。

現在の Cloud Interconnect SLA は、例えば、本番レベルのトポロジを単一接続から区別し、請求には顧客の証拠を必要とする。そのフレームワークは健全なトポロジを奨励できるが、ハイブリッドアクセスの4時間の喪失が許容可能かどうかを取締役会に伝えることはできない。また、製品固有の SLA は、サービスの変更に使用される API、それを観察するために使用されるモニタリング、およびそれを報告するために使用されるサポートチャネル間の相関障害を説明しない。

顧客は自社のユーザージャーニーに対するサービスレベル目標を必要とする。その目標には、ユーザージャーニーを完了するために必要なクラウド製品、ネットワークパス、内部サービス、およびサプライヤーを含めるべきである。定常状態のサービス提供と復旧アクションの両方を測定するべきである。稼働しているが容量を追加できないチェックアウトフローは、現在は正常でも即座にリスクにさらされる可能性がある。読み取りを提供するがレプリカを昇格できないデータベースは、ユーザーがエラーを見る前から復旧可能性が低下している可能性がある。

Google の責任とクレジット条件は法的な割り当てであり、工学的証拠ではない。逆に、プロバイダの公的な謝罪は過失の証明または法的な自認ではない。この記事は、誰が伝搬経路を設計したか、誰が依存関係を受け入れたか、誰がそれをテストできるか、誰が改善を検証しなければならないかに基づいて、運用上およびガバナンス上の説明責任を割り当てる。法的責任は契約、管轄権、事実、および技術的インシデントレポートの範囲外の裁定に依存する。

したがって、取締役会はベンダーアップタイムを超えた定量化されたエクスポージャーを求めるべきである。どのくらいの収益または公共サービスがコントロールプレーン操作に依存しているか？既に実行中のリソースは、スケーリングや資格情報なしでどのくらいサービスを提供できるか？代替トランジットパスを通じてユーザーを移動する時間は？どの復旧が失敗したプロバイダを必要とするか？最後の演習からの証拠は何か？サービスクレジットは財務記録に属する。それは継続性と誤解されるべきではない。

Google の改善リストは証拠になったときにのみ信頼できる

2025年のインシデントレポートには強力なコミットメントセットが含まれている。Google は復旧後、Service Control の変更と手動ポリシープッシュを凍結した。サービスをモジュール化し、適切な場所でフェイルオープンし、グローバルに複製されたデータを消費するシステムを監査し、そのようなデータを検証時間とともに段階的に伝搬させ、デフォルトで無効になっている機能フラグで重要なバイナリを保護し、静的解析と無効データテストを改善し、ランダム化指数バックオフを監査し、外部コミュニケーションを改善し、Google Cloud がダウンしたときにモニタリングとコミュニケーションを利用可能にし続けると述べた。

これらのアクションは観察された障害チェーンと異常によく一致している。残っている問題は保証である。約束は、リスクが本番で低下したことを証明せずに、トラッキングシステムのポストモーテムアクションを閉じることができる。Google は、詳細なアーキテクチャが機密のままでも、最も影響の大きいアクションについて完了状況、検証方法、残存制限を公開すべきである。

グローバルポリシーの安全性については、段階的アクティベーションの背後にある重要なポリシー消費者の割合、不正な候補データの自動拒否率、グローバル権限前の最小観測間隔、および悪いオブジェクトが1つのコホートで停止された成功した演習の証拠を含めることができる。障害分離については、クォータモジュールが失敗しても無関係の API チェックが継続し、セキュリティに敏感な決定が意図された境界を保持することを示すテストを含めることができる。

復旧については、Google はフリート再起動制限、バックオフ準拠、予約データストア容量、および同時リージョナル復旧の負荷テスト結果を示すべきである。コミュニケーションについては、最初の顧客影響から内部検出、最初の公開通知、最初の範囲指定影響声明、および演習中の独立したステータスパスの可用性までの時間を公開すべきである。制度的学習については、Service Control の外部で同様のグローバルコンシューマーが見つかり改善されたかどうかを報告すべきである。

以前のインシデントはこのフォロースルーの必要性を強調している。2019年以降、Google はより長いフェイルスタティックネットワーク動作、永続的な制御構成、堅牢な緊急ツール、および拡大されたカタストロフテストを約束した。2021年2月以降、グローバルネットワーク制御コンポーネントのさらなるリージョナル化、移行の自動一時停止、およびコントローラーが応答しない場合のデータプレーンの回復力向上を約束した。2021年3月以降、ルートポリシー執行の機能ドメインとルータービルドテストの改善を約束した。各コミットメントは独自のプログラム内で完了した可能性がある。公開記録は、プラットフォームのコモンモードリスクが時間とともにどのように変化したかを示す継続的な保証ビューを提供していない。

Google の SRE の本は、ポストモーテムを学習システムとして説明し、アクション項目を原因に結び付け、複雑なインシデントを個人の責任に還元しない。同じ原則が外部の説明責任をサポートしている。証拠を公開する目的は、従業員を露出させたり、顧客に Google のネットワークを実行させたりすることではない。それは、顧客が一時的な回避策と耐久性のある制御を区別し、何が未解決かを確認し、自分たちのリスク処理が適切かどうかを判断できるようにすることである。

独立したレビューは、最もグローバルな制御に価値を追加するだろう。設計文書、ロールアウト記録、フォールトインジェクション結果、緊急ボタンの独立性、アクションのクロージャをサンプリングできる。公開出力は、悪用可能な内部を明らかにせずに、範囲、例外、結論を述べることができる。自己報告は技術的深さを提供し、独立した保証はクロージャ基準が提供責任を負うチームのみによって定義されなかったという信頼を提供する。

次のグローバルインシデントの前に顧客がテストすべきこと

どの顧客も Google の内部 Service Control バイナリに機能フラグを付けたり、ポリシーテーブルの複製方法を変更したりすることはできない。プロバイダ全体の障害の後に単に「より良くアーキテクチャを設計する」ように顧客に指示するアドバイスは、責任を不当に転嫁する。それでも、顧客はプロバイダ障害が自社のビジネスに対してどれだけの権限を持つかについて重要な選択を行う。

サービス提供パスから始める。すべての Google Cloud 管理 API が3時間利用できない場合、どのユーザートランザクションが継続するかを特定する。新しいデプロイメントが一時停止され、オートスケーリングが凍結され、IAM 変更が利用できず、ロードバランサー変更がブロックされ、サポートにアクセスできない状態でテストする。容量、資格情報、証明書、キュー、またはスケジュールされたジョブがいつ制限要因になるかを測定する。結果は多くの場合、二値的な答えではなく曲線になる：サービスは現在の負荷で一定期間継続し、その後ルーチンの制御アクションが蓄積されるにつれて低下する。

次に、オペレーターアクセスをテストする。取得と検証にプライマリクラウドアイデンティティパスを必要としない緊急時資格情報を保持する。Google Cloud の外部に最小限のインシデントワークスペース、連絡先リスト、ランブック、アーキテクチャ図、ステータスパブリッシャーを維持する。チームが企業コラボレーションスイートが Google アイデンティティを共有している場合、それを介さずにネットワークキャリアと重要なサプライヤーに到達できることを確認する。すべての緊急ツールに隠された DNS、メール、シングルサインオン、シークレット依存関係がないか監査する。

次に、ネットワークパスをテストする。制御された演習中に各 BGP セッションとインターコネクトアタッチメントを撤回する。トラフィックが意図されたメトロとプロバイダを通って移動することを確認し、収束損失を測定し、代替ルートが全負荷容量を持つことを検証する。パブリックインターネットフォールバックがファイアウォール、ルーティング、または送信元アドレスの仮定によってブロックされていないことを確認する。VPC ピアリングについては、正確にインポートおよびエクスポートされたルートを証明し、トランジティビティを想定しない。マルチクラウドトランジットについては、パケットだけでなくデータの一貫性とアイデンティティもテストする。

コントロールプレーン障害中に作成できないものを事前にプロビジョニングする。これには、リージョナルロードバランサー、DNS レコード、セカンダリクラスター、スタンバイデータベース、クォータ、サービスアカウント、アーティファクト、ネットワークトンネルが含まれる可能性がある。最後に正常だった構成が使用可能なままになるように、変更を十分に小さく保つ。障害のあるプロバイダにリトライやスケールリクエストのバーストを発行する代わりに、非必須機能を排除する縮退モードを練習する。

最後に、演習後に調整する。どのトランザクションが失敗したか、どのトランザクションがリトライされたか、重複したか、キューに残ったか、どの顧客に通知が必要かを判断する。プロバイダの復旧はアプリケーションの正確性を保証しない。復旧目標には、HTTP ヘルスチェックだけでなく、バックログのクリアとデータ検証を含めるべきである。

小規模組織の場合、比例するバージョンは控えめにできる：外部のアップタイムチェック、別のプロバイダ上のステータスページ、エクスポートされた連絡先詳細とランブック、テスト済みバックアップ、既知の手動手順、およびマルチクラウドコストが正当化されるかどうかについて文書化された決定。説明責任は最大限のアーキテクチャと同義ではない。意識的なリスク決定が偶発的な依存関係に取って代わったことを示す能力である。

コントロールプレーンとネットワークの説明責任のスコアカード

取締役会、規制当局、または主要顧客は、正確な質問をするためにプロプライエタリなソースコードを必要としない。観察された障害モードに対応する証拠が必要である。

スコアカードは行を横断して読むべきである。独立したステータスのない機能フラグは十分ではない。プロバイダとルーターの多様性のない4つのインターコネクトアタッチメントは十分でないかもしれない。事前にプロビジョニングされた復旧のないマルチリージョンアプリケーションは、依然としてグローバルコントローラーに依存する可能性がある。信頼性はコントロールの構成と、その構成が障害下で機能するという証拠から生じる。

永続的なシグナルは共有権限の速度である

クラウドプラットフォームは意思決定を集中化することで価値を生み出す。1つのポリシーが数千のプロジェクトを統治できる。1つのネットワークが大陸間のトラフィックを運ぶことができる。1つの API が数秒でインフラを作成できる。同じレバレッジがエラーの爆風半径を決定する。

したがって、2025年6月の障害はヌルポインタとして最もよく記憶されるべきではない。ヌルポインタは普通のソフトウェア欠陥である。これをグローバルに重大にしたのは、休止コード、無効なポリシー、迅速な複製、リージョナルリーダー、同期再起動、共有モニタリング、そして下流プロバイダが1つのチェーンを形成したことである。システムは分散されていたが、権限は十分に分割されていなかった。

Google の対応は正しいテーマを特定した：増分伝搬、機能フラグ、モジュール式障害、バックオフ、独立したコミュニケーション。顧客は、それらの変更が機能するという証拠を期待しつつ、まだ自分たちが所有するリスクについて正直であるべきである。ワークロードはリージョンに分散されても、依然として1つのグローバル決定に依存する可能性がある。ビジネスは2つのネットワークを購入しても、依然として運命への1つのルートを使用する可能性がある。ステータスページは公開されても、依然としてインシデント内に存在する可能性がある。

適切な説明責任の基準は、グローバルクラウドが決して失敗してはならないということではない。グローバル権限はそれを検証する制御よりも速く移動してはならず、リージョナルシステムは安全でない共通状態を拒否または生き残ることができなければならず、ネットワークと復旧パスは名前だけでなく運用において独立していなければならず、顧客は行動する時間がある間に障害を見ることができなければならない。クラウドコントロールプレーンでは、速度は力である。回復力は、その力がどこまで移動できるかに制限を設けることから始まる。