オンラインシネマのバックエンドのスケーリングの難しさ。Yandexレポート

KinoPoisk HDのバックエンドは、Over the Top（OTT）テクノロジーを使用してコンテンツをさまざまなデバイス、地域、サイトに転送するためのプラットフォームです。ビデオテクノロジーPlayButtonに関する会議で、私は個人的な推奨事項をどのように作成するか、どのような困難に対処し、どの問題を克服するかについて話しました。





-オンラインシネマがどこから来たのかから始めましょう。







インターネットの開発の過程で、ケーブル、衛星、その他の通信チャネルが使用されていた従来のメディアサービスとは対照的に、インターネットを介してメディアコンテンツを転送するために使用されるようになったOTTメディアサービスが登場しました。



このようなメディアサービスは、コンテンツ管理システム、Webプレーヤー、CDNを含むオンラインビデオプラットフォームであるOVPに基づいています。このようなシステムの別のクラスは、オンラインシネマであるOTT-TVです。これは、OVPに加えて、コンテンツへのアクセスの制御および管理システム、デジタルコンテンツの権利保護システム、サブスクリプション、購入の管理、およびさまざまな製品および技術メトリックを実装します。また、これらのシステムには、稼働時間と待ち時間の要件が増加します。



コンテンツ管理システム、オンラインシネマのユーザー機能、およびコンテンツ管理および制御システムの一部を担当するバックエンドについて説明します。







オンラインシネマが何でできているか見てみましょう。 KinoPoisk HD Parallelepipedには、あらゆる種類のクールなものと表示モードが実装されています。何千人ものRPSユーザーがストアフロントで利用可能なコンテンツを選択し、サブスクライブして購入します。閲覧の進行状況、ユーザー設定を保存します。何千ものRPSがさまざまなメトリックを生成します。これはかなり大きくて興味深いコンポーネントのセットであり、その詳細については今日は説明しません。しかし、一般的に、これらはユーザーによってシャーディングされるという事実のために、優れた、理解できるほどスケーラブルなサービスであることに言及する価値があります。



今日は、ボックスの下のクラウドに焦点を当てます。これは、映画、シリーズ、著作権所有者からのさまざまな制限を保存するためのプラットフォームです。いくつかの部門の努力によってサポートされています。このプラットフォームの一部は、この場所で今見ることができる質問に答えるアクセシビリティトランスフォーマーです。アクセシビリティトランスフォーマーがないと、KinoPoiskHDに文字通りコンテンツが表示されません。



トランスフォーマーの課題は、柔軟で階層化されたアクセシビリティモデルを、できるだけ多くのコンテンツコンシューマーに適切に拡張できる効率的なモデルに変換することです。



なぜそれは柔軟でスケーラブルなのですか？主な理由は、コンテンツ、収益化、リレーショナル可用性、およびサイトでの可用性を説明するさまざまなエンティティが含まれているためです。これはすべて革命的な関係にあり、複雑な階層を持っています。そして、この柔軟性は、数十の著作権所有者の要件とさまざまな柔軟な価格設定オプションを満たすために必要です。



プラットフォームとは、たとえば、Web上のオンラインシネマ、デバイス上のオンラインシネマ、およびコンテンツを再生するその他のパートナーOTTサービスを意味します。



このようなマルチレベルモデルの可用性を効率的に計算するには、複雑な結合を構築する必要があり、そのようなクエリはどのような負荷にも対応できず、解釈が非常に複雑で、いくつかの機能をすばやく明確に構築できることは明らかです。これらの問題を解決するために、アクセシビリティトランスフォーマーが登場し、スライドに表示されたモデルを複合キーとして非正規化しました。これには、コンテンツID、国、サイト、サブスクリプション、およびメモリの大部分を構成するいくつかの非表示の非キー残差が含まれます。今日は、アクセシビリティトランスのスケーリングの難しさについてお話します。







このコンポーネントをさらに深く掘り下げて、それが何で構成されているかを見てみましょう。ここでは、問題が発生する直前のシステムの状態を確認できます。この間ずっと、アクセシビリティトランスフォーマーはオンラインシネマの超高速開発の道に沿って動いています。何万もの映画やテレビシリーズの可用性を確保するために、まず第一に、新しい機能を迅速に立ち上げることが重要でした。



左から右に行くと、CMSがあります。これは、第3の通常の形式とEAVのリレーショナルデータベースです。私たちの主要なエンティティが保存されます。次はスナップショットローダーです。さらに、関連データを定期的に受信するスナップショットジェネレーターは、それをフィルター処理して、スナップショットストレージに追加します。これは実際にはSQLダンプです。さらにリクエストプロセッサインスタンス内で、スナップショットローダーは定期的に新しいデータを受信して​​H2にインポートします。 H2は、DBMSの基本機能を実装する、Javaで記述されたメモリ内データベースです。つまり、クエリインタープリター、クエリオプティマイザー、およびインデックスがあります。



実際、これはまさに、SQLクエリを記述し、非正規化されたエンティティをすばやく簡単に結合できるため、オンラインシネマの新しい機能を作成する柔軟性を提供するコンポーネントです。



H2は、コピーオンライトモデルで更新されます。スナップショットローダーは、新しいデータベースインスタンスを取得し、それを設定します。そして、充填後、ガベージコレクターを使用して古いものを処分します。



H2と同時に、複合エンティティとその上のインデックスを含むエンティティキャッシュが発生します。複合エンティティは、基本的に、クライアントからのより要求の厳しい遅延要求に対応するために、H2にあるものの非正規化の継続です。キャッシュエンティティは、コピーオンライトモデルを使用して同じ方法で更新されると同時に、新しいH2インスタンスが発生します。



システムの主な利点：結合を使用して、新しい機能を簡単かつ柔軟に追加できます。コピーオンライトによってデータを更新するための比較的単純なスキーム。もちろん、欠点は、これらのエンティティを保存および更新するために2倍のメモリが必要になることです。これは、ガベージコレクターによって破棄されるため、ユーザー要求に間接的に影響します。



また、エンティティキャッシュを構築する際、インデックス作成にはCPUリソースが必要です。また、これは間接的にユーザーリクエストにも影響しますが、CPUリソースの競合が犠牲になります。これらの両方の点が合わさって、メインエンティティのデータ量の増加に伴い、クエリプロセッサはCPUとメモリの両方の観点から垂直方向にスケーリングする必要があるという事実につながります。



しかし、このシステムは、オンラインで入手できる何万もの映画やテレビシリーズに依存していました。したがって、長い間、これらの不利な点は受け入れられ、オンラインシネマの新しい機能を導入する柔軟性と容易さという点で主な利点を活用することを可能にしました。



これらすべてが特定の時点まで機能したことは明らかです。この黄色いバスが私たちのアクセシビリティトランスであると想像してください。







非正規化によって複製されたフィルムやシリアルをホストします。つまり、それらは数万あります。そして、ある停留所では、何十万ものミュージックビデオやトレーラーを持ち上げて、なんらかの方法で配置する必要があります。搭載されると、非正規化のためにそれらも増殖します。内側にいる人は縮む必要があり、外側にいる人は飛び込んで通り抜ける必要があります。あなたはこれがどのように起こるか想像することができます。技術的には、現時点では、インスタンスのメモリ容量は数十ギガバイトに増加しました。ガベージコレクターを使用してキャッシュを構築し、古いインスタンスを破棄するには、いくつかの仮想コアが必要でした。また、データ量が劇的に増加したため、この手順全体で、新しいコンテンツを公開するのに数十分かかるという事実につながりました。







技術的には、クエリプロセッサクラスターでCPU使用率が確認されています。塹壕（数千RPSのオーダーのクライアント要求の処理）と丘では、同じ数千RPSに加えて、スナップショットの同じロードとガベージコレクターを使用したそれらの廃棄。下の2つのグラフは、コンテナでのCPU待機です。スナップショットをダウンロードして廃棄した瞬間にも、それらが現れ始めていることがわかります。







これらのミュージックビデオとトレーラーに対応し、拡張を続けるために、アクティブおよびパッシブリクエストプロセッサインスタンスを導入しました。実際、これは1レベル上のコピーオンライトの転送です。これで、コンテナにアクティブインスタンスとパッシブインスタンスの両方があります。パッシブは新しいH2とエンティティキャッシュを準備し、アクティブは単にユーザーの要求を処理します。したがって、ガベージコレクションとその一時停止がユーザーリクエストの処理に与える影響を軽減しました。しかし同時に、それらは同じコンテナ内に存在するため、スナップショットのロードとキャッシュの構築はCPUリソースをめぐって競合し、ユーザー要求への影響は依然として存在します。



さらに、サイトごとのパーティショニングを導入しました。これにより、これらすべての新しいタイプのコンテンツが必要とされないサイトのメモリが削減されました。たとえば、これにより、オンライン映画館はミュージックビデオや予告編をダウンロードせず、影響を減らすことができました。しかし同時に、すべてのコンテンツにアクセシビリティを提供する必要があるサイトの場合、もちろん何も変わっていません。



したがって、スキームの長所と短所は以前とほぼ同じままでした。しかし、パーティショニングにより、CPUとメモリの垂直スケーリングがサイトに移動し、これにより一部のサイトはスケーリングを継続できました。以前のコンテンツ公開スキームと比較して、これはまったく変更されていません。通常、同じ数十分の時間がかかったので、それを最適化する方法を探し続けました。







その時までに私たちは何を理解していましたか？そのオンラインシネマクエリは、DBMS機能のごく一部を使用します。クエリインタープリターとオプティマイザーは、時間の経過とともにエンティティキャッシュに縮退しました。アクセシビリティの定義は広く普遍的であることに気づきました。クエリは、コンテンツユニットまたはリストの可用性を理解し、この可用性に属性を追加する必要があるという点で異なります。一般に、これは本格的なDBMSなしで実行できます。



そして第二に、複合キーの一部は低い基本パラメータです。数十の国があり、数百、数十のサイトの制限があり、サブスクリプションはごくわずかです。ほとんどの場合、完全な非正規化は必要ありません。これらの両方の調査結果により、ユーザーの要求に迅速に対応しながら、よりコンパクトで非正規化されていないメモリ内表現に移行することができました。







スライドでは、可用性トランスフォーマーv1からv2への移行を示しています。これは、新しいアクセシビリティスキームの概略図です。ここでは、複合キーは実際にはコンテンツIDキーになります。そして、アクセス可能性は、物理的または論理的に、国、サイト、およびサブスクリプションのリストによって可用性を決定することになります。



したがって、メモリの大部分を占める目に見えない非キーの残りの量を減らし、同時にメモリの量を減らします。







ここでは、新しいアクセシビリティトランス回路に移行するプロセスを確認します。 Netflix Hollowは、基本エンティティのプロバイダーおよびインデクサーの役割を果たし、ドメインサービスは、さまざまなサイズの複合エンティティのアセンブリをその場で収集します。これが機能するのは、基になるエンティティがまだ非正規化されており、ビルド時に結合の数が最小限であるためです。一方、可用性の決定は単純で安価なサイクルに帰着し、難しいことではありません。



同時に、Netflix Hollowは、データの更新中とそれらへのアクセス中の両方で、CPUとガベージコレクションの負荷を保存し、かなり慎重に処理します。これにより、CPU使用率グラフに表示された丘を減らし、許容可能な最小値に保つことができます。さらに、スナップショットとそれらへの差分の形式でハイブリッド配信スキームを実装するため、新しいコンテンツの公開速度を最大数分まで向上させることができます。



以前のスキームの利点のほとんどが維持されていることは明らかです。メモリ内のデータを更新するメカニズムは、リソース使用率の点でよりシンプルで安価になっています。パーティションごと、サイトごとの垂直スケーリングも特定のエンティティのスケーリングで補完され、現在は安価になっています。また、Snapshotコピーの更新のオーバーヘッドを削減したため、CPU全体で真に水平方向のスケーリングが行われました。



このスキームの欠点は、エンティティの構成にサービス間呼び出しまたは個別のサービスが必要になることです。また、データが使用されるすべてのドメインサービスに保存されるようになったため、基本エンティティレベルでのデータの重複がまだあります。ただし、Netflix HollowはH2よりもコンパクトにデータを格納し、H2はオブジェクトを含むHashMapよりもはるかにコンパクトにデータを格納します。したがって、このマイナスも間違いなく許容できると見なされ、楽観的に未来に目を向けることができます。







このスライドは、水道水でも楽観的に充電することができます。新しい国へのスケーリングは、もはやメモリからの乗数ではなく、新しいサイトへのスケーリングでもないためです。パーティショニングにより、水平スケーリングに変換されます。



さて、新しいユーザーを拡大し、オンラインシネマの機能を拡張することは、負荷の増加に帰着します。それを提供するために、必要な数の軽量CPUバウンドサービスを立ち上げる準備ができています。一方で、私たちはアクセシビリティの分野で十分な知識を蓄積しており、自信を持って新しい挑戦を楽しみにしています。この知識の一部を皆さんと共有できたと思います。清聴ありがとうございました。