트래픽이 10배 증가한다면 기존 서버에서 무엇부터 확인해야 할까?
서비스를 운영하다 보면 갑작스럽게 트래픽이 증가하는 순간이 찾아옵니다.
광고가 시작되거나, 특정 콘텐츠가 외부에 노출되거나, 이벤트와 프로모션으로 사용자가 몰리면서 평소보다 몇 배 많은 요청이 서버로 들어올 수 있습니다.
이때 운영자가 가장 먼저 하는 실수 중 하나가 CPU와 메모리만 확인하는 것입니다.
CPU 사용률이 낮고 메모리가 남아 있다고 해서 서버가 더 많은 요청을 처리할 수 있다는 의미는 아닙니다.
웹 서버의 동시 연결 수, TCP 연결 상태, 파일 디스크립터, 네트워크 대역폭, 애플리케이션 처리 속도, 데이터베이스 Connection Pool 등 다른 자원이 먼저 한계에 도달할 수 있기 때문입니다.
따라서 트래픽이 10배 증가할 것으로 예상된다면 단순히 서버 스펙부터 높이기보다 현재 요청 처리 구조에서 어디가 가장 먼저 병목이 될 것인지 찾는 과정이 필요합니다.
트래픽 증가가 서버 장애로 이어지는 이유
트래픽이 증가한다는 것은 단순히 네트워크 데이터 사용량만 증가한다는 의미가 아닙니다.
예를 들어 기존 서버가 초당 100개의 HTTP 요청을 처리하고 있었다고 가정해 보겠습니다.
트래픽이 10배 증가하면 초당 약 1,000개의 요청이 들어올 수 있습니다.
이때 서버 내부에서는 동시에 여러 자원이 영향을 받습니다.
HTTP Connection 수가 증가하고, Nginx Worker가 처리해야 할 이벤트가 많아지며, 애플리케이션 서버의 요청 처리량도 증가합니다.
데이터베이스 조회가 포함된 요청이라면 DB Connection 역시 증가할 수 있습니다.
외부 API를 호출하는 서비스라면 외부 서버 응답을 기다리는 Connection도 늘어납니다.
결국 트래픽 증가는 다음과 같은 형태로 서버 전체에 전달됩니다.
사용자 증가
↓
HTTP 요청 증가
↓
TCP Connection 증가
↓
웹 서버 처리량 증가
↓
Application 요청 증가
↓
DB / Cache / API 호출 증가여기서 어느 한 구간이라도 처리 능력이 부족하면 그 지점부터 요청이 쌓이기 시작합니다.
서버 장애는 CPU가 100%가 되었을 때만 발생하는 것이 아닙니다.
오히려 CPU 사용률이 40~50%인데도 사용자에게 Timeout이 발생하는 경우가 많습니다.
가장 먼저 확인해야 하는 것은 현재 처리량이다
트래픽 증가에 대비하려면 현재 서버가 얼마나 바쁜지부터 알아야 합니다.
단순히 CPU 사용률을 보는 것보다 중요한 것은 현재 서버가 초당 몇 개의 요청을 처리하고 있는지입니다.
Nginx를 사용한다면 Access Log를 이용해 일정 시간 동안 처리된 요청 수를 계산할 수 있습니다.
예를 들어 1분 동안 요청 수를 확인하면 현재 대략적인 RPS(Request Per Second)를 구할 수 있습니다.
awk '$4 ~ /22\/Sep\/2026:18:40/' /var/log/nginx/access.log | wc -l1분 동안 6,000개의 요청이 발생했다면 평균 처리량은 약 100 RPS입니다.
6,000 Request ÷ 60초
= 약 100 RPS트래픽이 10배 증가한다면 단순 계산으로 약 1,000 RPS를 처리할 수 있어야 합니다.
중요한 것은 서버가 현재 100 RPS를 처리하고 있다는 사실이 아니라 1,000 RPS에서도 정상적인 응답 시간을 유지할 수 있느냐입니다.
평균 트래픽만 확인해서도 안 됩니다.
실제 서비스에서는 특정 시간에 요청이 몰리는 Peak Traffic이 발생하기 때문입니다.
평균 100 RPS인 서버에서도 순간적으로 300~400 RPS가 발생할 수 있습니다.
따라서 트래픽을 계산할 때는 평균값과 함께 최대 요청량을 확인하는 것이 중요합니다.
CPU보다 먼저 동시 Connection을 확인해야 한다
웹 서버에서 트래픽 증가와 직접적인 관계가 있는 자원 중 하나가 Connection입니다.
Nginx에서는 Worker Process가 여러 Connection을 이벤트 기반으로 처리합니다.
현재 Connection 상태는 다음과 같이 확인할 수 있습니다.
ss -s또는 특정 포트의 연결 수를 확인할 수도 있습니다.
ss -ant | grep ':443' | wc -l여기서 중요한 것은 단순히 연결 개수만 보는 것이 아닙니다.
TCP 상태도 함께 확인해야 합니다.
ss -ant | awk '{print $1}' | sort | uniq -c예를 들어 결과가 다음과 같이 나타날 수 있습니다.
3200 ESTAB
850 TIME-WAIT
120 SYN-RECVESTABLISHED가 많다는 것은 실제 연결된 클라이언트가 많다는 의미입니다.
TIME_WAIT가 과도하게 증가한다면 짧은 연결이 반복적으로 생성되고 있을 가능성이 있습니다.
SYN_RECV가 급격히 증가한다면 서버가 새로운 연결을 충분히 빠르게 처리하지 못하고 있을 수도 있습니다.
트래픽이 10배 증가하면 요청 수뿐만 아니라 Connection도 함께 증가하기 때문에 이 부분을 미리 확인해야 합니다.
파일 디스크립터 한계도 반드시 확인해야 한다
Linux에서는 네트워크 Socket도 파일 디스크립터로 관리합니다.
따라서 Connection이 많아질수록 프로세스가 사용하는 File Descriptor 수도 증가합니다.
현재 제한 값은 다음 명령어로 확인할 수 있습니다.
ulimit -n예를 들어 결과가 다음과 같다고 가정해 보겠습니다.
1024이 경우 프로세스 하나가 사용할 수 있는 파일 디스크립터 수가 제한되어 있을 수 있습니다.
웹 서버가 수천 개 이상의 Connection을 처리해야 하는 상황이라면 문제가 발생할 수 있습니다.
현재 Nginx 프로세스가 사용하고 있는 파일 디스크립터 수도 확인할 수 있습니다.
ls /proc/$(pgrep -o nginx)/fd | wc -lConnection이 증가하면서 File Descriptor 제한에 가까워질 경우 로그에 다음과 같은 메시지가 나타날 수 있습니다.
Too many open filesCPU와 메모리가 충분한데도 새로운 연결이 실패한다면 반드시 확인해야 하는 항목입니다.
CPU는 사용률보다 처리 대기 상태를 봐야 한다
CPU를 확인할 때 단순히 사용률만 보면 실제 병목을 놓칠 수 있습니다.
먼저 다음 명령어를 사용할 수 있습니다.
top 또는 mpstat -P ALL 1여기서 봐야 할 것은 전체 CPU 사용률뿐만 아니라 특정 Core에 부하가 집중되는지 여부입니다.
예를 들어 16 Core 서버에서 전체 CPU 사용률은 40%인데 특정 Core가 100%에 가까울 수 있습니다.
Single Thread 기반 작업이나 특정 프로세스 구조에서는 이런 현상이 발생할 수 있습니다.
Load Average도 함께 확인합니다.
uptime예를 들어 다음과 같은 결과가 나왔다고 가정해 보겠습니다.
load average: 3.20, 3.05, 2.8016 Core 서버라면 크게 문제가 되지 않을 가능성이 있습니다.
하지만 2 Core 서버라면 CPU 또는 I/O 대기 작업이 상당히 쌓이고 있다는 신호일 수 있습니다.
Load Average는 단순 CPU 사용률이 아니라 CPU를 사용하려고 기다리는 작업과 일부 I/O 대기 작업도 포함하기 때문에 서버 전체 부하를 판단하는 데 유용합니다.
메모리는 free보다 Available을 봐야 한다
Linux 서버에서 메모리를 확인할 때 다음 명령어를 많이 사용합니다.
free -h여기서 단순히 free 값만 보고 메모리가 부족하다고 판단하면 안 됩니다.
Linux는 사용하지 않는 메모리를 Page Cache 등으로 적극 활용하기 때문입니다.
실제로 중요한 값은 available입니다.
예를 들어 다음과 같은 상황이라면
Mem:
total 16G
used 10G
free 500M
available 5.8Gfree 값은 매우 작지만 실제 애플리케이션이 추가로 사용할 수 있는 메모리는 약 5.8GB입니다.
다만 트래픽 증가 시 Application Process, Connection Buffer, Cache 사용량 등이 증가하면서 메모리 사용량도 함께 증가할 수 있습니다.
특히 Java나 Node.js처럼 애플리케이션 런타임 자체의 메모리 사용량이 큰 환경에서는 트래픽 증가에 따른 Heap 사용량을 별도로 확인해야 합니다.
Swap이 지속적으로 사용되는지도 중요합니다.
vmstat 1si, so 값이 지속적으로 발생한다면 메모리 압박으로 인해 Swap In/Out이 발생하고 있을 가능성이 있습니다.
이 상태에서는 CPU 사용률이 높지 않아도 응답 시간이 크게 증가할 수 있습니다.
네트워크 대역폭이 병목이 될 수도 있다
웹 서비스에서는 네트워크 처리량 역시 중요한 요소입니다.
특히 이미지, 영상, 대용량 파일을 직접 제공하는 서버에서는 트래픽 증가와 네트워크 사용량이 거의 비례해서 증가할 수 있습니다.
현재 인터페이스 트래픽은 다음과 같이 확인할 수 있습니다.
sar -n DEV 1 또는 ip -s link예를 들어 서버의 네트워크 인터페이스가 1Gbps라고 하더라도 실제 환경에서는 항상 최대 속도를 모두 사용할 수 있는 것은 아닙니다.
애플리케이션 특성에 따라 Outbound Traffic이 먼저 증가할 수도 있습니다.
평균 응답 크기가 500KB인 요청이 초당 200개 발생한다면 단순 계산만으로도 상당한 네트워크 대역폭을 사용하게 됩니다.
따라서 요청 수만 증가한다고 생각하지 말고 RPS × 평균 응답 크기도 함께 계산해야 합니다.
실제 병목은 데이터베이스에서 먼저 발생할 수 있다
웹 서버가 충분한 Connection을 처리한다고 해서 전체 서비스가 정상적으로 동작하는 것은 아닙니다.
실제 운영 환경에서는 DB가 먼저 병목이 되는 경우가 많습니다.
예를 들어 애플리케이션에 DB Connection Pool이 다음과 같이 설정되어 있다고 가정해 보겠습니다.
Maximum Pool Size = 100트래픽이 증가하면서 동시에 150개의 DB 요청이 발생하면 100개는 즉시 처리되지만 나머지 요청은 Connection이 반환될 때까지 기다려야 합니다.
이 과정에서 웹 서버 CPU는 여전히 여유가 있을 수 있습니다.
하지만 사용자 입장에서는 응답 시간이 계속 증가합니다.
따라서 다음 항목을 함께 확인해야 합니다.
DB Connection 수
Slow Query 발생 여부
Query 실행 시간
Lock 발생 여부
Connection Pool 대기 시간
DB CPU 및 Disk I/OCache를 사용하는 서비스라면 Redis와 같은 캐시 서버의 처리량과 Connection 수도 확인해야 합니다.
트래픽 증가 대응에서 웹 서버만 확인하면 안 되는 이유입니다.
트래픽 증가 전에 부하 테스트가 필요한 이유
기존 서버가 트래픽을 얼마나 견딜 수 있는지는 실제 부하를 발생시켜 보는 것이 가장 정확합니다.
부하 테스트에서는 단순히 서버가 다운되는 시점을 찾는 것이 목적이 아닙니다.
트래픽이 증가하면서 어떤 지표가 먼저 변하는지 확인해야 합니다.
예를 들어 테스트 결과가 다음과 같다고 가정해 보겠습니다.
200 RPS → 평균 응답 80ms
400 RPS → 평균 응답 95ms
600 RPS → 평균 응답 130ms
800 RPS → 평균 응답 420ms
1000 RPS → Timeout 발생이 경우 서버의 실질적인 안정 처리 구간은 1,000 RPS가 아닙니다.
800 RPS부터 응답 시간이 급격히 증가하고 있기 때문에 그 이전부터 이미 병목이 시작되고 있다고 봐야 합니다.
테스트 중에는 다음 항목을 동시에 수집해야 합니다.
RPS
Response Time
Error Rate
CPU
Memory
Load Average
TCP Connection
Disk I/O
Network
DB Connection이 지표들을 시간 순서대로 비교하면 어떤 자원이 먼저 한계에 도달했는지 확인할 수 있습니다.
서버 스펙 업보다 병목 제거가 먼저다
트래픽 증가가 예상될 때 가장 쉬운 대응은 서버 사양을 올리는 것입니다.
CPU Core를 늘리고 메모리를 추가하면 분명 처리 능력이 증가할 수 있습니다.
하지만 모든 병목이 서버 사양 부족 때문에 발생하는 것은 아닙니다.
예를 들어 DB Slow Query 하나가 요청당 2초씩 걸리고 있다면 웹 서버 CPU를 두 배로 늘려도 큰 효과가 없을 수 있습니다.
Connection Pool이 100개로 제한되어 있다면 서버를 고사양으로 변경해도 동시에 처리할 수 있는 DB 요청 수는 그대로일 수 있습니다.
따라서 확장은 다음 순서로 접근하는 것이 좋습니다.
현재 처리량 측정
↓
병목 지점 확인
↓
설정 및 애플리케이션 개선
↓
Cache / CDN 적용 검토
↓
Scale Up
↓
Scale Out정적 파일은 CDN으로 분리하고 반복 조회 데이터는 Cache를 활용하면 서버가 직접 처리해야 하는 요청 자체를 줄일 수도 있습니다.
그 이후에도 처리량이 부족하다면 여러 서버로 요청을 분산하는 Scale Out 구조를 고려할 수 있습니다.
운영자가 가장 중요하게 봐야 하는 것은 여유율이다
서버 운영에서는 최대 성능보다 현재 사용량 대비 남아 있는 여유가 더 중요합니다.
예를 들어 부하 테스트 결과 서버가 최대 1,000 RPS까지 처리할 수 있다고 해서 실제 운영 환경에서 950 RPS까지 사용하는 것은 위험합니다.
실제 트래픽에는 예상하기 어려운 순간적인 Peak가 발생하기 때문입니다.
외부 API 지연이나 DB Slow Query가 발생하면 동일한 트래픽에서도 Connection이 더 오래 유지됩니다.
평소보다 응답 시간이 길어지는 것만으로도 동시 Connection 수가 급격히 증가할 수 있습니다.
따라서 서버 용량을 계산할 때는 단순 최대 처리량보다 안정적인 응답 시간이 유지되는 구간을 기준으로 잡는 것이 좋습니다.
운영 환경에서는 평균 상태보다 장애 직전 상태를 이해하는 것이 중요합니다.
정리
트래픽이 10배 증가한다고 해서 서버 사양을 곧바로 10배 높여야 하는 것은 아닙니다.
먼저 현재 서버가 초당 몇 개의 요청을 처리하고 있는지 확인하고, 요청 증가에 따라 어떤 자원이 먼저 한계에 도달하는지를 찾아야 합니다.
특히 다음 항목을 함께 확인하는 것이 중요합니다.
현재 RPS와 Peak RPS
동시 TCP Connection
Nginx Worker 처리량
File Descriptor 제한
CPU와 Load Average
Available Memory와 Swap
Disk I/O
Network Bandwidth
DB Connection Pool
Slow Query
Cache 서버 처리량그리고 가능하다면 실제 트래픽 증가 전에 부하 테스트를 진행해 RPS 증가에 따른 Response Time과 Error Rate 변화를 확인해야 합니다.
서버 용량 계획에서 가장 중요한 질문은
“이 서버의 CPU가 얼마나 남아 있는가?”가 아니라 “요청이 증가했을 때 어떤 자원이 가장 먼저 한계에 도달하는가?”입니다.
이 병목 지점을 정확하게 찾을 수 있어야 불필요한 서버 증설을 줄이고, 실제 트래픽 증가에도 안정적으로 대응할 수 있습니다.
댓글 0
첫 댓글을 남겨보세요.