Ivideonチームは、1年以上にわたって、アーカイブされたビデオ録画を独自のクラウドにリモートストレージするサービスに取り組んでいます（この言葉は好きではありません）。 なぜそんなに長い技術的な詳細と、Habrの読者のために無料でアクセスするか-あなたは猫の下で学びます。
なぜ既存のクラウドストレージを使用できないのですか？
クラウドストレージを作成するためのいくつかの有名なプラットフォームがあります。 たとえば、同じOpenStackですが、ちなみにこれもサポートしています。 それにもかかわらず、彼ら自身のために、彼らは彼らの決定を完全に実現しました。 なぜこれをしたのですか？ この質問に答えるには、リモートビデオ監視アーカイブの保存の詳細を理解する必要があります。 事実、ほとんどすべてのクラウドプラットフォームは、主にレコードの読み取り操作を優先するように設計されています。 これが、クラウドへの着信トラフィックが無料であり、発信にお金がかかる理由の一部です。 このようなプラットフォームでは、ほとんどの場合、記録されたファイルがディスクに保存される順序はそれほど重要ではありません。 最適化の作業は確かに進行中ですが。
ビデオ監視システムのストレージでは状況が異なります。 まず、読み取り操作よりも書き込み操作の方が明らかに重要な優位性があります。 すべてのアーカイブされたレコードの1〜2％しか表示されません。 そして時にはそれ以下です。
記録が多数のクライアントで動作検出器を使用して実行されるという事実にもかかわらず、データフローは一定です。 そして、限られた量のハードドライブがなければすべてがうまくいくでしょう。 ある時点で、最も古いユーザーエントリを削除して、新しいエントリ用のスペースを確保する必要があります。 そして、ここで普通の雲の問題はすでに始まっています。
1日の統計によると、平均的なユーザーが1台のカメラから約1200の異なる期間のビデオ監視録画を生成できると想像してください。 録画全体の終了後ではなく、たとえば1分後にユーザーがビデオにアクセスできるようにするには、各録画をクラウドに保存する必要がある小さな部分に分割する必要があります。 つまり、ファイルのサイズは1200でなくてもかまいません。 2500個あるとします。
ここで、1台の物理ハードドライブに、1週間で200人のユーザーからのファイルがあると想像してください。 そして、ある時点で、アーカイブローテーション手順が開始されます-3日間で記録された最も古いファイルを削除します。 約150万のファイルを一度に削除する必要があります！ もちろん、クラウドは機能します。 ゆっくりですが、動作します。 このような負荷に長時間耐えることができないのはハードドライブだけです。ご存知のように、クラウドストレージでは最も高価な要素の1つです。 また、クラウドストレージは平均的なユーザーにとって非常に高価なサービスになると考えています。 そして、私たちは常に人々に最高品質だけでなく、市場に出回っているすべてのものから手頃な価格のサービスを提供するよう努めました。
ストレージの実装方法
Ivideonクラウドは階層構造を持ち、Ivideonプラットフォーム全体の独立した要素として作成されます。 つまり、サービス全体から個別に開発およびテストできます。 比較的独立した開発チームが個々のモジュールで作業できるように、開発全体でこのアプローチを確保するよう努めています。 その結果、プラットフォームの要素の開発速度を上げる機会を得て、新しい開発者をプロジェクトに引き付けます。
フロントエンドとして、大量のRAMを備えたサーバーのグループを使用します。 現在、これらのサーバーにはそれぞれ約96 GBのメモリが含まれています。
このサーバーのタスクは、カメラから完成したフラグメントを数分間蓄積することです。 これらのフラグメントはすべて、RAMのみに書き込まれます。
各カメラに約80〜100 MBが割り当てられます。 サーバーは、さまざまなカメラから多数のビデオフレームを受信します。 フラグメントが完了するとすぐに-バックエンドストレージに送信するためにすぐにキューに入れられます。 1つのフラグメントのサイズよりも多くのメモリが特別に割り当てられるため、完成したフラグメントを送信するときに、新しいフラグメントを記録する場所があります。
バックエンドとは何ですか？ これは、それぞれ36台のディスクを持つサーバーのグループであり、必要なストレージの信頼性の程度に応じて、1つまたは複数のデータセンターに配置できます。 このようなサーバーノードを呼び出します。 各フラグメントは、ユーザーの料金プランの設定に応じて、指定された数のノードで複製できます。 また、ノードの負荷を分散するために、シャーディングメカニズムが使用されます。 ノードでの物理記録の最大速度は、単位時間あたりの送信データ量がこのパラメーターを超えないように計算および制御されます。
ソフトウェアの観点から、OpenStack、web-dav、nfsなどのノードをサポートしています。 ただし、データセンターにアーカイブを保存するために、ノードソフトウェアの独自の実装を使用します。 この場合、それとの通信は内部HTTPベースプロトコルを介して実行されます。 実際、完成したフラグメントのほぼ瞬時の転送とノードでの記録が実行されます。 フラグメントに関するデータを内部データベースに入力するだけでなく。 ベースは、個別のサーバーにインストールされたmongoDBです。
しかし、それだけではありません。 大量の古いレコードを削除し、この削除の結果としてディスクの断片化を減らすという問題を解決するために、ノード実装で独自のファイルシステムを開発しました。 もちろん、これはかなり大きな音に聞こえますが、実際には複雑なことは何もありません。 各フラグメントはディスクに個別のファイルとして書き込まれるのではなく、前のフラグメントと順番に結合され、1時間以内に1つの大きなファイルが記録されます。 次の記事では、これについて詳しく説明します。
アーカイブをローテーションし、数日間データを削除する必要がある時点で、ノードは一時的に記録の準備ができていないとしてマークされ、新しいフラグメントが他のノードに配布されます。 これは、削除中にフラグメンテーションを防ぐためにノードが記録されないようにするためです。
その後、アンインストールプロセス自体が開始されます。 各ファイルは1時間で記録されるため、各ユーザーから7500個の小さなファイルではなく、72個だけを削除する必要があります。
まとめ
ここでは、たとえば、さまざまな料金プランに関連するプラットフォームの多くの微妙な点については触れませんでした。 誰かがアーカイブの週を保持し、誰かが月を保持します。 また、私たちのプラットフォームで使用されている有名な要素を操作する具体的な詳細に焦点を当てませんでした。 たとえば、MongoDB。 そして、これは次の記事のトピックです。
このおかげで、プレゼンテーションが理解しやすく、同時に有用であることが判明したことを願っています。
いつものように、データセンターではLinuxのみを使用し、サーバーソフトウェアを最適化するように追加したいだけです。
そして最後に。 私たちは、リモートストレージプラットフォームの総合的な負荷テストを行うために非常に懸命に努力しました。 それにもかかわらず、ベータモードで起動し、「抑制」関税を設定して、負荷の増加を制御します。 ただし、Habrの読者の1人がテストに参加して私たちを支援したい場合は、個人用メールに書き込み、あなたの個人アカウントの電子メールを入力してください。