장애 대응은 root cause를 빨리 맞히는 일이 아니라 요청이 어느 계층까지 도달했고 누가 응답을 만들었는지 증거로 좁히는 과정이다.
status code, response header, curl timing, request id, 마지막 로그 위치, 영향 범위, 최근 변경을 먼저 모아야 팀 간 추측을 줄일 수 있다.
기존 502와 HTTP 에러코드 진단 흐름은 상태코드별 병목, 요청 유형별 판단, 실제 502 보고 runbook으로 통합한다.
핵심 정리
계층별 진단은 DNS, TCP, TLS, HTTP, CDN/WAF, LB/Gateway, Proxy, App, DB/API로 나눈다. 한 계층이 정상이라고 다음 계층도 정상이라고 볼 수 없다.
지연 장애는 평균 latency보다 p95/p99, queue, pool pending, first byte, upstream response time을 봐야 한다. timeout이 난 뒤에도 app이나 DB 작업이 계속되는지 확인해야 한다.
status code는 원인이 아니라 다음 확인 위치를 고르는 라우팅 정보다. 403은 WAF와 app authz를 나누고, 502/503/504는 gateway/proxy/backend/timeouts를 나누어 본다.
요청 유형에 따라 네트워크 판단이 달라진다. 조회는 cache와 latency, 결제/주문은 idempotency와 중복 방지, 업로드는 body size와 streaming, WebSocket/SSE는 idle timeout과 heartbeat가 핵심이다.
502는 cloud provider 장애라고 단정하지 않는다. public DNS/TCP/TLS가 정상이어도 gateway to backend의 health probe, port/protocol, Host header, backend TLS, firewall이 실패할 수 있다.
좋은 장애 보고는 확인한 정상 계층, 마지막으로 관찰된 계층, 아직 내부 권한이 필요한 확인 항목을 분리한다.
헷갈리는 지점
App log에 요청이 없으면 백엔드 문제가 아니라고 생각하기 쉽다. 요청이 CDN/WAF/LB/proxy에서 끝났거나 app에 도달하지 못했을 수 있기 때문이다.
핵심 판단 포인트는 CDN, LB, proxy, app log에서 같은 request id가 어느 계층까지 남았는지 확인하는 것이다.
평균 latency가 낮으면 장애가 없다고 믿기 쉽다. 실제 사용자는 p99, 특정 endpoint, 특정 region, 특정 dependency의 느린 요청을 경험하기 때문이다.
핵심 판단 포인트는 p95/p99, pool pending, worker busy, DB/API span, GC, retry count를 같은 시간대에 보는 것이다.
502, 503, 504를 모두 같은 서버 장애로 묶기 쉽다. 실제로는 upstream 유효 응답 실패, no healthy target/overload, upstream timeout처럼 확인 위치가 다르기 때문이다.
핵심 판단 포인트는 즉시 실패인지 timeout 뒤 실패인지, gateway status와 target status가 무엇인지 보는 것이다.
요청 유형을 무시하고 같은 retry/timeout/cache 정책을 복사하기 쉽다. 같은 POST라도 결제, 검색, 업로드, 긴 작업은 위험이 다르기 때문이다.
핵심 판단 포인트는 side effect, idempotency, body size, expected duration, browser/mobile/server-to-server 여부를 먼저 표시하는 것이다.
확인 질문
장애 초기에 가장 먼저 모을 정보는 무엇인가?
발생 시각, 영향 범위, URL, method, status, response header, request id, curl timing, 마지막 로그 위치, 최근 변경이다.
time_starttransfer가 길면 무엇을 의심하는가?
서버가 요청을 받은 뒤 첫 바이트를 내기까지 오래 걸린 것이므로 app 처리, DB, 외부 API, lock, pool 대기를 의심한다.
502와 504의 핵심 차이는 무엇인가?
502는 gateway가 upstream에서 유효한 응답을 못 받은 상황에 가깝고, 504는 upstream 응답을 기다리다 timeout이 난 상황에 가깝다.
결제 요청과 조회 요청의 retry 정책이 달라야 하는 이유는 무엇인가?
결제는 중복 side effect가 치명적이므로 idempotency와 상태 저장 없이 retry하면 안 되고, 조회는 상대적으로 retry 위험이 낮기 때문이다.
좋은 502 보고에는 무엇이 포함되어야 하는가?
DNS/TCP/TLS/HTTP 확인 결과, Server header, curl timing, app log 도달 여부, backend health/probe/port/protocol/Host header/backend TLS 확인 요청이 포함되어야 한다.