TPS(Transaction Per Second)가 높아지기 시작했다면?

TPS가 초과되었을 때, 내가 가장 먼저 고민한 것: Scale-Up과 Scale-Out의 균형

“지금 우리 시스템이 감당할 수 있는 TPS(Transaction Per Second)는 과연 몇일까?”
TPS는 단순히 초당 얼마나 많은 트랜잭션을 처리할 수 있는지를 나타내는 지표이지만, 사실상 시스템 성능의 가장 명확한 척도다. 요청 하나가 들어와서 처리되기까지의 흐름, 즉 데이터베이스 쿼리 실행, 비즈니스 로직 수행, 응답 반환 등의 전 과정이 하나의 트랜잭션이라고 볼 수 있는데, 이 흐름을 초당 몇 개나 감당할 수 있느냐는 결국 시스템의 내구성과 설계 역량을 가늠하는 기준이 된다.

TPS 초과 시 나타나는 문제: 성능 저하와 장애

TPS를 초과하는 트래픽이 들어온다면 시스템은 어떻게 될까? 자연스럽게 서버는 점점 느려지고, 결국에는 요청에 응답하지 못하거나 전체 시스템이 멈추는 장애 상황으로 이어진다. 이러한 위기에서 가장 먼저 고려할 수 있는 것은 바로 ‘수직 확장’, 즉 Scale-Up이다. CPU, 메모리, SSD 등 하드웨어 성능을 끌어올려 즉각적인 효과를 보는 방식으로, 단기적인 위기 대응에 적합하다.

Scale-Up의 한계: 비용과 비선형적 성능 증가

하지만 나는 Scale-Up을 어디까지나 ‘시간을 벌기 위한 임시 대응’으로 본다. 수직 확장은 하나의 서버에 리소스를 몰아주는 방식이라 근본적인 한계가 존재한다. 무엇보다 성능이 선형적으로 증가하지 않는다. CPU나 메모리를 두 배로 늘린다고 해서 TPS도 두 배로 오르는 건 아니다. 일정 수준 이상에서는 하드웨어를 아무리 올려도 성능 향상이 거의 없는 지점에 도달하게 된다.

근본적인 해결책은 수평 확장, Scale-Out

그래서 근본적으로 시스템을 확장하기 위해서는 ‘수평 확장(Scale-Out)’이 필요하다. 서버를 여러 대로 구성하고, 들어오는 요청을 병렬적으로 분산 처리할 수 있는 구조를 설계해야 한다. 하지만 단순히 서버를 늘린다고 해서 모든 문제가 해결되는 것은 아니다. 여기에는 반드시 로드 밸런싱 전략이 함께 따라와야 한다.

로드 밸런싱의 기본: 정적 분산 방식

로드 밸런싱에는 정적 방식과 동적 방식이 존재한다. 가장 대표적인 정적 방식은 Round Robin이다. 요청을 순서대로 각 서버에 분배하는 단순한 방식으로, 구현이 쉬운 장점이 있다. 하지만 이 방식은 각 서버의 현재 상태를 고려하지 않기 때문에, 어떤 서버가 과도한 부하를 받고 있더라도 계속해서 요청을 할당받는 문제가 있다.
또 다른 방식인 IP Hash는 클라이언트 IP를 해싱하여 특정 서버에 요청을 고정시키는 방식이다. 그러나 이 역시 트래픽 불균형이나 해시 충돌 문제로 인해 분산이 제대로 이뤄지지 않는 경우가 있다.

로드 밸런싱 다이나믹 방식 : 실시간 부하 기반의 동적 방식

그래서 최근에는 서버의 실시간 상태를 반영하여 요청을 분산하는 동적 로드 밸런싱 방식이 널리 쓰인다. 이 방식은 각 서버의 응답 시간, CPU 사용률, 커넥션 수 등을 기준으로 판단하여 요청을 가장 적절한 서버로 보내준다. 실제 부하 상태를 기반으로 하기 때문에 트래픽이 고르게 분산되는 효과가 있지만, 그만큼 시스템 상태를 실시간으로 수집하고 분석해야 하므로 설계와 구현 난이도는 높아진다.

수평 확장의 필수 고려사항 : 세션 관리

서버를 여러 대로 구성하면 또 하나의 문제가 발생한다. 바로 세션 상태 관리다. 로그인 정보, 장바구니 등 세션 기반 데이터가 각 서버에 저장된다면, 서버 간 요청이 이동할 때 문제가 생길 수밖에 없다. 이를 해결하기 위해 Redis와 같은 외부 세션 저장소를 활용하거나, 서버를 Stateless하게 구성해 JWT와 같은 토큰 기반 인증 방식으로 전환하는 등의 방법이 필요하다.

TPS와 처리량을 구분해서 바라보기

TPS는 성능의 척도이고, 처리량은 병렬성의 척도다. 하나의 요청이 오래 걸리면 TPS는 자연스럽게 낮아지고, 처리량 역시 제한을 받는다. 따라서 TPS를 높이기 위해서는 서버를 늘리는 것 외에도, DB 인덱스 최적화, 캐시 도입, 비동기 처리, Queue 기반 아키텍처와 같은 근본적인 구조 개선이 병행되어야 한다.

TPS는 단순한 숫자가 아닌, 설계 철학의 반영일 수 있다.

TPS는 단지 “얼마나 빠르게 처리하느냐”의 문제가 아니다. 시스템이 예측 가능하고 안정적으로 동작하는가, 그리고 지금의 구조가 그 성장과 변화를 수용할 수 있는가를 묻는 지표이기도 하다. TPS가 넘쳐나는 상황은 결국 아키텍처 설계의 본질에 대한 질문이며, 단순한 대응이 아니라 전략적 접근이 필요하다.

문제를 얼마나 빨리 해결하느냐보다, 문제를 어떻게 바라보는가가 더 중요할 수 있다는 사실을 나는 이번 경험을 통해 다시 한번 체감하게 되었다.