はじめに：データプラットフォームのスケールが生む2つの課題

Netflixのデータプラットフォームは膨大です。数百万のテーブル、数万のスケジュールされたワークロードが日々実行されています。これらの背後にはエンジニア、チーム、イニシアチブがあり、そのさらに背後には「誰が何にアクセスできるか」「ワークロードはどのIDで実行されるか」という根本的な問いがあります。

従来の方法は個別アセット単位でのアクセス制御でした。すべてのテーブルに独自のACL（アクセス制御リスト）があり、すべてのワークフローは作成者のIDで実行されていました。しかし、流動的な人材環境において、この細粒度モデルは2つの方法で破綻しました。

課題1: 組織変更に追いつかない権限 チームが数百のテーブルを所有しているとします。組織再編で隣のチームが統合され、さらに数百のテーブルを引き継ぎます。すべてのテーブルのACLを探し出し、誰がアクセスすべきかを判断し、一つずつ更新しなければなりません。これを会社のすべてのチーム、すべての再編に対して繰り返します。結果は2つです：

  • サポートチームが過負荷になります。 サポートチケットの大部分が、組織変更に伴うテーブル権限の一括更新です。セルフサービスのツールはありますが、遵守率は一貫していません。
  • アクセス権限が過度に広くなります。 細かいACLを維持するよりも、チーム全体にテーブルアクセスを開放してしまうケースが多発します。これではACLの意味がありません。

課題2: 人間のIDに紐づくワークロード スケジュールされた非同期ワークロード（Maestroワークフロー、データ移動ジョブ、Sparkパイプラインなど）は、実行するためのIDが必要です。従来は人間、つまりワークフローを作成したエンジニアのIDが使われていました。

人間のIDは持続的ではありません。人はチームを移動し、役割が変わり、退職します。すると、そのIDで実行されていたワークフローが失敗し始めます。解決策は同僚のIDに切り替えることですが、同僚は異なる権限を持っているため、「権限のモグラ叩き」が始まります。そして結局その同僚も異動し、サイクルが繰り返されます。

Netflix data platform server racks representing massive scale of data assets Programming Illustration

Data Projects：問題の本質を解決する

Netflixは Data Projects という概念を導入しました。核はシンプルです。個別アセットではなく、意味のあるコンテナ（プロジェクト） 単位で管理を引き上げることです。

Data Projectは2つの要素から構成されます：

  1. 関連アセットをグループ化するコンテナ：テーブル、ワークフローなど、関連するデータアセットを1つの論理的な傘の下にまとめます。
  2. 合成され、持続可能で、引き受け可能（assumable）なID：非同期およびスケジュールされたワークロードが、人間のライフサイクルから独立して実行できるIDです。

簡単に言えば、500のテーブルの権限を個別に管理する代わりに、その500のテーブルを含む1つのプロジェクトの権限だけを管理すればよいのです。

GrantsとRoles

各Data Projectは、所有チームが管理する一連の Grant を持ちます。さまざまなIDタイプ（ユーザー、グループ、アプリケーション、CIジョブ）をGrantとして追加でき、各Grantはプロジェクト内で何ができるかを決定する Role を持ちます。例えば、Contributorは読み取り/書き込み権限、Viewerは読み取り専用権限を持ちます。誰かがチームに参加したり離脱したりするときに、数百のACLを書き換える代わりに、1つのプロジェクトのGrantを更新するだけです。

Identity Umbrella：Netflix IAMとの統合

すべてのData Projectは、NetflixアプリケーションIDとオプションのAWS IAMロールでプロビジョニングされます。これがワークロードを持続可能にする 「IDの傘（Identity Umbrella）」 です：

  • プロジェクトのNetflix IDは非同期ワークロード（例：Maestroワークフロー）を実行します。このIDはプロジェクトに属し、誰にも属しません。
  • プロジェクトのIAMロールは、Amazon EMRのSparkジョブなどのAWS固有のユースケースをサポートします。重要なのは、IAMロールをプロジェクトのNetflix IDと暗号学的に安全に交換できることです。
  • 特権ロールを持つメンバーは、プロジェクトのNetflix IDを 引き受ける（assume） ことができます。これは開発環境（ラップトップ、ノートブック）でのテストやトラブルシューティングに非常に便利です。スケジュールされたワークロードとまったく同じようにコマンドを実行できます。

Gravity（重力）：自動アセット帰属

Data Projectsの最もエレガントな特性の1つは Gravity です。プロジェクトIDで実行されるワークロードが新しいアセット（例：Maestroワークフローが3つのテーブルを作成）を作成すると、そのアセットは 自動的に プロジェクトの包含アセット（contained asset）として追加されます。プロジェクトは、そのIDで生成されたすべてのものの中心になります。プラットフォームがすでに動作している方法の副作用として、整理整頓を無料で得られ、関連アセットの発見とアクセス権取得の将来の課題を排除します。

Cloud infrastructure diagram showing identity and access management for data projects IT Technology Image

Maestroワークフローへの実際の適用：人間のIDからプロジェクトIDへの移行

Netflixの主要なバッチ分析ワークフローオーケストレーターである Maestro は、スケジュールされたETLパイプライン、データ移動ジョブ、MLトレーニングなどを処理します。ワークフローは元のユーザーがいなくてもスケジュールに従って実行できるため、Maestroは 信頼できるワークロードマネージャー（TWM） に指定され、管理するワークロードに代わって新しいIDトークンを発行する権限を持ちます。

人間のIDの問題点 従来のパターンは、ワークロードをOBO（On-Behalf-Of）資格情報で実行することでした。例：maestro OBO alice@netflix.com。これによりワークロードにMaestroと人間の権限の和集合が付与されますが、同時にワークロードの権限がその人の権限に紐づきます。その人がチームを移動したり退職したりすると、ワークロードは停止します。同僚が引き継いでも、以前の所有者と同じアクセス権限を持つことはほとんどないため、権限が整理されるまでワークロードは数日間停止します。数万のスケジュールされたワークロード、その多くがビジネスクリティカルな状況では、これは持続不可能でした。

Data Projectsの解決策：持続可能なID Data Projectsは、ユーザーIDを 持続可能なチーム所有のNetflixアプリケーションID に置き換えます。このIDはチームを移動せず、休暇を取らず、退職しません。各プロジェクトは関連するワークフロー、テーブル、シークレット、その他のアセットを単一の一貫したIDでグループ化し、Maestroはプロジェクトの下でワークフローを実行する前に、呼び出し元のプロジェクトアクセス権限を検証します。

改善効果：

  • 実行中に作成されたテーブルは、Gravityを介してプロジェクトIDと自動的に関連付けられ、追加設定なしでアクセス制御を継承します。
  • シークレットはプロジェクトポリシーにスコープされるため、所有権の移転によって資格情報が宙に浮くことはありません。
  • アクセスはプロジェクトレベルで1回管理され、ワークロードが触れるすべてのアセットに対する分散されたユーザー別Grantを置き換えます。

結果として、安定していて、監査可能で、組織変更に耐えうるワークロードIDモデルが誕生しました。

成功事例

  • ストリーミングQoE（Quality of Experience）：コアな可観測性パイプライン。以前はワークフローを所有するエンジニアに依存していた継続性が、プロジェクトIDの下で安定して実行されるようになりました。
  • メンバー分析（Member Analytics）：会員データプロダクトのための分析モデルとETLワークフロー。数百の個別テーブルとワークフローではなく、プロジェクトレベルでアクセスが管理されています。

より広く言えば、Data Projectsは分析ドメイン全体の 組織化の原理 として採用されました。チームは独自のアクセスポリシー、アドホックなGrantリスト、「誰が何にアクセスすべきか」という暗黙知を維持する必要がなくなり、プロジェクトが唯一の答えになりました。

Data analysis dashboard showing ETL workflows and asset management at scale Algorithm Concept Visual

実務適用のための考慮事項と限界

Data Projects導入方法

ワークフローをData Projectsにオンボーディングするには、以下の手順を踏みます：

  1. アセットの論理的なグループ化のためのプロジェクトを作成する（または既存の適切なプロジェクトを使用する）
  2. 適切な人とグループに適切なロールを付与する（Grant）
  3. ワークフローがプロジェクトのIDで実行されるように構成する

Gravityのおかげで、プロジェクトワークフローが作成した新しいアセットは自動的にプロジェクトに含まれます。

注意点： 既存のワークフローを移行することは課題です。実行IDを変更する前に、Data Projectに適切な権限を設定する必要があります。Netflixは、既存のワークフローのアクセスパターンを追跡し、移行先プロジェクトの正確な権限更新を推奨するインフラを積極的に開発中です。

この技術の限界または注意点

  • 初期設定コスト：従来個別アセット単位で管理されていたシステムをプロジェクト単位に移行するには、相当な労力が必要です。
  • プロジェクト設計の難しさ：「何が1つのプロジェクトか」という基準を明確にする必要があります。大きすぎると管理が難しく、小さすぎると細粒度管理の利点が失われます。
  • Gravityによる予期せぬアセット包含：ワークロードが意図しないアセットを作成した場合、自動的にプロジェクトに含まれ、アクセス権限が拡大する可能性があります。監視と監査が必要です。

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

  1. IAMロールとサービスアカウントの概念 をしっかり理解しましょう。AWS IAMロールをプロジェクト単位でマッピングする方法を学ぶと良いです。
  2. ワークロードオーケストレーター（Airflow、Maestroなど）の認証/認可モデル を分析してみてください。どのIDでワークロードが実行されるか、そのIDがどのように管理されるかが鍵です。
  3. 最小権限の原則（Principle of Least Privilege） をプロジェクト単位でどのように適用するかを検討しましょう。Netflixが「Rightsizing」と呼ぶ自動権限最適化は将来の方向性です。

根拠資料： Netflix Tech Blog - Data Projects: Managing Data Assets at Netflix Scale

合わせて読みたい記事

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。