Xが使えない18日の大規模障害、原因はデータベース設定ミス。Cloudflareが謝罪

障害発生中に顧客のデバイスで表示された画面の例

　Cloudflareは、11月18日に発生した大規模障害について詳細を報告した。サイバー攻撃によるものではなく、データベースの設定変更を行なった際の不備に起因する障害だったと説明している。

　報告によれば、障害は11月18日20時28分頃に最初のエラーが発生して以降、影響が拡大。18日23時24分頃に修正の適用を開始した後、23時30分頃から徐々に問題が解消し、翌19日2時6分頃に復旧が完了した。約5時間半にわたる大規模障害となり、一時はX(旧Twitter)にアクセスできない状態となるなど、多くのサービスに影響を与えた。

　同社では、2019年7月に発生した障害以来、最悪のサービス停止であり、インターネットエコシステムにおける重要性を考えると許されるものではなかったとして謝罪した。

　同社は報告の中で、今回の障害がデータベース「ClickHouse」に対して行なった設定変更に起因すると説明。権限の設定に不備があったことをきっかけに、顧客がボットアクセスを制御するためのモジュール「Bot Management」がエラーを引き起こし、大規模な障害へとつながったとしている。

Cloudflareネットワークの模式図

　Bot Managementは、Cloudflareへのリクエストが通過するコアプロキシシステム(Frontline、FL)内にあるモジュールの1つ。モジュール内のAIモデルが通過するリクエストを評価してボットスコアを算出し、そのスコアを活用してボットからのアクセスを制御している。

　このAIモデルは、データベースがネットワーク全体に配信する「feature file」(特徴量の情報が入ったファイル)に基づいて評価を行なっており、このファイルを5分ごとに更新することで迅速なボット対応を実現している。なお、パフォーマンス上の理由から、モジュールが扱えるfeature fileのサイズには上限が設けられていた。

　しかし、ClickHouseの権限設定を行なったところ、feature file内に大量の重複行が生じてしまい、本来想定されている2倍以上のサイズに肥大化。そのままネットワークに配信された結果、Bot Management側で設定していた上限を超えてしまい、不正なファイルを受け取ったモジュールでエラーが発生し、大規模な障害へと至った。

　さらに、この設定変更は段階的に実施していたため、正常なファイルと不正なファイルが交互に生成されてしまい、障害の復旧と再発を繰り返す状態に陥った。また同時期に、この障害とは関係なくCloudflareのステータスページがダウンしてしまったことから、当初は超大規模DDoS攻撃の可能性が疑われるなど、原因の特定が困難になったとしている。

　原因の特定後は、不正なファイルの生成と伝搬を止め、正常なファイルを手動で配信し、コアプロキシの強制再起動することで復旧が完了したと説明している。

障害の間、Cloudflareネットワークで発生した5XXエラーの量を示したグラフ

　障害はWorkers KVやCloudflare Accessといったコアプロキシに依存するほかのシステムにも波及。内部でWorkers KVを用いていることなどから、管理用画面のCloudflare Dashboardにも影響し、一部の顧客がログインできなくなった。また、デバッグおよび監視システムが大量のCPUリソースを使用したため、CDNからの応答にも遅延が発生した。

　同社では対応策として、Cloudflare内部で生成した設定ファイルを取り込む際に、ユーザーが生成したものと同等に厳格なチェックを行なうほか、機能ごとのグローバルキルスイッチの強化、エラー報告などがシステムを圧迫する可能性の排除、全コアプロキシモジュールの障害モードの再検証などを実施している。

【お詫びと訂正】初出時、記事タイトルに誤りがありました。お詫びして訂正させていただきます。