Netflix 마이크로서비스 전환

📌 Brief Summary

Netflix의 마이크로서비스 전환은 혁신성, 신뢰성, 효율성을 개선하기 위해 기존의 거대한 모놀리식 아키텍처를 독립적으로 배포 및 확장이 가능한 작은 서비스 단위로 쪼갠 7년간의 대규모 마이그레이션 과정입니다 [1, 2]. 이 과정에서 무상태(Stateless) 서비스 지향, 수평적 확장, 데이터베이스의 NoSQL(Cassandra) 전환 및 자동화된 파괴 테스트(Chaos Monkey)를 원칙으로 삼아 99.999%의 높은 가용성을 확보했습니다 [2-4]. 최근에는 모놀리식화된 기존 시스템의 한계를 극복하고자 API, 워크플로우, 서버리스 함수가 결합된 차세대 마이크로서비스 플랫폼인 'Cosmos'를 도입하여 시스템을 한 단계 더 진화시키고 있습니다 [5, 6].

넷플릭스(Netflix)는 비즈니스 혁신과 안정성을 위해 기존의 RDBMS 기반 모놀리식 아키텍처를 독립적인 마이크로서비스로 전환하여 뛰어난 확장성과 가용성을 확보했습니다 [1, 2]. 이후 비디오 및 오디오 처리와 같은 미디어 중심의 비동기식 대규모 워크플로우에서 발생하는 병목 현상을 해결하기 위해 마이크로서비스, 워크플로우, 서버리스 함수를 결합한 '코스모스(Cosmos)' 플랫폼을 새롭게 도입했습니다 [3, 4]. 코스모스 플랫폼은 다차원적인 관심사 분리를 통해 인프라와 애플리케이션 코드를 격리하고 시스템의 모듈성 및 생산성을 비약적으로 향상시켰습니다 [4, 5].

📖 Core Content

초기 아키텍처와 전환 배경: Netflix는 2008년 8월 데이터 센터와 RDBMS를 기반으로 한 모놀리식 아키텍처로 서비스를 시작했으나, 시스템의 단단한 결합(tight coupling)으로 인해 빠른 혁신과 잦은 배포가 불가능했습니다 [2, 7]. 개발 속도를 높이고 높은 가용성을 달성하기 위해 7년에 걸쳐 작은 독립적인 서비스들로 구성된 마이크로서비스 아키텍처로의 전환을 단행했습니다 [1, 2].
전환의 핵심 원칙 (First Principles):
- 구축보다 구매 (Buy vs. Build): 가능하면 오픈소스(OSS) 기술을 우선적으로 사용하고, 꼭 필요한 기능만 직접 구축합니다 [2].
- 무상태(Stateless) 서비스와 수평적 확장: 지속성이나 캐싱 계층을 제외한 모든 서비스는 상태를 유지하지 않도록(Stateless) 설계하여, 수직적 확장(Scale up)의 한계를 피해 수평적 확장(Scale out)을 지향합니다 [2, 3].
- 이중화와 격리 (Redundancy and Isolation): 다중 지역(Multi-Regional) 복제 구성을 채택하고, 장애 발생 시 파급 반경(Blast radius)을 격리하여 복원력을 높입니다 [3].
- 파괴 테스트 자동화: Simian Army의 Chaos Monkey 등을 활용하여 의도적으로 결함을 주입하고 파괴 테스트를 자동화함으로써 시스템의 신뢰성을 지속적으로 검증합니다 [3].
- 데이터베이스 마이그레이션: 대규모 확장에 불리한 기존의 RDBMS 대신 확장성, 파티션 내구성, 가용성이 뛰어난 NoSQL인 Cassandra로 전환했습니다 [3].
운영 효과 및 한계: 마이크로서비스 구조는 클린 아키텍처의 높은 응집도와 낮은 결합도 개념을 적용하여, 컨테이너 및 Kubernetes를 통해 수백만 명의 사용자를 위한 탄력적인 확장을 제공합니다 [8, 9]. Netflix는 이를 통해 연간 단 52분의 다운타임만 허용하는 99.999%(4 9's)의 가용성을 목표로 합니다 [4]. 그러나 분산 시스템으로 변모하면서 서비스 간 통신 메커니즘 처리, 여러 팀의 조율, JVM/VM 추가 구동에 따른 메모리 소비 급증과 같은 복잡성 및 비용의 증가라는 단점도 수반되었습니다 [10-12].
차세대 마이크로서비스 플랫폼 'Cosmos' 도입:
- 시간이 지나면서 기존의 3세대 미디어 처리 시스템('Reloaded') 또한 비대해져 모놀리스와 같이 인프라와 애플리케이션 코드가 뒤섞이는 운영상 병목을 일으켰습니다 [13-15].
- 이를 해결하기 위해 워크플로우 기반 미디어 중심 마이크로서비스 플랫폼인 'Cosmos'를 구축했습니다 [5]. Cosmos는 외부 요청을 처리하는 API 계층(Optimus), 비즈니스 규칙을 모델링하는 워크플로우 계층(Plato), 계산 집약적이고 상태가 없는 작업을 실행하는 서버리스 함수 계층(Stratum)으로 관심사를 횡단 및 논리적으로 철저히 분리했습니다 [15, 16].
- 레거시 시스템에서 Cosmos로의 이전은 점진적으로 기존 시스템을 둘러싸며 대체하는 교살자 무화과(StrANGLEr fig) 패턴을 적용하여 리스크를 최소화하고 있습니다 [17].

마이크로서비스 아키텍처로의 전환 및 운영

넷플릭스는 2008년부터 확장성의 한계를 극복하기 위해 기존 모놀리식 아키텍처에서 마이크로서비스 기반으로 인프라를 이전하기 시작했습니다 [1, 2].
이 전환은 서비스의 무상태성(Stateless) 유지와 수평적 확장을 원칙으로 하였으며, 카오스 몽키(Chaos Monkey)를 포함한 Simian Army를 통해 파괴적 테스트를 자동화하여 장애 복원력을 높였습니다 [2, 6].
데이터베이스 계층 또한 다중 리전 복제와 파티션 허용 오차가 뛰어난 NoSQL인 카산드라(Cassandra)로 교체했습니다 [6].
이러한 마이크로서비스로의 전환은 넷플릭스 내 개별 팀의 개발 및 배포 독립성을 보장하여 혁신 속도를 높였으며, 연간 52분의 다운타임만 허용하는 99.999%의 가용성을 달성하는 데 기여했습니다 [7, 8].

코스모스(Cosmos) 플랫폼의 도입 배경

넷플릭스의 미디어 클라우드 엔지니어링 및 인코딩 기술 팀은 미디어 파일의 처리를 위해 3세대 시스템인 'Reloaded(리로디드)'를 수년간 성공적으로 운영해 왔습니다 [9].
그러나 시스템 규모가 커지고 개발 인력과 유스케이스가 확장되면서, 기존 모놀리식 구조에서는 인프라 코드와 애플리케이션 코드가 뒤섞여 신규 기능의 배포가 지연되는 심각한 병목 현상이 발생했습니다 [4, 9, 10].
이를 해결하기 위해 비동기 워크플로우와 서버리스 기능을 결합한 미디어 중심의 마이크로서비스 플랫폼 '코스모스(Cosmos)'가 구축되었으며, 기존 Reloaded 시스템을 대체하기 위해 스트랭글러 피그(StrANGLEr fig) 패턴을 채택하여 점진적인 전환을 시도했습니다 [4, 5, 11].

코스모스 플랫폼의 다차원적 관심사 분리([[뇌와 팔다리의 분리 - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]]) 코스모스는 플랫폼과 애플리케이션 사이의 분리뿐만 아니라, 논리적 계층을 3개로 분리함으로써 고도의 관심사 분리를 구현했습니다 [4, 12].

Optimus(옵티머스): 외부의 요청을 내부 비즈니스 모델로 매핑해 주는 API 계층입니다 [4, 13].
Plato(플라톤): 비즈니스 규칙을 모델링하고 무상태 함수들을 오케스트레이션하는 워크플로우 계층입니다 [4, 13, 14].
Stratum(스트라툼): 무상태이면서 고도의 계산 집약적인 함수들을 실행하는 서버리스 계층입니다 [4, 13].
Timestone(타임스톤): 위의 각 하위 시스템들이 비동기적으로 통신할 수 있도록 지원하는 대규모 우선순위 큐잉 시스템으로, 각 컴포넌트 간의 결합도를 극도로 낮추는 핵심적인 역할을 합니다 [4, 13].

⚖️ Trade-offs & Caveats

과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
정책 변화: Programming & Language 분야의 자동 자산화 수행.

과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
정책 변화: Programming & Language 분야의 자동 자산화 수행.

🔗 Knowledge Connections

Related Topics: 모놀리식 아키텍처, 수평적 확장 (Scale out), Cassandra, 오픈소스 (OSS), 서버리스 함수
Projects/Contexts: Reloaded 시스템, Cosmos 플랫폼, Chaos Monkey (Simian Army)
Contradictions/Notes: 마이크로서비스 아키텍처는 혁신과 배포 속도 향상이라는 큰 장점을 가져다주었지만, 반대로 구현 시 분산 시스템의 복잡성을 관리해야 하고 다수의 서비스 인스턴스를 실행하는 데 따른 심각한 메모리 사용량(오버헤드) 증가를 초래한다는 구조적 한계점이 소스에서 분명히 지적되고 있습니다 [10, 11].

Last updated: 2026-04-18

Related Topics: Microservices Architecture, Separation of Concerns, Serverless Functions, Asynchronous Workflows, Chaos Monkey
Projects/Contexts: Reloaded, Tapas, Sagan, Strangler Fig Pattern
Contradictions/Notes: 마이크로서비스 전환과 코스모스와 같은 분산 플랫폼의 구축은 혁신과 확장성 측면에서 큰 이점을 제공하지만, 그 대가로 분산 시스템의 통신 메커니즘을 직접 구현해야 하는 설계적 복잡성을 증가시킵니다 [15, 16]. 또한 여러 서비스 인스턴스를 독립적으로 실행하고 배포해야 하므로, 메모리 소비가 증가하고 운영 비용이 상승하는 단점이 존재합니다 [16-18].