Home 技術記事 大規模CDNでのBBR評価
Applications

About The Author

Outline

ボトルネック帯域幅とラウンドトリップ伝播時間(BBR)は、多くのコンテンツプロバイダーによって報告されているように、より高いスループットを提供する能力のために市場で大きな注目を集めているTCP輻輳制御アルゴリズムです。 この記事では、大量のソフトウェアアップデートとストリーミングビデオを配信するVerizon Media(現Edgio)のコンテンツ配信ネットワーク(CDN)ワークロード(バージョン1))を評価し、トラフィックに対する利点と影響を定量化します。 大規模なCDNでのこのような評価が、他のコンテンツプロバイダーがトラフィックに適した輻輳制御プロトコルを選択するのに役立つことを願っています。

背景

多くのコンテンツプロバイダーや学術研究者は、BBRがTCP-Cubicなどの他のプロトコルよりも高いスループットを提供することを発見しています。 ユビキタスなTCP-Cubicのような損失ベースの輻輳制御アルゴリズムとは異なり、BBRには異なる運用パラダイムがあります。BBRはバッファブロートを回避するために、セッションがこれまでに見た最小RTTに基づいて、どれだけのデータが送信可能かを継続的に更新します。 BBRの運用についての詳細は、こちらのGoogle社のオリジナルの出版物をご覧 ください。

測定と分析

CDNにおけるBBRの可能性を理解するために、複数の段階でBBRを評価し、少数のPoPからのTCPフローへの影響を測定しました。 PoPは、大都市圏にあるキャッシングサーバーの集中を表します。 最初に、小規模なBBRテストをPOPで実行し、また、BBRを実行しているクライアントへのすべてのフローを使用して、フルPOPテストを実行しました。 クライアントが経験するメリットを特定するために、テスト中に社内のプロキシWebサーバーログからのスループットとソケットレベルの分析を測定しました。

評価するメトリック

当社のマルチテナントCDNでは、さまざまなクライアントトラフィックが検出されます。 多くのお客様は小さなオブジェクトをたくさん持っていますが、他のお客様ははるかに大きなマルチギガバイトのオブジェクトを持っています。 したがって、さまざまなトラフィックパターンで実際のパフォーマンス向上を把握する成功指標を特定することが重要です。 特に、この評価では、スループットとTCPフローの完了時間を成功パラメータとして特定しました。 図1では、CDNから要求された一般的なオブジェクトサイズと、それらを提供するのにかかる時間のヒートマップを示しています。 色のグラデーションは、各カテゴリのリクエスト数を示します。 これらは、一般的な動作だけをキャプチャするのに十分な、少数のサーバセットからの代表的な数値です。

図1。 一般的なオブジェクトサイズを示すヒートマップ。

ヒートマップは、さまざまな要求パターンを理解することができます。 一般的に、スループットを向上させることは、パフォーマンスの向上を示す最良の指標です。 ただし、測定としてのスループットは、特にオブジェクトサイズが小さい(数MB未満)場合には非常にノイズが多い場合があります。 そのため、スループットの評価に最も信頼性の高いサイズを個別に評価し、スループットの評価には3MB以上のオブジェクトサイズのみを使用します。 オブジェクトサイズが3 MB未満の場合は、フロー完了時間の追跡が適しています。

評価の最初のステップとして、ロサンゼルスのPOPでいくつかのサーバでBBRを有効にし、すべてのTCPフローのスループットとフロー完了時間を監視しました。 次の結果は、いくつかのインターネットサービスプロバイダ固有のケーススタディを調べたものです。

大規模なワイヤレスプロバイダ

図2は、BBRをオンにしたときの違いを示しています。

図2。 BBRをオンにしたとき(テスト)、キュービックフロー(制御)と比較したときの、大規模なワイヤレスプロバイダーのクライアントのスループットへの影響。 左:2日間のスループット測定。 青の縦線は、BBRがアクティブになったことを示します。 ここでは、BBRでは全体的に約6 ~ 8%の改善が見られます。 右:5パーセンタイルスループットのCDF。 BBRフローは大幅な改善を示しています。

このワイヤレスプロバイダでは、BBRを有効にするとすぐに、スループットが平均6 ~ 8%向上しました。 全体的にTCPフローの完了時間も短縮されました。 この発見は、パケット損失が一般的なワイヤレスネットワークでスループットの明確な向上が見られるSpotify、Dropbox、YouTubeの他のレポートと一致するが、必ずしも輻輳の指標ではない。

大規模な有線プロバイダ

次に、大規模な有線プロバイダーのパフォーマンスを調べました。 また、スループット(大きなオブジェクトの場合)とフロー完了時間(図3参照)の両方を確認しました。 BBRを使用した改良。

図3。 大規模な有線プロバイダーのフローを完了するのにかかる平均時間。 BBR(テスト)フローでは、ジッタが少なく、データ転送の完了にかかる時間が短くなります。 大きなオブジェクトでは、より大きなメリットが得られます。 ただし、CubicとBBRの両方で大きなファイルサイズでは、同様のジッタが発生します。

これらのテストから報告された利益は、クライアント側トラフィックの非常に有望な結果を示しています。

これらの利益は集約ビューに基づいているため、PoPのすべてのTCPフローがBBRを使用する利点を見たかどうか、または一部のTCPフローが影響を受けたかどうか、およびどのフローが影響を受けたかを確認するために、もう少し掘り下げて確認することにしました。

CDNエッジでは、次の4種類のTCPセッションを実行します。

  • Pop-to-Client(上記のように)
  • ポップツーポップ(データセンター間)
  • ポップ内通信(同じポップのキャッシュ間)
  • POPからオリジン(POPからカスタマーオリジンデータセンター)

この研究では、エッジからオリジンへのフローは他の3つのフローほど大きくないため、Pop-to-Client、Pop-Pop、およびIntra-Popフローを検討しました。

ポップツーポップおよびイントラポップトラフィック

多くの場合、これらのTCPフローは動的コンテンツなどのクライアント配信のブロッカーであるため、これらのTCPフローへの影響も評価することが重要です。

ポップツーポップおよびイントラポップのトラフィックスループットでは、パフォーマンスが大幅に低下しています。 図4は、同じ期間におけるイントラポップトラフィックとポップツーポップトラフィックへの影響を示しています。

図4。 BBRをオンにしたとき(テスト)、キュービックフロー(制御)と比較したときの、イントラポップおよびポップツーポップトラフィックのスループットへの影響。 2日間のスループット測定。 青の縦線は、BBRがアクティブになったことを示します。 スループットはBBRで約半分に低下しました。

エンドユーザーへのフローとデータセンター間のこのような明確なパフォーマンスの違いは、これまでの調査結果では報告されていません。 これらの特定のTCPフローがなぜ影響を受けたのか、CDN上のハードウェアまたは設定のアーティファクトである場合、およびその場合、どのような調整を変更する必要があるかを評価する必要があります。

Webサーバのアクセスログを用いてさらに調査し,サーバ側のソケットデータから評価したところ,RTTの高さと低さの両方のフローが存在する場合には,RTTが非常に低いTCPフローがBBRを使用していたことが明らかになった。 さらに0.5KB以下のデータが転送された場合を評価したところ、BBRはほとんどの場合Cubicと同様に機能することがわかりました。

これらの結果から、トラフィックパターンについては、RTTと損失が少ないイントラポップおよびポップツーポップ通信には、キュービックを使用する方が良いと結論付けました。 クライアント側トラフィックの場合は、BBRを使用する価値があります。

フルポップテスト

BBRのパフォーマンス上の利点を大規模に評価するために、リオデジャネイロのPOPで、そのPOPでネットワークからのクライアントに面したすべてのトラフィックについてフルPOPテストを実行しました。 このPOPは興味深いケーススタディを作成しました。このケーススタディは、リージョン内のロケーションとピアリングの制約により、クライアントが経験するRTTの中央値が他のリージョンよりも高くなるためです。

図5。 再送信回数が多い(ASN1)ため、クライアントのBBRを使用したスループットの向上。

輻輳制御アルゴリズムの変更を展開し、パフォーマンスを監視しました。 RIOの上位2つのASE(自律システム)についてBBR vs. Cubicを使用して観察されたスループットのCDFを示した。 図5に示すように、1つのASは全体的にBBRの利点を見たが、もう1つのASはそうではなかった。

その背後にある理由を調査するために、ssユーティリティを使用してテスト中に収集された他のTCPメトリックを調べました。 これら2つのAS間の再送信レートには明確な違いがあります。 RTTが高いASであっても、BBRは再送信回数が多い場合にのみ有効です。言い換えれば、損失の少ないASでは、Cubicはバックオフする理由がなく、BBRよりも優れたパフォーマンスを発揮します。 ただし、TCP Cubicのパラメータの多くは、CDNで慎重に調整されていることに注意することが重要です。

次に、図5に示すASN1からのすべての接続でスループットが向上しているかどうかを調べました。 図6は、さまざまなオブジェクトサイズのBBR接続とキュービック接続によってかかった時間のプロットです(低いほどスループットが向上します)。 ここでは、BBRはMBのオーダーで、大きなオブジェクトに対して顕著な利点を示し始めただけであることがわかります。 BBRを使用した異常なインスタンスが1つ見つかりましたが、輻輳制御プロトコル関連の特定の問題に起因するものではありませんでした。

図6。 改善が見られるASEの場合、BBRの利点は、大容量ファイルを含む長時間実行フローで見られます。

なぜこれが起こるのですか?

これらの結果には2つの側面があります-立方対BBRおよびBBR対BBRです。

キュービック対BBR

BBRは、ボトルネック帯域幅を見積もるときに、バッファサイズとRTTに非常に反応します。 ミドルボックスがキューを構築する可能性がある大きなバッファの場合、BBRの推定RTTは増加します。 パケット損失がないため、このような場合、つまりポップツーポップのようなトラフィックがバックオフされないため、Cubicはより高いスループットを実現します。 無線クライアントなどの小さなバッファの場合、バッファは急速にいっぱいになり、損失が発生します。したがって、キュービックフローはオフになり、BBRフローのパフォーマンスが向上します。

BBRとBBR

このシナリオでは、損失が発生してもフローは戻りません。 ただし、RTTが異なる2つのフローが帯域幅のシェアを競う場合、RTTが大きいフローの最小RTTも大きくなり、帯域幅遅延積も大きくなります。 したがって、このフローは、RTTが低いフローよりもはるかに速いレートで、飛行中のデータを増加させます。 これにより、RTTの降順でフローへの帯域幅の再割り当てが行われ、RTTの値が大きいフローは、RTTの値が小さいフローよりも早くバッファをいっぱいにします。

ラボ設定での結果の再現

フロー間の相互作用をさらに理解するために、本番環境で見た動作をキャプチャするテストベッド環境を仮想マシンに作成しました。 エッジサーバーでさまざまなトラフィッククラスをシミュレートする方法を次のように特定しました。

クライアントトラフィック遅延は最大50msに設定され、損失範囲は0.001 ~ 0.1、ボトルネック帯域幅は50Mbpsでした。 同様に、ポップツーポップの場合、損失と遅延は約15msに設定され、0.0001は0.01に設定されました。 イントラポップトラフィックでは、VMに使用可能な容量を最大化します。 最後に、さまざまなオブジェクトサイズを使用してシミュレーションを実行し、トラフィックのマルチテナントの性質を把握しました。 Poissonスタイルのフロー到着分布を捕捉するために、3つのトラフィックパターンすべてをフローの指数到着と並行して実行します。 図7は、テストベッドのセットアップを示しています。

このテストの目的は、実稼働テストで見られる問題、特にイントラポップトラフィックとポップツーポップの小さなRTTフローのスループットの低下を再現することでした。

図7。 kvm’iperf’netem’tcユーティリティを使用した実習のセットアップ

このセットアップを使用して、キュービックとBBRの両方のシミュレートされたバックグラウンドトラフィックと、フローを完了するためにかかった測定時間を使用して、シミュレーションを何百回も実行しました。 バックグラウンドトラフィックの目的は、実稼働環境と同様の環境をシミュレートすることです。 多くの既存の研究は、CubicとBBRのいくつかのフローを実行し、それらの行動を評価することに焦点を当てていました。 このような場合、フローごとの動作を理解することは有用ですが、大規模で大量のCDNの複雑さはあまりわかりません。 ファイルサイズが小さいとスループットがノイズになる可能性があるため、クライアント側のフロー完了時間を信頼できる指標として使用しました。

図8。 イパーフの流れにかかる時間。 左:クライアントフロー 右:ポップツーポップフロー。 オブジェクトサイズ:3MB。 シミュレートされたクライアントフローでは、BBRはキュービックよりも優れていました。

テストベッドでもパターンが再現されました 図8では、BBRとキュービックアイパーフフローが消費するCDFを、クライアントトラフィックと3MB(中規模)ファイルのポップツーポップトラフィックの2つのシナリオで示しています。 低損失高帯域幅セットアップでは、BBRフローは立方晶に追いつくことができません。 クライアントトラフィック(低帯域幅)は改善されました。つまり、BBRフローにかかる時間が短くなりました。 ただし、小さなファイルの改善はわずかです。 テスト環境でこれらの動作を再現することで、異なるフロータイプ間の相互作用の結果であるという確信が得られます。 そのため、CDNにBBRを導入する場合は、さまざまなフロータイプにBBRが与える影響が大きいことを認識する必要があります。

結論

その結果,BBRフローはすべてのシナリオでうまく機能しないことがわかった。 具体的には、BBRを使用すると、データセンター/ポイントオブプレゼンス(POP)内のトラフィックおよびデータセンター間のトラフィック(POPからPOP)が発生します。 極端な場合には、スループットが半分に低下することもあります。 ただし、Pop-to-Clientトラフィックのスループットは6 ~ 8%向上しました。

この記事では、BBR(version 1) in the context in the context of our CDN)の評価について概説しました。 私たちは、1回のPOPで数台のサーバーをテストし、大規模なコンテンツプロバイダーとして関心のあるさまざまな変数を評価しました。 大規模なフルPOPテストでは、再送信が多いASEでBBRが最も役立つことがわかり、大きなファイルにBBRを使用する価値があることがわかりました。

ここからどこに行くの?

システムレベル(すべてのフロー)でBBRをイネーブルにすると、イントラポップおよびポップツーポップのトラフィックがスループットの低下を被るリスクがあります。

ただし、BBRは潜在的な可能性を示しており、クライアント側のトラフィックに対しては良好なパフォーマンスを発揮しています。 これにより、ワイヤレスプロバイダから開始する場合もありますが、クライアントのBBRを選択的に有効にすることになります。 さらに、これらのパスには浅いバッファと無線損失があり、BBRが他の立方晶流よりも優れたパフォーマンスを発揮するのに理想的な状況です。

この概要が、大規模なコンテンツプロバイダーでのBBRの使用と、ボトルネックを共有する可能性のあるさまざまなタイプのトラフィックへの影響について、ある程度明確になることを願っています。 BBRv2のアルファリリースが利用可能になりました。これにより、これらの問題の一部が解決されます。 今後もBBRの新バージョンの評価を継続し、適切なタイプのフローに対して適切な輻輳制御を選択するインテリジェントトランスポートコントローラを使用する予定です。 詳細については、今後説明します。

この分析を可能にした組織全体のさまざまなチームの貢献に感謝します。