Netflixがデータインフラのコストを効率化する方法

Netflixの分散したインフラ構造と「自由と責任」という社内文化のため、効率化はかなり難しい課題だった。そのため、コストの透明性を提供し、効率化に関するコンテキストを意思決定者の近くに置くために、カスタムダッシュボードを開発した。

この「データ効率性ダッシュボード」をどのように作ったのか、その学びについて。

• Netflixのデータプラットフォーム環境: 2つに分類可能

1. Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid

2. Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto

** 使用量とコストの可視性をひと目で **

すべてのプラットフォームのコストを集計するが、各コストを意味のある単位に分解できる情報を含めたまま集計する。

→ 単位: テーブル、インデックス、カラムファミリー、ジョブなど

このコスト情報のソースは基本的に、サービスおよびタグで分類したAWSの課金情報に依存しているが、これだけではリソース別/チーム別の区分ができないため、次のような方法を使った。

• EC2ベースのプラットフォーム

→ ボトルネックを引き起こすメトリクス(bottleneck metric)をプラットフォームごとに定義

→ たとえば Kafka はネットワークバウンドだが、Spark はCPUとメモリにバウンドされる。

→ Atlas とプラットフォームログ、Rest APIを活用して各リソースごとのメトリクスを区別し、コストを割り当てる

• S3ベースのプラットフォーム

→ 各リソースごとにS3 Prefixを付け、ストレージ価格基準でリソースごとのコストを計算

• Dashboard View

Apache Druidベースのカスタムダッシュボードを使って各コストをチームに割り当てる。

このコスト情報の主な顧客はエンジニアリングチームとデータチーム。彼らがその情報に基づいてアクションできるように提供する。

さらに、エンジニアリングリーダーには、より高いレベルで見られるように提供する。

ユースケースに応じて、データ資源単位または組織単位でグループ化して見ることができ、スナップショットおよび時系列でデータを見ることが可能

** 自動化されたストレージ推奨 - Time to Live (TTL) **

一部のシナリオでは、透明性の提供を超えて最適化の推奨事項も提供する。

データストレージは使用量も多く、コストのモメンタム（保存したまま忘れられてしまうような性質）も大きいため、

データ利用パターンに基づいて最適な保存期間(TTL)を決定する分析を自動化した。

S3のビッグデータウェアハウス向けテーブルに対してはTTL推奨を適用

• コスト計算とビジネスロジック

最大のS3コストはトランザクションテーブルで発生し、一般的に日付ごとにパーティショニングされている。

S3アクセスログとS3 prefix-to-table-partitionマッピングを使って、アクセスされる日付パーティションを判断できる。

過去180日間のアクセス（読み取り/書き込み）活動を見て、最大Lookback（日数）を確認する。

このLookback日数によって、そのテーブルのTTL値が決まる。

この計算されたTTLに基づいて、実現可能な年間削減額を計算する。

• Dashboard View

データオーナーは詳細なデータアクセスパターンを見ることができ、TTLの推奨値と現在値を比較し、可能なコスト削減額も確認できる。

** コミュニケーションとユーザーへの通知 **

データコストの確認は、技術チームの日常業務であってはならない。特に意味のないデータコストであればなおさらだ。

そこで、データコストへの認識を高められるよう、データ使用量が多いチームにのみメールのプッシュ通知を行う機能を開発した。

また、コスト削減の可能性があるテーブルに対してのみ、自動でTTL推奨値を送る。

現在、このメールは毎月送信されている

** 学びと課題 **

1. 各資産のメタデータを識別し維持することは、コスト配分において重要である。

→ そのために Netflix Data Catalog (NDC) というメタデータリポジトリを構築

→ データへのアクセスと検索が容易になり、既存データでも新規データでも管理可能

→ NDC をコスト計算の出発点として活用

2. 時系列トレンドデータは難しい。

→ トレンドデータはスナップショットより管理負荷がはるかに大きい

→ データ不整合や処理待ち時間のため、一貫したビューを提供するのは難しい

→ 2つの課題を解決する必要があった

• リソースの所有権変更: スナップショットは自動的に所有権変更が反映される必要があり、時系列ビューでは変更履歴自体もメタデータに反映する必要がある

• データ問題発生時の状態損失: リソースのメタデータはAPIを通じてさまざまなソースから抽出されるため、収集中に失敗すると状態が失われる。こうしたデータは一時的なものなので、API抽出だけでは限界がある。Keystone側へデータをポンピングするような代替策を探す必要がある

** 結論 **

高度に分散したデータプラットフォームがあるなら、このようなダッシュボードでフィードバックループを作り、利用量とコストのコンテキストを統合することで、効率性を大きく向上できる。

可能であれば、自動化された推奨によって効率を高めるべきだ。

Netflixの場合、データ保持期間の推奨が高いROIを示した。

このダッシュボードとTTL推奨によって、データウェアハウス全体の保存容量を10%以上削減できた。

[kunggom]

レコメンド機能は視聴者だけのためのものではなかったようです。

[heycalmdown]

いいですね。リアルタイムのモニタリング装置を見ることができれば不随意筋も動かせる、という研究をどこかで見たのを急に思い出しました。