사일로에서 서비스 토폴로지로: 넷플릭스가 실시간 서비스 맵을 구축한 이유 (새 탭에서 열림)

넷플릭스는 수천 개의 마이크로서비스 간 실제 의존성을 실시간으로 보여주는 ‘Service Topology’를 구축했다. 기존의 지표·로그·트레이스는 시스템의 일부만 보여주므로, 장애 원인과 영향 범위를 파악하려면 엔지니어가 정보를 직접 조합해야 했다. Service Topology는 여러 데이터 소스로 네트워크와 애플리케이션 의존성 그래프를 만들고, 이를 통합해 빠르게 탐색할 수 있도록 하는 것이 핵심이다.

분산 시스템에서 의존성 파악이 어려운 이유

• 넷플릭스의 하나의 재생 요청도 인증, 추천, 인코딩 선택, 재생 최적화 등 수많은 서비스 호출을 발생시킨다.
• 장애 상황에서 엔지니어가 즉시 확인해야 하는 질문은 다음과 같다.
  • 어떤 서비스가 서로 의존하는가?
  • 특정 서비스 장애나 점검의 영향 범위는 어디까지인가?
  • 문제가 상위 의존 서비스에서 시작됐는가, 현재 서비스가 다른 서비스로 전파하고 있는가?
• 기존 관측 도구의 한계:
  • 메트릭은 성능 저하나 오류 같은 증상을 보여준다.
  • 로그는 개별 서비스의 동작을 보여준다.
  • 트레이스는 특정 요청의 흐름을 보여준다.
  • 그러나 시스템 전체의 지속적인 서비스 연결 구조를 한눈에 보여주지는 못한다.
• 여러 도구의 정보를 엔지니어가 머릿속으로 조합해야 하므로, 장애 대응이 느리고 오류가 발생하기 쉽다.

실시간 서비스 맵이 필요한 배경

• 넷플릭스는 수천 개의 마이크로서비스와 수백 개의 엔지니어링 팀으로 운영된다.
• 라이브 프로그램과 광고 지원 요금제 등 새로운 기능이 추가되면서 장애 조사와 모니터링의 신속성이 더욱 중요해졌다.
• 특히 라이브 이벤트는 긴 장애 분석을 기다릴 수 없기 때문에 실시간에 가까운 의존성 정보가 필요하다.
• 엔지니어 지원 요청을 분석한 결과, 다음과 같은 의존성 관련 질문이 반복적으로 제기됐다.
  • 상·하위 의존 서비스는 무엇인가?
  • 장애가 내 서비스 문제인가, 의존 서비스 문제인가?
  • 서비스를 중단하면 어떤 서비스가 영향을 받는가?
  • 메트릭에서 특정 서비스가 Unknown으로 표시되는 이유는 무엇인가?
  • 최근 호출 경로가 어떻게 바뀌었으며, 그것이 현재 문제와 관련 있는가?

기존 접근 방식에서 얻은 교훈

넷플릭스는 외부 그래프 데이터베이스와 상용 플랫폼을 검토하고, 다양한 저장 기술과 데이터 모델로 내부 프로토타입을 만들며 접근 방식을 발전시켰다.

• 실시간성이 중요하다
  • 하루 전 또는 몇 시간 전의 토폴로지는 자주 배포되는 환경에서는 이미 오래된 정보다.
  • 서비스 배포와 트래픽 변화에 따라 토폴로지가 거의 실시간으로 갱신되어야 한다.
• 대규모 환경에서는 확장성이 핵심이다
  • 소규모 환경에서 동작하는 저장소와 그래프 모델도 넷플릭스의 서비스 수와 트래픽 규모에서는 한계에 도달한다.
• 기존 관측 생태계와의 통합이 필요하다
  • 엔지니어가 새로운 도구와 작업 방식을 별도로 배워야 해서는 안 된다.
  • 기존 메트릭, 로그, 트레이스와 자연스럽게 연결되어야 한다.
• 데이터 품질이 중요하다
  • 누락되거나 잘못된 의존성 정보는 정보가 없는 것보다 위험하다.
  • 장애 상황에서 잘못된 원인이나 영향 범위를 판단하게 만들 수 있기 때문이다.
• 단일 데이터 소스만으로는 부족하다
  • 네트워크 연결 정보에는 애플리케이션 수준의 의미가 부족하다.
  • 애플리케이션 메트릭은 계측된 서비스만 포함할 수 있다.
  • 따라서 여러 관점의 데이터를 결합해야 한다.

Service Topology의 요구사항

넷플릭스가 구축하려 한 것은 정적인 아키텍처 다이어그램이 아니라, 운영 상태를 계속 반영하는 ‘살아 있는 지도’였다.

• 서비스 배포, 트래픽 변화, 신규 의존성 생성과 기존 의존성 제거를 실시간에 가깝게 반영한다.
• 호출 그래프 탐색 결과를 1초 이내에 제공해야 한다.
• 다음 두 계층을 모두 표현한다.
  • 네트워크 계층: 실제로 어떤 서비스가 통신하는가
  • 애플리케이션 계층: 어떤 API와 엔드포인트가 호출되는가
• 단순한 연결 관계 외에도 다음 정보를 함께 표시한다.
  • 서비스 상태와 가용성
  • 중요도 및 availability tier
  • 비즈니스 도메인
  • 서비스 소유 팀
  • 기타 운영 메타데이터
• 엔지니어가 탐색할 수 있는 UI뿐 아니라 자동화 시스템도 사용할 수 있는 프로그래밍 API를 제공한다.
  • 복원력 프레임워크
  • 영향 범위 계산기
  • 장애 대응 자동화 시스템

세 가지 데이터 소스를 결합하는 구조

핵심 설계는 하나의 데이터 소스에 의존하지 않고, 서로 다른 관점에서 별도의 의존성 그래프를 구축하는 것이다.

• 네트워크 계층, IPC 계층, 트레이싱 계층을 물리적으로 분리해 저장한다.
• 각 계층은 독립적으로 발전하고 병렬로 조회할 수 있다.
• 통합된 뷰가 필요할 때는 각 계층의 그래프를 동시에 탐색한 뒤 결과를 병합한다.
• 이 구조를 통해 여러 계층을 함께 조회하더라도 1초 이내의 응답 시간을 목표로 한다.
• 필요에 따라 통합된 그래프를 보거나, 특정 계층의 그래프만 독립적으로 분석할 수 있다.

eBPF 기반 네트워크 흐름

첫 번째 데이터 소스는 커널 수준에서 eBPF로 수집한 네트워크 흐름 정보다.

• 실제 네트워크 통신을 기반으로 어떤 서비스가 어떤 서비스에 연결되는지 기록한다.
• 애플리케이션 계측 여부와 관계없이 실제 트래픽이 발생하는 모든 서비스를 포착할 수 있다.
• 클러스터 간 통신과 애플리케이션 간 통신을 모두 파악할 수 있다.
• 네트워크 트래픽이라는 실제 운영 데이터를 사용하므로 네트워크 계층의 기준점 역할을 한다.
• 다만 네트워크 정보만으로는 어떤 API나 애플리케이션 기능이 호출됐는지 알기 어렵다.
• 따라서 eBPF 데이터는 포괄적인 연결 관계를 제공하지만, 애플리케이션 의미를 해석하려면 IPC나 트레이싱 같은 추가 데이터가 필요하다.

운영 관점의 의미

• 서비스 토폴로지는 장애 원인 분석을 단순화하고, 상·하위 의존성 및 장애 전파 경로를 빠르게 확인하게 한다.
• 서비스 중단이나 유지보수 전에 영향받을 서비스와 관련 팀을 파악할 수 있다.
• UI와 API를 함께 제공함으로써 사람의 장애 대응과 자동화된 복원력·영향 분석을 모두 지원한다.
• 정적인 아키텍처 문서보다 실제 트래픽과 현재 운영 상태를 반영하는 동적 지도가 분산 시스템에 더 유용하다.

실무적으로는 단일 관측 도구에 의존하기보다 네트워크 흐름, 애플리케이션 호출, 트레이싱 데이터를 결합해 의존성 정보를 구성하는 것이 좋다. 특히 대규모 마이크로서비스 환경에서는 실시간성, 데이터 정확성, 빠른 그래프 탐색, 기존 도구와의 통합을 초기 설계부터 핵심 요구사항으로 삼아야 한다.