대규모에서 로그, 지표, 트레이스를 위한 observability 전략은 무엇인가요?

Question

IT Interview Practice · Accepted Answer

관측 가능성(observability)은 **세 가지 기둥** — **로그(logs)**, **지표(metrics)**, **트레이스(traces)** — 에 기반하며, 목표는 직접 검사하기에는 너무 큰 시스템에 대해 "무엇이 잘못되었고 왜인가"에 답하는 것입니다. 대규모에서 전략은 상관관계(correlation), 샘플링, 비용에 관한 것입니다.

## 세 가지 기둥

| 기둥 | 답하는 것 | 도구 |
|---|---|---|
| 지표 | 무언가 잘못되었나?(비율, 지연) | Prometheus, Grafana |
| 트레이스 | 흐름의 어디에서? | OpenTelemetry, Jaeger |
| 로그 | 정확히 무슨 일이 있었나? | ELK, Loki |

```text
지표 알림 ─▶ 트레이스가 느린 서비스를 정확히 짚음 ─▶ 로그가 원인을 설명
   (넓음)              (경로)                          (상세)
```

## 서로 상관되게 만들기

trace/correlation ID는 지표 레이블, 로그 라인, span을 관통해야 합니다. 그래야 이들 사이를 전환(pivot)할 수 있습니다.

```text
로그 라인:  level=error trace_id=abc123 service=payments msg="gateway timeout"
                       ^^^^^^^^^^^^^^^ 동일한 id가 트레이스 + 지표에도 나타남
```

## 대규모 고려사항

```text
✓ 표준화: 모든 서비스에 OpenTelemetry
✓ 구조화된(JSON) 로그 사용 — grep만이 아니라 질의 가능
✓ 트레이스 샘플링(예: 모든 오류 + 성공의 1% 유지)으로 비용 제어
✓ SLO를 정의하고 잡음이 아니라 증상(지연/오류율)에 알림
✓ 대시보드에 RED/USE 방법(Rate, Errors, Duration)
```

## 함정

모든 것을 100%로 로깅하는 것은 감당할 수 없고 신호를 묻어버립니다. 대신 샘플링하고, 구조화하고, SLO에 알림을 거세요.

## 왜 중요한가

수백 개의 서비스가 있으면 SSH로 들어가서 들여다볼 수 없습니다. 관측 가능성은 프로덕션 동작을 이해하는 유일한 방법입니다.

이기는 전략은 상관되고, 샘플링되며, SLO 주도적입니다. 텔레메트리 저장 비용으로 파산하거나 온콜을 잡음에 묻지 않으면서 실제 문제를 빠르게 드러냅니다.

지표	무언가 잘못되었나?(비율, 지연)	Prometheus, Grafana
트레이스	흐름의 어디에서?	OpenTelemetry, Jaeger
로그	정확히 무슨 일이 있었나?	ELK, Loki

세 가지 기둥

서로 상관되게 만들기

대규모 고려사항

함정

왜 중요한가

관련 질문