15:31 UTC (世界協定時)から19:52 UTCまでの間、Cloudflare ダッシュボードとAPIが利用が出来なくなる障害が発生しました。これは、二つのコアデータセンターのうち一つから、複数の冗長化したファイバー接続が切断されたためです。

今回の停止は、DDoS攻撃によって引き起こされたものや、、新型コロナウイルス危機によるトラフィック増加に関連したものでもありません。また、ソフトウェアやハードウェアの誤動作、または設定ミスによって引き起こされたものでもありません。

発生の原因

コアデータセンターの一つにおける計画的なメンテナンスの一環として、技術者は当社のキャビネットの一つにある機器を取り外すよう指示を受けていました。そのキャビネットには、廃止予定で非アクティブな旧型の機器が含まれていましたが、キャビネット内のサーバーには、アクティブなトラフィックもデータもありませんでした。また、キャビネットには他のCloudflareデータセンターへの全ての外部接続を提供するパッチパネル(ケーブルのスイッチボード)が1つ含まれていました。未使用のハードウェアを破棄する作業をしていた技術者は3分間にわたり、このパッチパネルのケーブルも取り外してしまいました。

このデータセンターにはCloudflareの主要なコントロールプレーンとデータベースなどが格納されており、接続が失われた際にダッシュボードとAPIが即時に使用出来なくなりました。。Cloudflareのネットワーク自体は正常に動作し、プロキシされたお客様のウェブサイトやアプリケーションは正常に機能していました。Magic Transit、Cloudflare Access、およびCloudflare Spectrumも同様です。また、Webアプリケーションファイアウォールなどのセキュリティサービスもすべて正常に機能していました。しかし、以下の一部サービスが利用できませんでした:

  • ダッシュボードへのログイン
  • API通信
  • 設定の変更(DNSレコード変更など)
  • キャッシュのパージ
  • 自動負荷分散 health checkの実行
  • 新規Argo Tunnel接続の作成または維持
  • Cloudflare Workersの作成及び更新Cloudflare Registrarへのドメインの移行
  • CloudflareログとAnalyticsへのアクセス
  • Cloudflare Streamでの動画のエンコーディング
  • エッジ側でご利用機能のログ(Logが表示されていない時間帯があります))

この障害による既存の設定データの消失はありませんでした。当社のお客様の設定データは、オフサイトでバックアップおよび複製されますが、バックアップも複製も必要ありませんでした。全ての設定データは現状維持されていました。

どのように対処するか

停止中、当社は障害復旧コアデータセンターへの切り替えと接続の復旧を同時に行いました。

新型コロナウイルによる緊急事態のために、Cloudflareではほとんどが在宅作業をしているため、多数のエンジニア達は二ヶ所にあるバーチャル作戦ルームから作業を続けました。バーチャル作戦ルームは、一つを接続の復元専用にし、もう一つは障害復旧failover専用としました。

そして、Cloudflareネットワーク全体を把握するために内部監視システムを迅速にフェイルオーバーしました。これによってグローバルな管理が可能となり、世界200以上の都市に広がる当社のネットワークロケーション全てで、問題が確認できるようになりました。今回のカットオーバーが意味することは、Cloudflareのエッジサービスは正常に動作し続けることができた上に、SREチームが日々のサービス運営で発生した問題に対処することができたということです。

インシデントに対応する間、ダッシュボードとAPIをフェイルオーバーするか、または接続の復旧に挑戦し続けるかという決断を20分毎に行いました。これが、データセンターに物理的な被害が発生した場合(自然災害の場合など)、カットオーバーをするという決断は簡単なものだったでしょうが、当社はfailoverのテストを実行しており、障害復旧からのフェイルバックが複雑であることをよく認識していたため、インシデント発生時における最善の行動方針を検討していました。

1944 UTC に、データセンターからインターネットへの最初のリンクがバックアップ。これは、10Gbpの接続を持つバックアップリンクです。

1951 UTC に、インターネットへの4つの大きいリンクのうち一つ目が復旧。

1952 UTC に、CloudflareダッシュボードとAPIが利用可能に。

2016 UTC に、4つのリンクのうち二つ目が復旧。

2019 UTC に、4つのリンクのうち三つ目が復旧。

2031 UTC に、完全に冗長化された接続が復旧。

今後の取り組み

この障害を真摯に受け止め、それがもたらした影響の大きさを認識しています。こうしたタイプの問題が今後再発した場合のリスクに対処できるように手順をいくつか特定しました。そして、次のように問題に迅速に取り組みを始める予定です:

  • デザイン: 外部接続はそれぞれ異なるプロバイダーを使用し、多様なデータセンターにつながっていましたが、当社では、全ての接続がたった一つのパッチパネルを通過しており、物理的な単一障害点が発生しました。これは、当社の施設で複数の部分に分散されるべきだと考えます。
  • ドキュメント化:ケーブルがパッチパネルから取り外された後、データセンター技術者が、復旧させる外部接続を提供する重要なケーブルを特定するために、貴重な時間がかかってしまいました。問題修正を行う人が誰でも、即時にその問題を特定できるように、様々なケーブルとパネルにラベル付けをして対策を講じる必要があります。これで、必要なドキュメントへのアクセスできるようになるはずです。
  • プロセス:技術者に対してハードウェアを撤去するよう指示を出す際に、明確にケーブルには決して触れないように確認する必要があります。

このインシデントの根本的な原因を見つけ出して対処するために、徹底的な内部事後分析を行います。

この度は、ご迷惑をおかけして大変申し訳ございませんでした。