NetflixのTimeSeries Data Abstraction Layerの紹介

• NetflixはVoDやGamingなど多様な分野へ拡大する中で、大量の時系列データ（ペタバイト単位）をミリ秒単位のレイテンシで保存・処理する能力が重要になっている。
• Key-Value抽象化とData Gatewayプラットフォームを基盤にTimeSeries抽象化を開発し、多様なユースケースにわたって時間的イベントデータを効率的に保存・クエリできるソリューションを提供している。

課題

• Netflixでは、ユーザーインタラクション、アセット露出、複雑なマイクロサービスネットワークの活動などから継続的に時系列データが生成・利用されている。
• こうしたデータを効果的に管理し、ユーザー体験とシステム信頼性を確保することが重要である。
• 主な課題:
  • 高スループット: 1秒あたり最大1,000万件の書き込みを処理しつつ、高可用性を維持する必要がある。
  • 大規模データセットでの効率的なクエリ: ペタバイト級のデータを保存しながら、プライマリキー読み取り結果を低ミリ秒で返し、複数の補助属性による検索と集計をサポートする必要がある。
  • グローバルな読み書き: 世界中のどこからでも読み書き操作をサポートし、調整可能な一貫性モデルを提供する。
  • 調整可能な構成: シングルテナントまたはマルチテナントのデータストアでデータセットを分割できる機能を提供する。
  • バーストトラフィックへの対応: 新コンテンツ公開やリージョン障害復旧時に発生するトラフィック急増を管理する必要がある。
  • コスト効率: 長期保存を最適化しながら、インフラコストを最小化する必要がある。

TimeSeries抽象化

• データ分割: 独自の時間分割戦略とイベントバケット方式を用いて、バーストワークロードを効率的に処理し、クエリを簡素化する。
• 柔軟なストレージ: Apache CassandraやElasticsearchのようなさまざまなストレージバックエンドと統合できるよう設計されている。
• 構成可能性: 各データセットに対して多様な調整可能オプションを提供し、さまざまなユースケースに適応できる柔軟性を備える。
• 拡張性: 水平・垂直スケーリングをサポートし、Netflixのユーザーベースやサービスの拡大に伴う処理量とデータ量の増加に対応できる。
• シャードインフラ: Data Gateway Platformを活用し、必要なアクセス制御とトラフィック分離を通じて、シングルテナントおよび/またはマルチテナントのインフラをデプロイできる。

データモデル

• イベントデータをカプセル化し、効率的にクエリできる独自のイベントデータモデルに従う。
• イベントアイテム: イベントアイテムは、ユーザーが特定イベントのデータ保存に使うキー・バリューのペアである。例: {"device_type": "ios"}
• イベント: イベントは1つ以上のイベントアイテムから構成される構造化コレクションである。イベントは特定時点で発生し、クライアントが生成したタイムスタンプとイベント識別子（UUIDなど）で識別される。event_timeとevent_idの組み合わせは、イベントの一意な冪等キーの一部を形成し、ユーザーがリクエストを安全に再試行できるようにする。
• タイムシリーズID: time_series_idは、データセットの保存期間中に発生した1つ以上のイベントの集まりである。たとえば、device_idは保存期間中に特定デバイスで発生したすべてのイベントを保存する。すべてのイベントは不変であり、TimeSeriesサービスは与えられたタイムシリーズIDにイベントを追加するだけである。
• ネームスペース: ネームスペースはタイムシリーズIDとイベントデータの集合であり、TimeSeriesデータセット全体を表す。ユーザーは各ユースケースごとに1つ以上のネームスペースを作成できる。この抽象化はネームスペース単位でさまざまな調整可能オプションを適用する。

API

• WriteEventRecordsSync: このエンドポイントはイベントのバッチを書き込み、耐久性確認をクライアントへ返送する。ユーザーが耐久性保証を必要とする場合に利用される。
• WriteEventRecords: これは上記エンドポイントのfire-and-forget版である。耐久性確認なしでイベントバッチをキューに入れる。スループットをより重視し、多少のデータ損失を許容できるロギングやトレーシングのようなケースで利用される。
• ReadEventRecords: namespace、timeSeriesId、timeInterval、任意のeventFiltersの組み合わせが与えられると、このエンドポイントは一致するすべてのイベントをevent_timeの降順で、低ミリ秒レイテンシで返す。
• SearchEventRecords: 検索条件と時間間隔が与えられると、このエンドポイントは一致するすべてのイベントを返す。こうしたユースケースは結果整合性のある読み取りに適している。
• AggregateEventRecords: 検索条件と集計モード（例: DistinctAggregation）が与えられると、このエンドポイントは指定された時間間隔内で指定された集計を実行する。Searchエンドポイントと同様に、ユーザーは結果整合性と潜在的により高いレイテンシ（秒単位）を受け入れられる。

ストレージ層

• TimeSeriesのストレージ層は、基本データストアとオプションのインデックスデータストアで構成される。
• Apache Cassandraは、高スループットのシナリオで耐久性を保証するデータストアとして好まれる。
• Elasticsearchは、インデックス作成用のデータストアとして好まれる。

基本データストア

• Apache Cassandraを活用してTimeSeriesのユースケースを処理する。
• 時間間隔に応じてデータをチャンクへ分割するTemporal Partitioningでデータを管理する。
  • 時間スライス: 保存期間に対応するCassandraテーブルへマッピング
  • 時間バケット: 時間スライス内で、特定の時間範囲クエリを最適化するためにデータを再分割
  • イベントバケット: 短期間におけるタイムシリーズ大量書き込み処理のために時間バケットを再分割
• データテーブルは実際のイベントデータを保存し、メタデータテーブルはネームスペースごとの時間スライス構成情報を保存する。

インデックスデータストア

• 非プライマリキー属性による補助アクセスパターンをサポートするため、データをElasticsearchにインデックスする。
• ユーザーは検索・集計対象となる属性の一覧をネームスペースごとに構成できる。

コントロールプレーン

• データプレーンは読み書き操作を担い、コントロールプレーンはネームスペース動作のあらゆる側面を構成する。
• データプレーンはTimeSeries control stackと通信し、これはData Gateway control planeと相互作用する。
• ネームスペース構成により、さまざまな事項を柔軟に調整可能（例: 時間分割、バッファリング、一貫性、保持など）。

ネームスペース構成

• サービスの柔軟性を示す構成スニペットを通じて、ネームスペースごとにさまざまな項目を調整できる。

インフラプロビジョニング

• さまざまなパラメータを考慮し、自動化されたプロビジョニングワークフローを通じて最適な設定を導き出す。
• システムは初期インフラをプロビジョニングした後、ユーザーワークロードに応じて拡張する。

拡張性

• 初期プロビジョニング時は利用予測が限られるため、事後調整が必要となる。
• 水平スケーリング: TimeSeriesサーバーインスタンスはトラフィック需要に応じて自動的にスケールアウト/スケールインする。
• 垂直スケーリング: TimeSeriesサーバーインスタンスまたはストレージインスタンスを垂直に拡張し、より大きなCPU、RAM、そして/または接続ストレージ容量を得られる。
• ディスク拡張: EBSを接続してデータを保存でき、ディスクストレージが特定のしきい値に達するとEBSボリュームを拡張する。
• データの再分割により、過剰/過少分割されたデータセットを調整する。

設計原則

• イベント冪等性: すべての変更系エンドポイントに冪等性を組み込み、ユーザーがリクエストを安全に再試行できるようにする。
• SLOベースのヘッジング: さまざまなエンドポイントに対してサービスレベル目標（SLO）ターゲットを割り当て、性能を保証する。
• 部分返却: クライアントが遅延に敏感な場合、部分的な結果セットを受け入れられる。
• 適応型ページネーション: サービス層がタイムシリーズデータセットが高密度だと判断すると、fanout係数を動的に調整する。
• 制限付き書き込みウィンドウ: データをできるだけ早く不変状態にし、最適化を適用できるようにする。
• 書き込みバッファリング: バーストワークロードに対応するため、イベントを短時間マージして負荷を均等に分散する。
• 動的圧縮: データが不変状態になると、読み取り性能を最適化するため圧縮戦略を用いる。

実際の性能

• サービスは低ミリ秒でデータを記録でき、安定したポイントリードレイテンシを維持する。

NetflixにおけるTime Seriesの活用

TimeSeries抽象化はNetflixの主要サービス全体で重要な役割を果たしている。以下はいくつかの影響力あるユースケースである。

• トレーシングとインサイト: Netflix内のすべてのアプリとマイクロサービスでログトレースを実行し、サービス間通信を理解し、問題のデバッグを支援し、サポート問い合わせに回答する。
• ユーザーインタラクション追跡: 動画再生、検索、コンテンツエンゲージメントなど数百万件のユーザーインタラクションを追跡し、Netflixの推薦アルゴリズムをリアルタイムで改善し、全体的なユーザー体験を向上させるインサイトを提供する。
• 機能リリースと性能分析: 新しい製品機能のリリースと性能を追跡し、Netflixのエンジニアがユーザーの機能との相互作用を測定できるようにし、今後の改善に向けたデータ駆動の意思決定を支援する。
• アセットインプレッション追跡と最適化: アセット露出を追跡し、コンテンツとアセットが効率的に配信されるようにすると同時に、最適化のためのリアルタイムフィードバックを提供する。
• 請求とサブスクリプション管理: 請求およびサブスクリプション管理に関連する過去データを保存し、取引記録の正確性を確保し、カスタマーサービス問い合わせを支援する。

今後の改善点

ユースケースが進化し、この抽象化をさらにコスト効率の高いものにする必要性が高まるにつれて、今後数か月でサービスを大幅に改善する計画である。その一部は以下のとおり。

• コスト効率向上のための階層型ストレージ: 古くアクセス頻度の低いデータを、first byteまでの時間は長いが安価なオブジェクトストレージへ移すことをサポートし、Netflixに数百万ドル規模の節約をもたらす可能性がある。
• 動的イベントバケッティング: ネームスペースのプロビジョニング時に_やや_静的な構成を持たせる代わりに、イベントがストリーミングされる際にキーを最適サイズのパーティションへリアルタイム分割することをサポートする。この戦略には、パーティショニングが不要なtime_series_idをパーティショニング_しない_ことで、読み取り増幅の総コストを削減できる大きな利点がある。また、Cassandra 4.xでは広範なパーティション内のデータ部分集合を読む際に大きな改善があるため、事前にデータセット全体を積極的に分割する必要性が減る可能性がある。
• キャッシング: データの不変性を活用し、個々の時間範囲ごとにインテリジェントにキャッシュする。
• カウントおよびその他の集計: 一部のユーザーは、特定時間間隔に対するすべてのイベントデータを取得する代わりに、イベント数のみに関心を持つ。

結論

• TimeSeries AbstractionはNetflixのオンラインデータインフラにおける重要な構成要素であり、リアルタイムおよび長期的な意思決定を支えている。
• Netflixが新たな分野へ拡大するにつれて、TimeSeries Abstractionはプラットフォームの中核要素であり続け、ストリーミングとその先の可能性を広げることに貢献するだろう。

GN⁺の見解

• TimeSeries抽象化によって、拡張性、柔軟性、コスト効率を同時に確保し、膨大な量の時系列データを安定して処理できるNetflixのノウハウが印象的である。特に、時間ベースのパーティショニング、書き込みバッファリング、動的コンパクションなど、データ特性とアクセスパターンに最適化された手法が際立っている。
• 単なる時系列DBではなく、抽象化レイヤーを通じてCassandra、Elasticsearchなど多様なストレージを柔軟に活用し、ワークロード特性に合わせてインフラをプロビジョニング・運用できる制御体系を備えている点が効果的に見える。抽象化により、ユーザーは複雑さを隠蔽し、データに集中できる。
• 現在、ペタバイト規模のデータを収容しながら毎秒1,500万イベントを処理する性能を示しており、高性能な時系列データパイプラインを構築しようとする企業にとって模範となりうる。特に大規模サービスでは、データ量と速度だけでなくコスト面まで総合的に考慮すべきことを示唆している。
• トレーシング、ユーザー行動分析、請求管理などNetflix事業の中核領域で幅広く活用されており、時系列データがデータ駆動の意思決定とサービス革新の原動力であることが分かる。単なるロギングではなく、リアルタイム推薦などML/AIベースのサービスの基盤にもなっている。
• 今後、階層型ストレージ、動的パーティショニング、集計演算などの改善計画を通じて継続的に進化しようとする姿勢もうかがえる。急変するビジネス要件に対応するには、このような絶え間ない革新が必要だろう。その過程で蓄積されたノウハウがオープンソースなどを通じて共有されることにも期待したい。