Netflix TechBlog | Medium 日本語 フォロー Netflix Tech Blogは、Netflixが技術をどのように扱うかを明らかにします。彼らは、データーサイエンス、エンジニアリング、デザイン、技術イノベーションに関する研究を提供します。彼らは、自社のコンテンツ配信ネットワークやサービス信頼性向上の努力など、イノベーションを披露し、洞察を提供します。 Netflix TechBlog - Medium netflixtechblog.com RSS netflixtechblog.com Netflix TechBlog | Medium 日本語 RSS thenote.app
MAPS: Netflixのマルチモーダルアセットのパーソナライゼーションを大規模に Netflixは、アートワークやビデオプレビューのようなパーソナライズされたビジュアルアセットを通じて、メンバーが愛するコンテンツと繋がることを目指しています。新しいタイトルが登場する際、十分なインタラクションデータがないために効果的なパーソナライゼーションができないという大きな課題が生じます。これはコールドスタート問題として知られています。従来、モデルはアセットを不透明なIDとして扱い、十分なデータが蓄積されるまで人気度ヒューリスティックに依存していました。これは、新しいコンテンツのパーソナライゼーションが遅れ、発見体験に影響を与えることを意味していました。Netflixの解決策は、マルチモーダル埋め込みを使用して、モデルがアセットを「見て」「聞く」ことを可能にすることです。事前学習済みの画像テキストモデルであるCLIPでアートワークをエンコードすることにより、アセットは視覚的な理解を獲得します。このCLIP埋め込みは、アセットのID埋め込みと連結され、視覚的なテーマや才能を捉えたより豊かな表現を作成します。これにより、アセットがインタラクション履歴を持つ前でも、メンバーの視覚スタイルへの好みに基づいたパーソナライゼーションが可能になり、タイトル間の知識転送を促進します。このアプローチは、異なるアートワークキャンバス用の個別のモデルを単一の統合モデルにマージするモデル統合も可能にします。CLIP埋め込みはクロッピングやリサイズに対してほとんど不変であるため、ほぼ同一のアートワークレンダリングは類似のベクトルにマッピングされます。特にデータ量の少ないキャンバスに利益をもたらす、キャンバス全体でのインタラクション信号のこのプーリングにより、単一のモデルがすべてのアートワーク配置をパーソナライズできます。キャンバス間のデータ不均衡に対処するために、印象数ではなく長期的な価値に基づいたインタラクションを優先する、報酬ベースの重み付けが使用されます。このアプローチの有効性は、逆確率重み付けスコアリングを使用したオフライン評価と大規模なA/Bテストによって検証されました。画像埋め込みと統合モデル（V3）を組み合わせたものは、これらの改善のいずれかのみを持つモデルを大幅に上回りました。この組み合わせアプローチは、最小限の履歴データを持つ主要なキャンバスが導入された、Netflixのホーム画面の大規模な再設計中に重要であることが証明されました。CLIP埋め込みを備えた統合モデルは、この新しいレイアウトのコンテンツを正常にパーソナライズし、発見指標とストリーミング時間の統計的に有意な増加を示し、コールドスタート問題を克服するためのマルチモーダル埋め込みの力を強調しました。 MAPS: Netflix’s Multimodal Asset Personalization at Scale netflixtechblog.com +1
二つのFlinkオートスケーラーの物語 Netflixは現在、2つのFlinkオートスケーラーを実行しており、1つのオープンソースソリューションに統合することを目指しています。当初、数千のFlinkジョブを管理するために社内オートスケーラーを構築しましたが、これは効果的でしたが、複雑なマルチオペレーターのジョブを処理する能力には限界がありました。この自社開発システムは外部メトリクスに依存しており、不正確であったり、内部ジョブの問題を見逃したりする可能性がありました。その後、Apache Flinkコミュニティは、ジョブ自体の中から推論する、より洗練されたオートスケーラーを開発しました。この2番目のオートスケーラーは、オペレーターの真の処理レートを推定して、頂点ごとの最適な並列度を決定します。Netflixは、ステートフルジョブをスケーリングし、詳細な設定を可能にする能力から、このオープンソースソリューションに収束しています。NetflixでOSSオートスケーラーを実装するには、既存のコントロールプレーンへの統合を含む、大幅な適応が必要でした。また、メトリクス収集の改善や、フォワード接続されたサブグラフやシンクの制限のような特定のジョブ構造を処理するために、Flinkのランタイムに変更を加えました。OSSオートスケーラーを採用することにより、Netflixは大幅なコスト削減とリソース利用率の向上を達成しました。学んだ教訓は、メトリクスの品質が重要であること、チューニング可能なデフォルト値が有益であること、そして既存のソリューションを拡張する前に採用することが賢明な戦略であることを強調しています。彼らは、運用を合理化するために、OSSベースのオートスケーラーへの完全な移行を計画しています。 A Tale of Two Flink Autoscalers netflixtechblog.com +1
Netflixがリアルタイム分散グラフを構築した方法と理由：パート3 — gRPCによるグラフのクエリ… Netflixは、社内パートナー向けのリアルタイムインサイトを強化するためにリアルタイム分散グラフを構築しました。このブログシリーズの第3部では、グラフを効率的にクエリする方法に焦点を当てています。グラフは数十億ものノードとエッジからなる複雑なネットワークであり、そのクエリには高速で柔軟なサービングレイヤーが必要です。著者は、幅広いアクセスパターンを処理し、シャローワイドクエリとディープナロウクエリの両方をサポートすることを含む、グラフのクエリにおける課題について論じています。彼らは、レイテンシを最小限に抑えるために幅優先アプローチと非同期コンポジションを使用して、グラフを効率的にクエリするためのサービングレイヤーをどのように設計したかを説明しています。著者はまた、クエリレイヤーの設計におけるキャッシング、オプトインエンリッチメント、および結果整合性の重要性についても論じています。クエリレイヤーは、グラフクエリサービス、ストレージ抽象化レイヤー、エンリッチメントレイヤーの3つのレイヤーで構成されており、これらが連携してクエリを効率的に実行します。著者は、クエリレイヤーが実際にどのように機能するかを示すためにクエリ例を説明し、リクエストの読み取りと解釈、ストレージからの効率的な読み取り、幅優先レベルでのトラバーサルの実行、多くの操作の並列実行、スマートなフィルタリング、およびキャッシングによる繰り返しクエリの高速化の重要性を強調しています。クエリレイヤーの目標は、100ミリ秒未満でクエリを完了することであり、著者はその設計がこの目標をどのように達成するかを示しています。クエリレイヤーは、それぞれが異なる可能性のある毎秒数万件のクエリを処理するように設計されており、著者はこのレベルのパフォーマンスを達成するためにクエリレイヤーを設計する際に彼らが行ったトレードオフについて論じています。全体として、著者は、大規模分散グラフのための高性能クエリレイヤーの構築に伴う課題とトレードオフを強調しながら、クエリレイヤーの設計と実装の詳細な概要を提供しています。クエリレイヤーはリアルタイム分散グラフの重要なコンポーネントであり、著者の設計と実装により、Netflixは社内パートナー向けのリアルタイムインサイトを強化することができました。 How and Why Netflix Built a Real-Time Distributed Graph: Part 3 — Querying the graph with gRPC… netflixtechblog.com +1
分析のためのデバイス機能のモデリング Netflixは、様々なデバイスで幅広い機能とコンテンツタイプを提供していますが、ハードウェアの制限により特定のデバイスでは一部の機能が制限される場合があります。この問題に対処するため、同社はデバイスの能力を理解し、最高のユーザーエクスペリエンスを確保するための包括的なデバイス能力データモデルを開発しました。このデータモデルは、内部システムからのフィーチャーフラグを統合し、グローバルなデバイス環境全体でよりスマートな機能管理を可能にします。デバイスの画面解像度、ビデオプロファイル、RAMサイズなどのデバイス能力に関する情報は、分析とレポート作成に最適な累積テーブルに保存されます。このテーブルは、各デバイスの最新の状態とその関連する能力を捉えるように構造化されており、効率的な情報処理を可能にします。集計分析のためには、過去28日間のアクティブデバイス数をデバイスモデルとソフトウェアバージョン別に捉えるヒストグラムテーブルが使用されます。このテーブルは、特定の能力をサポートするデバイス数も記録し、詳細な分布分析を可能にします。ヒストグラムデータは、HDまたはUHDプロファイルをサポートするデバイスの割合など、外部ディスプレイ能力の分布を分析するために使用できます。これらのデータセットを活用することで、Netflixは4K Ultra HD、Netflix Spatial Audio、Cloud Gamingを含む機能のリーチを包括的に把握するための分析製品を構築しました。同社は、パフォーマンスと信頼性の両方を確保するために、特定のデバイスでどの機能を有効にするかについて、データに基づいた洞察を使用して情報に基づいた意思決定を行っています。 Modeling Device Capabilities for Analytics netflixtechblog.com +1
GenRec:NetflixでのLLMネイティブ推薦に向けて レコメンデーションはNetflixの体験において重要な部分であり、同社は数千もの手作業で作成された特徴量と特殊なアーキテクチャに依存する複雑なプロダクションモデルを使用してきました。しかし、これらのモデルは維持・更新にコストがかかり、同社はより効率的で効果的なソリューションを探しています。大規模言語モデルはこの分野で有望視されていますが、まだプロダクションレディではなく、人気コンテンツを過剰に推奨したり、ビジネス上の制約を無視したりするなどの制限がしばしばあります。これに対処するため、NetflixはGenRecを構築しました。これは、Netflix固有のデータと目標に基づいて内部の基盤LLMを後学習させるLLMバックのレコメンデーションランカーです。GenRecは、ユーザー履歴、アイテムメタデータ、コンテキストをテキストとして言語化し、カタログを意識したスコアリングヘッドを使用してアイテムをランク付けします。このモデルは、ランキング、言語、報酬シグナルを組み合わせたマルチオブジェクティブロスでトレーニングされ、ビジネス目標と長期的なメンバー満足度と整合させます。GenRecは、調整済みのプロダクションランカーと比較して、短期および長期のオンラインメトリクスで統計的に有意な改善を示しており、ラベル付きデータと入力シグナルのごく一部しか使用していません。このモデルは、vLLMを使用してNetflixの内部LLMスタックで提供されており、同社は、より小さなモデルの使用、積極的なコンテキスト圧縮、プリフィルのみの推論などのサービングコストを制御するための戦略を実装しています。全体として、GenRecはNetflixにおけるレコメンデーションのよりLLM中心の未来に向けた重要な一歩を表しており、その成功は同社がレコメンデーションとパーソナライゼーションに取り組む方法を変革する可能性があります。自然言語入力から学習し、パーソナライズされたランキングを生成するモデルの能力は、ユーザーエクスペリエンスを向上させ、エンゲージメントを高める可能性があります。大規模言語モデルの力を活用することで、Netflixはビジネスの成功を推進する、より効果的で効率的なレコメンデーションシステムを作成できます。 GenRec: Towards LLM-Native Recommendation at Netflix netflixtechblog.com +1
Netflixでの社内LLMサービス Netflixは、大規模言語モデルスタック全体を社内で実行し、デプロイメントと推論を直接管理しています。これは、既存のプロダクション環境に統合されており、独立した機械学習サイロではありません。このアプローチには、推論エンジンの慎重な選択、モデルのパッケージ化方法の決定、APIサーフェスの設計、デプロイメント戦略の定義、および出力制約の施行が含まれます。選択された推論エンジンはvLLMであり、その運用上の適合性、カスタムアーキテクチャのロード能力、拡張性、デバッグ可能性、および実務家間の馴染みやすさから選ばれました。モデルはTritonのvLLMバックエンドを使用してパッケージ化され、動的なI/Oテンソル指定を可能にし、モデルとフロントエンドの独立した進化を促進します。より広範なエコシステムとの互換性のために、既存のgRPCインターフェースに加えて、OpenAI互換のHTTPフロントエンドが追加されました。デプロイメントにおいて、Netflixはモデルバージョン間のスキーマ変更の可能性に対応するためにバージョン管理戦略を使用しており、コンシューマーが独立して更新できるようにしています。モデルインターフェースが安定している場合は、コストの低いレッドブラックデプロイメント戦略が採用されます。運用上の重要な課題の1つは、モデルの起動時間の遅さであり、Amazon FSx上に大規模モデルをマテリアライズすることで、より高速なアクセスを実現しました。vLLMとTritonの両方からのデータを集約する統一された/metricsエンドポイントを作成することで、オブザーバビリティが向上しました。重要な機能は、vLLMのカスタムロジットプロセッサを介して実装された、大規模な制約付きデコーディングです。これにより、モデルは推論後の修正を回避し、コンプライアンスに準拠した出力を直接生成できます。制約付きデコーディングの初期の純粋なPython実装は、グローバルインタープリタロック（GIL）とCPU上での逐次処理により、スケーリングに苦労しました。これは高同時実行下でのみ明らかになり、大幅なテールレイテンシーを引き起こしました。システムは、デプロイメント、バージョン管理、およびオートスケーリングの管理のためにJavaコントロールプレーンに依存しています。リアルタイムおよびキャッシュされたバッチ推論パスの両方が、サービングシステムによってサポートされています。この統一されたシステムは、ルーティング、候補生成、およびロギングを含む、完全なダウンストリームコンシューマーフローを処理します。 In-House LLM Serving at Netflix netflixtechblog.com +1
Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned Netflix は、エンジニアが分散アーキテクチャのトラブルシューティングと理解を支援するために、リアルタイムのサービス依存関係マップを開発しました。このシステムは、eBPF ネットワークフロー、IPC メトリクス、および分散トレーシングを独立したグラフレイヤーに組み合わせています。初期バージョンはローカルで動作しましたが、本番環境では Kafka コンシューマーラグやメモリの問題など、重大なスケーリングの課題が明らかになりました。コアアーキテクチャの決定は、ストリーミングファーストのアプローチであり、毎時のバッチ処理ではなく、ほぼリアルタイムのトポロジー更新を提供しました。これは、インシデント対応とライブイベント監視にとって非常に重要でした。毎秒数百万件のフローレコードをデータ損失なしで処理するために、システムはバックプレッシャーを備えたリアクティブストリームを採用しており、ダウンストリームシステムが過負荷になった場合にアップストリームコンポーネントに減速をシグナルします。これにより、クラッシュやデータ損失ではなく、正常な劣化が保証されます。アーキテクチャは、ネットワーク、IPC、およびトレーシングレイヤーの物理ストレージ分離を備えたマルチレイヤー設計を使用しており、独立した最適化を可能にします。ネットワークレイヤーの取り込みは、3段階の分散集計パイプラインに依存しています。ステージ 1 は Kafka からの初期集計を実行し、ステージ 2 はネットワーク中間体（ロードバランサーなど）を直接アプリケーションレベルの依存関係に解決し、ステージ 3 は最終集計、外部データによるエンリッチメント、およびグラフデータベースへの永続化を処理します。この3段階パイプラインは、中間体の解決とエンリッチメント中のデータ集中による「ホットノード」に悩まされていた初期の2段階設計からの重要な進化でした。これらの責任を3つのステージに分割することで、ワークロードが分散され、ボトルネックが防止されます。Server-Sent Events (SSE) は、gRPC のパフォーマンスオーバーヘッドにより、ステージ間通信のために gRPC に取って代わりました。このオーバーヘッドは、スケール時に過剰な CPU とメモリを消費していました。 Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned netflixtechblog.com +1
GenPage: Netflixにおけるエンドツーエンドのジェネレーティブホームページ構築に向けて Netflixのホームページは、コンテンツ発見のための高度にパーソナライズされ、構造化されたインターフェースです。従来、その生成は複雑な多段階パイプラインを伴っていました。GenPageは、新しいアプローチであり、単一の生成トランスフォーマーモデルを使用して、ホームページ全体を自己回帰的に構築します。このエンドツーエンドモデルは、ユーザーコンテキストをプロンプトとして受け取り、行、エンティティ、レイアウトを同時に生成します。主な目標には、レコメンデーションスタックの簡素化、強化学習によるページ全体の最適化の実現、スケーラビリティと柔軟性の向上などが含まれます。本番環境での課題には、リアルタイムサービングレイテンシ、エンティティのコールドスタート、モデルの鮮度維持が含まれていました。GenPageは、A/Bテストにおいてユーザーエンゲージメントの大幅な向上とサービングレイテンシの削減を示しました。データは、ユーザー情報を表すコンテキストトークンと、ホームページ構造のページトークンにトークン化されます。ドメイン固有のトークン化は、汎用的なテキストトークン化と比較して、計算効率とプロダクトコントロールを向上させます。ユーザー履歴、プロフィール、リクエストコンテキストがプロンプトを形成し、エンティティと行は生成されたページのトークンとして表されます。システムは、ユーザーフィードバックに基づいた報酬システムを使用して、レコメンデーションの価値を定量化し、トレーニングをガイドします。GenPageは、標準的なデコーダーオンリートランスフォーマーアーキテクチャを採用し、LLMライクなトレーニングレシピである事前トレーニングと事後トレーニングに従います。事前トレーニングでは、次のトークン予測を使用してモデルにホームページの言語を教え、その後、重み付きバイナリ分類または強化学習による事後トレーニングを行います。この生成アプローチは、Netflixホームページ全体の体験を最適化するための、より統合された直接的なパスを提供します。 GenPage: Towards End-to-End Generative Homepage Construction at Netflix netflixtechblog.com +1
Netflixにおけるより制御可能なAIビデオ編集に向けた初期の研究探求 Netflixの研究者は、ビデオ編集者がプロモーションアセットを作成するのを支援するために、2つのAIツールを開発しました。最初のツールであるVeraは、コンテンツを維持した編集のために設計されたレイヤードビデオ拡散モデルです。Veraは編集を個別のレイヤーとして生成し、元の映像の変更されていない部分をそのままにして、アイデンティティと詳細を維持します。Veraをトレーニングするために、彼らは特殊なデータセットを作成し、効率的な出力生成のためにMixture-of-Transformersアーキテクチャを採用しました。評価により、Veraはコンテンツ維持において既存の方法を大幅に上回り、同等のビデオ品質であることが示されました。2番目のツールであるVOIDは、ビデオオブジェクトとインタラクションの削除フレームワークです。VOIDは、大きなインタラクションを持つオブジェクトを削除する際に、物理的にありえない結果が生じるという課題に対処します。これは2パス推論パイプラインを使用しており、最初のパスで物理的にありえる反事実的なビデオを生成します。2番目のパスで出力を洗練し、オブジェクトの変形のようなアーティファクトを防ぎます。VOIDは、シミュレーションから生成された合成データと実際のモーションキャプチャデータを使用してトレーニングされました。実験によると、VOIDは以前のアプローチと比較して、一貫したシーンダイナミクスをより良く維持することが示されています。これらの研究は、アーティストに力を与えながら、AIビデオ編集を責任を持って進歩させることを目指しています。VeraとVOIDの両方は、公開された研究論文で詳細に説明されています。 Toward More Controllable AI Video Editing: An Early Research Exploration at Netflix netflixtechblog.com +1
NetflixがKueueを活用してバッチ処理をいかに簡素化したか Netflixは、コンピューティングインフラをKubernetesネイティブモデルへと移行しており、KueueなどのコンポーネントをTitusプラットフォームに統合しています。クラウドネイティブなジョブキューイングシステムであるKueueは、自社開発のバッチソリューション「Compute Managed Batch（CMB）」の独自ロジックをほぼ置き換えました。 この移行の動機としては、CMBの老朽化、Kubernetesの進化、そして既存システムにプリエンプションなどの機能を追加することがますます困難になってきたことが挙げられます。Kueueが他の候補よりも選ばれた理由は、既存のTitusスケジューリングプロファイルとの互換性、導入の勢い、そしてプリエンプションなどの機能をネイティブにサポートしている点にあります。「Netflix Batch」として知られるこの移行では、ユーザーへの影響をゼロにし、スループットを低下させないことを目標とした。このプロセスでは、ジョブの送信先をKueue対応のTitusセルに再ルーティングし、ジョブの分散はTitusフェデレーションが処理した。 オペレーターによる調整は最小限で、主にテナントをKueueに登録するためのシンプルなUIトグルの切り替えのみでした。この登録により、CMBの既存のテナント階層およびキャパシティ設定が、Kueueの「コホート（Cohorts）」「クラスターキュー（ClusterQueues）」「ローカルキュー（LocalQueues）」という概念に変換されます。得られた主な教訓としては、スムーズなユーザー体験を確保するために旧システムとのAPI互換性を維持すること、および信頼性を確立するために複雑なユースケースを早期に移行することが挙げられます。また、KueueがNetflixの高いスループット要件に対応できることを確認するために負荷テストを実施し、デフォルト設定の調整が必要だった点も重要でした。 現在、Kueueは完全に稼働しており、数百万件のバッチワークロードを管理するとともに、フェアシェアリングおよびプリエンプション機能の強化を実現しています。これらの改善により、予約済みキャパシティの有効活用、ジョブのスターベーションの低減、および重要なワークロードの処理時間の短縮が可能となり、平均リソース利用率が大幅に向上しました。 How Netflix Simplified Batch Compute with Kueue netflixtechblog.com +1
Cassandra における時系列ワークロードのためのワイドパーティションの動的分割 NetflixのTimeSeries Abstractionは、Apache Cassandraをストレージとして使用し、ミリ秒単位のレイテンシでペタバイト級の時系列イベントデータを投入およびクエリします。単一のパーティションが時間の経過とともに大量のイベントを蓄積するワイドパーティションは、TimeSeriesワークロードにとって大きな課題となります。これにより、Cassandraクラスタでは読み取りレイテンシの増加、タイムアウト、CPU使用率の上昇、ガベージコレクションの一時停止が発生します。これに対処するため、TimeSeriesデータは離散的な時間チャンクにパーティション分割され、管理可能なセグメントが作成されます。初期のプロビジョニング戦略は、ユーザー指定のワークロード特性とモンテカルロシミュレーションに依存して、最適なインフラストラクチャとパーティション構成を決定していました。しかし、ワークロードが不明な場合、不正確に見積もられた場合、時間の経過とともに進化した場合、またはデータのアウトライアを含んでいた場合、このアプローチは不十分であることが判明しました。調整を自動化するために、バックグラウンドワーカーが導入され、パーティションヒストグラムを監視し、観測されたデータ密度に基づいて将来の時間スライスを動的に再パーティション分割するようになりました。このTime Slice Re-Partitioning戦略は、ほとんどのデータが同様のワイドパーティションの動作を示す場合に、読み取りレイテンシとタイムアウトを効果的に削減します。しかし、この戦略は、テーブル内のIDのごく一部のみがワイドであるシナリオには対応していません。そのようなケースでは、呼び出し元がレイテンシの上昇を伴ってもすべてのデータを必要とする場合に、Dynamic Partitioning per IDが開発されました。この非同期パイプラインは、読み取り操作中にワイドパーティションを検出し、透過的に最適なサイズに分割します。このプロセスには、検出、計画と分割、および分割されたパーティションへのクエリのリダイレクトによる読み取りの提供が含まれます。検出は、読み取り操作が設定されたバイトしきい値を超えた場合に発生し、Kafkaにイベントを発行します。システムは、簡潔さのために、最初は不変のパーティションに焦点を当てます。計画段階では、パーティション全体を読み取って分割計画を作成し、チェックポインティングを使用して障害に対処します。分割は、イベントバケットを時間バケットに割り当てるなどの特定の戦略にデータ分割を委任することを含みます。分割の検証は重要であり、チェックサムを使用して、分割が完了したとマークする前にデータの整合性を保証します。最後に、TimeSeriesサーバーはインメモリのブルームフィルタを使用して、読み取りクエリを分割されたパーティションに効率的にリダイレクトし、呼び出し元には実質的に見えないようにリダイレクトを行います。 Dynamically Splitting Wide Partitions in Cassandra for Time Series Workloads netflixtechblog.com +1
Netflixのハイスループットグラフ抽象化:パートI Netflixは、特にリアルタイム分散グラフやソーシャルグラフのようなユースケースでの使用を目的として、高スループット、低レイテンシのグラフ操作を処理するためのグラフ抽象化を構築しました。これは、詳細な分析のためのOLAPと、ストリーミングユーザーエクスペリエンスのためのOLTPの2つのカテゴリで動作します。この抽象化は、強く型付けされたノードとエッジを持つプロパティグラフモデルを使用し、分離された名前空間に編成されています。各名前空間には、データゲートウェイコントロールプレーンを通じて管理される事前定義されたグラフスキーマがあります。このスキーマは、データ品質の強制や効率的なクエリプランニングのような最適化を可能にします。リアルタイムインデックスは、ノードとエッジにキーバリューストレージを使用し、リンクとプロパティに別々のインデックスを採用しています。エッジリンクは、ソースとデスティネーションの関係によってインデックスが付けられます。方向に関係なくアクセスを保証するために、これは識別子を辞書順に編成します。キャッシュは、書き込み増幅と読み取り増幅を最小限に抑えるために使用されます。抽象化アーキテクチャは、高性能を優先し、ライトアサイドキャッシュのような戦略を取り入れています。 High-Throughput Graph Abstraction at Netflix: Part I netflixtechblog.com +1
サイロからサービストポロジーへ：なぜNetflixはリアルタイムサービスマップを構築したのか Netflixは、エンジニアがサービスの依存関係を理解し、問題をトラブルシューティングするのを支援するために、Service Topologyと呼ばれる分散インフラストラクチャの「ライブマップ」を開発しました。このマップは、障害発生時のサービス間の関係と潜在的な影響をより迅速に特定する必要性に対応します。どのサービスが互いに依存しているか、問題の原因は何かといった重要な質問に答えます。彼らは、eBPFネットワークフロー、IPCメトリクス、エンドツーエンドトレーシングの3つのソースからデータを収集しました。各データソースは、ネットワーク接続性、アプリケーションレベルの詳細、実際の要求フローという独自の視点を提供します。この多層アーキテクチャは、これらのビューを統合されたリアルタイムマップに組み合わせています。システムは、各データソースに個別のグラフデータベースを使用して、独立性を維持し、並列クエリを可能にします。エンジニアは、各グラフを個別に表示することも、それらを組み合わせてサービス間の相互作用を包括的に理解することもできます。システムは、複数のリージョンでKafkaからフローログを取り込み、処理し、グラフデータベースにデータを保存します。このライブマップは、Netflixのエンジニアが問題を迅速に診断および解決するのに役立ち、スムーズなストリーミング体験を保証します。 From Silos to Service Topology: Why Netflix Built a Real-Time Service Map netflixtechblog.com +1
Nebula ArchRules による ArchUnit のスケーリング Netflixは、数千のJavaリポジトリを持つポリリポ戦略を採用しており、効率的なビルドロジックの共有が必要です。彼らは、依存関係を管理し、コード標準を強制するために、ArchRulesを含むNebula Gradleプラグインスイートを構築しました。この取り組みは、後方互換性のない変更インシデント後のJavaライブラリライフサイクル管理を改善する必要性から生まれました。Netflixは、非推奨コードの潜在的な問題を特定するために、APIライフサイクルアノテーション（@Deprecated、@Public、@Experimental）を利用しています。アーキテクチャルールを強制するための一般的なライブラリであるArchUnitは、これらのアノテーションの誤用やその他の技術的負債の問題を検出するために選択されました。Nebula ArchRulesプラグインは、多くのリポジトリ間でArchUnitルールを共有および適用できるようにし、強化された機能を提供します。ArchRulesは、バイトコード分析（ASM）を使用してクロス言語サポートを実現し、使いやすいビルダーパターンでルールの作成を簡素化します。ルールはライブラリにバンドルすることも、スタンドアロンのルールライブラリで定義することもでき、プラグインによって自動的に検出および実行されます。ArchRules Runnerプラグインは、ソースセットに対してルールを評価し、JSONおよびコンソールレポートを生成し、より優れたレポート機能を提供します。ArchRulesを使用することにより、Netflixはライブラリ作成者がAPIの使用状況を追跡し、非推奨APIの使用を検出するためのプラットフォームを提供します。 Scaling ArchUnit with Nebula ArchRules netflixtechblog.com +1
Netflixにおける機械学習の民主化：モデルライフサイクルグラフの構築 Netflixは、パーソナライゼーション、スタジオ制作、決済、広告など、さまざまなビジネスドメインで機械学習を活用しています。MLの導入が進むにつれて、モデルとデータがサイロ化され、コラボレーションと発見が妨げられる断片化された状況という課題が生じました。MLの実践者は、モデルの系統、特徴源、および異なるシステム間での影響を理解するのに苦労しました。この断片化により、既存の特徴、データソース、パイプラインの依存関係、および変更の影響に関する質問に簡単に答えることができませんでした。根本的な困難は、メタデータを生成する異種なMLインフラストラクチャコンポーネントを接続することにありました。パイプラインオーケストレーターから実験プラットフォーム、特徴ストアまで、数十のシステムがさまざまな形式でデータを生成していました。これを解決するには、異種なメタデータを収集し、統一されたモデルに変換し、探索のための接続されたグラフを構築する必要がありました。その解決策は、NetflixでMLエンティティを相互接続するモデルライフサイクルグラフを構築するメタデータサービス（MDS）です。MDSはMLメタデータをリアルタイムで取り込み、特定のモデルを使用する実験を特定したり、特定の特徴を共有するモデルを特定したりするような、クロスドメインクエリを可能にします。ビジョンは、すべてのMLアセットを会社全体で発見可能、理解可能、再利用可能にすることです。MDSは、一意のAIP URIを持つコンポーネント、プロパティを持つML固有のアセットであるエンティティ、データ形状を定義するエンティティタイプ、関連するエンティティタイプをグループ化するドメイン、およびソースシステムからのドメインの具体的な実装であるプロバイダーというコア抽象化に基づいて動作します。このURIベースのアドレス指定により、任意のサービスが任意のMLアセットを普遍的に参照できます。グラフの構築プロセスにはいくつかの段階があります。まず、MDSはKafkaおよびAWS SNS/SQSを介してソースシステムと統合し、変更を示す薄いイベントを消費します。専用のイベントハンドラーが、パイプラインオーケストレーション、モデルレジストリ、特徴ストア、実験プラットフォーム、IDプラットフォームなどのシステムからのイベントを処理します。次に、MDSはハイドレーション契約を実装し、イベントを検証し、ソースシステムAPIを呼び出して完全な状態を取得し、それを正規化されたエンティティに変換します。「変更通知」パターンは、イベント順序の問題に対する堅牢性を確保しますが、ソースシステムに読み込み負荷をかけます。第三に、生のイベントは、標準化されたフィールドを持つ統一されたエンティティモデルに変換され、下流のコンシューマーに一貫したインターフェースを作成します。正規化されたエンティティは、フィールド名、形式を標準化し、プラットフォーム固有のIDをグローバルAIP URIに変換します。最後に、正規化されたエンティティは、キャッシュと関係ストレージのためにDatomicに永続化され、同時にElasticsearchにインデックス付けされます。不変の事実モデルを持つDatomicは、複雑なグラフトラバーサルとエンティティ関係をサポートし、非効率的なN+1クエリパターンなしで複数のドメインにわたるクエリを可能にします。 Democratizing Machine Learning at Netflix: Building the Model Lifecycle Graph netflixtechblog.com +1
モデルサービングにおけるルーティングの状態 このブログ記事では、NetflixのMLモデルサービングインフラストラクチャが、さまざまなドメインにわたるパーソナライズされたエクスペリエンスを大規模にどのように実現しているかについての技術的な洞察を論じています。中央のMLモデルサービングプラットフォームは、ドメインに依存しないAPI抽象化とトラフィックルーティング機能を提供し、モデル推論のためにいくつかのドメイン固有のマイクロサービスに公開しています。この単一のAPIは、既存のMLエクスペリエンスの新しいバージョンのイテレーションのイノベーション速度を向上させ、MLによる新しい製品エクスペリエンスを可能にしました。MLモデルサービングインフラストラクチャの成功は、研究者が新しい仮説を迅速に実験し、モデルを安全に本番環境にリリースできるかどうかにかかっています。このプラットフォームは、数百のモデルタイプとバージョンを提供し、毎秒100万リクエストを処理し、個々のスコアリング関数だけでなく、ワークフローのレベルで動作します。モデル定義には、特徴量を計算するために必要な事実のリストが含まれており、サービング時に他のいくつかのマイクロサービスを呼び出すことによってこれらの事実を供給するためにモデルサービングプラットフォームに依存しています。呼び出し元のサービスは、標準的なリクエストコンテキストと関連するドメインコンテキストを提供するだけでよく、モデル自体が実行フローの一部として特徴量を計算し、推論を実行できます。このプラットフォームは、迅速なMLイノベーションの実現者として機能し、MLモデルのイテレーションがクライアントアプリに公開される範囲を制限します。プラットフォームの主要な原則には、クライアントアプリから独立したモデルイノベーション、クライアントとモデルシャーディングの分離、および柔軟なトラフィックルーティングルールが含まれます。このプラットフォームは、Switchboardと呼ばれるカスタムサービスを使用しており、これはすべてのトラフィックの柔軟なプロキシレイヤーとして機能し、毎秒100万リクエスト以上を処理しながら、高い可用性と信頼性を維持します。Switchboardは、すべてのクライアントのモデルニーズに対する単一の連絡窓口を提供し、豊富なコンテキスト機能に基づいてリクエストをルーティングできます。このプラットフォームは、「Objective」という概念も導入しています。これは、サービングプラットフォームによって定義された列挙型であり、システムへのすべてのリクエストが提供する必要があります。Objectiveは、クライアントと具体的なモデルを分離し、プラットフォームのルーティングとモデル選択の決定をガイドします。Switchboard Rulesは、研究者がクライアントコードを変更せずにObjectiveにモデルバリアント、実験、およびトラフィック分割をアタッチできるJavaScript構成です。ルールは、特定のObjectiveに使用するデフォルトモデル、一連のObjective用に設定するA/B実験、および新しいモデルへのトラフィックを段階的にシフトするためのカスタマイズを指示します。ルールはSwitchboardとModel Servingクラスターの両方によって消費され、サービングプラットフォームコンポーネントはこれらのルールに基づいてさまざまなアクションを実行できます。全体として、このプラットフォームは、NetflixでMLモデルをサービングするためのスケーラブルで柔軟なソリューションを提供し、クライアントアプリへの影響を最小限に抑えながら、迅速なイノベーションと実験を可能にします。 State of Routing in Model Serving netflixtechblog.com +1
Netflixにおけるカメラファイル処理のスケーリング Netflixは、グローバルな制作におけるメディアワークフローを効率化し、効率性と一貫性を目指して、メディアプロダクションスイート（MPS）を構築しました。MPSの中核は、画像処理のためにFilmLightのAPI（FLAPI）を活用しており、すべてをゼロから構築することを避けるための協力関係です。MPSは、ファイル管理やメディア処理の一貫性のなさといった課題に対処し、タスクを自動化してエラーを最小限に抑えます。FLAPIは、カメラファイルメタデータを検査し、正規化して検索可能にし、一貫性を確保するために使用されます。また、FLAPIは、正確なカラーマネジメントとデベイヤリングを備えたVFXプレートと納品物を生成します。MPSはCosmosを使用してクラウド統合されており、Docker化された環境でCPUのみのインスタンスを使用できるため、効率を最大化します。プロダクションワークロードは、オンデマンドでスケーリングできるように弾力的に処理され、迅速なターンアラウンドタイムを保証します。MPSは、経験豊富なチームとガイダンスを必要とするチームの両方を対象として設計されており、FLAPIが複雑さを処理します。このパートナーシップにより、オープンなコミュニケーション、共同検証が可能になり、標準化エコシステムに利益をもたらします。全体的な影響は、遅延の削減、ターンアラウンドの迅速化、およびより効率的な制作プロセスです。 Scaling Camera File Processing at Netflix netflixtechblog.com +1
人間のインフラストラクチャ：Netflixが大規模なライブ配信の裏側に構築した運用レイヤー Netflixのライブストリーミング事業は、最初のライブショーから急速に拡大し、現在は毎日複数のイベントをストリーミングしています。初期のライブショーは、エンジニアと即興のセットアップに頼っており、専用の運用チームが不足していました。進化には、ライブ放送プロセスを管理するために専用の放送運用センター（BOC）を構築する必要がありました。信号の信頼性を確保するために、Netflixは会場からのビデオとオーディオフィードの貢献について厳格な仕様を課しています。Netflixの運用モデルは、エンジニア主導の運用から専門のエンジニアチームへと進化しました。効率を向上させて同時に多くのイベントを管理するために、送信運用センター（TOC）モデルが開発されました。TOCモデルでは、送信、ストリーミング、放送制御オペレーターなどの異なる役割が重要です。ハイプロファイルのイベントの場合、専用の「ビッグベット」モデルが提供され、専用のリソースが割り当てられます。ライブコマンドセンター（LCC）は、全ライブストリーミングパイプラインを監視し、リアルタイムのデータをオペレーターに提供します。LCCは、カスタムの観測可能性スタックを使用して大量のデータを管理し、問題に対応します。LCCオペレーションリードとテクニカルランチマネージャーは、インシデント対応を担当しています。 The Human Infrastructure: How Netflix Built the Operations Layer Behind Live at Scale netflixtechblog.com +1
LLMを審査員として使ったNetflixドラマのあらすじの評価 Netflixは、膨大なコンテンツライブラリのスニペット選択プロセスを改善することを目指しています。何千ものタイトルがユーザーの選択を複雑にし、スニペットが意思決定において重要になります。質の高いスニペットはユーザーエンゲージメントを高めますが、質の低いスニペットはフラストレーションと離脱につながります。課題は、数十万ものスニペットにわたる品質検証をスケーリングすることにあります。Netflixは、4つの主要な次元でスニペットの品質を評価するために、LLMベースのアプローチを開発しました。このシステムは、クリエイティブライターとの間で85%以上の合意を達成し、専門家主導の品質基準を保証します。スニペットの品質は、ライターによって定義されるクリエイティブ品質と、ストリーミング指標を介したメンバーの暗黙のフィードバックの両方を通じて評価されます。LLM-as-a-Judgeシステムは、精度を最適化するために、階層的な理由付け、コンセンサススコアリング、事実性エージェントなどの技術を採用しています。これらのLLMから派生した品質スコアは、テイクフラクションや離脱率などの主要なストリーミング指標と相関しています。これにより、Netflixはスニペットの問題を積極的に特定して修正し、メンバーエクスペリエンスとコンテンツ発見を改善することができます。 Evaluating Netflix Show Synopses with LLM-as-a-Judge netflixtechblog.com +1
同じ質問への二重回答を停止する：Netflix規模でのDruid向けインターバル認識型キャッシング Netflixは、大規模なDruidクエリのパフォーマンスを向上させるために、実験的なキャッシュレイヤーを実装しました。このキャッシュシステムは、特に注目度の高いイベント中に、ダッシュボードからの冗長なクエリという問題を解決します。その中心的なアイデアは、結果の一部をキャッシュし、最新のデータのみをDruidに問い合わせることで、わずかな古さとのトレードオフを導入することです。指数関数的なTime-To-Live（TTL）値が使用され、遅れて到着するイベントに対応するために、古いデータほど長くキャッシュされます。キャッシュシステムは、キャッシュデータの効率的な範囲スキャンのために、マップ・オブ・マップ構造を使用しています。キャッシュはDruidルーターでリクエストを傍受し、必要に応じて結果を提供したり、Druidに問い合わせたりします。このソリューションは、キャッシュされたデータと最新のデータを組み合わせ、完全な結果を返し、最新のデータを非同期的にキャッシュします。空のバケットにはネガティブキャッシュが使用され、末尾の空のバケットをキャッシュしないように注意が払われています。このシステムは、NetflixのKey-Value Data Abstraction Layer（KVDAL）を使用しており、Cassandraをバックエンドとしています。Cassandraは、各データポイントに独立したTTLを提供します。このキャッシュレイヤーは、Druidクエリの負荷を大幅に削減し、特に大量のイベント中にクエリ時間を改善しました。このキャッシュシステムはまだ実験段階であり、今後の目標には、Druid自体への統合が含まれています。 Stop Answering the Same Question Twice: Interval-Aware Caching for Druid at Netflix Scale netflixtechblog.com +1
ビデオ検索のためのマルチモーダルインテリジェンスを活用する この記事は、高度なビデオ検索エンジンの構築における課題と解決策について論じています。中心的な問題は、膨大な量のビデオ映像と、関連性の高い瞬間を抽出することの難しさです。解決策は、ビデオコンテンツのさまざまな側面を分析するために、さまざまなAIモデルを統合するマルチモーダルアプローチを採用することです。このアプローチでは、専門モデルからの多様なデータを、統一されたリアルタイムインテリジェンスシステムに統合する必要があります。システムのアーキテクチャは、大規模な処理に焦点を当て、数十億のデータポイントを効率的に処理します。トランザクション永続化、オフラインデータ融合、リアルタイム検索のためのインデックス作成を含む3段階のプロセスにより、データの整合性と応答性が確保されます。このプロセスでは、取り込みプロセス中のボトルネックを回避するために、分離されたパイプラインを使用します。検索サービスは、クエリの前処理、セマンティック検索のファインチューニング、および正確な結果を得るための高度なテキスト分析などの機能を提供します。また、検索精度を向上させるために、フレーズマッチング、Nグラム分析、あいまいマッチングも含まれています。システムは、よりニュアンスのある検索を可能にするために、集計と柔軟なグループ化を提供します。全体として、映画製作者が関連性の高いビデオコンテンツを発見するための強力なツールを提供することで、映画製作者に力を与えることを目指しています。 Powering Multimodal Intelligence for Video Search netflixtechblog.com +1
大規模なライブストリーミングをよりスマートに：Netflixの全ライブイベントでVBRを導入 Netflixは、効率向上のため、ライブイベントのエンコーディングを定数ビットレート（CBR）から可変ビットレート（VBR）に移行しました。VBRは、シーンの複雑さに応じてビットレートを動的に調整し、平均トラフィックの削減と視聴体験の向上を実現します。VBRの大きな課題は、トラフィックの予測可能性の低さであり、ビットレートの大きな変動により、サーバーの過負荷や不安定化につながる可能性があります。この問題に対処するため、Netflixは、公称ビットレートに基づいた新しい容量予約システムを実装し、VBRの可変性に関連するリスクを軽減しました。また、VMAFを指標として、ストリーミングラダー全体の公称ビットレートをCBRストリームの品質に合わせる調整を行いました。VBRへの移行により、バッファリングの減少や初期起動遅延の短縮といった効率化が実現しました。Netflixは現在、VBRをさらに最適化するために、適応ビットレートアルゴリズムと容量予約の改善に取り組んでいます。VBRの実装は、複数のチームと貢献者が関わった、全社的なプロジェクトでした。 Smarter Live Streaming at Scale: Rolling Out VBR for All Netflix Live Events netflixtechblog.com +1
ストリームの裏側：Netflixライブ。パート1 3年前、Netflixは、テレビ放送とほぼ同じくらい歴史の古いフォーマットであるライブストリーミングを通じて世界を楽しませる方法を模索しました。この問いから、コメディショー、スポーツ、WWEイベントなど、何百ものライブイベントが開発されました。Netflixは「Behind the Streams」と題したシリーズで、ライブストリーミング機能構築の技術的な道のりを共有します。ライブストリーミングは、アーキテクチャや技術選定における新たな考慮事項をもたらし、Netflixでうまく機能させるためには、かなりの構築が必要でした。Netflixのライブアーキテクチャの主要な柱には、専用の放送施設、クラウドベースの冗長なトランスコーディングおよびパッケージングパイプライン、ライブコンテンツ配信のスケーリング、ライブ再生の最適化、そしてクラウドでのディスカバリおよび再生制御サービスの実行が含まれます。Netflixはまた、クラウド上でリアルタイムメトリクスを一元化し、専門的なツールと施設を活用しました。ライブ機能の構築は、新たな課題と学習の機会をもたらし、Netflixは現在も日々、ライブイベントをより効果的に配信する方法を学んでいます。これまでの主な学習成果としては、徹底的なテスト、定期的な練習、視聴者予測、段階的な機能低下、そしてリトライストームの重要性が挙げられます。Netflixは堅牢なライブストリーミングシステムの構築において大きな進歩を遂げましたが、学ぶべきこと、改善すべきことはまだ多くあります。 Behind the Streams: Live at Netflix. Part 1 netflixtechblog.com +1
Netflix Tudum アーキテクチャー：Kafka を使用した CQRS から RAW Hollow を使用した CQRS へ Tudum.comは、Netflixの公式ファン向けデスティネーションで、毎月2000万人以上のメンバーに独占的コンテンツ、behind-the-scenesのインサイト、インタラクティブ体験を提供しています。プラットフォームのアーキテクチャーは、メンテナンス性、拡張性、柔軟性を考慮して設計されており、Command Query Responsibility Segregation（CQRS）に似たサーバー駆動型UIアプローチを使用しています。Tudumのエディトリアルチームがコンテンツを作成し、それを書き込みデータベースに保存し、ユーザーが消費するために読み取り最適化された形式に変換します。初期のアーキテクチャーでは、Kafkaを使用して書き込みデータベースと読み取りデータベースを分離し、独立したスケーリングと最終的一貫性を実現しました。ただし、このアプローチでは、コンテンツの編集とウェブサイトでの反映との間に遅延が生じました。チームは、Page Data Serviceがニアキャッシュを使用してページビルディングを加速するために遅延の原因を特定しました。Netflixは、この問題に対処するために、RAW Hollowというインメモリー、コロケート、圧縮オブジェクトデータベースを開発しました。これにより、強い読み取り後の書き込み一貫性と低レイテンシーを実現できました。Tudumは、RAW Hollowをテストするための完璧なフィットでした。これにより、I/Oを大幅に削減し、O（1）時間での同期データアクセスを可能にしました。更新されたアーキテクチャーでは、Kafkaインフラストラクチャーの必要性がなくなり、データ伝搬時間が短縮され、ライターとエディターが秒単位で変更をプレビューできるようになりました。また、リクエスト時間も短縮され、ホームページの構築時間が1.4秒から0.4秒に短縮されました。 Netflix Tudum Architecture: from CQRS with Kafka to CQRS with RAW Hollow netflixtechblog.com +1
キャッシュミスの分類によるコンテンツデリバリーの効率化 NetflixのOpen Connectプログラムは、インターネットサービスプロバイダー（ISP）とのパートナーシップを通じてコンテンツ配信をローカライズすることで、会員に最高の品質の体験（QoE）を提供することを目的としたコンテンツ配信ネットワーク（CDN）です。このプログラムでは、効率性とコスト効率を考慮して設計されたカスタムビルドのサーバーであるOpen Connectアプライアンス（OCA）を使用します。Open Connectの効率性を評価するために、Netflixは、特にキャッシュミス（キャッシュミスとは、クライアントの最適なOCAからバイトが提供されない場合に発生する）を特定するフレームワークを使用しています。キャッシュミスは、3つのカテゴリに分類されます。コンテンツミス（コンテンツミスとは、ローカルサイトのOCAにファイルが見つからない場合）、ヘルスミス（ヘルスミスとは、ローカルサイトのOCAハードウェアリソースが飽和している場合）、その他のミスです。Netflixは、キャッシュミスを計算するために、2つの重要なデータコンポーネントをログに記録しています。プレイバックマニフェストログとOCAサーバーログです。これらのログは、さまざまな集約レベルでの詳細なキャッシュミスメトリックを計算するために結合されます。キャッシュミスを計算するシステムアーキテクチャには、ログの発信、ログの統合、ログの強化、ストリーミングウィンドウベースの結合が含まれます。キャッシュミスを評価するために使用されるデータモデルでは、ロジックをオフラインで再生し、シミュレーションで可変パラメータを使用して、新しい条件や機能をテストできます。 Driving Content Delivery Efficiency Through Classifying Cache Misses netflixtechblog.com +1
大規模AV1：フィルムグレイン合成、覚醒 Netflixは、映画の芸術的インテグリティを保持しながらデータ効率を最適化するAV1 Film Grain Synthesis（FGS）ストリームを導入しました。映画のグレインは、映画の物語に深みとリアリズムを追加する重要な要素ですが、伝統的なアルゴリズムでは圧縮するのが困難です。AV1 FGSツールは、映画のグレインを2つのコンポーネントに分割してモデル化しています。すなわち、映画のグレインのパターンと映画のグレインの強度です。映画のグレインのパターンは、自己回帰モデルを使用して複製され、映画のグレインの強度はスケーリング関数によって制御されます。エンコーディングプロセスでは、ビデオから映画のグレインを除去し、圧縮し、圧縮されたビデオデータと一緒にグレインのパターンと強度を送信します。再生中、ブロックベースの方法を使用して映画のグレインが再作成され、ビデオに再統合されます。AV1 FGSの有効化により、ビットレートの削減が達成され、高品質のビデオストリーミングが少ないデータで実現可能になりました。また、視覚的な品質も向上し、合成ノイズが圧縮アーティファクトを効果的にマスクしています。Netflixは、プラットフォーム全体でFGSを展開し、サポートデバイス上でFGS対応ストリームを利用できるようになりました。展開により、Netflixメンバーのためのよりスムーズで信頼性の高いQuality of Experienceが実現され、ビットレートが低下し、再生エラーが減少し、再生の安定性が向上しました。 AV1 @ Scale: Film Grain Synthesis, The Awakening netflixtechblog.com +1
一度モデル化、どこでも表現：NetflixのUDA（ユニファイド・アーキテクチャー） Netflixの提供が増えるにつれて、サポートするシステムの複雑化も進み、重複や不一致のモデル、用語の不一致、データ品質の問題、データ間の関係の不一致などが生じます。これらの課題に対処するために、新しい基盤が必要になりました。すなわち、モデルを一度定義し、どこでもその定義を再利用できるようにし、概念を実際のシステムに結びつけ、定義を外部に投影し、スキーマを生成し、システム全体での一貫性を強制する必要がありました。これにより、UDA（ユニファイド・データ・アーキテクチャー）が開発されました。UDAでは、ドメインをモデル化することが一度でき、システム全体で一貫して表現することができます。これにより、自動化、発見可能性、セマンティック・インターオペラビリティーを実現します。UDAでは、ユーザーとシステムがドメイン・モデルを登録し、ドメイン・モデルをデータ・コンテナーにマッピングし、ドメイン・モデルをスキーマ定義言語にコンパイルし、データを忠実にデータ・コンテナー間で移動し、ドメイン・コンセプトを発見し探索し、知識グラフをプログラム的に内省することができます。UDAは、ビジネス・コンセプトをスキーマやデータ・コンテナーに結びつける知識グラフであり、 Upper というインハウス・メタモデルに基づいています。Upper は、ドメインを形式的に記述する言語であり、UDAでのドメイン・モデリングに使用されます。UDA は、ネームド・グラフ・ファーストの情報モデルを採用し、グラフ全体での解決、モジュール性、ガバナンスを確保します。 Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix netflixtechblog.com +1
FM-Intent: ヒエラルキー・マルチタスク・ラーニングによるユーザーセッションインテント予測 レコメンダーシステムは、電子商取引、ストリーミングメディア、ソーシャルネットワークの不可欠なコンポーネントであり、製品やビジネスに大きな影響を与えている。Netflixでは、これらのシステムが適切なコンテンツをメンバーに提供する。レコメンデーション基盤モデルは、ユーザーの嗜好を理解するために大きな進歩を遂げているが、能力をさらに高める機会がある。基盤モデルを拡張して、潜在的なユーザーの意図を予測することで、モデルは次のアイテム予測を超えてユーザーセッションの理解を豊かにすることができる。最近の研究では、オンラインプラットフォームでのユーザーの意図を理解することが、より正確でパーソナライズされたレコメンデーションにつながることを強調している。FM-Intentという新しいレコメンデーションモデルは、短期的および長期的な暗黙のシグナルをプロキシとして、ユーザーの潜在的なセッション意図を捉え、次のアイテム予測を改善するためにこの意図予測を活用する。モデルは、意図予測と次のアイテム予測の間に階層的な関係を確立し、より一貫した効果的なレコメンデーションパイプラインを作成する。FM-Intentは、三つの主要な貢献を行う：新しいレコメンデーションモデル、階層的なマルチタスク学習アプローチ、および最新の状態にあるモデルとの比較実験による有意な改善を示す。FM-Intentは、Netflixのレコメンデーションエコシステムに成功的に統合されており、パーソナライズされたUI最適化、アナリティクス、および強化されたレコメンデーションシグナルなどの下流アプリケーションに活用することができる。 FM-Intent: Predicting User Session Intent with Hierarchical Multi-Task Learning netflixtechblog.com +1
舞台裏：ロバストな広告イベント処理パイプラインの構築 Netflixでは、広告キャンペーンを監視、測定、および最適化するためのイベント処理プラットフォームを構築しました。広告サーブシステムは、決定、頻度制限、ペース、パーソナライゼーションのための安定した広告イベントのストリームに依存しています。初期の広告イベントハンドリングシステムは3つの主要コンポーネントで構成されていました。Microsoft Ad Server、Netflix Ads Manager、およびAd Event Handler。システムは、インプレッション、頻度制限、および収益化プロセスに関するフィードバックループが効果的に機能することを保証するように設計されていました。ビジネスが拡大すると、新しい永続レイヤーがKey-Value抽象化を使用して導入されました。これにより、データボリュームの成長や第三者トラッキングURLの課題に対処することができます。イベント処理パイプラインはさらに進化し、自社の広告テクノロジーをサポートする機能を追加しました。これには、頻度制限、価格情報、およびロバストなレポートシステムが含まれます。中央化された広告イベントコレクションシステムが計画され、単一の統一データ契約を消費者に提供し、上流システムと消費者の間での心配を分離することを目的としています。新しいパイプラインは、測定、財務/請求、頻度制限、および広告サーバーへのフィードバックループの維持などの多くの機能をサポートしています。広告イベント処理システムの開発は、チームワーク、計画、および調整の協力による旅のjourneyを示しています。新しいシステムは、ビジネスに対する新しい機能の立ち上げを大幅に加速化し、プログラマティック・バイイング・キャパビリティーの共有、オプトアウト・シグナルの共有、および正確なレポートと測定を保証しています。 Behind the Scenes: Building a Robust Ads Event Processing Pipeline netflixtechblog.com +1
Netflixコンテンツにおける会話の聞き取りやすさの測定 「Netflixは、技術パートナーとの協力により、メンバーの体験を向上させることを優先しています。この協力は、生産プロセス全体でダイアログの聴き取りやすさを改善することを目的としており、セットからスクリーンまでの問題を解消しています。主要なイニシアチブは、ダイアログ・インテグリティ・パイプラインであり、ノイズのある環境やオーディオ・ミキシングなどの要因が聴き取りやすさに影響を与えることを特定し、緩和しています。Netflixは、業界標準のラウドネス・メーターとeSTOIベースの測定システムを使用して、ダイアログの聴き取りやすさを分析しています。プリ・デリバリーの最適化を改善するために、Netflixは、フラウンホーファー IDMTとヌゲン・オーディオとパートナーになって、DialogCheckプラグインを作成しました。このプラグインは、デジタル・オーディオ・ワークステーション（DAWs）に統合されており、サウンド・エンジニアにリアルタイムのフィードバックを提供しています。この協力は、フラウンホーファーの機械学習ベースのスピーチ・インテリジェンス・ソリューションとヌゲン・オーディオのオーディオ・プラグインのエキスパートのノウハウを活用しています。DialogCheckプラグインは、ダイアログの聴き取りやすさの問題を早期に検出して解消することを可能にしており、アーティスティック・インテントが損なわれません。最終的な目標は、すべての視聴者に、どのようなリスニング環境でも没入感とアクセシブルなストーリーテリングを提供することです。この協力的なアプローチは、オーディオ・エクセレンスとストーリーテリングのイノベーションに対するNetflixのコミットメントを強調しています。 Measuring Dialogue Intelligibility for Netflix Content netflixtechblog.com +1
NetflixがeBPFフローログを正確に属性付ける方法 Netflixは、ネットワークの洞察を高めるために、大規模なTCPフロー ログをeBPFでキャプチャしています。しかし、フローIPアドレスをワークロードIDに正確に帰属させることは大きな課題でした。初期の帰属付けアプローチは、内部のIPアドレス追跡サービスであるSonarに依存していましたが、分散システムでの遅延や障害により誤った帰属付けが発生しました。誤った帰属付けにより、フロー データは意思決定に信頼できないものとなり、受信フローを15分間保持してから帰属付けするという回避策も問題を解決しませんでした。この問題を解決するために、Netflixは、新しい帰属付け方法を開発しました。この方法では、ローカルのIPアドレスをワークロードIDに帰属させるために、環境からローカルのワークロードIDを決定します。コンテナーワークロードの場合、Netflixは、コンテナIPアドレス割り当てサービスであるIPManを利用して、ローカルのIPアドレスを帰属させました。ローカルのIPアドレスが帰属付けられると、各ワークロードが特定のIPアドレスを所有する時間範囲を学習することで、リモートIPアドレスを帰属させることができます。FlowCollectorは、この知識を表すためにメモリ内ハッシュマップを維持し、Kafkaを使用して他のノードと学習した時間範囲を共有します。この新しい方法は、正確な帰属付けを実現し、一時的な問題に対して優雅に処理します。また、シンプルさとメモリ内検索によりコスト効率も高いです。この方法は、フローを対応するリージョンのノードに転送することで、リージョン間のIPアドレスを帰属させるように拡張されています。最後に、この方法は、Netflixのコンテンツ配信ネットワークに属するものなど、ワークロード以外のIPアドレスを帰属させるようにさらに拡張されています。 How Netflix Accurately Attributes eBPF Flow Logs netflixtechblog.com +1
Netflixのメディア・プロダクション・スイートによるグローバル・プロダクションの実現 「映画産業がクラウドベースのワークフローに移行するにつれて、グローバルな実施に課題が生じています。Netflixは、映画製作者向けに設計されたMedia Production Suite（MPS）を通じて、これらの問題を解決しようとしています。MPSは、メディア管理をストリームライン化し、退屈なタスクを排除し、創造的なフォーカスを高めます。物理テープを使用した従来のワークフローは、遅くてcumbersomeであり、コラボレーションを阻害しています。デジタルワークフローも、配布や標準化の課題に直面しています。クラウドは、解決策を提供しますが、運用上の課題や技術的なハードルを克服する必要があります。Netflixは、これらの問題を、メディアに人々やアプリケーションを持ち込む代わりに、逆のアプローチで解決しています。MPSは、技術や標準化のグローバルな格差に取り組み、多様な市場のニーズを考慮しています。スイートは、業界標準に基づくカラーマネジメントやフレーミングなどのプロセスを自動化しています。インフラストラクチャーは、クラウドと物理的な能力を最適化し、ユーザーのパフォーマンスを向上させています。MPSには、インジェスト、メディアライブラリ、デイリーズ、リモートワークステーションなど、多くのツールが含まれています。350以上のタイトルがMPSのツールを使用しており、世界各地からのフィードバックを受けています。ブラジルのシリーズ「セナ」がMPSを採用し、地理的なバリアーを克服する能力を示しています。」 Globalizing Productions with Netflix’s Media Production Suite netflixtechblog.com +1
パーソナライズドレコメンデーションのための基盤モデル Netflixは、会員の好みを一元的に学習し、様々なレコメンデーションモデル全体の効率を向上させるための、レコメンデーション向け基盤モデルを開発しています。現在のシステムは、維持コストが高く、イノベーションの共有に苦労する特殊なモデルで構成されています。基盤モデルは、広範なユーザーインタラクション履歴とコンテンツデータから学習し、その学習内容を他のモデルに分配することを目指しています。大規模言語モデルに触発されたこのアプローチは、半教師あり学習を用いたデータ中心の戦略へと移行します。Netflixは、ユーザーインタラクションをトークン化し、データの粒度とシーケンス圧縮のバランスを取りながら、長期的なインタラクション履歴を処理します。スパースなアテンションメカニズムとスライディングウィンドウサンプリングを用いて、トレーニング中の計算効率を管理します。各トークンには、アクションとコンテンツに関する豊富な異種情報が含まれており、リクエスト時およびアクション後の特徴を利用します。このモデルは、GPTと同様の自己回帰的な次のトークン予測を目的としていますが、インタラクションの重要度のばらつきを考慮した修正が加えられています。モデルは複数のトークンを予測し、長期的な依存関係を捉え、精度を向上させるために補助的な予測目的を使用します。エンティティのコールドスタートに対処するため、このモデルはインクリメンタルトレーニングで構築されており、エンティティと入力のメタデータ情報を使用して、未見のエンティティでも推論できる能力を備えています。 Foundation Model for Personalized Recommendation netflixtechblog.com +1
NetflixでHDR10+のストリーミングが始まりました Netflixは、AV1対応デバイスでHDR10+コンテンツのストリーミングを開始し、認証されたHDR10+デバイス向けにより良い視聴体験を提供しています。この機能強化は、静的メタデータしか使用していなかった既存のHDR10コンテンツに対するものです。HDR10+のダイナミックメタデータは、画像の品質と正確さを向上させます。Netflixは、HDR技術の採用のパイオニアであり、過去5年間にHDRストリーミングが300%以上増加しています。現在、会社は11,000時間以上のHDRタイトルを提供しています。Netflixは、AV1ビデオコーデックを使用してHDR10+を有効にしました。AV1は、既にNetflixで2番目にストリーミングされているコーデックであり、HDR10+ストリームの追加により、すぐに最もストリーミングされるコーデックになると予想されます。会社は、新しいリリースと既存の人気HDRタイトルにHDR10+ストリームを追加し、今年末までにすべてのHDRタイトルにHDR10+体験を提供することを目指しています。HDR10+は、Dolby VisionとHDR10の3つの主要なHDR形式の1つです。HDR10+とDolby Visionは、フレームごとのコンテンツイメージ統計を提供するダイナミックメタデータを使用し、各シーンのトーンマッピング調整を最適化します。これにより、オリジナルの創造意図をより忠実に再現することができます。HDR10+を受信するには、Netflixプレミアムプランのサブスクリプション、タイトルのHDR10+形式での提供、AV1とHDR10+をサポートするデバイスが必要です。HDR10+のローンチは、Netflixの複数のチームが協力して実現したものであり、会社はこのアイデアを実現するために貢献したすべての人々に感謝しています。イノベーションと品質に対するコミットメントは、Netflixがすべてのメンバーに対して没入型でオーセンティックな視聴体験を提供するという決意を示しています。 HDR10+ Now Streaming on Netflix netflixtechblog.com +1
タイトル：Netflix規模での観測可能性の導入 Netflixでは、パーソナライゼーションとディスカバリースタック全体のサービスにわたって観測可能性エンドポイントを導入することで、包括的なタイトル観測可能性を実現しました。スタックに関与する各マイクロサービスは、タイトルヘルスエンドポイントを新しく導入し、生産環境の動作を正確に反映し、標準化し、インサイトトライアドに答えるという原則に従う必要がありました。インサイトトライアドでは、エンドポイントがタイトルがプロモーションの対象かどうか、対象でない場合はなぜ対象でないか、また問題を解決するために何ができるかを回答する必要があります。観測可能性サービスとパーソナライゼーションスタックの観測可能性エンドポイント間の通信を標準化するために、安定したプロトコルリクエスト/レスポンス形式が開発されました。ソリューションの高レベルアーキテクチャには、観測可能性エンドポイントの確立、積極的な監視、リアルタイムのタイトルインプレッションの追跡、最適化されたデータストアへのデータの保存、およびダッシュボードのための簡単に統合できるAPIの提供が含まれます。タイトルヘルスミクロサービスは、30分ごとにスケジュールされたコレクタージョブを実行して、割り当てられた行サービスから関連するタイトルヘルス情報を取得します。リアルタイムのタイトルインプレッションデータは、2分ごとにインプレッションデータを取得するためにポーリングされるKafkaキューから処理されます。データはその後集約され、ステークホルダーにとって追加のヘルスステータスインジケーターとして提示されます。データは、各コレクターに専用のHollowフィードに保存され、読み取り専用の高パフォーマンスアクセスを可能にし、全体のヘルスとタイトルの履歴の追跡を可能にします。観測可能性ダッシュボードは、タイトルヘルスサービスを利用して、ステークホルダーにタイトルのステータスを提示し、システムには、問題がメンバーに影響を与える前にそれらをキャッチして修正するために、事前にトラフィックをシミュレートする「タイムトラベル」機能もあります。システムのアーキテクチャと戦略により、Netflixはタイトルローンチの観測可能性を強化し、魅力的な視聴体験を提供し、コンテンツクリエイターとパートナーとの信頼を築くことができました。ソリューションはまた、将来の革新の基盤を提供し、すべてのストーリーが意図した対象者に届き、すべてのメンバーがNetflixでお気に入りのタイトルを楽しむことができるようにします。 Title Launch Observability at Netflix Scale netflixtechblog.com +1
Netflixのインプレッションを紹介する Netflixでは、プラットフォーム上の画像は「インプレッション」と呼ばれ、ユーザーエクスペリエンスのパーソナライゼーションに重要な役割を果たします。インプレッションの取得と処理は、複雑なタスクであり、洗練されたシステムが必要です。このシステムは、毎日数十億のインプレッションを追跡して処理し、各プロファイルの露出の詳細な履歴を保持しています。このインプレッション履歴は、パーソナライゼーションの向上、頻度制限、新着リリースの強調表示、および分析的な洞察に不可欠です。インプレッションを管理する第一歩は、Source-of-Truth（SOT）データセットを作成することです。これは、さまざまなダウンストリームワークフローをサポートし、複数のユースケースを可能にします。生のインプレッションイベントはクライアント側から収集され、カスタムイベントエクストラクター、Apache Kafka、およびApache Icebergを介して処理されます。次に、データはApache Flinkを使用してフィルタリング、エンリッチメント、構造化され、Netflixのインプレッションデータの決定的な真実の源が確立されます。システムは、詳細なメトリクスを収集し、潜在的な問題についてチームに警告することで、高品質のインプレッションを保証します。アーキテクチャは、スケーラビリティ、柔軟性、および高可用性に焦点を当てて、インプレッションイベントの大容量をリアルタイムで処理するように設計されています。将来の作業には、スキーマ化されていないイベントの処理、パフォーマンスチューニングの自動化、およびデータ品質アラートの改善が含まれます。 Introducing Impressions at Netflix netflixtechblog.com +1
タイトル：Netflix規模での観測可能性の導入 Netflixでのタイトルのスムーズなリリースと発見性を確保するには、解決策に取り組む前に、より広い文脈を理解することが不可欠です。この思慮深いアプローチにより、将来のために回復力とスケーラビリティが構築されます。最初のステップは、利害関係者を特定し、現在の状況を把握し、コアの問題を明確にし、ビジネス優先順位を評価することです。タイトルリリースオペレーター、パーソナライゼーションシステムエンジニア、プロダクトマネージャー、クリエイティブ担当者が主な利害関係者です。現在の状況を把握すると、タイトルリリースの可視性のための確立された解決策がなかったことがわかり、課題と機会が両方存在することが明らかになりました。コアの問題は、パーソナライゼーションスタックによってすべてのタイトルが公平に扱われることを保証することでした。これに対処するために、「タイトルヘルス」という共通の理解が導入され、発見性とメンバーのエンゲージメントの観点からタイトルのパフォーマンスを反映するさまざまなメトリックと指標が含まれました。タイトルヘルスは、各タイトルのライフサイクルを監視および最適化するためのフレームワークを提供し、パートナーとの原則と要件の調整を可能にしました。タイトルリリースの可視性のための堅牢な計画を構築するために、問題は3つの主なカテゴリに分類されました。タイトル設定、パーソナライゼーションシステム、アルゴリズムです。問題をカテゴリ化することで、課題を体系的に解決し、各タイトルに対して信頼性の高いパーソナライズされた体験を提供できます。問題分析により、設定問題は最も一般的ですが、最も簡単に修正できることがわかりましたが、アルゴリズム問題はまれですが、解決が難しいことがわかりました。オプションの評価により、最初に積極的な問題検出に焦点を当てることが決定され、リリース前に問題を捕捉してスムーズなリリース、メンバーの体験の向上、システムの信頼性の向上を確保しました。この決定により、複雑なプラットフォームの進化に合わせて成長できるスケーラブルで堅牢なシステムの基礎が築かれました。 Title Launch Observability at Netflix Scale netflixtechblog.com +1
第3部：Netflixでの分析エンジニアリング業務の調査 この記事は、Netflixでのアナリティクス・エンジニアリングの多パート・シリーズの最後を締めくくるもので、技術的スキルに焦点を当てています。ダッシュボード・デザインのヒントを議論し、ユーザーのニーズを理解し、既存のパターンを活用する重要性を強調しています。また、ダッシュボードのデザインについても触れ、ユーザーのメンタル・モデルに合ったアプリケーションの構造化方法、ページ・レイアウト、インタラクティブ・チャート、およびオンボーディングのガイドラインを提供しています。さらに、Netflixでのアナリティクス・APIのデプロイメントでの学びを共有し、リアルタイム・結果の影響と必要性の測定、すべてのソリューションの探索、パフォーマンス・期待値の調整、徹底的なテストとコラボレーションの重要性などの主要なポイントを強調しています。 Part 3: A Survey of Analytics Engineering Work at Netflix netflixtechblog.com +1
パート2：Netflixにおけるアナリティクスエンジニアリングの調査 Netflixの分析エンジニアリングチームは、Netflixゲームのユーザー獲得キャンペーンの効果を測定するゲーム分析を含むさまざまなプロジェクトに取り組んでいます。このチームは、対照シナリオを推定するために合成コントロールフレームワークを使用し、インクリメンタル結果に関する洞察を提供するためのインタラクティブツールを開発しました。また、将来のキャンペーンの設計と予算化を導くインクリメンタル投資収益率モデルにも取り組んでいます。さらに、チームは、インクリメンタルアカウントライフタイムバリューションなどの他のフレームワークを活用してインクリメンタルサインアップを推定するアプローチを使用して、Netflixゲームのインクリメンタルサインアップを測定および検証することに重点を置いています。Netflixゲームのプレイヤージャーニーは、日次の状態遷移確率を示す状態マシンを使用してモデル化されており、エンゲージメント目標への進捗状況を評価し、月間アクティブアカウントを増やすための改善点を特定するのに役立ちます。この記事では、Netflixが「未定」のスロットのキャッシュニーズを予測するために、タイトルの発売日までおよびその後までの日次キャッシュ支出をモデル化するコンテンツキャッシュモデリングについても説明しています。最後に、チームは、多層構造の測定フレームワークを使用してそのパフォーマンスを評価するアシスタンススピーチ認識技術を使用して、吹き替えワークフローのトランスクリプションプロセスの効率を向上させることに取り組んでいます。 Part 2: A Survey of Analytics Engineering Work at Netflix netflixtechblog.com +1
Configurable Metaflowの紹介 Netflixのチームは、Metaflowを使用して効率的にML/AIプロジェクトを開発および管理できます。Configsは、Metaflowの新機能であり、ユーザーが人間が読みやすい設定ファイルでフロー パラメータ、リソース要件、およびアプリケーション固有の設定を定義できるようにすることで、設定可能なフローを実現します。Configsは、既存のMetaflowアーティファクトとパラメータを拡張し、より柔軟性とカスタマイズ オプションを提供します。リモート実行や本番環境でのデプロイ時でも、動的に読み込まれ、変更できます。Configsは、固定デプロイとランタイム設定の組み合わせ、設定の検証、設定ファイルの階層の管理、設定の動的生成などの高度なユースケースを実現します。Hydraなどの設定マネージャーと組み合わせて使用すると、複数の設定をまたぐ実験のオーケストレーションやパラメータ空間のスイープが可能になります。Netflixの内部ツールであるMetaboostは、実践でConfigsを使用する例であり、異なるプラットフォームのMLプロジェクトを単一のインターフェイスで管理し、プロジェクトの整合性を高め、リスクを軽減します。 Introducing Configurable Metaflow netflixtechblog.com +1
パート 1: Netflix の分析エンジニアリング作業の調査 Netflix のアナリティクス エンジニアリング チームは、会社全体で高品質で実用的なインサイトを効果的に作成して提供できるように、会社の機能を強化することに取り組んでいます。最近では、DataJunction、LORE、基礎プラットフォーム データを活用したクラウド効率アナリティクスの有効化など、さまざまなトピックを取り上げた年次内部 Analytics Engineering カンファレンスを開催しました。DataJunction は、指標定義を標準化してアクセスできるようにするオープンソース ソリューションです。一方、LORE は LLM を使用してエンドユーザーに実用的なインサイトを提供するチャットボットです。チームは、アナリティクス プラクティショナーが Netflix で高品質のインサイトを効果的に作成して提供できるようにすることを目的としたアナリティクス有効化などの取り組みを通じて、アナリティクスの民主化にも注力しています。チームの目標は、エンジニアリング組織が Netflix のストリーミングサービスとしての機能を可能にするサービスを構築および維持する際に、効率に配慮した意思決定を行えるようにすることです。 Part 1: A Survey of Analytics Engineering Work at Netflix netflixtechblog.com +1
Netflix のクラウド効率 Netflixは、コンピューティング、ストレージ、ネットワーキングを含め、クラウドインフラストラクチャニーズに対してAmazon Web Services（AWS）を使用しています。同社の多様な技術環境は、さまざまなインフラストラクチャエンティティから膨大なデータを生成し、データエンジニアとアナリストはこれを活用してエンジニアリング組織に実行可能な見識を提供しています。Data & Insights組織は、エンジニアリングチームと提携して重要な効率指標を共有し、関係者が情報に基づくビジネス上の意思決定を下せるようにしています。Platform DSEチームは、Foundational Platform Data（FPD）とCloud Efficiency Analytics（CEA）という2つのコンポーネントソリューションを開発しました。FPDは、すべてのプラットフォームデータの中央データレイヤーを提供し、一貫したデータモデルと標準化されたデータ処理手法を備えています。CEAは、さまざまなビジネスユースケースにわたる時系列効率指標を提供する分析データレイヤーを提供します。このチームは、FPDとCEAにプラットフォームのオンボーディングを継続し、来年にはほぼ完全なコストインサイトカバレッジを目指しています。また、セキュリティや可用性など、ビジネスの他の分野にFPDを拡張し、予測分析とMLを使用して使用を最適化し、コストの異常を検出するなどの予防的なアプローチに移行する予定です。 Cloud Efficiency at Netflix netflixtechblog.com +1
タイトルの起動に関する Netflix 規模のオブザーバビリティ Netflixでは、毎月1000を超えるグローバルコンテンツの配信を管理することが最優先事項であり、包括的な可観測性を実現する堅牢なシステムが必要です。同社は、あらゆるストーリーを適切な視聴者につなげることを目指していますが、エラー率やCPU使用率などの従来のシステムメトリクスでは、タイトルの成功のニュアンスを捉えることはできません。このギャップを埋めるため、Netflixはこれらのニュアンスを認識し、すべてのタイトルが際立つようにするシステムを設計する必要があります。Netflixオリジナルの初期段階では、配信チームがタイトルの配置を手作業で確認していましたが、このアプローチは同社のグローバル展開に合わせて拡張することはできませんでした。その結果、Netflixはタイトルのパフォーマンスと発見に関する複雑なクエリに正確かつタイムリーに回答するという運用上の課題に直面しました。同社は、すべてのタイトルを完璧に配信し、メタデータとアセットを正しく設定し、データをシームレスに流し、アルゴリズムを意図したとおりに機能させるための拡張可能なソリューションを必要としていました。これらの課題に対処するため、Netflixはパーソナライズシステムでのログ処理とオブザーバビリティエンドポイントの2つのオプションを検討しました。ログ処理はタイトルの発売を監視して分析するための簡単なソリューションを提供しますが、問題を事前に検出して正確性を確保するなどの制限があります。一方、可観測性エンドポイントは、リアルタイムの監視、問題の予防的検出、精度の向上を提供しますが、かなりの初期投資と同期作業が必要です。最終的に、Netflixはリアルタイムモニタリング、問題の予防検出、真実のソースの照合を含む包括的なオブザーバビリティ戦略を採用しました。このアプローチにより、同社はプラットフォーム全体でタイトルの成功した発売と発見を確実に実行できる能力が大幅に向上しました。このシリーズの次の部分で、Netflixはこれを実現する方法に関する重要な技術的洞察と詳細を共有します。 Title Launch Observability at Netflix Scale netflixtechblog.com +1
Netflixの分散カウンタ抽象化 Netflixの分散カウンタ・アブストラクションは、低ミリ秒レイテンシーの大容量の時系列イベント・データを格納およびクエリーするためのサービスです。このサービスは、2つの主要なユース・ケース・カテゴリをサポートしています。Best-EffortとEventual Consistency。Best-Effort・カウンタは、単一リージョン内の高スループットと低レイテンシーをEVCacheを使用して実現しますが、クロス・リージョン・レプリケーションと一貫性の保証がありません。一方、Eventual Consistency・カウンタは、アパッチ・カフカのような耐久的なキューイング・システムを使用して正確で耐久的なカウントを実現しますが、パーティションのリバランスに伴う遅延や課題が生じる可能性があります。Netflixのアプローチは、各カウント・アクティビティをイベントとしてログに記録し、これらのイベントを継続的に集計することで、監査や再カウントの要件を満たします。 Netflix’s Distributed Counter Abstraction netflixtechblog.com +1
ワークベンチUIの遅延問題の調査 あるユーザーが、特定のノートブックを実行する際に、JupyterLab UI が遅くなり、応答が遅れると報告しました。遅さを量的に評価するために、15秒間キーを押し続けながらユーザーのノートブックを実行し、遅延が1秒から10秒で、平均7.4秒であったことを観察しました。CPUの過剰割り当てやネットワークの問題が原因でないと判断しました。py-spyを使用して、jupyter-labプロセスで多くのCPU時間が__parse_smaps_rollupという関数に費やされていることを発見しました。この関数は、jupyter_resource_usage拡張の一部で、リソース使用状況の情報を取得するために使用されます。この関数は、UIから定期的に呼び出されるAPIエンドポイントによってトリガーされます。このコードは、JupyterLabプロセスのすべての子プロセス、つまりipykernel Notebookプロセスとノートブックによって作成されたすべてのプロセスを再帰的に取得します。この関数のコストは、すべての子プロセスの数に比例します。再現コードでは、コンテナーに割り当てられた64CPUよりも多くの96プロセスを作成します。この不一致が親プロセスを遅くする原因です。 Investigation of a Workbench UI Latency Issue netflixtechblog.com +1
Netflix TimeSeriesデータ抽象化レイヤーの紹介 Netflixは効率的に大量の時間的イベントデータを格納し、わずかミリ秒の遅延でクエリを実行するためのTimeSeries Abstractionを開発しました。このシステムは、大規模データセットでの効率的なクエリ、グローバルな読み取りと書き込み、調整可能な設定、コスト効率など、高スループットの書き込みに対応するように設計されています。TimeSeries Abstractionは、パーティションされたデータ、柔軟なストレージ、構成可能性、スケーラビリティ、シャーディングされたインフラストラクチャなどの基本設計原則に基づいています。データモデルは、イベントアイテム、イベント、時系列ID、名前空間で構成されています。イベントアイテムは特定のイベントのデータを格納するキーと値のペアであり、イベントは1つ以上のイベントアイテムの構造化されたコレクションです。時系列IDはデータセットの保持期間を超えるイベントのコレクションであり、名前空間は時系列IDとイベントデータのコレクションです。TimeSeries Abstractionは、WriteEventRecordsSync、WriteEventRecords、ReadEventRecords、SearchEventRecords、AggregateEventRecordsなどのイベントデータと対話するためのAPIを提供します。ストレージ層はプライマリデータストアとオプションのインデックスデータストアで構成されており、Apache CassandraとElasticsearchが、それぞれ永続的なデータの格納とインデックス作成の優先的な選択肢となっています。プライマリデータストアは時間パーティションスキームを使用して、データを時間間隔に基づいて管理可能なチャンクに分割することで、特定の時間範囲の効率的なクエリを実行し、ストレージとクエリのパフォーマンスを最適化します。データはさらに、効果的なレンジスキャンを容易にし、高スループットの書き込み操作を管理するために、タイムバケットとイベントバケットにパーティション化されます。TimeSeries Abstractionは、大規模な時間的イベントデータのストレージとクエリの課題に対応するように設計されており、高スループット、効率的なクエリ、グローバルな読み取りと書き込み、調整可能な設定、コスト効率が含まれます。独自のイベントデータモデルとスケーラブルなストレージ層を使用することで、TimeSeries AbstractionはNetflixで時間データ管理のための汎用的でコスト効率の高いソリューションを提供します。 Introducing Netflix TimeSeries Data Abstraction Layer netflixtechblog.com +1
Netflixのキー・バリュー・データ・アブストラクション・レイヤーの導入 NetflixのKey-Value (KV) データ抽象化レイヤー (DAL) は、データアクセスを簡単化し、インフラストラクチャーの信頼性を高める基礎的な抽象化サービスです。このレイヤーは、基礎となるデータベースにかかわらず、開発者に対して一貫したインターフェースを提供します。KV抽象化は、2レベルのマップアーキテクチャーを採用し、単純なデータモデルと複雑なデータモデル両方をサポートします。このレイヤーは、基本的なCRUD API (PutItems、GetItems、DeleteItems) と、多様なユースケースに対応するMutateItemsとScanItems APIを提供します。名前空間は、データがどこで、どのように保存されるかを定義し、論理的なおよび物理的な分離を提供します。これにより、特定のパフォーマンス、耐久性、整合性のニーズに基づいて、異なるユースケースが最適なストレージシステムにルーティングされます。PutItemsとDeleteItems APIは、idempotency tokensを使用してデータの整合性を保証し、操作の正しい順序を確保します。クライアントが生成する単調的なトークンが信頼性のために好まれます。大きなブロブを処理するために、KV抽象化はチャンク分割を使用します。この技術は、大きなデータを小さなチャンクに分割し、適切なメタデータとともにステージングおよびコミットします。ページネーションは、大きなデータセットを管理するために重要な機能です。GetItems APIは、next_page_tokenを使用したページネーションをサポートし、複数のリクエストでの効率的なデータ取得を確保します。墓石（削除されたデータを示すもの）は、パフォーマンスに影響を与える可能性があります。KVは、レコードと範囲の削除を最適化し、単一の墓石を生成し、読み込みページネーションのパフォーマンスを維持します。アイテムレベルの削除は、TTLベースの削除とジッターを使用して処理します。この技術は、ストレージエンジンの複雑さを隠し、削除が読み込みページネーションに与える影響を最小限度に抑えます。idempotencyとチャンク分割は、テールレイテンシーの処理と予測可能な低レイテンシーパフォーマンスの確保にとって不可欠です。これらのデザイン哲学は、Netflixのグローバルオペレーションに必要とされる信頼性とパフォーマンスに貢献します。 Introducing Netflix’s Key-Value Data Abstraction Layer netflixtechblog.com +1
限界まで押し進める：NetflixのWebSocketプロキシを未来に向かって進化させる Pushyは、NetflixのWebSocketサーバーで、Netflixアプリが動作するデバイスとの永続的な接続を維持しています。メッセージ配信サービスの進化から、Netflixのエコシステムの不可欠な部分となった。Pushyは、数億の同時WebSocket接続を処理し、1秒あたり数十万のメッセージを配信し、メッセージ配信の信頼性が99.999%です。FireTVs向けに初めて開発されたが、Pushyの範囲は、携帯デバイスや能力が限られた古いデバイスを含む、ほぼ10億のデバイスにまで広がりました。この成長に対応するために、Pushyは、Netflixの舗道コンポーネントを使用してメッセージプロセッサーを書き直し、パフォーマンスとスケーラビリティの向上のためにPushレジストリーをKeyValueに移行し、接続数に基づく指数関数的なスケーリングポリシーを実装しました。これらの改善により、Pushyはより信頼性が高く、安定し、効率的に、デバイスの増加と新機能の要件に対応することができます。 Pushy to the Limit: Evolving Netflix’s WebSocket proxy for the future netflixtechblog.com +1
eBPF を使用した騒がしい隣人検出 Netflixは、eBPFを使用して、サーバーのリソースを大量に使用するコンテナ（ノイジー・ネイバー）が隣接するコンテナのパフォーマンスを低下させることを示すラン・キューラテンシーの継続的な監視を行っています。eBPFのフック（sched_wakeup、sched_wakeup_new、sched_switch）は、ラン・キューラテンシーをキャプチャし、cgroup IDと関連付けるためにkfuncs（カーネル・ファンクション）を使用してRCU保護されたデータにアクセスします。eBPFのレート・リミッターは、観察可能性とパフォーマンスのバランスをとり、ユーザースペースに送られるデータ・ポイントの数を制限します。ユーザースペースのプロセスは、eBPFのリング・バッファーからイベントを受け取り、アトラスにメトリクスを出力します。このメトリクスには、cgroup ID別のラン・キューラテンシー（runq.latency）とプリエンプション・カウント（sched.switch.out）が含まれます。runq.latencyとsched.switch.outの両メトリクスがノイジー・ネイバーの特定に必要です。なぜなら、runq.latencyだけでは、コンテナがCPUの制限に達している場合、誤解を招く可能性があるからです。ケース・スタディーでは、新しいコンテナがホストのCPUを完全に使用し、ラン・キューラテンシーとプリエンプションのスパイクを引き起こすノイジー・ネイバーの問題を示しています。sched.switch.outメトリクスを使用して、ノイジー・ネイバーがシステム・プロセスであることが特定されました。eBPFコードの最適化、特にBPF_MAP_TYPE_HASHの使用、タスク・ストラクト・メンバーの直接アクセス、カーネル・タスクの無視などで、オーバーヘッドが最小限度に抑えられます。Linuxカーネル・パッチが提出され、受け入れられて、カーネルでの統計の計算を改善しました。BPFtop、オープンソースのeBPFプロセス監視ツールが、eBPFコードのオーバーヘッドを測定するために使用されました。 Noisy Neighbor Detection with eBPF netflixtechblog.com +1
Netflixでの長期的な会員満足度向上のための推奨 Netflixは、会員の長期的な満足度を高めることを目的として、パーソナライゼーションアルゴリズムを使用してコンテンツを会員に推薦します。この推薦は、会員のフィードバックに基づいてシステムがアクションを選択する文脈的なバンディット問題と捉えられます。従来のレコメンダーシステムは、クリック数などの短期的なメトリクスを最適化するが、長期的な満足度を完全に捉えることができない場合があります。長期的な会員の満足度にのみ最適化することは、問題があります。Netflixは、長期的な会員の満足度と一致するプロキシ報酬関数を使用します。クリックスルー率（CTR）は、単純なプロキシ報酬ですが、Netflixは、CTRを超える多くのユーザーアクションとそれらが満足度に与える影響を考慮します。報酬エンジニアリングは、長期的な会員の満足度と一致するプロキシ報酬関数を改良する反復的なプロセスです。このプロセスには、仮説の形成、報酬の定義、バンディットポリシーのトレーニング、A/Bテストが含まれます。Netflixは、遅延フィードバックの問題に対処するために、欠けているフィードバックを予測し、プロキシ報酬関数にすべてのフィードバックを使用します。オフラインモデル改善にもかかわらず、オンラインオフラインメトリクス不一致が、プロキシ報酬が長期的な会員の満足度と完全に一致しない場合に生じます。Netflixは、プロキシ報酬関数の定義をさらに改良することでこれを解決します。まだ解決が必要な問題として、プロキシ報酬関数の自動学習、遅延フィードバックの最適な待ち時間の決定、長期的な満足度との一致のための強化学習の活用があります。 Recommending for Long-Term Member Satisfaction at Netflix netflixtechblog.com +1
