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

概要

• 2025年6月12日、クォータポリシーに意図しない空白フィールドが含まれているものが、ほぼ同時に Google Cloud のリージョン Service Control データストアに到達しました。以前にデプロイされたコードパスには、適切なエラー処理とフィーチャーフラグによる保護の両方が欠如していました。そのポリシーを処理した結果、全リージョンで Service Control バイナリがクラッシュしました。多くの Google Cloud、Google Workspace、Google Security Operations API が503エラーを返しました。既存のストリーミングおよび IaaS リソースは大部分がサービスを継続できましたが、サービスの検査、変更、スケーリング、復旧に必要な管理および API のパスが広範にわたって機能不全に陥りました。
• 直接的なバグは限定的でしたが、説明責任の欠陥はアーキテクチャ上のものでした。Google はリージョンごとに分散したサービスインスタンスと段階的なバイナリロールアウトを備えていましたが、問題のポリシーは数秒以内にグローバルに複製されました。そのため、強制終了メカニズムは、ロールアウトが本来提供するはずだったリージョン単位の学習を迂回してしまいました。その後、タスクの再起動時にランダム化された指数バックオフが欠けていたため、大規模リージョンでの Spanner に対する群集効果が発生し、復旧が困難になりました。パブリック Cloud Service Health インフラストラクチャそのものも影響を受けた環境に依存していたため、Google による最初の通知が約1時間遅延しました。
• 過去のインシデントは原因こそ異なりますが、論理的な独立性に関する問いかけが繰り返されています。2019年6月、メンテナンス自動化により複数の物理拠点のネットワークコントロールプレーンクラスタがスケジュール解除され、BGP 経路が撤回され、診断に必要なツールが混雑したネットワークを奪い合いました。2021年2月には、ピアリングクォータ変更中に潜在バグがトリガーされ、グローバルネットワークプログラミングがブロックされました。2021年3月には、不正な経路が既知のベンダー欠陥を露呈し、一部の Cloud Interconnect 拠点ではルーターベンダーの多様性が不十分でした。これらは単一のソフトウェア欠陥が再発しているのではなく、共通モードの封じ込め、変更権限、ネットワーク復旧、真実の可視性に関するテストが繰り返されているのです。
• Google には、グローバルに複製されるデータの検証、コントロールプレーン機能の分離、安全な場合のフェイルスタティックまたはフェイルオープン動作の保持、インシデントコミュニケーションの独立性維持、そして約束された是正措置が完了したことの証明責任があります。顧客はこれらのプラットフォーム制御を修復することはできませんが、どの操作がコントロールプレーン 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 はタスク作成を抑制し、トラフィックをマルチリージョンデータベースにルーティングする必要がありました。言い換えれば、最初の障害はグローバルデータの安全でない解釈であり、第二の障害は共有依存関係を過負荷にする復旧動作でした。

Google 自身の SRE 文献は、この危険性を長年説明してきました。カスケード障害への対処に関する章では、再試行と再起動がバックエンドを過負荷状態に維持する仕組みと、ランダム化指数バックオフ、グレースフルデグラデーション、制御された負荷軽減が、局所的な容量問題のカスケード化を防ぐ方法を解説しています。2025年のレポートでは、そのバックオフについてシステムを監査することを明示的に約束しています。重要なのは、Google が本の一節に従えなかったことではありません。重要なのは、再起動の対象がリージョナルで、その裏付けデータがグローバルである重要なサービスに、既知の分散システムハザードが残存していたことです。

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

ロングテールも顧客コミュニケーションにとって重要です。Google の予備レポートでは3時間のグローバルイベントと説明されましたが、インシデントページでは午後6時18分まで製品の復旧が列記され続けました。一部の製品では、API サービスが復帰した後もバックログが発生しました。主要時間帯にリクエストが失敗した顧客では、再試行、キューイングされたジョブ、部分的なワークフロー、古いキャッシュ、あるいは復旧にさらに時間を要したサードパーティサービスが存在した可能性があります。プロバイダのグリーン状態は、顧客のリカバリ開始点であり、すべてのビジネスプロセスが完全であることの証明ではありません。

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

プログレッシブデリバリーは、距離を証拠に変えることを意図しています。変更はまず小規模な集団に到達し、オペレーターがその挙動を観測し、それからさらに拡大します。Google は新しい Service Control コードに対してリージョンごとのバイナリロールアウトを使用しましたが、そのデプロイメントでは後に失敗したコードパスを一度も実行しませんでした。作動させるポリシーは別の配信メカニズム、つまりクォータ状態を数秒でグローバルにするよう最適化されたメカニズムをたどりました。コードは段階的でしたが、コードの意味はそうではありませんでした。

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

Google の現在のインフラガイダンスはこのリスクを認識しています。信頼性の構成要素ガイドは、グローバルリソースはゾーンおよびリージョンのインフライベントに対して耐性を持つが、クリティカルな構成エラーがグローバルスコープを持つ場合には単一障害点になりうると述べています。変更の慎重な管理と、非常に要求の厳しいワークロードに対してはリージョナルな多層防御フォールバックを推奨しています。関連する管理とモニタリングガイダンスは、プログレッシブデプロイメントとグローバルリソースへの追加精査を助言しています。2025年のインシデントは、同じ論理をプロバイダ内部に適用します。グローバルリーチは物理障害に対する信頼性の利点であると同時に、不良な論理状態に対しては被害範囲拡大のハザードとなるのです。

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

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

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

Google は、影響を受けたポリシー機能を分離してフェイルオープンさせ、対応するチェックが失敗した場合に API リクエストを続行できるように、Service Control をモジュール化することを約束しました。これは有意義な修正ですが、「フェイルオープン」という言葉には限界が必要です。クォータチェック、認証判断、課金制御、不正利用防止制御は、利用不可能になった場合に同じ結果をもたらすわけではありません。

低リスクのクォータチェックでは、すべての顧客 API リクエストを拒否するよりも、一時的に許容的なサービスを提供する方が安全かもしれません。プロバイダは後で利用状況を調整し、プロジェクトごとにエクスポージャーを制限し、中核的な可用性を維持できます。認証チェックでは、盲目的にリクエストを許可すると、ダウンタイムよりも悪いセキュリティインシデントを引き起こす可能性があります。リソース作成では、最近のポリシーを境界付きのローカルキャッシュに保持する方が、全面的な拒否や全面的な許可よりも安全かもしれません。適切な劣化動作は、制御の目的、信頼できる状態の新鮮さ、アクションの可逆性、詐欺、データ損失、または制御不能な支出の可能性に依存します。

Google のService Infrastructure アーキテクチャは、管理、制御、データの各プレーンを分離しつつ、認証、認可、クォータ、レート制限、監査、課金、ログ、モニタリングといったプラットフォーム機能の広さを示しています。その広さこそが、モジュール化された障害動作が重要である理由です。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 クラスタがノードやクラスタのプロビジョニング不能の影響を受けました。一部のインスタンス作成とロードバランサ更新は非常に高い率で失敗しました。既存の正常なサーバーは、新しいネットワーク接続されたサーバーを必要とするオートスケーリンググループを支援しませんでした。

これはディザスタリカバリのコントロールプレーンパラドックスです。復旧計画におけるアクションは、通常のサービス提供よりもテストが不十分で、コントロールプレーンへの依存度が高いことがよくあります。ランブックには「第二リージョンにキャパシティを作成する」とか「ロードバランサを切り替える」と書かれているかもしれませんが、それらは 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つのリンクがある」というだけで済ましてはならない理由です。レビューでは、誰が各ファイバーパスを所有しているか、それがどの建物とエッジ可用性ドメインを使用しているか、どのルーターベンダーとソフトウェアトレインが終端しているか、どの Cloud Router がその BGP セッションを制御しているか、経路がどのように再収束するか、フェイルオーバー容量が全負荷を支えられるか、両方のパスが同じプロバイダコントロールプレーンに依存していないか、を尋ねるべきです。トポロジ図を証拠として受け入れるのではなく、実際の経路変更を観測し、計画された撤回を実行すべきです。

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 に依存し続けるかもしれません。セカンドクラウドがプロバイダ集中を低減できるのは、アプリケーション、データ、アイデンティティ、デプロイメントツール、可観測性、DNS フェイルオーバーがそこで独立して動作できる場合に限ります。ロゴの数はアーキテクチャではありません。

マルチリージョンは誤った種類の障害に対しては強力な保護となる

マルチリージョン設計は依然として価値があります。それは電力イベント、局所的な容量損失、ゾーンハードウェア障害、多くのリージョナルソフトウェア問題から保護できます。誤りは複数のリージョンを使用することではなく、その言葉を独立性の完全な表明として扱うことです。

2019年のネットワーク事象は、コントロールプレーン自動化の境界が物理ロケーションを横断したために、複数のリージョンに影響を及ぼしました。2021年のピアリングクォータインシデントは、関連するコントローラと VPC リソースがグローバルスコープを持っていたため、グローバルにネットワークプログラミングに影響を及ぼしました。2025年の Service Control 事象は、ポリシープレーンがグローバルだったため、全リージョンに影響を及ぼしました。いずれの場合も、影響を受けた管理ドメイン内のアプリケーションレプリカを増やしても、共通の原因を取り除くことはできませんでした。

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

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

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

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

Cloudflare は、あるプロバイダのインシデントを別のプロバイダの依存関係の教訓に変えた

2025年6月の事象は、特に教訓的な形で企業境界を越えました。Cloudflare の自社の障害レポートによると、Workers KV は一部サードパーティのクラウドプロバイダに依存していました。その依存関係が機能不全に陥ると、Workers KV が利用不能となり、Access、Gateway、WARP、Turnstile、Images、Stream、ダッシュボードの一部、その他のサービスを含む、それを使用する広範な Cloudflare 製品が影響を受けました。Cloudflare のコア CDN およびセキュリティサービスは一律にダウンしていたわけではありませんが、その依存関係により、別のプロバイダの名前で販売される製品を通じて Google Cloud のコントロールプレーン障害が可視化されました。

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

Cloudflare は自らの説明責任の一部を受け入れました。そのレポートは、どのサービスが Workers KV に依存しているかを説明し、コアサービスが当初サードパーティストレージパスからフェイルオーバーしなかったことを指摘し、重要製品の依存関係を削減または除去する作業を概説しました。Google は上流のプラットフォーム障害に対して責任を負い続けます。Cloudflare は、重要な内部サービスが適切な継続性なしにそれに依存しうると判断したことに対して責任を負い続けます。エンドカスタマーは、自社システムへのアクセスに非常用経路があるかどうかを評価する責任を負い続けます。これらの義務は並行して存在し、相互排他的ではありません。

当時のAssociated Press の報道は、人気オンラインサービス全体にわたる目に見える混乱と数万件のユーザー報告を記録しました。このような報道は公衆への影響を示すのに役立ちますが、障害報告数は影響を受けた人々、リクエスト、または財務損失の国勢調査ではありません。より強力な証拠は、プロバイダの技術レポートと顧客のトランザクションデータから得られます。説明責任は過小評価とスペクタクルの両方に抵抗すべきです。正確なグローバル損失総額が入手できなくても、広範な依存関係の連鎖は重要です。

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

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

サービスレベルアグリーメント（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月の障害は、null ポインタとして記憶するのが最善ではありません。null ポインタは通常のソフトウェア欠陥です。これをグローバルに重大なものにしたのは、休止コード、無効なポリシー、迅速な複製、リージョンリーダー、同期された再起動、共有監視、そして下流プロバイダが1つの連鎖を形成したことです。システムは分散されていましたが、権限は十分に分割されていませんでした。

Google の対応は、増分的伝播、フィーチャーフラグ、モジュール化された障害、バックオフ、独立した通信という適切なテーマを特定しました。顧客はそれらの変更が機能するという証拠を期待すべきですが、同時に依然として自らが負うリスクについて正直であるべきです。ワークロードはリージョンに分散していても、依然として1つのグローバルな決定に依存しえます。ビジネスは2つのネットワークを購入しても、依然として1つの経路を使用して運命を共にしえます。ステータスページは公開されていても、依然としてインシデントの中に存在しえます。

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