はじめに：MLの規模拡大がもたらす「接続」の問題

Netflixはパーソナライズレコメンデーションから始まった機械学習(ML)を、現在ではスタジオ、決済、広告など全ビジネス領域に拡大しています。各ドメインは独自の技術スタックと組織構造で運用されており、MLモデルとデータが「サイロ」に閉じ込められる問題が発生しました。

例えば、スタジオチームが作成したコンテンツ埋め込み(シーンチェンジ検出、視覚的トランジションなど)は、広告のコンテキストマッチングやパーソナライズレコメンデーションにも活用できるはずですが、それを発見・接続するインフラがありませんでした。モデルレジストリ、パイプラインオーケストレーター、実験プラットフォームがそれぞれ独立して動作しており、ML実践者は以下のような基本的な質問に答えるために複数のシステムを行き来する必要がありました。

  • 発見(Discovery): どの特徴量が存在し、どのデータソースが利用可能か？
  • 系統(Lineage): このモデルのデータを生成したパイプラインは何か？
  • 影響度(Impact): このモデルを使用しているA/Bテストは？この特徴量を変更するとどのモデルに影響するか？

この問題の本質は、単にUIを統合することではなく、異種メタデータをひとつの接続されたグラフに変換する技術的挑戦でした。

Netflix ML lifecycle graph metadata service connecting models pipelines and experiments Developer Related Image

核心的解決策：Metadata Service(MDS)とModel Lifecycle Graph

Netflixは Metadata Service (MDS) という中央システムを構築しました。MDSは多様なソースシステム(Kafka、AWS SNS/SQS)からイベントをリアルタイムで収集し、正規化(Normalization)して統一エンティティモデルに変換した後、知識強化(Knowledge Enrichment) プロセスを通じてエンティティ間の関係を推論し、グラフを形成します。

主要な抽象化概念

  • Component: AIP URI(例: aip://model/registry/ranking-v5)で一意に識別可能なオブジェクト
  • Entity: MLエコシステム内の具体的な資産(モデル、特徴量、パイプラインなど)
  • Entity Type: 同じデータ構造を共有するエンティティのグループ
  • Domain: 関連エンティティタイプの機能グループ (例: Models Domain)
  • Provider: 特定のソースシステムに基づくDomainの実装

グラフ形成プロセス (5ステップ)

  1. イベント収集: ソースシステムが'thin event'を発行 (例: model_instance_created)
  2. エンティティ補完(Hydration): MDSがソースシステムのAPIを呼び出し最新状態を取得
  3. データ変換・正規化: 各システムのスキーマを統一エンティティモデルに変換 (例: owner_emails -> owners with AIP URI)
  4. 保存・インデックス: Datomic(グラフ+キャッシュ)とElasticsearch(検索)に同時保存
  5. 知識強化・グラフ形成: バックグラウンドジョブがエンティティ間の関係を推論しエッジを作成

例：モデルとA/Bテストの接続

  1. モデルインスタンスが pipeline_run_id を参照
  2. 強化ジョブがパイプラインを照会しA/Bテストセル情報を発見
  3. 実験プラットフォームでテスト詳細情報を照会
  4. 最終的にモデル -> パイプライン -> A/Bテストセル -> A/Bテスト間の関係をグラフに追加

このプロセスにより、MDSは単なるデータ収集器を超えて 新しい知識を推論するシステム として動作します。以下は、この接続を活用したGraphQLクエリの例です。

# Netflix AIP Portalでモデルの系統と影響度を探索するクエリ例
query {
  model(id: "aip://model/registry/ranking-model-v5-20XX0101") {
    name
    owners { name }
    currentInstance {
      version
      pipeline {
        name
        owners { name }
      }
      features {
        edges {
          node {
            name
            data { edges { node { name } } }
          }
        }
      }
      associatedAbTests {
        name
        cells { number name }
      }
    }
  }
}

このクエリひとつで、モデルの所有者、パイプライン、特徴量、データソース、関連するA/Bテストまですべてを取得できます。以前は各システムを個別に呼び出す必要がありました。

Cloud infrastructure diagram of Netflix ML metadata ingestion and entity enrichment Algorithm Concept Visual

実務適用時の注意点と限界

MDSの設計にはいくつかのトレードオフがあります。

1. 非同期補完によるレイテンシ

新しいエンティティが作成されてから、関係がグラフに完全に反映されるまで数分の遅延が発生する可能性があります。Netflixは各エンティティの「最終補完時刻」をポータルに表示し、実務者がデータの鮮度を判断できるようにしています。

2. ソースシステムへの追加負荷

HydrationプロセスでMDSがソースシステムのAPIを呼び出すため、読み取り負荷が増加します。これを軽減するために、レートリミット、キャッシング、バックオフ戦略が不可欠です。

3. メタデータ品質への依存

ソースシステムがイベントを欠落させたり、所有権情報が古くなったり、エンティティに説明が不足していると、グラフの有用性が低下します。Netflixは自動検証・補完システムでこの問題に対処していますが、完全な解決策はまだありません。

日本開発コミュニティでの適用コンテキスト

日本のIT企業、特に大規模プラットフォーム(EC、ゲーム、FinTech)でも同様の問題が発生しています。複数のチームが各々MLモデルを開発する中で、「誰がどのモデルを作ったか」「この特徴量を変更するとどのサービスに影響するか」を把握することが困難なケースが多く見られます。Netflixのアプローチは以下の環境で特に有効です。

  • MLプラットフォームチームが存在する組織: 中央でメタデータサービスを構築できる体制がある場合
  • 複数ドメインにMLを適用している企業: パーソナライズ、検索、広告、リスク管理など多様な領域でモデルを運用する場合
  • マイクロサービスアーキテクチャを採用している環境: 各サービスが独立したデータストアを持つ場合

ただし、Netflixのように自前のMLインフラ(特徴量ストア、モデルレジストリ、実験プラットフォーム)をすべて備えている場合にこそ、このアーキテクチャの真価が発揮されます。日本の中小企業であれば、オープンソースツール(MLflow、Kubeflow、Feastなど)を組み合わせて類似の効果を得ることが可能です。

Developer exploring model lineage and impact analysis on Netflix AIP Portal interface Dev Environment Setup

まとめ：MLエコシステムの「接続」こそが生産性を生む

NetflixのModel Lifecycle Graphは、単なる技術システムではありません。これはML組織のコラボレーション文化を変えるインフラです。モデル、特徴量、パイプライン、実験がひとつのグラフで接続されることで、実践者は「誰に聞けばいいか」と悩むことなく、システム自体から答えを見つけられます。

MDSの核心的な教訓は以下の通りです。

  • イベントを「変更通知」としてのみ使い、状態はソースシステムから直接取得する (順序に頑健)
  • 非同期補完によって関係を段階的に発見する (リアルタイム性と正確性のトレードオフ)
  • URIベースのアドレス体系で全エンティティを一意に識別する (拡張性)

このアプローチは、MLツールが増え続ける状況でも拡張可能な基盤を提供します。新しいツールが追加されるたびにProviderを実装するだけで、グラフ全体が自動的に拡張されます。

合わせて読みたい記事

次のステップとしての学習方向

  • 実践: MLflowやKubeflowを使って、自分だけのMLメタデータストアを構築してみましょう。
  • 深堀り: GraphQLとDatomicのデータモデリングパターンを学ぶと、より深く理解できます。
  • 参考: Netflixの原文ブログを訪れて、より詳細なアーキテクチャ図を確認してください。
本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。