数百Gbpsの負荷に対応するビデオサービスの準備。Yandexレポート

従来のCDN（anycast、GeoDNS、キャッシュ付きWebサーバー）は、単純なファイルと少数のユーザーでうまく機能します。しかし、ストリーミングビデオを配信する必要が生じた場合、すべてがはるかに興味深いものになります。 1つの短い要求の代わりに、数十分続くセッションが表示されます。ユーザーとコンテンツの適切なバランスがなければ、生きることはできません。すべてに十分な現金がなく、ロシアがスペインと対戦するとき、誰もが一度にそれを見たいと思っています。ビデオストリーミングプラットフォーム開発の責任者であるAndreyVasilenkov氏は、このおかげで、CDNにより、数十万のユーザーセッションを同時に処理し、サーバーとデータセンターのシャットダウンを体験できると述べました。そしてボーナスとして、彼は現代のポップカルチャーがどのように学習を妨げるかを例によって示しました。





- こんにちは！数百ギガビット、さらには1秒あたりテラビットの負荷に対応するためにサービスを準備する必要がある場合に、解決する必要のある問題について説明します。 2018年にFIFAワールドカップの放送の準備をしていたときに、このような問題に最初に遭遇しました。



ストリーミングプロトコルとは何か、そしてそれらがどのように機能するかから始めましょう-最も表面的な概要オプションです。







ストリーミングプロトコルは、マニフェストまたはプレイリストに基づいています。これは、コンテンツに関するメタ情報を含む小さなテキストファイルです。コンテンツのタイプ（ライブブロードキャストまたはVoDブロードキャスト（ビデオオンデマンド））について説明します。たとえば、ライブの場合は、現在のようにサッカーの試合やオンライン会議です。VoDの場合、コンテンツは事前に準備され、サーバー上に置かれ、ユーザーに配布できるようになっています。同じファイルに、コンテンツの期間、DRMに関する情報が記載されています。







また、コンテンツのバリエーション（ビデオトラック、オーディオトラック、サブタイトル）についても説明します。ビデオトラックは、さまざまなコーデックで表すことができます。たとえば、ユニバーサルH.264はすべてのデバイスでサポートされています。これを使用すると、家のどのアイロンでもビデオを再生できます。または、4K HDR画像をストリーミングできる、より現代的で効率的なHEVCおよびVP9コーデックがあります。



オーディオトラックは、さまざまなビットレートのさまざまなコーデックで表示することもできます。そして、それらのいくつかもあるかもしれません-英語での映画のオリジナルのオーディオトラック、ロシア語への翻訳、intershum、または、例えば、コメンテーターなしでスタジアムから直接スポーツイベントの録音。







プレイヤーはこれで何をしますか？プレーヤーの仕事は、まず第一に、再生できるコンテンツのバリエーションを選択することです。これは、すべてのコーデックがユニバーサルであるとは限らず、特定のデバイスですべてを再生できるわけではないためです。



その後、彼は再生を開始するビデオとオーディオの品質を選択する必要があります。彼は、ネットワークの状態を知っている場合はその状態に基づいて、または非常に単純なヒューリスティックに基づいてこれを行うことができます。たとえば、低品質でプレイを開始し、ネットワークで許可されている場合は、解像度をゆっくりと上げます。



また、この段階で、彼は再生を開始するオーディオトラックを選択します。オペレーティングシステムに英語があるとします。その後、彼はデフォルトで英語のオーディオトラックを選択できます。おそらくそれはあなたにとってより便利でしょう。



その後、ビデオおよびオーディオセグメントへのリンクの生成を開始します。実際、これらは通常のHTTPリンクであり、インターネット上の他のすべてのシナリオと同じです。そして、彼はビデオとオーディオセグメントのダウンロードを開始し、それらを次々にバッファに入れてシームレスに再生します。このようなビデオセグメントの長さは通常2、4、6秒で、サービスによっては10秒になる場合があります。







CDNを設計するときに考慮する必要があるここでの重要なポイントは何ですか？まず、ユーザーセッションがあります。



ユーザーにファイルを渡して、そのユーザーのことを忘れることはできません。彼は絶えず戻ってきて、新しいセグメントと新しいセグメントを自分のバッファーにダウンロードします。



ここで、サーバーの応答時間も重要であることを理解することが重要です。ある種のライブブロードキャストをリアルタイムで表示している場合、ユーザーがビデオをできるだけリアルタイムに近づけたいという理由だけで、大きなバッファーを作成することはできません。原則として、バッファを大きくすることはできません。したがって、ユーザーがコンテンツを表示する時間がある間にサーバーが応答する時間がない場合、ビデオはある時点で単にフリーズします。さらに、コンテンツはかなり重いです。フルHD1080pの標準ビットレートは3〜5Mbpsです。したがって、1つのギガビットサーバーで、同時に200人を超えるユーザーにサービスを提供することはできません。そして、これは完璧な図です。なぜなら、原則として、ユーザーは時間の経過とともに要求に均等に従わないからです。







ユーザーはどの時点で実際にCDNを操作しますか？インタラクションは主に2つの場所で発生します。プレーヤーがマニフェスト（プレイリスト）をダウンロードするときと、セグメントをダウンロードするときです。



マニフェストについてはすでに説明しましたが、これらは小さなテキストファイルです。このようなファイルの配布には特に問題はありません。必要に応じて、少なくとも1つのサーバーから配布します。そして、それらがセグメントである場合、それらはトラフィックの大部分を占めます。それらについてお話します。



システム全体のタスクは、これらのセグメントへの正しいリンクを形成し、そこにあるCDNホストの一部の正しいドメインに置き換えたいという事実に還元されます。この時点で、次の戦略を使用します。プレイリストですぐに、ユーザーが移動する目的のCDNホストを指定します。このアプローチには多くの欠点がありませんが、重要なニュアンスが1つあります。再生中に、表示を中断することなく、ユーザーをあるホストから別のホストにシームレスに移動するメカニズムがあることを確認する必要があります。実際、最新のストリーミングプロトコルにはすべてこの機能があり、HLSとDASHの両方でサポートされています。ニュアンス：非常に人気のあるオープンソースライブラリでも、標準では存在しますが、そのような可能性は実装されていないことがよくあります。私たち自身がバンドルをShakaオープンソースライブラリに送信する必要がありました。これは、DASHを再生するためのWebプレーヤーに使用されるjavascriptです。



1つのドメインを使用し、それをすべてのリンクに指定する場合、もう1つのスキーム（anycast-scheme）があります。この場合、微妙な違いについて考える必要はありません。1つのドメインを提供するだけで、誰もが満足します。 （...）では







、リンクを形成する方法について説明しましょう。



ネットワークの観点から見ると、大企業は自律システムとして組織されており、多くの場合、1つでもありません。実際、自律システムは、単一のオペレーターによって制御され、外部ネットワークとインターネットで単一のルーティングポリシーを提供するIPネットワークとルーターのシステムです。 Yandexも例外ではありません。 Yandexネットワークも自律型システムであり、他の自律型システムとの通信は、Yandexデータセンターの外部のプレゼンスポイントで行われます。 Yandexからの物理ケーブル、他のオペレーターからの物理ケーブルがこれらの場所に到着し、現場で鉄製の機器に切り替えられます。そのような時点で、いくつかのサーバー、ハードドライブ、SSDを配置する機会があります。これは、ユーザートラフィックを転送する場所です。



このサーバーのセットを場所と呼びます。そして、そのような場所ごとに、一意の識別子があります。このサイトのホストのドメイン名の一部として、またそれを一意に識別するために使用します。



Yandexにはそのようなサイトが数十あり、そこには数百のサーバーがあり、複数のオペレーターからのリンクが各場所に来るので、約数百のリンクもあります。



特定のユーザーを送信する場所をどのように選択しますか？







この段階では、選択肢はそれほど多くありません。決定を下すために使用できるのはIPアドレスのみです。別のYandexトラフィックチームがこれを支援します。これは、企業内のトラフィックとネットワークの仕組みについてすべてを知っており、他のオペレーターのルートを収集して、ユーザーのバランスをとるプロセスでこの知識を使用できるようにするのは彼女です。



BGPを使用して一連のルートを収集します。 BGPについては詳しく説明しません。これは、自律システムの境界にいるネットワーク参加者が、自律システムがサービスできるルートをアナウンスできるようにするプロトコルです。トラフィックチームは、このすべての情報を収集し、ネットワーク全体の完全なマップを集約、分析、および構築します。これを使用して、バランスを取ります。



トラフィックチームから、クライアントにサービスを提供できる一連のIPネットワークとリンクを受け取ります。次に、特定のユーザーに適したIPサブネットを理解する必要があります。







これは非常に簡単な方法で行います。プレフィックスツリーを作成します。そして、私たちのタスクは、ユーザーのIPアドレスをキーとして使用して、このIPアドレスに最も近いサブネットを見つけることです。







それを見つけたとき、リンクのリストとその重みがあり、リンクによって、ユーザーを送信する場所を一意に決定できます。







この場所の重さは？これは、さまざまな場所にまたがるユーザーの分布を管理できるようにするメトリックです。たとえば、さまざまな容量のリンクを作成できます。同じサイトに100ギガビットリンクと10ギガビットリンクを配置できます。明らかに、最初のリンクは容量が大きいため、より多くのユーザーを最初のリンクに送りたいと考えています。インターネットは相互接続されたネットワーク機器の複雑なグラフであるため、この重みはネットワークトポロジを考慮に入れます。トラフィックはさまざまなパスを通過する可能性があり、このトポロジも考慮に入れる必要があります。



ユーザーが実際にデータをダウンロードする方法を監視することが不可欠です。これは、サーバー側とクライアント側の両方で実行できます。サーバーでは、TCP情報ログにユーザー接続を積極的に収集し、往復時間を調べています。ユーザー側からは、ブラウザとプレーヤーのパフォーマンスログを積極的に収集しています。これらのパフォーマンスログには、CDNからファイルがどのようにダウンロードされたかに関する詳細情報が含まれています。



これらすべてを分析して集計すると、このデータを使用して、トラフィックチームが最初の段階で選択した重みを改善できます。







リンクを選択したとしましょう。この段階でユーザーをそこに送ることはできますか？重量は長期間にわたって非常に静的であり、負荷の実際のダイナミクスを考慮していないため、できません。負荷が10％しかない、優先度がわずかに低いリンクが近くにある場合に、たとえば80％が読み込まれたリンクを使用できるかどうかをリアルタイムで判断したいと思います。ほとんどの場合、この場合、2番目を使用したいだけです。







この場所で他に何を考慮する必要がありますか？リンクの帯域幅を考慮し、現在のステータスを理解する必要があります。動作するか、技術的に欠陥がある可能性があります。または、ユーザーがサービスを提供できないようにするために、サービスに持っていきたい場合もあります。たとえば、拡張します。このリンクの現在の負荷を常に考慮する必要があります。



ここにはいくつかの興味深いニュアンスがあります。リンクの読み込みに関する情報は、ネットワーク機器など、いくつかのポイントで収集できます。これが最も正確な方法ですが、問題は、ネットワーク機器では、このダウンロードの迅速な更新期間を取得できないことです。たとえば、Yandexでは、ネットワーク機器は非常に多様であり、このデータを1分に1回以上収集することはできません。システムが負荷に関してかなり安定している場合、これはまったく問題ではありません。すべてがうまくいくでしょう。しかし、突然の負荷の流入があるとすぐに、反応する時間がないだけであり、これは、たとえば、パッケージのドロップにつながります。



一方、ユーザーに送信されたバイト数はわかっています。この情報は、配布マシン自体で収集し、バイトカウンターを直接作成できます。しかし、それはそれほど正確ではありません。どうして？



CDNには他のユーザーがいます。これらのディスペンサーを使用するサービスは当社だけではありません。そして、私たちの負荷を背景に、他のサービスの負荷はそれほど重要ではありません。しかし、私たちの背景に対してさえ、それはかなり目立つことがあります。それらの分布は私たちの回路を通過しないので、このトラフィックを制御することはできません。



別のポイント：送信マシンでトラフィックを特定のリンクに送信したと考えても、プロトコルとしてのBGPはそのような保証を提供しないため、これは事実とはほど遠いものです。そして、あなたが推測する可能性を高める方法がありますが、それは別の議論の主題です。







メトリックを計算し、すべてを収集したとしましょう。ここで、バランスを取るときに決定を下すためのアルゴリズムが必要です。 4つの重要なプロパティが必要です



。-リンク帯域幅を提供します。

-リンクの過負荷を防止します。これは、リンクを95％または98％でロードした場合、ネットワーク機器のバッファがオーバーフローし始め、パケットがドロップし、再送信が開始され、ユーザーがこれから何も得られないためです。

-「飲んだ」負荷を警告するために、これについては少し後で説明します。

「理想的な世界では、リンクを正しいと思う特定のレベルにリサイクルする方法を学ぶことができれば素晴らしいと思います。たとえば、85％のダウンロード。







以下の考え方を参考にしました。 2つの異なるクラスのユーザーセッションがあります。最初のクラスは、ユーザーが映画を開いたばかりで、まだ何も見ていない新しいセッションです。私たちはそれをどこに送信するかを見つけようとしています。または、2番目のクラスは、現在のセッションがある場合、ユーザーはすでにリンクでサービスを受け、帯域幅の特定の部分を占有し、特定のサーバーでサービスを受けます。



私たちは彼らをどうするつもりですか？そのようなセッションのクラスごとに1つの確率値を紹介します。 Slowdownという値があります。これは、このリンクで許可しない新しいセッションの割合を決定します。スローダウンがゼロの場合、すべての新しいセッションを受け入れ、50％の場合、大まかに言えば、2番目のセッションごとにこのリンクでのサービスを拒否します。同時に、より高いレベルのバランシングアルゴリズムは、このユーザーの代替案をチェックします。ドロップ-同じですが、現在のセッションのみです。一部のユーザーセッションは、別の場所のサイトから取得できます。







確率的メトリックの値をどのように選択しますか？リンク負荷のパーセンテージを基準として、最初のアイデアは次のとおりです。ピースワイズ線形補間を使用しましょう。



いくつかの屈折点を持つこのような関数を取り、それを使用して係数の値を調べます。リンクのダウンロードレベルが最小の場合、すべてが正常であり、スローダウンとドロップがゼロに等しい場合、すべての新規ユーザーをに入れます。負荷レベルが特定のしきい値を超えるとすぐに、このリンク上の一部のユーザーへのサービスを拒否し始めます。ある時点で、負荷が増大し続ける場合は、単に新しいセッションの起動を停止します。



ここには興味深いニュアンスがあります。このスキームでは、現在のセッションが優先されます。これが発生している理由は明らかだと思います。ユーザーがすでに安定した負荷パターンを提供している場合、システムのダイナミクスを向上させ、システムが安定しているほど、制御が容易になるため、ユーザーをどこにも連れて行きたくないでしょう。



ただし、ダウンロードは増え続ける可能性があります。ある時点で、いくつかのセッションを取り除いたり、このリンクから負荷を完全に取り除いたりすることができます。



FIFAワールドカップの最初の試合でこのアルゴリズムを開始したのはこの形式です。私たちがどのような写真を見たのかを見るのはおそらく興味深いでしょう。彼女は次のことについてでした。







裸眼でも、外部の観察者はここで何かがおかしいのではないかと理解し、「アンドレイ、元気ですか？」と私に尋ねます。そして、もしあなたが私の上司だったら、あなたは部屋の中を走り回って叫ぶでしょう。すべてロールバック！すべてを元に戻してください！」ここで何が起こっているのかをお話ししましょう。



X軸、時間、Y軸で、リンク負荷のレベルを観察します。同じサイトにサービスを提供する2つのリンクがあります。現時点では、ネットワーク機器から削除されたリンク負荷監視スキームのみを使用しているため、負荷のダイナミクスに迅速に対応できなかったことを理解することが重要です。



リンクの1つにユーザーを送ると、そのリンクのトラフィックが急激に増加します。リンクが過負荷になっています。アンロードして、前のグラフで見た関数の右側にいることに気づきます。そして、古いユーザーを削除し始め、新しいユーザーの受け入れを停止します。彼らはどこかに行く必要があります、そしてもちろん、彼らは次のリンクに行きます。前回は優先度が低かったかもしれませんが、今では優先度が高くなっています。



2番目のリンクは同じ画像を繰り返します。負荷を急激に増加させ、リンクが過負荷になっていることに気づき、負荷を取り除きます。これら2つのリンクは、負荷レベルに関して逆位相になっています。







何ができるの？システムのダイナミクスを分析し、負荷が大幅に増加することでこれに気づき、少し湿らせることができます。これはまさに私たちがしたことです。現在の瞬間を取り、観測ウィンドウを数分間、たとえば2〜3分間過去に取り、この間隔でリンクの負荷がどの程度変化するかを調べました。最小値と最大値の差は、このリンクの発振間隔と呼ばれます。また、この発振間隔が大きい場合は、ダンピングを追加して、スローダウンを増やし、実行するセッションを減らします。







この関数は前の関数とほぼ同じように見えますが、破損がわずかに少なくなっています。オシレーションをダウンロードする間隔が短い場合は、extra_slowdownを追加しません。そして、発振間隔が大きくなり始めた場合、extra_slowdownはゼロ以外の値を取り、後でメインのSlowdownに追加します。







同じロジックが発振間隔の低い値で機能します。リンクの変動が最小限である場合は、逆に、もう少し多くのユーザーをそこに移動させ、スローダウンを減らして、リンクをより有効に活用したいと考えています。







この部分も実装しました。最終的な式は次のようになります。同時に、extra_slowdownとreduce_slowdownの両方の値が同時にゼロ以外の値になることはないため、どちらか一方だけが効果的に機能することを保証します。このバランスの公式がFIFAワールドカップのすべてのトップマッチを生き延びたのはこの形です。最も人気のある試合でさえ、彼女は非常にうまく機能しました：これらは「ロシア-クロアチア」、「ロシア-スペイン」です。これらの試合中に、Yandexのトラフィック量の記録を配布しました-毎秒1.5テラビット。落ち着いて通り抜けました。それ以来、私たちのサービスにはそのようなトラフィックがないため、式はまったく変更されていません-ある瞬間まで。



それからパンデミックがやって来ました。人々は家に座るように送られました、そして家には良いインターネット、テレビ、タブレットとたくさんの自由な時間があります。私たちのサービスへのトラフィックは、有機的に、かなり迅速かつ大幅に増加し始めました。現在、この種の負荷は、ワールドカップのときと同様に、私たちの日常業務です。それ以来、オペレーターを使ってチャネルを少し拡大しましたが、それでも、アルゴリズムの次の反復、それがどうあるべきか、ネットワークをより有効に活用する方法について考え始めました。







以前のアルゴリズムの欠点は何ですか？私たちは2つの問題を解決していません。 「のこぎり」の負荷を完全に取り除くことはできません。全体像を大幅に改善し、これらの変動の振幅を最小限に抑え、周期を大幅に増やしたため、ネットワークをより有効に活用できます。しかし、それらが時々現れるのと同じままです。私たちは、ネットワークを私たちが望むレベルまで利用する方法を学びませんでした。たとえば、この構成を使用して、必要な最大リンク負荷レベルを80〜85％に設定することはできません。







アルゴリズムの次の反復についてどのような考えがありますか？理想的なネットワーク使用率をどのように想定しますか？有望な分野の1つは、トラフィックに関する決定を行うための単一の場所がある場合のオプションであるように思われます。すべてのメトリックを1つの場所に収集し、セグメントをダウンロードするためのユーザーリクエストがそこに届きます。システムの完全な状態が得られるたびに、決定を下すのは非常に簡単です。



しかし、ここには2つのニュアンスがあります。まず、Yandexでは、「共通の意思決定ポイント」を書くことは習慣的ではありません。なぜなら、負荷レベルやトラフィックによって、そのような場所がすぐにボトルネックになるからです。



もう1つのニュアンスがあります。Yandexでフォールトトレラントシステムを作成することも重要です。多くの場合、データセンターを完全にシャットダウンしますが、コンポーネントはエラーなしで、中断することなく動作し続けるはずです。そして、この形式では、この単一の場所は、実際には、制御する必要のある分散システムになります。これは、この場所で解決したいタスクよりも少し難しいタスクです。







確かに高速な指標が必要です。それらがなければ、ユーザーの苦痛を回避するためにできる唯一のことは、ネットワークを十分に活用しないことです。しかし、それも私たちには合いません。



私たちのシステムを大まかに見ると、私たちのシステムはフィードバックのある動的なシステムであることが明らかになります。入力信号であるカスタムロードがあります。人々は行き来します。制御信号があります-リアルタイムで変更できる2つの値です。フィードバックを備えたこのような動的システムでは、自動制御の理論が長い間、数十年にわたって開発されてきました。そして、システムを安定させるために使用したいのはそのコンポーネントです。







カルマンフィルターを見ました。これは、システムの数学モデルを構築し、ノイズの多いメトリックを使用して、またはメトリックのクラスがない場合に、実際のシステムを使用してモデルを改善できる、非常に優れた機能です。そして、数学モデルに基づいて実際のシステムについて決定を下します。残念ながら、使用できるメトリックのクラスが多くなく、このアルゴリズムを適用できないことが判明しました。







私たちは反対側からアプローチし、この理論のもう1つの要素であるPIDコントローラーを基礎として採用しました。彼はあなたのシステムについて何も知りません。その仕事は、システムの理想的な状態、つまり必要な負荷レベルと、システムの現在の状態、たとえば負荷レベルを知ることです。彼は、これら2つの状態の違いをエラーと見なし、内部アルゴリズムを使用して、制御信号、つまりスローダウン値とドロップ値を管理します。その目的は、システムのエラーを最小限に抑えることです。



このPIDコントローラーを実稼働環境で日々試してみます。おそらく数ヶ月以内に、結果についてお話しできるようになります。



これで、おそらくネットワークについて終了します。すでにホスト間でトラフィックを選択している場合に、ロケーション自体の中でトラフィックをどのように分散するかについてお話ししたいと思います。しかし、そのための時間はありません。これはおそらく、別の大きなレポートのトピックです。







したがって、次のシリーズでは、ホストのキャッシュを最適に利用する方法、ホットトラフィックとコールドトラフィックの処理方法、ウォームトラフィックの発生元、コンテンツの種類が配信のアルゴリズムにどのように影響するか、サービスで最大のキャッシュヒットをもたらすビデオとそのユーザーについて学習します。歌を歌う人。



別の興味深い話があります。ご存知のように、春に検疫が始まりました。 Yandexには、教師がビデオやレッスンをアップロードできるYandex.Tutorialという教育プラットフォームが長い間ありました。学生が来て内容を見ます。パンデミックの間、Yandexは学校をサポートし始め、学生がリモートで勉強できるように積極的にプラットフォームに招待しました。そして、ある時点で、トラフィックがかなり増加し、かなり安定した状況が見られました。しかし、4月のある夜、チャートに次のようなものが表示されました。







以下は、教育コンテンツのトラフィックの写真です。ある時点で彼が急降下したのを見た。私たちはパニックになり始め、一般的に何が起こっているのか、何が壊れているのかを調べました。その後、サービスへの全体的なトラフィックが増加し始めたことに気づきました。明らかに、何か面白いことが起こっています。



実際、その瞬間、次のことが起こりました。







これは男がどれだけ速く踊るかです。



リトルビッグコンサートが始まり、生徒全員がそれを見に行きました。しかし、コンサートの終了後、彼らは戻ってきて、さらに勉強を続けることに成功しました。私達は私達のサービスでそのような写真をかなり頻繁に見ます。ですから、私たちの仕事はとても面白いと思います。ありがとうございます！私はおそらくCDNについてこれで終わります。