Capacity & Resource Engineering

1. Overview

용량 계획과 리소스 엔지니어링(Capacity & Resource Engineering)은 블랙프라이데이나 월드컵 결승전처럼 수백 배의 트래픽 쓰나미가 예고된 날, 서버가 불타기 전에 "얼마나 많은 서버가 더 필요한가?"를 수학적으로 예측하고 선제적으로 자원을 깔아두는 인프라 방어의 최전선을 해부합니다.

학습자는 단순히 "서버 좀 늘려"라는 감(Guess)에 의존하는 낡은 관행을 버리고, 리틀의 법칙(Little's Law)과 부하 테스트를 통해 **현재 인프라의 물리적 한계점(Saturation Point)**을 숫자로 도출하는 기법을 뜯어봅니다. 나아가 이벤트 시작 5분 전 트래픽 폭증을 방어하기 위한 **오토스케일링(Auto-scaling)의 한계(콜드 스타트)**를 깨닫고, 시간 기반의 스케줄드 스케일링(Scheduled Scaling)과 웜 풀(Warm Pool)로 타협하는 법을 배웁니다. 마지막으로, 자원이 바닥났을 때 VIP 유저만 살리고 무임승차자는 쳐내는 트래픽 셰딩(Traffic Shedding)과 쿼터(Quota) 관리라는 비정하지만 완벽한 리소스 통제 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Capacity Planning (용량 계획): 트래픽 성장률 예측, 한계 돌파점(Ceiling) 계산, Little's Law.
• Load Testing (부하 테스트): Stress Test, Soak Test, Spike Test, 병목(Bottleneck) 식별.
• Scaling Mechanisms: Auto-scaling (Metrics-based), Scheduled Scaling, Cold Start 대처.
• Resource Protection: Quota(할당량), Rate Limiting(속도 제한), Traffic Shedding(트래픽 버리기).

Out-of-Scope

• Auto-scaling 툴(K8s HPA) 설정법: 쿠버네티스의 CPU 메트릭 연동 구현 → 09-02 CI/CD & DevOps 영역.
• 비용 최적화(FinOps): 클라우드 RI/Spot Instance 할인 구매 → 클라우드 매뉴얼 영역으로 위임.

Boundaries

• Auto-scaling vs Capacity Planning: 오토스케일링은 "CPU가 80%가 넘으면 3분 뒤에 서버 1대 추가해 줘"라는 훌륭한 자동화 도구입니다. 하지만 블랙프라이데이 정각 00시 00분에 트래픽이 100배로 폭주할 때, 오토스케일링이 3분 동안 서버를 켜는(Cold Start) 사이에 기존 서버들은 모조리 터져나갑니다. 오토스케일링을 맹신하여 사전에 최대 용량을 수동으로 깔아두는 '용량 계획(Capacity Planning)'을 게을리하는 것은 대규모 라이브 서비스에서 파산을 부르는 최악의 안티 패턴임을 명확히 경계 짓습니다.

3. Counterexample

• 선형 확장의 맹신: "서버 1대가 1,000 TPS를 버티니까, 10대면 10,000 TPS를 버티겠지!"라고 계산하고 이벤트를 열었습니다. 그러나 5,000 TPS 부근에서 10대의 서버가 똑같은 DB 인덱스 업데이트(Write)를 하려다 락(Lock) 경합이 터지며 전체 시스템이 멈췄습니다. 수평 스케일아웃(Horizontal Scaling)이 영원히 선형적으로 증가할 것이라 착각하고, DB Connection Pool이나 Lock 병목을 사전에 부하 테스트(Stress Test)로 뚫어보지 않은 치명적 용량 계획 실패입니다.
• 무자비한 타임아웃 재시도 (Retry Storm): 시스템 용량이 $100\%$ 에 달해 서버가 응답을 2초간 늦게 줍니다. 클라이언트(앱)는 1초 만에 타임아웃(Timeout)을 띄우고 즉시 "재시도(Retry)"를 날립니다. 유저 1만 명이 재시도를 연타하자, 서버에는 2만 개, 4만 개의 중복 트래픽 폭풍(Retry Storm)이 쏟아져 들어오며 숨통을 끊어놓습니다. 용량이 한계에 달했을 때 클라이언트의 백오프(Exponential Backoff)나 서버의 트래픽 버리기(Shedding)를 셋업하지 않아 스스로 DDoS를 유발한 인프라 자살골입니다.

4. Prerequisites

• 수평 스케일링 원리 (Basic): Stateless 서버 확장의 기본기. (07-03-01 Vertical vs Horizontal)
• 큐잉 이론 (Basic): 대기열과 지연 시간. (07-04-01 Message Brokers)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 용량의 물리학, 리틀의 법칙 (The Math of Capacity)

• Why to Learn: "서버 1대가 1초에 몇 명을 감당할 수 있나요?"라는 기획자의 질문에, 엔지니어의 '감'이 아닌 수학적 공식으로 명확한 한계점(Ceiling)을 도출하기 위함입니다.
• What to Learn:
  • Concepts: Capacity Planning, Little's Law ($L = \lambda W$), Throughput (처리량 - TPS), Latency (지연 시간), Concurrency (동시성).
  • Skills: 평균 응답 시간과 목표 동시 접속자를 기반으로 필요 서버 대수(Capacity) 산출.
• How to Learn:
  • 1단계: 리틀의 법칙: 식당(서버)에 손님이 1초에 10명 들어옵니다($\lambda$, Throughput). 손님 1명이 밥 먹고 나가는 데 2초가 걸립니다($W$, Latency). 그렇다면 이 식당 안에는 항상 평균적으로 20명($L$, Concurrency)의 손님이 들어차 있게 된다는 큐잉 이론의 진리를 해부합니다.
  • 2단계: 용량 한계의 계산: 톰캣(Tomcat) 스레드가 딱 200개입니다(최대 $L=200$). API 하나 처리하는 데 평균 0.5초($W$)가 걸립니다. 그럼 이 서버가 감당할 수 있는 최대 TPS($\lambda$)는? $200 = \lambda \times 0.5$, 즉 $\lambda = 400$ TPS입니다. 401 TPS부터는 스레드 고갈로 병목이 시작됨을 뜯어봅니다.
• Implement: 리틀의 법칙 계산기 (CLI). Latency(ms)와 Max Threads를 입력받아, 서버 1대당 낼 수 있는 Max TPS를 계산해 주고, 기획자가 요구하는 Target TPS를 입력하면 필요한 서버 대수를 반올림하여 견적을 내주는 파이썬 스크립트.

Recommended

Core Topic 02: 한계 돌파점 찾기, 부하 테스트 (Stress & Soak Testing)

• Why to Learn: 수학적 계산(리틀의 법칙)은 완벽한 환경을 가정합니다. 실제로는 숨겨진 락(Lock)이나 메모리 누수로 인해 예상보다 훨씬 일찍 서버가 터지는 임계점(Breaking Point)을 오픈 전에 미리 부숴보기 위함입니다.
• What to Learn:
  • Concepts: Load Testing (일반 부하), Stress Testing (파괴 테스트), Soak Testing (장기 누수 테스트), Spike Testing (순간 폭주), Bottleneck.
  • Skills: k6, JMeter 등의 도구를 활용한 파괴 점 식별 및 병목 추적.
• How to Learn:
  • 1단계: 스트레스 테스트(파괴): "어디까지 버티나 보자." 100 TPS부터 시작해서 서버가 500 에러를 뿜거나 응답이 10초가 넘어갈 때까지 부하를 계속 올립니다. 터진 순간 대시보드를 봅니다. CPU가 $100\%$ 인가? DB 커넥션이 마른 것인가? 병목의 진짜 원인을 색출하는 법을 해부합니다.
  • 2단계: 소크 테스트(누수): 500 TPS는 가뿐히 버팁니다. 그런데 그 500 TPS를 '48시간 동안' 멈추지 않고 쏴봅니다. 첫날엔 멀쩡하던 서버가 이틀째에 OOM(메모리 부족)으로 서서히 죽습니다. 가비지 컬렉터(GC)가 미처 지우지 못한 미세한 메모리 누수(Memory Leak)를 잡아내는 장기 고문 기법을 뜯어봅니다.
• Implement: 파이썬 asyncio 미니 스트레스 테스터. 타겟 로컬 서버로 비동기 HTTP 요청을 발사. 1초마다 $TPS$ 를 $10 \rightarrow 20 \rightarrow 30$ 으로 계단식으로 올리며(Ramp-up), 타겟 서버가 Timeout 혹은 HTTP 500을 최초로 뱉는 순간의 TPS(Breaking Point)를 [CRASH DETECTED]로 로깅하는 시뮬레이션.

Practical

Core Topic 03: 너무 늦은 지원군, 콜드 스타트의 딜레마 (The Cold Start Dilemma)

• Why to Learn: 오토스케일링(ASG)을 맹신하여 트래픽 스파이크(이벤트 오픈) 시 서버가 늘어나기도 전에 서비스가 전멸해 버리는 끔찍한 타임래그(Time Lag)를 방어하기 위함입니다.
• What to Learn:
  • Concepts: Auto-scaling Group (ASG), Cold Start (부팅 지연), Scheduled Scaling (스케줄링 확장), Warm Pool (사전 대기풀), Golden Image (AMI).
  • Skills: 예측 불가능한 스파이크 트래픽(Metric 기반)과 예측 가능한 스파이크 트래픽(이벤트 기반)의 스케일링 전략 분리.
• How to Learn:
  • 1단계: 지원군의 지각: CPU $80\%$ 도달 시 서버 1대를 추가하라고 설정했습니다. 낮 12시 00분 타임세일 시작. 1초 만에 CPU가 $100\%$ 를 칩니다. 새 인스턴스가 할당되고(OS 부팅), Java Spring이 올라오고(무거운 프레임워크), 로드밸런서 헬스체크를 통과하는 데 3분이 걸렸습니다. 그 3분 동안 기존 서버는 모두 타버린(Cascading Failure) 참사를 해부합니다.
  • 2단계: Warm Pool과 타임머신: 타임세일처럼 "미리 알고 있는" 트래픽은 CPU 기반 오토스케일링을 쓰면 안 됩니다. 11시 50분에 무조건 서버 50대를 강제로 띄워놓는(Scheduled Scaling) 전략과, OS와 런타임이 미리 캐싱된 황금 이미지(Golden AMI)로 콜드 스타트를 3분에서 10초로 압축하는 인프라 튜닝을 뜯어봅니다.
• Implement: ASG 랙(Lag) 시뮬레이션. 서버 2대로 시작(Max 용량 200). 초당 트래픽이 10 -> 300으로 1초 만에 폭증(Spike). ASG 룰이 동작하여 서버를 늘리기 위해 sleep(5)를 호출하는 동안, 초과된 트래픽 100(300-200) 개가 매초 에러(Dropped)로 유실되는 끔찍한 타임래그 로깅.

Advanced

Core Topic 04: 구명보트의 냉혹함, 트래픽 셰딩과 쿼터 (Traffic Shedding & Quota)

• Why to Learn: 서버 10대로 감당할 수 있는 트래픽은 1만 명인데 2만 명이 밀려왔을 때, 2만 명 모두에게 렉(Lag)을 걸어 다 같이 죽는 대신, 절반을 냉혹하게 쳐내어(Shedding) 남은 만 명이라도 쾌적하게 살려내는 생존 본능을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Traffic Shedding (트래픽 버리기), Rate Limiting (속도 제한), Quota (할당량), Graceful Degradation (우아한 기능 저하).
  • Skills: 중요도가 낮은 API(예: 추천 상품 조회)부터 503 에러로 차단하고 결제 트래픽을 보호하는 API 우선순위 라우팅.
• How to Learn:
  • 1단계: 트래픽 셰딩(다 버려!): 타이타닉호의 구명보트 자리는 1,000개입니다. 2,000명을 우겨넣으면 구명보트가 가라앉아 전원 사망합니다. 로드 밸런서 단에서 1,000명이 넘어가면 1,001번째 요청부터는 백엔드 서버로 넘기지조차 않고 로드밸런서가 즉각 HTTP 503 Service Unavailable로 튕겨버려(Shedding) 백엔드의 숨통을 지키는 역학을 해부합니다.
  • 2단계: 우아한 쇠퇴(Graceful Degradation): DB가 너무 버겁습니다. 홈 화면에 접속한 유저에게 '개인화 추천 상품'을 보여주려면 복잡한 쿼리가 돕니다. 시스템이 벅찰 때는 과감하게 추천 상품 쿼리를 차단(Shedding)하고 '빈 화면' 혹은 '캐시된 기본 상품'을 보여줍니다. 결제나 로그인 같은 코어(Core) 기능은 살려두면서 부가 기능을 잘라내는 고도의 생존 전략을 뜯어봅니다.
• Implement: 우선순위 트래픽 셰딩 로직. 서버 가용 큐 크기 10. req_A(우선순위 High - 결제), req_B(우선순위 Low - 썸네일 로드). 큐가 8(80%) 차오르면 req_B가 들어올 때 큐에 넣지 않고 즉시 [Dropped] 시켜버려, 이후 들어오는 req_A를 위한 공간(여유분 20%)을 방어해 내는 큐 관리 스크립트.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Performance Engineering (Capacity Planning)
• [P5] SFIA - Capacity Management (CPMG) - Capacity Forecasting and Sizing

Secondary

• [Site Reliability Engineering: How Google Runs Production Systems] - Load Balancing in the Datacenter and Managing Load
• [The Art of Capacity Planning] John Allspaw - Scaling Web Resources

Industry

• [AWS Architecture Blog] - Using Amazon EC2 Auto Scaling Warm Pools
• [Stripe Engineering Blog] - Rate limiters and shedding load

9. Final Checklist

Primary

• 톰캣(Tomcat) 스레드가 200개이고 평균 API 응답 시간이 1초일 때, 리틀의 법칙(Little's Law)에 따라 이 서버가 낼 수 있는 최대 처리량(TPS)이 200임을 수학적으로 증명할 수 있는가?
• 트래픽이 선형적으로 늘어날 때, 부하 테스트(Stress Test)를 통해 DB 커넥션 풀 고갈이나 CPU $100\%$ 임계점 등 아키텍처의 특정 병목(Bottleneck)이 시스템 전체를 붕괴시키는 한계점을 식별할 수 있는가?

Secondary

• 블랙프라이데이 타임세일처럼 정각 00시에 트래픽이 100배 폭증하는 상황에서, CPU 기반 오토스케일링(ASG)을 걸어두는 것이 왜 콜드 스타트(Cold Start) 지연으로 인해 재앙으로 끝나는지 해부할 수 있는가?
• 예측 불가능한 트래픽 스파이크를 방어하기 위해 '항상 $30\%$ 의 잉여 리소스를 켜두는(Over-provisioning)' 비용과, 장애(Downtime) 시 발생하는 비즈니스 손실(에러 버젯)을 어떻게 경제적으로 저울질할지 논증할 수 있는가?

Industry

• 트래픽 셰딩(Traffic Shedding)을 구현할 때, 신규 유저의 '추천 페이지 조회(Low Priority)' 요청은 503 에러로 날려버리고 기존 유저의 '장바구니 결제(High Priority)' 요청은 끝까지 살려내는 L7 로드밸런서 티어링(Tiering)을 설계할 수 있는가?
• 과부하 시 클라이언트(모바일 앱)가 1초 만에 타임아웃을 띄우고 즉각 재시도(Retry)를 때리는 로직이 서버에 미치는 끔찍한 재시도 폭풍(Retry Storm)을 차단하기 위해, 지수 백오프(Exponential Backoff)와 Jitter(랜덤 지연)를 어떻게 클라이언트에 강제할지 평가할 수 있는가?