このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
測定は、世界や宇宙だけでなく、私たちが設計しデプロイするシステムを理解するためにも不可欠です。インターネットも例外ではありませんが、インターネットの測定には独特の課題があります。
インターネットは驚くほど不透明で、オープンでマルチステークホルダーモデルであることから直感に反するものです。最終的には、インターネットは多くのネットワークやサービスに参加し、それらは無関係な組織によって所有・運営され、システムについての共有や報告もほとんどないため、不透明であると言えます。すべてのネットワークは、他のシステムが生成したものを伝送したり転送したりするかもしれませんが、各システムは完全に独立しています。正直に言うと、これがインターネットの魔法です。このような不透明でありながら重要な文脈において、インターネット測定は科学的実践として存在しなければならず、すべての関連する厳密性、反復性、複製可能性を併せ持つ必要があります。
科学的実践としての測定は、うまくいくこともあれば間違っていることも含めて、ワクワクします。次の文には、微妙な違いがあることを説明しています。
「6人の科学者のうち5人は、ロシアンルーレットは安全だと言っています。」
バカげています！おかしな話ですが、この記述も論理的なものです。上記の記述につながる実験を設計するのはごく簡単です。しかし、この実験が成功する唯一の方法は、「行為者」、つまり実験を行う人が、以下のように、その行為に信頼性を持たせる測定科学のあらゆる側面を無視する場合です。
方法論：データキュレーション、モデリング、検証からなるサイクルここでは、各参加者が他の人の傷害を見ることができなかった場合にのみ、実験（データキュレーション）が成功する可能性があります。さらに重要なのは、アクターは実験なしで利用可能な数字を使って確率を計算できるため、測定が必要ないということです。
倫理：測定の方法は、過度に望ましくない結果をもたらす可能性があります。最低限の原則は、害を及ぼさないことです。
表現：明確で完全な記述または視覚化は、少なくとも情報提供可能であり、理想的には実行可能である必要があります。誤解を招く可能性があるのです。それぞれの参加者が「安全ですか？」という質問に「イエス」と答えたとします。彼らの答えは、「ゲームは安全か？」ではなく、違うものになっています。
このブログでは、上記の測定の各側面を取り上げ、それらがインターネット空間にどのように顕在化するかを説明し、今週取り上げる仕事の例と関連させます。まず、背景を少し説明しましょう。
高品質な測定は、当社のエクスペリエンス、環境、システムの特定、理解、さらには説明に役立ちます。しかし、文脈を持たずに単独で観察することは危険です。以下は、ウクライナのリヴィウからのHTTPリクエストの内部グラフの時系列で、2022年2月28日の夜までのものです。
その日、この地域からのトラフィックは3倍から4倍に増えました。ちなみに、ロシアのウクライナ侵攻は4日前に始まりました。世界はこの出来事を注視していました。Cloudflareも例外ではなく、ネットワーク影響のレポートと軽減の両方を支援しました。
その異常な急増を観察したCloudflareは、この増加をDoS攻撃の可能性と誤って報告した可能性があった。しかし、反対の兆候もありました。まず、DoS防御・軽減システムによって攻撃がフラグを立てることはありませんでした。さらに、プロファイルは攻撃トラフィックとしては特殊なもので、単一の場所からの単一のソース、または複数の場所からの複数のソースのいずれかである傾向がありました。この例では、複数のソースネットワークからの増加がみられましたが、1つの場所（リヴィウ）で発生しました。
Cloudflareは誤ったレポートを回避するためのツールを備えていました。その後、ウクライナ国外へ向かう最後の鉄道駅があるリヴィウでの人々の集中による増加が原因であると正確に報告しました。しかし、これは測定の文脈でも重要なことですが、Cloudflareの視点から見ると、説明できるものはありません。最後に、ある従業員がBBCのレポートで、ウクライナのその地域における人々の大規模な移動に関するレポートを目にしました。それにより、トラフィックの変化をよりよく説明できるようになりました。
この例は、常に代替説明を探すことを示す重要な例です。また、観察だけでは、情報の欠落や認識されないバイアスによって、誤った結論につながる可能性があることも示しています。しかし、バイアスのない良い数字も誤解されることがあります。
測定の文脈では、実践や例に踏み込む前に知っておくべき特定の意味を持つ一般的な単語が存在します。
これらは「方法」を説明しています。アクティブ測定では、アクターが応答をトリガーするように設計されたアクションを開始します。レスポンスは、pingから返される遅延やクエリに対するDNS応答などのデータになることがあります。応答は、ミドルボックスからのプロンプトと公開を促す巧妙なプローブパケットなど、アクションによってトリガーされるメカニズムまたはシステムの観測可能な変更である場合があります。
受動的な測定では、アクターはそれを観察するだけです。何も実行しません。その結果、レスポンスはトリガーされません。システムとその動作は変更されていません。ログは通常、受動的な観察からコンパイルされ、Cloudflare独自のものも例外ではありません。Cloudflare Radarに表示されるデータの大部分は、これらのログから取得したものです。
それぞれにトレードオフがあります。積極的な測定は対象を絞り、制御が可能です。また、拡張が非常に困難（そして多くの場合、コストがかかる）であり、その結果、システムのデプロイされた部分しか観察できません。逆に、パッシブの測定は軽量化される傾向がありますが、観察者が適切な場所に適切なタイミングにいれば必ず成功するのです。
この2つの方法は効果的に互いに補完し合い、一方の方法が他方の方法に集約するように連携させることで最も強力なものとなります。例えば、以前にCDN全体のパフォーマンスを理解しようとした際には、（パッシブ）リクエストログを調査してインサイトを得ました。これにより、RIPEのAtlasを使用してその後の（アクティブ）pingに情報を伝達し、洞察と結果を確認しました。逆に、接続障害を（受動的に）検出して理解しようとする私たちの取り組みは、大規模な接続の改ざんを理解するための、リサーチコミュニティの大量の（アクティブな）測定によって行われたと考えることができます。
アクティブとパッシブの相互作用の詳細については、リサーチコミュニティの過去のアクティブな測定からの洞察により、Cloudflareの膨大なデータを深く掘り下げることができた研究者の経験をお読みください。
何かを直接観察しなくても、インサイトを得ることは可能です。たとえば、帯域幅と呼ばれるパスの容量を考えてみましょう。帯域幅を直接確認する一般的な方法は、スピードテストを起動することです。簡単なテストですが、2つの問題があります。
1つ目は、帯域幅をできるだけ多く消費することで機能することです（これは、倫理的なジレンマを生じさせます。これは、後ほど説明します）。2つ目は、送信者から受信者へのスループットを実際に測定することです。これは、ボトルネックリンクの利用可能な帯域幅（または、残りの容量）を指します。2つのスピードテストがボトルネックを共有している場合、それぞれのスループットが実際の帯域幅の1/2になる可能性があります。その証拠は数字で示されています。以下に見られるように、スピードテストの観測値は69～85Mbpsの範囲で、これは中央値から20%近くの+/-の範囲で、固定値からは遠く離れています。
代わりに、パケットペアまたはパケットトレースと呼ばれる25年以上前からあるスピードテストの間接的な代替手段があります。これは、最初にパケットのペアを送信し、その送信時間を記録し、その後、到着時間を記録することで機能します。2つのパケットの送信時間と到着時間の変化から、ボトルネックの帯域幅がわかります。パケットペアのプローブを繰り返し、統計分析を行うことで、真のボトルネック帯域幅の推定値が得られます。パケットペア技術では、経時的にバイト数をプッシュしたりカウントしたりして帯域幅を直接観察するのではなく、2つのパケット間の時間を利用して間接的にメトリクスを計算（または推測）します。
測定は、合理的な予測につながる場合に最も効果的です。予測によって、世界やその中にデプロイするシステムの理解が深められることもあります。時折、予測によって新しいことが明らかになることもあります。いずれにしても、予測測定は、データをキュレートし、そのデータに基づいてモデルを構築し、その後（理想的には）異なるデータでモデルを検証するというシンプルなパターンで出現します。これらが連動することで、測定のライフサイクルが作成されます。
測定は、ライフサイクルの最初から最後までを包含するのが理想的ですが、それぞれの段階で非常に価値ある貢献や進歩が存在する可能性があります。個々の高品質なデータセットは厳選するのが非常に難しく、それぞれが有効な貢献となり得ます。同様に、モデリング技術、または検証のためのツールを使用します。測定は専門分野にまたがり、多様なスキルセットの恩恵を受けます。
データキュレーションから、各ステップを順番に見てみましょう。
最も一般的で身近な測定手法は、データの収集とキュレーションです。データはそれ自体が魅力的で有用なものです。Cloudflare Radarは、そのことの明確な証拠です。多くのコンテキストで単純にカウントすることで、自社の環境をコンテキストに関連付け、配置することができます。
データ収集とキュレーションには、モデリングや検証よりも多くのエネルギーと時間、リソースが必要です。この説明は、循環的な測定パターンによって示唆されています。検証には先行モデルが必要であり、データを使用してモデルが構築されます。データもモデルも検証も、インサイトも予測も学習もありません。サイクルの各ステップの質は、前のステップの質に依存します。測定方法では、高品質のデータが要となります。Large Hadron ColliderとJames Web Telescopeは、Cloudflareがいかに可能で、どれだけのことを必要としているかを示すよい例です。これらは高品質なデータを追求し続けています。インターネット測定コミュニティにおける同様の「常時稼働」ツールは、特色には欠けますが、重要性は変わりません。CAIDAとRIPEのAtlasは、テレメトリを収集し、データセットをキュレートする長期的プロジェクトの2つの例に過ぎません。
誤解しないでください。高品質なデータの収集とキュレーションは困難です。
幸いなことに、「高品質」は完璧を意味するものではありません。代表という意味です。たとえば、距離や時間をカウントする場合、精度は真の値を反映している必要があります。大規模な人口でも、はるかに少ないサンプル数で合理的に研究できます。たとえば、当社が接続の改ざんについてグローバル評価を行ったところ、10,000件に1件（0.0001%）の割合で、貴重なインサイトが得られました。低いサンプリングレートがCloudflareで機能している理由の1つには、Cloudflareのお客様の多様性があり、あらゆる種類のコンテンツや目的のトラフィックが集中しているからです。今週後半に、Cloudflareのリクエストログから、約180,000件のキャリアグレードNATのサンプルを見つけるのに使用された、不完全な信号が、直接観測できない1200万件以上の他のNATを特定するのに「十分である」ことを、ブログ記事で紹介する予定です。
もう一つの重要な、そしておそらく直感に反する誤解は、より多くのデータを使えば、より多くの質問に対する答えが得られるということです。Ram Sundaran氏がゲスト投稿で書いているように、時にはノイズが多すぎて、大規模なデータセットの中から答えを見つけることが小さな奇跡のように思えることもあります。
モデルは概念的な場合があり、環境やシステムの側面を説明するものもあります。最も役立つ情報は、当社の理解や仮定に関する簡単な記述として表現できます。実際には、検証可能な仮説をカプセル化しているのです。たとえば、インターネットサービスプロバイダーやネットワークは、直接経路が長い場合でも、コストが発生するトランジットネットワークパスよりも、CDNへの直接の無料ピアリング経路を通常優先すると、私たちは考えるかもしれません。これにより、検証可能なモデルが形成されます。
予測モデルは、私たちの理解の境界を超えて、明らかでない、または直接観測できない、または確認が難しいシステムの側面を特定し、説明し、理解するのに役立ちます。予測モデルでは、例えば基礎となる統計的プロセスを特定したり、機械学習の分類子を作成したりするために、統計的テクニックを用いることが多くあります。統計ツールのより一般的な用途は、厳選されたデータ自体の特徴を明らかにすることです。驚くほど強力なモデルは、平均、中央値、分散、信頼性指標を備えた単純な確率分布である場合があります。
多くの注目を集めたインターネットの側面の1つは、インターネット上のネットワークが他のネットワークへの接続をどのように選択するかでした。インターネットの形成と成長の方法を理解することは、シミュレーションにとって極めて重要ですが、ネットワークがどのように故障するかを予測するのにも役立ちます。左側にある方程式は、優先接続、またはより身近な言葉で言えば「リッチになる」を前提とした初期のモデルであるBarabási–Albert（BA）モデルから来ています。
最も単純な例では、BAモデルの新しいネットワークは、既存のネットワークの接続数に比例した確率で既存のネットワークに接続することを選択します。以降のモデルでは、「インテリジェントな」選択メカニズムを排除しました。右にある下記の方程式は、ネットワークのサイズに基づいており、宇宙で天体が形成される方法に似た、より一般的なメカニズムです。
どのツールをいつ使うべきかを知ること自体が技術力である場合もあります。例えば、MLやAIを使った、よりシンプルで透明性の高いメカニズムで対処可能な問題を解決することが挙げられます。例えば、このゲストブログでは、TCPが厳密に指定されているため、異常なTCPの動作を理解するためにMLが除外されたことを説明しています。これにより、さまざまなパケットシーケンスの完全な列挙が可能であり、その正しいことが証明されています。
多くの場合、ドメインの理解は、正確なモデルを構築する能力に不可欠です。例えば、機械学習は大規模な非構造化データを理解するのに役立つツールですが、一定の分野に関する専門知識を使用することで非常に強力になります。今週後半に取り上げるマルチユーザーIPの検出に関する研究は、その一例を提供するものです。特に、キャリアグレードのNATデバイス（CGNAT）の検出を目指しました。これは、VPNやプロキシとは異なり、ユーザーがCGNATを使用することを選択したり、その存在を認識しないため、大規模なマルチユーザーIPの中で独自のものです。
MLモデルはマルチユーザーIPの識別に成功しましたが、ドメイン知識を適用するまで、CGNATの曖昧性解消は不明でした。たとえば、CGNATは通常、連続したIPの範囲にわたってデプロイされます（例：/24ブロック内）。以下に示すように、このモデルでは非常に重要な機能となっています。
検証段階では、データに対してモデルの出力をテストすることで、測定行為全体の価値をほぼ単一で決定します。モデルがデータに反映される予測を行う場合、そのモデルは妥当性があります。検証データと対照的または矛盾する予測は、モデルに欠陥があるか、厳選されたデータによってバイアスされているかのどちらかであることを示しています。
検証では、優れた測定が逸脱する可能性があります。主に2つの方法があります。まず、最初のデータキュレーションフェーズと同様に、検証データは人口を代表するものである必要があります。例えば、1日の交通に関するデータを収集して、そのデータに関するモデルを構築し、夜間の交通データを使用して検証するというのは間違いです。また、例えばTCPに関する測定値を検証するのにQUICデータを使用することにも意味はありません（共通の属性を持つという測定の仮説を除く）。検証と最初のデータの違いによって測定が歪むことがないように、常に注意を払う必要があります。
また、検証は、キュレーションされたデータを直接使用する場合、誤解を招くリスクがあります。確かに、このアプローチであれば、データセット間の差異を軽減できます。しかし、同じデータで検証するときに導き出される唯一の結論は、データが何を表すものではなく、モデルがデータを合理的に説明しているということです。例えば、機械学習を例に挙げてみましょう。機械学習の本質は、データをキュレートし、（それを機械学習アルゴリズムに入力して）モデルを構築し、データに照らして出力を検証するというライフサイクルに沿った測定です。機械学習コミュニティの初期の一般的な慣行は、1つのデータセットをトレーニング用に70%、検証用に30%に分割することでした。この設定は、正当な評価ではなく、潜在的に誤解を招く可能性が高い設定です。重要な特性を増幅または省略するデータセットで訓練したMLモデルにとって最適な場合は、そうしたバイアスを反映するモデルであり、これがアルゴリズムバイアスの発生源となる可能性があります。
当然ながら、無関係なデータでも有効であることを証明できるモデルに対して、より大きな信頼感が得られます。検証データセットは、異なるソースからの同じ属性を記述することができます。例えば、パッシブのRTTログデータから構築され、アクティブなpingに対して検証されたモデルなどです。あるいは、モデルの構築では無視された、分布やヘッダー値による接続の改ざんを確認するなど、まったく異なるデータやシグナルを使用してモデルを検証することもできます。
ネットワーク測定における倫理の重要性は、強調する必要があります。ネットワークの測定は、リスクなし、人間から取り残され、人間にはほとんど影響を与えないものとして認識されがちです。これは真実とはかけ離れたものです。前述の帯域幅を推定するためのスピードテストとパケットペア技術を思い出してください。スピードテストでは、アクターのネットワーク内にあるかどうかにかかわらず、利用可能なボトルネック容量をすべて消費することによって、帯域幅を推定します。リソース消費のコストは他の人が負担する可能性があり、ユーザーのためにネットワークの潜在的なパフォーマンスを確実に低下させます。この種の帯域幅測定のリスクにより、パケットペア技術がプロンプトされ、わずか数ペアのパケットと小さな数学的数学を使用して帯域幅を推測することができるようになりました。送信者と受信者の間で何らかの調整が行われているにもかかわらずです。
ネットワーク測定のベストプラクティスでは、測定を行う前にリスクと影響を精査します。これは負担のように思えるかもしれませんが、倫理的考慮はしばしば創造力をかき立て、新しい方法論が生まれる理由となっています。Cloudflareは、JavaScriptインジェクションの代替手段を探していたことが、パッシブデータを使用して他のCDNのパフォーマンスを評価しようとするきっかけとなりました。詳細については、Communications of the ACM（2016）に掲載された「ネットワーク測定ペーパーにおける倫理的考慮事項」を参照してください。
可視化と表現は、測定ライフサイクルの各段階で非常に役立ちます。表現は、少なくとも当社の理解を深め、理想的には、フォローアップ行動も明確にします。コンテキストのない記述は、不十分な表現です。例えば、「30%の可能性」は高いように聞こえますが、基準点がなければ価値はありません。0.5%の30%は、20%の30%よりは懸念が低い可能性があります。
その一例として、Cloudflareの「近接性」に関する記述があります。Cloudflareは「世界のインターネット接続人口の95%から約50ミリ秒以内」です。このステートメントには、当社のログの「調査」が盛り込まれています。Cloudflareに接続する各IPアドレスからの全接続のうち、最小RTTの半分は、IPアドレスからCloudflareへの遅延の「最悪近似値」です。 95%のケースで、minRTT/2は50ミリ秒以下です。
一方、可視化は強力になり、誤解を招く結論につながることがあります。これは、今週後半のルーティング耐障害性評価に関するブログ記事で取り上げた概念です。この件に関する一例を以下に示します。2つの棒グラフは、各州の相互接続施設の数を、各州の相互接続施設の数を多い順から少ないものにランク付けしたものです。左側では、州は未加工カウント施設に従って順序付けられています。上位の州には140以上の相互接続施設があります。右側は、未加工のカウントが各州の人口で正規化された（この場合は割った）ものです。
これらの表現は、私たちのモデルが形成されたものであり、データの評価方法によって誤った情報を得ることができることを示しています。この例では、X軸のステート名が邪魔になるため、意図的に省略しています。その代わりに、各バーは、右側のグラフの1人あたりの施設の中央値を上（緑）にするか下（黄色）にするかを色分けで示しています。すぐにわかるのは、施設の数が最も多い2つの州が中央値を下回っていることです。つまり、1人あたりの施設で並んでいる州の下半分にあることです。
視覚化があまりにも強力で、疑いの余地がなくなることもあります。以下の画像は、データとモデルが正確であることを示す強力な証拠が得られるため、個人的に気に入ったものです。この可視化では、各列が、私たちが観測した1つの種類の接続異常を表しています。各列では、異常の発生が接続を開始した国に比例して分割されます。例として、SYN→∅異常（タイムアウトの一種）の一番左の列を見てみましょう。中国、インド、イラン、米国からの接続が、この特定の異常タイプを占めていることがわかります。このように可視化を整理することで、データを第一に考え、説明、根本的なメカニズム、場所に関するバイアスを軽減することができました。
このように異常を整理することで、可視化は「障害は想定される動作なのか？」という1つの質問にすぐに答えました。それらが想定される、あるいはインターネット上で通常であれば、異常は異なる割合ではなく、ほぼ同じような割合で現れるでしょう。視覚化は私たちのアプローチと直感の強力な検証（しかし、唯一ではありません）であり、結果として調査のさらなる道が開かれました。
Cloudflareは、利用可能な（パッシブ）データの新しくて斬新な方法について考え続け、アイデアを歓迎します。測定は、私たち全員が依存し、価値とし、愛するインターネットを理解するのに役立ち、コミュニティ全体の取り組みです。
Cloudflareは、測定分野への新規参入を推奨します。このブログが、その課題を紹介すると同時に、Cloudflareやその他の場所で公開された測定作業の評価に関するマップとして機能することを願っています。