ビデオホスティングの「コンテンツ」とは何ですか？ まず、ビデオホスティングコンテンツは単なるビデオであり、これはさまざまな形式、特にユーザーがFlash Playerで視聴するためのFLV形式のファイルのセットです。 これらのファイルは静的であり、ユーザーが動画をアップロードすると、動画ホスティングは必要なビットレートですべての必要な形式に変換します。 このようなコンテンツのストレージは、通常のファイルのストレージであり、かなり大きなサイズです。 コンテンツの返却は、本質的に、ファイルをダウンロードする組織です。
第二に、ビデオホスティングコンテンツは「ライブ」ストリームまたはブロードキャストです。 ブロードキャストはディスクに書き込まれず、変換されず、チャネル容量を考慮してクライアントにストリームが配信されます（クライアントチャネルがブロードキャストストリームを完全な品質で受信するには不十分な場合、パケットはスキップされます）。 この状況でのコンテンツのリターンは、接続された多数のユーザー（何千人もの視聴者）へのストリームの配信です。
コンテンツを配信するタスク（正確性、負荷のかかった作業など）に加えて、実際の問題はユーザーへのコンテンツの「近似」です。 ユーザーが帯域幅ネットワークチャネルの観点から、またユーザーのトラフィックのコストの観点から近くにあるサーバーからビデオまたはブロードキャストを受信できるように、コンテンツの配信を編成する必要があります。
RIT：High Load Conference -2008のレポートに基づいて書かれたこの記事では、タスクを解決するための可能なアプローチの1つについて説明します。 このストーリーは、 Smotri.Comビデオホスティングの設計、開発、サポートにおける経験に基づいています。これは、現在Runetで最大のビデオホスティングです。 説明したアプローチは、コンテンツの特性が類似している領域に適用できます。十分な量のファイル、多くのファイル、さまざまな種類のブロードキャストなどです。
この記事は2つのパートで構成されます。最初のパートでは、ビデオファイルのファイルストレージの整理と、放送組織の一般的な側面について説明します。 第2部では、CDN（ コンテンツ配信ネットワーク ）を整理する方法、つまりコンテンツを最終消費者に「もたらす」方法を紹介し、このアプローチを静的ファイル（ビデオファイル）およびストリーミング（放送）の配信に適用します。
ビデオ：ファイルストレージ組織
ビデオファイル
運用中のビデオホスティングは、ユーザーがダウンロードするさまざまな形式のビデオを受信します。 ビデオホスティングは、元のビデオファイルの保存に加えて、ファイルをいくつかの形式（ FLV 、 3GP 、 MP4など）に変換します。 これらのファイルはすべてファイルサーバーに保存し、ユーザーに提供する必要があります。 まず、そのようなファイルの保存を検討してください。
これらのファイルは何ですか？ 計算によると、1秒のビデオを保存するには平均250 Kbのディスク容量が必要で（すべてのビデオ形式を合わせて250 Kb / sを意味します）、平均ビデオ時間は約4分です。 100万のビデオファイルを保存するために60 TBのディスクスペースが必要であると計算するのは簡単です。これはすでに非常に印象的な数字です。 このようなストレージボリュームを効果的に管理するとともに、そのようなコンテンツをユーザーに確実に配信する必要があります。 直接ビデオファイルに加えて、ビデオから切り取られたフレームを保存および提供する必要があります。この場合、15個のピースになります：ビデオのさまざまなセクションから切り取られた5つのフレームで、それぞれが3つの異なるサイズで表示されます（ビデオに関する情報を異なる形式のブロックで表示するため）
WebDAVを介したファイルサーバーへのアクセス
ファイルサーバーは、信頼性とアクセス速度（RAID）の点でかなり適切に構築されたディスクサブシステムがあり、ファイルの保存を直接担当します。 ファイルの変更（新しいファイルの作成、古いファイルの削除など）の要求は、サーバーの別のグループ（「フロント」およびトランスコーダー）から送信されます。 マズルは、サイト自体とそのAPIの両方に直接HTTP要求の大部分を提供する通常のサーバーです。 トランスコーダは、ソースビデオファイルをダウンロードして変換するというユーザーからの要求を受け入れます。 そのため、ファイルサーバー上のファイルに対する操作の順序は、フェイスまたはトランスコーダーで生成されます。 ファイルシステムがローカルではない場合、このネットワークまたはファイルサーバーへのネットワークアクセス手段が必要です。
最も簡単なソリューションはNFSです 。これにより、ファイルをローカルに配置していることをサイトに「感じ」させながら、ネットワーク経由でリモート操作を実行する際のあらゆる困難に対処できます。 ただし、Muzzleとファイルサーバー間のネットワーク接続が切断された場合、NFSは非常に信頼性の低い動作をする可能性があり、多数のMuzzleとファイルサーバーがあるため、NFSクロスマウントの数が大きくなりすぎます。
この状況での別の解決策はWebDAVです。 WebDAVはHTTP拡張であり、ちなみに、もともとWorld Wide Webのコンテンツは静的ではなく、可変であると想定されていました。 WebDAVは、ファイル、ディレクトリのリモート変更、作成、削除、ファイルに関する情報の取得などのためにHTTPに完全な機能を追加することにより、さらに一歩前進します。
ビデオホスティングサーバーのクラスター内では、ファイルサーバーへのアクセスはWebDAVプロトコルを介して行われます。 ファイルのダウンロード（Flash Playerでのビデオの再生を含む）はファイルサーバーから直接行われるため、ネットワークチャネルをより均等にダウンロードでき、「余分な」中間リンクがなくなります。
クラスターからファイルサーバーを選択する
ファイルサーバーのクラスターがあり、全員が構成されており、ファイルを送信する準備ができており、WebDAVを介して新しいファイルを受け入れるとします。 ビデオがアップロードされました。 次のファイルを保存するために選択するファイルサーバーはどれですか？ 選択は、たとえば、次の特性に基づいて行うことができます。
- 空き容量/サーバー容量。
- サーバー負荷（測定方法？）;
- ランダム選択。
不適切な戦略の例として、占有サーバースペースの割合（または単に空きスペースの量）がクラスター内のすべてのサーバー間で等しくなるように、すべてのサーバーをいっぱいにすることがあります。 このアプローチにより、サーバーがいっぱいになりますが、実際には、プロジェクトは複数のファイルサーバーで開始され、それらはますます追加され、新しいサーバーがクラスターに追加されると、すべての新しいファイルがこのサーバーに追加されます（現在サーバー上にあるため）ほとんどの空き領域）。 また、新しいファイルは、特定の期間内で最も人気があることがほとんどであるため、この構成の新しいファイルサーバーの負荷は何倍にも増加します。
そのような戦略は、はるかに成功しています：すべてのファイルサーバーの中で、充填レベルが特定のクリティカルポイントに達していないファイル（つまり、まだ空き領域があるサーバー）が選択され、それらの間でランダムな選択が行われます（おそらく、サーバーの重量を考慮に入れて）。 この戦略により、人気のあるビデオはより多くのサーバーに均等に分散され、コンテンツのダウンロードの負荷をより均等に分散できます。
必要なソフトウェア
上記のアプローチには、シンプルで一般的なソフトウェアが必要です。たとえば、 nginxやlighttpdなどの「高速」HTTPサーバーは、ファイルのダウンロードに適しています。 同時に、FLVが任意のタイムスタンプ（いわゆる「ストリーミング」）からプレーヤーに確実にロードされるようにするには、 nginxとlighttpd （flv-streaming）の両方に存在する非常に簡単な拡張が必要です。 Apache httpdなどは、WebDAVサーバーとして適しています。 WebDAVを介してファイルにアクセスするには、ほとんどすべてのプログラミング言語で何らかの形式で利用可能なWebDAVクライアントを使用できます。 そのため、たとえば、PHPでは、PEARクラスの形式で実装されます（適切なパフォーマンスを確保するには、「仕上げる」必要があります）。 WebDAVは空きディスク容量を取得する機能を提供しませんが、これは最も単純なcronスクリプトを使用して簡単に回避できます。このスクリプトは、dfコマンドの出力をファイルサーバーのルートにあるファイルにリダイレクトします。このファイルは、HTTP経由で任意の銃口から既にダウンロードできます。
クロスバックアップ
60 TBのデータの信頼できるストレージを確保する方法は？ （この数値が大きくなるとしたら？）中央サーバーにバックアップする従来のオプションは、もはや適切ではありません。 このようなストレージボリュームを1台のサーバーに提供することは難しく、そのようなスキームの信頼性は低くなります。 単一サーバー内のRAIDレベルは信頼性を保証できません ハードウェアとソフトウェアの両方の障害が発生し、データが失われます。 シンプルでかなり信頼性の高い方法は、クロスバックアップです。各ファイルサーバーが半分いっぱいになり、最初のサーバーのコンテンツが2番目にバックアップされ、その逆も同様です。 したがって、いずれかのサーバーで障害が発生した場合、2番目のサーバーは両方のサーバーの完全なコンテンツを残します。
このアプローチを実装するには、シンプルな制御モジュールとrsyncが必要です。 クロスバックアップを使用する場合、ファイルサーバー上の空き領域と占有領域に関する情報によれば、その満杯を判断することが不可能であることが興味深い。 バックアップ部分の同期後、ストレージボリュームの任意の増加が可能です（事前に内訳がわからない場合：データ自体が占有する容量と別のサーバーのバックアップが占有する量）。
放送：リレー
放送の編成と放送サーバーに関する詳細な話はすでにRIT-2008カンファレンスで発表されたので、ここでは繰り返しはせず、詳細に入りません。主な側面のみに焦点を当てます。
ブロードキャストは、Flash Playerを使用してクライアント側でエンコードされたビデオおよびオーディオストリームで構成され、RTMPプロトコルを使用してブロードキャストサーバーに送信され、ブロードキャストに接続されたすべての視聴者にRTMPストリームを配信します。 ここでの主な問題は、ストリームがクライアントに配信されることです。ただし、再エンコードは行われません（品質とブロードキャスト作成者が設定したビットレート）が、ブロードキャストに接続するクライアントの数は数千人になります。 同時に、各クライアント（ストリームを通過するパケット）のスループットに従って、変更されたストリームを各クライアントに配信できます。 さらに、RTMPストリームには、ブロードキャストストリーム自体に加えて、リモートプロシージャコール（サーバークライアントまたはクライアントサーバー）があり、共有オブジェクトの状態は、ブロードキャストに接続されたすべてのクライアント間で送信されます。
1つのサーバーがブロードキャストストリームを配信するタスクに常に対応できるとは限らないため、中継に頼ります。ブロードキャストの作成者はプライマリブロードキャストサーバーに接続し、他のブロードキャストサーバーがクライアントとして参加し、最終的にブロードキャスト視聴者にストリームを配信します。 このスキームを使用すると、ブロードキャストサーバー間で負荷を均等に分散できます（各サーバー上のクライアントの数はほぼ同じです）。
次のパートでは、自分の手でCDNを作成する方法について説明します。 継続するには...