Cloudflareの障害が露呈した世界規模の設定リスク
- •Cloudflareのグローバル設定変更により、25分間の障害でHTTPトラフィックの28%が影響を受けた。
- •数週間で2度目の大規模障害が発生。段階を踏まない即時のネットワーク更新が孕む危険性が浮き彫りになった。
- •CTOのデーン・クネヒト(Dane Knecht)氏は、影響範囲を抑えるため「フェイルオープン」と段階的リリースの導入を急いでいる。
Cloudflareはわずか2週間のうちに2度目となる大規模な世界規模の障害に見舞われた。これは、主要なウェブインフラが設定更新を処理する際、いかに脆い部分を抱えているかを物語っている。全HTTPトラフィックの約28%を遮断したこの事態は、元々はReactのセキュリティ上の欠陥を修正しようとする日常的な作業から始まったものだった。内部テストツールにバグが発見された際、エンジニアがその機能を停止させるために「グローバル・キルスイッチ」を作動させた。しかし、この変更がネットワーク全体に瞬時に波及し、意図せず広範囲にわたるHTTP 500エラーを引き起こしたのだ。
この失敗は、迅速なデプロイの必要性と、安定したインフラの安全性の間にある深刻な葛藤を浮き彫りにしている。通常、段階的なリリースサイクルを辿るソフトウェアのコードとは異なり、多くのグローバル設定ファイルはいまだにネットワーク上のすべてのノードへ同時に配信される仕組みになっている。エラーを監視しながら小規模なセグメントから順次更新を適用する「段階的リリース」が欠如しているため、システムは致命的な障害に対して脆弱なままなのだ。これを受け、Cloudflareは「フェイルオープン」処理の優先順位を引き上げた。これは、システムが壊れた設定に遭遇した際、リクエストを完全に遮断するのではなく、既知の安全な状態を維持する仕組みを指す。
業界全体に目を向けると、ハードウェアおよびシステム開発を手がけるOxide社のエンジニアリングチームは、大規模言語モデル（LLM）を複雑なシステム開発にどう活用できるかを模索している。彼らは研究の要約やドキュメントの解析には有用であると感じる一方、コードレビューにおける成果については一長一短であるとの見解を示した。また、LinuxカーネルにRustのサポートが正式に統合されたことも注目に値する。これはコアOSインフラにおけるメモリ安全な言語への大きな転換点であり、最新の安全性向上という利点と、新しい言語への依存に伴う複雑さとの間でバランスを取る試みといえる。