本日、バックボーンネットワークで発生した設定エラーにより、インターネットプロパティとCloudflareサービスが27分間にわたり、停止する障害が発生しました。その結果、当社ネットワーク全体で約50%のトラフィックが減少しました。バックボーンの構造上、この停止がCloudflareネットワーク全体に影響を与えることはなく、特定の地域での影響に抑えられました。
この障害は、ニューアークとシカゴ間のバックボーンセグメントとは無関係の問題に取り組んでいる最中に発生したもので、当社のネットワークエンジニアリングチームが、輻輳を軽減するためにアトランタでルーター設定を更新したことが原因です。この設定には、当社のバックボーン全体のトラフィックすべてがアトランタに送信される原因となったエラーが含まれていました。これにより、急速にアトランタのルーターの負荷が増加し、バックボーンに接続されるCloudflareネットワークのロケーションで障害が発生しました。
影響を受けた地域は、サンノゼ、ダラス、シアトル、ロサンゼルス、シカゴ、ワシントンDC、リッチモンド、ニューアーク、アトランタ、ロンドン、アムステルダム、フランクフルト、パリ、ストックホルム、モスクワ、サンクトペテルブルク、サンパウロ、クリチバ、ポルトアレグレです。他の場所では、通常通りの稼働が継続されました。
これは、攻撃や違法行為によって発生したものでないことをここに明記いたします。
この障害によりご迷惑をおかけしたことを心よりお詫び申し上げます。このような事態を二度と起こさないために、グローバルにバックボーン設定を変更いたしました。
Cloudflareのバックボーン
Cloudflareはバックボーンを世界中にあるデータセンター間で運用しています。バックボーンは様々なデータセンターを接続する一連のプライベート回線で、データセンター間でより高速で信頼性の高いルーティングを確保するために使用しています。こうしたリンクのおかげで、当社は異なるデータセンター間のトラフィックをパブリックインターネットを経由することなく、実行することができるのです。
たとえば、当社はニューヨークにあるWebサイトの配信元サーバーにアクセスするためにこれを使い、当社のプライベートバックボーンを介して、サンノゼとカリフォルニアの両方、さらにフランクフルトやサンパウロにまでリクエストを運びます。パブリックインターネットの回避というオプションが追加され、プライベートネットワークがインターネット輻輳ポイントを回避するために使うことができるため、質の高いサービスを提供することが可能となります。バックボーンを使うと、インターネットリクエストとトラフィックをどこでどのようにルーティングするかという点で、パブリックインターネットを使うよりもはるかに優れたコントロールが実現します。
タイムライン
記載の時間は全て協定世界時（UTC）です。
まず、ニューアークとシカゴ間のバックボーンリンクで問題が起き、これがアトランタとワシントンDC間でのバックボーンの輻輳につながりました。
この問題に対応するために、アトランタで設定変更が行われました。21:12に、この変更によって停止が始まりました。停止が確認されると、アトランタのルーターを無効化し、トラフィックが正常に流れ始めたのが、21:39です。
その後まもなく、ログとメトリクスを処理するコアデータセンターの一つで輻輳が発生し、ログの一部が削除されました。この期間、エッジネットワークは正常に稼働を続けていました。
20:25: ニューアークとシカゴ間のバックボーンリンクが喪失
20:25: アトランタとワシントンDC間のバックボーンが輻輳を始める
21:12 から 21:39: アトランタでバックボーン全体からトラフィックが集中する
21:39 から 21:47: アトランタでバックボーンが削除され、サービスが復旧する
21:47 から 22:10: 中心となった輻輳がログの削除を引き起こし、エッジは通常稼働を続行
22:10: ログとメトリクスを含め、完全復旧する
こちらは、Cloudflareの社内トラフィックマネージャーツールの影響を示したものです。上部の赤色とオレンジ色の部分は、アトランタのCPU使用率が過負荷に達していることを示しています。そして、白い部分は影響を受けたデータセンターでトラフィックが処理できなくなったため、CPUがゼロ近くまで低下したことを示しています。こちらは、障害の発生期間です。
影響を受けなかったデータセンターでは、インシデント（障害発生）中でもCPU使用率に何も変化が起きなかったことがわかります。緑色は、インシデント中でもこうしたデータセンターでは、なんの変化も起きなかったという事実を示しています。
何が起きたのか、Cloudflareがどう対処したか
アトランタでバックボーン輻輳が発生していたので、当社チームはアトランタのバックボーントラフィックを一部削除することにしました。しかし、バックボーンからアトランタのルーティングを削除するのではなく、１行変更したために、バックボーンへのBGPルーティング全ての漏えいが開始されました。
{master}[edit]
atl01# show | compare
[edit policy-options policy-statement 6-BBONE-OUT term 6-SITE-LOCAL from]
! inactive: prefix-list 6-SITE-LOCAL { ... }term全体はこちらの通りです。
from {
prefix-list 6-SITE-LOCAL;
}
then {
local-preference 200;
community add SITE-LOCAL-ROUTE;
community add ATL01;
community add NORTH-AMERICA;
accept;
}from {
このtermは、local-preference （ローカルプリファレンス）値を設定し、いくつかのコミュニティを追加、そしてprefix-list（プリフィクスリスト）に一致するルーティングを受け入れます。ローカルプリファレンスとは、iBGPセッションの推移的プロパティです（次のBGPピアに転送されます）。
プリフィクスリストの無効化ではなく、termを無効にすることが、正しい変更でした。
プリフィクスリストの条件を削除することで、ルーターはBGPルーティングの全てを他のバックボーンルーター全てに送信するように指示し、ローカルプリファレンスは200に増加しました。残念なことに、今回エッジルーターがコンピュートノードから受信したローカルルーティングは、ローカルプリファレンスが100でした。ローカルプリファレンスは高い方が優先されるため、ローカルコンピュートノード向けのトラフィックは全てアトランタコンピュートノードへと流れてしまいました。
ルーティングが送信されると、アトランタはバックボーンからトラフィックが集中し始めました。
当社は、以下の変更を行いました。
バックボーンBGPセッションに最大プリフィクスの制限を導入。この導入によりアトランタのバックボーンがシャットダウンされてしまいますが、当社のネットワークはバックボーンなしでも適切に機能するネットワークの構築ができます。この変更は、7月20日月曜日にリリースされます。
ローカルサーバールーティングのBGPローカルプリファレンスを変更。この変更により、一か所のロケーションのトラフィックが同様の方法で、他のロケーションのトラフィックを収集できなくなります。この変更は、インシデント発生後に展開されています。
まとめ
当社のバックボーンで障害が発生するのは初めてのことであり、チームは迅速に対応して影響を受けたロケーションのサービス復旧させましたが、関係者の皆様にご迷惑をおかけするのは非常に心苦しい限りでした。お客様およびユーザーの皆様、障害発生中にインターネットプロパティへのアクセスができなくなり、ご迷惑をおかけしたことを深くお詫び申し上げます。
バックボーン設定に変更を加え、このようなことが再び起こることがないよう対策を講じました。さらなる変更は月曜日に再開される予定です。