대용량 트래픽 장애는 CPU 하나가 아니라 queue, connection pool, DB lock, cache hot key, NAT/DNS/TLS, bandwidth, downstream quota가 같이 만든다.
평균 응답시간 대신 p95/p99, error rate, saturation, queue length, retry rate, pool pending, tail latency를 봐야 병목 위치가 보인다.
백엔드 개발자는 scale out 전에 공유 자원 한계와 backpressure를 계산하고, 장애 시 “어디서 줄을 서는가”를 metric과 trace로 설명할 수 있어야 한다.
핵심 정리
Capacity planning은 최대 RPS를 맞히는 일이 아니라 SLO를 지키는 traffic 범위와 여유 headroom을 아는 일이다.
병목은 CPU, memory, disk I/O, network, connection pool, thread pool, DB lock, cache, external API, LB/proxy 중 어디에 queue가 생기는지 찾는 작업이다.
부하 테스트는 RPS 숫자 놀이가 아니라 실제 traffic mix, payload, auth, cache hit ratio, think time, cold/warm 상태를 재현하는 실험이다.
Backpressure와 rate limit은 “사용자를 막는 기능”이 아니라 전체 장애를 막기 위해 감당 가능한 만큼만 받는 안전장치다.
희귀하지만 중요한 한계로는 ephemeral port exhaustion, NAT gateway port exhaustion, DNS resolver throttling, file descriptor limit, conntrack table full, TLS handshake spike, SYN backlog overflow가 있다.
헷갈리는 지점
CPU가 낮으면 병목이 없다고 생각하기 쉽다.
핵심 판단 포인트는 CPU가 낮아도 DB pool pending, lock wait, network egress, external API quota, queue가 포화될 수 있다는 것이다.
scale out이 항상 처리량을 늘린다고 생각하기 쉽다.
핵심 판단 포인트는 app instance를 늘리면 DB connection, cache, NAT, DNS, downstream API 같은 공유 자원 부하도 같이 늘어난다는 것이다.
부하 테스트에서 평균 latency만 보면 충분하다고 생각하기 쉽다.
핵심 판단 포인트는 사용자는 p95/p99 tail latency와 timeout/retry를 경험하고, tail이 길어질수록 자원 점유가 더 늘어난다는 것이다.
rate limit은 나쁜 사용자만 막는 기능이라고 생각하기 쉽다.
핵심 판단 포인트는 정상 traffic burst도 시스템 한계를 넘을 수 있으므로 tenant/user/route별 보호 정책이 필요하다는 것이다.
확인 질문
p99 latency가 capacity planning에서 중요한 이유는 무엇인가?
일부 느린 요청이 사용자 경험을 망치고 connection/thread/pool을 오래 점유해 전체 처리량을 떨어뜨리기 때문이다.
scale out 후에도 장애가 나는 대표 이유는 무엇인가?
DB, cache, external API, NAT gateway, DNS resolver 같은 공유 자원의 한계가 그대로이거나 더 빨리 찰 수 있기 때문이다.
backpressure의 목적은 무엇인가?
시스템이 감당할 수 없는 요청을 일찍 제한해 queue 폭증과 cascading failure를 막는 것이다.
“네트워크 병목”이라고 말하기 전에 확인해야 할 최소 증거는 무엇인가?
DNS/TCP/TLS/HTTP timing, LB/proxy status, app trace, pool pending, OS socket 상태, downstream latency를 함께 확인해야 한다.