Home Blogs 再送信率を使用した中間の測定
Applications

再送信率を使用した中間の測定

About The Author

Outline

大規模なグローバルネットワークを運用する場合、パブリックインターネット経由で通信するシステム間の良好な接続性とパフォーマンスを確保することは、良好なユーザエクスペリエンスを確保するための鍵となります。 インターネットの複雑でベストエフォートな性質を考えると、最も信頼性の高いプロバイダーの最も適切にプロビジョニングされたリンクでさえ問題が発生することがあります。

このようなリンクを監視するための戦略はいくつかあります。たとえば、測定専用のトラフィックを生成するアクティブ測定や、既存のトラフィックを監視するパッシブ測定など です。 この記事では、xTCPソケットサンプリングシステムを使用して、ネットワークが依存する多くのリンクを受動的に監視するパッシブアプローチについて説明します

xTCPのデータを最大限に活用するために、インターネット監視に関連するいくつかの課題に対処するこのデータを処理するアプローチをさらに開発しました。 特に、再送信率と呼ばれる概念を導入します 。これは、コンテンツ配信ネットワーク(CDN)サイト間で観察される再送信の重大度の相対的な測定値を提供し ます。 我々は、一定レベル以上の再送信率がスループットの低下に対応し、ユーザが知覚するパフォーマンスに直接影響することを実証している。したがって、ネットワークのパフォーマンス低下に対処するためのネットワーク自動化の優れた基盤となる。

背景

CDNの一般的なワークフローでは、あるPOP(Point of Presence)が別のPOP(Point of Presence)にアクセスしてコンテンツを取得し、キャッシュするなどの方法でコンテンツを取得します。 多くの場合、これらのやり取りはクライアントの要求に直接応答して行われます。つまり、ダウンストリームの要求がこの転送の完了を待っている可能性があります。 一般に、要求自体は数キロバイトのオーダーで非常に小さい場合があります。 応答のサイズは、キロバイトからメガバイトまで、大きく変動します。

図1:要求フローは、小さい(オーダーKB)要求を送信し、潜在的に大きい(潜在的にメガバイト)応答を受信します。

アクセスポイント間の接続の状態を監視するために、ソケット監視ツールxTCPを使用して、エッジサーバー上のすべてのオープンソケットの現在の状態をサンプリングできます。 これにより、クライアント側のソケットで重要な可視性が得られますが、このソケットデータはPoP間のデータのビューも提供します。

しかし、このデータの測定にはいくつかの課題があります。 まず、xTCPは異なる接続のポイントインタイムサンプルを提供します。 つまり我々は様々な場所で様々なつながりを捉えることができるかもしれません したがって、評価を行う際には、単一の値ではなく、行動のより広い分布を考慮する必要があります。

次に、正しい方向を監視していることを確認する必要があります。 要求を生成したPOP(上の図のPOP A)と、要求を受信して応答しなければならないPOP(上の図のPOP B)の両方にソケット情報がありますが、これらの非対称ワークロードにより、異なる動作が予想されます。 クライアントから送信されるパケットの大部分は制御パケット(初期要求、後続の確認応答パケット)であり、サーバから送信されるパケットの大部分はデータパケットであり、意味のある量のデータが含まれている可能性が高い。

その結果、パス上に輻輳などの問題がある場合、データを伝送するパケットがより多くのキュースペースを占有するため、パケット損失が発生し、再送信が発生する可能性が高くなります。たとえば、ビジールータでキューがドロップされた場合などです。 これを実証するために、10分間のPoPペア間の要求および応答フローに見られるパケット再送レートの分布(再送信パケットの合計を送信データセグメントの合計数で割った比率として計算されます。再送信回数は少なくなります)を検討します。

図2:応答トラフィックの再送信回数が増加します。これは、サイズが大きいためと考えられます。

ここでは、この期間中、クライアントリクエストソケットの再送信はほとんど行われません。 一方、応答では、ほぼ85%のソケットでゼロ以外の再送信が行われていることが示されていますが、大部分の接続では、再送信率が1%を大幅に下回っていることに注意してください。 当然のことながら、テスト期間中にゼロ以外の再送信を行ったPOPのほぼすべてのペアで同様の動作が確認されています。 したがって、データを含んだ応答フローに焦点を当てます。 元の要求PoPへの要求を処理することに関心があるため、これらのフローを「インバウンド」フローと呼びます。

最後の課題は、再送信に関する一般的な複雑さと、それらをパフォーマンス低下の信号として使用することの難しさです。 実際、再送信は送信者の状態とパケットが再送信された回数を反映するだけなので、特定の問題を示すことなく定期的に行われる場合があります。 これらは、最終的には損失以外の複雑なプロトコル動作(テール損失プローブなど)の結果である可能性があります 。 さらに複雑さを増すと、多くのソケットは再送信を観測しないことがわかります。 つまり、単純な要約(中央値を取るなど)は、再送信率の非常に保守的な要約になる可能性があり、歪んだ要約(95パーセンタイルまたは99パーセンタイルなど)は、一般的な集団に有害ではない行動を大部分捕捉する可能性があることを意味します。

再送信率

これらの課題の影響を単純化するために、再送率と呼ばれる複合メトリックを検討します。 MetaのHD Ratioは、 HDビデオをストリーミングできるクライアントの割合を定量化することを目的としており、この測定は、異常なレベルの再送信が発生しているソケットの割合を説明することを目的としています。 ゼロ以外の再送信が予想されることがあるため、再送信率は次のように定義します。

重要なことに、この値はxTCPを介して利用可能なデータを使用して計算するのが特に簡単です。 私たちの運用経験では、正常なリンクでは再送信率の値が一般的に小さく、生の再送信率の測定に存在するほとんど常にゼロの課題を回避していることがわかりました。

また、測定は機密性が高く、他のパフォーマンス監視システムよりも先にアラートが生成されることがよくあります。 これは、ネットワークの劣化を迅速に診断する場合に特に役立ちます。これは、小さな問題から始まり、最終的には大きな問題につながります。

メトリックの検証

再送率がアプリケーション性能と直接相関していることを示すために,二つの測定を考慮してその有効性を実証した。 第1に、再送信率が高い場合には、再送率が低いかゼロの場合に比べて、クライアントアプリケーション(リクエスタ)のスループットが低下することを示した。 第二に、高い再送信率は、他のネットワーク信号、特にPOP間のICMPプローブの劣化に対応することが多いことを示した。

アプリケーションパフォーマンスへの影響を調べるために、アプリケーションレイヤーから明示的に測定した測定値に注目します。 特に、クライアントPOPで測定されたスループットは、データ送信プロセスで達成された機能提供率を表すため、考慮します。 再送信イベントの影響を理解するために、次の調査を1週間にわたって実施しました。この調査では、プロバイダーの重大な問題が発生しました。

まず、再送信イベントが発生したすべての期間を考慮します 。 再送信イベントは、PoPのペア間の再送信率が少なくとも10分間連続して一定の範囲内にある任意の期間として定義します。 これは、短命のイベントを除外することに注意してくださいが、長いイベントの動作に関する洞察を提供します。 再送信イベントごとに、イベント中に対応するスループット値を収集します。 コントロールとして、イベントと同じ期間、ただし3時間前のデータを収集します。 これにより、「During」の再送信イベントと「Normal」の2つのスループット測定が得られます。再送信が行われない時間に測定されます。 次に、POP間のスループットの中央値によって、「During」測定値を正規化します。 しきい値については、0より大きいが25%未満、25より大きいが50%未満、50より大きいが75%未満、最終的に75%を超えるという4つの範囲を考慮します。

図3:各再送信イベント中に観察された非再送信期間との相対スループット。

上の図は、測定期間中に観測された相対スループットの分布を示しています。 第1に、最小の範囲であっても、60%のトランザクションが中央値より低いスループットを達成していることがわかります。 再送信率が高いほど、スループットは低下し続け、再送信率が高いほどスループットが低下し、最悪の場合は1桁以上の相対的な中央値の低下になります。 これらの測定により、再送信率が影響を受けたフローのパフォーマンスの低下をうまく捕捉できることが明らかになりました。

次に、これらのイベントがPOP間のアクティブなICMP測定値とどのように相関するかについて見ていきます。 ここでは、遅延パターンの損失または変化を測定するために、PoP間で定期的にICMPプローブを実行するアクティブモニタリングの一部の動作を検討します。 この分析では、スループット比較から抽出したイベントを再度使用します。 ただし、今回は、ICMPで測定された各しきい値の時間帯の損失を見てみます。この場合、通常は損失は見られませんでした。 ICMPプロービングの制限により、これらの特定の測定では2%の損失粒度が生じることに注意してください。

図4:各時間における観測されたICMP損失。 再送信率が大きいほど、損失が大きくなります。

ここでは、低いしきい値では損失がほとんど示されず、測定値の90%が検出されませんでした。 対照的に、0.75閾値では、測定値の80%が損失を観測し、4%という比較的高い損失中央値を観測した。 重要な点として、再送率がスループットに大きな影響を与えるレベル(例:0.25)でICMPメトリックの損失がほとんどないレベルに注意してください。 これらの知見は、単純なICMPプローブを超えてパスパフォーマンスを測定することの重要性を改めて示しており、インターネット上の実際のフローのパフォーマンスを微妙に把握するための再送信率の能力を浮き彫りにしています。

結論とその先

この記事では、再送率の値を示しました。これは、xTCPソケットデータからも利用可能なデータを使用して簡単に計算できる便利なサマリーメトリックです。 さらに、アプリケーションのパフォーマンスに影響があり、ネットワーク介入が必要な場合について、明確な洞察を提供することを示しました。

再送信率は、当社の監視プロセスの重要な部分となっており、システムパフォーマンスに関する明確な洞察を提供します。大規模で扱いにくいアプリケーションログを処理したり、一部の影響を捕捉できないICMPプローブに依存する必要はありません。

私たちの現在進行中の作業は、劣化の早期警告を提供しながら、より複雑な自動化システムに適切な情報を提供するために、メトリックをできるだけ敏感にする方法を模索しています。

この作業をサポートしてくれたアーキテクチャおよびネットワーク信頼性エンジニアリングチームに感謝します。

Edgio Labs & Advanced Projectsの詳細を知りたい研究者、または上記のトピックに関する共同研究を検討したい研究者は、research@edg.ioまでご連絡 ください。