火曜日、Cloudflare は過去 6 年で最悪となる障害を経験し、データベースのアクセス制御の変更がグローバルネットワーク全体で連鎖的な障害を引き起こした結果、多くのウェブサイトやオンラインプラットフォームへのアクセスがほぼ 6 時間にわたって遮断されました。
同社のグローバルネットワークは、120 か国以上に分散配置されたサーバーとデータセンターから成るインフラで、コンテンツ配信、セキュリティ、パフォーマンス最適化サービスを提供し、世界中のあらゆる主要 ISP、クラウドプロバイダー、企業を含む 13,000 以上のネットワークと Cloudflare を接続しています。
同社 CEO の Matthew Prince 氏は、障害が収束した後に公開された事後分析レポートの中で、今回のサービス障害はサイバー攻撃によるものではないと述べました。
「この問題は、直接的にも間接的にも、いかなる種類のサイバー攻撃や悪意ある活動によって引き起こされたものではありません。代わりに、当社のデータベースシステムの 1 つに対する権限変更がトリガーとなり、その結果、Bot Management システムで使用される『フィーチャーファイル』にデータベースが複数のエントリを出力してしまいました」と、Prince 氏は述べています。
この障害は、定例のデータベース権限更新が Cloudflare の Bot Management システムに重複したエントリを含む巨大な設定ファイルを生成させた 11:28 UTC に始まりました。組み込みのサイズ制限を超えたこのファイルにより、Cloudflare のネットワーク全体でトラフィックをルーティングするソフトウェアがクラッシュしました。
このデータベースクエリは、権限変更後に重複したカラムメタデータを返し、フィーチャーファイルをおよそ 60 個のフィーチャーから 200 個超へと倍増させました。これにより、無制限のメモリ消費を防ぐために設けられていたシステムのハードコードされた 200 フィーチャー上限を超過しました。
5 分ごとに、更新済みのクラスターノードかどうかに応じて、クエリが正しい設定ファイルまたは不正な設定ファイルを生成したため、ネットワークは正常稼働と障害状態の間を行き来することになりました。
さらに、巨大化したファイルがネットワーク上のマシンに伝播した際、Bot Management モジュールの Rust コードがシステムパニックと 5xx エラーを引き起こし、トラフィック処理を担うコアプロキシシステムがクラッシュしました。
Cloudflare のエンジニアが根本原因を特定し、問題のファイルを以前のバージョンに差し替えたことで、14:30 UTC までにコアトラフィックは正常に戻りました。すべてのシステムが完全に復旧したのは 17:06 UTC でした。この障害は、Cloudflare の中核となる CDN とセキュリティサービス、Turnstile、Workers KV、ダッシュボードへのアクセス、メールセキュリティ、アクセス認証に影響しました。
「お客様およびインターネット全体に与えた影響についてお詫び申し上げます。インターネットのエコシステムにおける Cloudflare の重要性を踏まえると、当社システムのいかなる障害も容認できるものではありません」と Prince 氏は付け加えました。
「今日は 2019 年以来、Cloudflare にとって最悪の障害でした。これまでにもダッシュボードを利用できなくする障害や、新しい機能が一定期間利用できなくなる障害はありました。しかし、この 6 年以上の間、コアトラフィックの大部分が当社ネットワークを流れなくなるような障害は発生していませんでした。」
Cloudflare は 6 月にも、複数地域で Zero Trust WARP の接続問題や Access 認証障害を引き起こし、Google Cloud のインフラにも影響を与えた大規模障害を緩和しました。
10 月には Amazon も、Amazon Web Services（AWS）クラウドコンピューティングプラットフォームを利用する数百万のウェブサイトへの接続を妨げた、障害への対応を行いました。この障害は、重大な DNS 障害が引き金となっていました。
