NetflixのTimeSeries Abstractionは、Apache Cassandraをストレージとして使用し、ミリ秒単位のレイテンシでペタバイト級の時系列イベントデータを投入およびクエリします。単一のパーティションが時間の経過とともに大量のイベントを蓄積するワイドパーティションは、TimeSeriesワークロードにとって大きな課題となります。これにより、Cassandraクラスタでは読み取りレイテンシの増加、タイムアウト、CPU使用率の上昇、ガベージコレクションの一時停止が発生します。これに対処するため、TimeSeriesデータは離散的な時間チャンクにパーティション分割され、管理可能なセグメントが作成されます。 初期のプロビジョニング戦略は、ユーザー指定のワークロード特性とモンテカルロシミュレーションに依存して、最適なインフラストラクチャとパーティション構成を決定していました。しかし、ワークロードが不明な場合、不正確に見積もられた場合、時間の経過とともに進化した場合、またはデータのアウトライアを含んでいた場合、このアプローチは不十分であることが判明しました。調整を自動化するために、バックグラウンドワーカーが導入され、パーティションヒストグラムを監視し、観測されたデータ密度に基づいて将来の時間スライスを動的に再パーティション分割するようになりました。このTime Slice Re-Partitioning戦略は、ほとんどのデータが同様のワイドパーティションの動作を示す場合に、読み取りレイテンシとタイムアウトを効果的に削減します。 しかし、この戦略は、テーブル内のIDのごく一部のみがワイドであるシナリオには対応していません。そのようなケースでは、呼び出し元がレイテンシの上昇を伴ってもすべてのデータを必要とする場合に、Dynamic Partitioning per IDが開発されました。この非同期パイプラインは、読み取り操作中にワイドパーティションを検出し、透過的に最適なサイズに分割します。このプロセスには、検出、計画と分割、および分割されたパーティションへのクエリのリダイレクトによる読み取りの提供が含まれます。 検出は、読み取り操作が設定されたバイトしきい値を超えた場合に発生し、Kafkaにイベントを発行します。システムは、簡潔さのために、最初は不変のパーティションに焦点を当てます。計画段階では、パーティション全体を読み取って分割計画を作成し、チェックポインティングを使用して障害に対処します。分割は、イベントバケットを時間バケットに割り当てるなどの特定の戦略にデータ分割を委任することを含みます。分割の検証は重要であり、チェックサムを使用して、分割が完了したとマークする前にデータの整合性を保証します。最後に、TimeSeriesサーバーはインメモリのブルームフィルタを使用して、読み取りクエリを分割されたパーティションに効率的にリダイレクトし、呼び出し元には実質的に見えないようにリダイレクトを行います。

Netflixは、特にリアルタイム分散グラフやソーシャルグラフのようなユースケースでの使用を目的として、高スループット、低レイテンシのグラフ操作を処理するためのグラフ抽象化を構築しました。これは、詳細な分析のためのOLAPと、ストリーミングユーザーエクスペリエンスのためのOLTPの2つのカテゴリで動作します。この抽象化は、強く型付けされたノードとエッジを持つプロパティグラフモデルを使用し、分離された名前空間に編成されています。各名前空間には、データゲートウェイコントロールプレーンを通じて管理される事前定義されたグラフスキーマがあります。このスキーマは、データ品質の強制や効率的なクエリプランニングのような最適化を可能にします。リアルタイムインデックスは、ノードとエッジにキーバリューストレージを使用し、リンクとプロパティに別々のインデックスを採用しています。エッジリンクは、ソースとデスティネーションの関係によってインデックスが付けられます。方向に関係なくアクセスを保証するために、これは識別子を辞書順に編成します。キャッシュは、書き込み増幅と読み取り増幅を最小限に抑えるために使用されます。抽象化アーキテクチャは、高性能を優先し、ライトアサイドキャッシュのような戦略を取り入れています。

Netflixは、エンジニアがサービスの依存関係を理解し、問題をトラブルシューティングするのを支援するために、Service Topologyと呼ばれる分散インフラストラクチャの「ライブマップ」を開発しました。このマップは、障害発生時のサービス間の関係と潜在的な影響をより迅速に特定する必要性に対応します。どのサービスが互いに依存しているか、問題の原因は何かといった重要な質問に答えます。彼らは、eBPFネットワークフロー、IPCメトリクス、エンドツーエンドトレーシングの3つのソースからデータを収集しました。各データソースは、ネットワーク接続性、アプリケーションレベルの詳細、実際の要求フローという独自の視点を提供します。この多層アーキテクチャは、これらのビューを統合されたリアルタイムマップに組み合わせています。システムは、各データソースに個別のグラフデータベースを使用して、独立性を維持し、並列クエリを可能にします。エンジニアは、各グラフを個別に表示することも、それらを組み合わせてサービス間の相互作用を包括的に理解することもできます。システムは、複数のリージョンでKafkaからフローログを取り込み、処理し、グラフデータベースにデータを保存します。このライブマップは、Netflixのエンジニアが問題を迅速に診断および解決するのに役立ち、スムーズなストリーミング体験を保証します。

Netflixは、数千のJavaリポジトリを持つポリリポ戦略を採用しており、効率的なビルドロジックの共有が必要です。彼らは、依存関係を管理し、コード標準を強制するために、ArchRulesを含むNebula Gradleプラグインスイートを構築しました。この取り組みは、後方互換性のない変更インシデント後のJavaライブラリライフサイクル管理を改善する必要性から生まれました。Netflixは、非推奨コードの潜在的な問題を特定するために、APIライフサイクルアノテーション（@Deprecated、@Public、@Experimental）を利用しています。アーキテクチャルールを強制するための一般的なライブラリであるArchUnitは、これらのアノテーションの誤用やその他の技術的負債の問題を検出するために選択されました。Nebula ArchRulesプラグインは、多くのリポジトリ間でArchUnitルールを共有および適用できるようにし、強化された機能を提供します。ArchRulesは、バイトコード分析（ASM）を使用してクロス言語サポートを実現し、使いやすいビルダーパターンでルールの作成を簡素化します。ルールはライブラリにバンドルすることも、スタンドアロンのルールライブラリで定義することもでき、プラグインによって自動的に検出および実行されます。ArchRules Runnerプラグインは、ソースセットに対してルールを評価し、JSONおよびコンソールレポートを生成し、より優れたレポート機能を提供します。ArchRulesを使用することにより、Netflixはライブラリ作成者がAPIの使用状況を追跡し、非推奨APIの使用を検出するためのプラットフォームを提供します。

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クエリパターンなしで複数のドメインにわたるクエリを可能にします。

このブログ記事では、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モデルをサービングするためのスケーラブルで柔軟なソリューションを提供し、クライアントアプリへの影響を最小限に抑えながら、迅速なイノベーションと実験を可能にします。

Netflixは、グローバルな制作におけるメディアワークフローを効率化し、効率性と一貫性を目指して、メディアプロダクションスイート（MPS）を構築しました。MPSの中核は、画像処理のためにFilmLightのAPI（FLAPI）を活用しており、すべてをゼロから構築することを避けるための協力関係です。MPSは、ファイル管理やメディア処理の一貫性のなさといった課題に対処し、タスクを自動化してエラーを最小限に抑えます。FLAPIは、カメラファイルメタデータを検査し、正規化して検索可能にし、一貫性を確保するために使用されます。また、FLAPIは、正確なカラーマネジメントとデベイヤリングを備えたVFXプレートと納品物を生成します。MPSはCosmosを使用してクラウド統合されており、Docker化された環境でCPUのみのインスタンスを使用できるため、効率を最大化します。プロダクションワークロードは、オンデマンドでスケーリングできるように弾力的に処理され、迅速なターンアラウンドタイムを保証します。MPSは、経験豊富なチームとガイダンスを必要とするチームの両方を対象として設計されており、FLAPIが複雑さを処理します。このパートナーシップにより、オープンなコミュニケーション、共同検証が可能になり、標準化エコシステムに利益をもたらします。全体的な影響は、遅延の削減、ターンアラウンドの迅速化、およびより効率的な制作プロセスです。

Netflixのライブストリーミング事業は、最初のライブショーから急速に拡大し、現在は毎日複数のイベントをストリーミングしています。初期のライブショーは、エンジニアと即興のセットアップに頼っており、専用の運用チームが不足していました。進化には、ライブ放送プロセスを管理するために専用の放送運用センター（BOC）を構築する必要がありました。信号の信頼性を確保するために、Netflixは会場からのビデオとオーディオフィードの貢献について厳格な仕様を課しています。Netflixの運用モデルは、エンジニア主導の運用から専門のエンジニアチームへと進化しました。効率を向上させて同時に多くのイベントを管理するために、送信運用センター（TOC）モデルが開発されました。TOCモデルでは、送信、ストリーミング、放送制御オペレーターなどの異なる役割が重要です。ハイプロファイルのイベントの場合、専用の「ビッグベット」モデルが提供され、専用のリソースが割り当てられます。ライブコマンドセンター（LCC）は、全ライブストリーミングパイプラインを監視し、リアルタイムのデータをオペレーターに提供します。LCCは、カスタムの観測可能性スタックを使用して大量のデータを管理し、問題に対応します。LCCオペレーションリードとテクニカルランチマネージャーは、インシデント対応を担当しています。

Netflixは、膨大なコンテンツライブラリのスニペット選択プロセスを改善することを目指しています。 何千ものタイトルがユーザーの選択を複雑にし、スニペットが意思決定において重要になります。 質の高いスニペットはユーザーエンゲージメントを高めますが、質の低いスニペットはフラストレーションと離脱につながります。 課題は、数十万ものスニペットにわたる品質検証をスケーリングすることにあります。 Netflixは、4つの主要な次元でスニペットの品質を評価するために、LLMベースのアプローチを開発しました。 このシステムは、クリエイティブライターとの間で85%以上の合意を達成し、専門家主導の品質基準を保証します。 スニペットの品質は、ライターによって定義されるクリエイティブ品質と、ストリーミング指標を介したメンバーの暗黙のフィードバックの両方を通じて評価されます。 LLM-as-a-Judgeシステムは、精度を最適化するために、階層的な理由付け、コンセンサススコアリング、事実性エージェントなどの技術を採用しています。 これらのLLMから派生した品質スコアは、テイクフラクションや離脱率などの主要なストリーミング指標と相関しています。 これにより、Netflixはスニペットの問題を積極的に特定して修正し、メンバーエクスペリエンスとコンテンツ発見を改善することができます。

Netflixは、大規模なDruidクエリのパフォーマンスを向上させるために、実験的なキャッシュレイヤーを実装しました。このキャッシュシステムは、特に注目度の高いイベント中に、ダッシュボードからの冗長なクエリという問題を解決します。その中心的なアイデアは、結果の一部をキャッシュし、最新のデータのみをDruidに問い合わせることで、わずかな古さとのトレードオフを導入することです。指数関数的なTime-To-Live（TTL）値が使用され、遅れて到着するイベントに対応するために、古いデータほど長くキャッシュされます。キャッシュシステムは、キャッシュデータの効率的な範囲スキャンのために、マップ・オブ・マップ構造を使用しています。キャッシュはDruidルーターでリクエストを傍受し、必要に応じて結果を提供したり、Druidに問い合わせたりします。このソリューションは、キャッシュされたデータと最新のデータを組み合わせ、完全な結果を返し、最新のデータを非同期的にキャッシュします。空のバケットにはネガティブキャッシュが使用され、末尾の空のバケットをキャッシュしないように注意が払われています。このシステムは、NetflixのKey-Value Data Abstraction Layer（KVDAL）を使用しており、Cassandraをバックエンドとしています。Cassandraは、各データポイントに独立したTTLを提供します。このキャッシュレイヤーは、Druidクエリの負荷を大幅に削減し、特に大量のイベント中にクエリ時間を改善しました。このキャッシュシステムはまだ実験段階であり、今後の目標には、Druid自体への統合が含まれています。

この記事は、高度なビデオ検索エンジンの構築における課題と解決策について論じています。中心的な問題は、膨大な量のビデオ映像と、関連性の高い瞬間を抽出することの難しさです。解決策は、ビデオコンテンツのさまざまな側面を分析するために、さまざまなAIモデルを統合するマルチモーダルアプローチを採用することです。このアプローチでは、専門モデルからの多様なデータを、統一されたリアルタイムインテリジェンスシステムに統合する必要があります。システムのアーキテクチャは、大規模な処理に焦点を当て、数十億のデータポイントを効率的に処理します。トランザクション永続化、オフラインデータ融合、リアルタイム検索のためのインデックス作成を含む3段階のプロセスにより、データの整合性と応答性が確保されます。このプロセスでは、取り込みプロセス中のボトルネックを回避するために、分離されたパイプラインを使用します。検索サービスは、クエリの前処理、セマンティック検索のファインチューニング、および正確な結果を得るための高度なテキスト分析などの機能を提供します。また、検索精度を向上させるために、フレーズマッチング、Nグラム分析、あいまいマッチングも含まれています。システムは、よりニュアンスのある検索を可能にするために、集計と柔軟なグループ化を提供します。全体として、映画製作者が関連性の高いビデオコンテンツを発見するための強力なツールを提供することで、映画製作者に力を与えることを目指しています。

Netflixは、効率向上のため、ライブイベントのエンコーディングを定数ビットレート（CBR）から可変ビットレート（VBR）に移行しました。VBRは、シーンの複雑さに応じてビットレートを動的に調整し、平均トラフィックの削減と視聴体験の向上を実現します。VBRの大きな課題は、トラフィックの予測可能性の低さであり、ビットレートの大きな変動により、サーバーの過負荷や不安定化につながる可能性があります。この問題に対処するため、Netflixは、公称ビットレートに基づいた新しい容量予約システムを実装し、VBRの可変性に関連するリスクを軽減しました。また、VMAFを指標として、ストリーミングラダー全体の公称ビットレートをCBRストリームの品質に合わせる調整を行いました。VBRへの移行により、バッファリングの減少や初期起動遅延の短縮といった効率化が実現しました。Netflixは現在、VBRをさらに最適化するために、適応ビットレートアルゴリズムと容量予約の改善に取り組んでいます。VBRの実装は、複数のチームと貢献者が関わった、全社的なプロジェクトでした。

3年前、Netflixは、テレビ放送とほぼ同じくらい歴史の古いフォーマットであるライブストリーミングを通じて世界を楽しませる方法を模索しました。この問いから、コメディショー、スポーツ、WWEイベントなど、何百ものライブイベントが開発されました。Netflixは「Behind the Streams」と題したシリーズで、ライブストリーミング機能構築の技術的な道のりを共有します。ライブストリーミングは、アーキテクチャや技術選定における新たな考慮事項をもたらし、Netflixでうまく機能させるためには、かなりの構築が必要でした。Netflixのライブアーキテクチャの主要な柱には、専用の放送施設、クラウドベースの冗長なトランスコーディングおよびパッケージングパイプライン、ライブコンテンツ配信のスケーリング、ライブ再生の最適化、そしてクラウドでのディスカバリおよび再生制御サービスの実行が含まれます。Netflixはまた、クラウド上でリアルタイムメトリクスを一元化し、専門的なツールと施設を活用しました。ライブ機能の構築は、新たな課題と学習の機会をもたらし、Netflixは現在も日々、ライブイベントをより効果的に配信する方法を学んでいます。これまでの主な学習成果としては、徹底的なテスト、定期的な練習、視聴者予測、段階的な機能低下、そしてリトライストームの重要性が挙げられます。Netflixは堅牢なライブストリーミングシステムの構築において大きな進歩を遂げましたが、学ぶべきこと、改善すべきことはまだ多くあります。

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のOpen Connectプログラムは、インターネットサービスプロバイダー（ISP）とのパートナーシップを通じてコンテンツ配信をローカライズすることで、会員に最高の品質の体験（QoE）を提供することを目的としたコンテンツ配信ネットワーク（CDN）です。このプログラムでは、効率性とコスト効率を考慮して設計されたカスタムビルドのサーバーであるOpen Connectアプライアンス（OCA）を使用します。Open Connectの効率性を評価するために、Netflixは、特にキャッシュミス（キャッシュミスとは、クライアントの最適なOCAからバイトが提供されない場合に発生する）を特定するフレームワークを使用しています。キャッシュミスは、3つのカテゴリに分類されます。コンテンツミス（コンテンツミスとは、ローカルサイトのOCAにファイルが見つからない場合）、ヘルスミス（ヘルスミスとは、ローカルサイトのOCAハードウェアリソースが飽和している場合）、その他のミスです。Netflixは、キャッシュミスを計算するために、2つの重要なデータコンポーネントをログに記録しています。プレイバックマニフェストログとOCAサーバーログです。これらのログは、さまざまな集約レベルでの詳細なキャッシュミスメトリックを計算するために結合されます。キャッシュミスを計算するシステムアーキテクチャには、ログの発信、ログの統合、ログの強化、ストリーミングウィンドウベースの結合が含まれます。キャッシュミスを評価するために使用されるデータモデルでは、ロジックをオフラインで再生し、シミュレーションで可変パラメータを使用して、新しい条件や機能をテストできます。

Netflixは、映画の芸術的インテグリティを保持しながらデータ効率を最適化するAV1 Film Grain Synthesis（FGS）ストリームを導入しました。映画のグレインは、映画の物語に深みとリアリズムを追加する重要な要素ですが、伝統的なアルゴリズムでは圧縮するのが困難です。AV1 FGSツールは、映画のグレインを2つのコンポーネントに分割してモデル化しています。すなわち、映画のグレインのパターンと映画のグレインの強度です。映画のグレインのパターンは、自己回帰モデルを使用して複製され、映画のグレインの強度はスケーリング関数によって制御されます。エンコーディングプロセスでは、ビデオから映画のグレインを除去し、圧縮し、圧縮されたビデオデータと一緒にグレインのパターンと強度を送信します。再生中、ブロックベースの方法を使用して映画のグレインが再作成され、ビデオに再統合されます。AV1 FGSの有効化により、ビットレートの削減が達成され、高品質のビデオストリーミングが少ないデータで実現可能になりました。また、視覚的な品質も向上し、合成ノイズが圧縮アーティファクトを効果的にマスクしています。Netflixは、プラットフォーム全体でFGSを展開し、サポートデバイス上でFGS対応ストリームを利用できるようになりました。展開により、Netflixメンバーのためのよりスムーズで信頼性の高いQuality of Experienceが実現され、ビットレートが低下し、再生エラーが減少し、再生の安定性が向上しました。

Netflixの提供が増えるにつれて、サポートするシステムの複雑化も進み、重複や不一致のモデル、用語の不一致、データ品質の問題、データ間の関係の不一致などが生じます。これらの課題に対処するために、新しい基盤が必要になりました。すなわち、モデルを一度定義し、どこでもその定義を再利用できるようにし、概念を実際のシステムに結びつけ、定義を外部に投影し、スキーマを生成し、システム全体での一貫性を強制する必要がありました。これにより、UDA（ユニファイド・データ・アーキテクチャー）が開発されました。UDAでは、ドメインをモデル化することが一度でき、システム全体で一貫して表現することができます。これにより、自動化、発見可能性、セマンティック・インターオペラビリティーを実現します。UDAでは、ユーザーとシステムがドメイン・モデルを登録し、ドメイン・モデルをデータ・コンテナーにマッピングし、ドメイン・モデルをスキーマ定義言語にコンパイルし、データを忠実にデータ・コンテナー間で移動し、ドメイン・コンセプトを発見し探索し、知識グラフをプログラム的に内省することができます。UDAは、ビジネス・コンセプトをスキーマやデータ・コンテナーに結びつける知識グラフであり、 Upper というインハウス・メタモデルに基づいています。Upper は、ドメインを形式的に記述する言語であり、UDAでのドメイン・モデリングに使用されます。UDA は、ネームド・グラフ・ファーストの情報モデルを採用し、グラフ全体での解決、モジュール性、ガバナンスを確保します。

レコメンダーシステムは、電子商取引、ストリーミングメディア、ソーシャルネットワークの不可欠なコンポーネントであり、製品やビジネスに大きな影響を与えている。Netflixでは、これらのシステムが適切なコンテンツをメンバーに提供する。レコメンデーション基盤モデルは、ユーザーの嗜好を理解するために大きな進歩を遂げているが、能力をさらに高める機会がある。基盤モデルを拡張して、潜在的なユーザーの意図を予測することで、モデルは次のアイテム予測を超えてユーザーセッションの理解を豊かにすることができる。最近の研究では、オンラインプラットフォームでのユーザーの意図を理解することが、より正確でパーソナライズされたレコメンデーションにつながることを強調している。FM-Intentという新しいレコメンデーションモデルは、短期的および長期的な暗黙のシグナルをプロキシとして、ユーザーの潜在的なセッション意図を捉え、次のアイテム予測を改善するためにこの意図予測を活用する。モデルは、意図予測と次のアイテム予測の間に階層的な関係を確立し、より一貫した効果的なレコメンデーションパイプラインを作成する。FM-Intentは、三つの主要な貢献を行う：新しいレコメンデーションモデル、階層的なマルチタスク学習アプローチ、および最新の状態にあるモデルとの比較実験による有意な改善を示す。FM-Intentは、Netflixのレコメンデーションエコシステムに成功的に統合されており、パーソナライズされたUI最適化、アナリティクス、および強化されたレコメンデーションシグナルなどの下流アプリケーションに活用することができる。

Netflixでは、広告キャンペーンを監視、測定、および最適化するためのイベント処理プラットフォームを構築しました。広告サーブシステムは、決定、頻度制限、ペース、パーソナライゼーションのための安定した広告イベントのストリームに依存しています。初期の広告イベントハンドリングシステムは3つの主要コンポーネントで構成されていました。Microsoft Ad Server、Netflix Ads Manager、およびAd Event Handler。システムは、インプレッション、頻度制限、および収益化プロセスに関するフィードバックループが効果的に機能することを保証するように設計されていました。ビジネスが拡大すると、新しい永続レイヤーがKey-Value抽象化を使用して導入されました。これにより、データボリュームの成長や第三者トラッキングURLの課題に対処することができます。イベント処理パイプラインはさらに進化し、自社の広告テクノロジーをサポートする機能を追加しました。これには、頻度制限、価格情報、およびロバストなレポートシステムが含まれます。中央化された広告イベントコレクションシステムが計画され、単一の統一データ契約を消費者に提供し、上流システムと消費者の間での心配を分離することを目的としています。新しいパイプラインは、測定、財務/請求、頻度制限、および広告サーバーへのフィードバックループの維持などの多くの機能をサポートしています。広告イベント処理システムの開発は、チームワーク、計画、および調整の協力による旅のjourneyを示しています。新しいシステムは、ビジネスに対する新しい機能の立ち上げを大幅に加速化し、プログラマティック・バイイング・キャパビリティーの共有、オプトアウト・シグナルの共有、および正確なレポートと測定を保証しています。

「Netflixは、技術パートナーとの協力により、メンバーの体験を向上させることを優先しています。この協力は、生産プロセス全体でダイアログの聴き取りやすさを改善することを目的としており、セットからスクリーンまでの問題を解消しています。主要なイニシアチブは、ダイアログ・インテグリティ・パイプラインであり、ノイズのある環境やオーディオ・ミキシングなどの要因が聴き取りやすさに影響を与えることを特定し、緩和しています。Netflixは、業界標準のラウドネス・メーターとeSTOIベースの測定システムを使用して、ダイアログの聴き取りやすさを分析しています。プリ・デリバリーの最適化を改善するために、Netflixは、フラウンホーファー IDMTとヌゲン・オーディオとパートナーになって、DialogCheckプラグインを作成しました。このプラグインは、デジタル・オーディオ・ワークステーション（DAWs）に統合されており、サウンド・エンジニアにリアルタイムのフィードバックを提供しています。この協力は、フラウンホーファーの機械学習ベースのスピーチ・インテリジェンス・ソリューションとヌゲン・オーディオのオーディオ・プラグインのエキスパートのノウハウを活用しています。DialogCheckプラグインは、ダイアログの聴き取りやすさの問題を早期に検出して解消することを可能にしており、アーティスティック・インテントが損なわれません。最終的な目標は、すべての視聴者に、どのようなリスニング環境でも没入感とアクセシブルなストーリーテリングを提供することです。この協力的なアプローチは、オーディオ・エクセレンスとストーリーテリングのイノベーションに対するNetflixのコミットメントを強調しています。

Netflixは、ネットワークの洞察を高めるために、大規模なTCPフロー ログをeBPFでキャプチャしています。しかし、フローIPアドレスをワークロードIDに正確に帰属させることは大きな課題でした。初期の帰属付けアプローチは、内部のIPアドレス追跡サービスであるSonarに依存していましたが、分散システムでの遅延や障害により誤った帰属付けが発生しました。誤った帰属付けにより、フロー データは意思決定に信頼できないものとなり、受信フローを15分間保持してから帰属付けするという回避策も問題を解決しませんでした。この問題を解決するために、Netflixは、新しい帰属付け方法を開発しました。この方法では、ローカルのIPアドレスをワークロードIDに帰属させるために、環境からローカルのワークロードIDを決定します。コンテナーワークロードの場合、Netflixは、コンテナIPアドレス割り当てサービスであるIPManを利用して、ローカルのIPアドレスを帰属させました。ローカルのIPアドレスが帰属付けられると、各ワークロードが特定のIPアドレスを所有する時間範囲を学習することで、リモートIPアドレスを帰属させることができます。FlowCollectorは、この知識を表すためにメモリ内ハッシュマップを維持し、Kafkaを使用して他のノードと学習した時間範囲を共有します。この新しい方法は、正確な帰属付けを実現し、一時的な問題に対して優雅に処理します。また、シンプルさとメモリ内検索によりコスト効率も高いです。この方法は、フローを対応するリージョンのノードに転送することで、リージョン間のIPアドレスを帰属させるように拡張されています。最後に、この方法は、Netflixのコンテンツ配信ネットワークに属するものなど、ワークロード以外のIPアドレスを帰属させるようにさらに拡張されています。

「映画産業がクラウドベースのワークフローに移行するにつれて、グローバルな実施に課題が生じています。Netflixは、映画製作者向けに設計されたMedia Production Suite（MPS）を通じて、これらの問題を解決しようとしています。MPSは、メディア管理をストリームライン化し、退屈なタスクを排除し、創造的なフォーカスを高めます。物理テープを使用した従来のワークフローは、遅くてcumbersomeであり、コラボレーションを阻害しています。デジタルワークフローも、配布や標準化の課題に直面しています。クラウドは、解決策を提供しますが、運用上の課題や技術的なハードルを克服する必要があります。Netflixは、これらの問題を、メディアに人々やアプリケーションを持ち込む代わりに、逆のアプローチで解決しています。MPSは、技術や標準化のグローバルな格差に取り組み、多様な市場のニーズを考慮しています。スイートは、業界標準に基づくカラーマネジメントやフレーミングなどのプロセスを自動化しています。インフラストラクチャーは、クラウドと物理的な能力を最適化し、ユーザーのパフォーマンスを向上させています。MPSには、インジェスト、メディアライブラリ、デイリーズ、リモートワークステーションなど、多くのツールが含まれています。350以上のタイトルがMPSのツールを使用しており、世界各地からのフィードバックを受けています。ブラジルのシリーズ「セナ」がMPSを採用し、地理的なバリアーを克服する能力を示しています。」

Netflixは、会員の好みを一元的に学習し、様々なレコメンデーションモデル全体の効率を向上させるための、レコメンデーション向け基盤モデルを開発しています。現在のシステムは、維持コストが高く、イノベーションの共有に苦労する特殊なモデルで構成されています。基盤モデルは、広範なユーザーインタラクション履歴とコンテンツデータから学習し、その学習内容を他のモデルに分配することを目指しています。大規模言語モデルに触発されたこのアプローチは、半教師あり学習を用いたデータ中心の戦略へと移行します。Netflixは、ユーザーインタラクションをトークン化し、データの粒度とシーケンス圧縮のバランスを取りながら、長期的なインタラクション履歴を処理します。スパースなアテンションメカニズムとスライディングウィンドウサンプリングを用いて、トレーニング中の計算効率を管理します。各トークンには、アクションとコンテンツに関する豊富な異種情報が含まれており、リクエスト時およびアクション後の特徴を利用します。このモデルは、GPTと同様の自己回帰的な次のトークン予測を目的としていますが、インタラクションの重要度のばらつきを考慮した修正が加えられています。モデルは複数のトークンを予測し、長期的な依存関係を捉え、精度を向上させるために補助的な予測目的を使用します。エンティティのコールドスタートに対処するため、このモデルはインクリメンタルトレーニングで構築されており、エンティティと入力のメタデータ情報を使用して、未見のエンティティでも推論できる能力を備えています。

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がすべてのメンバーに対して没入型でオーセンティックな視聴体験を提供するという決意を示しています。

Netflixでは、パーソナライゼーションとディスカバリースタック全体のサービスにわたって観測可能性エンドポイントを導入することで、包括的なタイトル観測可能性を実現しました。スタックに関与する各マイクロサービスは、タイトルヘルスエンドポイントを新しく導入し、生産環境の動作を正確に反映し、標準化し、インサイトトライアドに答えるという原則に従う必要がありました。インサイトトライアドでは、エンドポイントがタイトルがプロモーションの対象かどうか、対象でない場合はなぜ対象でないか、また問題を解決するために何ができるかを回答する必要があります。 観測可能性サービスとパーソナライゼーションスタックの観測可能性エンドポイント間の通信を標準化するために、安定したプロトコルリクエスト/レスポンス形式が開発されました。ソリューションの高レベルアーキテクチャには、観測可能性エンドポイントの確立、積極的な監視、リアルタイムのタイトルインプレッションの追跡、最適化されたデータストアへのデータの保存、およびダッシュボードのための簡単に統合できるAPIの提供が含まれます。 タイトルヘルスミクロサービスは、30分ごとにスケジュールされたコレクタージョブを実行して、割り当てられた行サービスから関連するタイトルヘルス情報を取得します。リアルタイムのタイトルインプレッションデータは、2分ごとにインプレッションデータを取得するためにポーリングされるKafkaキューから処理されます。データはその後集約され、ステークホルダーにとって追加のヘルスステータスインジケーターとして提示されます。 データは、各コレクターに専用のHollowフィードに保存され、読み取り専用の高パフォーマンスアクセスを可能にし、全体のヘルスとタイトルの履歴の追跡を可能にします。観測可能性ダッシュボードは、タイトルヘルスサービスを利用して、ステークホルダーにタイトルのステータスを提示し、システムには、問題がメンバーに影響を与える前にそれらをキャッチして修正するために、事前にトラフィックをシミュレートする「タイムトラベル」機能もあります。 システムのアーキテクチャと戦略により、Netflixはタイトルローンチの観測可能性を強化し、魅力的な視聴体験を提供し、コンテンツクリエイターとパートナーとの信頼を築くことができました。ソリューションはまた、将来の革新の基盤を提供し、すべてのストーリーが意図した対象者に届き、すべてのメンバーがNetflixでお気に入りのタイトルを楽しむことができるようにします。

Netflixでは、プラットフォーム上の画像は「インプレッション」と呼ばれ、ユーザーエクスペリエンスのパーソナライゼーションに重要な役割を果たします。インプレッションの取得と処理は、複雑なタスクであり、洗練されたシステムが必要です。このシステムは、毎日数十億のインプレッションを追跡して処理し、各プロファイルの露出の詳細な履歴を保持しています。このインプレッション履歴は、パーソナライゼーションの向上、頻度制限、新着リリースの強調表示、および分析的な洞察に不可欠です。インプレッションを管理する第一歩は、Source-of-Truth（SOT）データセットを作成することです。これは、さまざまなダウンストリームワークフローをサポートし、複数のユースケースを可能にします。生のインプレッションイベントはクライアント側から収集され、カスタムイベントエクストラクター、Apache Kafka、およびApache Icebergを介して処理されます。次に、データはApache Flinkを使用してフィルタリング、エンリッチメント、構造化され、Netflixのインプレッションデータの決定的な真実の源が確立されます。システムは、詳細なメトリクスを収集し、潜在的な問題についてチームに警告することで、高品質のインプレッションを保証します。アーキテクチャは、スケーラビリティ、柔軟性、および高可用性に焦点を当てて、インプレッションイベントの大容量をリアルタイムで処理するように設計されています。将来の作業には、スキーマ化されていないイベントの処理、パフォーマンスチューニングの自動化、およびデータ品質アラートの改善が含まれます。

Netflixでのタイトルのスムーズなリリースと発見性を確保するには、解決策に取り組む前に、より広い文脈を理解することが不可欠です。この思慮深いアプローチにより、将来のために回復力とスケーラビリティが構築されます。最初のステップは、利害関係者を特定し、現在の状況を把握し、コアの問題を明確にし、ビジネス優先順位を評価することです。タイトルリリースオペレーター、パーソナライゼーションシステムエンジニア、プロダクトマネージャー、クリエイティブ担当者が主な利害関係者です。 現在の状況を把握すると、タイトルリリースの可視性のための確立された解決策がなかったことがわかり、課題と機会が両方存在することが明らかになりました。コアの問題は、パーソナライゼーションスタックによってすべてのタイトルが公平に扱われることを保証することでした。これに対処するために、「タイトルヘルス」という共通の理解が導入され、発見性とメンバーのエンゲージメントの観点からタイトルのパフォーマンスを反映するさまざまなメトリックと指標が含まれました。 タイトルヘルスは、各タイトルのライフサイクルを監視および最適化するためのフレームワークを提供し、パートナーとの原則と要件の調整を可能にしました。タイトルリリースの可視性のための堅牢な計画を構築するために、問題は3つの主なカテゴリに分類されました。タイトル設定、パーソナライゼーションシステム、アルゴリズムです。問題をカテゴリ化することで、課題を体系的に解決し、各タイトルに対して信頼性の高いパーソナライズされた体験を提供できます。 問題分析により、設定問題は最も一般的ですが、最も簡単に修正できることがわかりましたが、アルゴリズム問題はまれですが、解決が難しいことがわかりました。オプションの評価により、最初に積極的な問題検出に焦点を当てることが決定され、リリース前に問題を捕捉してスムーズなリリース、メンバーの体験の向上、システムの信頼性の向上を確保しました。この決定により、複雑なプラットフォームの進化に合わせて成長できるスケーラブルで堅牢なシステムの基礎が築かれました。

この記事は、Netflixでのアナリティクス・エンジニアリングの多パート・シリーズの最後を締めくくるもので、技術的スキルに焦点を当てています。ダッシュボード・デザインのヒントを議論し、ユーザーのニーズを理解し、既存のパターンを活用する重要性を強調しています。また、ダッシュボードのデザインについても触れ、ユーザーのメンタル・モデルに合ったアプリケーションの構造化方法、ページ・レイアウト、インタラクティブ・チャート、およびオンボーディングのガイドラインを提供しています。さらに、Netflixでのアナリティクス・APIのデプロイメントでの学びを共有し、リアルタイム・結果の影響と必要性の測定、すべてのソリューションの探索、パフォーマンス・期待値の調整、徹底的なテストとコラボレーションの重要性などの主要なポイントを強調しています。

Netflixの分析エンジニアリングチームは、Netflixゲームのユーザー獲得キャンペーンの効果を測定するゲーム分析を含むさまざまなプロジェクトに取り組んでいます。このチームは、対照シナリオを推定するために合成コントロールフレームワークを使用し、インクリメンタル結果に関する洞察を提供するためのインタラクティブツールを開発しました。また、将来のキャンペーンの設計と予算化を導くインクリメンタル投資収益率モデルにも取り組んでいます。さらに、チームは、インクリメンタルアカウントライフタイムバリューションなどの他のフレームワークを活用してインクリメンタルサインアップを推定するアプローチを使用して、Netflixゲームのインクリメンタルサインアップを測定および検証することに重点を置いています。Netflixゲームのプレイヤージャーニーは、日次の状態遷移確率を示す状態マシンを使用してモデル化されており、エンゲージメント目標への進捗状況を評価し、月間アクティブアカウントを増やすための改善点を特定するのに役立ちます。この記事では、Netflixが「未定」のスロットのキャッシュニーズを予測するために、タイトルの発売日までおよびその後までの日次キャッシュ支出をモデル化するコンテンツキャッシュモデリングについても説明しています。最後に、チームは、多層構造の測定フレームワークを使用してそのパフォーマンスを評価するアシスタンススピーチ認識技術を使用して、吹き替えワークフローのトランスクリプションプロセスの効率を向上させることに取り組んでいます。

Netflixのチームは、Metaflowを使用して効率的にML/AIプロジェクトを開発および管理できます。Configsは、Metaflowの新機能であり、ユーザーが人間が読みやすい設定ファイルでフロー パラメータ、リソース要件、およびアプリケーション固有の設定を定義できるようにすることで、設定可能なフローを実現します。Configsは、既存のMetaflowアーティファクトとパラメータを拡張し、より柔軟性とカスタマイズ オプションを提供します。リモート実行や本番環境でのデプロイ時でも、動的に読み込まれ、変更できます。Configsは、固定デプロイとランタイム設定の組み合わせ、設定の検証、設定ファイルの階層の管理、設定の動的生成などの高度なユースケースを実現します。Hydraなどの設定マネージャーと組み合わせて使用すると、複数の設定をまたぐ実験のオーケストレーションやパラメータ空間のスイープが可能になります。Netflixの内部ツールであるMetaboostは、実践でConfigsを使用する例であり、異なるプラットフォームのMLプロジェクトを単一のインターフェイスで管理し、プロジェクトの整合性を高め、リスクを軽減します。

Netflix のアナリティクス エンジニアリング チームは、会社全体で高品質で実用的なインサイトを効果的に作成して提供できるように、会社の機能を強化することに取り組んでいます。最近では、DataJunction、LORE、基礎プラットフォーム データを活用したクラウド効率アナリティクスの有効化など、さまざまなトピックを取り上げた年次内部 Analytics Engineering カンファレンスを開催しました。DataJunction は、指標定義を標準化してアクセスできるようにするオープンソース ソリューションです。一方、LORE は LLM を使用してエンドユーザーに実用的なインサイトを提供するチャットボットです。チームは、アナリティクス プラクティショナーが Netflix で高品質のインサイトを効果的に作成して提供できるようにすることを目的としたアナリティクス有効化などの取り組みを通じて、アナリティクスの民主化にも注力しています。チームの目標は、エンジニアリング組織が 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を使用して使用を最適化し、コストの異常を検出するなどの予防的なアプローチに移行する予定です。

Netflixでは、毎月1000を超えるグローバルコンテンツの配信を管理することが最優先事項であり、包括的な可観測性を実現する堅牢なシステムが必要です。同社は、あらゆるストーリーを適切な視聴者につなげることを目指していますが、エラー率やCPU使用率などの従来のシステムメトリクスでは、タイトルの成功のニュアンスを捉えることはできません。このギャップを埋めるため、Netflixはこれらのニュアンスを認識し、すべてのタイトルが際立つようにするシステムを設計する必要があります。 Netflixオリジナルの初期段階では、配信チームがタイトルの配置を手作業で確認していましたが、このアプローチは同社のグローバル展開に合わせて拡張することはできませんでした。その結果、Netflixはタイトルのパフォーマンスと発見に関する複雑なクエリに正確かつタイムリーに回答するという運用上の課題に直面しました。同社は、すべてのタイトルを完璧に配信し、メタデータとアセットを正しく設定し、データをシームレスに流し、アルゴリズムを意図したとおりに機能させるための拡張可能なソリューションを必要としていました。 これらの課題に対処するため、Netflixはパーソナライズシステムでのログ処理とオブザーバビリティエンドポイントの2つのオプションを検討しました。ログ処理はタイトルの発売を監視して分析するための簡単なソリューションを提供しますが、問題を事前に検出して正確性を確保するなどの制限があります。一方、可観測性エンドポイントは、リアルタイムの監視、問題の予防的検出、精度の向上を提供しますが、かなりの初期投資と同期作業が必要です。 最終的に、Netflixはリアルタイムモニタリング、問題の予防検出、真実のソースの照合を含む包括的なオブザーバビリティ戦略を採用しました。このアプローチにより、同社はプラットフォーム全体でタイトルの成功した発売と発見を確実に実行できる能力が大幅に向上しました。このシリーズの次の部分で、Netflixはこれを実現する方法に関する重要な技術的洞察と詳細を共有します。

Netflixの分散カウンタ・アブストラクションは、低ミリ秒レイテンシーの大容量の時系列イベント・データを格納およびクエリーするためのサービスです。このサービスは、2つの主要なユース・ケース・カテゴリをサポートしています。Best-EffortとEventual Consistency。Best-Effort・カウンタは、単一リージョン内の高スループットと低レイテンシーをEVCacheを使用して実現しますが、クロス・リージョン・レプリケーションと一貫性の保証がありません。一方、Eventual Consistency・カウンタは、アパッチ・カフカのような耐久的なキューイング・システムを使用して正確で耐久的なカウントを実現しますが、パーティションのリバランスに伴う遅延や課題が生じる可能性があります。Netflixのアプローチは、各カウント・アクティビティをイベントとしてログに記録し、これらのイベントを継続的に集計することで、監査や再カウントの要件を満たします。

あるユーザーが、特定のノートブックを実行する際に、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プロセスを作成します。この不一致が親プロセスを遅くする原因です。

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で時間データ管理のための汎用的でコスト効率の高いソリューションを提供します。

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のグローバルオペレーションに必要とされる信頼性とパフォーマンスに貢献します。

Pushyは、NetflixのWebSocketサーバーで、Netflixアプリが動作するデバイスとの永続的な接続を維持しています。メッセージ配信サービスの進化から、Netflixのエコシステムの不可欠な部分となった。Pushyは、数億の同時WebSocket接続を処理し、1秒あたり数十万のメッセージを配信し、メッセージ配信の信頼性が99.999%です。FireTVs向けに初めて開発されたが、Pushyの範囲は、携帯デバイスや能力が限られた古いデバイスを含む、ほぼ10億のデバイスにまで広がりました。この成長に対応するために、Pushyは、Netflixの舗道コンポーネントを使用してメッセージプロセッサーを書き直し、パフォーマンスとスケーラビリティの向上のためにPushレジストリーをKeyValueに移行し、接続数に基づく指数関数的なスケーリングポリシーを実装しました。これらの改善により、Pushyはより信頼性が高く、安定し、効率的に、デバイスの増加と新機能の要件に対応することができます。

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コードのオーバーヘッドを測定するために使用されました。

Netflixは、会員の長期的な満足度を高めることを目的として、パーソナライゼーションアルゴリズムを使用してコンテンツを会員に推薦します。この推薦は、会員のフィードバックに基づいてシステムがアクションを選択する文脈的なバンディット問題と捉えられます。従来のレコメンダーシステムは、クリック数などの短期的なメトリクスを最適化するが、長期的な満足度を完全に捉えることができない場合があります。長期的な会員の満足度にのみ最適化することは、問題があります。Netflixは、長期的な会員の満足度と一致するプロキシ報酬関数を使用します。クリックスルー率（CTR）は、単純なプロキシ報酬ですが、Netflixは、CTRを超える多くのユーザーアクションとそれらが満足度に与える影響を考慮します。報酬エンジニアリングは、長期的な会員の満足度と一致するプロキシ報酬関数を改良する反復的なプロセスです。このプロセスには、仮説の形成、報酬の定義、バンディットポリシーのトレーニング、A/Bテストが含まれます。Netflixは、遅延フィードバックの問題に対処するために、欠けているフィードバックを予測し、プロキシ報酬関数にすべてのフィードバックを使用します。オフラインモデル改善にもかかわらず、オンラインオフラインメトリクス不一致が、プロキシ報酬が長期的な会員の満足度と完全に一致しない場合に生じます。Netflixは、プロキシ報酬関数の定義をさらに改良することでこれを解決します。まだ解決が必要な問題として、プロキシ報酬関数の自動学習、遅延フィードバックの最適な待ち時間の決定、長期的な満足度との一致のための強化学習の活用があります。

Netflixの研究者が、歴史的な実験を使用して、短期的な代理メトリックと長期的な北極星メトリックの関係を確立する方法を提示します。単純なアプローチでこの関係を理解することは、混同因子と相関する測定誤差のために誤解を招く可能性があります。Total Covariance (TC) 估算器は、OLS傾斜を計算するために、測定誤差の共分散を除去します。Jackknife Instrumental Variables Estimation (JIVE) は、各観察のデータを、観察の代理サロゲート値の計算から除去することで、相関する測定誤差を除去します。Limited Information Maximum Likelihood (LIML) 估算器は、処置と北極星メトリックの間に直接的な影響が無いと仮定する状況下で、統計的に効率的です。これらの方法は、北極星に向かっての調整と協調を容易にする、線形的な構造モデルを生成します。これらは、メトリックのトレードオフの管理、メトリックのイノベーション、独立したチーム作業を可能にします。現在のデータアーキテクチャーの課題にもかかわらず、これらの方法はNetflixで成功裏に実装されており、代理メトリックの開発に積極的に使用されています。研究者は、より柔軟なデータアーキテクチャーがこれらの方法の適用を簡単にする必要があると認め、潜在的な貢献者を、オープンジョブポストイングスを通じて歓迎します。

Netflixは、Amazon AWS上の複数のリージョンで広範囲なクラウドインフラストラクチャーを運営し、内容のスムーズな配信を可能にしています。あるアプリケーションがリージョン間のデータ同期問題を経験した際、タイムアウトが原因でネットワークが疑われた。 調査の結果、ネットワークエンジニアは、クライアントが生成するTCP RSTパケットを発見し、クライアントが接続を早期に終了させていることを示しました。 パケットキャプチャーは、サーバーが継続的にデータを送信し、クライアントが30秒後に接続を終了させていることを確認しました。 アプリケーションの調査で、サーバーから初期データを受信するための30秒のタイムアウトがあり、データがこの時間枠内に受信されなかった場合、接続を終了させていたことがわかりました。 アプリケーションやサーバーに最近の変更がなかったにもかかわらず、この問題はLinuxカーネルが6.5.13から6.6.10にアップグレードされた時期と一致していました。 メソディカルなカーネルバイセクションで、問題の原因となったコミットを特定し、新しいTCP受信ウィンドウサイズ計算メカニズムが導入されたことを発見しました。 元の計算では50%のオーバーヘッドを仮定していたが、新しいメカニズムは実際のデータ特性に基づいてオーバーヘッドを動的に計算し、結果的に受信ウィンドウサイズが小さくなりました。 この小さいウィンドウサイズでは、アプリケーションが30秒のタイムアウト内でデータを受信することができず、接続が終了する結果となった。 根本的な原因は、古いsysctl_tcp_adv_win_scaleパラメーターの置き換えで、より正確なスケーリング比率が受信ウィンドウサイズの計算に使用されるようになったためです。 カーネルアップグレードのロールバックで、アプリケーションの正常な運営が復元し、カーネル変更が問題の根本的な原因であることを示しました。

Netflixは、Javaの広範囲な使用で知られており、仮想スレッドのパフォーマンス上の利点に熱心でした。 しかし、Java 21に移行する過程で、SpringBoot 3と組み込みTomcatを使用するアプリケーションで仮想スレッドを使用する際、断続的なタイムアウトと応答しないインスタンスが発生しました。 調査で、closeWait状態のソケットが増加し、アプリケーションが接続を閉じることに失敗していることが明らかになりました。 スレッドダンプは、最初はアイドル状態のJVMを示しましたが、特定のコマンドを使用したさらなる分析で、多くの「白紙」仮想スレッドが存在することがわかりました。これは、仮想スレッドの実行に関する問題を示し、Tomcatが各入力リクエストに対して新しい仮想スレッドを作成し、基礎となるオペレーティングシステムスレッドがすべて占有されていることを示しました。 スレッドダンプのより深い分析で、オペレーティングシステムスレッドが、コード内の同期ブロックでロックを待ち合わせている仮想スレッドにピン留められていることがわかりました。 これが、レギュラープラットフォームスレッドがウェイト操作を完了した後、ロックを再取得できなかったデッドロック状況を引き起こし、観察されたパフォーマンス問題を生じさせました。

Maestroは、Netflixが開発したオープンソースのワークフロー・オーケストレーターです。大規模なデータ・パイプラインと機械学習ワークフロー向けに設計されています。Maestroは、acyclicとcyclicの両ワークフローをサポートし、foreachループ、サブワークフロー、条件分岐のような再利用可能なパターンも含みます。Maestroは、水平方向のスケーラビリティを提供し、単一のワークフロー内で大きな数のワークフローとジョブを管理できます。Maestroは、JSON形式の柔軟なワークフロー定義フォーマットを提供し、ユーザーが提供するフィールドとMaestroが管理するフィールドを組み合わせています。Maestroのワークフロー実行戦略には、sequential、strict sequential、first-only、last-only、並列実行（同時実行制限あり）があります。Maestroのパラメータと式言語サポートでは、動的なパラメータ、コード・インジェクション、ワークフローとステップ間での状態共有が可能です。また、callable stepの実行結果パラメータとパラメータ化されたワークフローも提供し、柔軟性と管理のしやすさを向上させています。Maestroは、foreachサポート、サブワークフロー、条件分岐のような一般的なビルディング・ブロックも含み、データフローと他のワークフロー・パターンの定義を簡単にしています。

Netflixは、ユーザー体験とシステムの耐久性を向上させるために、サービスレベルの負荷シェディング技術を導入しました。この技術は、同じサービスの非クリティカルなプリフェッチリクエストよりもクリティカルなユーザーが開始したリクエストを優先します。PlayAPIというクリティカルなバックエンドサービスのConcurrency Limiterでパーティション分割を実装することで、100%のスループットをクリティカルなリクエストに割り当て、余剰の容量を非クリティカルなリクエストに使用します。この優先付けにより、トラフィックのピークや高レイテンシーの状況下でもユーザーが開始したリクエストが高可用性を維持できます。このアプローチの成功が、サービスの優先順位を定義するための汎用的なライブラリの開発につながりました。このライブラリは、CPUの使用率をシステムの負荷の尺度として使用し、ユーザー体験を維持し、自動スケーリングの時間を提供するために、低優先度のトラフィックを段階的にシェディングします。実験結果によると、このアプローチは、過剰な負荷条件下で非クリティカルかつクリティカルなトラフィックを効果的にシェディングし、合理的なレイテンシと安定したスループットを維持します。Netflixは、ユーザー体験を悪化させたり、システムの不安定さを招く「no shedding」や「congestive fail」などのアンチパターンを避けることが重要であると強調しています。

2024年、Netflixで開催されたData Engineering Open Forumは、データエンジニアリングの課題に対する洞察とソリューションを共有するための専門家が集まった。Max Schmeiserは、データ駆動型の意思決定においてデータエンジニアリングの重要性を強調した。Stephanie Vezich TamayoとBinbing Houは、Netflixのデータプラットフォーム上でのジョブ失敗に対するMLパワードの自動修復システムを発表した。Jide Ogunjobiは、企業のデータモデリングとアーキテクチャーにジェネレーティブAIを使用することを話し合った。Tulika Bhattは、Netflixが日々18億のインプレッションを管理するためにリアルタイムの適応的なレコメンデーションを提供する方法を共有した。Jessica Larsonは、GDPR以降の時代におけるデータプラットフォームの作成に関する考慮事項を話し合った。Jason Reidは、データウェアハウスのバンドル化とアンバンドル化の利点と欠点を探検した。Clark Wrightは、Airbnbがデータ品質を維持するために採用するData Quality Scoreのアプローチを共有した。Iaroslav Zeigermanは、データパイプラインの管理においてSQLMeshの利点を強調した。このイベントは、Chris Colburn、Xinran Waibel、Jai Balani、Rashmi Shamprasad、Patricia Hoによって組織された。

Video Annotator (VA) は、ビデオ分類器のトレーニングに関する課題に対処するフレームワークです。VA は、ビジョン言語モデルとアクティブラーニングを使用し、ドメインエキスパートがプロセスを導くことができます。 VA は、3つのステップで構成されています：テキスト・トゥ・ビデオ・サーチを使用して初期の例を探し、ヒューマン・イン・ザ・ループ・システムを使用してアクティブラーニングとアノテーションの改善を行い、反復的にアノテーションをレビューし改善します。 VA は、サンプル効率を向上させ、コストを削減し、モデル品質を改善します。ドメインエキスパートがアノテーションプロセスに直接関与することを可能にし、信頼と所有権を育む。 VA のアクティブラーニングは、ユーザーが徐々に困難な例に焦点を当てることを許し、アノテーション時間を短縮し、モデル性能を向上させます。 VA は、継続的なアノテーションをサポートし、急速なデプロイメント、監視、およびエッジケースの訂正を可能にします。VA は、ユーザーがデータ・サイエンティストやサードパーティのアノテーターや頼らずにモデルを改善し反復することを可能にします。 実験結果は、VA が従来の分類器トレーニング技術と比較して、より高品質のビデオ分類器を生成することを示しています。 VA は、多様なビデオ理解タスクの効率的なアノテーションを可能にし、ドメインエキスパートと機械学習エンジニアの協力関係を促進します。 著者は、VA を使用してアノテーションされた 56 タスクの 153k ラベルが含まれるデータセットを提供し、レプリケーションのためのコードもリリースします。 VA は、従来の分類器トレーニング技術の課題に対処し、ビデオアノテーションの効率、品質、ユーザー関与を向上させます。VA は、システムに対する信頼と所有権を育むことで、正確なビデオ分類器の急速なデプロイメントと反復的な改善を促進します。

Netflixで因果推論は、意思決定とメンバーの体験向上の両方において非常に重要です。年次の因果推論と実験サミットは、メソドロジーの開発と革新的な適用を共有する専門家たちが集まる会議です。 一つの話は、A/Bテストからの年次化された影響をより速く自動的に推定するアプローチの開発に焦点を当てました。このアプローチは、観察されていない請求期間と、新規登録コーホートの両方に関する課題に対処します。 別の話は、ゲームイベントの評価に関する包括的なフレームワークを提示しました。このフレームワークは、A/Bテストが実際的でない状況での介入シナリオや、データが限られている状況での合成コントロールモデルを扱います。 ダブルマシンラーニングは、A/Bテストでの異なるメトリックの重要性を比較するために適用されました。このアプローチは、治療効果が異なる場合の潜在的なバイアスを解決します。 アンケートA/Bテストにおける異なる非応答バイアスは、条件付き平均治療効果、傾向スコア、反復的な比例フィッティングを使用して分析されました。これにより、メンバーの意見を正確に表現することができます。 デザインは、Netflixでの因果推論の不可欠な部分として強調されました。特に、実験を通じて意思決定を促進するために、ユーザーインターフェースとデータプレゼンテーションの最適化に焦点が当てられました。

Netflixの新しいビデオ処理プラットフォーム、Cosmosは、マイクロサービスを使用してメディア処理パイプラインを近代化します。ビデオエンコーディングサービス（VES）は、メザニンコンテンツをストリーミングやスタジオでの使用に適したビデオストリームにエンコードする主要なマイクロサービスです。 VESは、複数のコーデック、解像度、品質レベルをサポートし、低遅延のためにチャンクされたエンコーディングを使用します。外部ユーザーに対する安定したインターフェースを提供するAPIレイヤー、Optimusがあります。 ワークフローレイヤー、Platoは、有向非巡回グラフ（DAG）とMapReduce並列性を使用してエンコーディングの手順を調整します。リソースが多く必要なタスクは、Stratumレイヤーに委ねられます。Stratumレイヤーは、Dockerイメージにパッケージ化されたStratum Functionsを使用します。 VESは、異なるコーデック形式に対応する複数のStratum Functionsを使用し、独立したリリースとエンコーダーアップグレードを可能にします。プラットフォームは、メディアアクセスパターンの抽象化を提供し、Stratum Functionのコードを簡素化します。 リソースの要件は、ベンチマークテストを通じて決定され、「コンテナーシェイピング」がコーデック形式と解像度に基づいてリソースを割り当てます。自動化されたリリースパイプラインと広範囲なテストを通じて、継続的なリリースが可能です。 生産メトリクスとログは、監視とアラートのために使用され、メトリクスが大幅に逸脱した場合、自動的にサービスをロールバックします。VESの構築から学びられた教訓は、チームのマイクロサービスの開発における後のデザイン選択に導いています。

NetflixのGraph Search（以前はStudio Searchと呼ばれていた）は、コンテンツ・エンジニアリングの範囲を超えて、エンジニアリング組織全体で展開された。この技術は、100以上のアプリケーションと50以上のインデックスをサポートしている。映画の状況が変わったとき誰に通知すべきかを知るという課題に対処するために、Graph SearchはElasticsearchのpercolatorフィールドを使用した逆検索を導入した。 逆検索では、既存のインデックス上でフィルタをかける「SavedSearches」を作成できる。これらのフィルタはElasticsearchのクエリーに翻訳され、percolatorフィールドにインデックスされる。ドキュメントが提出されたとき、既存のクエリーと照合し、ドキュメントが返されるものを特定する。 この機能は、状況変更イベントに基づく正確な通知を可能にし、フェデレーテッド・グラフに対する影響を最小限度に抑える。逆検索をサポートするために、Graph Searchのインデックス・パイプラインは、保存された検索のインデックス用の別のパイプラインを含むように変更された。インデックスのマッピングは、インデックス・テンプレートを使用して揃えられている。 percolateインデックス・パイプラインは、Data Mesh CDCイベントとGraph Search DGSミューテーションを使用して、保存された検索を翻訳しインデックス化する。バージョン管理は、新しいインデックス・バージョンとパイプラインを作成することで行われ、既存のパイプラインを中断することなくマッピングの変更が可能になっている。 逆検索は、通知のためのものだけでなく、動的な基準・マッチャーを作成することもできる。Movie Matchingサービスは、逆検索を使用して、映画を基準に基づいて分類する。このパターンは、Graph Searchのどのインデックスにも拡張できる。 さらに、逆検索は、インデックスの変更に基づいて結果を更新するサブスクリプションを可能にするUIの作成の基礎を提供する。