애플리케이션 모니터링을 처음부터 어떻게 설계하시겠어요?

Question

IT Interview Practice · Accepted Answer

인프라에서 출발하는 bottom-up이 아니라 **사용자가 체감하는 것에서 시작하는 top-down**으로 시작하세요. 요청이 실패하고 있다면 아무리 안정적인 호스트 군집도 쓸모없으므로, 먼저 사용자 대면 **SLI** — **latency**, **error rate**, **availability** — 부터 시작하고, 그다음 네 가지 golden signal, 마지막으로 인프라 metric을 추가합니다.

## 사용자에서 안쪽으로의 계층화

```text
1. 사용자 대면 SLI   → 사용자가 경험하는 것 (latency, errors, availability)
2. GOLDEN SIGNALS   → service별 latency, traffic, errors, saturation
3. 인프라 METRIC    → CPU, memory, disk, network (증상이 아니라 원인)
```

CPU와 disk만 본다면(bottom-up) 사용자가 500을 받는 와중에도 전부 초록색일 수 있습니다. SLI를 먼저 보는 것(top-down)은 **사용자가 실제로 체감하는 증상**에 alert를 걸고, 그다음 golden signal과 인프라로 파고들어 원인을 찾는다는 뜻입니다.

## 파이프라인: instrument → collect → dashboard → alert

```text
INSTRUMENT  app이 metrics/logs/traces를 방출 (예: request_duration_seconds histogram)
   ↓
COLLECT     TSDB가 이를 scrape/ingest (Prometheus, Datadog agent)
   ↓
DASHBOARD   사람이 읽도록 SLI + golden signals 시각화 (Grafana)
   ↓
ALERT       SLO 위반 / burn rate에 발화, on-call로 라우팅
```

## 구체적인 출발점

```promql
# Availability SLI: 성공한 요청의 비율
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 요청 latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

각 SLI에 **SLO**를 정의하고(예: 99.9% availability, p99 < 300ms), dashboard로 만들고, SLO가 위험할 때 alert를 거세요 — 모든 작은 흔들림이 아니라.

## 왜 중요한가

bottom-up으로 만든 모니터링은 disk가 80% 찼다는 것은 알려주지만 고객이 결제를 못 한다는 것은 알려주지 않습니다. 사용자 대면 SLI에서 시작하면 모든 dashboard와 alert가 실제 사용자 영향으로 연결되고, 노이즈가 낮게 유지되며, 문제가 생겼을 때 명확한 drill-down 경로(증상 → golden signal → 인프라 원인)를 제공합니다.

사용자에서 안쪽으로의 계층화

파이프라인: instrument → collect → dashboard → alert

구체적인 출발점

왜 중요한가

관련 질문