면책 조항. 이 글은 Netflix의 공개 커뮤니케이션 — 테크 블로그, 컨퍼런스 발표, 오픈소스 저장소, 외부 케이스 스터디 — 만을 기반으로 합니다. Netflix 공식 아키텍처 문서가 아닙니다. 복잡한 스택이 C4 모델로 어떻게 readable해질 수 있는지 보여주기 위해 공개된 내용을 모델링합니다. 세부사항이 Netflix가 명시한 것이 아니라 추론된 경우 그 사실을 명시합니다.

Play의 해부학: Netflix를 C4로 Archyl에서 모델링하기

Netflix에서 Play를 누르면 약 50개의 서비스가 200ms 이내에 협력하여 바이트가 TV로 흐르기 시작합니다.

인증, 프로필 해석, eligibility 확인, watch-state 조회, manifest 생성, DRM 라이선스 발급, ad decisioning(2023년부터), CDN 라우팅, 엣지 캐시 hit, bitrate 협상, packet pacing — 이 모든 것이 frame 0이 화면에 도달하기 전에 일어납니다.

Netflix는 1,000개 이상의 마이크로서비스를 운영합니다. 테크 블로그는 "the membership platform" 을 하나의 것처럼 무심코 언급하지만 — 12개의 서비스입니다. "The video pipeline" 은 3개의 아키텍처 레이어로 오케스트레이션된 수십 개의 마이크로서비스입니다. "Open Connect" 는 ISP 네트워크에 임베디드된 1만 대의 FreeBSD 어플라이언스의 글로벌 함대입니다.

이런 스택을 어떻게 이해할까요? 이해할 수 없습니다, 한 번에는. 그것이 바로 C4 모델이 해결하기 위해 발명된 문제입니다.

이 글에서는 Netflix의 아키텍처를 4개의 C4 레벨(System Context, Container, Component, Code)로 모델링하고, Archyl이 이런 규모의 스택을 단순히 문서화 가능한 것을 넘어 읽을 수 있는 것으로 만드는 방법을 보여드립니다.

모든 서비스를 다루지는 않습니다. 그건 누구도 할 수 없습니다. 하나의 사용자 액션 — Play를 누르는 것 — 을 따라가며 레이어를 가로지르는 것을 보겠습니다.

레벨 1 — System Context: 1,000이 아닌 10가지

Netflix C4 System Context: 10 시스템, 외부 액터

System Context 레벨에서 Netflix는 1,000개의 마이크로서비스가 아닙니다. 10개의 시스템입니다.

지난 5년간 Netflix의 공개 커뮤니케이션을 보면 10개의 뚜렷한 시스템이 일관되게 나타납니다:

  1. Member Experience — 가입, 빌링, 계정, 프로필, 플랜 관리
  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, federated 개발자 콘솔
  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개의 마이크로서비스라는 것을 알 필요가 없습니다. 그것이 존재한다는 것, 빌링과 통신한다는 것, 결국 ISP가 바이트를 호스팅한다는 것을 알면 됩니다. 다이어그램은 대화의 시작점이지 인벤토리가 아닙니다.

ADR-001 · Open Connect를 구축하라, CDN에 비용을 지불하지 말라

상태 · Accepted (2011년, 2026년에도 여전히 활성)

컨텍스트 · 스트리밍 트래픽이 기하급수적으로 증가하고 있었습니다. 상용 CDN(Akamai, Limelight, Level 3)은 Netflix 스케일에서 프레임당 품질을 보장할 수 없었고, 비용 곡선은 지속 불가능했습니다.

결정 · 자체 CDN을 구축한다. ISP 네트워크 내부에 어플라이언스를 임베디드한다. 네트워크가 idle할 때인 밤에 prefetch한다. 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를 fronting.
  • Cassandra 클러스터 — viewing state, watch history, 영구 세션 데이터.

전형적인 play는 Playback API → Manifest Service → License Service를 병렬로 거치며, 모두 hot할 때는 EVCache에서, 그렇지 않으면 Cassandra에서 제공됩니다. manifest URL은 Open Connect 어플라이언스를 가리키며 — 거기서 TV는 말 그대로 ISP 데이터센터 안에 있을 수 있는, 밀리초 거리의 서버와 통신합니다.

이 레벨의 기술 스택: Spring Boot가 있는 Java, 서비스 간 호출에 gRPC, 이벤트에 Kafka, 2022년 Falcor → GraphQL 마이그레이션 이후 클라이언트 API에 GraphQL Federation.

ADR-002 · 기본 데이터스토어로서의 Cassandra

상태 · Accepted (2011년, 대부분의 stateful 워크로드에 여전히 활성)

컨텍스트 · 2008년 Netflix의 데이터센터 장애는 단일 primary 데이터베이스가 비즈니스의 SPOF임을 증명했습니다. 멀티-DC eventual consistency, 선형 쓰기 스케일, SPOF 없음이 새로운 요구사항이 되었습니다.

결정 · 새 서비스의 기본 데이터스토어로 Cassandra를 채택. 데이터 레이어에서 eventual consistency를 수용. EVCache를 위에 구축하여 hot read 경로를 커버.

결과 · 대부분의 stateful 서비스는 Cassandra-backed입니다. 멀티 리전 active-active가 자연스러워집니다. 글로벌 SQL 트랜잭션이 필요한 워크로드(membership pricing, redemption code)에는 2020년에 CockroachDB가 추가되었습니다 — 하지만 Cassandra는 여전히 영구적인 사용자 데이터를 소유합니다.

ADR 두 개가 더해지면 다이어그램이 의미를 갖기 시작합니다. 컨테이너 선택은 시스템 레벨 결정에서 따르고, 그것은 비즈니스 제약에서 따릅니다.

레벨 3 — Component: Cosmos 비디오 파이프라인 내부

Netflix C4 Component: Cosmos 파이프라인 VIS CAS LGS VES VVS VQS

인코딩은 play 시점에 일어나지 않습니다. 타이틀이 입수되는 몇 달 전에 일어납니다. 하지만 아름다운 레벨 3 예입니다 — Netflix가 충분히 공개해서 컨테이너 중 하나의 내부를 매핑할 수 있는 곳입니다.

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로 결과 점수.

이것이 Component 레벨 C4가 어떻게 보이는지입니다: "여기 코드가 있어요" 가 아니라 "여기 비즈니스적으로 의미 있는 프리미티브의 체인이 있고, 각각이 owned되고, 각각이 교체 가능하고, 각각이 측정 가능" 입니다.

ADR-003 · Reloaded에서 Cosmos로의 마이그레이션

상태 · Accepted (~2018년 시작, 2023년 9월 완료)

컨텍스트 · Reloaded는 모놀리식이고 순차적인 비디오 파이프라인이었습니다. Netflix의 카탈로그가 성장하고 코덱 복잡도가 폭발(HDR, AV1, per-shot 인코딩)함에 따라 Reloaded는 병목이 되었습니다 — 새 코덱을 추가하는 것은 전체 파이프라인을 재구축해야 했습니다.

결정 · 청크 병렬 마이크로서비스로 분해, 각각이 Optimus / Plato / Stratum 3 레이어 패턴을 구현. 오케스트레이션을 위해 Netflix 내부의 priority-aware 메시징 시스템 Timestone 사용.

결과 · 인코딩 처리량이 배가되었습니다. 새 코덱과 품질 실험이 재앙적이지 않고 조합 가능해졌습니다. 분해는 per-shot 인코딩을 잠금 해제했고, 이는 member 경험의 bitrate 효율성을 직접 개선했습니다.

Archyl 모델에서는 이런 ADR이 아키텍처와 함께 여행합니다. 2026년에 Cosmos 컨테이너를 클릭하고 7개의 컴포넌트를 볼 때, 왜 7개이고 1개가 아닌지를 설명하는 2018년의 결정도 보게 됩니다.

Archyl에 렌더링된 ADR 카드 3개

세 가지 결정. Archyl의 세 카드, 각각이 형성하는 C4 요소에 링크 — Open Connect는 자신의 시스템 박스에, Cassandra는 데이터스토어 컨테이너에, Cosmos는 2018년 이전에 존재하지 않았던 컴포넌트들에. 다이어그램은 현재형; ADR은 그 이유.

Ownership: 모델을 책임감으로 변환

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 모델과 현재 코드에 있는 것 사이의 격차. 컨포먼스 규칙은 정책 레이어를 추가합니다 — "모든 컨테이너는 소유자 팀이 필요", "교차 데이터베이스 접근 없음", "ADR-마크된 모든 기술은 radar에 있어야 함".

Netflix에게 이는 1,000 서비스 규모에서의 drift 탐지입니다. 하지만 규칙은 10개일 때와 동일합니다.

그리고 지난주 출시한 팀 아키텍처 다이제스트는 Netflix 같은 설정에서:

  • Member Systems 의 월요일 다이제스트는 12개의 membership 마이크로서비스를 커버
  • Open Connect 의 다이제스트는 OCA와 컨트롤 플레인을 커버
  • Streaming Algorithms 의 다이제스트는 Cosmos와 인코딩 컴포넌트를 커버
  • 각 다이제스트는 자기 팀이 소유한 경계에 스코프되고, 자기 팀의 시간대에서

같은 표면. 다른 스코프. 그것이 C4 + ownership이 잠금 해제하는 대칭성입니다.

1,000개의 서비스가 필요하지 않습니다

당신은 Netflix가 아닙니다. 대부분의 엔지니어링 조직은 그렇지 않습니다.

하지만 교훈은 아래로도 스케일합니다. Context를 Container와 Component에서 분리하는 규율, 다이어그램을 설명하는 ADR을 작성하는 규율, 모든 박스에 ownership을 첨부하는 규율 — 이 규율이 50개 서비스 스택이 1,000처럼 느껴지지 않게 하는 것입니다.

C4 + ADR + Ownership + Drift + 컨포먼스가 Archyl이 out of the box로 제공하는 것입니다. Netflix 예시는 모델의 가장 큰 그럴듯한 스트레스 테스트일 뿐입니다.

자신의 아키텍처를 열어보세요. 10개의 시스템을 스케치하세요. 가장 아픈 하나를 골라 컨테이너로 줌인하세요. 왜 선택이 그런 모양인지 설명하는 3개의 ADR을 작성하세요. 각 컨테이너에 팀을 매핑하세요.

대부분의 엔지니어링 조직이 1년에 도달하는 곳보다 앞서 있을 것입니다.

자신의 아키텍처를 C4로 모델링하고 싶으신가요? Archyl로 시작하세요. 왜 ADR과 C4가 함께 더 잘 작동하는지 또는 Architecture Change Requests가 C4 모델에 풀 리퀘스트의 엄격함을 가져오는 방법도 읽어보세요.