환영합니다
환영합니다
웹 규모 플릿에는 많은 머신이 포함되어 있습니다. 어떤 순간이든 일부는 정상 상태이고, 일부는 시작 중이며, 일부는 드레인 중이고, 일부는 조용히 고장 나 있습니다. 플릿이 이를 견디는 이유는 모든 머신이 요청 시 두 가지 간단한 질문에 답하기 때문입니다:
- /health — 현재 실제 요청을 처리할 수 있는가?
- /version — 어떤 코드를 실행하고 있는가?
모니터링 도구가 스크래핑할 수 있는 카운터 및 게이지를 노출하는 메트릭스 엔드포인트(일반적으로 /metrics)도 포함됩니다.
이 레슨에서는 이러한 엔드포인트가 실제 상황을 정확히 반영하도록 설계하는 방법, 프록시 계층에서 네 가지 골든 시그널의 의미, 그리고 관찰된 데이터가 용량 결정에 어떻게 영향을 미치는지를 배웁니다.
수업이 끝날 때쯤에는 다음을 수행할 수 있습니다:
- 프로세스의 생존 여부뿐 아니라 실제 경로 장애를 감지하는 /health 엔드포인트를 설계합니다
- 배포가 정상적으로 완료되었는지 검증할 수 있는 /version 엔드포인트를 설계합니다
- 프록시 계층에 네 가지 골든 시그널(지연 시간, 트래픽, 오류, 포화 상태)을 적용합니다
- 관찰된 서지(급증) 메트릭을 용량 결정과 연결합니다: 언제 스케일 업할지, 언제 트래픽을 배수(drain)할지, 언제 페이지(긴급 알림)를 보낼지
- '우리가 얼마나 신경 써야 하는가?'라는 질문 뒤에 있는 운영 원칙으로서 SLO 및 에러 버짓 소진율을 논리적으로 분석합니다
두 가지 종류의 헬스 체크
Liveness와 Readiness
Liveness: 프로세스가 살아있는가? 오케스트레이터(Kubernetes, systemd)가 프로세스를 재시작할지 결정하는 데 사용됩니다.
Readiness: 프로세스가 지금 실제 트래픽을 처리할 준비가 되어 있는가? 로드 밸런서가 요청을 보낼지 결정하는 데 사용됩니다.
이것은 서로 다른 질문입니다. 데이터베이스에 접근할 수 없는 프로세스는 살아있지만 준비되지 않은 상태입니다. 시작 중인 프로세스도 살아있지만 아직 준비되지 않은 상태입니다.
얕은(Shallow) vs 깊은(Deep) 헬스 체크
Shallow: HTTP 핸들러가 실행되면 {"status": "ok"}를 반환합니다. 매우 단순하며 프로세스 다운 상태만 감지합니다.
Deep: 실제 요청 경로를 실제로 실행해 봅니다. 데이터베이스 연결 풀이 연결을 반환할 수 있는지, 캐시에 접근할 수 있는지, 하위 의존성이 응답하는지 확인합니다. 얕은 체크가 놓치는 기능적 장애를 감지합니다.
Trade-off(장단점): 심층 체크는 비용이 더 많이 듭니다(각 체크는 기본적으로 합성 요청과 같습니다) & 연쇄적 장애를 유발할 수 있습니다(모든 리플리카의 헬스 체크가 데이터베이스를 집중적으로 공격하면, 느려진 데이터베이스가 모든 리플리카를 비정상 상태로 만들어 회전에서 제외되고, 이는 모든 용량을 제거하게 됩니다).
Best practice(최적의 관행): 생존성(liveness)을 위한 얕은 체크(빠르고, 저렴하며, 외부 의존성이 없음) & 준비 상태(readiness)를 위한 더 깊은 체크(캐시된 결과, 다운스트림을 집중적으로 공격하지 않도록 스로틀링 적용).
버전 엔드포인트
/version은 git 커밋, 빌드 시간, & 서비스 이름을 반환합니다. 배포 후 curl https://service.example.com/version을 실행하여 반환된 커밋이 푸시한 것과 일치하는지 확인합니다. 일치하지 않으면 배포가 조용히 실패한 것입니다.
/version이 없으면, 오래된 배포가 성공적으로 보일 수 있으며 몇 시간 동안 숨겨질 수 있습니다.
최소 응답 형식: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
지연 시간, 트래픽, 오류, 포화도
운영의 대부분을 커버하는 4개의 숫자
구글 SRE 책에서 가져왔습니다. 모든 서비스 계층에서 측정하는 4가지 시그널입니다. 이 4가지를 잘 계측하면 사용자가 인지하기 전에 대부분의 프로덕션 문제를 포착할 수 있습니다.
Latency(지연 시간): 요청에 걸리는 시간은 얼마나 되는가? 평균값만이 아닌 분포를 보고해야 한다. p99(99백분위 지연 시간)가 평균보다 더 중요하다. 왜냐하면 사용자가 '느리다'고 느끼는 것은 꼬리 지연(tail latency)이기 때문이다. 평균 50ms이고 p99가 5,000ms인 서비스는 대부분의 사용자는 인지하지 못하지만, 가장 큰 영향을 받는 1%의 사용자에게는 절대적으로 심각한 실제 문제를 가지고 있다.
Traffic(트래픽): 초당 요청 수는 얼마나 되는가? 총 요청 수, 엔드포인트별, 상태 코드별, 지역별 트래픽을 추적한다. 기준선(Baseline)을 파악하고 이상치에 대해 경보를 설정한다(갑작스러운 감소 = 인그레스 문제, 갑작스러운 급증 = 트래픽 폭주 또는 공격).
Errors(에러): 실패한 요청의 비율이다. 4xx(클라이언트 에러, 내 책임이 아님)와 5xx(서버 에러, 내 책임)를 구별한다. 경보가 다양한 부하 수준에서 작동하도록, 절대 개수가 아닌 트래픽 대비 백분율로 에러율을 추적한다.
Saturation(포화도): 시스템이 얼마나 가득 차 있는가? CPU 사용률, 메모리, 연결 풀 깊이, 큐 길이를 모니터링한다. 이는 선행 지표이다. 포화도는 지연 시간이나 에러가 악화되기 전에 먼저 상승한다. 90% 포화도에 도달한 티어는 큐 붕괴까지 나쁜 1분만 남겨둔 상태이다.
프록시 티어에 특히 주목할 때
각 시그널은 엣지 레이어에서 다음과 같이 발광한다:
- 프록시에서의 지연 시간: TLS 핸드셰이크 시간, 업스트림 연결 시간, 요청-응답 총 소요 시간. 경로(path)의 서로 다른 부분에 위치하므로 각각 별도로 측정한다.
- 프록시에서의 트래픽: 총 초당 요청 수, 백엔드별 분포(뜨거운(hot) 백엔드는 로드 밸런서 편향을 시사함), 상태 코드별 분해.
- 프록시에서의 오류: 클라이언트(잘못된 엔드포인트를 호출하는 사용자)에서 발생하는 4xx, 백엔드(서비스 장애)에서 발생하는 5xx, 프록시 내부 오류(502 = 백엔드 접근 불가, 504 = 백엔드 타임아웃).
- 프록시에서의 포화(Saturation): TLS 세션 수, 업스트림 연결 풀 깊이, 프록시 자체의 CPU 사용률(TLS 종결은 CPU 부하가 큼).
Pro tip: 백엔드 지연 시간이 낮은 상태에서 502 오류가 갑자기 증가하면, 백엔드가 응답하기 전에 연결을 끊고 있음을 의미합니다(연결 리셋, 크래시, OOM). 504 오류가 증가하면 백엔드가 느리지만 여전히 응답하고 있음을 의미합니다. 오류 코드를 읽으세요. 실패가 어디에 있는지 알려줍니다.
시그널 읽기
대시보드에 지난 10분 동안의 다음 내용이 표시됩니다:
- 트래픽: 800 req/s로 대략 평탄함(급증 없음)
- 지연 시간: p50은 40ms로 안정적이며, p99는 5분 동안 200ms에서 2,500ms로 상승했으며 여전히 상승 중
- 오류: 4xx 비율은 0.3%로 안정적(정상 배경 수준); 5xx 비율은 0.1%에서 1.2%로 상승(대부분 504 Gateway Timeout)
- 포화 상태(Saturation): 같은 5분 동안 백엔드 CPU가 45%에서 78%로 상승; 프록시 CPU는 30%로 안정적
언제 스케일업할지, 언젠 드레인할지, 언제 페이지할지
용량 결정에는 트리거가 필요합니다
메트릭을 관찰하는 것은 쉽습니다. 언제 행동해야 하는지를 아는 것이야말로 진정한 규율입니다.
스케일업할 때: 포화도가 지속적인 임계값을 초과할 때(예: 백엔드 CPU가 5분 이상 70% 초과), 또는 큐 깊이가 목표치를 초과할 때, 또는 지연 시간 p99가 SLO를 초과할 때. 트리거는 시스템이 깨지기 전에, 깨지는 순간이 아니라 발동되어야 합니다.
리플리카를 드레인할 때: 다른 피어들은 정상적인데 해당 리플리카만 지속적으로 느리거나 에러가 발생할 때(하나의 리플리카만 과부하 상태인 것은 종종 애플리케이션 문제가 아닌 호스트 레벨의 문제입니다), 또는 새 버전을 롤아웃할 때, 또는 리플리카를 정상적으로 폐기할 때.
인간에게 페이지할 때: SLO가 에러 버짓으로 감당할 수 있는 속도보다 빠르게 소진되고 있을 때, 또는 포화도 트리거가 발동되었는데 오토스케일링이 이를 흡수하지 못할 때, 또는 캐스케이드 패턴이 나타날 때(에러율과 재시도율이 동시에 상승).
페이지하지 말아야 할 때: 단일 불량 분(1분)이 스스로 해결될 때, 또는 백그라운드 배치 작업이 예상되는 주기적인 변동(blip)을 일으킬 때, 또는 노이즈가 임계값을 초과할 때(이 경우 시스템이 잘못된 것이 아니라 임계값 설정이 잘못된 것입니다).
SLO 및 에러 버짓 소진
SLO(서비스 수준 목표)는 허용 가능한 성능을 정의합니다: '28일 기간 동안 성공률 >= 99.9%'. 그 보수(0.1%)가 에러 버짓입니다.
소진율(Burn rate): 에러 버짓을 소진하는 속도입니다. 1시간 동안 버짓의 10%를 소진한다면, 지속 가능한 속도보다 240배 더 빠른 것입니다(1시간은 28일 기간의 1/672이며, 그 기간 동안 10%를 소진하는 것은 전체 기간에 대해 10% × 672 = 6720%로 예측되는 것을 의미하며, 허용치는 100%뿐입니다).
다중 윈도우 소진율 알림: 짧은 윈도우(5분, 14.4x 속도)와 긴 윈도우(1시간, 6x 속도) 모두 지속 가능한 속도보다 빠르게 소진될 때 페이지(긴급 알림)를 트리거합니다. 이는 빠른 장애와 느린 성능 저하를 모두 포착합니다.
용량 관점에서 이것이 중요한 이유: 99.9% SLO로 실행되며 1%의 여유 공간이 있는 서비스는 경미한 장애를 흡수할 수 있습니다. 99.93%로 실행되는 서비스(간신히 SLO를 충족)는 나쁜 하루만 지나면 위반 상태가 됩니다. 용량 결정은 최소 충족치가 아닌, 여유로운 SLO 마진을 목표로 해야 합니다.
관찰 하의 용량 결정
귀하의 서비스에는 28일 동안 99.9%의 성공 요청 SLO가 있습니다. 지난 1시간 모니터링의 현재 상태:
- 성공률: 99.5% (30분간 지속)
- 백엔드 CPU: 전체 플릿 평균 82% (목표 70%)
- p99 지연 시간: 800 ms (SLO 목표: <500 ms)
- 트래픽: 초당 1,400회 요청, 기준선 1,000 req/s에서 증가 (정상 대비 40% 초과; 추세는 여전히 상승 중)
- 오토스케일링: CPU가 5분 이상 80%를 초과할 때 리플리카를 추가하도록 설정되어 있음; 현재 약 90초 후 3개의 리플리카가 추가될 스케일업 진행 중
발사 가시성 계획 설계하기
종합
이제 실제 실패를 포착하는 /health, 배포를 검증할 수 있는 /version, 프록시 계층의 4가지 골든 시그널 대시보드, 그리고 SLO 소진율에 연결된 용량 트리거를 설계할 수 있습니다.
네 가지 모두 적용하세요.
귀하의 팀은 search.example.com(실패 모드 레슨의 검색 서비스)을 출시하고 있습니다. 팀은 사용자가 문제를 인식하기 전에 문제를 포착하는 가시성을 출시하고, 명확한 페이지(경보) 또는 비페이지(경보 없음) 결정 매트릭스를 갖추기를 원합니다. SLO: 28일 윈도우에서 99.9%의 성공적인 요청, p99 레이턴시 < 300 ms.
코스 마무리
코스 마무리
5개 레슨을 모두 완료했습니다:
- 프록시 & 오리진: 거의 모든 공개 웹 서비스가 사용하는 엣지 계층 구조
- 무상태 수평 확장: 무상태 계층이 왜 저렴하게 복제되는지, 그리고 어떻게 크기 조절하는지
- 인그레스 & 에그레스 분리: 왜 하나의 박스가 두 개가 되는지, 그리고 이를 강제하는 장애 모드
- 장애 모드 & 영향 범위: 단일 장애점(SPOF), 연쇄 장애, 사후 분석(포스트모템), 무과실 조치 항목
- 관측 가능성 & 용량 (이 레슨): 사용자가 인지하기 전에 문제가 드러나도록 무엇을 측정해야 하는지
핵심 줄거리: 웹 스케일의 분산 시스템은 마법이 아닙니다. 이는 소수의 패턴(리버스 프록시, 무상태 레플리카, 인그레스/에그레스 분리, 벌크헤드 & 서킷 브레이커, 4대 골든 시그널)을 신중하게 조합한 것입니다. 패턴을 인식하게 되면 모든 프로덕션 아키텍처에서 그들을 볼 수 있습니다.
동반 레슨: 5개의 기하학-* 레슨은 동일한 내용을 그래프 이론과 기하학으로 재구성했습니다. 어떤 순서로 진행해도 좋습니다.
수고하셨습니다.