Observability & SLI-SLO

1. Overview

관측 가능성과 서비스 수준 지표(Observability & SLI-SLO)는 블랙박스처럼 닫혀 있는 거대한 분산 시스템 내부에서 무슨 일이 벌어지고 있는지 꿰뚫어 보고, "우리 시스템이 충분히 건강한가?"라는 모호한 질문을 0과 1의 냉혹한 수학적 지표로 계량화하는 SRE(사이트 신뢰성 엔지니어링)의 첫 번째 눈(Eye)을 해부합니다.

학습자는 단순히 CPU 사용량을 보는 전통적인 모니터링(Monitoring)을 넘어, 시스템이 왜 터졌는지 인과관계를 추적하는 **관측 가능성(Observability)의 3본주(Metrics, Logs, Traces)**를 뜯어봅니다. 나아가 엔지니어의 감(Feeling)이 아닌, 유저가 느끼는 진짜 고통을 수치화하는 **SLI(서비스 수준 지표)**와, 회사 전체가 합의한 타협점인 **SLO(서비스 수준 목표)**의 철학을 장악합니다. 마지막으로, "우리는 1달에 43분 동안은 합법적으로 서버를 꺼트려도 된다"는 극단적인 자유도인 **에러 버젯(Error Budget)**을 통해 속도(배포)와 안정성(신뢰성) 사이의 영원한 딜레마를 지배하는 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Observability (관측 가능성): Metrics(수치), Logs(이벤트), Distributed Traces(분산 추적 - TraceID).
• SRE Metrics: SLI (Indicator), SLO (Objective), SLA (Agreement - 재무적 배상).
• Error Budget (에러 버젯): SLO 100% 달성의 허상과, 배포 속도를 조절하는 수학적 브레이크.
• The 4 Golden Signals: Latency(지연), Traffic(트래픽), Errors(오류), Saturation(포화도).

Out-of-Scope

• Prometheus/Grafana/Datadog 설정법: 특정 모니터링 툴 설치 및 쿼리 작성(PromQL) → 09-03 Monitoring & Logging 영역.
• 재난 복구(DR) 아키텍처: Multi-region 장애 복구 세팅 → 07-03-04 Disaster Recovery 영역으로 위임.

Boundaries

• Monitoring vs Observability: 모니터링은 "CPU가 90%를 넘었네? 알람 울려!"라는 '알려진 문제(Known Unknowns)'에 대한 수동적인 뷰(View)입니다. 반면 관측 가능성은 유저가 결제 실패 에러를 뿜었을 때, "A 서버의 로그 → B 서버의 트레이스 → C DB의 느린 쿼리 메트릭"을 하나로 꿰어내어 "도대체 왜 터졌는지(Unknown Unknowns)"를 능동적으로 찾아낼 수 있게 시스템 코드를 악기처럼 조율(Instrumentation)해 놓은 상태를 뜻함을 명확히 구분합니다.

3. Counterexample

• 100% SLO의 저주: "우리 시스템은 단 1초도 죽으면 안 돼! SLO는 100%다!"라고 사장님이 선언했습니다. 개발팀은 버그가 무서워서 1년에 2번만 배포하고, 서버를 10배로 증설해 회사의 현금을 탕진합니다. 구글 SRE의 핵심 철학은 "100% 신뢰성은 틀린 목표다"입니다. 인터넷 자체가 끊기거나 유저의 폰이 꺼지는 등 외부 변수 때문에 유저는 100%를 체감할 수 없습니다. 99.9%로 합의하고 남은 0.1%(약 43분/월)를 '에러 버젯'으로 삼아 미친 듯이 혁신적인 배포를 해야 함을 간과한 리더십의 안티 패턴입니다.
• 무의미한 CPU 알람의 늪: 서버 CPU가 80%를 넘자 슬랙(Slack)으로 알람(Alert)이 미친 듯이 쏟아집니다. 개발자는 새벽에 깨서 서버를 증설했습니다. 그런데 정작 유저 트래픽은 0이었습니다. 단순한 배치 크롤러가 CPU를 먹고 있었을 뿐입니다. 유저에게 아무런 고통(Pain)을 주지 않는 내부 리소스 수치(CPU)를 SLI로 잡고 알람을 울려 엔지니어를 번아웃(Alert Fatigue) 시키는 전형적인 낡은 모니터링의 참사입니다.

4. Prerequisites

• 분산 시스템 아키텍처 (Basic): 여러 마이크로서비스 간의 복잡성. (07-01-02 Microservices)
• 오차와 네트워크 지연 (Basic): 통신의 불확실성. (07-02-01 8 Fallacies)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 블랙박스를 뚫는 시선, 관측 가능성 (Observability's 3 Pillars)

• Why to Learn: MSA 환경에서 장애가 터졌을 때 서버 10대의 로그를 열어놓고 grep을 치는 노가다를 끝내고, 단 한 번의 클릭으로 병목 지점을 핀포인트(Pinpoint)로 찾아내기 위함입니다.
• What to Learn:
  • Concepts: Observability (관측 가능성), Metrics (메트릭 - 계량 가능 수치), Logs (로그 - 불변의 이벤트), Traces (분산 추적 - 흐름).
  • Skills: 애플리케이션 코드 내에 적절한 계측(Instrumentation) 로직 삽입.
• How to Learn:
  • 1단계: 장님의 코끼리 만지기: 결제가 실패했습니다. 결제 서버 로그엔 Timeout만 찍혀 있고, 재고 서버 로그엔 Out of Stock이 찍혀 있습니다. 이 둘이 같은 유저의 동일한 요청인지 알 방법이 없습니다. 분산 환경의 추적 상실을 해부합니다.
  • 2단계: 3본주(Pillars)의 결합: 클라이언트가 요청을 찌를 때 TraceID(tx-123)를 생성합니다. 결제 서버, 재고 서버, DB가 모두 이 tx-123을 로그(Log)에 달아놓고, 각 구간별 걸린 시간(Metric)을 전송합니다. 대시보드에서 tx-123을 검색하면 5개 서버를 관통하는 완벽한 타임라인(Trace)이 그려지는 마법을 뜯어봅니다.
• Implement: 파이썬 Context Variable을 이용한 TraceID 릴레이. 웹 프레임워크 미들웨어에서 uuid를 생성해 전역 컨텍스트에 넣고, Order() -> Payment() -> DB()로 이어지는 모든 함수의 print(log) 앞에 [Trace-ID]를 자동으로 박아 넣는 데모.

Recommended

Core Topic 02: 서비스의 맥박, 4가지 황금 신호 (The 4 Golden Signals)

• Why to Learn: 대시보드에 떠 있는 수백 개의 화려한 그래프 중 당장 새벽 3시에 엔지니어를 깨워야 할 진짜 치명적인 신호를 골라내는 안목을 세우기 위함입니다.
• What to Learn:
  • Concepts: The 4 Golden Signals (Latency, Traffic, Errors, Saturation), Alert Fatigue (경고 피로), RED Method.
  • Skills: 유저의 고통(Pain)과 직결되는 인디케이터에만 알람(PagerDuty) 연결하기.
• How to Learn:
  • 1단계: 버려야 할 신호 (CPU/RAM): DB 서버의 CPU가 95%입니다. 하지만 쿼리는 0.1초 만에 잘 나가고 에러도 0입니다. 이럴 때 알람이 울리면 엔지니어는 '늑대 소년' 효과로 진짜 장애가 났을 때 알람을 무시하게 됩니다(Alert Fatigue).
  • 2단계: 4대 황금 신호: 구글 SRE가 정의한 진리. 1) Latency(얼마나 느린가?), 2) Traffic(요청이 얼마나 쏟아지나?), 3) Errors(유저가 에러 화면을 보는가?), 4) Saturation(DB 커넥션 풀처럼 꽉 차기 직전의 한계치가 있는가?). 이 4가지만 모니터링하면 서비스의 생사가 완벽히 통제됨을 해부합니다.
• Implement: 4 Golden Signals 모니터링 워치독 로직. 큐에 들어오는 로그를 분석하여 1) req/sec(Traffic), 2) avg_time(Latency), 3) 5xx_count(Errors)를 1초마다 출력하고, 큐의 남은 크기(Saturation)가 $90\%$ 를 넘을 때만 터미널을 빨간색으로 칠하며 경고를 뱉어내는 스크립트.

Practical

Core Topic 03: 유저의 고통을 수치화하라, SLI와 SLO (SLI, SLO & SLA)

• Why to Learn: "우리 서버는 좀 느려"라는 모호한 징징거림을 끝내고, "전체 HTTP 요청 중 $99.9\%$ 는 200ms 이내에 응답한다"는 차갑고 명확한 엔지니어링 계약을 체결하기 위함입니다.
• What to Learn:
  • Concepts: SLI (Service Level Indicator - 측정 지표), SLO (Service Level Objective - 내부 목표치), SLA (Service Level Agreement - 외부 배상 계약).
  • Skills: 비즈니스 목표에 맞는 적절한 SLI 정의 및 99.9% (3 Nines) 임계치 계산.
• How to Learn:
  • 1단계: SLI (무엇을 측정할 것인가?): 좋은 SLI는 유저의 관점입니다. "서버의 메모리 여유량"은 유저와 상관없습니다. "유저가 '재생' 버튼을 눌렀을 때 1초 안에 영상이 켜지는 비율"이 진짜 훌륭한 SLI(지표)임을 뜯어봅니다.
  • 2단계: SLO와 SLA의 차이: SLO는 회사 내부의 목표(예: $99.9\%$)입니다. SLA는 유저(고객사)와 맺는 돈이 걸린 계약(예: $99.5\%$)입니다. SLO를 달성하지 못하면 팀 회식을 못 하고, SLA를 달성하지 못하면 회사 통장에서 배상금이 빠져나가는 극명한 차이를 해부합니다.
• Implement: Nines($99.9\%$) 다운타임(Downtime) 계산기. 일(Day), 주(Week), 월(Month), 년(Year) 단위로 99%(2 Nines)부터 99.999%(5 Nines)까지 허용 가능한 오프라인 시간을 분/초 단위로 계산하여 출력하는 툴. (예: 99.9% → 월 43.8분 허용).

Advanced

Core Topic 04: 혁신의 브레이크, 에러 버젯 (Error Budget)

• Why to Learn: 개발팀은 새로운 코드를 빨리 배포(속도)하려 하고, 운영팀은 서버가 터질까 봐 배포를 막는(안정성) 영원한 사일로(Silo) 전쟁을 수학적 룰 하나로 종식시키기 위함입니다.
• What to Learn:
  • Concepts: Error Budget (에러 예산 = 100% - SLO), Deployment Freeze (배포 동결), Reliability as a Feature.
  • Skills: 에러 버젯 소진율(Burn rate)에 따른 배포 파이프라인 자동 차단(Freeze) 룰 세팅.
• How to Learn:
  • 1단계: 에러 버젯의 탄생: 한 달 SLO가 99.9%라면, 반대로 0.1%(약 43분)는 "우리 시스템이 합법적으로 죽어 있어도 되는 시간"입니다. 이 43분을 '에러 버젯'이라고 부릅니다.
  • 2단계: 예산의 탕진과 동결: 개발팀이 코드를 배포하다 서버를 30분 날려 먹었습니다. 이제 에러 버젯이 13분 남았습니다. 며칠 뒤 또 장애를 내서 15분을 까먹어 버젯이 $-2$ 분이 되었습니다(목표 실패). SRE 팀은 즉각 모든 신규 피처(Feature) 배포를 멈추고(Freeze), 남은 한 달 동안 오직 버그 수정과 안정화 코드만 짜도록 전사 규칙을 강제하는, 속도와 안정성의 기막힌 통제력을 뜯어봅니다.
• Implement: 에러 버젯 통제 시뮬레이션. budget = 43 (분). 랜덤하게 deploy_feature()를 시도할 때 성공하면 통과, 실패 시 budget -= 10 분 차감. 만약 budget < 0이 되면 deploy_feature() 호출 시 [DENIED: Error Budget Exhausted] 에러를 뱉어내며 배포를 튕겨내는 상태 머신(State Machine) 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Reliability and Observability
• [P5] SFIA - Service Management (ITMG) - Service Level Management (SLMO)

Secondary

• [Site Reliability Engineering: How Google Runs Production Systems] - SLIs, SLOs, SLAs, and Error Budgets
• [Distributed Systems Observability] Cindy Sridharan - The Three Pillars of Observability

Industry

• [DatadogHQ] - The 4 Golden Signals of Monitoring
• [Google Cloud Architecture Center] - SRE fundamentals: SLIs, SLAs and SLOs

9. Final Checklist

Primary

• 전통적인 서버 헬스체크(Ping, CPU 모니터링) 방식이 MSA 환경에서 왜 원인을 찾을 수 없는 무용지물이 되며, 관측 가능성(Observability)의 3요소가 이를 어떻게 구원하는지 설명할 수 있는가?
• 수천 개의 대시보드 지표 중에서 구글 SRE가 꼽은 딱 4가지 황금 신호(Latency, Traffic, Errors, Saturation)가 유저의 고통(Pain)을 가장 잘 대변하는 이유를 증명할 수 있는가?

Secondary

• "데이터베이스 접속 실패 횟수"보다 "결제 API의 HTTP 500 에러 비율"이 훨씬 더 훌륭한 SLI(서비스 수준 지표)인 이유를 '사용자 관점(User Journey)'의 철학으로 해부할 수 있는가?
• SLO를 99%(2 Nines)에서 99.99%(4 Nines)로 높이려 할 때, 허용되는 월간 장애 시간이 7시간에서 4분으로 줄어들며 투입되는 인프라 비용이 기하급수적으로 폭발하는 역학을 논증할 수 있는가?

Industry

• 이번 달 에러 버젯(Error Budget)이 모두 소진(Exhausted)되었을 때, SRE 팀이 개발팀의 신규 피처(Feature) 배포를 강제로 동결(Freeze)하고 안정화 작업만 강제하는 정책의 비즈니스적 가치를 평가할 수 있는가?
• 분산 추적(Distributed Tracing) 시스템에서 A → B → C로 이어지는 API 호출 흐름을 하나의 타임라인으로 묶기 위해, 클라이언트 첫 요청 시 생성한 TraceID를 어떻게 컨텍스트(Context)로 릴레이(Propagation) 할 것인지 아키텍처 관점으로 설계할 수 있는가?