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 に対して群れ効果（herd effect）が発生しました。また、公開 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 はタスク作成を絞り、トラフィックをマルチリージョンデータベースにルーティングする必要がありました。言い換えれば、最初の障害はグローバルデータの安全でない解釈であり、2 番目は共有依存関係を過負荷にした復旧動作でした。

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

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

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

リージョンデプロイはリージョン学習を生まなかった

プログレッシブデリバリーは、距離を証拠に変えることになっています。変更が小さな集団に到達し、オペレーターがその動作を観察し、その後初めてさらに進みます。Google は新しい Service Control コードに対してリージョンごとのバイナリロールアウトを使用しましたが、デプロイメントは後に失敗したコードパスを決して実行しませんでした。アクティベーションポリシーは異なる配信メカニズムに従い、それはクォータ状態を数秒以内にグローバルにするように最適化されたものでした。コードは段階的でしたが、コードの意味はそうではありませんでした。

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

Google の現在のインフラガイダンスはこのリスクを認識しています。信頼性のビルディングブロックガイドは、グローバルリソースはゾーンやリージョンのインフラインシデントに対して回復力があるが、重大な構成エラーがグローバルスコープを持つ場合には単一障害点になる可能性があると述べています。変更の注意深い管理と、極めて要求の厳しいワークロードに対してはリージョンの多層防御フォールバックを推奨しています。関連する管理と監視のガイダンスは、プログレッシブデプロイとグローバルリソースに対する追加精査を助言しています。2025 年のインシデントは、同じ論理をプロバイダー内部に適用しています：グローバルな到達範囲は、物理障害に対する信頼性の利点であると同時に、悪い論理状態に対する爆破半径の危険でもあります。

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

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

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

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

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

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

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

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

ステータスシステムは、説明すべき停止を共有した

最初の約 1 時間、顧客は公開の Cloud Service Health インシデントレポートを受け取れませんでした。なぜなら、そのインフラ自体がダウンしていたからです。一部の顧客は Google Cloud 上で監視も実行していたため、サービスとその証拠の両方が同時に失敗しました。停止は本番だけでなく、認識の制御、つまり何が起こっているかを知り、フェイルオーバーすべきかを決定し、状況をユーザーに説明する能力をも損なわせました。

これは前例のないことではありませんでした。2020 年 12 月 14 日の Google のグローバル認証停止時、インシデントレポートによれば、Cloud Support の内部ツールが影響を受け、顧客はコンソールでサポートケースを作成または表示できず、ダッシュボード通信は主要な影響が終了するまで遅延しました。そのイベントは、中央 ID システムの容量を減少させる自動クォータ管理から発生しました。既存のネットワークデータプレーン構成は動作し続けましたが、認証されたサービス、API アクセス、コンソール、および多くの内部ツールは動作しませんでした。メカニズムは 2025 年とは異なりますが、繰り返しの懸念は、ID、サポート、監視、および通信が、それらが診断すべきサービスと運命を共にし得ることです。

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

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

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

この分離にはガバナンス上の理由があります。遅延したステータスページは顧客の行動を変えます。チームは、自身のデプロイメントを検索して時間を浪費したり、危険なロールバックを行ったり、機能不全のコントロールプレーンにスケーリングしたり、確認を待っている間にフェイルオーバーを延期したりする可能性があります。サポートの沈黙は、下流のプロバイダーが推測を公表することにもつながります。したがって、通信の可用性は、エンジニアリング作業が開始された後に追加される礼儀ではなく、測定可能な検出と公開の目的を備えたリスク制御です。

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

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

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

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

これが、災害復旧におけるコントロールプレーンのパラドックスです。復旧計画内のアクションは、多くの場合、通常のサービスよりもテストされておらず、よりコントロールプレーンに依存しています。ランブックには「第 2 リージョンにキャパシティを作成する」や「ロードバランサーを切り替える」とあるかもしれませんが、それらは API 操作です。開始した停止がリソース作成やグローバルロードバランサー更新を損なわせた場合、復旧ステップはまさに要求されたときに利用できません。

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

各復旧ステップについて、オペレーターは、それが要求する API、ID プロバイダー、ネットワーク経路、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 年のヌルポインタを防げたかどうかではありません。それらの背後にあるガバナンス手法が標準になったかどうかです。共通の権限をマッピングし、安全な状態を永続化し、緊急制御をプライマリ障害ドメインの外に保ち、壊滅的な相関障害をテストすることです。修復プログラムは、その制御パターンがポストモーテムを書いたチームを超えて伝わって初めて制度的価値を持ちます。

ピアリングとトランジットの多様性は、回線数ではなく運命の問題である

クラウドの可用性はネットワークを通じて顧客に届きます。ワークロードはリージョン内では健全でも、ユーザーはエッジ、バックボーンルート、ピアリングセッション、トランジットプロバイダー、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 がないことを説明しています。パートナーインターコネクトガイダンスは、推奨される 99.99%トポロジーのために、2 つのメトロとエッジ可用性ドメインにわたる 4 つの VLAN アタッチメントを要求しています。また、Google ネットワーク外のプロバイダーセグメントは独自の保証が必要であるとも述べています。複数のサービスプロバイダーを使用すると可用性が向上する可能性がありますが、それはそれらの基盤となる経路が実際に分離されており、フェイルオーバー中に十分な容量がある場合に限ります。

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

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

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

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

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

Google の信頼性ドキュメントは、ロケーションスコープとアプリケーションの信頼性を有用に区別しています。グローバルリソースは、リージョンのインフラ停止に対して非常に回復力がある一方で、構成を通じて依然として単一障害点になる可能性があります。マルチリージョンリソースは 1 つのリージョンの損失を生き残ることができますが、グローバル ID、API 管理、ネットワーク制御、またはグローバルフロントエンドに依存し続けます。顧客は、地理と権限の両方をマークする依存関係グラフを必要とします。

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

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

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

Cloudflare は、1 つのプロバイダーインシデントを別の事業者のための依存関係の教訓に変えた

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 の報道は、人気のあるオンラインサービスにわたる可視的な混乱と、何万ものユーザー報告を記録しました。そのような報道は公共への到達範囲を示すのに有用ですが、停止報告の数は影響を受けた人、リクエスト、または財務損失の国勢調査ではありません。より強力なエビデンスは、プロバイダーの技術レポートと顧客のトランザクションデータから得られます。説明責任は、過小評価とスペクタクルの両方に抵抗すべきです。正確なグローバル損失総額が利用できない場合でも、広範な依存関係のカスケードは重要です。

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

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 月以降、ルートポリシー強制の機能ドメインとルータービルドテストの改善を約束しました。各コミットメントは、それぞれのプログラム内で完了したかもしれませんが、公開記録は、プラットフォームの共通モードリスクが時間とともにどのように変化したかを示す 1 つの継続的な保証ビューを提供していません。

Google の SRE の本は、ポストモーテムを学習システムとして説明し、アクションアイテムを原因に結び付け、複雑なインシデントを個人の非難に矮小化することなく説明しています。同じ原則が外部への説明責任を支えます。エビデンスを公表する目的は、従業員をさらしたり、顧客に Google のネットワークを運用させたりすることではありません。それは、顧客が一時的な回避策と永続的な制御を区別し、何が未解決のままかを確認し、自身のリスク対応が適切かどうかを判断できるようにすることです。

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

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

どの顧客も、Google の内部 Service Control バイナリをフィーチャーフラグで制御したり、そのポリシーテーブルの複製方法を変更したりすることはできません。プロバイダー全体の障害後に、単に「より良いアーキテクチャにしろ」とだけ言うアドバイスは、責任を不当に転嫁します。それでも、顧客はプロバイダー停止が自社のビジネスにどれだけの権限を持つかについて、結果を伴う選択を行います。

サービングパスから始めます。すべての Google Cloud 管理 API が 3 時間利用できない場合に、どのユーザートランザクションが継続するかを特定します。新しいデプロイを一時停止、オートスケーリングを凍結、IAM 変更を不可、ロードバランサー変更をブロック、サポートにアクセスできない状態でテストします。キャパシティ、クレデンシャル、証明書、キュー、またはスケジュールされたジョブが制限要因になる時点を測定します。結果はしばしばバイナリの答えではなく曲線になります。サービスは現在の負荷で一定期間継続し、その後、日常的な制御アクションが蓄積するにつれて劣化します。

次に、オペレーターアクセスをテストします。プライマリクラウド ID 経路を必要としない取得と検証が可能な非常用クレデンシャルを保持します。最小限のインシデントワークスペース、連絡先リスト、ランブック、アーキテクチャダイアグラム、ステータスパブリッシャーを Google Cloud の外に維持します。チームが、そのスイートが Google ID を共有している場合に、企業コラボレーションスイートなしでネットワークキャリアや重要サプライヤーに連絡できることを確認します。すべての緊急ツールについて、隠れた DNS、メール、シングルサインオン、シークレットの依存関係を監査します。

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

コントロールプレーン停止中に作成できないものを事前プロビジョニングします。これには、リージョンロードバランサー、DNS レコード、セカンダリクラスター、スタンバイデータベース、クォータ、サービスアカウント、アーティファクト、ネットワークトンネルが含まれ得ます。最後の既知の良好な構成が使用可能であるように、変更を十分に小さく保ちます。機能不全のプロバイダーに再試行やスケールリクエストを大量に発行する代わりに、非必須機能を切り捨てる劣化モードを練習します。

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

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

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

取締役会、規制当局、または主要顧客は、正確な質問をするのに独自ソースコードを必要としません。観測された障害モードに対応するエビデンスが必要です。

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

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

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

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

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

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