4주차에서 Metrics / Logs / Traces 개념을 배웠다. 이번엔 그걸 실제로 어떻게 구축하는지다.

표준 스택

Prometheus 구조

Prometheus는 Pull 방식으로 메트릭을 수집한다. 서비스가 메트릭을 보내는 게 아니라 Prometheus가 주기적으로 가져간다.

[서비스] → /metrics 엔드포인트 노출 [Prometheus] → 주기적으로 /metrics 호출해서 수집 [Grafana] → Prometheus에서 데이터 조회해서 시각화

서비스가 죽어도 Prometheus가 감지할 수 있다는 게 Pull 방식의 장점이다.

메트릭 타입

SLI를 측정할 때 응답 시간은 Histogram, 에러율은 Counter로 계산한다.

로그 파이프라인

[서비스] → [Fluent Bit] → [Loki / Elasticsearch] → [Grafana]

Fluent Bit은 각 노드에 DaemonSet으로 배포해서 모든 컨테이너 로그를 빠짐없이 수집한다.

분산 트레이싱

각 서비스가 Span을 생성하고 같은 Trace ID로 묶인다. 요청이 어디서 느려졌는지 한눈에 볼 수 있다.

[서비스 A] → [서비스 B] → [서비스 C] ↓ ↓ ↓ Span 생성 Span 생성 Span 생성 ↓ [Jaeger / Tempo] → [Grafana]

Grafana로 연결하기

Grafana는 여러 데이터 소스를 연결해서 한 화면에서 보는 도구다. Prometheus는 데이터를 모으는 역할, Grafana는 모인 데이터를 보여주는 역할이다.

• Prometheus → 메트릭 대시보드

• Loki → 로그 검색

• Jaeger / Tempo → 트레이스 조회

  하나의 장애 상황에서 메트릭, 로그, 트레이스를 Grafana 한 화면에서 전환하며 볼 수 있다.

구축 시 흔한 실수

마이크로서비스 환경에서 서비스가 수십 개가 되면 서비스 간 통신이 복잡해진다. 각 서비스가 직접 다른 서비스를 호출하는데, 이때 문제가 생긴다.

• 어떤 서비스가 어디로 트래픽을 보내는지 보이지 않는다

• 서킷 브레이커, 재시도 로직을 서비스마다 따로 구현해야 한다

• 서비스 간 통신 암호화를 각자 처리해야 한다

  Service Mesh는 서비스 간 통신을 인프라 레벨에서 관리하는 것이다. 애플리케이션 코드를 건드리지 않고 트래픽 제어, 보안, 관찰을 한 곳에서 처리한다.

Sidecar 패턴

Service Mesh의 핵심 구조다. 각 서비스 옆에 Proxy(사이드카)를 붙여서 모든 네트워크 트래픽이 Proxy를 통하게 만든다.

[서비스 A] → [Proxy A] → [Proxy B] → [서비스 B]

서비스는 직접 통신하지 않는다. Proxy끼리 통신한다. 트래픽 제어, 로깅, 암호화가 전부 Proxy에서 처리된다.

Control Plane / Data Plane

Istio(Control Plane)가 Envoy(Data Plane)에게 지시하고, Envoy가 실제 트래픽을 처리한다. 지휘관과 병사 관계로 기억하면 편하다.

Service Mesh가 제공하는 것

트래픽 제어

• Canary 배포를 코드 없이 설정으로 처리한다

• 특정 헤더가 있는 요청만 새 버전으로 보낼 수 있다

• 요청 비율 기반으로 A/B 테스트가 가능하다

• Observability*

• 서비스 간 모든 트래픽의 메트릭이 자동으로 수집된다

• 분산 트레이싱이 자동으로 적용된다

• 서비스 맵을 시각화한다

• 보안 (mTLS)*

• 서비스 간 통신을 자동으로 암호화한다

• 서비스 인증을 자동으로 처리한다

• 특정 서비스만 특정 서비스를 호출하도록 정책을 설정한다

• Resilience*

• 서킷 브레이커를 코드 없이 설정으로 적용한다

• 재시도, Timeout을 인프라 레벨에서 처리한다

대표 도구

SRE 관점에서 Service Mesh

12주차에서 배운 Reliability Patterns (Circuit Breaker, Retry, Timeout)을 애플리케이션 코드 없이 인프라 레벨에서 적용할 수 있다. 각 서비스 개발자가 직접 구현하던 것을 플랫폼이 처리해준다.

결국 Service Mesh는 Platform Engineering과 연결된다. 개발자가 Reliability 코드를 직접 짜지 않아도 신뢰성 있는 서비스를 만들 수 있는 환경을 만드는 것이다.

기능이 완성됐다고 바로 프로덕션에 올리면 안 된다. 모니터링이 없거나, On-call 담당자가 없거나, 장애 대응 절차가 없는 상태로 나가면 첫 장애 때 아무것도 못 한다.

PRR은 서비스가 프로덕션에 나갈 준비가 됐는지 체계적으로 검토하는 프로세스다.

PRR이 필요한 이유

PRR 체크리스트

Observability

• 메트릭이 수집되고 있는가

• 로그가 중앙에 수집되고 있는가

• 대시보드가 있는가

• 핵심 트레이스가 설정되어 있는가

• Alerting*

• SLO 기반 알림이 설정되어 있는가

• 알림 티어가 Page / Ticket으로 구분되어 있는가

• 알림이 적절한 채널로 전달되는가

• On-call*

• On-call 담당자가 지정되어 있는가

• Escalation Policy가 있는가

• Runbook이 작성되어 있는가

• Reliability*

• SLI / SLO가 정의되어 있는가

• Error Budget이 설정되어 있는가

• 장애 시 롤백 절차가 있는가

• Graceful Degradation이 고려되어 있는가

• Change Management*

• 배포 전략이 정의되어 있는가 (Canary / Blue-Green)

• Feature Flag가 적용되어 있는가

• DB 스키마 변경 시 하위 호환이 유지되는가

Launch Criteria

체크리스트를 다 채웠다고 바로 나가는 게 아니다. 프로덕션 출시를 허용하는 최소 기준이다.

PRR 프로세스

1. 개발팀이 PRR 문서 작성 - 체크리스트 항목을 직접 채운다
2. SRE팀 검토 - 누락된 항목, 리스크 파악
3. 피드백 반영 - Must 항목 미충족 시 출시 보류
4. 출시 승인 - Launch Criteria 충족 시 승인
5. 출시 후 모니터링 - 초기 트래픽 유입 시 집중 모니터링

PRR과 지금까지 배운 것의 연결

PRR은 지금까지 배운 모든 개념의 종합이다.

정리

PRR은 지금까지 배운 SRE 개념 전체의 종합 점검표다. 기능 완성이 출시 기준이 아니라, 모니터링/알림/On-call/SLO/롤백이 모두 갖춰진 상태가 출시 기준이다. Must 항목이 하나라도 빠져 있으면 출시를 보류하는 것이 맞다.

DevOps vs SRE

둘 다 개발과 운영의 간극을 줄이는 게 목적이지만 접근 방식이 다르다.

DevOps가 "무엇을 해야 한다"라면 SRE는 "어떻게 한다"다. Google이 DevOps를 구체적으로 실현하기 위해 만든 것이 SRE다.

SRE 팀 구성

Toil 줄이는 자동화 전략

Toil은 수동적이고 반복적이고 자동화 가능한 작업이다.

• 빈도 × 소요 시간으로 우선순위를 정한다. 자주 하고 오래 걸리는 것부터 자동화한다
• Runbook이 잘 정비되면 자동화하기 쉽다
• SRE 업무의 50% 이상이 Toil이 되면 안 된다. 넘어가면 팀이 운영에만 매몰되고 개선이 멈춘다

Blameless Culture

장애가 났을 때 누구의 잘못인지 찾는 게 아니라 시스템의 문제를 찾는 문화다.

개인을 처벌하는 문화에서는 아무도 솔직하게 말하지 않는다. 솔직하게 말할 수 있는 환경이 먼저다.

Error Budget Policy

Error Budget을 팀 문화로 만드는 것이다.

• Error Budget이 남아있으면 개발팀은 기능 개발에 집중한다

• Error Budget이 소진되면 신규 기능 배포를 멈추고 신뢰성 개선에 집중한다

• 이 규칙을 개발팀과 SRE팀이 사전에 합의해둔다

  SRE가 일방적으로 배포를 막으면 갈등이 생긴다. Error Budget Policy는 사전 합의로 갈등을 줄이는 도구다.

SRE 팀의 흔한 실패 패턴

정리

SRE는 직함이 아니라 방식이다. 이름만 바꾼다고 SRE가 되는 게 아니다. SLO로 측정하고, Toil을 줄이고, Blameless Culture로 투명하게 공유하고, Error Budget Policy로 개발팀과 합의하는 것이 SRE 조직 문화의 핵심이다.

클라우드를 쓰면 비용이 눈에 안 보인다. 서버를 켜두고 잊어버리거나, 필요 이상으로 큰 인스턴스를 쓰거나, 아무도 안 쓰는 리소스가 돈을 먹고 있다.

FinOps는 클라우드 비용을 최적화하고 비용 대비 가치를 높이는 것이다. 단순히 비용을 줄이는 게 아니라 SLO를 지키면서 가장 저렴한 구성을 찾는 것이 목표다.

FinOps의 3단계

파악도 안 된 상태에서 최적화할 수 없다. Inform이 항상 먼저다. Operate가 마지막인 이유는 한 번 최적화하고 끝이 아니라 지속적으로 유지하고 반복하는 단계이기 때문이다.

비용 낭비 패턴

비용 최적화 전략

Right-sizing 실제 사용량에 맞게 인스턴스 크기를 조정한다. CPU 10%만 쓰는데 최고 사양 인스턴스를 쓰고 있다면 낭비다.

인스턴스 종류별 비교

Auto Scaling 트래픽이 없을 때 자동으로 줄이고, 필요할 때 늘린다. 24시간 최대 용량으로 켜두는 것보다 훨씬 효율적이다.

비용과 Reliability 트레이드오프

비용을 줄이면 Reliability가 낮아질 수 있다. 비용을 줄이면 항상 Reliability가 높아지는 게 아니다.

SRE 관점에서는 Error Budget 안에서 SLO를 지키면서 가장 저렴한 구성을 찾는 것이 목표다.

비용 지표

Unit Economics가 중요한 이유는 트래픽이 늘어도 1건당 비용이 유지되거나 줄어야 사업이 지속 가능하기 때문이다.

정리

FinOps는 비용을 무조건 줄이는 게 아니다. Inform → Optimize → Operate 순서로 파악하고, 낭비를 제거하고, 지속적으로 관리하는 것이다. SLO를 지키면서 가장 효율적인 구성을 찾는 것이 SRE와 FinOps가 만나는 지점이다.

개발자가 인프라를 직접 다루려면 배워야 할 게 너무 많다. K8s 설정, CI/CD 파이프라인, 모니터링 연동, 보안 정책... 이걸 개발자마다 각자 하면 비효율적이고 실수도 많다.

Platform Engineering은 개발자가 인프라를 직접 몰라도 쉽게 쓸 수 있도록 내부 플랫폼을 만드는 것이다. 개발자는 플랫폼을 통해 Self-service로 필요한 것을 가져다 쓴다.

Internal Developer Platform (IDP)

개발자를 위한 내부 플랫폼이다. 외부 사용자를 위한 제품이 아니라, 내부 개발팀이 쓰는 도구다.

Golden Path

플랫폼 팀이 권장하는 표준 개발 방식이다. 검증된 경로를 미리 만들어두면 개발자가 가져다 쓴다.

Golden Path를 쓰면:

• 보안, 모니터링, 배포가 자동으로 따라온다

• 개발자가 인프라 지식 없이도 프로덕션 수준의 서비스를 만들 수 있다

• 팀마다 다르게 하던 걸 표준화할 수 있다

  강제는 아니다. 벗어날 수도 있지만 벗어나면 직접 책임져야 한다.

DevOps vs SRE vs Platform Engineering

SRE가 "서비스가 안 죽게 한다"라면, Platform Engineering은 "개발자가 쉽게 서비스를 만들고 배포하게 한다"다.

Backstage

Spotify가 만든 오픈소스 IDP 프레임워크다. 현재 가장 널리 쓰이는 Platform Engineering 도구다.

• 서비스 카탈로그: 내부 서비스 목록과 소유자 관리
• 템플릿: 표준화된 서비스 생성 자동화
• 플러그인: 모니터링, CI/CD, 문서 연동

정리

Platform Engineering의 핵심은 Self-service와 표준화다. 개발자가 "서버 하나 만들어주세요"라고 요청하는 대신 직접 버튼 하나로 해결하고, K8s yaml이나 CI/CD 설정 같은 걸 매번 처음부터 짜는 게 아니라 검증된 템플릿을 가져다 쓰는 방식이다.

결국 개발자가 인프라 걱정 없이 서비스 개발에만 집중할 수 있는 환경을 만드는 것이 목표다.

컨테이너 환경은 기존 서버 환경과 다르다. Pod가 언제든 죽고 다시 생기고, IP가 바뀌고, 스케일이 자동으로 오르내린다. 기존 방식으로 모니터링하면 놓치는 게 많다.

기존 서버 환경 vs K8s 환경

핵심 차이는 수명과 동적 변화다. 기존 환경은 "이 서버의 CPU가 높다"처럼 대상이 명확하다. K8s는 Pod가 계속 생겼다 사라지기 때문에 서비스 전체 상태를 기준으로 봐야 한다.

Liveness / Readiness Probe

Pod가 정상인지 K8s가 판단하는 기준이다.

Readiness가 없으면 앱이 뜨는 중에 트래픽이 들어와서 배포 중 503이 쏟아진다.

HPA / VPA

SLO와 연결하려면 커스텀 메트릭 기반 HPA를 쓴다. 에러율이 올라가면 Pod를 늘리는 방식이다.

K8s 환경 Observability

로그 Pod가 죽으면 로그도 사라진다. 중앙 로그 수집이 필수다. (Fluentd, Loki 등)

메트릭 노드뿐 아니라 Pod, 컨테이너 단위 메트릭이 필요하다. Prometheus + Grafana가 K8s 표준 스택이다.

트레이싱 마이크로서비스 환경에서 요청이 여러 Pod를 거치기 때문에 Trace가 더 중요하다.

K8s SLO 측정 대상

주요 장애 패턴

정리

K8s SRE의 핵심은 동적 환경에 맞는 관찰 방식이다. Pod가 언제든 사라질 수 있기 때문에 로그는 중앙에 수집하고, 메트릭은 서비스 전체 단위로 보고, Probe로 트래픽 유입 시점을 정확히 제어해야 한다.

장애는 막을 수 없다. 대신 장애가 전파되지 않게 막거나, 부분적으로만 동작하거나, 빠르게 회복하도록 설계할 수 있다. 그게 Reliability Patterns의 목적이다.

Circuit Breaker

문제가 생긴 서비스로의 요청을 자동으로 차단해서 장애 전파를 막는 패턴이다.

실패율이 임계값을 넘으면 Open 상태가 된다. 일정 시간 후 Half-Open으로 전환되고, 일부 요청이 성공하면 Closed로 복귀한다. 계속 재시도하다가 시스템 전체가 느려지는 걸 막는 게 핵심이다.

Retry + Exponential Backoff

일시적인 장애에서 재시도하는 패턴이다. 무작정 재시도하면 서버에 부하가 몰리기 때문에 재시도 간격을 점점 늘린다.

• 1차 재시도: 1초 후

• 2차 재시도: 2초 후

• 3차 재시도: 4초 후

  여기에 Jitter(무작위 편차)를 추가하면 여러 클라이언트가 동시에 재시도하는 Thundering Herd를 방지할 수 있다. Jitter가 없으면 1000개 클라이언트가 전부 동시에 재시도해서 서버 부하가 급등한다.

Bulkhead

배의 격벽처럼 서비스 리소스를 격리해서 한 곳의 장애가 전체로 번지지 않게 막는 패턴이다.

결제 API와 조회 API가 같은 스레드 풀을 쓰면 조회 요청이 폭발할 때 결제도 느려진다. Bulkhead를 적용하면 스레드 풀을 분리해서 서로 영향을 안 준다.

Circuit Breaker와 헷갈리기 쉬운데 구분 기준은 이렇다.

• Circuit Breaker: 문제 있는 서비스로 요청이 가는 걸 차단
• Bulkhead: 서비스 간 리소스를 격리해서 영향이 번지는 걸 차단

Timeout

응답을 무한정 기다리지 않고 일정 시간 후 실패 처리하는 패턴이다. Timeout이 없으면 느린 서비스 하나가 전체 요청을 블로킹한다.

Graceful Degradation

일부 기능이 실패해도 핵심 기능은 동작하게 유지하는 패턴이다.

• 추천 서비스가 죽어도 상품 목록은 보여준다

• 실시간 데이터를 못 가져오면 캐시된 데이터를 보여준다

  전부 아니면 전무(All or Nothing)가 아니라, 부분적으로라도 동작하는 것이 목표다.

정리

이 패턴들은 하나만 쓰는 게 아니라 조합해서 쓴다. 실제 시스템에서는 Timeout + Circuit Breaker + Graceful Degradation이 같이 적용되는 경우가 많다.

서비스 장애의 70% 이상은 변경(Change)에서 발생한다. 새 기능 배포, 설정 변경, 인프라 업그레이드 — 전부 변경이다.

Change Management는 변경으로 인한 장애를 최소화하기 위한 프로세스다. 변경을 막는 게 아니라, 변경을 안전하게 하는 것이 목적이다.

변경의 종류

배포 전략

변경을 안전하게 하는 핵심은 점진적 배포다.

Canary 배포 전체 트래픽 중 일부(예: 1~5%)에만 먼저 배포한다. 문제가 없으면 점진적으로 확대하고, 문제가 생기면 해당 트래픽만 롤백하면 된다.

Blue/Green 배포 기존 환경(Blue)을 그대로 두고 새 환경(Green)을 별도로 구성한다. 준비되면 트래픽을 한 번에 전환하고, 문제 시 Blue로 즉시 롤백 가능하다.

Feature Flag 코드 배포와 기능 활성화를 분리한다. 코드는 배포됐지만 플래그를 끄면 사용자에게 노출되지 않는다. 특정 사용자 그룹에만 먼저 켤 수도 있다.

DORA 지표

Change Management 수준을 측정하는 4가지 지표다.

배포를 자주 하면서 Change Failure Rate가 낮은 팀이 잘하는 팀이다.

롤백 전략

배포했는데 문제가 생기면 빠르게 롤백할 수 있어야 한다.

• 롤백 절차가 미리 정의되어 있어야 한다
• 롤백 시간이 길면 그만큼 장애 시간이 늘어난다
• DB 스키마 변경은 기존 데이터에 영향을 주고 하위 호환을 깨뜨릴 수 있어서 별도 전략이 필요하다

정리

변경을 줄이는 것이 답이 아니다. 오히려 자주 배포하되 안전하게 하는 것이 목표다. Canary, Blue/Green, Feature Flag로 점진적으로 배포하고, DORA 지표로 수준을 측정하고, 롤백 절차를 미리 준비해두는 것이 Change Management의 핵심이다.

알림 기준을 어떻게 정할 건지가 문제다. CPU 75%면 알림? 에러율 1%면 알림? 이 숫자들이 감으로 정해진 거라면 SLO 달성과 직접 연결이 안 된다.

SLO 기반 알림은 SLO와 Error Budget을 기준으로 알림을 설계하는 방식이다.

Burn Rate

Error Budget이 얼마나 빠르게 소진되고 있는지를 나타내는 지표다.

• SLO: 월 99.9% 가용성 → Error Budget = 월 43.2분

• Burn Rate 1 = 정상 속도로 소진 중

• Burn Rate 10 = 10배 빠르게 소진 중

• Burn Rate 720 = 1시간 안에 한 달치 Error Budget을 다 쓴다

  Burn Rate가 높을수록 긴급하다.

왜 Burn Rate 기반으로 설계하나

에러율이 낮아도 오래 지속되면 Error Budget이 많이 소진된다. 반대로 에러율이 높아도 금방 회복되면 SLO에 영향이 없다. Burn Rate는 이 둘을 모두 반영한다.

멀티 윈도우 알림

Burn Rate만으로는 부족하다. 단기 급등인지 장기 지속인지 구분이 안 되기 때문이다.

두 윈도우 모두 Burn Rate가 높을 때만 알림을 낸다. 1시간만 높으면 노이즈일 가능성이 크다.

알림 티어 설계

모든 알림을 Page로 설계하면 Alert Fatigue가 온다. 긴급도에 따라 티어를 나눠야 한다.

정리

SLO 기반 알림 설계 순서는 이렇다.

SLO 정의 → Error Budget 계산 → Burn Rate 설계 → 알림 티어 설정

기존 임계값 방식보다 복잡하지만 사용자 영향도와 직접 연결되어 있고, Alert Fatigue를 줄일 수 있다. 긴급한 것과 그렇지 않은 것을 구분하는 게 핵심이다.

시스템이 "잘 돌아가고 있다"는 건 장애가 없는 게 아니라 장애가 와도 버틸 수 있다는 뜻이다. Chaos Engineering은 그걸 미리 검증하는 방법이다.

한 줄 정의: 의도적으로 장애를 만들어서 시스템의 약점을 먼저 찾는 것

Netflix가 처음 만든 개념이다. 프로덕션 서버를 무작위로 죽이는 "Chaos Monkey"를 실제로 운영했고, 거기서 발전했다.

왜 하는가

테스트는 "예상한 시나리오"만 검증한다. 근데 실제 장애는 예상 밖에서 온다.

• 특정 서버가 갑자기 죽으면?

• DB 응답이 10배 느려지면?

• 네트워크 패킷이 30% 손실되면?

  이런 상황을 미리 만들어보면 시스템이 어떻게 반응하는지 알 수 있다. 모르는 채로 있다가 실제 장애 때 처음 보는 것보다 훨씬 낫다.

핵심 원칙

실험 절차

1. 정상 상태 정의: 지금 시스템의 정상 기준을 SLI로 정한다 (예: 에러율 < 1%)

2. 가설 수립: "서버 1대가 죽어도 에러율 1% 미만이어야 한다"

3. 실험 설계: 어떤 장애를 어떤 범위에서 주입할지 결정

4. 실행: 장애 주입

5. 관찰: 시스템이 가설대로 동작하는지 확인

6. 복구 & 분석: 결과 기록, 약점 발견 시 개선

   정상 상태 정의가 가장 먼저다. 지금 정상이 뭔지 알아야 가설을 세울 수 있기 때문이다.

대표 도구

Game Day

Chaos Engineering을 팀 훈련으로 만든 것이 Game Day다.

정해진 날에 팀 전체가 모여서 의도적으로 장애를 내고, On-call 프로세스가 제대로 동작하는지 처음부터 끝까지 훈련한다. 알림이 제대로 오는지, Runbook대로 대응이 되는지, MTTA/MTTR이 목표치 안에 드는지 전부 확인한다.

정리

Chaos Engineering은 "장애가 안 나게 하는 것"이 아니라 "장애가 났을 때 시스템이 어떻게 반응하는지 미리 아는 것"이다.

일반 테스트가 예상한 시나리오를 검증한다면, Chaos Engineering은 예상 밖 상황을 검증한다. 둘은 대체 관계가 아니라 보완 관계다.

On-call은 서비스 장애가 발생했을 때 즉시 대응할 수 있는 당직 체계다. 24시간 365일 서비스를 운영하면 언제든 장애가 터질 수 있는데, 그때 "누가 받을 건데?"를 미리 정해두는 것이다.

개발자 한 명이 항상 대기하는 게 아니라, 팀원들이 돌아가면서 담당하는 Rotation 구조로 운영한다.

핵심 구성 요소

Escalation Policy가 없으면 Primary가 못 받았을 때 알림이 그냥 사라진다. 반드시 있어야 한다.

핵심 지표

On-call 품질을 측정하는 지표가 두 가지 있다.

MTTA가 길다는 건 알림을 못 받거나 늦게 확인한다는 뜻이다. MTTR이 길다는 건 인지는 했는데 해결이 느리다는 뜻이다. 둘 다 추적해야 어디서 병목인지 보인다.

On-call 피로

On-call 자체보다 On-call 피로(Fatigue)가 더 큰 문제다. 피로가 쌓이면 알림을 무시하거나, 번아웃이 오거나, 팀 전체 사기가 떨어진다.

주요 원인은 세 가지다.

1. 노이즈 알림 진짜 장애가 아닌데 울리는 알림. 알림이 자주 오면 "또 오겠지"라는 학습된 무기력이 생긴다. Alerting 설계를 잘못하면 여기서 막힌다.

2. 불공평한 로테이션 특정 사람만 자꾸 당직을 서거나, 야간 당직이 한쪽에 몰리면 반드시 문제가 된다. 자동화된 스케줄링 도구(PagerDuty, OpsGenie 등)를 쓰는 이유가 여기 있다.

3. 보상 없음 야간에 2시간 대응하고 아무 보상이 없으면 지속 불가능하다. 보상 체계가 없는 On-call은 팀 이탈로 이어진다.

Runbook

Runbook은 장애 대응 절차서다. "이 알림이 오면 이렇게 해라"를 미리 적어두는 것이다.

On-call 담당자가 해당 서비스를 잘 모르는 경우가 있다. 로테이션으로 돌아가다 보면 내 영역이 아닌 서비스 당직을 서야 할 수도 있기 때문이다. Runbook이 잘 정비돼 있으면 모르는 서비스도 절차대로 대응할 수 있다.

좋은 Runbook의 조건:

• 알림 이름과 1:1로 매핑되어 있다
• 진단 명령어가 복붙 가능한 형태로 있다
• "이 단계에서 모르겠으면 누구한테 연락해라"가 명시되어 있다

정리

On-call은 그냥 폰 들고 대기하는 게 아니다. Rotation, Escalation Policy, Runbook이 제대로 갖춰져야 지속 가능한 운영이 된다. MTTA/MTTR로 측정하고, 피로 원인을 주기적으로 점검하는 게 SRE의 역할이다.

결국 On-call을 잘한다는 건 "장애를 빨리 끄는 것"이 아니라 "장애가 와도 팀이 지치지 않는 구조를 만드는 것"이다.

장애가 나고 나서 서버를 늘리는 게 아니라, 미리 예측해서 준비하는 방법에 대한 내용이다.

Capacity Planning이 뭔가

한 줄 정의는 이렇다.

"미래의 트래픽을 예측해서 서버 용량을 미리 준비하는 것"

준비가 안 됐을 때와 됐을 때의 차이는 명확하다.

❌ 준비 안 했을 때 트래픽 폭증 → 서버 다운 → Error Budget 소진

✅ 준비 했을 때 성장률 예측 → 미리 확장 → 장애 없음

핵심 3가지

1. 현재 용량 파악

지금 시스템이 어느 정도를 버티는지 먼저 알아야 한다. TPS, CPU, 메모리, 응답시간이 SLO를 넘기 시작하는 지점을 측정한다.

2. 트래픽 성장 예측

과거 데이터로 성장률을 계산한다.

3개월 전: 1,000 TPS → 현재: 1,300 TPS → 월 성장률 약 10% 6개월 후 예측: 약 2,300 TPS

3. 여유분 (Headroom) 확보

예측은 항상 틀릴 수 있다. 이벤트나 마케팅으로 갑자기 폭증할 수도 있다. 그래서 예측값의 30% 정도 여유를 두고 준비한다.

USE Method

시스템 용량 상태를 판단하는 기준이다.

Utilization이 높아도 Saturation이 없으면 아직 괜찮다. Saturation이 생기기 시작하면 용량 한계에 가까워진 신호다.

언제 확장해야 하는가

Utilization 70% 도달 → 확장 계획 시작 Utilization 85% 도달 전 → 확장 완료

월 10% 성장률 기준으로 계산하면 이렇다.

현재 60% → 1개월 후 66% → 2개월 후 73% (70% 초과) → 지금부터 1개월 안에 계획 수립 필요

너무 일찍 확장하면 비용 낭비고, 너무 늦으면 장애로 이어진다. 숫자로 계산해서 타이밍을 잡는 게 핵심이다.

정리

Capacity Planning은 결국 Error Budget과 연결된다.

용량 초과로 장애가 나면 Error Budget이 소진된다. 미리 준비해두면 예방 가능한 Budget 소진을 막을 수 있다.

서비스를 수치로 정의하는 개념이다.

SLI는 현재 서비스 상태를 측정한 수치고, SLO는 팀 내부에서 유지해야 하는 목표값이다. SLA는 그 목표를 고객과 계약으로 맺은 것으로, 위반하면 패널티가 생긴다.

쉽게 기억하는 방법은 이렇다.

SLI → 지금 가용성이 99.7%다 (측정값) SLO → 99.9% 이상 유지해야 한다 (내부 목표) SLA → 99.5% 보장, 위반 시 환불 (고객 계약)

SLA는 항상 SLO보다 낮게 설정한다. 그 차이가 버퍼가 되어서 SLO를 약간 못 지켜도 고객 클레임이 발생하지 않는다.

Error Budget

SLO를 기반으로 실패해도 되는 허용 범위를 수치로 정한 것이다.

Error Budget = 100% - SLO SLO 99.9% → 한 달 43.2분까지 다운돼도 괜찮다

버짓을 최대한 아끼는 게 목표가 아니다. 버짓은 새 기능을 배포하기 위한 연료다. 버짓이 남아있을 때 적극적으로 배포하고, 소진되면 배포를 중단하고 안정성 개선을 먼저 한다.

버짓 소진이 꼭 개발팀 배포 때문만은 아니다. 인프라 문제나 외부 의존성 장애도 버짓을 소진시킨다.

Toil

자동화할 수 있는데 사람이 손으로 반복하고 있는 작업이다.

귀찮은 일이랑은 다르다. 반복적이고, 자동화 가능하고, 서비스가 커질수록 같이 늘어나는 작업이 Toil이다.

Google SRE 기준으로 Toil은 업무 시간의 50%를 넘으면 안 된다. 넘기는 순간 개선하는 팀이 아니라 그냥 반복 작업하는 팀이 된다.

자동화도 비용이 들기 때문에 무조건 하는 게 아니라 절감 효과가 자동화 비용보다 클 때 한다.

Observability

모니터링이랑 다른 개념이다.

모니터링은 미리 정해둔 지표를 보는 것이고, Observability는 어떤 질문이든 데이터로 답할 수 있는 능력이다.

세 기둥으로 구성된다.

세 개가 같이 있어야 장애를 빠르게 해결할 수 있다. Metrics만 있으면 "이상하다"는 건 알지만 왜, 어디서인지는 모른다.

Alerting 설계

알림이 많다고 좋은 게 아니다.

알림이 너무 많으면 Alert Fatigue가 생긴다. 팀이 알림에 무감각해져서 진짜 장애 알림도 무시하게 된다.

좋은 알림은 사용자가 실제로 영향을 받는 증상 기준으로 설계한다.

❌ "DB 슬로우 쿼리 10개 발생" → 내부 수치, 사용자 영향 불명확 ✅ "결제 성공률 95% 아래로 하락" → 사용자가 결제를 못 하고 있음

그리고 알림마다 Runbook을 연결해두면 처음 보는 알림도 절차대로 대응할 수 있다.

Incident Management

장애가 발생했을 때 표준화된 절차로 대응하는 것이다.

감지 → 대응 → 완화 → 해결 → 사후분석

완화는 일단 불을 끄는 것이고, 해결은 불이 왜 났는지 찾는 것이다. 급할 때는 완화 먼저, 그 다음 근본 원인을 해결한다.

장애가 끝난 후에는 반드시 Postmortem을 작성한다. 핵심은 사람을 비난하지 않는 것이다. 누가 실수했는지가 아니라 왜 그 실수가 장애로 이어질 수 있었는지를 본다.

근본 원인은 5 Whys로 찾는다. "왜?"를 5번 반복해서 표면적 원인이 아닌 진짜 원인을 찾는 것이다. 마지막 원인이 팀이 실제로 개선할 수 있는 것이어야 한다.

서비스 품질이 저하되거나 중단되는 사건이다. 중요한 건 발생했을 때 표준화된 절차로 대응하는 것이다.

인시던트 대응 5단계

Mitigation과 Resolution을 헷갈리기 쉬운데 이렇게 구분하면 된다.

Mitigation = 불 끄기 (서버 재시작으로 일단 복구) Resolution = 불이 왜 났는지 찾기 (메모리 누수 코드 수정)

급할 때는 Mitigation 먼저, 그 다음 Resolution이다.

Postmortem (사후 분석)

인시던트가 끝난 후 재발을 막기 위해 작성하는 문서다. 서비스가 복구됐다고 안 쓰면 같은 장애가 반복된다.

Blameless (무비난) 원칙

사람을 비난하지 않는다. 시스템의 문제를 찾는다.

❌ 잘못된 접근 "김개발이 배포하다가 실수한 거잖아요"

✅ 올바른 접근 "왜 배포 실수가 장애로 이어질 수 있는 구조였는가?"

사람을 탓하면 다음번에 장애를 숨기게 된다. 시스템을 탓해야 다음번에 솔직하게 보고한다.

5 Whys 기법

근본 원인을 찾는 방법이다. "왜?"를 5번 반복한다.

장애: 사용자들이 로그인을 못 하고 있다

Why 1: 왜? → 인증 서버가 응답하지 않는다 Why 2: 왜? → 메모리가 꽉 찼다 Why 3: 왜? → 특정 요청이 메모리를 반환하지 않는다 Why 4: 왜? → 예외 발생 시 finally 블록이 없다 Why 5: 왜? → 예외 케이스 테스트 기준이 없었다

근본 원인: 테스트 기준 부재

표면적 원인만 보면 재시작으로 끝난다. 근본 원인까지 찾아야 재발을 막을 수 있다.

5 Whys의 핵심은 마지막 원인이 팀이 실제로 개선할 수 있는 것이어야 한다는 점이다. "회사에 돈이 없어서" 같은 답은 Action Item으로 이어질 수 없다.

Postmortem 구성

Action Items는 반드시 구체적이고 추적 가능해야 한다.

❌ 나쁜 Action Item "장애 재발 방지를 위해 노력한다"

✅ 좋은 Action Item "예외 케이스 테스트 가이드라인 작성 (담당: 김개발, 기한: 3/20)"

나쁜 알림 설계의 가장 큰 부작용이다.

알림이 너무 많으면 → 팀원이 알림에 무감각해짐 → 진짜 중요한 알림도 무시하게 됨 → 실제 장애를 늦게 발견 → 서비스 다운

알림의 신뢰도를 유지하는 것 자체가 SRE의 중요한 역할이다.

나쁜 알림 vs 좋은 알림

❌ 나쁜 알림 CPU가 75%를 넘을 때마다 즉시 알림을 보낸다. 순간적인 스파이크에도 울리고, 하루에 수십 번 발생할 수 있다.

✅ 좋은 알림 CPU가 75%를 5분 이상 지속할 때 알림을 보낸다. 10분 쿨다운으로 같은 알림이 반복되지 않는다.

좋은 알림의 5가지 원칙

Symptom-based vs Cause-based

가장 중요한 원칙이다.

❌ Cause-based (원인 기반) "DB 슬로우 쿼리가 10개 발생했다" → 내부 수치일 뿐, 사용자가 지금 불편한지 모른다

✅ Symptom-based (증상 기반) "결제 성공률이 95% 아래로 떨어졌다" → 사용자가 실제로 결제를 못 하고 있다

사용자가 느끼는 증상을 기준으로 설계해야 한다.

Runbook이 뭔가

알림마다 연결해두는 대응 절차 문서다.

알림: "결제 오류율 2% 초과" Runbook:

1. 결제 서비스 로그 확인

2. 외부 PG사 상태 페이지 확인

3. 이상 없으면 DB 커넥션 확인

4. 해결 안 되면 온콜 담당자 호출

   Runbook이 있으면 처음 보는 알림도 절차대로 대응할 수 있다. 없으면 매번 "이거 어떻게 처리하지?"부터 시작한다.

정리

처음엔 모니터링이랑 같은 말인 줄 알았는데 달랐다.

모니터링이랑 뭐가 다른가

모니터링: "CPU가 80%다" → 미리 정해둔 지표를 보는 것 Observability: "왜 저 요청만 느린 거지?" → 어떤 질문이든 데이터로 답할 수 있는 것

모니터링은 알고 있는 문제를 감지한다. Observability는 모르는 문제도 찾아낼 수 있다.

세 기둥 (Three Pillars)

Observability는 세 가지로 구성된다.

각각 어떤 상황에서 쓰는가

✅ Metrics 오류율, 응답시간, CPU 같은 수치를 추적할 때. "이상하다"는 걸 가장 먼저 감지하는 역할이다.

✅ Logs 특정 오류가 왜 발생했는지 파악할 때. "무슨 일이 있었는지" 상세하게 기록되어 있다.

✅ Traces 요청이 시스템을 통과하는 전체 경로와 구간별 시간을 보여준다.

사용자 요청 총 2,100ms ├─ API 서버 처리: 50ms ├─ DB 쿼리: 1,800ms ← 여기가 문제 └─ 외부 API 호출: 250ms

DB가 느린지, 외부 API가 느린지 딱 집어낼 수 있다.

장애 상황에서 세 개를 같이 쓰면

1단계 - Metrics로 감지: "오류율이 갑자기 5%로 올랐다" 2단계 - Logs로 원인 파악: "결제 서비스에서 timeout 에러 발생" 3단계 - Traces로 위치 특정: "외부 PG사 API 호출에서 3초씩 걸림"

세 개가 같이 있어야 장애를 빠르게 해결할 수 있다. 하나만 있으면 절반만 보이는 것과 같다.

Observability가 없으면

❌ 장애 발생 → 어디가 문제인지 몰라서 코드 뒤짐 → 로그 추가하고 재배포 → 재현 시도 → 틀리면 다시 반복 → 수 시간 소요

Observability가 있으면 Metrics로 감지하고, Logs로 원인 찾고, Traces로 위치 특정해서 수십 분 안에 해결된다. MTTR(평균 복구 시간)이 극적으로 줄어든다.

정리

한 줄 정의

"자동화할 수 있는데 사람이 손으로 반복하고 있는 작업"

단순히 귀찮은 일이 아니다. Toil로 분류되려면 6가지를 만족해야 한다.

뭐가 Toil이고 뭐가 아닌가

처음에 헷갈렸던 부분이다.

✅ Toil 맞음

• 서버 추가할 때마다 설정 파일 직접 수정
• 배포할 때마다 같은 체크리스트 수동 확인
• 매월 서버 100대에 직접 SSH 접속해서 패치 적용

❌ Toil 아님

• 장애 원인 분석 (매번 다른 문제, 판단 필요)

• 코드 리뷰 (판단 필요)

• 아키텍처 설계 (창의적 작업)

  장애 원인 분석을 Toil로 착각하기 쉬운데, 매번 다른 원인을 다루고 판단이 필요하기 때문에 Toil이 아니다.

50% 규칙

Google SRE에서 정한 기준이다.

SRE는 업무 시간의 50% 이상을 Toil에 써서는 안 된다

"10분밖에 안 걸리니까 괜찮다"는 착각

Toil을 방치하는 가장 흔한 이유다.

10분 × 365일 = 연 60시간이다. 팀원 5명이면 연 300시간이다. 그리고 서비스가 커지면 10분이 20분, 30분이 된다.

지금 작다고 방치하면 나중에 더 크게 돌아온다.

자동화 투자 판단법

Toil을 발견했다고 무조건 자동화하는 게 아니다.

작업 시간 × 발생 빈도 > 자동화 개발 시간이면 해야 한다

매주 3시간짜리 Toil이 있고 자동화 개발에 20시간이 걸린다면, 7주 후부터 이득이고 1년 기준 136시간을 절약한다. 해야 한다.

반대로 1년에 한 번 있는 작업을 자동화하는 데 40시간을 쓰면 본전 뽑는 데 40년이 걸린다. 이건 하지 않는 게 낫다.

정리

Toil을 완전히 없애는 게 목표가 아니다. 현실적으로 제로는 불가능하고, 자동화 자체도 비용이 든다.

목표는 50% 이하로 유지하면서 남은 시간을 진짜 엔지니어링에 쓰는 것이다.

지난 글에서 SLI / SLO / SLA를 정리했다.

이번엔 SLO를 배우고 나면 자연스럽게 나오는 질문, "그래서 얼마나 실패해도 되는 거야?" 에 대한 답인 Error Budget을 정리해본다.

왜 필요한가

SLO를 정하고 나면 팀 안에서 이런 상황이 생긴다.

상황

개발팀: "새 기능 배포하고 싶은데요" SRE팀: "배포하면 장애 날 수도 있어요. 위험합니다" 개발팀: "그럼 언제 배포할 수 있어요?" SRE팀: "..."

SRE팀이 배포를 막는 역할이 되면 개발팀과 계속 충돌한다. 이걸 없애려면 "얼마나 실패해도 되는가"를 미리 숫자로 정해야 한다. 그게 Error Budget이다.

공식

Error Budget = 100% - SLO

SLO가 99.9%라면 Error Budget = 100% - 99.9% = 0.1% 0.1%가 체감이 잘 안 돼서 한 달(30일) 기준 분 단위로 바꾸면 한 달 총 분 = 30 × 24 × 60 = 43,200분 허용 다운타임 = 43,200 × 0.001 = 43.2분

SLO 99.9% = 한 달에 43분까지는 서버가 죽어도 괜찮다는 뜻이다.

SLO별로 얼마나 차이나는지

직접 비교해보면 차이가 크게 느껴진다.

배포 결정에 어떻게 쓰이는가

버짓이 얼마나 남았냐에 따라 배포 여부를 결정한다.

버짓 50% 이상 남음 → 대규모 배포 가능 버짓 20~50% 남음 → 소규모 배포만 허용 버짓 20% 미만 남음 → 배포 중단, 안정성 개선 집중 버짓 소진 → 모든 배포 금지

이렇게 하면 "배포해도 돼요?" 가 주관적인 판단이 아니라 데이터 기반 대화가 된다.

가장 중요한 관점

처음 배울 때 이렇게 오해하기 쉽다.

❌ 버짓이 있으니까 그냥 실패해도 된다 ❌ 버짓을 최대한 아껴야 한다

✅ 버짓은 혁신(배포)을 위한 연료다

버짓이 남아있을 때 배포를 망설이는 것 자체가 낭비다. 버짓은 다음 달로 이월되지 않는다. 다 쓰지 않고 달이 끝나면 그냥 사라진다.

반대로 버짓이 소진됐을 때 배포를 강행하는 것도 문제다. 버짓 소진은 "이번 달 시스템이 많이 불안정했다"는 신호인데, 원인도 모르는 상태에서 변경을 추가하면 위험이 겹친다.

버짓이 소진되는 원인

한 가지 더 알게 된 것이 있다.

버짓 소진이 꼭 개발팀 배포 때문만은 아니라는 점이다.

• 개발팀 신규 배포 중 장애

• 인프라 문제로 서버 다운

• 외부 의존성 장애 (DB, 결제 API 등)

• 예측 불가한 자연 발생 장애

  외부 API가 다운돼서 내 서비스가 영향을 받아도 버짓이 소진된다. 그래서 버짓이 소진됐을 때 개발팀만 탓할 수 없고, SRE팀이 같이 원인을 찾아야 한다.

정리

Google이 2003년에 만든 직군이자 운영 방법론이다.

핵심은 이 한 문장이다.

"소프트웨어 엔지니어링 방식으로 운영 문제를 해결한다"

기존에는 개발팀이 코드를 만들면 운영팀이 서버를 관리하는 구조였는데, 서비스가 커질수록 수동 운영이 불가능해졌다. Google이 "그냥 운영도 코드로 자동화하면 되지 않나?"라고 생각한 게 시작이다.

DevOps랑 자주 비교되는데 이렇게 이해하면 편하다.

• DevOps : 개발과 운영이 협력해야 한다는 문화/철학

• SRE : 그 철학을 어떻게 실행할지에 대한 구체적인 방법론

  DevOps가 "뭘 해야 하는지"라면, SRE는 "어떻게 하는지"다.

SLI - 지금 서비스 상태를 수치로 측정하는 것

SLI(Service Level Indicator) 는 서비스 품질을 측정한 수치다.

중요한 건 "사용자가 체감하는 품질" 을 기준으로 잡아야 한다는 점이다.

좋은 SLI 예시

• 가용성 : 정상 응답 수 / 전체 요청 수 × 100 = 99.95%

• 오류율 : 5xx 오류 수 / 전체 요청 수 × 100 = 0.03%

• 응답시간 : 요청의 99%가 200ms 이내로 처리됨

  나쁜 SLI 예시

• CPU 사용률 80% → 사용자 입장에서 직접적인 영향이 아님

• 서버 대수 3대 → 서비스 품질을 나타내지 않음

  SLI는 측정된 숫자 그 자체다. 여기에 아무 판단이나 행동이 들어오면 SLI가 아니다. "현재 가용성이 99.7%이다" — 이게 SLI다.

SLO - 얼마나 유지해야 하는지 목표를 정하는 것

SLO(Service Level Objective) 는 SLI에 목표값을 붙인 것이다. 팀 내부에서 "이 수준은 지키자"고 정한 기준선이다.

SLI : 현재 가용성이 99.7%이다 ← 측정값 SLO : 가용성은 99.9% 이상이어야 한다 ← 목표값

SLO는 내부 기준이라서, 위반해도 고객한테 직접 책임지는 일은 없다. 다만 팀이 "뭔가 잘못됐다"는 신호로 받아들여야 한다.

좋은 SLO를 정의하려면 세 가지 조건을 만족해야 한다.

• 사용자 관점 : 사용자가 느끼는 품질을 반영해야 한다
• 측정 가능 : 수치로 명확하게 측정할 수 있어야 한다
• 현실적 : 달성 가능한 수준이어야 한다 (100%는 현실적으로 불가능하다)

SLA - 고객한테 약속하는 것

SLA(Service Level Agreement) 는 SLO를 고객과 계약으로 맺은 것이다. 여기서부터 위반하면 패널티(환불, 크레딧 지급 등) 가 생긴다.

SLO : 내부 목표 "우리 팀은 99.9% 유지하자" SLA : 외부 계약 "고객에게 99.5% 보장, 위반 시 크레딧 지급"

AWS S3 서비스 정책을 보면 이런 내용이 있다.

월간 가동률 99.9% 미만 시 서비스 크레딧 지급

이게 SLA다. AWS 내부에서 실제로 유지하는 SLO는 이것보다 훨씬 높게 설정되어 있을 것이다.

왜 SLA를 SLO보다 낮게 잡는지

처음에 이게 이해가 안 됐는데 이렇게 생각하면 된다.

SLO = 99.9% (내부 목표) SLA = 99.5% (고객 보장) ↑ 0.4% 차이 = 여유분

SLO를 약간 못 지켜서 실제 가용성이 99.6%가 되더라도, SLA(99.5%)는 지킬 수 있다. 고객 클레임이 발생하지 않는다.

이 버퍼가 있어야 팀이 사고 없이 운영할 수 있다.

세 개념 정리

헷갈리지 않으려고 체온계로 비유해봤다.

SLI = 체온계 수치 (지금 38.2°C) SLO = 의사의 목표 (37.5°C 이하로 유지) SLA = 보험 계약 (40°C 이상이면 보험금 지급)

표로 보면 이렇다.

외워야 할 것만 정리하면

• SLA ≤ SLO (항상 SLA가 더 낮거나 같다)
• SLI는 숫자만, SLO는 숫자 + 기준, SLA는 숫자 + 기준 + 패널티
• SLO 위반은 팀 내부 문제, SLA 위반은 고객 클레임