왜 모니터링인가?
서비스를 운영하다 보면 필연적으로 장애를 만나게 됩니다. 서버가 다운되거나, 응답 속도가 느려지거나, 데이터베이스가 멈추는 상황은 피할 수 없습니다. 서비스 규모가 커질수록 장애 확률은 1에 수렴합니다.
장애 대응 사이클
1. Detect
장애 감지
2. Diagnose
원인 진단
3. Resolve
복구
핵심 지표
Mean Time To Detect
장애 발생부터 인지까지 걸리는 평균 시간
Mean Time To Resolve
장애 인지부터 복구까지 걸리는 평균 시간
모니터링의 궁극적 목표
모니터링의 궁극적 목표는 MTTD와 MTTR을 줄이는 것입니다. 장애를 빨리 발견하고(MTTD ↓), 빨리 복구하면(MTTR ↓) 사용자에게 미치는 영향을 최소화할 수 있습니다.
모니터링 없는 팀
고객이 먼저 문의해야 장애를 알게 됨
모니터링 있는 팀
알람이 즉시 울리고 빠르게 원인 파악
SLI / SLO / SLA
서비스 신뢰성을 정량적으로 측정하고 관리하기 위해서는 SLI, SLO, SLA라는 세 가지 개념을 이해해야 합니다. 이들은 Google SRE(Site Reliability Engineering)에서 정립한 핵심 개념입니다.
SLI Service Level Indicator
서비스 품질을 나타내는 정량적 측정값입니다. 실제로 측정 가능한 지표여야 하며, 사용자 경험과 직접적으로 연관되어야 합니다.
SLI 예시
- • API 응답시간 p99 (99%의 요청이 이 시간 안에 응답)
- • 에러율 (전체 요청 중 5xx 에러 비율)
- • 가용성(Uptime) (서비스가 정상 동작한 시간 비율)
SLO Service Level Objective
SLI에 대한 목표값입니다. "이 정도는 되어야 한다"는 내부 목표를 수치화한 것입니다.
SLO 예시
- • "API p99 응답시간 < 200ms"
- • "월간 가용성 99.9%"
- • "에러율 < 0.1%"
SLA Service Level Agreement
고객과의 계약입니다. SLO를 못 지키면 페널티(환불, 크레딧 지급 등)가 발생합니다. SLA는 보통 SLO보다 느슨하게 설정합니다.
SLA 예시
- • "가용성 99.95% 미달 시 크레딧 10% 환불"
- • "가용성 99.5% 미달 시 크레딧 25% 환불"
| 개념 | 정의 | 대상 | 예시 | 위반 시 |
|---|---|---|---|---|
| SLI | 측정값 | 내부 | p99 = 150ms | - |
| SLO | 목표값 | 내부 | p99 < 200ms | 내부 개선 작업 |
| SLA | 계약 | 고객 | 가용성 99.9% | 페널티 발생 |
Error Budget (오류 예산)
SLO가 99.9%라는 것은 0.1%는 실패해도 괜찮다는 뜻입니다. 이 실패 허용치를 Error Budget이라고 합니다.
계산 예시
| SLO | 월 다운타임 | 연 다운타임 |
|---|---|---|
| 99% | 7시간 18분 | 3.65일 |
| 99.9% | 43.8분 | 8.76시간 |
| 99.95% | 21.9분 | 4.38시간 |
| 99.99% | 4.38분 | 52.6분 |
Tip: SLO는 100%로 설정하면 안 됩니다
SLO를 100%로 설정하면 Error Budget이 0이 되어 어떤 변경도 할 수 없게 됩니다. 배포, 업데이트, 새로운 기능 출시 등 모든 변경에는 리스크가 따르기 때문입니다. 적절한 Error Budget을 남겨두어야 혁신과 안정성의 균형을 맞출 수 있습니다.
Four Golden Signals (Google SRE)
Google SRE에서 정의한 Four Golden Signals는 시스템 건강도를 파악하는 가장 중요한 4가지 지표입니다. 이 4가지만 제대로 모니터링해도 대부분의 장애를 빠르게 감지할 수 있습니다.
1. Latency 응답 시간
요청을 처리하는 데 걸리는 시간입니다. 성공한 요청과 실패한 요청의 Latency를 분리하여 측정해야 합니다. 실패한 요청은 빨리 실패하기 때문에 Latency가 낮게 나올 수 있어 평균을 왜곡합니다.
측정 방법
- • p50, p95, p99 백분위수 (평균보다 중요)
- • 성공 요청 Latency vs 실패 요청 Latency 분리
2. Traffic 요청량
시스템에 걸리는 부하의 양입니다. HTTP requests/sec, DB QPS(Queries Per Second), 네트워크 트래픽 등으로 측정합니다.
측정 방법
- • HTTP 요청 수 / 초
- • 데이터베이스 쿼리 수 / 초
- • 네트워크 I/O (bytes/sec)
3. Errors 에러율
실패한 요청의 비율입니다. HTTP 5xx 에러, 비즈니스 로직 에러, 타임아웃 등을 포함합니다.
측정 방법
- • HTTP 5xx 응답 비율
- • 타임아웃 비율
- • 비즈니스 로직 에러 (예: 결제 실패)
4. Saturation 리소스 포화도
시스템 리소스가 얼마나 가득 찼는지를 나타냅니다. CPU, Memory, Disk IO, Network 등의 사용률을 측정합니다.
측정 방법
- • CPU 사용률 (%)
- • 메모리 사용률 (%)
- • 디스크 I/O 대기 시간
- • 네트워크 대역폭 사용률
모니터링 도구별 Golden Signals 지표 매핑
| Signal | Datadog | CloudWatch | Prometheus |
|---|---|---|---|
| Latency | APM trace duration p99 | API Gateway IntegrationLatency | histogram_quantile(0.99, ...) |
| Traffic | APM requests/sec | ALB RequestCount | rate(http_requests_total[5m]) |
| Errors | APM error rate, RUM JS errors | ALB HTTPCode_Target_5XX_Count | rate(http_requests_total{code=~"5.."}[5m]) |
| Saturation | System CPU/Memory usage | EC2 CPUUtilization, RDS FreeableMemory | node_cpu_seconds_total, node_memory_MemAvailable_bytes |
핵심 포인트
Four Golden Signals만 제대로 모니터링해도 대부분의 장애를 빠르게 감지할 수 있습니다. 다른 복잡한 지표들을 추가하기 전에, 먼저 이 4가지 지표를 완벽하게 설정하세요.
모니터링 도구 생태계
실제 프로덕션 환경에서는 여러 모니터링 도구를 조합하여 사용합니다. 각 도구는 특정 레이어에 특화되어 있으며, 함께 사용할 때 최대의 효과를 발휘합니다.
Datadog 통합 모니터링 플랫폼
RUM(Real User Monitoring, 프론트엔드), APM(백엔드 트레이싱), Logs(로그 수집), Infrastructure(서버 메트릭)를 모두 제공하는 올인원 플랫폼입니다.
강점
- • 통합 대시보드로 전체 스택 가시성 확보
- • 프론트엔드부터 백엔드까지 트레이스 연결
- • 강력한 쿼리 언어와 알람 기능
약점
- • 높은 비용 (트래픽 많을 시)
- • 벤더 락인 위험
AWS CloudWatch AWS 네이티브 모니터링
EC2, RDS, ALB, Lambda 등 모든 AWS 리소스의 메트릭을 수집하고 알람을 설정할 수 있습니다. AWS 인프라를 사용한다면 기본으로 활용해야 하는 도구입니다.
강점
- • AWS 리소스와 긴밀한 통합
- • 추가 설정 없이 기본 메트릭 수집
- • 커스텀 메트릭 발행 가능
약점
- • 쿼리 기능이 제한적
- • 대시보드 UI가 투박함
- • 프론트엔드 모니터링 불가
Prometheus + Grafana 오픈소스 모니터링
Prometheus는 메트릭 수집 및 저장, Grafana는 시각화를 담당합니다. Kubernetes 환경에서 사실상 표준으로 자리잡았습니다.
강점
- • 오픈소스 (비용 없음)
- • Kubernetes 클러스터 모니터링에 최적화
- • 강력한 PromQL 쿼리 언어
- • Grafana로 유연한 대시보드 구성
약점
- • 직접 설치/운영 필요
- • 장기 저장소 구축 필요 (Thanos 등)
- • 애플리케이션 레벨 트레이싱 제한적
모니터링 레이어 구조
도구별 강점/약점 비교
| 도구 | 대상 레이어 | 주요 강점 | 주요 약점 |
|---|---|---|---|
| Datadog | 전체 스택 | 올인원, 강력한 쿼리 | 높은 비용 |
| CloudWatch | AWS 인프라 | AWS 긴밀 통합 | 제한적 쿼리, 투박한 UI |
| Prometheus + Grafana | K8s 클러스터 | 오픈소스, K8s 최적화 | 직접 운영 필요 |
Tip: 하나의 도구로 모든 것을 해결하려 하지 마세요
각 레이어에 적합한 도구를 선택하는 것이 핵심입니다. 예를 들어 프론트엔드는 Datadog RUM, 백엔드는 Datadog APM, 인프라는 CloudWatch와 Prometheus를 조합하여 사용할 수 있습니다. 도구를 추가할 때는 "이 도구가 해결하는 문제가 무엇인가?"를 먼저 명확히 하세요.
퀴즈
학습한 내용을 확인해봅시다. 5문제를 모두 풀어보세요.