今日、大手ISP／インターネット帯域幅プロバイダーであるCenturyLink/Level(3)で大規模な障害が発生し、一部のCloudflareのお客様およびインターネット上の多数のサービスやプロバイダーが影響を受けました。CenturyLink/Level(3)の障害報告書を待つ間、障害発生の時系列的データ、Cloudflareのシステムが問題を回避した方法、当社が影響緩和策を講じたにもかかわらず一部のお客様が影響を受けた理由、問題の根本原因と思われることなどを整理したいと思います。
エラーの増加
10:03 UTC（協定世界時）、Cloudflareのモニタリングシステムが、お客様の配信元サーバーに到達するエラーの数が増加するのを観測し始めました。これらのエラーは「522エラー」として報告されたものであり、Cloudflareのネットワークからお客様のアプリケーションがホストされている場所への接続に問題があることを表しています。
Cloudflareは、多数かつ多様なネットワークプロバイダーと接続していて、その1つがCenturyLink/Level(3)です。1つのネットワークプロバイダーからのエラーが増加した場合、システムは自動的に別のプロバイダーに切り替えてお客様のアプリケーションにアクセスしようとします。アクセスできるプロバイダーの数を考えると、1つのプロバイダーで問題が発生しても、通常はトラフィックのルーティングを継続することができます。
自動軽減策
今回の場合、522エラーの増加から数秒以内に、システムはCenturyLink/Level(3)からCogent、NTT、GTT、Telia、Tataを含む代替ネットワークプロバイダーにトラフィックを自動的に迂回させました。
ネットワークオペレーションセンターにも警告が表示され、当社のチームは、10:09 UTCから自動システムが自動的に対処できなかった問題を軽減するための追加措置を講じ始めました。ネットワークプロバイダーの1つであるCenturyLink/Level(3)が失われても、ほとんどのお客様とエンドユーザーに影響が出ないよう、Cloudflareネットワーク上のトラフィックフローを維持することに成功しました。
以下のグラフは、Cloudflareのネットワークと、当社が接続しているネットワークプロバイダーのうち、大手6社のTier-1ネットワークとの間のトラフィックを示しています。赤い部分は、CenturyLink/Level(3)のトラフィックを示しており、インシデント発生中にほぼゼロにまで低下しています。また、インシデント発生時にトラフィックをほかのネットワークプロバイダーに自動的に移し、影響を緩和してトラフィックが流れ続けるようにしていることも確認できます。
以下のグラフは、インシデント発生時のCloudflareネットワーク全体における522エラー（お客様のアプリケーションにアクセスできないことを表している）を示しています。
10:03 UTCに急増したのは、CenturyLink/Level(3)ネットワークの障害が原因でした。当社の自動システムは即座に始動し、代替ネットワークプロバイダー間でトラフィックの再ルーティングと再分散を試みた結果、エラーがすぐに半減し、これらのパスが自動的に最適化されたため、ピーク時の約25%にまで低下しました。
10:03 UTCと10:11 UTCの間で、システムは、接続されている48都市のCenturyLink/Level(3)を自動的に無効化し、別のネットワークプロバイダーにトラフィックを迂回させました。当社のシステムは、カスケード障害を防ぐために、トラフィックをシフトアウトする前に他社プロバイダーの容量を考慮に入れます。このため、フェイルオーバーは自動的に行われますが、すべての場所で瞬時に行われるわけではありません。私たちのチームは、追加の手動軽減策を適用して、エラー数をさらに5%減らすことができました。
なぜエラーがゼロにならなかったのか？
残念ながら、依然として一部のお客様との接続を確立できないことを示すエラーが多数発生していました。CenturyLink/Level(3)は、世界最大のネットワークプロバイダーの1つです。その結果として、多くのホスティングプロバイダーは、CenturyLink/Level(3)のネットワークを介してインターネットに接続するシングルホーム接続のみを行っています。
昔のインターネットを「高速道路」に例えるならば、町への出口が1つしかないようなものです。もし、出口が塞がれている場合、町に到達する方法はありません。CenturyLink/Level(3)のネットワークが経路撤回を受け入れず、撤回後もCloudflareのようなネットワークに経路を広報し続けたため、状況が悪化しました。お客様がCenturyLink/Level(3)を介してのみインターネットに接続している場合、または撤回後もCenturyLink/Level(3)が不良経路を広報し続けた場合、Cloudflareがアプリケーションにアクセスする手段はありませんでした。そうして、CenturyLink/Level(3)が14:30 UTC頃に問題を解決するまで、522エラーは発生し続けました。
同じことが、ネットワークのもう一方の（「アイボール」）側でも問題になっていました。個人ユーザーは、インターネットの高速道路への入口を必要とします。インターネットへの入口は、基本的にISPが提供するものです。CenturyLinkは米国最大のISPの1つです。
この障害は、CenturyLink/Level(3)ネットワークのすべてをオフライン状態にしたようであったため、CenturyLinkのお客様である個人ユーザーは、問題が解決するまでCloudflareやほかのインターネットプロバイダーにアクセスすることができませんでした。世界的には、障害発生時にグローバルトラフィックが3.5%減少しましたが、そのほとんどが米国内のCenturyLinkのISPサービスのほぼ完全な停止によるものでした。
何が起こったと思われるか？
CenturyLink/Level(3)が障害報告書を発行するまで何が起こったのか正確にはわかりませんが、BGPアナウンスメントと、障害発生中にそれらがどのようにインターネット全体に伝達したかから手掛かりを得ることができます。BGPはボーダーゲートウェイプロトコルの略です。どのIPが背後にあるのか、どのようなトラフィックを受信すべきか、インターネット上のルーターが、お互いの経路情報をやり取りするために使われるプロトコルのことです。
10:04 UTCから、かなりの数のBGPアップデートがありました。BGPアップデートとは、経路が変更された、または利用できなくなったことをルーターが知らせる信号のことです。通常の状況では、インターネットは約1.5 MB～2 MBのBGPアップデートを15分ごとに確認します。インシデントの開始時には、BGPアップデートの数は15分間に26 MB以上に急増し、インシデント発生中ずっと上昇したままでした。
これらのアップデートは、CenturyLink/Level(3)バックボーン内のBGP経路の不安定性を示しています。問題は、何がこの不安定性を引き起こしたのかということです。CenturyLink/Level(3)のステータスアップデートは、いくつかのヒントとポイントを提供し、根本原因としてFlowspecのアップデートを指摘しています。
Flowspecとは？
CenturyLink/Level(3)のステータスアップデートでは、不正なFlowspecルールが問題を引き起こしたことについて言及しています。では、Flowspecとは何でしょうか？FlowspecはBGPの拡張機能であり、これにより、BGPを使用して、ファイアウォールのルールをネットワーク全体、またはネットワーク間で簡単に配布することができます。Flowspecは強力なツールです。これにより、ほぼ瞬時にネットワーク全体に効率的にルールをプッシュすることができます。攻撃のようなものに迅速に対応しようとしている時には素晴らしいのですが、一歩間違えると危険なことがあります。
Cloudflareでは、創業当初、大規模なネットワーク層のDDoS攻撃を軽減するために、Flowspecを使用してファイアウォールのルールをプッシュしていました。7年以上前に、Cloudflareでも、Flowspecによって障害が発生しました。Cloudflareでは、もうFlowspecは使用していませんが、ネットワークファイアウォールルールをプッシュするための一般的なプロトコルであることに変わりありません。
CenturyLink/Level(3)で何が起こったのかを推測するしかありませんが、もっともらしいシナリオの1つは、ネットワークへの攻撃やそのほかの不正行為をブロックしようとして、Flowspecコマンドを発行したということです。ステータスレポートは、FlowspecルールによってBGP自体がアナウンスされないようになったことを示しています。そのFlowspecルールが何であるかを知る術はありませんが、ネットワーク全体のすべてのBGP通信をブロックした可能性があるJuniper形式のFlowspecルールを以下に示します。
route DISCARD-BGP {
match {
protocol tcp;
destination-port 179;
}
then discard;
}
これほどアップデートが多いのはなぜか？
しかし、なぜグローバルBGPのアップデートが、インシデント発生中ずっと高いままだったのか、謎が残ります。もし、ルールがBGPをブロックしていたのであれば、最初はBGPアナウンスが増加し、その後は通常のレベルに戻るはずです。
考えられる理由の1つは、問題のあるFlowspecルールがBGPアップデートの長いリストの終わり近くに来たということが考えられます。もしそうだとすると、CenturyLink/Level(3)のネットワーク内のすべてのルーターがFlowspecルールを受信することになります。そしてBGPをブロックします。それによって、ルールを受信しなくなります。バックアップを再開し、問題のFlowspecルールに再び到達するまで、すべてのBGPルールを順に処理していきます。BGPは再びドロップされます。Flowspecルールは受信されなくなります。そして、これが何度も繰り返されます。
この仮説における問題点の1つは、CenturyLink/Level(3)のネットワーク内では、サイクルごとにBGPアップデートのキューが増加し続けることです。それにより、ルーターのメモリとCPUが過負荷状態となり、ネットワークをオンライン状態に戻すためにさらなる問題が発生していた可能性があります。
なぜ修正に時間がかかったのか？
これは世界規模の重大なインターネットの障害であり、間違いなくCenturyLink/Level(3)チームは即座に警告を受けたはずです。CenturyLink/Level(3)チームは、世界クラスのネットワークオペレーションセンター（NOC）を備えた非常に優秀なネットワークオペレーターです。では、なぜ解決に4時間以上もかかったのでしょうか？
ここでも、推測するしかできません。第1に、Flowspecルールと、大量のBGPアップデートがルーターにかける負荷は大きく、ルーターのインタフェースにログインすることが困難になった可能性があります。ほかのTier-1プロバイダーのいくつかは、CenturyLink/Level(3)の要請により、ネットワーク間のピアリング接続を解除したようです。これにより、CenturyLink/Level(3)ネットワークが受信するBGPアナウンスの数を制限し、CenturyLink/Level(3)ネットワークによる処理が追いつく時間を稼ぐことができました。
第2に、FlowspecルールはCenturyLink/Level(3)が発行したものではなく、その顧客が発行した可能性もあります。多くのネットワークプロバイダーは、Flowspecピアリングを許可しています。これは、攻撃トラフィックをブロックしたいダウンストリームの顧客にとって強力なツールになり得ますが、何か問題が発生したときに、問題のあるFlowspecルールの追跡をはるかに困難にする可能性があります。
最後に、こうした障害が日曜の早朝に発生することは、問題をさらに厄介にするだけです。CenturyLink/Level(3)ほどの規模のネットワークは非常に複雑です。インシデントは発生するものです。私たちは、インシデントの間、何が起こっていたのかを知らせてくれたCenturyLink/Level(3)のチームに感謝しています。#hugops