免責事項。 この記事はNetflixの公開コミュニケーション(テックブログ、カンファレンストーク、オープンソースリポジトリ、外部ケーススタディ)のみに基づいています。Netflixの公式アーキテクチャドキュメントではありません。複雑なスタックがC4モデルでどのようにreadableになり得るかを示すために、公開されている内容をモデリングしています。詳細がNetflixの主張ではなく推論である場合はその旨を明記します。

Playの解剖学:NetflixをC4でArchylにモデル化する

NetflixでPlayを押すと、約50のサービスが200ミリ秒未満で連携し、バイトをあなたのテレビに流し始めます。

認証、プロファイル解決、eligibilityチェック、watch-stateルックアップ、manifest生成、DRMライセンス発行、ad decisioning(2023年以降)、CDNルーティング、エッジキャッシュヒット、bitrateネゴシエーション、packet pacing — 全部、フレーム0が画面に届く前に。

Netflixは1000以上のマイクロサービスを運用しています。テックブログでは "the membership platform" を1つのものであるかのように軽く言いますが — 12のサービスです。 "The video pipeline" は3つのアーキテクチャレイヤーで構成された数十のマイクロサービスです。 "Open Connect" はISPネットワークに埋め込まれた1万台のFreeBSDアプライアンスのグローバルフリートです。

このようなスタックをどう理解するか?一度には理解できません。それこそがC4モデルが解決するために発明された問題です。

この投稿では、NetflixのアーキテクチャをC4の4レベル(System Context、Container、Component、Code)にわたってモデリングし、Archylがこのスケールのスタックをドキュメンタブルにするだけでなくreadableにする方法を示します。

すべてのサービスをカバーするわけではありません。誰にもできません。1つのユーザーアクション(Playを押すこと)を追って、レイヤーを横断するのを見ます。

レベル1 — System Context:1000ではなく10のもの

Netflix C4 System Context: 10システム、外部アクター

System Contextレベルでは、Netflixは1000のマイクロサービスではありません。10のシステムです。

過去5年間のNetflixの公開コミュニケーションを見ると、10の異なるシステムが一貫して浮かび上がります:

  1. Member Experience — signup、billing、アカウント、プロファイル、プラン管理
  2. Content Discovery — 検索、レコメンデーション、ブラウズ、ランキング
  3. Streaming Platform — playback、manifest、DRM、QoE
  4. Open Connect — 自社開発のグローバルCDN
  5. Studio Engineering — pre-からpost-productionまでのツール
  6. Content Engineering — カタログ、メタデータ、タクソノミー
  7. Data Platform — Kafka、Flink、Iceberg、Atlas、Mantis
  8. Cloud Platform — Spinnaker、Titus、Eureka、フェデレーテッドデベロッパーコンソール
  9. Security — 境界、シークレット、脅威検知
  10. Ads Platform — 2023年に広告対応プラン追加とともに登場

その周りに:数百種類のデバイス上のmember、Open ConnectアプライアンスをホストするISP、基盤クラウドのAWS、DRMパートナー(Widevine、PlayReady、FairPlay)、決済プロセッサーとパートナービラー(App Store、Google Play、テルコバンドル)、サプライヤー側のコンテンツスタジオ。

それだけです。10のシステム、6カテゴリの外部アクター。それ以外はすべて詳細です。

これがレベル1の贈り物です:System Contextでは、Membershipが12のマイクロサービスであることを知る必要はありません。それが存在し、billingと話し、最終的にISPがあなたのバイトをホストすることを知る必要があるだけです。図は会話の起点であり、インベントリではありません。

ADR-001 · Open Connectを構築する、CDNにお金を払わない

ステータス · Accepted (2011年、2026年も依然アクティブ)

コンテキスト · ストリーミングトラフィックは指数関数的に増加していました。商用CDN(Akamai、Limelight、Level 3)はNetflixのスケールでper-frame品質を保証できず、コストカーブも持続不可能でした。

決定 · 自社CDNを構築する。ISPネットワーク内にアプライアンスを埋め込む。ネットワークがアイドルな夜間にプリフェッチする。NVMeとHDDストレージを備えたFreeBSD + NGINXで動かす。

結果 · Netflix動画トラフィックの約95%が現在Open Connectで直接配信されています。CDNはコストラインから戦略的な堀へと変わりました。レベル1の図は、他のすべてのストリーミングサービスがAkamaiを持つ場所にOpen Connectを持っています。

Open Connectを構築する決定は、Netflixのレベル1図を最も強く形作った単一のアーキテクチャ選択です。それなしでは、図は今CDN全体が座っている場所に巨大なAkamaiボックスを持つことになります。

Archylではこのようにして、ADRがその場を獲得します:なぜ図がこのように見えるのかを説明するのです。

レベル2 — Container:Streaming Platformへのズーム

Netflix C4 Container: Streaming Platform内部

Playを押すと、クライアント(たとえばスマートTV)がStreaming Platformに到達します。箱を開けてみましょう。

Streaming Platform内部では、公開ソースが少なくとも以下のコンテナを明らかにしています:

  • Playback API — エントリーポイント。セッション検証、コンカレントストリーム上限チェック、bitrate ladderへのeligibilityを判断。
  • Manifest Service(Netflix内部の語彙ではCadmium / Akira)— セッションごとのHLSまたはDASH manifestを生成し署名。
  • License Service — デバイスのDRM(AndroidとChromeはWidevine、EdgeとXboxはPlayReady、AppleはFairPlay)とハンドシェイク。
  • MSL Gateway — Netflix独自のMessage Security Layer、HTTPSがプラットフォーム内で終端する前にクライアントが話すプロトコル。
  • FTL (Fast Track Live) — ライブストリーミングパイプライン。
  • EVCache — 22 000インスタンス、14.3 PBのワーキングセットのMemcachedフリート、ホットなセッションとメタデータreadをfront。
  • Cassandraクラスター — viewing state、watch history、永続化セッションデータ。

典型的なplayは、Playback API → Manifest Service → License Serviceを並行して触れ、すべてホット時はEVCacheから、それ以外はCassandraから提供されます。manifest URLはOpen Connectアプライアンスを指していて — そこからあなたのTVは、文字通りあなたのISPのデータセンター内にあるかもしれない、ミリ秒の距離にあるサーバーと話します。

このレベルのテックスタック:Java with Spring Boot、サービス間呼び出しにgRPC、イベントにKafka、2022年のFalcor → GraphQL移行以降、クライアントAPIにはGraphQL Federation。

ADR-002 · デフォルトデータストアとしてのCassandra

ステータス · Accepted (2011年、ほとんどのstatefulワークロードで依然アクティブ)

コンテキスト · 2008年のNetflixデータセンター障害は、単一プライマリデータベースが事業上のSPOFであることを証明しました。マルチDC eventual consistency、線形書き込みスケール、SPOFなしが新しい要件になりました。

決定 · 新サービスのデフォルトデータストアとしてCassandraを採用。データレイヤーでeventual consistencyを受け入れる。EVCacheを上に構築してホットread pathをカバー。

結果 · ほとんどのstatefulサービスはCassandra-backed。マルチリージョンactive-activeが自然になる。グローバルSQLトランザクションが必要なワークロード(membership pricing、redemption code)用に2020年にCockroachDBを追加 — しかしCassandraは依然として永続的なユーザーデータを所有。

ADRを2つ書いた段階で、図が意味を持ち始めます。コンテナ選択はシステムレベル決定から従い、それはビジネス制約から従います。

レベル3 — Component:Cosmos動画パイプラインの内部

Netflix C4 Component: Cosmosパイプライン VIS CAS LGS VES VVS VQS

エンコーディングはplay時には起こりません。タイトルが取り込まれた数ヶ月前に起こります。しかしレベル3の美しい例です — Netflixが十分公開しているため、コンテナの1つの内部をマップできる場所です。

CosmosはNetflixの以前のビデオパイプラインReloadedに取って代わったプラットフォームです。移行は数年の作業を経て2023年9月に完了しました。各Cosmosマイクロサービスは3層のパターンに従います:

  • Optimus — 外部に公開されるAPI層
  • Plato — ワークフローオーケストレーション層
  • Stratum — サーバーレスコンピュート層

エンコーディングを通るタイトルは、各々がCosmosマイクロサービスである一連のコンポーネントを通り抜けます:

  1. VIS — Video Inspection Service。ソースアセットをプローブ。
  2. CAS — Complexity Analysis Service。コンテンツのエンコード難易度をスコア。
  3. LGS — Ladder Generation Service。bitrate ladderを決定。
  4. VES — Video Encoding Service。実際のエンコーディング、チャンク並列化。
  5. VVS — Video Validation Service。出力の整合性を検証。
  6. VQS — Video Quality Service。NetflixのオープンソースのVMAFという知覚品質メトリクスで結果をスコア。

これがコンポーネントレベルのC4の見た目です:*"これはコードです"ではなく、"これはビジネス的に意味のあるプリミティブの連鎖で、それぞれownedされ、それぞれ置換可能で、それぞれ計測可能"*なのです。

ADR-003 · ReloadedからCosmosへの移行

ステータス · Accepted (~2018年開始、2023年9月完了)

コンテキスト · Reloadedはモノリシックでシーケンシャルな動画パイプラインでした。Netflixのカタログが拡大しコーデックの複雑さが爆発する(HDR、AV1、per-shotエンコーディング)につれ、Reloadedはボトルネックになりました — 新しいコーデックを追加するにはパイプライン全体を再構築する必要がありました。

決定 · チャンク並列のマイクロサービスに分解、各々がOptimus / Plato / Stratumの3層パターンを実装。オーケストレーションにはNetflix内部のpriority-aware messaging system Timestoneを使用。

結果 · エンコーディングスループットが乗算的に増加。新コーデックと品質実験は破滅的ではなく構成可能になった。分解はper-shotエンコーディングを解放し、これは直接memberエクスペリエンスのbitrate効率を改善した。

Archylモデルでは、このようなADRはアーキテクチャと一緒に旅をします。2026年にCosmosコンテナをクリックして7つのコンポーネントを見るとき、なぜ7つで1つではないかを説明する2018年の決定も見ることになります。

ArchylにレンダリングされたADRカード3枚

3つの決定。Archylの3枚のカード、それぞれ形作るC4要素にリンク — Open Connectはそのシステムボックスに、Cassandraはデータストアコンテナに、Cosmosは2018年以前には存在しなかったコンポーネントに。図は現在形;ADRはなぜ。

Ownership:モデルをaccountabilityに変える

Netflix Ownership Map: チームをシステムにマッピング

C4モデルは、チームをマッピングするまでは静的なアーティファクトです。

Netflixはグループについて公に発信しています:Member Systems、Studio Engineering、Open Connect(独立したハードウェア中心の組織)、Cloud Platform、Streaming Algorithms、Data Platform、Insight Engineering、Security、Ads Engineering、Personalization Research。

これらをC4モデルに落とすと:

  • Member Systems がMember ExperienceとAds Platformを所有
  • Studio Engineering がStudioとContent Engineeringのコンテナを所有
  • Open Connect がOpen Connectシステム全体を上から下まで所有 — そのハードウェアとソフトウェアの垂直統合は有名
  • Cloud Platform がSpinnaker、Titus、Eurekaを所有 — プラットフォーム生地
  • Streaming Algorithms がエンコーディングコンポーネント(Cosmosパイプライン)を所有
  • Data Platform がKafka、Flink、Iceberg、Atlas、Mantisを所有
  • Personalization Research がレコメンデーションモデル、検索、ランキングを所有

このマッピングは装飾ではありません。続くすべてのものの基盤です。

システム、コンテナ、またはコンポーネントがチーム所有者を持てば、driftの検出は責任のあるものになります:新しいサービスがコミットに現れて図にない場合、特定のチームが問われます。コンフォーマンスルールが違反されると、inboxに名前が入ります。ADRを書く必要があるとき、曖昧さは崩壊します。

Archylでは、Ownership Mapはドキュメンテーションツールがガバナンスツールに変わる瞬間です。

Drift、コンフォーマンス、そして週次ダイジェスト

このサイズのモデルはdriftします。新しいサービスが上陸します。古いものは廃止されます。スタックは変わります — Falcor → GraphQL Federation、Reloaded → Cosmos、Hystrix → メンテナンスモード。

Archylは週次のdriftスコアを計算します:ドキュメント化されたC4モデルとコードに現在あるものとのギャップ。コンフォーマンスルールはポリシー層を追加します — 「すべてのコンテナはownerチームが必要」、「クロスデータベースアクセスなし」、「ADRマークされたすべての技術はradarに含まれる必要がある」。

Netflixにとってそれは1000サービススケールでのdrift検出です。しかしルールは10サービスのときと同じです。

そして先週リリースしたチームアーキテクチャダイジェストは、Netflix風のセットアップでは:

  • Member Systemsの月曜のダイジェストは12のmembershipマイクロサービスをカバー
  • Open ConnectのダイジェストはOCAとコントロールプレーンをカバー
  • Streaming AlgorithmsのダイジェストはCosmosとエンコーディングコンポーネントをカバー
  • 各ダイジェストはチームが所有する境界にスコープされ、チーム自身のタイムゾーンで配信

同じサーフェス。異なるスコープ。それがC4 + ownershipが解錠する対称性です。

1000サービスは必要ない

あなたはNetflixではありません。ほとんどのエンジニアリング組織もそうではありません。

しかし学びは下方向にもスケールします。ContextをContainerからComponentから分ける規律、図を説明するADRを書く規律、すべてのボックスにownershipを付ける規律 — その規律こそが、50サービスのスタックを1000のように感じさせないものです。

C4 + ADRs + Ownership + Drift + コンフォーマンスはArchylがout of the boxで提供するものです。Netflixの例はモデルの最大の妥当なストレステストにすぎません。

自分のアーキテクチャを開きましょう。10のシステムをスケッチしましょう。最も痛む1つを選んで、そのコンテナにズームインします。なぜ選択がそう見えるのかを説明する3つのADRを書きましょう。各コンテナにチームをマッピングしましょう。

ほとんどのエンジニアリング組織が1年で到達する場所より先にいるはずです。

自分のアーキテクチャをC4でモデリングしたいですか?Archylで始めましょう。なぜADRとC4が一緒に機能するのか、またはArchitecture Change RequestsがC4モデルにpull requestの厳密さをもたらす方法も読んでみてください。