しかし、ダウンロードおよび変換システムの残りの要素は、一時的な落ち着きを完全に補償しました。
小児疾患
問題は、アップローダーを介したソースの「物理的な」ロードで始まりました。
2009年に、nginx c nginx-upload-moduleはホストとして機能し、現在のバージョンのWebサーバーをサポートし、ファイルのアップロードの進行状況を正しく提供できましたが、1台のマシンのフレームワーク内のみでした。 また、複数のマシン（実際には2台）があるため、進捗状況は1回おきに正確に機能しました。
ダウンロード後、ファイルはNFSボールに転送され、データベース内の対応するクリップはステータス「変換準備完了」でマークされました。 コンバーターはファイルをNFSからローカルフォルダーにダウンロードし、flv形式で700k @ 360pのようなものを作成し、上からiflvインデックスを「ロールアップ」し、SSHを介してfileClusterサーバーにアップロードしました（FileClusterの詳細については、 こちらを参照してください） ）
注釈：最初の間違いは、1つのプロセスのメモリ内のnginx-upload-moduleの進行に依存することでした。
アップローダーをTwistedに書き換えても、希望する安定性が得られませんでした。別のサーバーへのリクエストによって進行が落ちないように、ハードウェアバランシングのセットアップに多くの時間を費やさなければなりませんでした。 スティッキーセッションが問題を解決するように見えますが、いいえ-彼らもそれを試しました-負荷の不均衡の問題が発生します。 これで、ダウンロードの進行状況がRedisで定期的にスローされ、どのマシンからでも利用できるようになります。
雲が集まっています
ビデオ数の増加に伴い、コンバータースケジューラーに問題が発生し始めました。メインサイトテーブル（トラック）のステータスで変換キューを整理すると、大量のデッドロックとトランザクションタイムアウトが発生し始めました。
その瞬間、Beanstalkdキューサーバーが視野に登場し、変換システムでそれを使用するというアイデアが生まれました。 アップローダーの新しいバージョンでは、ダウンロードが完了すると、beanstalkdでタスクが設定されました。 このタスクは無料の従業員の1人によって行われ、サイトのデータベースと緊密に協力して、ビデオ処理アルゴリズムを使用してビデオを運転しました。
注意事項： Beanstalkdは、タスクの信頼性の高い処理を保証するための最良の選択ではないことがわかりました。 binlogに加えて、バックアップおよび複製ツールはなく、binlog自体は「驚き」です。
たとえば、サーバーがロードされている場合の最も単純なDOSは、誰もリッスンしないキューにタスクを1つ（！）入れることで構成できます。 この場合、binlogは使用可能なすべてのスペースを占有するか、「そのタスク」がキューから削除されるまで拡大し始めます。 私たちの記録は170GBです。 しかし、彼らはなんとかタスクをBuriedステータスに「作業中」の行に入れることに成功しました。永久に延期されました。 Beantalkが「死んだ」場合、そのようなバイナリログではほとんど上昇しませんでした。
その間、人生は止まらず、新しいフォーマットと表示デバイス、新しいタイプのソースファイルの両方をもたらしました。 2011年に、RTMPからHDSに、そしてそれに応じて、元のiflv形式からmp4に切り替えるという疑問が生じました。 「deindexer」がシステムに追加され、iflvが通常の「マシンで読み取り可能な」flvになり、mp4に再パックされました。
注釈： UGCコンテンツは一般に、既成の一連のテストです。音声なしのビデオ、サムネイル付きの音声、および単に「叩かれた」ファイルです。
以前のオリジナリティーが「マシャニャ」のフラッシュクリップとPowerPointプレゼンテーションのみに限定されていた場合、すべてがもっと楽しくなります。 メタデータには、ビデオに関連するオーディオのオフセットとオーディオに関連するビデオのオフセットが同時に示されたファイルがあります。
記録するファッションがありました、それは大丈夫、ただ縦長のビデオであり、撮影プロセス中に何度も向きを変え、未完成のシェアウェアエディターで不幸なビデオファイルを（事前に）編集します。
ヒント：この極端な方法では不十分な場合は、クリエイティブビデオコンテストの主催者になります。
周囲の現実の変化の結果、これら
救助メタプログラミング
松葉杖と論理的枝の全量はすぐにコードの形で開発者の頭に収まりなくなり、グラフ上のメタプログラミングを使用して書き直されました。
タンブラーは言う：
-一般に、これは事実でさえありませんでした。 最初に、ファイル処理アルゴリズム全体をyedエディターで手動で描画しました：理解し、単純化するためです。 その結果、大きなXMLファイルが作成されます。これは、基本的に、頂点とエッジにテキストデータが添付された有向グラフの記述です。
次に、グラフから手動でエンコードするのではなく、Pythonでステートマシンを生成するというアイデアが生まれました。その結果、一連の副作用（ビデオファイルと画像）が生成されます。 グラフの頂点は呼び出された関数の名前に変わり、エッジは条件付き遷移に変わりました。
関数の引数もグラフにきちんと適合します（異なる種類の頂点で）。
注釈： コードとは異なり、グラフ全体が2つのA4シートに完全に収まり、変更や分析に非常に便利でした。 まだ克服していない唯一の欠点は、既存のツールを使用してこのグラフの変更をレビューすることができないことです。
多重ビットレートサポートの出現により、変換管理システムはさらに大きな困難に直面しました：複数のサーバーで1つのクリップを一度に処理する必要があり、ソースファイルの特性に応じて品質のリストを選択するためのトリッキーな条件がありました。センター。
ただし、これらは、ライセンス部門からダウンロードおよび変換システムが受け取った呼び出しと比較すると、依然として「花」です。さまざまなDRMのサポート。 変換パラメーターと優先度のカスタム設定。 既存のビデオの再変換、LIVEストリームからのVODの記録。 mxf（変換中に削除する必要がある論理的な一時停止のマークが付いたファイルを伴う）などの専門的な形式のファイルをロードする。 Rutubeストレージだけでなく、外部アーカイブサーバーにも変換結果を送信します。 ビデオストリームにロゴを追加します。 そして、クリエイティブコンペティションでは、第8シーズンが始まり、ソースフォーマットでの絶妙な実験が続きました。
メタプログラミングはもはや安全ではないことが明らかになりました-より多くのリファクタリングが必要です！
現在のアーキテクチャ
現時点では、管理ロジックはコンバーターから切り離されており、変換に直接関与しています。 また、変換プロセスの管理は、 ダウンロード、アップロード、変換キングの DUCKサービスによって実行されます。
DUCKは、さまざまなサブシステムの要求に応じて、セッションを作成し、セロリでタスクを設定し、サーバーのパフォーマンスと負荷を監視し、最も重要なこととして、主に発生するエラーを追跡するためにタスクからのすべてのイベントを処理します。 これは、一般的に別のサービスであることが判明しました。ここでは、「おい、ファイルを受け取って」と言うことができます。 それを「これ」にして、「ここ」に置きます。 どうやって、この「リンク」を引いてください。
タスクを受け取ったコンバーターは、処理サーバーでDUCKワーカーを実行し、セロリタスクの空のボディを処理コードで「置き換え」ます。
たとえば、タスクコード「duck.download」はFTP / HTTPを介してダウンロードし、エラーとタイムアウトを監視します。 コード「duck.encode.images」は、ソースファイルからスクリーンショットを作成します。
これらすべてのタスクは、「celery.canvas」モジュールからの「チェーン」と「コード」にラップされ、基本クラス「celery.Task」は追加機能を取得しました。特定の条件下では、長いチェーンをスキップして最終部分「duck.cleanup」 "; これにより、たとえばビデオの作成段階でファイルが破損していることが判明した場合、チェーンのすべてのタスクを実行することなく実行できます。
一方、未知のエラーはすべて自動的にWTFキューに分類されます。 開発者がすくい上げます（通常、そのようなケースはそれほど多くありませんが、興味深いものです）：バグトラッカーのバグになるか、チェーンの最初からタスクが新たに実行されます（たとえば、ファイルが処理されたサーバーが「死んだ」場合）。
DUCKは、セロリの「カメラ」を使用してタスクの進行状況を監視します。変換セッションは、「カメラ」に到達したイベントに応じてデータベースのステータスを変更します。 エラーとタスク処理の進行状況は自動的に処理されます。 同時に、処理されたファイルがFileHeapに正常に保存されたことを記録するなど、最も重要なイベントはRPCを介して行われます。このようにして、ファイルは失われません。
DUCKは、異なるユーザーの変換設定も保存します。 優先設定として使用できます（たとえば、スポーツの生中継のハイライトをすぐに視聴できるようにする必要があり、過去数年間のアーカイブのアップロードはバックグラウンドで数週間行われます）。 処理および変換される動画の数の制限も同様です。 設定では、各品質のカスタム変換パラメーターを指定できます（4Kが必要ですか？-ようこそ！）。 「黒いバー」（「テレビ」ソースの一般的な問題）をトリムし、サウンドを正規化し、ビデオストリームにロゴを追加し、不要なフラグメントを自動的に「カット」する必要があります。
もちろん、カスタム編集の可能性をフロントエンドでラップし、すべての人がアクセスできるようにしたいと考えています（ダッシュボードプロジェクトのフレームワーク内でこれを少し行っています）が、これまでの目標は、変換を大幅に高速化することです。 予備的な見積もりによると-ほぼ10回。 結果についてお知らせします！