AI News HubLIVE
サイト内リライト3 分で読了

Netflix AIチーム、CassandraパーティションをIDごとに分割し、ワイドパーティションの読み取りレイテンシを秒からミリ秒に短縮

Netflixのエンジニアは、TimeSeries AbstractionにおけるApache Cassandraのワイドパーティションの処理方法を詳しく説明しました。2つのアプローチが連携します。Time Slice再パーティショニングはテーブルレベルで将来のパーティションを調整し、動的パーティショニングは読み取りパスでTimeSeries IDごとに過大なパーティションを検出して分割します。検出はバイトカウントとKafkaを介して実行され、分割はチェックサムで検証され、ブルームフィルタが読み取りを並列子パーティションにルーティングします。平均読み取りレイテンシは秒から低二桁ミリ秒に低下し、500MB以上のパーティションも利用可能なままです。

ソースMarkTechPost著者: Asif Razzaq

Netflixのエンジニアリングチームは、Apache Cassandraにおけるワイドパーティションの処理方法を公開しました。この研究は、時系列イベントデータのプラットフォームであるNetflixのTimeSeries Abstractionを対象としています。

TimeSeries Abstractionは、ペタバイト規模の時系列イベントデータをミリ秒のレイテンシで取り込み、クエリします。基盤としてApache Cassandra 4.xを使用しています。時系列データは、識別子と時間範囲によってイベントをグループ化するパーティションに編成されます。イベントが蓄積されるにつれて、これらのパーティションは「ワイド」になる可能性があります。動的再パーティショニングは、過大なパーティションを非同期に小さな子パーティションに分割します。アプリケーションは同じ論理パーティションにクエリを続け、ストレージレイアウトは透過的に進化します。

ほとんどのデータセットでは、平均読み取りレイテンシは1桁ミリ秒にとどまります。しかし、パーティションが広くなりすぎると、テール読み取りレイテンシが秒単位に上昇し、読み取りタイムアウト、ガベージコレクションの一時停止、高いCPU使用率、スレッドキューイングを引き起こす可能性があります。TimeSeriesサーバーは非常に高い読み取りスループットも処理するため、問題がさらに悪化します。Netflixチームは、単にクラスターを拡張するよりもスマートな代替案を求めていました。

TimeSeriesは、データセットを離散的な時間チャンク(Time Slice、時間バケット、イベントバケット)に分割します。名前空間(データセット)が作成されるとき、ユーザーは予想されるワークロード特性を指定し、プロビジョニングパイプラインはモンテカルロシミュレーションを実行してインフラストラクチャとパーティション構成を選択します。この事前のアプローチは、次の3つの状況で不十分です。ワークロードが不明または不正確に見積もられている場合、ワークロードが時間とともに変化する場合、および一部のIDがはるかに多くのイベントを受信するデータ外れ値が存在する場合。離散Time Sliceは最初の2つのケースに自然な逃げ道を提供しますが、数千のデータセットを手動で調整することは持続可能ではないため、自動化が必要です。

解決策1:Time Slice再パーティショニング。Cassandraはnodetool tablehistogramsなどのイントロスペクションAPIを公開しています。バックグラウンドワーカーはこれらのヒストグラムを監視し、パーティションサイズが設定された密度(通常2〜10 MiB)から外れた場合に調整係数を計算します。たとえば、過剰なパーティショニングが高い読み取り増幅を引き起こした場合、ワーカーは将来のTime Sliceをより広い間隔で更新します。これにより、読み取りレイテンシとタイムアウトが減少しますが、テーブルの大部分が再パーティショニングを必要とする場合にのみ有効です。一部のIDのみがワイドである場合には役立ちません。

解決策2:IDごとの動的パーティショニング。これは、TimeSeries IDごとにワイドパーティションを分割する非同期パイプラインです。検出、計画と分割、読み取りサービスの3つの段階があります。検出は読み取りパスで行われ、各読み取りはパーティションの読み取りバイト数を追跡します。しきい値を超えると、サーバーはKafkaにイベントを送信します。最初の実装では不変パーティションを対象とします。計画段階では、パーティション全体を読み取って正確な分割計画を計算し、チェックポイントをサポートします。分割はイベントバケットパーティション分割戦略を使用し、より多くのイベントバケットを同じタイムバケットに割り当てます。検証は分割前後のチェックサムを比較し、一致した場合にのみ分割が完了とマークされます。

読み取りパスでは、ブルームフィルタを使用して分割されたパーティションキーをマイクロ秒でチェックし、ヒットした場合はルーティングメタデータを読み取ってリクエストを小さな子パーティションにルーティングします。元のワイドパーティションは削除されず、安全なフォールバックを提供します。NetflixはData Bridge Sparkジョブを使用したオフライン検証も行いました。段階的なロールアウトにより、シャドウ比較フェーズを含むさまざまな読み取りモードを経て信頼性を高めました。

2つのソリューションの比較:粒度、トリガー、影響範囲、コアメカニズム、検出信号、最適なユースケースが異なります。ユースケースの例には、長期ユーザーアクティビティログ、デバイステレメトリ、過剰プロビジョニングされた新しいデータセット、レイテンシセンシティブなダッシュボードが含まれます。

結果:ワイドパーティションの平均読み取りレイテンシは秒から低二桁ミリ秒に低下し、テールレイテンシは数秒から約200ミリ秒以下に改善されました。読み取りタイムアウトが減少し、CPU使用率が低下し、クラスターの安定性が向上しました。500MB以上の極端なワイド行でも、サービスはページネーションとクエリを実行可能で、可用性を維持できました。将来の作業には、可変ワイドパーティションの分割と、以前に失敗した分割の再処理が含まれます。