Observability & Telemetry Physics
분산 시스템의 내부 상태를 외부 출력을 통해 파악하는 가관측성의 원리와, 로그/메트릭/트레이스를 결합한 고차원 텔레메트리 연쇄 작용을 다루는 학습 노드입니다.
sys.entry
M
Me
hyunyoun's Blog
posts6 min read
1. Overview
가관측성 및 텔레메트리 물리학(Observability & Telemetry Physics, OTP)은 복잡해진 분산 시스템의 내부에서 어떤 물리적 현상이 벌어지는지, 직접 들여다보지 않고도 밖으로 내뱉는 신호(Signal)들을 수리적으로 조합하여 완벽하게 추론해내는 '시스템 투시 공학'입니다.
학습자는 시스템의 상태를 수치로 기록하는 메트릭(Metrics), 이벤트의 흐름을 텍스트로 남기는 로그(Logs), 그리고 요청이 수많은 하드웨어 노드를 거치는 경로를 추적하는 **트레이스(Traces)**의 3대 요소를 배웁니다. 특히, 고밀도 지표(High Cardinality)를 성능 저하 없이 수집하는 물리적 수순과, 수만 개의 서비스 요청 중 단 하나의 지연 원인을 수리적으로 찾아내는 분산 트레이싱의 물리학을 익힙니다. 이를 통해 장애 발생 시 '무엇(What)'이 아닌 '왜(Why)' 발생했는지를 1초 안에 밝혀내는 하이엔드 운영 가시성 역량을 확보합니다.
2. Scope & Boundaries
In-Scope
- Three Pillars: Logging, Metrics, Tracing의 수리적 수집 및 저장 모델
- Telemetry Pipelines: 데이터 정제, 가공, 하드웨어 전송의 물리적 연쇄 작용
- Distributed Tracing Mechanics: Span ID와 Trace ID를 통한 물리적 요청 추적 수순
- Metric Dynamics: Counter, Gauge, Histogram, Summary의 수치적 해석법
- Observability vs Monitoring: 사후 대응(Monitoring)과 사전 추론(Observability)의 물리적 차이
Out-of-Scope
- 특정 모니터링 도구(Grafana, Datadog)의 UI 대시보드 꾸미기 상세 (도구 활용 영역으로 위임)
- 네트워크 패킷 단위의 로우 레벨 캡처 기술 (08-04-XX 영역에서 분담)
Boundaries
- OTP vs. GPD: GPD(09-03-04)가 '지표를 보고 배포 여부를 결정'하는 제어에 집중한다면, OTP는 그 '지표 자체를 어떻게 수집하고 시스템의 진실로 승화시킬 것인가'라는 데이터 물리 자체에 집중하여 구분합니다.
3. Counterexample
- 단순히 "로그 많이 찍기"라 설명하는 것은 OTP 학습이 아닙니다. 왜 로그를 구조화(Structured)하지 않았을 때 대규모 하드웨어팜에서 검색 연산 비용이 수리적으로 폭증하는지 증명할 수 있어야 하며, 트레이싱에서 '샘플링(Sampling)' 비율이 가용성 지표의 수리적 정확도와 성능 오버헤드 사이에서 어떻게 물리적 균형을 이루는지 논증하지 못한다면 OTP의 정수를 이해하지 못한 것입니다.
4. Prerequisites
- Networking & Communication (Basic): 08-01-XX의 통신 지연 및 패킷 흐름 이해가 필수입니다.
- Operating Systems & System Mechanics (Recommended): 03-01-XX의 시스템 호출 소요 시간 및 I/O 오버헤드 이해가 권장됩니다.
5. Learning Map
- Signals of Life: 시스템이 살아있음을 알리는 메트릭(숫자)과 로그(글)를 수집합니다.
- The Golden Path: 요청 하나하나가 수많은 서버를 통과하는 물리적 여정(Trace)을 기록합니다.
- The Power of Context: 로그와 메트릭을 트레이스 ID로 묶어, 시스템의 모든 점을 선으로 잇는 수리적 통합을 배웁니다.
- Transparent Core: 블랙박스였던 시스템의 내부를 밝은 대낮처럼 드러내는 하이엔드 투시 레이더를 완성합니다.
6. Learning Topics
Basic
Core: 가관측성의 3요소와 텔레메트리 (The Three Pillars)
- Why to Learn: 시스템 붕괴 징후를 숫자로 감지하고, 발생한 일을 글자로 기록하기 위해서입니다.
- What to Learn:
- Metrics: 시계열(Time-series) 기반의 수치 데이터 물리 수집
- Logging: 이벤트 발생 시점의 스냅샷을 텍스트로 보존하는 법
- Telemetry Pipeline: 신호를 하드웨어 저장소로 안전하게 옮기는 흐름
- How to Learn:
- 간단한 서버에 프로메테우스(Prometheus) 메트릭을 심고, 요청 수() 가 증가함에 따라 그래프가 물리적으로 솟아오르는 것 관찰 실습
- 비구조화 로그(Plain Text)를 JSON 구조화 로그로 바꾸었을 때의 수리적 검색 속도 성능 비교
- Implement: 현재 CPU 점유율을 1초마다 메트릭 파일로 기록하는 기초
SignalCollector
Recommended
Core: 분산 트레이싱과 요청 추적 (Distributed Tracing)
- Why to Learn: "A서버가 느린지, B서버가 느린지"를 수리적으로 확신하여 핑퐁 게임을 끝내기 위함입니다.
- What to Learn:
- Tracing Context: 요청 헤더를 통해 ID를 물리적으로 전달(Propagation)하는 수순
- Spans & Parent-Child Rel: 작업 간의 시간적/논리적 인과 관계 형상화
- Root Cause Analysis (RCA): 전체 경로 중 병목(Bottle-neck)인 하드웨어 노드를 식별하는 법
- How to Learn:
- Jaeger나 OpenTelemetry를 사용하여, 마이크로서비스 3곳을 거치는 요청의 '간트 차트' 형태 물리 형상을 분석하는 실습
- 특정 구간의 소요 시간()이 99분위()에서 튀는 원인을 수치적으로 추적하는 훈련
- Implement: 요청마다 유니크한 ID를 발급하고 헤더에 실어 다음 서버로 넘기는
ContextPropagator
Practical
Core: 메트릭의 유형과 수치적 해석 (Metric Dynamics)
- Why to Learn: 숫자에 속지 않고, 시스템의 실제 건강 상태를 수학적으로 판별하기 위해서입니다.
- What to Learn:
- Gauges vs Counters: 휘발성 수치와 누적 수치의 수리적 용도 차이
- Histograms & Percentiles: 평균()이 놓치는 '꼬리 지연(Tail Latency)'의 물리적 위험 감지
- Alerting Threshold: 초당 에러 수치()가 얼마일 때 알람을 보낼지의 수리적 결정 수순
- How to Learn:
- 평균 응답 속도는 100ms인데 5%의 사용자가 5s를 기다리는 '비대칭 지연' 상황을 히스토그램으로 수치 증명하는 실습
- 카운터 지표의 '변화율(Rate)'을 계산해 트래픽 폭주 시점을 수리적으로 예견하는 훈련
- Implement: 데이터 스트림에서 지연 시간을 실시간 연산하는
PercentileEngine
Advanced
Core: 고밀도 가시성과 연관 분석 (Observability High-end)
- Why to Learn: 수조 개의 신호 중에서 "VIP 사용자의 주문 실패"와 같은 특정 정황(Context)을 소실 없이 찾아내기 위함입니다.
- What to Learn:
- High Cardinality Management: 수만 개의 태그(ID, 지역 등)가 결합될 때의 하드웨어 부하 제어
- Correlation ID: 로그, 메트릭, 트레이스를 강력한 수리적 끈으로 묶는 법
- Predictive Analytics: 과거 지표의 물리적 추세를 분석하여 미래 장애를 수치적으로 예방
- How to Learn:
- 수천 개의 고유 ID로 필터링을 시도할 때 저장소의 메모리 점유율() 수치 분석 실습
- 로그 파일의 특정 에러 행에서 버튼 클릭 한 번으로 해당 시점의 트레이스 그래프로 물리 전이되는 통합 분석 체계 연구
- Implement: 여러 시그널 소스에서 동일 ID의 데이터를 취합하여 장애 시나리오를 재구성하는
TraceAssembler
7. Terminology
8. References
Primary
- [P1] CS2023 - NC/Networking and Communication (Network management and monitoring) — Monitoring standards.
- [P5] SFIA v9 - Software Engineering / Programming/software development (Monitoring & Reporting) — Professional skills.
Secondary
- [Observability Engineering] Charity Majors — The modern foundation.
- [Distributed Tracing in Practice] Austin Parker — Technical implementation.
Industry
- [OpenTelemetry Specification] — The global standard for telemetry data.
- [Google SRE Book: Monitoring Distributed Systems] — Best practices at scale.
9. Final Checklist
Primary
- '모니터링'이 "무엇이 잘못되었나"를 묻는다면, '가관측성'이 "왜 잘못되었나"를 수리적으로 어떻게 대답하는지 설명 가능한가? (P1)
- '메트릭' 수집 주기가 하드웨어 부하와 가시성 정밀도 사이에서 갖는 물리적 트레이드오프를 기술할 수 있는 가? (P1)
Secondary
- 'Trace ID'가 서비스 간 통신 과정(HTTP, RPC)에서 소실되지 않도록 보장하는 물리적 컨텍스트 전파 수순을 소통 가능한가?
- **구조화된 로깅(Structured Logging)**이 검색 도구에서 'Full Text Search'보다 왜 수리적으로 압도적 성능을 내는지 논증할 수 있는 가?
Industry
- 실무 환경에서 '로그 폭발'로 인한 하드웨어 비용 상승을 막기 위한 '동적 레벨 제어' 전략을 수치적으로 제안할 수 있는 가? (SFIA)
- OpenTelemetry를 활용해 특정 하드웨어 벤더에 종속되지 않는 독립적인 텔레메트리 파이프라인을 물리적으로 설계할 수 있는 가?