私たちは長い間コードを書いてあなたを読み、最終的に企業ブログを始めてRunetの最大のビデオプラットフォームの1つがエンドユーザーにビデオを配信する方法について話をするために影を脱ぐことにしました。



インフラストラクチャとアーキテクチャの原則を明らかにし、使用するソリューションについて説明し、日常的で完全に非標準的な問題を解決した経験を共有し、もちろんすべての苦情や提案に耳を傾けます。



今日のRutubeとは何かをお話しする前に、歴史について少しお話しします。

若い頃：作成とモスクワへの移行

ビデオプラットフォームとWebサイト（「グリーン」RuTube、企業のスラング）は、 InventosによってOrelで発明および開発されました。



2008年、プロジェクトはGazprom Media Holdingに買収され、新しいチームの募集がモスクワで開始されましたが、2009年末まで、Oryol開発者によるサポートが提供されていました。

注意事項：モスクワチームは、全体として負荷の高いシステムの操作経験のある専門家で構成されているにもかかわらず、ビデオの経験はほとんどありませんでした。ゼロから。

私たちは、今日まで改訂された形で使用されていたソリューションのいくつかがすぐに評価されなかったことを認めています。

興味深いのは、チームの重要な部分がこれに由来することであり、最初のモスクワの「呼びかけ」です。



これは、Gazprom-Media Holdingの買収時の2008年秋のプロジェクトのアーキテクチャの様子です。



開発言語はPerlです。 データはMySQLに保存され、そのためにORMが書き込まれました。 Memcachedはキャッシュとして使用されました。 ビデオファイルの保存には、4台のSuperMicroサーバーがいくつか使用され、それぞれ1 TBの16個のディスクがRAID-5アレイに組み合わされました。 各サーバーには独自のバックアップがあり、データの正確なコピーが含まれていました。 DRBD（ブロックコピー）に従ってレプリケーションが発生しました。

注意事項：このようなソリューションの成功例には多くの例があります-スキームは非常に単純で、大きな投資といくつかのトリッキーなツールの知識を必要としませんが、いくつかの欠点があります。 ドライブに障害が発生するとアレイのパフォーマンスが低下し、マスターサーバー全体に障害が発生した場合、クライアントトラフィックを処理する負担がレプリカにかかります。 マスターサーバーがサービスに戻った後、逆方向のデータ複製により負荷が増加しますが、これも喜びを追加しません。

このような条件で16テラバイトアレイの完全なレプリカを作成するには、約1か月かかりました。 活発な手がかりなしで放置されるリスクがありました。



このファーム全体は、FileClusterと呼ばれるツールによって制御されていました。これは、Perlのインターフェースを持つMySQLデータベースでした。 データベースには、ビデオファイルに関するすべての情報、つまり、どの特定のマシン上にあるのかが保存されていました。 FileClusterのアイデアは、すべての物理ストレージを論理的に結合する特定のエンティティからファイルの入力、削除、読み取りの操作を実行できる抽象レイヤーをユーザーに提供することでした。











ストレージとの補助マシン（エンコーダーなど）のすべての通信は、FileClusterを介して行われました。

サーバー間でファイルが転送されたのは、ご想像のとおり、sshによるとlibsshに基づいて作成された特別なユーティリティです。

注意事項：一般に、FileClusterは多くの問題を解決しました。特定の物理ストレージへのアクセスを回避でき、すべてのマシンに多数のマウントポイントを作成する必要がなくなりました。 ただし、これにはいくつかの重大な欠点がありました。たとえば、ストレージをまたいでコンテンツを再配布する機能がないため、新しいストレージの試運転後、負荷が増大していました。

ビデオを配信するためのプロトコルとして、HTTPプロトコル（プログレッシブダウンロード）が使用されました。 当時（2008）には、RTMPのみがフラッシュで再生するための代替手段であったことに注意してください。



ビデオ出力システムは、ストレージキャッシュ（アドビの用語ではオリジンエッジ）の原理に基づいて構築されました。 クライアントは、キャッシュサーバーからビデオを受信します。 要求されたファイルがキャッシュにない場合、リポジトリへの要求が送信され、応答がキャッシュされます。 これは、地理的に分散したコンテンツ配信ネットワーク（CDN）の実装を容易にする非常に柔軟なスキームです。











ビデオ出力の基礎は、別のオリジナルの開発-VideoDと呼ばれるlibeventに基づく特別なデーモンです。 デーモンは、STLを使用してC ++で記述されています。



Runetの昔の人は、当時のRuTubeビデオが独自のiflv形式で圧縮されていたことをおそらく覚えているでしょう。 形式は、キーフレームの数とその場所に関するメタデータを持つ通常のflvファイルでした。 標準的な方法でこのようなファイルを再生することは不可能でしたが、VideoDはビデオの任意の部分を要求できました。 プロジェクトの前には、VideoDを実行している複数のサーバーがありました。 ビデオを要求すると、VideoDはリポジトリにアクセスし、必要なファイルまたはそのフラグメントを取得して、クライアントに提供しました。



バイト範囲のリクエストとキャッシュを実装するために、ストレージを構成するすべてのマシンでVideoDインスタンスが特別なモードで起動されました。 この方法でストレージから受信したファイルの断片は、キャッシュサーバーに格納され、繰り返し要求があった場合、そこから戻されました。

注意事項：VideoDの1つのインスタンスは複数のクライアントにサービスを提供できますが、デーモンはシングルスレッドであるため、ハードディスクからの読み取り操作は他のすべてをブロックしました。 このため、1ギガビットの帯域幅を備えたネットワークインターフェイスが、返されるすべてのサーバーにインストールされました。当時は、それ以上は必要ありませんでした。

ストレージキャッシュスキームの柔軟性は、キャッシュサーバーの負荷分散システムを複雑にすることで実現されます。 バランサーが効果的に機能するためには、システム全体の状態を常に監視し、多数のメトリックを収集および分析する必要があります：キャッシュサーバーの可用性、ネットワークインターフェイスのトラフィック、ディスクサブシステムの読み込み、現在視聴中のビデオ、特定のクリップのリクエスト頻度（人気）、リクエストの配信地域など。 2009年のサンプルのバランス調整システムは、特別なプラグインの形式でPerlbalに基づいて実装され、1つのメトリック（ビデオの人気度）のみを追跡できました。



このメトリックに基づいて、バランシングシステムは、コンテンツをキャッシュするサーバーのグループを選択しました。 ファイルへのリンクを取得するために、バランサーはキャッシュ（memcached）を使用しました。 キャッシュにデータがなかった場合、バランサーはバックエンド（FileCluster）に戻り、リクエストを処理してデータをキャッシュに入れた後、バランサーは再びキャッシュにアクセスしました。











すべてがうまくいった場合、データはキャッシュに正常に落ち、繰り返し使用すると、バランサーはそれを受け取りました。 問題が発生した場合（通常は適切なタイミングではない）、キャッシュに再度アクセスしたときにデータがまだなかった場合、ユーザーはビデオが現在利用できないという悲しいメッセージを見ました。 すでにバランスシステムが別のエンティティであったため、後でバックエンドに大きな変更を加えることなくビデオプラットフォームを再構築できることに注意してください。



すべての負荷は2つのサイト間で分散されました。 メインデータセンターには48台のサーバーがあり、もう16台はRostelecomにありました。 すべてのサーバーは、フォールトトレランスが提供されたIPVSの背後に配置されていました。「フォールンした」マシンは出力に落ちませんでした。

注意事項：すべてが最適に行われたわけではないように思われるかもしれません。 しかし、Inventosはある種の先駆者であり、2008年当時は奇妙に思えた多くの決定が正当化され、時には唯一の正しい決定であったという事実を考慮する必要があります。 いずれにせよ、このアーキテクチャにより、約2万の同時ユーザーにサービスを提供でき、総負荷は25ギガビットになりました。

今日のRutube

2009年以降、プロジェクトのアーキテクチャにグローバルな変化が起こり、その主なものは2012年から2014年に発生しました。 サイトとビデオプラットフォーム自体は完全に書き直されました。



PythonおよびDjangoフレームワークは、メインの開発ツールとして使用されます。 すべての独立したタスク（ビデオ変換、統計、重複検索、Webサイト）は、CeleryベースのRPCを介して相互作用する独立したサービス間で分散されます。 メッセージキューを整理するために、beanstalkが選択されましたが、後にサービス間でトランスポートの大部分を提供するRabbitMQを優先して、それを放棄することが決定されました。 RabbitMQとの相互作用はCeleryを使用して行われます。 キャッシュは、Cacheops + Redisを介して編成されます。 Sphinxは検索に使用されます。



メインデータベースはまだMySQLですが、一部のプロジェクトは新しいライフパートナーを探して着実に「左に」見ています。



すべてのプラットフォームコンポーネントは、2つのデータセンターに複製されます。 メインデータベース間でマスターマスタレプリケーションが構成され、統計など、大量の読み取り負荷が発生するすべてのサービスに対して個別のマスタースレーブレプリカが作成されました。

保管

FileClusterは、FileHeapと呼ばれる新しいツールに置き換えられました。 FileHeapは、SDS（ソフトウェア定義ストレージ）のほぼ古典的な実装です。 すべてがPythonで記述され、MySQLはデータベースとして使用されます。 ファイルの保存には、16 GBのRAM、1つの6コアプロセッサ、および4 TBの12個のディスクを備えた安価な2ユニットサーバーが使用されます。 また、このスキームには、FileClusterから継承されたTsar Disk-NetAppがあります。 安価なストレージの容量を必要なサイズに増やしたらすぐに、NetAppを近い将来廃止する予定です。 ファイルの保存に使用されるすべてのサーバーは、2つのデータセンターに分散されています。 核戦争が発生した場合、FileHeapは常に各オブジェクトの3つのコピーを作成しますが、そのうち2つは必然的に異なるデータセンターに物理的に配置されます。



FileHeapは、各ハードドライブを個別のストレージとして扱い、利用可能なすべてのドライブの均一な充填を監視します。 このようなスキームにより、ニーズに応じてストレージを簡単に拡張したり、故障したハードドライブを簡単に交換したりできます。

ファイルのアップロードと変換

ファイルをダウンロードして変換するために、2つのデータセンターに均等に分割された個別のマシングループがあります。 変換サービスはCeleryライブラリに基づいています。 変換には、ffmpegが使用されます。 各品質のトランスコーディングは個別のプロセスによって開始され、原則として異なるサーバーで開始されるため、コンバーターが「デッド」の場合、ソースが別のコンバーターに保存される可能性はゼロではなく、その結果タスクはエラーなしで終了します。 コンバーター間のファイル転送はWebDAVを介して行われ、nginxがサーバーとして使用されます。



コンバーターのグループを管理するために、ダック（キングのダウンロード、アップロード、変換）と呼ばれる特別なサービスが開発されました。 その助けを借りて、コンバーターの動作、タスクキュー管理、削除および処理のための再設定の監視、およびシステムへの変換のための新しいマシンの導入が行われます。

バランスとCDN

ビデオファイルのアップロードのバランスは、Py3 asyncioライブラリを使用してPythonで実装されます。 いくつかのデーモンは、バランスグループのサーバー上で動作し、すべての送信サーバーの状態を監視し、チャネルの状態を監視します。 さらに、バランサーは動画の視聴回数と人気度に関する情報を保存します。 これらのパラメーターはすべて、ユーザーが要求したコンテンツを迅速に配信するサーバーを決定するために使用されます。 分散サーバー間のデータ交換は、Redisを介して編成されます。



ビデオを要求するときに、キャッシュにクリップの場所のデータが含まれていない場合、バランサーはFileHeapに接続し、物理ストレージから必要なファイルを取得できるキャッシュサーバーへのリンクを形成します。



Rutubeには、ビデオ出力用のサーバーをキャッシュするためのインストールポイントがいくつかあります。 モスクワでは、3つのデータセンターにあります。 サーバーの3分の1は「ホットな」コンテンツ（「インターン」などの人気のあるビデオ）用に設計されています。 「ホット」サーバーでは、最大80ギガビットのスループットを持つネットワークインターフェイスが、「コールド」サーバーでは最大40に引き上げられました。さらに、クラスノヤルスクに1つ、エレバンに2つ、他の通信事業者がサービスを提供します。 現在、配信ネットワークの拡大に積極的に取り組んでいます。



ライブプラットフォーム（GPM Technologyが開発）とインフラストラクチャを統合し、NOW.ruシネマをプラットフォームプレーヤーに移行した後、2015年10月の初めに、Rutubeプラットフォームは最大35万の同時ビデオオンデマンド（VOD）視聴と最大65,000の同時ライブを提供します。合計700ギガビットのトラフィックを伴うストリーム。



しかし、これは限界からはほど遠いです。結局のところ、管理者はサーバーを購入し、ホールディングは新しいチャネルを開き、開発はコードを記述します。