왜 서비스 의존성 추적이 필요한가?
마이크로서비스 아키텍처를 운영하다 보면 어느 순간 **'이 서비스가 죽으면 어디까지 영향을 받지?'**라는 질문에 답하기 어려워집니다. 서비스가 10개일 때는 머릿속으로 그릴 수 있지만, 100개를 넘어가면 이야기가 달라져요. 장애가 터졌을 때 원인 서비스를 찾는 데만 몇 시간을 쓰는 상황이 반복됩니다.
넷플릭스가 공개한 서비스 토폴로지 맵은 바로 이 지점을 해결합니다. 단순한 다이어그램이 아니라 실시간으로 살아 움직이는 의존성 지도예요. 어떤 서비스가 어떤 서비스를 호출하고, 어느 구간에서 지연이 발생하며, 장애가 어디로 전파되는지를 한눈에 볼 수 있게 만든 것이 핵심입니다.
이 글에서는 넷플릭스의 접근 방식을 뜯어보면서, 우리 팀에 적용할 수 있는 실무 포인트를 정리해보겠습니다.
서비스 토폴로지 맵의 핵심 원리
넷플릭스의 접근은 크게 세 단계로 나뉩니다.
1. 텔레메트리 수집 (Telemetry Collection)
각 서비스는 자신이 호출한 대상과 응답 시간, 에러율 등을 구조화된 이벤트로 내보냅니다. 넷플릭스는 내부적으로 Edgar라는 분산 트레이싱 시스템을 사용해요. OpenTelemetry로 비유하면 Span과 Trace 개념과 동일합니다.
# OpenTelemetry 기반 의존성 수집 예시
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
# 트레이서 초기화 (서비스별로 한 번만)
trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)
# 외부 서비스 호출 시 의존성 정보를 Span 속성으로 기록
def call_downstream_service(service_name: str, endpoint: str):
with tracer.start_as_current_span(f"call-{service_name}") as span:
span.set_attribute("peer.service", service_name) # 호출 대상 서비스
span.set_attribute("http.url", endpoint) # 엔드포인트
span.set_attribute("dependency.type", "http") # 의존성 유형
# ... 실제 HTTP 호출 로직
2. 그래프 구축 (Graph Construction)
수집된 Span 데이터를 방향성 그래프(Directed Graph) 로 변환합니다. 노드는 서비스, 엣지는 호출 관계가 되죠. 여기서 중요한 건 시간 윈도우 단위로 집계한다는 점입니다. 5분 단위 슬라이딩 윈도우로 그래프를 만들면 "지금 이 순간"의 의존성 상태를 볼 수 있어요.
3. 실시간 시각화 (Live Visualization)
구축된 그래프를 UI로 렌더링합니다. 넷플릭스는 여기에 헬스 상태(Healthy/Degraded/Failing) 를 색상으로 입혀서, 장애 전파 경로를 즉시 파악할 수 있게 했습니다. 이 부분이 단순 모니터링 대시보드와 토폴로지 맵의 결정적 차이예요.
💡 실무 팁: 처음부터 완벽한 그래프를 만들려고 하지 마세요. 우선 서비스 간 호출 로그만이라도 구조화해서 쌓아두면, 나중에 그래프로 승격시키기 훨씬 수월합니다.
주의사항과 흔한 함정
⚠️ 카디널리티 폭발(Cardinality Explosion)
서비스가 늘어나면 엣지 수가 기하급수적으로 증가합니다. 서비스 100개면 이론상 엣지는 10,000개까지 가능하죠. 모든 엣지를 실시간 렌더링하면 브라우저가 죽습니다. 넷플릭스도 이 문제를 해결하기 위해 임계값 기반 필터링과 클러스터링을 적용했다고 알려져 있어요.
⚠️ 샘플링 편향(Sampling Bias)
트레이스 데이터는 보통 1~10%만 샘플링합니다. 저트래픽 서비스는 샘플에 아예 안 잡힐 수 있어요. 이 경우 그래프에 노드가 누락되어 "존재하지 않는 의존성" 처럼 보이는 착시가 발생합니다. 반드시 샘플링 정책을 그래프 해석 가이드와 함께 문서화하세요.
⚠️ 국내 SI 환경에서의 적용 맥락
국내 SI 프로젝트에서는 모놀리식 레거시 + 신규 MSA가 혼재된 경우가 많습니다. 이때 토폴로지 맵은 레거시 구간에서 끊깁니다. 레거시 구간은 별도로 APM(Scouter, Jennifer 등) 으로 보완하고, MSA 구간만 토폴로지로 관리하는 하이브리드 접근이 현실적입니다. 또한 금융권처럼 망분리가 된 환경에서는 외부 SaaS형 옵저버빌리티 도구를 쓸 수 없으니, 셀프호스팅 가능한 오픈소스 스택(Tempo + Grafana 등)을 먼저 검토하세요.
정리: 그래프는 수단이지 목적이 아니다
넷플릭스의 사례에서 진짜 배울 점은 '예쁜 다이어그램'이 아니라 '의사결정 속도' 입니다. 장애가 났을 때 "어디부터 봐야 하지?"라는 질문에 5초 안에 답할 수 있다면, 그게 성공한 토폴로지 맵이에요.
다음 단계 학습 방향
- OpenTelemetry Collector 로컬 환경에서 띄워보기 → 서비스 2~3개로 최소 그래프 만들기
- Grafana Tempo + Node Graph 패널 로 토폴로지 시각화 실습
- SLO 기반 알림 과 결합해 "의존성 그래프 + 에러 버짓" 대시보드 구성
토폴로지 맵은 한 번 만들면 끝이 아니라, 서비스가 변할 때마다 함께 진화해야 하는 살아있는 문서입니다. 작게 시작해서 팀의 운영 문화로 정착시키는 것이 핵심이에요.
함께 보면 좋은 글