Netflixのエンジニアは、Apache Cassandra向けの動的パーティション分割メカニズムを詳述しました。これにより、 oversized な時系列パーティションの読み取りレイテンシを秒単位から低2桁ミリ秒に短縮し、読み取りタイムアウト、CPU使用率、スレッドキューイングを本番クラスター全体で低減しました。NetflixのTimeSeries Abstractionプラットフォーム向けに開発されたこのアプローチは、アプリケーションの変更、ダウンタイム、大規模な再パーティショニング作業を必要とせずに、成長するパーティションを自動的に小さな子パーティションに分割します。

このシステムは、Cassandraベースの時系列ワークロードにおける長年の課題に対処します。継続的に成長するパーティションは、読み取りレイテンシの増加、コンパクションのオーバーヘッド、メモリプレッシャー、および不均一な負荷分散を引き起こし、パフォーマンスを低下させる可能性があります。Netflixは、500 MBを超えるパーティションを管理するサービスで、以前は可用性の問題が発生していましたが、この機能の導入後、データのパaginationとクエリを継続しながら運用を維持できたと報告しています。

Cassandraの時系列データは通常、識別子と時間範囲でイベントをグループ化するパーティションに整理されます。初期のパーティションサイズの前提は、システムが最初にデプロイされた時点では有効である場合がありますが、トラフィックパターンの変化、保持ポリシー、および不均一なデータ成長により、一部のパーティションが予想よりも大幅に大きくなる可能性があります。Netflixによると、これらの問題に対処するには従来、スキーマの再設計、再パーティショニング作業、またはアプリケーションの変更が必要で、これらは大規模ではコストと運用面で混乱を招く可能性があります。

これらの課題に対処するため、Netflixは自動化されたパーティション進化フレームワークを構築しました。これにより、 oversized パーティションを検出し、事前定義されたしきい値を超えた時点で非同期に分割します。このシステムはパーティション境界と分割履歴を記述するメタデータを維持し、基盤となるストレージレイアウトが透過的に進化する間、アプリケーションが同じ論理パーティションをクエリし続けられるようにします。

Dynamic Wide Partition Split Async Pipeline (出典: Netflix Blog Post)

このアーキテクチャは、親パーティションと子パーティションの関係を追跡するメタデータレイヤーを導入します。読み取り時には、メタデータサービスが要求されたデータを含む子パーティションを判断し、それに応じてクエリをルーティングします。複数のパーティションから取得した結果は、クライアントに返される前にマージされます。Netflixは、このアプローチにより、サービスのダウンタイムやアプリケーションインターフェースの変更を必要とせずにデータ再配布が可能になると述べています。

運用上の安全性は主要な設計上の考慮事項でした。分散システムにおけるパーティション分割は、同時書き込み、データ移動、一貫性保証に関連する課題をもたらします。複雑さとデプロイリスクを低減するため、初期実装は不変パーティションに焦点を当てました。元のパーティションは移行プロセス全体を通じて保持され、データ再配布中に問題が発生した場合のフォールバックメカニズムを提供します。

Netflixはまた、パーティション進化中の正確性を検証するための検証メカニズムを組み込みました。既存の検証パイプラインを使用して、元のパーティションから返された結果と新しい読み取りパスを通じて生成された結果を比較しました。エンジニアは段階的なロールアウトを実施し、2つのアプローチ間の整合性を確認した後でのみ、本番トラフィックを徐々に増加させました。

Netflixによると、影響を受けたパーティションの平均読み取りレイテンシは、デプロイ後に秒単位から低2桁ミリ秒に低下しました。テールレイテンシは数秒から約200ミリ秒以下に短縮されました。また、同社はCassandraクラスター全体で読み取りタイムアウトの減少、CPU使用率の低下、およびスレッドキューイングの最小化を報告しました。

Phased Read Rollout and Validation Process (出典: Netflix Blog Post)

Netflixは、今後の作業として、mutable wide partitionsのサポートと、以前に失敗したパーティション分割の再処理メカニズムを含むと述べました。デプロイを振り返り、エンジニアリングチームは、複雑なアーキテクチャ変更の適用範囲を縮小し、段階的に検証することが、本番システムへの機能導入時に価値があると指摘しました。

About the Author

Leela Kumili