Observability관측 가능성
쉽게 이해하기
대규모 서비스는 오류 알림만으로는 부족합니다. 왜 느려졌는지, 어느 구간에서 막혔는지, 특정 사용자만 문제가 생기는지 같은 예상 못 한 질문이 바로 터집니다. 모니터링이 문제가 있음을 알려준다면, 관측 가능성은 왜를 찾아가게 해 줍니다. 이를 위해 서비스는 로그(텍스트 이벤트), 메트릭(시간에 따른 수치), 트레이스(요청의 hop-by-hop 경로)를 함께 남기고, 같은 요청에 붙는 trace ID를 모든 신호에 실어 경로·오류·리소스 지표를 한 화면에서 연결해 봅니다. 택배 상자 운송장 번호로 접수부터 배송까지를 추적하는 것과 같습니다. 실무에서는 OpenTelemetry(OTel)로 애플리케이션을 계측하고 Collector를 사이에 둬 샘플링·PII 마스킹·벤더 전환을 구성으로 바꿉니다. 완료된 트레이스를 보고 에러·지연은 100% 남기고 평시 트래픽은 낮은 비율로 남기는 tail-based 샘플링을 권장합니다.
비유와 예시
- 야간 배치 추론 지연 추적: 일부 GPU 작업이 14초 지연. 트레이스에서 특정 DB 호출 뒤 CUDA 커널 대기가 길어진 것을 확인해 병목을 제거.
- 메시지 큐 경계의 오류 상관: 결제 요청이 큐를 건너며 trace ID가 끊김. 메시지 헤더에 컨텍스트를 직렬화하자 생산자 로그와 소비자 스팬이 한 트레이스로 묶임.
- LLM 비용 이상 탐지: 스팬에 모델명·토큰 수·예상 비용을 속성으로 넣고 tail-based 샘플링으로 고비용 케이스만 보존해 프롬프트 팽창 원인 파악.
한눈에 비교
| 모니터링 | 관측 가능성 | 프로파일링 | |
|---|---|---|---|
| 초점 | 알려진 지표 감시 | 예기치 않은 질문에 답 | 코드 레벨 성능 분석 |
| 단위 | 집계 시계열 | 고카디널리티 이벤트·트레이스 | 프로세스·스레드 |
| 상관 | 낮음(대시보드 중심) | 높음(trace ID 연계) | 없음(단일 프로세스) |
| 사용 시점 | 운영 지표 경보 | 원인 분석·경험 개선 | 성능 튜닝 |
| 비용 관리 | 지표 제한 | 샘플링·필터링 | 개발기/테스트 위주 |
원인 규명이 목표라면 트레이스·로그·메트릭을 trace ID로 묶는 관측 가능성이 가설 검증을 빠르게 돕습니다.
어디서 왜 중요한가
- OpenTelemetry Collector 중간층: 백엔드 교체, 샘플링, 민감정보 마스킹을 재배포 없이 변경.
- Kubernetes 운영: 사이드카+게이트웨이 모드로 각 Pod 텔레메트리를 수집·집중 전송.
- 샘플링 전략: 에러·슬로우 보존, 일상 트래픽 저비율 유지로 비용/가치 균형.
- GPU 워크로드: 장치·컨테이너·애플리케이션 맥락 통합으로 병목/스케줄링 실패 예방.
- 실무 관행 전환: trace ID 상관 표준화로 장애 분석 시간 단축.
자주 하는 오해
- ❌ 관측 가능성은 멋진 대시보드다 → ✅ 핵심은 상관관계이며, trace ID가 로그·메트릭·트레이스를 묶습니다.
- ❌ 100% 트레이스 수집이 필수다 → ✅ 테일 샘플링으로 에러/지연 전량, 평시 트래픽은 저비율.
- ❌ 앱에서 바로 벤더로 보내는 게 단순하다 → ✅ Collector로 벤더 교체·필터링·샘플링을 구성화.
대화에서는 이렇게
- "이번 장애 트레이스에 trace ID가 로그에 없네요. 로거 컨텍스트 연결부터 고치겠습니다."
- "백엔드 마이그레이션 전까지 Collector에서 이중 전송으로 팬아웃해 주세요. 앱 재배포 없이 전환하고 싶습니다."
- "GPU 배치는 tail-based로 5초 이상만 보존합시다. 스토리지 비용이 큽니다."
- "메트릭 라벨에 사용자 ID는 금지, 요청 단위 정보는 스팬 속성으로 남깁니다."
- "큐 경계에서 OpenTelemetry 컨텍스트가 끊깁니다. 메시지 헤더에 traceparent 주입 패치하겠습니다."
함께 읽으면 좋은 용어
참고 자료
- Observability primer
로그·메트릭·트레이스와 trace/span 상관관계를 설명하는 OpenTelemetry 공식 primer.
- CNCF Observability Whitepaper
CNCF TAG Observability의 관측 가능성 개념, 신호, 클라우드 네이티브 운영 관점 정리.
- Architecture Requirements (OpenTelemetry Community Demo)
OTel 데모의 Collector 배치·신호 수집 구조.
- GPU Monitoring Reference Architecture
GPU 텔레메트리를 컨테이너·애플리케이션 맥락과 통합하는 관측 아키텍처 참조.
- What Is Observability? Fundamentals & Architecture
관측 가능성의 목적, 사용 사례, 데이터 기반 운영 관점 개요.