How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEEは、放送テレビ、映画、ストリーミングメディア、音楽をカバーするインド最大のメディアおよびエンターテイメント事業です。ZEE5は、190カ国以上で利用可能なプレミアムOTTストリーミングサービスで、月間アクティブユーザーは約150Mです。そして、各ユーザーの再生体験、セキュリティ、および推奨は、1日あたり100B以上の心拍を処理する「ハートビットAPI」に依存しています。 システムの背後にあるエンジニアは、継続的なビジネス成長がインフラストラクチャ(データベースの請求書をレビューする人々と同様に)を強調することを知っていたので、チームは心臓発作を起こす前にシステムを再考することにしました。 彼らは、交換のための技術的要件(クラウド中立性、マルチレンタントの準備、新しい使用ケースのオンボードのシンプルさ、および最適なコストで高パフォーマンスと低遅延)およびそれがScyllaDBにどのように導いたかを概説しました。 まとめると、ScyllaDBを検討したり使用する誰にでも役に立つかもしれない学習を共有しました。 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true 以下は、その会話のいくつか・・・。 ハートビートって何? 「Heartbeat」とは、ZEE5 OTTプラットフォーム上でビデオ再生中に定期的に発射されるリクエストです。これらの単純なリクエストは、ユーザーが何を見ているか、各ビデオでどの程度進歩しているかを追跡します。それらはZEE5の「見続ける」機能に不可欠で、ユーザーは1つのデバイスでコンテンツを休止し、その後、任意のデバイスで再生することができます。 なぜ変わる? ZEE5のオリジナルのハートバットシステムは、それぞれストリーミング体験の特定の部分を扱う異なるデータベースのウェブであり、技術的に機能していたが、このアプローチは高価で、特定のベンダーのエコシステムに閉じ込められた。 彼らは、特定のクラウドプロバイダーにロックされていないシステムを欲しがり、運用コストが低くなり、一貫して高速なパフォーマンスで膨大な規模を処理できるようになった - 具体的には、1 桁のミリ秒応答です。さらに、新しい機能を簡単に追加する柔軟性と、システムを他のストリーミングプラットフォームに提供する能力を欲しかった。 システムアーキテクチャ: Before and After 以下は、複数のデータベースを搭載したオリジナルのシステムアーキテクチャをご覧ください。 DynamoDB は、基本的な心拍データを格納します。 Amazon RDS では、次のエピソードと以前のエピソードの情報を格納します。 Apache Solr が持続的なメタデータを保存する メタデータをキャッシュするためのOne Redis instance もう一つの Redis インスタンスで視聴率の詳細を格納 ZEE5チームは、このプロジェクトのための4つの主要なデータベースオプションを検討しました: Redis、Cassandra、Apache Ignite、およびScyllaDB. 評価とベンチマークの後、彼らはScyllaDBを選択しました。 ScyllaDB は、同じインフラストラクチャ内のキャッシュ レイヤーと persistent データベースの両方を管理し、地域間の遅延、複製、および複数のクラウドの準備を低くします。 ScyllaDB は、同じインフラストラクチャ内のキャッシュ レイヤーと persistent データベースの両方を管理し、地域間の遅延、複製、および複数のクラウドの準備を低くします。 新しいアーキテクチャは、以前のシステムアーキテクチャ構造を簡素化し、平らげます。 現在、すべてのハートビットイベントはハートビットテーマに押し込まれ、ストリーム処理を通じて処理され、ScyllaDB コネクタを使用して ScyllaDB クラウドに注入されます。 Srinivas氏は「この新しいアーキテクチャで、DynamoDB、RDS、Redis、SolrからScyllaDBへのワークロードを成功に移行しました。 ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. デザインに深く入る 次のJiveshは、彼らの低レベルのデザインについてもっと話しました... リアルタイムストリーム処理パイプライン リアルタイムストリーム処理パイプラインでは、心拍数が定期的にScyllaDBに送信されます。 心拍間隔は60秒に設定されているため、すべてのフロントエンドクライアントは、ユーザーがビデオを視聴している間、60秒ごとに心拍を送信します。これらの心拍は再生ストリーム処理システムを通過し、ビジネスロジックの消費者はそのデータを必要な形式に変換します - 処理されたデータはScyllaDBに保存されます。 スケーラブル API Layer スケーラブル API レイヤーの最初のコンポーネントは、ハートバット サービスで、大規模なデータ侵入を処理する責任があります。トピックはデータを処理し、接続サービスを通過し、ScyllaDB に保存されます。 もう一つの注目すべき API レイヤー サービスは Concurrent Viewership Count サービスです. このサービスは ScyllaDB を使用して、ユーザごとにまたは資産ごとに (たとえば ID ごとに) 同時視聴データを取得します。 メタデータ管理用例 ZEE5が直面した最初の大きな課題の1つは、彼らの巨大なOTTプラットフォームのメタデータの管理でした。最初、彼らは3つの異なるデータベース(Solr、Redis、Postgres)の組み合わせに頼って、彼らの膨大なメタデータのニーズに対処しました。最適化と簡素化を目指して、彼らはデータモデルを再設計し、代わりにScyllaDBと動作させました。 以下は彼らのメタデータモデルをご覧ください: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; このモデルでは、ID がパーティションキーとして機能するため、このテーブルは比較的少ない書き込み(新しい資産がリリースされたときにだけ書き込み)を経験しているが、大幅に多くの読み込みがあるため、彼らはレベルの縮小戦略を使用してパフォーマンスを最適化しました。 Viewership Count Use Case の検索結果 Viewership Count は ScyllaDB に移行したもう一つの使用例です. Viewership count はユーザーごとにまたはアセット ID ごとに追跡できます. ZEE5 は、ユーザー ID がパーティションキーとして機能し、アセット ID がソートキーとして機能するテーブルを設計することにしました。 ScyllaDB の TTL を 60 秒の心拍間隔と一致させるように設定し、指定された時間後にデータが自動的に終了することを保証しました。 Jivesh氏は「このテーブルは、すべてのフロントエンドとすべてのユーザーから心拍数で継続的に更新されています。心拍数が到着するにつれて、視聴数はリアルタイムで追跡され、TTLが終了したときに自動的にクリアされます。 以下は視聴者数データモデルです。 CREATE TABLE keyspace.USER_SESSION_STREAM ( USER_ID text, DEVICE_ID text, ASSET_ID text, TITLE text, …, PRIMARY KEY((USER_ID), ASSET_ID) ) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' }; ScyllaDB の結果とレッスン 下記のロードテストレポートは、1秒あたり41.7Kのリクエストのパフォーマンスを示しています. This benchmark was conducted during the database selection process to evaluate performance under high load. Jivesh氏は「このような高いパフォーマンスでさえ、マイクロ秒の書き込み遅延と平均マイクロ秒の読み込み遅延を達成することができました。 その後、彼はZEE5のScyllaDB展開の規模を明らかにするいくつかの事実を共有し続けた。 ScyllaDBには約9TBがありますが、このような大量のデータでさえ、マイクロ秒と1桁のミリ秒で遅延を処理することができ、これはかなり巨大です。 毎秒、私たちは ScyllaDB にたくさんのデータを書き込み、それからたくさんのデータを得ています。 私たちは1日で10億回以上の心拍を処理しています。 講演は以下の教訓で終わった。 データモデリングは、1 桁のミリ秒遅延を達成する最も重要な要因です。 適切なクォーラム設定と圧縮戦略を選択します. たとえば、読み取れる前に各ノードに心拍を書き込む必要がありますか、または地元のクォーラムが十分ですか? 適切なクォーラムを選択すると、遅延とSLA要件の最適なバランスが確保されます。 Partition and Clustering Keys を賢く選択してください - 後でそれらを変更することは容易ではありません。 素材化されたビューを使用して、検索をより速くし、フィルタ クエリを避けることができます。 効率を向上させるために準備された発言を使用します。 たとえば、メタデータモデルでは、20 つの同期クエリが並行して実行され、ScyllaDB はミリ秒以内にそれらを処理しました。 Zone-aware ScyllaDB クライアントは、クロス-AZ (Availability Zone) ネットワークコストを削減するのに役立ちます。
