모니터링과 관측 가능성: 로그, 메트릭, 트레이싱

개요

**관측 가능성(Observability)**이란 시스템의 외부 출력(로그, 메트릭, 트레이스)만으로 시스템 내부 상태를 추론할 수 있는 능력이다. 전통적 모니터링(Monitoring)이 "미리 정의한 문제를 감시"하는 것이라면, 관측 가능성은 "예상하지 못한 문제를 탐색"하는 것이다.

2026년 현재, OpenTelemetry가 관측 가능성의 사실상 표준(de facto standard)으로 자리잡았으며, AIOps는 단순 이상 탐지를 넘어 장애 예측과 자동 수정까지 발전하고 있다. eBPF 기술은 커널 레벨에서의 고성능 텔레메트리 수집을 가능하게 하여, 관측 가능성의 책임이 애플리케이션 팀에서 플랫폼 팀으로 이동하고 있다.

관측 가능성의 세 기둥 (Three Pillars)

1. 로깅 (Logging)

시스템에서 발생하는 **이산적 이벤트(Discrete Events)**를 시간순으로 기록한다.

구조화된 로깅 (Structured Logging):

{
  "timestamp": "2026-02-10T09:30:00Z",
  "level": "ERROR",
  "service": "payment-service",
  "traceId": "abc123def456",
  "userId": "user-789",
  "message": "결제 처리 실패",
  "error": "insufficient_funds",
  "amount": 50000,
  "currency": "KRW"
}

비구조화 로그 vs 구조화 로그:

로그 수집 도구:

로그 레벨 가이드라인:

• FATAL: 서비스 중단 수준의 오류
• ERROR: 요청 처리 실패, 즉각적 대응 필요
• WARN: 잠재적 문제, 주의 필요
• INFO: 주요 비즈니스 이벤트 (결제 완료, 사용자 가입)
• DEBUG: 개발/디버깅용 상세 정보 (프로덕션에서는 비활성화)

2. 메트릭 (Metrics)

시간에 따른 **수치적 측정값(Numerical Measurements)**을 수집하고 집계한다.

메트릭 유형:

Prometheus + Grafana:

Prometheus는 Pull 기반의 시계열 데이터베이스로, 주기적으로 타겟을 스크레이핑(Scraping)하여 메트릭을 수집한다.

# Prometheus 스크레이핑 설정
scrape_configs:
  - job_name: 'payment-service'
    scrape_interval: 15s
    static_configs:
      - targets: ['payment-service:8080']

# PromQL 쿼리 예시
# 5분간 초당 요청 수
rate(http_requests_total[5m])
 
# 95번째 백분위 응답 시간
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
 
# 에러율
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])

3. 트레이싱 (Distributed Tracing)

분산 시스템에서 하나의 요청이 여러 서비스를 거치는 전체 경로를 추적한다.

사용자 요청
  └── API Gateway (Span 1: 2ms)
      └── Auth Service (Span 2: 5ms)
      └── Product Service (Span 3: 15ms)
          └── Database Query (Span 4: 10ms)
          └── Cache Lookup (Span 5: 1ms)
      └── Payment Service (Span 6: 50ms)
          └── External Payment API (Span 7: 45ms)

핵심 개념:

• Trace: 하나의 요청에 대한 전체 추적 기록
• Span: Trace를 구성하는 개별 작업 단위
• Context Propagation: 서비스 간 TraceID/SpanID 전파

도구:

OpenTelemetry (OTel) - 통합 표준

개념

OpenTelemetry는 CNCF의 프로젝트로, 로그, 메트릭, 트레이스를 **벤더 중립적(Vendor-Neutral)**으로 수집, 처리, 내보내기 위한 통합 표준이다. 2026년 현재, 클라우드 네이티브 조직이 OTel을 기본 데이터 표준으로 채택하는 추세가 가속화되고 있다.

애플리케이션 (OTel SDK)
       │
       ▼
OTel Collector
  ├── Exporter → Prometheus (메트릭)
  ├── Exporter → Loki (로그)
  ├── Exporter → Tempo/Jaeger (트레이스)
  └── Exporter → Pyroscope (프로파일링)

OTel Collector 아키텍처

# OTel Collector 설정
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
 
processors:
  batch:
    timeout: 5s
    send_batch_size: 1024
  memory_limiter:
    limit_mib: 512
 
exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  otlp/tempo:
    endpoint: tempo:4317
  loki:
    endpoint: http://loki:3100/loki/api/v1/push
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, memory_limiter]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

OTel의 장점

1. 벤더 종속성 제거: 백엔드를 자유롭게 교체 가능
2. 통합 계측(Instrumentation): 하나의 SDK로 로그, 메트릭, 트레이스 모두 수집
3. 자동 계측(Auto-Instrumentation): 코드 변경 없이 HTTP, DB, gRPC 등 자동 수집
4. 풍부한 생태계: 모든 주요 언어와 프레임워크 지원

SRE 지표 (SLA, SLO, SLI)

정의

관계:

SLI (실측) → SLO (내부 목표) → SLA (외부 약속)
99.97%        99.95%            99.9%
 
SLO > SLA: SLA를 만족시키기 위한 안전 마진 확보

에러 버짓 (Error Budget)

SLO에서 허용하는 장애 허용량이다.

SLO = 99.95% (월간)
에러 버짓 = 100% - 99.95% = 0.05%
월간 허용 다운타임 = 30일 x 24시간 x 60분 x 0.05% = 약 21.6분

에러 버짓 정책:

• 에러 버짓이 남아있으면 → 새 기능 배포, 실험 가능
• 에러 버짓이 소진되면 → 신규 배포 중단, 안정성 작업에 집중
• 에러 버짓 소진 속도 알림 → 번다운(Burn Rate) 기반 알림

골든 시그널 (Golden Signals)

Google SRE 팀이 정의한 4가지 핵심 모니터링 지표이다.

RED Method (마이크로서비스용):

• Rate: 초당 요청 수
• Errors: 에러율
• Duration: 요청 처리 시간

USE Method (인프라용):

• Utilization: 리소스 사용률
• Saturation: 대기열 깊이
• Errors: 에러 수

eBPF 기반 관측 가능성

개념

**eBPF(extended Berkeley Packet Filter)**는 Linux 커널에서 샌드박스된 프로그램을 실행하는 기술로, 코드 변경 없이 네트워크, 보안, 관측 가능성 데이터를 수집할 수 있다.

전통적 방식 vs eBPF:

도구

Continuous Profiling

개념

프로덕션 환경에서 지속적으로 CPU, 메모리, I/O 프로파일링을 수행하여, 성능 병목을 식별하는 기법이다. 관측 가능성의 "네 번째 기둥"으로 부상하고 있다.

도구:

• Pyroscope: 오픈소스 Continuous Profiling 플랫폼
• Parca: eBPF 기반, 낮은 오버헤드
• Datadog Continuous Profiler: SaaS 통합 프로파일링

Flame Graph: 프로파일링 결과를 시각화하는 대표적 방법으로, 스택의 깊이(호출 순서)와 너비(시간 비중)를 한눈에 파악할 수 있다.

AIOps (2026 트렌드)

개념

AIOps(Artificial Intelligence for IT Operations)는 AI/ML을 활용하여 모니터링, 분석, 최적화를 자동화하는 접근이다. 2026년에는 기본적인 이상 탐지를 넘어, 장애 예측과 구성 편차 탐지, 자동 수정까지 발전하고 있다.

AIOps의 핵심 기능

데이터 수집 → 이상 탐지 → 상관 분석 → 근본 원인 추론 → 자동 조치
  (OTel)      (ML 모델)   (토폴로지)    (인과 추론)      (자가 치유)

1. 알림 노이즈 감소: 관련 알림을 자동 그룹핑하여 "알림 피로(Alert Fatigue)" 방지
2. 이상 탐지 (Anomaly Detection): 과거 패턴을 학습하여 비정상 메트릭 자동 탐지
3. 근본 원인 분석 (Root Cause Analysis): 서비스 토폴로지와 상관관계를 활용한 자동 추론
4. 예측적 관측 (Predictive Observability): 장애가 발생하기 전에 미리 탐지하고 대응

AIOps 도구 (2026)

AIOps 도입 팀은 평균 MTTR 17.8% 감소를 보고하며, 선도적 구현에서는 30-70% 감소를 달성한다. AIOps 시장은 2024년 146억 달러에서 2030년 360억 달러 이상으로 성장할 전망이다.

실시간 사용자 모니터링 (RUM) & 합성 모니터링 (Synthetic Monitoring)

RUM (Real User Monitoring)

실제 사용자의 브라우저/디바이스에서 성능 데이터를 수집한다.

측정 지표:

• Core Web Vitals: LCP (Largest Contentful Paint), FID (First Input Delay), CLS (Cumulative Layout Shift)
• 페이지 로딩 시간, 에러율, 세션 리플레이

Synthetic Monitoring

인위적인 트래픽을 생성하여 사전에 정의된 시나리오를 주기적으로 실행하고 성능을 측정한다.

RUM: 실제 사용자 데이터 → "지금 사용자가 경험하는 것"
Synthetic: 시뮬레이션 데이터 → "사용자가 없어도 문제를 미리 발견"

관측 가능성 비용 최적화

2026년의 주요 과제 중 하나는 관측 가능성 비용 관리이다. 데이터 볼륨이 기하급수적으로 증가하면서, 비용이 전체 클라우드 비용의 상당 부분을 차지하게 되었다.

최적화 전략

1. 샘플링 (Sampling): 모든 트레이스를 저장하지 않고, Head/Tail 기반 샘플링
2. 메트릭 집계: 고해상도 메트릭을 시간이 지나면 저해상도로 다운샘플링
3. 로그 레벨 조정: 프로덕션에서는 INFO 이상만 수집
4. 데이터 보존 정책: 핫/웜/콜드 스토리지 티어링
5. 관련 데이터만 수집: OTel Processor에서 불필요한 데이터 필터링

참고 자료

• Observability Engineering - Charity Majors, Liz Fong-Jones, George Miranda
• Site Reliability Engineering - Google SRE Team
• OpenTelemetry Documentation: https://opentelemetry.io/docs
• Prometheus Documentation: https://prometheus.io/docs