트래픽이 몰리면 시스템에는 무슨 일이 일어날까
이 글은 「대용량 트래픽 제어하기」 시리즈 1편이다.
이 시리즈에서는 단순한 개념 정리를 넘어, 실제 운영 환경에서 트래픽이 증가할 때 시스템 내부에서 어떤 일이 벌어지는지를 단계적으로 풀어간다. 1편에서는 대용량 트래픽 문제가 왜 발생하는지, 그리고 왜 Scale Out만으로는 충분하지 않은지를 중심으로 살펴본다.
대용량 트래픽 문제는 언제 시작되는가
대용량 트래픽 문제는 단순히 요청 수가 많아졌기 때문에 발생하지 않는다.
문제는 시스템이 감당할 수 있는 처리 능력을 초과하는 순간부터 시작된다.
이때 시스템 내부에서는 다음과 같은 변화가 동시에 일어난다.
- 요청 대기 시간 증가
- 스레드 점유 시간 증가
- 커넥션 풀 고갈
- 응답 지연이 다음 요청으로 전파
트래픽 증가는 하나의 현상이지만, 실제 문제는 여러 계층에서 동시에 발생한다.
가장 먼저 떠올리는 해결책: 서버를 늘리자
트래픽이 늘면 가장 먼저 떠올리는 해결책은 서버를 늘리는 것이다.
- 서버 사양을 올리는 Scale Up
- 서버 수를 늘리는 Scale Out
이 중 현대적인 웹 서비스에서는 Scale Out이 기본 전략처럼 여겨진다. 하지만 여기서 중요한 질문이 하나 있다.
정말 서버만 늘리면 문제가 해결될까?
Scale Out은 무엇을 해결하고, 무엇을 해결하지 못하는가
Scale Out은 처리량을 늘리는 전략이다.
동일한 역할을 하는 서버를 여러 대 두고 요청을 분산한다.
이 방식이 효과적인 이유는 다음과 같다.
- 요청 처리 병렬화
- 단일 서버 장애 영향 감소
- 수평 확장 용이
하지만 Scale Out은 모든 문제를 해결하지 않는다.
Scale Out이 전제하는 조건들
Scale Out이 제대로 동작하려면 몇 가지 전제가 필요하다.
- 요청이 독립적일 것
- 서버가 무상태(stateless)일 것
- 병목 지점이 애플리케이션 서버일 것
이 전제가 깨지는 순간, Scale Out의 효과는 급격히 감소한다.
트래픽은 항상 같은 경로로 흐르지 않는다
하나의 요청이 처리되는 경로를 단순화해보면 다음과 같다.
- 클라이언트 요청
- Load Balancer
- API 서버
- DB 또는 외부 시스템
Scale Out은 이 중 API 서버 구간만 확장한다.
하지만 실제 병목은 종종 다른 지점에서 발생한다.
- DB 쓰기 성능
- 외부 API 응답 지연
- 인증 시스템 장애
이 경우 서버를 아무리 늘려도 체감 성능은 개선되지 않는다.
Scale Out이 오히려 문제를 키우는 순간
대용량 트래픽 상황에서 Scale Out이 역효과를 내는 경우도 있다.
- 느린 외부 시스템을 더 많이 호출
- 실패 요청에 대한 재시도 증가
- 스레드와 커넥션 소모 가속
서버 수가 늘어날수록 문제를 더 빠르게 증폭시키는 구조가 만들어진다.
Load Balancer는 해결책이 아니라 시작점이다
Scale Out 구조에서 Load Balancer는 필수다.
하지만 Load Balancer는 문제를 해결하지 않는다.
Load Balancer의 역할은 다음에 불과하다.
- 요청 분산
- 장애 서버 제외
- 단일 진입점 제공
병목이나 장애의 근본 원인을 제거하지는 않는다.
대용량 트래픽 문제의 본질
대용량 트래픽 문제의 본질은 다음 질문으로 요약된다.
- 어디에서 병목이 발생하는가
- 어떤 리소스가 먼저 고갈되는가
- 실패가 어떻게 전파되는가
이 질문에 답하지 않고 서버만 늘리면, 시스템은 더 빠르게 불안정해진다.
왜 Kubernetes를 써도 문제가 발생할까
Kubernetes는 확장을 쉽게 만들어준다.
- Pod 자동 생성
- HPA를 통한 자동 Scale Out
- 장애 시 자동 복구
하지만 Kubernetes는 문제를 숨겨주지 않는다.
- 리소스 한계는 그대로 존재
- 외부 시스템은 확장되지 않음
- 잘못된 설정은 더 빨리 드러남
Kubernetes는 문제를 해결하는 도구가 아니라, 문제를 명확하게 드러내는 도구에 가깝다.
대용량 트래픽을 다룬다는 것의 의미
대용량 트래픽을 다룬다는 것은 단순히 “많이 처리한다”는 뜻이 아니다.
- 어디까지 버틸 수 있는가
- 어디서 빠르게 실패할 것인가
- 어떻게 회복할 것인가
이 관점이 빠지면 시스템은 쉽게 무너진다.
다음 편에서 다룰 내용
1편에서는 트래픽 증가가 왜 단순한 확장 문제로 끝나지 않는지를 살펴봤다.
다음 편에서는 한 단계 더 들어가 왜 Scale Out을 했는데도 시스템이 터지는지를 다룬다.
다음 글에서는 다음 주제를 중심으로 설명한다.
- HPA는 어떻게 Scale Out을 결정하는가
- requests / limits 설정이 왜 중요한가
- OOMKill은 왜 발생하는가
- JVM 기반 애플리케이션이 특히 취약한 이유
정리
대용량 트래픽 문제는 서버 수 부족의 문제가 아니라, 시스템 구조와 병목, 그리고 실패 전파의 문제다. Scale Out은 중요한 전략이지만, 그것만으로는 충분하지 않다. 이 시리즈에서는 확장 이후에 반드시 마주하게 되는 문제들을 하나씩 분해하며, 대용량 트래픽을 “제어”하는 관점으로 접근한다.
다음 편:
대용량 트래픽 제어하기 2편 – Scale Out을 해도 터지는 이유