現在、Cloudflare Radarは、障害センターで観測されたインターネット障害（部分的または完全な停止を含む）のリストを管理しています。これらの障害は、ISPからのステータスの更新やそれに関連する通信を確認した場合、ケーブル切断、政府の指令、停電、または自然災害に関連するニュース記事を発見するなど、トラフィックの減少と関連付ける十分な文脈がある場合に記録されます。
ただし、ジョージア工科大学のIODA（インターネットの切断の検出と分析、IODA）のように外部情報源で検証することはできるものの、観測している事象の原因と思われる情報源が見つからない場合もあるため、障害センターでは実際に観測された件数よりも少ない件数の報告件数が報告されています。このキュレーションプロセスには手作業が必要で、トラフィック量を分析して自動的に異常を検出し、関連する根本原因を見つけるワークフローをトリガーできる内部ツールを使用します。Cloudflare Radarの障害センターは貴重なリソースですが、重大な欠点として、すべての障害を報告しているわけではないこと、また、現在のキュレーションプロセスは、依然としてコンテキストを見つける必要があるため、私たちが望むほどタイムリーではないことが挙げられます。
本日、関連ブログ記事でお知らせしたように、Cloudflare Radarは国と自律システム（AS）の異常トラフィックイベントを公開します。これらのイベントは、障害を検証し確認するための内部ワークフローをトリガーしている上述のイベントと同じものです。（現時点での「異常なトラフィックイベント」はトラフィックの低下に関連するものであり、予期しないトラフィックスパイクは対象外としています）。障害センターにトラフィックの異常情報を追加するだけでなく、新しい異常イベントが検出されたとき、または障害テーブルに新しいエントリが追加されたときに、ユーザーが場所（国）またはネットワーク（自律システム）レベルで通知を購読できる機能も開始します。購読方法の詳細については、関連ブログ記事を参照してください。
検出された各異常の現在のステータスは、[障害センター]ページの新しい「トラフィック異常」の表に表示されます：
自動検出された異常の初期ステータスは
「Unverified」（未確認）です「Unverified」（未確認）エントリの確認後
社内の複数の情報源、場合によっては社外の情報源からも異常を確認できた場合、ステータスを「確認済み」に変更します。関連するコンテキストが見つかった場合、停電エントリも作成します。
複数の情報源で確認できない場合、ステータスを「False Positive」（偽陽性）に変更します。変更すると「トラフィック異常」の表から削除されます。（通知が送信されたにもかかわらず、Radarに異常が表示されなくなった場合、私たちが「False Positive」（偽陽性）としてフラグを立てたことを意味します）。
また、手動で「確認済み」ステータスのエントリを追加することもあります。これは、トラフィックの落ち込みを観測し、検証した結果、顕著ではあるものの、アルゴリズムが捕らえるほどの落ち込みではなかった場合に対応します。
インターネットのトラフィック量の様子を垣間見る
Cloudflareでは、特定のエンティティのトラフィックの様子について洞察を提供できるいくつかの内部情報源を保有しています。ロケーションの場合はIPアドレスのジオロケーション、ASの場合はIPアドレスの割り当てに基づいてエンティティを特定し、DNS、HTTP、NetFlows、ネットワークエラーログ（NEL）などのさまざまな情報源からトラフィックを分析することができます。以下の図で使用されている全てのシグナルは、これらの情報源の1つから取得したものであり、このブログ記事では、これを単変量時系列問題として扱います。現在のアルゴリズムでは、冗長性を追加し、より高いレベルの信頼性で異常を特定するために、複数の信号を使用しています。以下の議論では、インターネットの潜在的なトラフィック量のシナリオを幅広く網羅するために、意図的にさまざまな例を選択しています。
1. 理想的な波形は、以下に示すオーストラリア（AU）のように、傾向の平均が時間の経過とともに上昇する、わずかな上昇傾向を示す安定した週足パターン（オーストラリアのユーザーからのトラフィックが時間の経過とともに増加していることがわかります）です。
この波形が示すものは、時系列分解を行い、時系列を構成要素で分解し、基礎となるパターンをよく理解し、分析することで、明確に知ることができます。LOESSを使用した季節およびトレンドの分解（STL）を行い、上記のオーストラリアのトラフィックを週ごとのパターンと仮定して分解すると、以下のようになります：
今回調査する週ごとのパターンは、私たちが目視／人間のインターネットトラフィックに注目するために予想される信号の季節成分で表されます。上の画像で観察されるように、Trendの成分は信号レベルと比較してゆっくりした動きとなることが予想され、残りの成分は理想的にはホワイトノイズに似ています。これは、シグナルのすべての既存のパターンがSeasonal（季節）およびTrend（トレンド）の成分によって表されることを意味します。
2. 以下は、AS15964（CAMNET-AS）のトラフィック量で、週ではなく、日を尺度とするパターンをより強く示しています。
また、最初の4日間（青い破線）の直後に波形が低迷していることが見て取れます。赤い背景は、私たちのデータや他のインターネットデータプロバイダで確認された以外に報告が見つからなかった停電を示しています。ここでの目的は、このようなパターンに遭遇したときにイベントをトリガーするアルゴリズムを開発することです。
3. フランス領ギアナ（GF）の同様の例を示します。いくつかのデータの低迷（8月9日と23日）、振幅の変化（8月15～23日）、Cloudflare Radarで観測可能なコンテキストを持つ別の停電を観測しています。
4. もう1つのシナリオは、AS203214（HulumTele）で予定されている数回の停電です。その背景情報もあります。このような異常はトラフィックが停電に特有の値（通常のトラフィックと区別できる値）になるため、最も検出しやすい一方で、別の課題もあります。週を尺度とするパターンのみを確認する場合、これらの政府主導の停電は頻度の差がなくなり、アルゴリズムはある時点でこれを予想されるトラフィックと見なしてしまいます。
5. このケニアで発生した停電は、上記の停電と類似していると考えられます。トラフィック量はそれほど多くありませんが、可視範囲を超える値の低下が見られます。また、データには特定のパターンに従っていないいくつかの上昇スパイクも観察され、これはおそらく外れ値であり、時系列をモデル化するために使用するアプローチによっては除去する必要があります。
6. 最後に、私たちがこの問題にどのように取り組んでいるかの例として、この記事で使用するデータを示します。マダガスカル（MG）では、週末（青色の背景）に顕著な明確なパターンが見られます。また、緑色の背景でハイライトされている祝日（聖母の被昇天）と赤色の背景でハイライトされている停電があります。この例では、週末、祝日、停電のトラフィック量はすべてほぼ同じ様に見えます。幸いなことに、停電の日は、通常の営業日であれば同じように増加する予定でしたが、突発的な落ち込みを示しています。この記事の後半で詳しく説明します。
まとめると、私たちは約700（現在私たちが自動で異常を検出しているエンティティの数）のうち6つの例について調査しましたが、その結果、さまざまなばらつきがあることがわかりました。つまり、時系列を効果的にモデル化するためには、モデル化自体の前に、外れ値の除去、短期間および長期間のデータのオフセットの検出と再調整、分散、平均、または大きさの変化の検出など、多くの前処理ステップを実行する必要があります。また、トラフィックの落ち込みが発生するイベントや祝日の時期を事前に把握し、データに時間的なズレが生じるサマータイム調整を適用し、複数のタイムゾーンを持つロケーションや異なるタイムゾーンで共有されるASトラフィックへの対応を含め、各エンティティにローカルタイムゾーンを適用できるようにする必要があるため、時間も前処理の要素となります。
さらに、これらのステップの中には、新しいパターンで、観察後季節性に変化があったと言えるまでにある程度の時間を要する場合など、リアルタイムに実行できないものもあります。私たちは、これら前述の課題を考慮した基本的な前処理と統計を組み合わせたアルゴリズムを選択しました。このアプローチは、データの特性に対する私たちの期待に沿うもので、解釈が容易で、偽陽性率の制御が可能で、前述した多くの前処理ステップを不要にしながら、高速な実行を実現します。
上記では、発表時点で約700のエンティティ（ロケーションおよび自律システム）の異常を検出していると述べました。当然これが国やネットワークの世界全体を表しているわけではありませんが、それには十分な理由があります。この記事で説明したように、関連するモデルを構築し、その後異常を検出できるようにするには、特定のエンティティからの十分な量のトラフィックを確認する（十分な強度の波形を得る）必要があります。小さな国や人口がまばらな国では、トラフィックの波形に十分な強度がないだけでなく、多くの自律システムでそれらからのトラフィックがほとんど、あるいは全く見られないため、信号波形の強度が弱すぎて役に立ちません。私たちはまず、トラフィックの信号波形に十分な強度があり、かつ／またはトラフィック異常が発生する可能性が高いロケーション、および主要または重要な自律システム（利用者がそのロケーションの人口の相当な割合を占めるもの、および／または過去にトラフィック異常の影響を受けたことがあるもの）に焦点を当てています。
異常の検出
この問題を解決するために私たちがとったアプローチは、過去のデータから私たちの予想に対応するデータポイントの集合である予測を作成することです。これについては、「予測の作成」セクションで説明します。この予測と実際の観測を比較し、観測が予測と大きく異なっている場合、異常と判断します。ここでは、トラフィックの落ち込みに焦点を当てるため、異常は常に予測／予想トラフィックよりも低いトラフィックに対応します。この比較については、「予測と実際のトラフィックの比較」のセクションで詳しく説明します。
予測を計算するためには、以下のビジネス要件を満たす必要があります：
主に人間の操作によるトラフィックに関心がある。
異常を検出するタイミングが早ければ早いほど嬉しい。これを実現するには、データの取り込み時間や処理時間などの制約を考慮する必要がありますが、データが利用可能になれば、最新のデータポイントを使用し、それが異常かどうかを検出できるようになります。
真陽性（TP）率を上げるよりも偽陽性（FP）率を下げることが重要。このツールが内部向けのものであれば、これが必ずしも当てはまるわけではありませんが、一般向けに公開される通知サービスとしては、若干の異常を見逃しても、偽のエントリを避けたいと考えます。
観測するエンティティの選択
上記の例は別として、データの品質はデータの量に大きく依存します。つまり、どのエンティティ（ロケーション／AS）を対象とするかによって、データの品質レベルは異なります。極端な例ですが、南極には停電を確実に検出するための十分なデータは存在しません。どのエンティティが観測の対象となるかを選択するために使用したプロセスに従います。
ASの場合、主に人間の操作によるインターネットトラフィックに関心があるため、APNICが提供するユーザー数の推定値を使用します。次に、そのロケーションの各ASのユーザー数を合計することで、そのロケーションにおけるユーザー数の合計を計算し、次に、ASがそのロケーションに占めるユーザーの割合を計算します（この数も、APNICの表の「% of country」の列に表示されます）。そのロケーションにおけるユーザーの総数に対してASのユーザーが1％未満の場合、そのASを除外します。以下はポルトガルにおける表ですが、AS15525（MEO-EMPRESAS）は、ポルトガルのインターネットユーザー総数（推定）の1%未満のユーザーしか持たないため、除外されています。
この時点では、ASのサブセットとロケーションのセット（可能な限り多くのロケーションをカバーしたいため、_事前_にどのロケーションも除外しません）がありますが、自動で確実に異常を検出できるようにするには、データの品質に基づいて絞り込む必要があります。いくつかの指標をテストし、結果を視覚的に分析した結果、安定した波形の最良の予測因子はデータ量に関連するという結論に達したため、2週間の期間で基準（毎日のユニークIPの最小数）に達しないエンティティを除外しました（この閾値は目視検査に基づくものです）。
予測の作成
異常をタイムリーに検出するため、15分ごとにトラフィックを集計することにし、1時間分のデータ（4つのデータポイント／15分のブロック）予測と、実際のデータと比較します。
異常を検出するエンティティを選択した後のアプローチは非常に簡単です：
1. 予測範囲の直近24時間を参照として使用します。これは、直近24時間には、その後の波形に関する情報が含まれているという考えを前提にしたものです。下図では、直近の24時間（青）は金曜日から土曜日への遷移に対応しています。ユークリッド距離を使用することで、その参照（オレンジ色）に最も類似した6つの一致が得られます（内4つが金曜日から土曜日への遷移に対応しています）。また、月曜日（2023年8月14日）から火曜日にかけての休日も捕捉され、水曜日から木曜日にかけての通常稼働日の参照と最もかけ離れたものも見られます。参照に類似しない波形を捕捉した場合も、予測は参照と最も類似した24時間の中央値であり、その日のデータは破棄されるため、問題ではありません。
このアプローチを機能させるために使用する2つの重要なパラメータがあります：
過去28日間（+参照日=29）を考慮します。こうすることで、週ごとの季節変動を少なくとも4回確認できるようにし、トレンドが時間と共に変化することに伴うリスクをコントロールし、処理に必要なデータ量に上限を設定します。上記の例を見ると、最初の日は金曜日から土曜日への遷移に対応するため、参照との類似性が最も高くなっています。
もう1つのパラメータは、最も類似する日の数です。経験則から週ごとの季節性を考慮して6日間を使用する場合、同じ平日に一致するのはせいぜい4日間で、あと2日間はまったく異なる日であると予想されます。中央値を使用して予測を作成するため、この場合も大多数は4日となり、そのため残りの日数は参照として使用されなくなります。もう一つのシナリオは、以下の例に示す祝日の場合です：
このケースでは、週の半ばにある祝日が、金曜日から土曜日への遷移の曲線に類似しています。直近28日間を使用しており、祝日は火曜日から始まるため、一致は3つのみで（オレンジ色）。その後は通常の稼働日が3つ続きます。そのパターンは時系列データの他の場所に見当たらないため、これらが最も近い一致であるため、別の3つの通常の稼働日が表示されます。このため、偶数個の値について中央値を計算する際に下位四分位を使用し（つまり、データを下位の値に切り捨てます）、その結果を予測値として使用します。これにより、より保守的なアプローチが可能になり、真陽性と偽陽性のトレードオフに影響を与えることができます。
最後に、停電の例を見てみましょう：
このケースでは、直近24時間（参照）は日曜日から月曜日への遷移に対応し、トラフィックが少ないため、ユークリッド距離が最も小さい（最も類似した24時間）は土曜日（2回）または日曜日（4回）であるため、一致は常に低トラフィックに接続されています。この予測は、通常の月曜日に予想されるものです。そのため、予測（赤）は上昇傾向にありますが、停電が発生したため、実際のトラフィック量（黒）は予測よりもかなり少なくなっています。
このアプローチは、他のいくつかのモデリングアプローチと同様に、規則的な季節パターンに対して機能します。また、祝日やその他の変動イベント（毎年同じ日に行われないお祭りなど）の場合にも、その情報を積極的に追加しなくても機能することが示されています。とはいえ、特にデータにオフセットがある場合など、失敗するユースケースも存在します。これは、アルゴリズムがデータの人為的な影響を受ける可能性を減らすために、複数のデータソースを使用する理由の1つです。
以下に、このアルゴリズムが時間とともにどのように動作するかの例を示します。
予測と実際のトラフィックの比較
予測と実際のトラフィック量を取得したら、次のステップに進みます。
ある値が他の値に対してどれだけ変化したかを測定する相対変化を計算します。トラフィックの落ち込みに基づいて異常を検出しているため、実_際の_トラフィックは常に_予測値_よりも低くなります。
この指標を計算した後、以下のルールを適用します：
実際と予測の差は、信号の大きさの10％以上ある必要があります。この大きさは、選択されたデータの95パーセンタイルと5パーセンタイルの差を使用して計算されます。目的は、トラフィックが少ないシナリオ、特に1日のオフピーク時や、実際のトラフィックのわずか変化が相対的な変化に大きな変化を与えるシナリオを避けることです。これは、予測も低い場合に起こります。一例として：
予測が100 Gbpsで、実際の値が80 Gbpsの場合、相対変化は-0.20（-20％）です。
予測が20 Mbpsで、実際の値が10 Mbpsの場合、総量の減少は前の例よりずっと小さくなりますが、相対的な変化は-0.50（50%）となります。
次に、かなり低いトラフィックを検出するための2つのルールがあります：
持続的な異常：予測範囲全体（4つのデータポイント全て）で相対的な変化が所定の閾値αを下回る。これにより、時間をかけて広がる（相対変化が小さい）弱い異常を検出することができます。
ポイント異常：予測範囲の最後のデータポイントの相対変化が所定の閾値βを下回る（ただし、β<αの場合これらの閾値は負の値となります。例えば、βが-0.6でαが-0.4などです）。この場合、データの確率的性質に起因する異常のトリガーを回避しつつ、突発的で短時間のトラフィック低下を検出できるようにするには、β<αである必要があります。
αとβの値は、誤検出率を許容レベルに保ちながら、検出率を最大化するように経験的に選択しました。
異常イベントのクローズ
私たちが伝えたい最も重要なメッセージは、異常がいつ始まったかということですが、2つの主な理由から、インターネットのトラフィック量がいつ正常に戻ったかを検出することも非常に重要です：
検出した異常がまだ継続していることを意味する_「アクティブな異常」_という概念を持つ必要があります。異常がまだアクティブである間は、そのデータを考慮してしまうと、参照や24時間の最も類似したセットの選択に影響を与えてしまうため、参照に対して新しいデータを考慮しないようにすることができます。
トラフィックが正常に戻れば、異常が継続した期間を知ることで、そのデータポイントを外れ値としてフラグを立て、置き換えることができます。これにより、参照として、または参照に最適な一致として使用することがなくなります。私たちは中央値を用いて予測を計算しており、ほとんどの場合はそれで異常データの存在を克服するのに十分ですが、例4として用いたAS203214（HulumTele）のように、停電が同じ時間帯に頻繁に発生し、数日後には異常データが予想値となるようなシナリオもあります。
参照が異常なデータを含まないように、異常検出時は、データが正常に戻るまで同じ参照を保持します。いつトラフィックが正常に戻ったかを判断するために、αよりも低い閾値を使用し、異常が発生しない時間（現在は4時間）を与えてクローズします。これは、トラフィックの落ち込みが観察され、それが正常に戻ってまた落ち込むという状況を避けるためです。このような場合、1つの異常を検出し、それを集約することで複数の通知を送信することを避けたいと考えています。また、意味論的に同じ異常に関連する可能性が高いと判断できます。
まとめ
インターネットのトラフィックデータは一般的に予測可能であり、理論的にはインターネットの混乱を検出するための非常に簡単な異常検出アルゴリズムを構築することができます。しかし、観測対象（ロケーションやAS）に応じて時系列が異質であることや、データ内にアーティファクトが存在することから、リアルタイムで追跡しようとすると、多くのコンテキストが必要となり、いくつかの課題が生じます。ここでは、この問題を難しくしている特定の例を示し、課題のほとんどを克服するために私たちがこの問題にどのように取り組んだかを説明しました。このアプローチは、私たちの優先事項の1つである誤検出率を低く抑えながら、トラフィックの異常を検出するのに非常に効果的であることが示されています。静的な閾値アプローチであるため、これまで示したような急峻でない異常は検出できないという欠点があります。
私たちは、より多くのエンティティを追加し、より広範な異常をカバーできるようにアルゴリズムを改良していきます。
インターネットの混乱、ルーティングの問題、インターネットトラフィックの傾向、攻撃、インターネットの品質などに関するその他の洞察については、Cloudflare Radarにアクセスしてください。ソーシャルメディアでは、@CloudflareRadar（Twitter）、Cloudflare.social/@radar（Mastodon）、radar.Cloudflare.com（Bluesky）をフォローするか、メールにてお問い合わせください。