06. Observability — 트레이싱, 로그 상관관계 ID, 메트릭, SLI/SLO, 알람

이 문서가 답하는 질문: 분산 파이프라인의 진실을 어떻게 보는가? 무엇을 측정하고 어떻게 알람할 것인가?

한 줄 답

관측 가능성은 3축(traces / logs / metrics) 의 합이다. 분산 파이프라인에서는 correlation ID가 모든 관측의 본드 — 한 파일이 여러 람다·큐를 지나는 동안 같은 ID로 묶여야 진실이 보인다. 메트릭은 SLI(우리가 측정하는 것)에서 SLO(약속하는 것)로 추상화되고, 알람은 error budget의 소진 속도로 결정된다.

Why — “왜 단순 로그는 부족한가”

처음에는 다들 console.log로 시작한다. 람다가 5개로 늘어난 시점에서 다음 질문을 풀 수 없다.

console.log로는 (a) 람다별 로그가 분리되어 있고, (b) 같은 영상의 흐름이 ID로 묶이지 않으며, (c) 시간 기반 통계가 없고, (d) 알람을 걸 수치가 없다.

→ 분산 파이프라인은 3축 관측이 필요하다.

How — Traces, Logs, Metrics 3축

1) 3축의 정체

→ 3축은 서로 보완 — trace가 high-level path를 보여주고, log가 detail을 채우고, metric이 대시보드 알람을 만든다.

2) Correlation ID — 모든 관측의 본드

분산 파이프라인의 가장 중요한 single piece of information.

규칙:

• Producer가 trace 시작 시점에 traceId를 생성 (UUID 또는 OpenTelemetry context)
• 모든 메시지의 attributes/headers에 traceId 포함
• 모든 로그에 traceId 포함 (structured log)
• DB row에 traceId 컬럼 (선택)

이렇게 하면 CloudWatch Logs Insights에서 filter traceId = "abc-123" 한 줄로 한 영상의 전체 흐름이 보인다.

3) OpenTelemetry — 표준화된 관측

OpenTelemetry(OTel)는 traces/logs/metrics를 한 SDK로 통합한 CNCF 표준.

OpenTelemetry의 장점:

• 코드 한 번 작성으로 여러 backend 보냄
• 자동 instrumentation — Express, AWS SDK, MySQL 등 자동 trace
• 벤더 중립 — 나중에 Datadog → 자체 호스팅 전환 쉬움

Span 예 (transcode 단계):

const tracer = trace.getTracer('media-pipeline');
 
await tracer.startActiveSpan('transcode.submit', async span => {
  span.setAttribute('fileId', msg.fileId);
  span.setAttribute('input.size', stat.size);
  span.setAttribute('input.duration', metadata.duration);
 
  try {
    const job = await mc.createJob({ /* ... */ });
    span.setAttribute('mc.jobId', job.Id);
    span.setStatus({ code: SpanStatusCode.OK });
  } catch (err) {
    span.recordException(err);
    span.setStatus({ code: SpanStatusCode.ERROR, message: err.message });
    throw err;
  } finally {
    span.end();
  }
});

→ 이 span은 자동으로 traceId 컨텍스트를 따라 흐르고, X-Ray/Jaeger 같은 UI에서 timeline으로 본다.

4) Structured Logs — JSON 한 줄 로그

// 안티패턴
console.log(`Processing file ${fileId} took ${duration}ms`);
 
// 정답
log.info({
  msg: 'transcode.completed',
  traceId,
  fileId,
  durationMs: duration,
  outputCount: artifacts.length,
});

JSON 구조라야:

• CloudWatch Logs Insights에서 필드별 쿼리 가능
• Datadog/New Relic 같은 SaaS가 자동 indexing
• traceId로 필터, fileId로 필터, msg로 그룹 가능

필수 필드 카탈로그:

5) Metrics — SLI에서 SLO로

SLI (Service Level Indicator) — 측정값

• success_rate = 성공/(성공+실패)
• latency_p99 = 99% 요청의 처리 시간
• dlq_depth = DLQ에 쌓인 메시지 수

SLO (Service Level Objective) — 약속

• “성공률 ≥ 99.5% (월 단위)”
• “p99 latency < 5분 (영상당)”
• “DLQ depth = 0 (목표)“

Error budget — SLO 위반 허용량

• 99.5% SLO → 한 달에 0.5% (218분)까지 다운타임/실패 허용
• 이 budget을 다 쓰면 신규 기능 배포 멈추고 안정화에 집중 — Google SRE의 핵심 운영 원칙

6) 미디어 파이프라인의 표준 SLI 카탈로그

What — 알람 임계와 운영 대시보드

1) 알람 우선순위 체계

2) 알람 anti-pattern과 정답

3) 운영 대시보드 — 한 화면에 무엇이 있어야 하나

→ 한 화면(or 5분 안에 파악)에 시스템 상태 + 추세를 본다. 자세한 분석은 click-through로.

4) 트레이스 분석 — Service Map

X-Ray / Jaeger / OTel UI는 자동으로 service map을 그린다.

[API Gateway] → [Lambda A] → [SQS-1] → [Lambda B] → [MediaConvert] → [EventBridge] → [SQS-2] → [Lambda C]
                  20ms          (avg 2s)    p99 8min        (avg 3min)                              50ms

각 화살표에 평균 latency + 에러율이 자동 표시 — 어느 hop이 느린지/실패하는지 즉시 파악.

5) 로그 상관관계 검색 (Logs Insights 예)

-- CloudWatch Logs Insights
fields @timestamp, level, msg, fileId, durationMs
| filter traceId = "abc-123"
| sort @timestamp asc
 
-- 실패 모드 분포
filter level = "error"
| stats count(*) by errorCode
 
-- 가장 느린 영상 top 10
filter msg = "pipeline.completed"
| stats max(durationMs) as maxDur by fileId
| sort maxDur desc
| limit 10

→ structured log + traceId가 있어야 이런 쿼리가 가능. 그래서 첫 단계 투자 가치 큼.

What-if — 잘못 쓰면 어떻게 깨지는가

1) “console.log + traceId 없음”

람다 5개로 늘어난 시점에 디버깅 불가. 영상 하나 분석하는 데 한 시간. → 첫 람다부터 structured log + traceId 강제.

2) “metric 없이 log만”

“평균 처리 시간이 늘었어요” 같은 트렌드 질문에 답 못 함. → Lambda는 자동 메트릭 (Duration, Errors, Invocations) 무료 — 활용.

3) “알람만 많고 안 봄 — alarm fatigue”

PagerDuty 알람이 매일 50개 → 진짜 critical 알람도 묻힘. → P0/P1/P2/P3 layered alerting + 정기 리뷰로 무의미 알람 제거.

4) “SLO 없이 SLI만”

“성공률 모니터링하고 있어요” — 그래서 몇 %여야 OK인지 합의 없음. → SLO + Error Budget으로 운영-개발 합의.

5) “PII가 로그에 노출”

log.info({ user: { email, password, ssn } });  // 사고

→ logger 레벨에서 PII 필드 자동 mask (mode 분리), 또는 명시적 sanitize.

6) “트레이스 100% 샘플링”

비용/성능 폭주. 보통 1-10% 샘플링. 예외: 에러는 100%, 성공은 1% 같은 hybrid (tail-based sampling).

7) “MC 등 외부 서비스 latency 무시”

내부 람다 시간만 봐서 “우리 시스템은 빠른데 사용자는 느려”라고 함. → end-to-end latency (업로드 → 재생 가능) 측정. 외부도 trace에 포함.

Insight — 흥미로운 이야기

“Three Pillars of Observability — Cindy Sridharan (2017)”

Sridharan의 책이 traces / logs / metrics 3축을 정식화했다. 그 전에는 다들 “monitoring”이라고 했지만 monitoring(미리 정의된 질문에 답)과 observability(미리 모르는 질문에 답)는 다르다. 미디어 파이프라인은 사고가 항상 새로운 모양으로 온다 — observability가 monitoring보다 가치 있다.

“OpenTelemetry는 OpenTracing + OpenCensus 합병의 결과”

2019년 OpenTracing(traces 표준)과 OpenCensus(metrics 표준)가 합병해 OpenTelemetry가 됐다. 단일 SDK로 3축을 모두 커버. CNCF 프로젝트 중 Kubernetes 다음으로 큰 프로젝트. 의의: 벤더 lock-in 탈출 가능. Datadog → 자체 Jaeger → CloudWatch 같은 전환이 코드 한 줄 안 바꾸고 가능.

“Google SRE의 Error Budget은 정치 도구다”

Google SRE 책의 핵심 통찰 — Error Budget은 기술 수치가 아니라 개발팀과 운영팀의 정치적 합의. 99.99% SLO를 약속하면 신규 기능 배포가 5분 미만 다운타임 안에 들어와야 한다. 자연스럽게 신규 기능 배포 속도가 안정성과 균형 잡힌다. 미디어 파이프라인도 마찬가지 — SLO 99.5%를 약속하면 한 달에 218분까지 실패를 허용. 그 이상이면 freeze. 비즈니스 결정과 기술 결정의 다리.

“Honeycomb의 Charity Majors — ‘로그는 죽었다’”

Charity Majors의 도발 — “로그는 인간을 위한 것, 진짜 분석은 wide event(고차원 attribute가 붙은 한 줄)에서 일어난다”. 그래서 Honeycomb은 모든 관측을 ‘event’ 단위로 통합. 실용적으로는 — log 한 줄에 30개 attribute(traceId, fileId, durationMs, awsRegion, 등등)를 붙이면 그것이 곧 metric + log + trace의 합집합이 된다.

요약 + Mermaid

요점 — 관측은 traces/logs/metrics 3축의 합이고, correlation ID가 모든 축을 묶는 본드다. OpenTelemetry는 이 3축의 벤더 중립 표준. SLI에서 SLO로, error budget으로 알람 → 정치적 합의가 자동화된다. 알람은 임계 절대값이 아니라 burn rate로. 다음 문서(07)는 이 모든 것의 비용 구조와 컴퓨트 선택을 본다.