용량의 본질

DDoS 공격자가 아니라 자기 고객이 자기 시스템을 죽일 수 있다면? 용량을 제대로 이해하지 못하면 이런 일이 실제로 벌어져.

어느 전자상거래 회사의 블랙프라이데이 이야기야. 수개월 준비하고, 서버 증설하고, 로드 테스트도 돌리고, 팀 전원 대기 상태로 출근했는데 — 막상 당일에 시스템이 무너졌어. 트래픽이 예상의 3~5배를 넘겼거든. 로드 테스트에서는 "상품 보기, 장바구니, 결제" 순서를 가정했는데, 실제로는 수만 명이 같은 특가 상품 페이지에 몰려서 새로고침을 미친 듯이 눌렀어. 리로드 버튼이 서버를 공격하는 무기가 된 거야. 마케팅팀이 한정 수량 특가를 이메일, 전단지, TV 광고로 대대적으로 홍보했으니까. 이전 장에서 배운 Self-Denial Attack의 완벽한 사례지.

근데 트래픽 폭증보다 더 치명적이었던 건 세션 관리였어. 사용자마다 서버 측 세션을 만들었는데, 장바구니, 최근 본 상품, 개인화 데이터까지 넣으니 세션 하나가 500KB~1MB. 정상 때 5만 명 예상이었는데 50만 명이 몰리면? 50만 x 1MB = 500GB 세션 데이터. 서버 힙이 감당할 수 없으니 GC가 미쳐 돌아가기 시작하고, Full GC가 수 초씩 걸리면서 Stop-the-World 일시정지가 발생해. GC가 돌아도 세션이 살아있으니 회수할 게 없고, 결국 OutOfMemoryError로 JVM이 죽어. 한 대 죽으면 나머지로 몰리면서 — Chain Reaction — 순차적으로 쓰러졌지.

이 사례의 핵심 교훈은 용량 계획이 기술적 문제이자 조직적 문제라는 거야. 마케팅팀과 소통하지 않으면 트래픽 폭탄을 맞고, 로드 테스트 시나리오가 현실과 다르면 테스트 자체가 무의미해. 세션은 가볍고 짧게 유지하고, 가능하면 클라이언트 측으로 옮기고, 용량 초과 시엔 **부하 차단(load shedding)**으로 새 사용자를 대기 페이지로 돌려야 해.

그런데 이런 사고를 예방하려면 먼저 용량이 뭔지 정확히 알아야 해. 사람들이 성능(Performance), 처리량(Throughput), **용량(Capacity)**을 혼동하는데 이 셋은 완전히 다른 거야. 성능은 단일 요청의 응답 시간이고, 처리량은 초당 처리 건수이고, 용량은 허용 가능한 성능 수준을 유지하면서 감당할 수 있는 최대 부하야. 성능을 개선하면 처리량이 올라가고 용량이 늘어나지만, 이게 선형적이지 않아. 병목이 어디냐에 따라 하나를 개선해도 전체가 안 좋아질 수 있거든 — **암달의 법칙(Amdahl's Law)**이랑 같은 원리지. 그리고 부하가 올라가면 성능이 떨어져. 사용자 1명일 때 100ms이던 게 5000명이면 2초가 돼. 리소스 경합, 큐잉 지연, GC 압박 때문이야.

이걸 제대로 다루려면 **부하 모델(Load Model)**이 필요해. 동시 사용자 수, 요청 패턴, 데이터 크기, 시간대별 패턴 — 이런 걸 기술한 모델 없이 "서버 10대면 될 것 같은데?" 하는 건 계획이 아니라 도박이야. 성능을 측정할 때도 함정이 많아. 평균 응답 시간 100ms라는 건, 50%가 10ms이고 나머지 50%가 190ms일 수도 있거든. 백분위수(percentile) — 특히 P99 — 를 봐야 실제 사용자 경험에 가까워. 그래프 시간축을 5분 간격으로 평균내면 1초짜리 스파이크가 묻혀버리고, 개발 환경 측정은 프로덕션에만 존재하는 요소들이 빠져있으니 거의 의미가 없어.

부하 테스트에서 진짜 해야 할 건 "잘 돌아가는지 확인"이 아니라 **"어디서 깨지는지 확인"**이야. 트래픽을 점점 올려서 응답 시간이 급격히 나빠지는 지점, 에러가 나기 시작하는 지점 — 이 **브레이킹 포인트(breaking point)**를 알아야 "우리 시스템은 동시 접속 3만 명까지 SLA를 만족한다"고 말할 수 있고, 3만 명을 넘었을 때 부하 차단이나 서버 증설 같은 대응을 할 수 있어.

---

정리

3장 읽고 기억할 거 세 가지:

1. 자기 고객이 자기 시스템을 죽일 수 있어 — 마케팅 캠페인이 DDoS와 같은 효과를 내니까, 용량 계획은 기술이자 조직의 문제야.
2. 평균이 아닌 백분위수(P95, P99)를 봐 — 평균 응답 시간은 실제 사용자 경험을 숨기고, 현실적인 부하 모델 없는 테스트는 도박이야.
3. 시스템의 브레이킹 포인트를 알아야 해 — "어디서 깨지는가"를 모르면, 깨졌을 때 대응할 수 없어.