넷플릭스가 직접 공개한 실시간 서비스 맵 MSA 의존성 지옥에서 탈출한 방법

들어가며: 새벽 3시, 당신은 무엇을 보고 있나요?

운영 중인 서비스에서 갑자기 에러율이 치솟습니다. 사용자 불만은 쌓여가고, 원인을 찾아야 하는데... 수천 개의 마이크로서비스 중 도대체 어디서 문제가 시작된 걸까요?

넷플릭스도 똑같은 고민을 했습니다. 그들은 이 문제를 해결하기 위해 서비스 토폴로지(Service Topology) 라는 실시간 의존성 맵을 직접 구축했습니다. 이 글에서는 그들의 접근 방식과 우리가 배울 수 있는 교훈을 살펴보겠습니다.

본 글은 넷플릭스 테크블로그 원문을 기반으로 재구성했습니다.

왜 기존 도구로는 부족했나?

전통적인 모니터링 도구들은 각각 조각난 그림만 보여줍니다.

• 메트릭(Metrics): 증상과 성능 특성만 알려줌
• 로그(Logs): 개별 서비스의 행동만 보여줌
• 트레이스(Traces): 단일 요청의 흐름만 추적

문제는 이 모든 것을 엔지니어가 머릿속으로 연결해야 한다는 점입니다. 새벽 3시에 여러 도구를 오가며 정보를 조합하는 것은 느리고, 실수하기 쉬우며, 스트레스가 큽니다.

넷플릭스의 해결책: 3가지 데이터 소스의 하이브리드

넷플릭스는 단일 데이터 소스로는 완벽한 그림을 얻을 수 없다는 결론에 도달했습니다. 그래서 3개의 보완적인 소스로 각각 별도의 의존성 그래프를 만들고, 이를 통합해서 보여주는 방식을 채택했습니다.

이 세 가지를 결합함으로써:

• 네트워크 플로우는 완전성(누락 없음) 보장
• IPC 메트릭은 상세한 애플리케이션 정보 제공
• 트레이싱은 실제 동작 패턴 반영

각 소스가 서로의 한계를 보완하는 구조입니다.

핵심 아키텍처: 3단계 분산 집계

실시간으로 수백만 개의 플로우 로그를 처리하는 핵심 파이프라인은 다음과 같습니다.

# 개념적 파이프라인 흐름 (Pseudo-code)

# 1단계: Kafka에서 초기 집계
stage1_aggregation = consume_from_kafka(topic="network_flows")

# 2단계: 중간자(Load Balancer, NAT Gateway 등) 식별 및 경로 재구성
#    App A -> LB -> App B 형태의 로그를 App A -> App B 로 변환
stage2_resolution = resolve_intermediaries(stage1_aggregation)

# 3단계: 헬스 상태 통합 및 최종 집계 후 그래프 DB 저장
stage3_final = aggregate_with_health(stage2_resolution)
save_to_graph_db(stage3_final)

이 3단계 접근법은 특정 서비스가 다른 서비스보다 100배 많은 트래픽을 받는 핫스팟(Hot Spot) 문제를 분산 처리함으로써 해결합니다.

엔지니어에게 주는 실질적 가치

이 시스템이 가동된 후, 넷플릭스 엔지니어들은 다음과 같은 작업을 할 수 있게 되었습니다.

1. 의존성 시각화: 어떤 서비스가 누구에게 의존하는지 실시간 그래프로 확인
2. 블래스트 레이더스 파악: 서비스 점검 전 영향 범위를 미리 예측
3. 헬스 상태 오버레이: 콜 체인 상에서 현재 문제가 있는 서비스를 한눈에 식별
4. 프로그래매틱 접근: gRPC API를 통해 자동화 시스템(예: 장애 대응 자동화)에 통합
5. 타임 트래블: 과거 특정 시점의 토폴로지를 조회하여 변경 사항 추적

한국 개발 생태계에서의 적용 맥락

국내 SI(시스템 통합) 환경이나 대규모 플랫폼 기업에서도 이 접근법은 매우 유용합니다. 특히 다음과 같은 상황에서 직접적인 도움을 받을 수 있습니다.

• 레거시 시스템과 신규 MSA의 공존: eBPF를 활용한 네트워크 계층 수집은 계측되지 않은 레거시 서비스도 자동으로 발견합니다.
• 대규모 배포 주기: 한국의 많은 서비스가 야간/주말 배포를 하는데, 타임 트래블 기능으로 배포 전후 의존성 변화를 즉시 파악할 수 있습니다.
• 조직 간 의존성 관리: 여러 팀이 운영하는 서비스 간의 의존성을 명확히 시각화하여, 변경 시 사전 협의 범위를 정확히 특정할 수 있습니다.

참고: 에어비앤비의 멀티 프로덕트 데이터 아키텍처 사례에서도 유사한 '분리와 통합'의 교훈을 찾을 수 있습니다.

주의사항: 이 방법의 한계와 도전 과제

넷플릭스의 접근법은 강력하지만, 모든 환경에 완벽히 적용 가능한 것은 아닙니다.

1. 인프라 복잡도: eBPF, Apache Pekko Streams, 분산 그래프 DB 등 상당한 인프라 역량이 필요합니다.
2. 운영 비용: 3계층의 데이터를 각각 수집, 저장, 집계하는 것은 스토리지와 컴퓨팅 비용이 큽니다.
3. 데이터 정합성: 서로 다른 소스에서 수집된 데이터 간의 시간 동기화와 중복 제거가 까다롭습니다.
4. 조직적 준비: 이 도구의 진가는 엔지니어 문화가 데이터 기반 의사결정에 익숙할 때 발휘됩니다.

다음 단계 학습 방향

이 주제에 관심이 있다면 다음을 추가로 학습해보세요.

• eBPF 기초: 리눅스 커널 관찰 가능성의 현대적 표준
• 분산 트레이싱(OpenTelemetry): 요청 수준의 가시성 확보
• 그래프 데이터베이스(Neo4j, Amazon Neptune): 복잡한 관계 데이터 모델링
• 리액티브 스트림즈(Reactive Streams): 백프레셔(Backpressure) 처리와 분산 파이프라인 설계

마무리: 실시간 의존성 맵이 가져올 미래

넷플릭스는 이 토폴로지 맵을 단순한 모니터링 도구가 아니라 자동화된 근본 원인 분석(RCA) 의 기반 지식 그래프로 진화시키고 있습니다. 장애가 발생하면 에이전트가 토폴로지 그래프를 탐색하며 의존성 체인을 따라 원인을 추적하는 것입니다.

이 접근법의 핵심 교훈은 다음과 같습니다.

"완벽한 단일 데이터 소스는 없다. 여러 관점을 결합하고, 각각의 장점을 살려 상호 보완하라."

우리 팀의 마이크로서비스 환경에서도 지금 당장 eBPF와 IPC 메트릭, 트레이싱을 모두 구축할 수는 없겠지만, 의존성 맵을 만든다는 개념 자체는 어떤 규모에서든 적용할 수 있습니다. 시작은 간단합니다. 서비스 간 호출 로그를 수집해서 그래프로 그려보는 것부터요.

함께 보면 좋은 글:

• 에어비앤비의 멀티 프로덕트 데이터 아키텍처 분리 vs 통합, 실전 프레임워크에서 배우는 7가지 교훈
• 게임을 실시간으로 생성하는 AI, Waypoint-1의 가능성과 작동 원리