Top Trends in Cybersecurity for 2024 | 
動画の質の高いストリーミングは、絶えず変動するワークロードの管理や、多数の視聴者が同時にストリームに入るときの「フラッシュクラウド」への対処など、何百万もの物事がうまくいくかにかかっている。 そのため、視聴者がテレビのような体験を期待する有料サービスの一部として、信頼性の高い高品質の動画ストリームを配信するには、パフォーマンスの課題を細かく明確に示すツールと指標が必要であり、問題の解決方法を知ることができる。
CDNは世界中でオンデマンドで低遅延のスケーラビリティを提供するため、ビデオストリーミングに不可欠なソリューションである。 方法を強化する最適化に加えて、CDNはライブストリームに伴う混沌とした視聴者の増加のバランスを取り、エンドユーザーに優れたパフォーマンスを提供するには、可視性、指標、ツール、自動化の追加レイヤーが必要である。
この記事では、北米の大規模なvMVPDストリーミングサービス向けに行った最近のパフォーマンス最適化の例を紹介する。
- パフォーマンスの問題を改善/修正するために使用する指標
- パフォーマンスの定義と測定方法
- 動画のパフォーマンスを向上させるための継続的な最適化
自律システム番号：カーテンの背後にある複雑さ
現代のウェブは、ASN（自律システム番号）として知られる複数の相互接続されたネットワーク層を中心に構築されており、それぞれがIPアドレスの大きなグループとCDN（コンテンツ配信ネットワーク）で構成されており、エッジでコンテンツを利用できるようにすることで輻輳を低減している。 基本的に、以下に示すように、インターネットはネットワークのネットワークから構成されており、それぞれが独自のビジネスモデルと優先順位を持っている。
出典：Research Gate
相互作用するASNの固有の複雑さと相まって、ASNの範囲と規模が非常に大きい。 vizASツールは、国ごとに多くのASN間の相互接続を視覚化しようとする。 たとえば、米国だけで、ネットワーク全体で16,979のASNと24,905のピアリング関係がある。 世界的には、90,000を超えるASNがある。
https://stats.apnic.net/vizas/index.html
CDNプロバイダーとしての私たちの観点からは、数千のASNへの接続に伴う複雑さは、各顧客のパフォーマンス要件、使用プロファイル、トラフィックの種類、およびその他の多くの要因に対応する必要性によってさらに複雑になる。 例えば、Twitterのようなサービスは、ゲーム会社がメジャーアップデートを発表する場合とは、利用プロファイルやフットプリントが大きく異なる。 同様に、スポーツイベントのライブ配信を行う放送局は、オンデマンド配信サービスとは異なるプロファイルを持つ。 2つのライブストリーミングサービスでもプロファイルが異なる可能性があり、それぞれに合わせたパフォーマンス最適化が必要である。
舞台裏では、お客様がパフォーマンス目標と要件を達成できるように調整および調整できる多数の構成設定がある。 一部の人にとっては、パフォーマンスは最初から期待していた(またはそれ以上)ものかもしれず、何も変更する必要はない。 ストリーミングサービスにとって重要な指標であるFaster TTFB（Time to First Byte）など、特定の目標を持っている場合もあり、対処する必要がある。
インターネットの複雑さと規模を考えると、「ワンクワック・ア・モール」や散乱ショットのアプローチでは、有用で一貫したパフォーマンスの向上を実現することは不可能である。 包括的なデータ収集と集中的なデータ分析によって、問題の根本原因を特定したり、顧客に最も利益をもたらすネットワーク設定の変更に関するインサイトを積極的に取得したりすることで、真の利益を得ることができる。
StargazerでRTTインサイトを提供する
ネットワーク遅延と全体的なパフォーマンスの健全性を決定する最も重要な指標の1つはRTT（ラウンドトリップ時間）である。 これは、送信元から宛先へパケットが移動し、応答が送信元に返送されるまでの時間（ミリ秒単位）として定義される。 輻輳、ハードウェアの問題、誤設定、ルーティングの問題など、複数のベクトルにわたるネットワークパフォーマンスの診断と改善に使用できる。
このメトリクスの重要性を考慮して、我々はStargazerと呼ばれる内部システムを構築し、我々は、我々のセンサー、我々が顧客からインポートしたデータ、そしてRTT情報を監視する第三者を含む様々なソースからのRTTデータを集約するために使用している。 Stargazerはクライアントへのアウトバウンドレスポンスタイムを監視する。 他のデータソースには、ルータからのBGP (Border Gateway Protocol)テーブル、ルータの地理的位置へのマッピング、クライアントからの接続のRTTログ、トラフィック量情報などが含まれる。 さらに、システムは必要に応じてtraceroutesや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をキャプチャした。
以下の要約に示すように、AGAから2番目のCDNのIPアドレスにtracerouteが送信され、クライアントのパスをシミュレートした。
いくつかのホップがASN 7018内にあることに気づいたが、より多くのホップが含まれ、より多くの輻輳が発生したため、優先ルートではなかった。 Stargazerを使用して、問題を迅速に確認し、適切なネットワーク変更を行った。 以下のtracerouteの要約が示すように、ネットワークを変更した後、ASN 7922に切り替えることでホップカウントを減らし、RTTを改善した。これにより、TTFBタイムアウトの問題も解決した。
別の例では、東海岸にある顧客のオリジンサーバーへの最適なオリジンシールドパスを決定するために、Stargazerツールを使用した。 顧客のオリジンへの負荷を効果的に軽減し、配送パフォーマンスを向上させるには、オリジンシールドポップをオリジンの近くに配置する必要がある。 時には、必ずしも最も近い物理的なポップが最も効果的であるとは限らない。 最小のASN、最小の輻輳、および低いRTT時間の組み合わせである。 下の表の前後でわかるように、Stargazerのtracerouteは、Nya（ニューヨーク）PopからDCC（ワシントンD.C.）Popに移行するとホップカウントが3に減少し、RTTのパフォーマンスが全体的に改善されることを示した。
Sweeper Fishを使用したより深い分析
世界中のCDNに7,000以上の相互接続と300以上のPoPがあるため、継続的な最適化作業が数多く行われている。 あまり効果がないような作業に歯車を回しないようにするには、運用チームが取ったアクションを優先する効率的な方法が必要だった。 この必要性から、スイーパーフィッシュと呼ばれるスターゲイザーのコンパニオンツールが開発された。スイーパーフィッシュは問題が存在する場所をスコアし、優先順位を付けて問題を浮き上がらせることができる。
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はmidspreadまたはmiddle 50%とも呼ばれ、ルートを分析して問題に迅速にフラグを立てるのに便利な方法を提供する。 IQRが低いほど良い。
対照的に、AGA PoPは、以下に示すように、最終的に使用したルートASN7922では一貫して10-22ミリ秒であった。 異なるASNを比較することにより、Sweeper Fishは最適で最も混雑の少ないルートを選択し、修復のための問題を特定することを可能にする。
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 PoPのパフォーマンスがわずかに向上すると結論付けた。 最初のグラフは、TCP-CubicからTCP BBRに変更すると再送信が減少することを示しているが、2番目のグラフは、BBRに変更すると平均スループットがわずかに増加することを示している。
図12。 この例では、TCP-CubicからTCP BBRに変更すると、再送信が減少する
図13。 この例では、フロー制御のためにBRに切り替えたAGA PoPではTCP-Cubicから再送信を減らし、平均スループットをわずかに改善した。
結論
インターネットは広大で複雑で、本質的にネットワークのネットワークである。 Edgecast（現在はEdgio）にとって、顧客のユースケースに合わせたパフォーマンスの最適化は、問題領域を把握し、可能な構成変更をテストするための詳細な分析なしには不可能に近いだろう。 顧客のパフォーマンスを向上させるために、RTTを継続的に監視するための堅牢なツールセットを開発し、ネットワーク全体で迅速かつ効率的に改善を行うことができる。 ライブストリーミングサービスでは、独自の要件に合わせてパフォーマンスを最適化する方法を見つけ、アプリケーションでのBBRの使用も評価した。 その結果、2つのCDNを活用した高性能ストリーミングソリューションが実現した。 まだ終わっていない。 ネットワークの輻輳が増加し続ける中、顧客とその顧客が最高のオンライン体験を得られるように、ネットワークの最適化を止めることは決してない。
