2025年6月12日に発生した約3時間にわたる Cloudflare の大規模な停止は、クラウドインフラの依存関係と単一障害点について激しい議論を巻き起こしました。この障害は、Workers KV、Access、WARP、そして Cloudflare ダッシュボードの一部を含む多数の重要なサービスに影響を与え、Cloudflare が重要な依存関係として依存しているサードパーティサービスの障害が原因とされています。
障害タイムライン(UTC):
- 18:19 - 初期インシデント報告(アクセス認証障害)
- 18:30-19:00 - 影響評価とサービス特定
- 19:12 - 復旧の初期兆候を確認
- 19:57 - 根本原因を特定(サードパーティサービス依存関係)
- 20:32 - サービスがグローバルに復旧中
- 20:57 - 全サービス復旧、監視フェーズに移行
- 21:31 - インシデント正式解決 総継続時間: 約3時間
サードパーティ依存関係が予期しない脆弱性を生み出す
この停止で最も衝撃的だったのは、Cloudflare が Workers KV サービスがサードパーティサービスの障害により停止したことを認めたことでした。コミュニティでの議論では、Google Cloud Platform(GCP)が犯人である可能性が高いとすぐに特定されました。GCP は同時に Identity and Access Management サービスに影響を与える停止を経験していたからです。この依存関係は、Cloudflare のサービスが完全に自社のインフラストラクチャ上で動作していると期待していた多くのユーザーにとって驚きでした。他社に冗長性と信頼性を提供することで知られる会社が、自身は外部依存関係に対して脆弱であったという皮肉は、観察者たちにとって見逃せないものでした。
サードパーティ依存関係:あるサービスが適切に機能するために他社のサービスに依存すること。直接制御できない潜在的な障害点を作り出す。
カスケード障害が設計上の弱点を明らかに
この停止は、Cloudflare の新しいサービス内の懸念すべきアーキテクチャ上の決定を浮き彫りにしました。運用を続けたコア CDN およびセキュリティサービスとは異なり、多くの高度な機能は Workers KV が停止した際にカスケード障害を起こしました。コミュニティメンバーは、Access 認証、Browser Isolation、Durable Objects、そして AI を活用した機能がすべて同時に利用不可能になったことを指摘しました。これは、これらのサービスが適切な障害分離を欠いていることを示唆しており、一つのコンポーネントの障害が無関係なシステムを停止させるべきではありません。
カスケード障害:一つのシステムコンポーネントの障害が連続するコンポーネントの障害を引き起こすこと。ドミノが連鎖的に倒れるように。
影響を受けた Cloudflare サービス:
- Access (認証サービス)
- WARP ( VPN サービス)
- Browser Isolation
- Browser Rendering
- Durable Objects ( SQLite バックエンドのみ)
- Workers KV (キーバリューストレージ)
- Realtime サービス
- Workers AI
- Stream (動画サービス)
- Turnstile ( CAPTCHA の代替)
- AI Gateway
- AutoRAG
- Cloudflare ダッシュボードの一部
復旧プロセスがグローバル調整の課題を露呈
復旧プロセス自体が技術観察者たちの批判の的となりました。ユーザーは、サービスが異なる地域で一貫性なく復旧したと報告し、一部では米国で機能を体験する一方で、ヨーロッパの顧客は影響を受け続けました。復旧には、ローカルサービスを復元するためにグローバルな調整が必要だったように見え、潜在的なアーキテクチャ上の問題を示しています。
「修正にローカルフローを復旧するためのグローバル調整が必要な場合、それは設計上の問題の兆候です」
コミュニティからのこの観察は、現代のクラウドサービスがどのようにアーキテクチャ設計されているか、そして実際に約束している分散型の回復力を本当に提供しているかどうかについての根本的な懸念を浮き彫りにしています。
より広範な業界への影響
この障害は、AWS や Google Cloud を含む他の主要プロバイダーでの停止と同時に発生し、潜在的な BGP ルーティング問題を含むより広範なインフラストラクチャ問題についての憶測を呼びました。これらの停止の同時性は、現代のインターネットインフラストラクチャの相互接続性と、業界が古い問題を解決する一方で新しいタイプのシステミックリスクを作り出したかどうかについて疑問を提起しました。
この停止は、インターネットインフラストラクチャの最前線にある企業でさえ、真に回復力のあるシステムを構築する際に課題に直面していることを思い出させるものです。クラウドサービスがますます複雑で相互依存的になるにつれて、冗長性と障害許容性への従来のアプローチは、これらの新しいカテゴリの障害モードに対処するために根本的な再考が必要かもしれません。