이벤트 당일 서버 다운을 막는 Peak TPS 기반 서버 수량 및 대역폭 계산법

Photo by panumas nikhomkhai on Pexels

신규 서비스 오픈이나 대규모 마케팅 이벤트를 앞두고 상급자로부터 "이번 이벤트 때 서버 몇 대나 띄워야 해?"라는 질문을 받으면 막막해지는 경우가 많습니다. 이제 막 서비스를 담당하게 된 신입 개발자나 실무자라면 대개 감에 의존하여 "넉넉하게 5대 정도 띄우면 되지 않을까요?"라고 답했다가, 이벤트 당일 트래픽 폭주로 서버가 먹통이 되는 아찔한 사고를 겪기도 합니다.

인프라를 무작정 증설하는 것은 과도한 클라우드 비용 지출로 이어지고, 반대로 너무 적게 준비하면 서비스 장애로 이어집니다. 따라서 논리적인 근거와 구체적인 수식을 바탕으로 필요한 서버 수량과 네트워크 대역폭을 산정하는 능력이 필수적입니다. 이 글에서는 신입 실무자가 바로 활용할 수 있도록, 서비스 예상 사용자 수(DAU)로부터 Peak TPS를 도출하고 필요한 API 서버 수량과 네트워크 대역폭까지 직접 계산하는 과정을 단계별 수치 예시와 함께 설명합니다.

1. 용량 산정의 출발점: DAU에서 Peak TPS 도출하기

용량 산정(Capacity Planning)의 첫 번째 단계는 서비스의 비즈니스 지표를 시스템이 처리해야 하는 초당 트래픽 단위인 TPS(Transactions Per Second)로 변환하는 것입니다. 기획팀이나 마케팅팀에서 제공하는 수치는 보통 일간 활성 사용자 수(DAU)나 이벤트 참여 예상 인원입니다. 이 단시각 지표를 초당 요청 수로 계산해내야 합니다.

계산을 위해 가장 먼저 정의해야 하는 4가지 변수가 있습니다.

• DAU (Daily Active Users): 하루 동안 서비스를 이용하는 총 유니크 사용자 수입니다.
• 1인당 평균 요청 수 (N): 한 사용자가 서비스에 접속해서 해당 API를 호출하는 평균 횟수입니다.
• 피크 시간대 집중률 (Concentration Rate): 하루 전체 트래픽 중 가장 사람이 몰리는 시간대에 발생하는 트래픽의 비율입니다.
• 피크 지속 시간 (Peak Hours): 가장 트래픽이 집중되는 시간의 길이입니다.

구체적인 숫자 예시 상황

가상 회사 A사에서 진행하는 '선착순 할인 쿠폰 발급 이벤트'의 예시를 들어보겠습니다. 기획서에 명시된 조건은 다음과 같습니다.

• 예상 이벤트 당일 DAU: 600,000명
• 사용자 1인당 쿠폰 조회 및 응답 API 호출 횟수: 5회
• 트래픽 집중 조건: 전체 하루 트래픽의 50%가 점심시간인 12:00 ~ 13:00 (1시간) 사이에 집중됨

Peak TPS 계산 과정

1단계: 하루 동안 발생하는 총 API 요청 수 계산

총 요청 수 = DAU x 1인당 평균 요청 수

총 요청 수 = 600,000명 x 5회 = 3,000,000회 (300만 건)

2단계: 피크 시간대(1시간) 동안 발생하는 요청 수 계산

피크 시간 요청 수 = 총 요청 수 x 피크 시간대 집중률

피크 시간 요청 수 = 3,000,000회 x 0.5 (50%) = 1,500,000회 (150만 건)

3단계: 피크 시간대의 평균 초당 처리량(Average Peak TPS) 계산

1시간은 3,600초(60분 x 60초)이므로, 1,500,000회를 3,600초로 나누어 줍니다.

평균 피크 TPS = 1,500,000회 / 3,600초 = 416.67 TPS

4단계: 순간 순간의 트래픽 변동성을 고려한 Peak Factor 반영

1시간 내에서도 특정 1~2분 사이에 트래픽이 더 급증할 수 있습니다. 이를 보정하기 위해 피크 계수(Peak Factor, 보통 2.0 ~ 3.0 적용)를 곱해 최종 Peak TPS를 산정합니다. 본 예시에서는 보수적으로 Peak Factor 2.5를 적용하겠습니다.

최종 Target Peak TPS = 416.67 TPS x 2.5 = 1,041.67 TPS (약 1,050 TPS)

2. 단일 API 서버(Pod)의 처리 가능 TPS 측정법

목표로 하는 Target Peak TPS(1,050 TPS)를 구했다면, 이제 우리가 띄울 API 서버 1대가 초당 몇 건의 요청을 안전하게 처리할 수 있는지 알아내야 합니다. 단일 서버의 성능은 코딩 방식, DB 쿼리 효율성, 메모리 및 CPU 스펙에 따라 완전히 달라집니다.

단일 서버 성능 측정을 위해서는 n6, k6, Apache JMeter와 같은 부하 테스트 도구를 사용하여 격리된 환경(Staging)에서 부하 테스트를 수행해야 합니다. 부하 테스트 시 반드시 확인해야 하는 핵심 지표는 다음과 같습니다.

• RPS/TPS: 서버가 오류 없이 처리하는 초당 요청 수
• Latency (응답 시간): Average Latency 및 p95, p99 Latency (상위 95%, 99% 사용자의 응답 시간)
• CPU 및 Memory Usage: 서버의 자원 사용률
• Error Rate: HTTP 5xx 에러나 Timeout 발생 비율 (0% 유지 필수)

안전 기준선(Target Utilization) 설정의 중요성

부하 테스트 결과, CPU 사용률 100% 한계 시점에서 단일 Pod(예: 2 vCPU, 4GB RAM)가 300 TPS를 처리했다고 해서 "이 서버의 용량은 300 TPS다"라고 결론을 내리면 안 됩니다. CPU 사용률이 80%를 넘어가면 Thread Context Switching 비용이 증가하고, GC(Garbage Collection) 지연이 발생하면서 응답 시간이 급격히 늘어납니다.

실무에서는 시스템 안정성을 위해 단일 서버 목표 CPU 사용률을 60% ~ 70% 수준으로 제한하고, 그 시점의 TPS를 단일 서버의 '임계 TPS(Target Capacity TPS)'로 잡습니다.

부하 테스트 결과 예시를 바탕으로 한 성능 데이터 표는 다음과 같습니다.

위 테스트 결과표에 따라, 해당 API 서버(2 vCPU, 4GB Memory) 1대의 안전한 권장 처리 용량은 180 TPS로 결정할 수 있습니다.

3. 필요 API 서버 수량 산정 공식과 실무 계산

목표 시스템의 전체 Target Peak TPS와 단일 서버가 처리할 수 있는 권장 TPS를 확보했으므로, 이제 인프라 배치를 위한 산정 공식을 적용할 수 있습니다.

서버 수량 산정 공식

필요 서버 수 = (Target Peak TPS x 여유 계수) / 단일 서버 권장 TPS

여기서 여유 계수(Safety Margin Factor)는 갑작스러운 트래픽 튐, 특정 Pod 장애로 인한 리로드, 배포 중 인스턴스 감소 등을 대비하기 위한 안전장치입니다. 일반적인 실무 환경에서는 1.2 ~ 1.5 (20% ~ 50% 여유)를 적용합니다.

A사 예시 데이터를 활용한 수치 계산

• Target Peak TPS: 1,050 TPS
• 단일 서버 권장 TPS: 180 TPS
• 안전 여유 계수: 1.3 (30% 여유)

계산식에 수치를 대입해 보겠습니다.

필요 TPS = 1,050 TPS x 1.3 = 1,365 TPS

필요 서버 수 = 1,365 TPS / 180 TPS = 7.58대

소수점 이하 수치는 무조건 올림 처리해야 하므로, 피크 타임에 필요한 최적 API 서버 수량은 8대가 됩니다.

Kubernetes HPA (Horizontal Pod Autoscaler) 설정값 도출

쿠버네티스 환경이나 AWS Auto Scaling Group을 운용하는 경우, 계산된 수치를 통해 최소/최대 인스턴스 수치를 정확하게 설정할 수 있습니다.

• Min Replicas (평시 최소 개수): 평상시 TPS가 피크의 10% 수준인 105 TPS라면, 105 / 180 = 0.58대입니다. 고가용성(HA, Multi-AZ)을 위해 최소 2대로 설정합니다.
• Max Replicas (피크시 최대 개수): 위에서 계산한 8대에 추가 예비분 20%를 더해 10대로 설정합니다.
• Target CPU Metrics: 부하 테스트 시 기준이 되었던 65%로 Auto Scaling 스케일 아웃 임계값을 지정합니다.

4. 네트워크 대역폭 및 트래픽 비용 사전 산정법

서버 수량만 충분히 확보했다고 해서 끝이 아닙니다. 서버 단의 컴퓨팅 자원(CPU, RAM)이 넉넉하더라도, 클라우드 인프라의 네트워크 NIC 한계나 대역폭(Bandwidth) 제한에 걸리면 패킷 드랍이 발생하여 사용자는 '접속 불가' 오류를 겪게 됩니다. 따라서 네트워크 아웃바운드 대역폭 산정이 반드시 병행되어야 합니다.

네트워크 대역폭을 산정하려면 API 1회 호출 시 오가는 데이터의 크기, 그중에서도 주로 서버에서 클라이언트로 나가는 **응답 페이로드(Response Payload) 크기**를 측정해야 합니다.

응답 데이터 크기 측정

개발자 도구(Network 탭)나 curl 명령어를 통해 쿠폰 발급 조회 API의 응답 헤더와 본문(JSON) 크기를 합산합니다.

• HTTP Response Header 평균 크기: 약 1 KB
• HTTP Response Body (JSON) 평균 크기: 약 24 KB
• 요청 1건당 총 데이터 크기 (Data Size): 25 KB

대역폭(Bandwidth) 산정 공식

네트워크 속도는 보통 bps(bit per second) 단위를 사용하므로, Byte 단위를 bit 단위로 변환(1 Byte = 8 bit)해야 합니다.

필요 대역폭(Mbps) = (Target Peak TPS x 요청당 데이터 크기(KB) x 8 bit) / 1,024

A사 예시 데이터를 활용한 네트워크 계산

• Target Peak TPS (여유율 반영): 1,365 TPS
• 요청당 평균 데이터 크기: 25 KB

계산 과정:

초당 전송 데이터(KB/s) = 1,365 TPS x 25 KB = 34,125 KB/s

초당 전송 데이터(MB/s) = 34,125 KB/s / 1,024 = 33.325 MB/s

필요 대역폭(Mbps) = 33.325 MB/s x 8 bit = 266.60 Mbps

즉, 피크 타임 시 네트워크 라인에서 최소 267 Mbps 이상의 아웃바운드 대역폭을 보장해야 병목이 생기지 않습니다. 일반적인 Cloud VM 인스턴스의 경우 기본 제공 대역폭(예: 1Gbps~10Gbps) 내에 충분히 들어오는지 체크해야 하며, CDN을 앞단에 배치할 경우 대역폭 부담을 크게 낮출 수 있습니다.

네트워크 트래픽 비용 산정 예시

이벤트가 발생하는 1시간 동안 전송되는 총 데이터 양을 기반으로 클라우드 트래픽 비용을 미리 예상해 볼 수 있습니다.

1시간 동안의 총 데이터 이전량 = 33.325 MB/s x 3,600초 = 119,970 MB = 약 117.15 GB

클라우드 서비스의 아웃바운드 트래픽 단가가 GB당 약 0.08 달러라고 가정하면, 피크 1시간 동안 발생하는 순수 네트워크 트래픽 비용은 약 9.37 달러 수준으로 계산됩니다. 이처럼 수치화된 계산을 바탕으로 예산 보고서를 작성할 수 있습니다.

5. 실무에서 놓치기 쉬운 4가지 병목 변수와 체크리스트

API 서버 대수와 네트워크 대역폭 계산이 끝나도 실제 운영 환경에서는 예기치 못한 병목이 발생할 수 있습니다. 계산된 서버 수량이 제 역할을 하기 위해 반드시 사전에 점검해야 하는 4가지 실무 변수가 있습니다.

1) DB Connection Pool 및 DB CPU 병목

API 서버를 2대에서 8대로 늘리면, DB로 들어오는 커넥션 수도 4배로 증가합니다. API 서버의 HikariCP 등 커넥션 풀 개수(Max Pool Size) 설정이 너무 크면 DB의 CPU가 100%에 도달하여 전체 시스템이 다운됩니다.

API 서버 8대 x Pod당 Pool Size 20개 = 총 160개 커넥션이 DB에 유입됩니다. DB의 Target TPS 및 Connection Limit을 미리 검증해야 합니다.

2) 외부 연동 API 제한 (Third-party Rate Limit)

우리가 구축한 API 내부에서 외부 연동 서비스(예: 카카오 알림톡, PG 결제 모듈, 본인인증 모듈)를 호출하는 경우, 외부 업체가 설정한 초당 요청 제한(Rate Limit)을 확인해야 합니다. 우리 서버가 1,000 TPS를 쏘더라도 외부 업체 제한이 200 TPS라면 외부 호출 부분에서 실패가 발생합니다.

3) Auto Scaling 스케일 아웃 반응 지연 (Warm-up Time)

트래픽이 급증할 때 CPU 사용률이 올라가고, 새 인스턴스가 생성되어 서비스에 투입(In-Service)되기까지는 보통 2분~5분 이상의 시간(Image Pull, Container Start, Application Warm-up)이 소요됩니다. 12:00 정각에 트래픽이 몰리는 이벤트라면 Auto Scaling에만 의존하지 말고, 이벤트 시작 30분 전에 미리 인스턴스를 8대로 늘려두는 Scheduled Scaling을 적용해야 합니다.

4) 캐시(Redis) 히트율 및 Cold Start

DB 부하를 줄이기 위해 Redis 캐시를 사용하는 경우, 피크 타임 직전에 캐시가 비어있으면(Cache Cold State) 모든 요청이 DB로 쏟아지는 Cache Stampede 현상이 발생할 수 있습니다. 주요 데이터는 피크 타임 전에 미리 캐시에 로딩(Warm-up)시켜 두어야 합니다.

용량 산정 실무 점검 체크리스트

• 이벤트 피크 타임 예상 DAU 및 Peak Factor를 적용한 Target TPS 계산 완료 여부
• Staging 환경에서 n6/k6 등을 활용한 단일 Pod(Target CPU 65% 이하) TPS 측정 완료 여부
• Safety Margin(1.2 ~ 1.5)을 반영한 최종 필요 API 서버 수량 산정 완료 여부
• API 응답 데이터 크기 기준 필요 네트워크 대역폭(Mbps) 계산 완료 여부
• API 서버 수증가에 따른 DB Connection Pool 총합 및 DB CPU 스펙 검증 여부
• 이벤트 시작 최소 30분 전 Scheduled Scaling (수동 사전 증설) 계획 수립 여부

6. 신입 실무자를 위한 용량 산정 핵심 실행 요약

1. 지표 변환: 비즈니스 지표(DAU, 이벤트 인원)를 바탕으로 피크 시간대 집중률과 Peak Factor(2.0~2.5)를 곱하여 시스템 목표 초당 처리량(Target Peak TPS)을 도출합니다.
2. 단일 성능 측정: 부하 테스트를 통해 CPU 사용률 60~70% 선을 유지하는 단일 서버의 안전 임계 TPS를 측정합니다.
3. 서버 수 산정: `(Target Peak TPS x 1.3) / 단일 서버 안전 TPS` 공식을 적용해 필요한 최적의 서버 대수를 구하고, 올림 처리하여 반영합니다.
4. 대역폭 검증: `(Target Peak TPS x 응답크기(KB) x 8) / 1024` 공식으로 필요 대역폭(Mbps)을 산정하고 클라우드 인프라 대역폭 한계와 비교합니다.
5. 사전 증설 및 DB 점검: 이벤트 당일에는 Auto Scaling 지연에 대비해 최소 30분 전 사전 증설(Scheduled Scaling)을 진행하고, DB 커넥션 풀과 캐시 Warm-up 상태를 반드시 재점검합니다.