Home 技術記事 RTTメトリックを使用してストリーミングパフォーマンスを向上させる方法
Applications

RTTメトリックを使用してストリーミングパフォーマンスを向上させる方法

About The Author

Outline

動画の質の高いストリーミングは、絶えず変動するワークロードの管理や、多数の視聴者が同時にストリームに入ったときの「フラッシュクラウド」への対処など、何百万ものことがうまくいくかにかかっています。 そのため、視聴者がテレビのような体験を期待する有料サービスの一部として、信頼性の高い高品質の動画ストリームを配信するには、パフォーマンスの課題を細かく明確にして問題を解決するためのツールと指標が必要です。

CDNは、世界中でオンデマンドで低遅延のスケーラビリティを提供するため、ビデオストリーミングに不可欠なソリューションです。 CDNは、方法を強化する最適化に加えて、ライブストリームに伴う混乱した視聴者の増加のバランスを取ります。エンドユーザーに優れたパフォーマンスを提供するには、可視性、指標、ツール、自動化の追加レイヤーが必要です。

この記事では、北米の大規模なvMVPDストリーミングサービス向けに最近行ったパフォーマンス最適化の例を紹介します。次に例を示します。

  • パフォーマンスの問題を改善/修正するために使用する指標
  • パフォーマンスの定義方法と測定方法
  • 動画のパフォーマンスを向上させるための継続的な最適化

自律システム番号:カーテンの背後にある複雑さ

現代のWebは、ASN(自律システム番号)と呼ばれる複数の相互接続されたネットワーク層を中心に構築されており、それぞれがIPアドレスの大規模なグループとCDN(コンテンツ配信ネットワーク)で構成されています。これらはエッジでコンテンツを利用できるようにすることで輻輳を軽減します。 基本的に、以下に示すように、インターネットはネットワークのネットワークで構成されており、それぞれが独自のビジネスモデルと優先順位を持っています。

出典:リサーチゲート

相互に作用するASNの固有の複雑さと相まって、ASNの範囲と規模は非常に大きい。 vizASツールは、国ごとに多くのASN間の相互接続を視覚化しようとします。 たとえば、米国だけでも、ネットワーク全体に16,979 ASNと24,905ピアリング関係があります。 グローバルには、90,000 ASN以外にも存在します。

https://stats.apnic.net/vizas/index.html

CDNプロバイダーとしての私たちの視点では、数千ものASNへの接続に伴う複雑さは、各顧客のパフォーマンス要件、使用プロファイル、トラフィックの種類、およびその他の多くの要因に対応する必要性によってさらに複雑になります。 たとえば、Twitterのようなサービスは、ゲーム会社が大規模なアップデートを発表するのとは、使用プロファイルやフットプリントが大きく異なります。 同様に、ライブスポーツイベントをストリーミングする放送局は、オンデマンドストリーミングサービスとはプロファイルが異なります。 2つのライブストリーミングサービスであっても、プロファイルが異なる場合があり、それぞれに合わせたパフォーマンスの最適化が必要です。

舞台裏では、お客様がパフォーマンス目標と要件を達成できるように調整および調整できる多数の構成設定が用意されています。 一部の人にとっては、パフォーマンスが最初から期待していたもの(またはそれ以上のもの)である可能性があり、何も変更する必要はありません。 また、ストリーミングサービスの重要な指標である高速TTFB(Time to First Byte)など、特定の目標を設定している場合もあります。

インターネットの複雑さと規模を考えると、「ワックアモール」または散乱的なアプローチで、有用で一貫したパフォーマンスの向上を実現することは不可能です。 包括的なデータ収集と集中的なデータ分析により、問題の根本原因を特定したり、お客様に最も有益なネットワーク構成変更をプロアクティブに把握したりすることで、真のメリットが得られます。

StargazerによるRTTインサイトの提供

ネットワーク遅延と全体的なパフォーマンスの健全性を決定する最も重要なメトリックの1つは、RTT(ラウンドトリップ時間)です。 これはミリ秒単位で定義され、パケットが送信元から宛先に移動し、応答が送信元に返送されるまでの時間です。 輻輳、ハードウェアの問題、設定ミス、ルーティングの問題など、複数のベクトルにわたるネットワークパフォーマンスの診断と向上に使用できます。

このメトリックの重要性を考慮して、当社はStargazerと呼ばれる社内システムを構築しました。これを使用して、当社のセンサー、お客様からインポートしたデータ、RTT情報も監視する第三者など、さまざまなソースからのRTTデータを集約しています。 Stargazerは、クライアントへの送信応答時間を監視します。 その他のデータソースには、ルータからのBGP(Border Gateway Protocol)テーブル、ルータの地理的な場所へのマッピング、クライアントからの接続のRTTログ、トラフィック量情報などがあります。 さらに、必要に応じて、トレースルートやpingなどのアクティブプローブを実行できます。

監視活動の背後にあるStargazerは、当社が開発した他のツールと連携して、収集したすべてのデータを照会し、継続的な改善への扉を開く詳細な分析を実行することができます。 当社のネットワーク管理者は、この情報を使用して問題を切り分け、ネットワークルートまたは構成を特定して、特定のお客様の目標と要件に合わせてパフォーマンスを最適化できます。 また、後で説明するように、BBR(ボトルネック帯域幅とラウンドトリップ伝播時間)プロトコルなどの新しいテクノロジーがパフォーマンスに与える影響を理解するのにも役立ちます。

オリジンサーバの最適化

パフォーマンス最適化が実際にどのように機能するかをより詳しく理解するために、マルチCDNアーキテクチャ向けに最適化する必要がある最近追加されたライブビデオストリーミングのお客様の例を見てみ ましょう。 従来のCDNクライアントアーキテクチャでは、以下に示すように、クライアントはPoPの1つにリクエストを行い、PoPキャッシュはオリジンからいっぱいになります。

しかし、このお客様は、冗長性と復元力を高め、潜在的にパフォーマンスを向上させるために、マルチCDNアーキテクチャを利用することを選択しました。 これは、図4に示すOrigin Shieldアーキテクチャによって実現されます。 Origin Shieldでは、最高のパフォーマンスを得るためにさまざまなクライアントのトラフィックをルーティングする方法をより詳細に制御できます。

従来のCDN関係とは異なり、2番目のCDNが処理するトラフィックを含むすべてのトラフィックは、キャッシュフィルのためにアトランタにあるOur PoP(AGA)の1つに戻ります。 AGA Popはオリジン、つまりより具体的にはオリジンシールドとして機能し、お客様のオリジンサーバーからの大きな負担を軽減します。 AGA Popは、2番目のCDNよりも高いキャッシュヒット率と性能からオリジンシールドの場所として選ばれた。 しかし、大きな懸念事項は、2つのCDN間のパフォーマンスを最適化することでした。

プロセスの最初のステップは、オリジンシールドとして機能する2番目のCDNがAGAに行くルートの最適化を検討することでした。 すぐに明らかになった問題の1つは、CDN間のパフォーマンスの低下と、多数の接続タイムアウトがTTFBに影響を与えていることでした。 パフォーマンスの問題を掘り下げるために、Stargazerを使用してAGAから目的の宛先にtracerouteを送信し、各ホップに使用されるASNをキャプチャしました。

次の要約に示すように、tracerouteがAGAから2番目のCDNのIPアドレスに送信され、クライアントのパスがシミュレートされました。

いくつかのホップがASN 7018内にあることに気づきましたが、これはホップ数が多く、輻輳が多いため、好ましいルートではありませんでした。 Stargazerを使用して、問題を迅速に確認し、適切なネットワーク変更を行いました。 以下のtracerouteの要約が示すように、ネットワークを変更した後、ASN 7922に切り替えることでホップカウントを減らし、RTTを改善しました。これにより、TTFBタイムアウトの問題も解決されました。

別の例では、Stargazerツールを使用して、東海岸にあるお客様のオリジンサーバーへの最適なオリジンシールドパスを決定しました。 お客様のオリジンへの負荷を効果的に軽減し、配送パフォーマンスを向上させるには、オリジンシールドポップをオリジンの近くに配置する必要があります。 時々、それは必ずしも最も近い物理的なポップが最もうまくいくとは限りません。 これは、ASNが最小で、輻輳が最小で、RTT時間が低いという組み合わせです。 下の図の前後に示すように、Stargazer tracerouteは、Nya(ニューヨーク)PopからDCC(ワシントンD.C.)Popに移行するとホップカウントが3に減少し、RTTパフォーマンスが全体的に向上したことを示しています。

Sweeper Fishによる詳細な分析

7,000 +相互接続と、世界中のCDN全体で300以上のPoPを使用することで、継続的な最適化作業が数多く行われています。 あまり変わらないタスクに車輪を回すことを防ぐために、運用チームが取ったアクションに優先順位を付ける効率的な方法が必要でした。 このニーズを受けて、StargazerのコンパニオンツールSweeper Fishが開発されました。Sweeper Fishは、問題が存在する場所を評価し、優先順位を付けてバブルアップできるようにします。

Sweeper Fishは、ルートが混雑しているかどうか、および問題を引き起こす可能性があるかどうかを判断するのにも役立ちます。 マルチCDNの例に戻りますが、Sweeper Fishを使用してどのルートが混雑しているかを検出しました。 これを行うために、Sweeper Fishは、AGA Popへのすべてのパスにわたって、すべてのクライアントのRUM (Real User Measurement)データの25パーセンタイルと75パーセンタイルの間のデルタを測定しました。これは、2番目のCDNのパスであるASN7922に焦点を当てています。 このASN上のすべてのトラフィックの標準偏差を次に示します。

また、ASN7018を使用した以前の構成ではないことも確認しました。 Sweeper Fish分析では、IQR (InterQuartile Range)が20 ~ 60 ~ミリ秒に急上昇していることが示されました(図9)を参照してください。 IQRは、中間拡散または中間50%とも呼ばれ、ルートを分析し、問題に迅速にフラグを付けるための便利な方法を提供します。 IQRが低いほど良いです。

対照的に、AGAポップは、次に示すように、最終的に使用したルートASN7922で一貫して10 ~ 22ミリ秒でした。 Sweeper Fishでは、異なるASNを比較することで、最適で最も混雑の少ないルートを選択したり、修復のための問題を特定したりすることができます。

TCPチューニング

また、輻輳により、パケットがドロップされ、再送信されます。 これは、PoP間のパスが離れており、TCPアルゴリズムが最適化されていない場合に発生します。 AGAはこの例の起源であるため、AGAに到達した遠方のポップではこの問題が発生する可能性があります。 多くのPoPに分散していますが、以下の集約されたCDNログを使用することで、ボックスで示されている問題領域を特定できました。

図11. 集約されたサーバログは、パケットがドロップされて再送信されている問題領域を迅速に特定します。

BBRの評価

Bottleneck Bandwidth and Round-trip Propagation Time(BBR)は、Googleが開発した代替TCP輻輳制御アルゴリズムで、ある程度の牽引力を得始めています。 これは、ユビキタスTCP-Cubicなどの損失ベースの輻輳制御アルゴリズムとは異なり、異なる操作パラダイムを導入します。 バッファの膨張を避けるために、これまでのセッションの最小RTTに基づいて、送信可能なデータ量を継続的に更新します。

BBRはRTT性能の向上に有用であるが,汎用的な解決策には及ばないことが分かった。 使用したいときもあれば、使用しないときもあります。 Stargazerは、目的地へのRTTの一貫したプロファイルを期間にわたって追跡することで、いつ使用するかを決定するのに役立ちます。 これにより、再送信を減らし、フロー制御を改善するためにBBRを適用する最適な場所を決定できます。

下のチャートに示されている分析に基づいて、BBRに切り替えると、2番目のCDNと顧客オリジンへのAGAポップのパフォーマンスがわずかに向上すると結論付けました。 最初のグラフセットは、TCP-CubicからTCP BBRに変更すると再送信が減少したことを示していますが、2番目のグラフセットは、BBRに変更すると平均スループットがわずかに増加したことを示しています。

図12. この例では、TCP-CubicからTCP BBRに変更すると、再送信が減少します。

図13. この例では、AGA PopのTCP-Cubicからフロー制御のためにBBRに切り替えると、再送信が減少し、平均スループットがわずかに向上しました。

結論

インターネットは広大で複雑で、本質的にネットワークのネットワークです。 Edgecast社(現Edgio社)にとって、顧客のユースケースに合わせてパフォーマンスを最適化することは、詳細な分析を実施して問題領域を把握し、可能な構成変更をテストしなければほぼ不可能です。 お客様のパフォーマンスを向上させるために、RTTを継続的に監視する堅牢なツールセットを開発しました。これにより、ネットワーク全体で迅速かつ効率的に改善を行うことができます。 ライブビデオストリーミングサービスでは、アプリケーションに対するBBRの使用を評価しながら、独自の要件に合わせてパフォーマンスを最適化する方法を見つけました。 その結果、2つのCDNを活用した高性能ストリーミングソリューションが実現しまし た。 そして、まだ終わっていません。 ネットワークの輻輳が増加し続ける中で、お客様とそのクライアントが可能な限り最高のオンライン体験を提供できるように、ネットワークの最適化を停止することはありません。