DelhiデータセンターとGoogle Cloud劣化：サードパーティ接続点依存のリスク

2026年6月5日未明、インド・ニューデリーのデータセンターで火災が発生した。運営するのはST Telemedia Global Data Centres（STT GDC）で、施設はTata Communicationsが借り受けるNext-Gen Tower内にある。Google Cloudはこの建物内に自社のPOP（Point of Presence、クラウド事業者がネットワーク相互接続のために設置する拠点）を置いており、火災を受けてこの設備を停止せざるを得なくなった。結果として、デリー・チェンナイ・ムンバイなど複数都市でGoogle Cloud利用者の通信遅延とパケット損失が数週間続いた。Google Cloud自体の設備が焼けたわけではない。被災したのは、自社が直接契約していないコロケーション事業者の建物だった。この構造は、マルチクラウド設計や事業継続計画が見落としがちな「相互接続点」という隠れた単一障害点を浮き彫りにする。

予備知識

• コロケーション: データセンター事業者の建物・電源・空調を借りて、自社のサーバーやネットワーク機器を設置する利用形態
• POP（Point of Presence）: クラウド事業者やISPがネットワーク相互接続のために置く拠点。自社所有でない建物内にあることも多い
• ピアリング: 事業者同士がネットワークを直接つなぎ、トラフィックを交換する取り決め
• マルチAZ: 同一リージョン内の複数のアベイラビリティゾーン（独立した設備群）にシステムを分散させる冗長化構成

クラウド／障害

クラウドアカウント停止という盲点：Railway全面障害に学ぶ隠れ依存

2026年5月19日、PaaS（アプリケーションの実行環境を丸ごと提供するクラウドサービス）大手のRailwayが約8時間の全面障害を起こした。原因はソフトウェアのバグでも攻撃でもない。Google Cloud（GCP）の自動システムが、[…]

Delhiのデータセンター火災で何が起きたのか

火災は現地時間2026年6月5日午前2時47分ごろ、Next-Gen Tower内のバッテリー室で発生した[1]。原因はリチウムイオン電池ユニットの発火とみられている[1]。施設スタッフに死者はなかったが、消火にあたった消防士2人が負傷した[1]。STT GDCとTata Communicationsは顧客向け書簡で「広範囲な被害」があったと説明し、破壊されたインフラの損失額は数百クロールルピー規模と報じられている[1]。入居していた国際SIMカード事業者Matrix Cellularは20年分を超えるデータ喪失の恐れに直面し、ISPのR2 Netは200万ドル（1ドル=155円換算で約3億1000万円）の損失を見込んだ[2]。

クラウド／障害

Coinbase障害報告で読み解くAWS単一AZ熱障害とMSKサイレント障害

2026年5月7日、米暗号資産取引所のCoinbaseが約8時間にわたり取引停止に陥った。原因はAWS（Amazon Web Services）の米バージニア北部リージョンus-east-1で起きた、1つのアベイラビリティゾーン（AZ、独[…]

Google Cloudの接続点はなぜ孤立したのか

Google Cloudはこの建物内にローカルPOPを構えていた。火災を受けてGoogleはPOPを稼働させるネットワーク機器を停止した[3]。その結果デリー拠点の相互接続が切り離され、デリー・チェンナイ・ムンバイなど周辺都市発のトラフィックで利用可能なネットワーク容量が低下した[3]。The Registerは6月14日時点でも「1週間経ってもGoogle Cloudのインド向けネットワークは遅いままだ」と報じている[4]。Googleはバックボーン容量の最適化、デリーPOPの拡張、一部ピアリングパートナーの切替を進め、6月下旬にかけて平常運用に近づけたとされる[5]。

障害

交渉最大の障害は「信頼の欠如」――プロスポーツ労使紛争に学ぶ克服法｜MBAファシリテーション＆ネゴシエーション Day6

MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]

相互接続点依存というアーキテクチャの盲点

多くの運用チームは、クラウド事業者との契約範囲だけを可用性設計の対象にする。だがクラウド事業者自身も、地域内の相互接続やネットワーク経路の一部を、自社が直接運用しない第三者施設に依存している。今回のケースでGoogle Cloudは、STT GDC/Tata Communicationsという上流のコロケーション事業者と直接の契約関係を持つエンドユーザーではない。それでも同社のPOPが同じ建物内にあったため、火災という物理的な被害がそのままクラウドの地域可用性へ波及した。リージョンやアベイラビリティゾーンの冗長設計だけでは、この経路のリスクは防げない。

直接契約するクラウド障害と相互接続点依存リスクを比較する

両者は検知手段も復旧手段も異なり、対策も別々に立てる必要がある。

表の最終行が示すとおり、今回の障害はクラウド側のSLA対象外でありながら、実際の利用者体験には数週間単位で影響した。契約書を確認するだけでは、この種のリスクは見えてこない。

よくある質問（FAQ）

POP（Point of Presence）とは何か

POPとは、クラウド事業者やISPがネットワーク相互接続のために設置する拠点であり、必ずしも自社が所有する建物内にあるとは限らない。

マルチクラウド構成にしていれば今回の障害は防げたか

防げない。POPは複数のクラウド事業者や通信キャリアが同じ建物や同じ回線設備を共有していることがあり、契約先を複数に分けるだけでは相互接続点の単一障害点を解消できない。

自社が使うクラウドリージョンの接続経路を確認する方法はあるか

クラウド事業者の一部はネットワークトポロジーやピアリング拠点の概要を公開しているが、建物単位の詳細は開示されないことが多く、契約担当窓口を通じた個別確認が必要になる。

まとめ

Delhiの火災は、自社と直接契約のないコロケーション事業者の設備障害が、クラウドの地域可用性を数週間単位で悪化させ得ることを示した。マルチAZやマルチクラウドの冗長設計だけでは、この種の相互接続点依存リスクは解消できない。運用担当者は、利用中のクラウドリージョンがどの物理拠点のPOPに依存しているかを契約窓口経由で確認し、代替経路や許容できる遅延劣化の基準をあらかじめ整理しておく必要がある。次の四半期の予算計画には、地域冗長化の見直しとBCP文書の更新を組み込む価値がある。

出典