[Cloud] Scale-up과 Scale-out

서버를 키울 것인가, 늘릴 것인가?

---

두 가지 확장 방식

포켓몬 카드로 인해 성수동의 트래픽이 급격하게 증가한 상황

 

트래픽이 늘어나면 인프라는 반드시 확장을 고민하게 된다. 이때 선택할 수 있는 방향은 크게 두 가지다.

기존 서버를 더 강하게 만드는 Scale-up(수직 확장)과, 서버 대수를 늘려 부하를 나누는 Scale-out(수평 확장)이다.

이 둘은 단순히 '방법이 다르다'의 문제가 아니라, 시스템 구조 전체의 설계 철학을 가르는 분기점이다.

---

Scale-up: 한 대를 더 강하게

Upgrade 5

Scale-up은 서버의 CPU, 메모리, 디스크를 업그레이드해 처리 능력을 높이는 방식이다. 애플리케이션 구조를 바꿀 필요 없다는 게 가장 큰 장점이다. 단일 서버, 단일 데이터베이스를 그대로 유지한 채 사양만 올리면 되기 때문에, 특히 데이터 정합성이 중요한 RDBMS(관계형 데이터베이스) 환경에서 여전히 널리 쓰인다. 여러 대로 쪼개는 순간 트랜잭션 처리나 데이터 동기화 문제가 따라오기 때문이다.

SPOF

하지만 물리적 한계가 명확하다. 서버 한 대에 넣을 수 있는 CPU 코어 수, 메모리 용량에는 상한선이 있고, 그 상한에 가까워질수록 업그레이드 비용은 기하급수적으로 증가한다. 또한 업그레이드 작업 중에는 서버를 잠시 멈춰야 하는 경우가 많아 다운타임이 발생하기 쉽다. 그리고 결정적으로, 서버 한 대에 모든 부하가 몰리는 구조이기 때문에 그 한 대가 죽으면 서비스 전체가 멈추는 단일 장애점(SPOF, Single Point of Failure) 문제를 안고 간다.

---

Scale-out: 여러 대로 나눠서

출처: https://devuna.tistory.com/73

Scale-out은 서버를 여러 대로 늘려 부하를 분산시키는 방식이다. 이론적으로는 서버를 계속 추가하면 되기 때문에 확장의 상한선이 사실상 없다. 게다가 서버 한 대가 죽어도 나머지가 요청을 처리할 수 있어 가용성 측면에서도 유리하다.

 

이 방식이 성립하려면 몇 가지 전제 조건이 따라 온다.

 

로드밸런서(load balancer)가 있어야 여러 서버에 요청을 고르게 분산할 수 있다. L4(전송 계층 기반, IP·포트 단위 분산)와 L7(애플리케이션 계층 기반, URL·헤더 단위 분산) 로드밸런싱 중 어떤 걸 쓰느냐에 따라 트래픽 제어 정밀도가 달라진다.

 

무상태(Stateless) 설계도 필요하다. 만약 서버가 사용자의 세션 정보를 자기 메모리에만 들고 있다면, 다음 요청이 다른 서버로 가는 순간 그 정보를 잃어버린다. 이 문제를 해결하려면 세션 정보를 Redis 같은 외부 저장소에 분리해서 어느 서버가 요청을 받아도 동일한 상태에 접근할 수 있게 만들어야 한다.

 

데이터베이스 계층에서는 샤딩(sharding)이나 복제(replication) 전략이 필요해진다. 서버는 늘렸는데 모든 서버가 결국 하나의 DB만 바라본다면 그 DB가 새로운 병목이자 새로운 SPOF가 되기 때문이다.

 

* 샤딩(sharding): 하나의 거대한 데이터베이스나 네트워크 시스템을 여러 개의 작은 조각으로 나누어 분산 저장하여 관리하는 것

---

클라우드가 Scale-out을 기본값으로 만든 이유

 

온프레미스 환경에서 Scale-out은 물리 서버를 직접 사서 랙에 꽂아야 하는 일이었다. 늘리는 데도, 다시 줄이는 데도 시간과 비용이 든다. 반면 클라우드는 가상 서버를 몇 분 안에 생성하고 삭제할 수 있기 때문에, Scale-out의 가장 큰 약점이었던 "구축 시간"이 사실상 사라졌다.

공포의 트래픽

 

여기서 나온 것이 오토스케일링(Auto Scaling)이다.

CPU 사용률이나 요청 수 같은 지표를 기준으로 삼아, 트래픽이 몰리면 서버를 자동으로 늘리고 트래픽이 빠지면 자동으로 줄인다. Scale-up이 "미리 넉넉하게 사양을 잡아두는" 정적인 접근이라면, 클라우드의 Scale-out은 "필요한 만큼만 실시간으로 맞추는" 동적인 접근이라는 점에서 근본적으로 다르다. 이 덕분에 트래픽이 예측 불가능한 서비스일수록 클라우드 환경에서는 Scale-out이 기본 전략으로 자리잡았다.

---

결국 무엇을 선택해야 하는가

 

두 방식 중 무엇이 우월한지는 정해져 있지 않다. 트래픽 패턴이 안정적이고 데이터 정합성이 최우선인 시스템(예: 금융 코어 뱅킹 DB)이라면 Scale-up이 여전히 합리적인 선택일 수 있다. 반대로 트래픽 변동이 크고 무중단 운영이 중요한 웹 서비스라면 Scale-out이 자연스러운 선택이 된다.

 

실무에서는 이 둘을 배타적으로 쓰기보다 함께 쓰는 경우가 많다.

데이터베이스는 어느 정도 Scale-up으로 사양을 확보하고, 그 앞단의 애플리케이션 서버들은 Scale-out으로 트래픽을 분산하는 하이브리드 구조가 대표적이다. 결국 "어디까지 수직으로 버틸 것인가, 어디부터 수평으로 나눌 것인가"를 결정하는 것이 인프라 설계의 핵심 질문 중 하나다.