Skip to main content

​
관찰성 & SRE 기초

운영 품질은 “문제가 없을 때”가 아니라 “문제가 생겼을 때 얼마나 빨리 복구하는가”로 결정됩니다.

​
학습 목표

  • 메트릭/로그/트레이싱의 역할을 구분하고 함께 활용할 수 있습니다.
  • SLI/SLO/Error Budget 개념을 실무 관점으로 이해합니다.
  • Prometheus + Grafana 기본 구성을 설명할 수 있습니다.
  • 알림과 런북 중심의 대응 체계를 설계할 수 있습니다.

​
관찰성 3축 (Three Pillars)

축역할핵심 질문대표 도구
Metrics시스템 상태를 수치로 관찰”지금 얼마나 바쁜가?”Prometheus, CloudWatch
Logs이벤트를 시간순으로 기록”무슨 일이 있었나?”Loki, OpenSearch, CloudWatch Logs
Traces요청의 전체 경로를 추적”어디서 느려졌나?”Jaeger, Tempo, X-Ray
이 세 가지를 함께 봐야 장애 원인을 빠르게 좁힐 수 있습니다.
메트릭으로 “문제가 있다”를 감지하고, 로그로 “무슨 문제인지” 파악하고, 트레이스로 “어디서 문제가 발생했는지” 특정합니다. 세 축이 연결되지 않으면 장애 진단에 시간이 배로 걸립니다.

​
SRE 핵심 개념

​
SLI / SLO / SLA 정의

개념정의예시담당
SLI (Service Level Indicator)서비스 품질을 측정하는 지표요청 성공률, p99 응답시간엔지니어
SLO (Service Level Objective)SLI의 목표치성공률 99.9%, p99 < 500ms엔지니어 + PM
SLA (Service Level Agreement)고객과의 계약 (위반 시 보상)월 가용성 99.5%비즈니스
Error BudgetSLO에서 허용되는 실패 범위월 0.1% 실패 허용팀 전체
SLO는 100%로 설정하면 안 됩니다. 100%는 달성 불가능하며, 배포/변경을 완전히 멈춰야 합니다. 99.9%와 99.99%의 차이는 월 허용 장애 시간이 43분 vs 4분입니다.

​
Error Budget 활용법

월간 Error Budget 계산:
- SLO = 99.9%
- 월 요청 수 = 1,000,000
- 허용 실패 수 = 1,000,000 × 0.1% = 1,000건

Budget 소진 현황:
- 이번 달 실패 = 600건 → 60% 소진 → 정상 배포 진행
- 이번 달 실패 = 950건 → 95% 소진 → 배포 동결, 안정화 집중
Error Budget을 쓰면 안정성과 배포 속도 사이 균형을 팀 합의로 관리할 수 있습니다.

​
Prometheus + Grafana 기본 구성

1

메트릭 수집 (Prometheus)

Prometheus는 Pull 방식으로 타겟 서비스의 /metrics 엔드포인트에서 데이터를 수집합니다.
# prometheus.yml 기본 설정
scrape_configs:
  - job_name: 'llm-api'
    scrape_interval: 15s
    static_configs:
      - targets: ['llm-api:8080']
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']
2

대시보드 구성 (Grafana)

Grafana에서 Prometheus를 데이터소스로 연결하고, 핵심 지표 대시보드를 구성합니다. 서비스별 성공률, 지연시간, 에러율, 리소스 사용량을 한 화면에 표시합니다.
3

알림 규칙 설정

임계치 기반 알림을 설정하고, 알림 채널(Slack, Telegram, PagerDuty)과 연결합니다.
# Grafana Alert Rule 예시
- alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "5xx 에러율이 5%를 초과했습니다"
4

런북 연결

각 알림에 대응 절차(런북)를 연결하여 누가 받아도 동일하게 대응할 수 있게 합니다.

​
운영 기본 세트 (LLM 서비스)

지표유형임계치 예시알림 수준
API 성공률SLI< 99.5%Critical
p95 응답시간SLI> 3초Warning
p99 응답시간SLI> 10초Critical
외부 LLM API 실패율의존성> 5%Warning
토큰 사용량/비용FinOps일 예산 초과Warning
큐 대기시간용량> 30초Warning
GPU 사용률리소스> 90% 5분 지속Warning
디스크 사용률리소스> 85%Warning

​
알림 설계 원칙

알림이 많으면 안전한 것이 아니라, 중요한 신호가 묻힙니다. “이 알림이 오면 지금 당장 누군가가 행동해야 하는가?”를 기준으로 설계하세요.
원칙설명
행동 가능성알림을 받고 할 수 있는 구체적 행동이 있어야 함
증상 기반원인이 아니라 증상(사용자 영향)을 알림으로 설정
노이즈 최소화동일 장애에 대한 중복 알림 억제 (grouping)
에스컬레이션Warning 5분 지속 → Critical → 담당자 호출
런북 연결모든 알림에 대응 절차 문서 링크 포함

​
장애 대응 흐름

1

감지

알림 임계치와 노이즈 필터를 분리해 진짜 장애를 빠르게 감지합니다.
2

진단

로그, 지표, 트레이스를 함께 보며 원인 범위를 좁힙니다. 메트릭 → 로그 → 트레이스 순서로 확인합니다.
3

완화

롤백, 트래픽 제한, fallback 전환으로 서비스 영향부터 줄입니다. 원인 분석보다 서비스 복구가 우선입니다.
4

회고 (Post-mortem)

포스트모템으로 재발 방지 액션을 남기고 책임자/기한을 지정합니다. 비난이 아닌 시스템 개선에 초점을 맞춥니다 (Blameless).
알림 과다는 오히려 중요한 신호를 묻습니다. 즉시 대응이 필요한 지표부터 적은 수(5개 이하)로 시작하세요. 1주일간 한 번도 행동으로 이어지지 않는 알림은 삭제하거나 등급을 낮추세요.
장애는 긴장 상태에서 발생합니다. 런북이 있으면 개인 숙련도 차이를 줄이고 대응 속도를 안정화할 수 있습니다. 최소 항목: 증상 설명, 확인 명령어, 복구 절차, 에스컬레이션 기준.
정답률/환각률 같은 품질 지표도 운영 지표와 함께 봐야 합니다. 품질 하락은 시스템 장애만큼 중요한 운영 이슈입니다. 토큰 비용 급증, 응답 품질 저하, 컨텍스트 윈도우 초과도 모니터링 대상입니다.
  • Counter: 누적 증가 값 (요청 수, 에러 수). rate() 함수로 초당 비율 계산.
  • Gauge: 현재 값 (CPU 사용률, 메모리). 올라가거나 내려갈 수 있음.
  • Histogram: 값의 분포 (응답시간 분포). p50/p95/p99 계산에 사용.
  • Summary: 클라이언트 측 분위수 계산. Histogram과 유사하나 서버 부하 적음.

​
체크리스트

  • 핵심 서비스 SLO가 정의되어 있나요?
  • 관찰성 3축(메트릭/로그/트레이스)이 모두 수집되나요?
  • 알림 기준과 대응 런북이 있나요?
  • 알림이 행동 가능하고, 노이즈가 통제되나요?
  • 장애 회고와 재발 방지 액션이 추적되나요?
  • Error Budget 기반으로 배포 속도를 조절하나요?

​
다음 문서