インターネットが単一障害点になった — クラウド依存リスクのSRE的解剖学

「自己治癒システムが自己破壊システムになる瞬間、我々は自動化のパラドックスと向き合う。」

はじめに:2025-2026 クラウド障害年表

過去18か月間、グローバルなインターネットインフラは前例のない連鎖障害を経験した。個別の事件ではなく、構造的なパターンである。

日時	事象	影響範囲	根本原因
2024.07.19	CrowdStrikeグローバル障害	850万Windowsデバイスのブルースクリーン	設定アップデートのグローバル即時展開
2025.09.26	韓国NIRSデータセンター火災	858TBの政府データが永久消失	同一建物内のバックアップ、DRセンター未稼働
2025.10.19	AWS US-EAST-1 DynamoDB障害	14.5時間、1,000以上のサービス停止	DNSレースコンディション
2025.11.18	Cloudflare第1次障害	インターネットトラフィックの20-25%に影響	設定変更のグローバル伝播、Rustパニック
2025.12.05	Cloudflare第2次障害	HTTPトラフィックの28%に影響	同一パターンの反復(17日後)
2026.02.20	Cloudflare第3次障害	BYOIPプレフィックスの25%が削除	API空文字列クエリ → 全件削除

これらの事件は一つのテーゼに収束する:インターネットそのものが一つの単一障害点(Single Point of Failure)になりつつある。 クラウドインフラの集中、自動化の複雑性、そしてデジタル主権の不在が生み出した構造的脆弱性である。

本稿では三つの軸で分析する。

レースコンディション → グローバル障害:単一のバグがどのようにインターネットを止めるのか
インフラ集中のパラドックス:「Too Big to Fail」となったクラウドインフラ
デジタル主権戦争:サーバーの所在地ではなくコントロールプレーンが決める管轄権

Part 1: レースコンディション → グローバル障害

DynamoDBがインターネットから消えた夜

2025年10月19日夜11時48分(PDT)。dynamodb.us-east-1.amazonaws.comのDNSレコードが空になった。IPアドレスが0個。DynamoDBが文字どおり「インターネットから消えた」。

Signal、Slack、Zoom、Reddit、Snapchat、Roblox、Venmo、Robinhood、Coinbase、Duolingo、Ringカメラ、Amazonリテール、Prime Video、Alexa — 1,000以上のサービスが連鎖的に停止した。プレミアリーグのサッカー試合にまで影響が及んだ。

根本原因はDNS管理システムの**潜伏レースコンディション(latent race condition)**だった。

技術的詳細:DNS PlannerとEnactorの衝突

DynamoDBのDNS管理は二つのコンポーネントで構成される。

DNS Planner:ロードバランサーの状態を監視し、トラフィック重み付きの「DNSプラン」を生成
DNS Enactor:DNSプランをRoute 53に適用。3つのアベイラビリティゾーンに各1つずつ、計3つのインスタンスが独立して稼働

ここに重要な設計上の決定があった。Enactorインスタンス群は意図的に分散ロック(distributed lock)なしで運用されていた。グローバルなデッドロックを避けるためである。「結果整合性で十分」という仮定 — 正常状態では正しかった。

障害シーケンスはこうだ。

1. Enactor #1が異常に遅くなる(原因不明)
2. 同時にPlannerが異常に速く新しいプランを生成する(原因不明)
3. Enactor #2が最新プランを高速に全エンドポイントへ適用
4. Enactor #2完了 → 古いプラン世代に対するクリーンアップ(cleanup)プロセスがトリガー
5. その瞬間、遅れていたEnactor #1がさらに古いプランをリージョンエンドポイントに適用完了
   → 最新プランを上書き
6. Enactor #1のstale-checkが失敗 — 自分のプランが削除対象であることを認識できない
7. クリーンアッププロセスが古いプランを検出 → リージョンDynamoDBエンドポイントの全IPを削除
8. 自動復旧不可能な不整合状態に陥り → 手動介入が必要

Gergely Orosz(Pragmatic Engineer)が指摘したように、AWSはポストモーテムでEnactor #1がなぜ遅くなったのか、Plannerがなぜ加速したのか、クリーンアッププロセスがなぜ選択的ではなく全削除を実行したのかを説明していない。「何が失敗したか」だけを語り、「何が失敗を引き起こしたか」は語っていないのだ。

復旧が障害より難しい理由

DynamoDB DNSは約2時間37分で復旧した。だがインシデント全体は14.5時間続いた。なぜか。

DynamoDBが復旧すると、EC2の内部システムであるDWFM(DropletWorkflow Manager)が一斉にリース再確立を試みた。これがcongestive collapse(輻輳崩壊)を引き起こした。各リース試行がタイムアウトし、タイムアウトしたリクエストがキューに積まれ、キューが処理速度より速く成長する正のフィードバックループ。古典的なthundering herdパターンである。

DynamoDB復旧 (2:25 AM)
  → DWFM全フリートが同時に再接続を試行
    → リースタイムアウト > リース完了速度
      → キューが処理より速く成長
        → congestive collapse (4:14 AMまで持続)
          → 手動スロットリング + 選択的ホスト再起動で介入

そして第二波が来た。NLB(Network Load Balancer)のヘルスチェックが、ネットワーク状態がまだ伝播していない新規EC2インスタンスを「不健全」と判定し、自動AZ DNSフェイルオーバーをトリガーして、マルチAZロードバランサーの容量を取り除いてしまった。これによりLambdaの内部フリートがアンダースケールし、午前7時に二度目の障害波が発生した。

復旧システムが復旧プロセスの中で新たな障害を生み出した。復旧が障害より難しかった。

SREの教訓:自己治癒が自己破壊になるパラドックス

DEV Communityの分析が核心を突いている:「レジリエンスのために設計された自己治癒システムが、障害の主要ベクトルになった。」AWSは復旧を始めるために世界中の自動化を停止しなければならなかった。

ここからSREが持ち帰るべきものは:

自動復旧にはハードセーフティバウンドが必要だ。 クリーンアッププロセスが「全DNSレコードの削除」を実行できてはいけない。削除上限が必要だ。
結果整合性はクリティカルパスのDNSには危険だ。 分散ロックのデッドロックリスクを避けようとして、全リージョン障害のリスクを作り出してしまった。
サーキットブレーカーが依存関係の境界ごとに必要だ。 EC2、Lambda、STS、IAM、Connect、NLB — すべてDynamoDBに依存していたが、効果的なサーキットブレーカーがなかった。DynamoDBが死ねば皆が死に、生き返ると皆でスタンピードした。
復旧モードのしきい値は正常状態とは異なるべきだ。 NLBヘルスチェックは正常状態の判定基準で復旧中のインスタンスを評価した。復旧中には別のしきい値が必要だ。

Part 2: インフラ集中のパラドックス

Cloudflare3連続障害 — 同一アンチパターンの反復

Cloudflareは2025年11月から2026年2月までの4か月間に三度の大規模障害を経験した。三件すべてが同一の構造的欠陥を共有している:設定変更のグローバル即時伝播、カナリアデプロイの不在。

第1次障害(2025.11.18):ClickHouse DB権限の変更がBot Managementのフィーチャーファイルのメタデータを2倍に増やし、ハードコードされた200個の上限を超過。Rustコードの.unwrap()がパニックを起こした。設定は数秒以内に全世界のフリートに伝播した。カナリアなし、検証ゲートなし。結果:インターネットトラフィックの20-25%に影響、ChatGPT・Spotify・Discord・Claudeなど月間アクティブユーザー24億人が影響圏に。

さらに深刻な問題があった。Cloudflareのダッシュボードのログインがturnstile(CAPTCHA)に依存し、TurnstileはWorkers KVに依存しているが、これら三つのサービスすべてがダウンしていた。エンジニアが障害を修正するためにアクセスすべきダッシュボードが、障害中のサービスに依存している循環依存。 SREアンチパターンの教科書的事例である。

第2次障害(2025.12.05):CVE-2025-55182対応のためのWAFバッファ拡張ロールアウト中、テストツールの非互換性を発見したエンジニアがグローバル設定システムでテストツールを無効化。FL1プロキシサーバーでLuaのnil参照エラー。HTTPトラフィックの28%に影響。第1次障害から17日後。第1次のポストモーテムで約束した段階的設定デプロイを「まだ実装できていない」と認めた。

第3次障害(2026.02.20):自動クリーンアップのサブタスクがBYOIPプレフィックスを照会する際、?pending_deleteパラメータを値なしで渡した。サーバーは空文字列を「全件照会」と解釈。約1,100個のBYOIPプレフィックス(全体の25%)が削除され、BGP経路が撤回された。Uber Eats、Bet365、Wikipediaなどがアクセス不能に。欠陥のあるコードは15日前にマージされていたが、ステージング環境のモックデータでは捕捉されなかった。

CrowdStrikeとの比較:同一のアンチパターン

次元	CrowdStrike (2024.07)	Cloudflare (2025.11)
トリガー	設定アップデート	設定アップデート(フィーチャーファイル)
検証	自動バリデータが見逃し	検証なし
デプロイ方式	グローバル、即時	グローバル、数秒
カナリア	なし	なし
影響範囲	850万Windowsデバイス	インターネットトラフィックの20%超
失敗モード	ブルースクリーン(クラッシュ)	Rustパニック(.unwrap())

4sysopsの分析:「CloudflareはCrowdStrikeのミスを繰り返した — 小規模なホストグループで先にテストせず、インフラ全体をアップデートした。」

これは個別企業のミスではなく業界全体の構造的問題である。Meta(2021、BGP設定)、Datadog(2023、Ubuntuアップデート)、Google Cloud(2024、Spannerクォータ) — すべて同一パターンだ。

「Too Big to Fail」— インフラ版のリーマン・ブラザーズ

数字で見てみよう。

Cloudflareは全世界のウェブサイトの20.4%、上位100万サイトの**48.7%**にサービスを提供
リバースプロキシ市場シェア81.5-82.3%(2位のAmazon CloudFrontは1.6%)
毎秒5,000万件超のHTTPリクエストを処理
CDN市場のHHI(ハーフィンダール・ハーシュマン指数):3,410(2,500超は「高度集中」判定)
インターネットトラフィックの**20-25%**がCloudflareを通過

2008年金融危機との比喩は的を射ている。当時、規制当局は特定の金融機関の崩壊が連鎖的な経済不全を引き起こすことを認識し、「システム上重要な金融機関(SIFI)」指定と規制フレームワークを構築した。インターネットインフラも同じ問題を抱えているが、規制フレームワークも安全網も存在しない。

さらにセキュリティ面のリスクもある。Krebs on Securityが指摘したように、Cloudflare障害時には企業がCloudflareに委任していたSQLインジェクション防御、クレデンシャルスタッフィング防御、XSSブロック、ボット緩和がすべて消える。攻撃者にとっては保護レイヤーが剥がされた攻撃ウィンドウが開かれることになる。

SREの教訓:依存関係の隔離とfail-open

Cloudflareの「Code Orange」対応はそれ自体がSREの教訓だ。

設定をコードのように扱え。 Cloudflareはソフトウェアリリースには適用していた保護ゲートを設定変更には適用しなかった。Health Mediated Deployment(HMD) — 従業員トラフィック先行、その後に顧客比率を段階的に上げ、異常検知時に自動ロールバックする構造が必要だ。
Fail-open設計。 Bot Managementの失敗が5xxを返す代わりに、トラフィックを通過させるべきだ。可用性が優先される経路では、未知/エラー状態は「許可」をデフォルトにするべきだ。
インシデント対応ツールは監視/制御対象のシステムから独立しているべきだ。 ダッシュボード → Turnstile → Workers KVの循環依存は、障害時にエンジニアのアクセスそのものを遮断した。
サーキットブレーカーで伝播を遮断せよ。 設定デプロイ中に異常なエラー率を検知すれば直ちにロールアウトを停止する仕組み、削除操作が想定範囲を超えれば停止する仕組みが必要だ。
プロダクションのRustコードで.unwrap()は禁止だ。 エラー経路の.unwrap()はC/C++プロダクションのassert()と同じだ。セーフティクリティカルなコードはすべてのエラー経路を明示的に処理しなければならない。

Part 3: デジタル主権戦争

韓国NIRS火災 — 主権はあったがレジリエンスがなかった事例

2025年9月26日、大田の国家情報資源管理院(NIRS)データセンターでリチウムイオン電池が保守中に爆発した。結果は以下の通り。

858TBの政府データの永久消失 — 2018年から2025年までの行政決裁、政策研究、公共サービス記録
745の政府システムに影響、700超のデジタルサービスが停止
モバイル本人確認、税務処理、緊急対応システム、郵便サービスが麻痺
75万人の公務員データに影響
10月中旬までに約1/3しか復旧せず;喪失データの大半は永久に復旧不可

なぜこうなったのか。G-Driveシステム(2017年構築)はデータ主権の確保とセキュリティ最大化のために設計された。致命的な欠陥:バックアップが同一建物内の別装置に保存されていた。 火災が原本とバックアップを同時に破壊した。公州にある災害復旧センターは13年間遅延し、建設は完了したが予算不足で稼働できなかった。2025年の割当予算は16億ウォン(110万ドル)に過ぎなかった。

254億ウォンの2024年IT基盤改善予算は執行されなかった。装備の34.6%が老朽化していた。

ASPI Strategistの評価が要点を突いている:「国有は冗長性を保証しなかった。形式的な統制はエンジニアリングの規律を代替できなかった。」

この事件はデジタル主権議論の核心にあるパラドックスを示している。主権のためにすべてを国内に、政府の統制下に置いたが、主権なきレジリエンスは単一障害点になる。ハイパースケールなクラウド環境がオーダーメードの国家システムよりレジリエンス設計で優位に立つケースが多い。

US CLOUD ActとFISA 702 — サーバーの所在地ではなく提供者の国籍が管轄権を決める

デジタル主権のもう一つの軸は法的管轄権である。ここで核心となる二つの法律。

US CLOUD Act(2018):米国政府が電子通信サービス提供者にデータの開示を強制できる — データが物理的にどこに保存されていようとも。 フランクフルト、東京、ソウルのサーバーに保存されたデータも、提供者が米国法人であればアクセス可能だ。「EUデータリージョン」を選んでもCLOUD Act露出は変わらない。いかなる契約もこれを無効化できない。

FISA Section 702:CLOUD Actが個別令状ベースなら、FISA 702は年単位のプログラム水準の承認で外国人通信の大量収集を許可する。個別令状なしに。EU居住者のデータが当事者や欧州機関の知らないうちにアクセスされうる。

これは抽象的な法律問題ではない。実際の前例がある。

Microsoftがイスラエル軍部隊(Unit 8200)のAzureアクセスを遮断
X(Twitter)/イーロン・マスクが1.2億ユーロの罰金後、欧州委員会の広告アカウントを遮断
米国がウクライナとの情報共有を一時中断
バイデン政権のAI拡散規則が欧州同盟国への先進チップ販売を制限

キルスイッチ・シナリオ — コントロールプレーン依存の政治的リスク

Andrea Fortunaの分析(2026年1月):「病院が患者システムにログインできない。税務ポータルが『サービス利用不可』を表示する。」

米国政府がクラウドアクセスを遮断できる法的メカニズムは既に存在する。

IEEPA(国際緊急経済権限法):国家安全保障/外交政策/経済関連の非常事態宣言時の商取引規制権限
輸出管理:商務省Entity Listを通じた技術輸出制限
連邦契約権限:米国テック企業に対する契約による脅し

核心的な弱点はコントロールプレーン依存である。

IAM/SSO(認証・認可)
課金および契約執行
コントロールプレーンAPI
鍵管理システム
プラットフォームガバナンスおよびサービス規約

「そのスイッチが外部の管轄権に属するとき、依存関係は設計上、政治的になる。」

欧州の対応:GAIA-XからEURO-3Cまで

欧州は米国クラウド依存度を下げるための多重イニシアチブを推進中だ。

GAIA-X:2020年にフランス・ドイツの共同で発足、100億ドル超の投入、180超のデータスペース。しかし米国企業(AWS、Google、Microsoft)が参加したため「ビッグテックのトロイの木馬」との批判も。

EuroStack:10年間で3,000億ユーロの投資計画、初期100億ユーロの技術ファンド。

EURO-3C(2026.03発表):Telefonica主導、欧州委員会支援、70超のエンティティが参加。新プラットフォームをゼロから構築するのではなく、既存の国家インフラを連合ネットワークで結ぶ現実的アプローチ。Telefonica CDO:「欧州がゼロからハイパースケーラーを作るのは非常に難しい。欧州は今や技術を使うだけでなく技術を作ることに投資すべきだ。」

フランスSecNumCloud 3.2:ANSSIの最高クラウドセキュリティ基準。FISAに対応して欧州法の排他的適用を求め、域外米国法を排除。OVHcloud、3DS OUTSCALEが認証取得。

Gartner予測:欧州ソブリンクラウドIaaS支出が2025年の69億ドルから2026年に126億ドルへと83%成長。2027年には北米を上回る見通し。

日本のハイブリッドモデル:技術・運用・財政の3軸主権

日本は別のアプローチを取った。孤立ではなくハイブリッドモデル — 主権的統制を維持しつつ最先端技術へのアクセスも確保。

政府クラウドシステムが671から2,918へと335%増加、約330のセキュリティベンチマーク要件で管理。

3軸主権モデル:

技術主権:機微情報を扱うすべてのデータセンター、ネットワーク、サーバーが日本国内に所在
運用主権:日本人スタッフが運用、暗号鍵管理、ネットワーク監視、パッチサイクルを担当
財政支援:経済安全保障推進法(METI、2024)で国内クラウドサプライチェーンを支援

SoftBank+Oracleのソブリンクラウド(Oracle Alloyベース、2026年4月東日本でローンチ)、FujitsuのTakane LLM(パブリッククラウドを使用できないデータ用)など民間パートナーシップも活発だ。

SREの教訓:依存関係を設計せよ

マルチクラウドは運用モデルだ。 Gartnerによると企業の76%が2つ以上のパブリッククラウドを使う。単なるトレンドではなく運用モデルとしてのマルチクラウド。
コントロールプレーンの所有が真の主権だ。 データセンターの所在地ではなく、IAM、課金、API、鍵管理、ToSが真のコントロールポイントだ。
鍵管理の主権は妥協不可だ。 暗号鍵がクラウド提供者ではなく組織/国家エンティティによって管理されるべきだ。
クラウド提供者のAPIアクセスが撤回されるシナリオをアーキテクチャに反映せよ。 政治的リスクをエンジニアリング問題に転換しなければならない。

結論:SREができること

これら三つの軸の分析は一つの結論に収束する:依存関係は隠れており、障害は依存関係に沿って伝播し、復旧は障害より難しい。

以下はSREチームが明日から実行できるチェックリストだ。

バックアップとレジリエンス

3-2-1-1-0バックアップルールの遵守:3つのコピー、2種類のメディア、1つはオフサイト、1つはエアギャップ/不変、0個の復旧テストエラー
バックアップがプライマリと物理的に分離された場所にあることを確認(NIRSの教訓:同一建物 = バックアップなし)
四半期ごとのDRテスト — バックアップの存在ではなく実際の復旧を検証

デプロイと変更管理

すべての設定変更にカナリアデプロイを適用(コードだけでなく設定も)
設定変更のグローバル即時伝播を禁止 — 従業員トラフィック → 1% → 5% → 25% → 100%の段階
異常検知時の自動ロールバックメカニズム
設定ファイルを信頼できない入力として検証

サーキットブレーカーと障害隔離

すべての外部/クリティカルな依存関係の境界にサーキットブレーカーを実装
可用性優先の経路ではfail-open設計(エラー/未知状態 → 許可)
依存関係マップの作成 — 2次、3次の依存関係まで(「依存関係の依存関係はあなたの依存関係だ」)
インシデント対応ツールが監視/制御対象から独立しているか確認

復旧設計

復旧モードのしきい値を正常状態と分離(ヘルスチェック、容量除去速度)
thundering herd防止:バックオフ、ジッター、キューベースのレートリミティング
自動復旧ロジックにハードセーフティバウンド(削除上限、変更速度制限)

デジタル主権とマルチクラウド

クラウド提供者APIアクセス撤回シナリオの文書化と対応計画
暗号鍵管理が提供者から独立していることを確認
データ分類に基づくワークロード配置 — 主権必須 vs パブリッククラウド許容
抽象化レイヤー(Kubernetes、Terraform)でポータビリティを確保

市場集中リスクへの対応

マルチCDN戦略(アクティブ・アクティブ、単純なバックアップではなく)
マルチプロバイダーDNS
同一インフラ上のバックアップは偽のセキュリティであることを認識
完全なプロバイダー障害をシミュレートする定期的フェイルオーバーテスト

2025年の業界統計:100%の組織が障害関連の売上損失を経験。大企業基準で障害あたり平均50万ドルの損失。組織は年間86時間のダウンタイムに耐えている。しかし定期的なフェイルオーバーテストを実施しているのは1/3未満。

インターネットが単一障害点になることを止めることはできない。だが我々のシステムがインターネットの単一障害点に依存する仕方は変えられる。それがSREの仕事だ。

本稿で扱った障害事例の技術的詳細は、各サービス提供者の公式ポストモーテムと独立分析に基づきます。

参考資料: