Vertical vs Horizontal Scaling

1. Overview

수직 스케일링과 수평 스케일링(Vertical vs Horizontal Scaling)은 터질 듯한 트래픽(TPS) 앞에서 시스템을 무너뜨리지 않고 살아남게 하는 인프라 확장 전략의 양대 산맥을 해부합니다.

학습자는 CPU와 RAM을 무한정 늘려 단일 몬스터 서버를 구축하는 **스케일 업(Scale-up, Vertical)**의 직관성과, 물리적 한계점(Hardware Ceiling) 및 단일 장애점(SPOF)이라는 치명적 약점을 뜯어봅니다. 나아가 작고 저렴한 서버를 100대, 1,000대 병렬로 늘려 부하를 쪼개는 **스케일 아웃(Scale-out, Horizontal)**의 무한한 확장성을 장악합니다. 마지막으로, 단순히 서버 대수를 늘리는 것을 넘어 상태(State)를 분리하고(Stateless), 로드 밸런서로 트래픽을 라우팅하며, 데이터베이스까지 찢어발겨야 하는(Sharding) 수평 확장의 끔찍한 아키텍처적 대가(Complexity)를 저울질하는 엔지니어링 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Vertical Scaling (Scale-up): 단일 장비의 리소스(CPU/Memory/Disk I/O) 증설, 하드웨어 임계점(Ceiling), 단일 장애점(SPOF).
• Horizontal Scaling (Scale-out): 노드(서버) 증설, 무상태(Stateless) 애플리케이션 설계.
• The Trade-offs: 비용 곡선(Cost Curve), 아키텍처 복잡성(Complexity), 락(Lock) 경합 및 오버헤드.
• Scaling State: 세션(Session) 스티키(Sticky) 라우팅 vs 외부 캐시(Redis) 세션 클러스터링.

Out-of-Scope

• Sharding & Partitioning 깊은 설계: DB 찢는 전략 $\rightarrow$ 07-03-02 Replication & Sharding 영역으로 위임.
• Auto-scaling 및 쿠버네티스 프로비저닝: 인프라 자동화 도구 $\rightarrow$ 09-02 CI/CD & DevOps 영역.

Boundaries

• Stateful vs Stateless의 분수령: 스케일 업(Vertical) 환경에서는 서버가 1대이므로, 유저의 로그인 세션이나 캐시를 서버 메모리(RAM)에 맘껏 저장(Stateful)해도 됩니다. 하지만 서버를 10대로 늘리는 스케일 아웃(Horizontal)을 시도하는 순간, 서버 1번에 로그인한 유저가 서버 2번으로 접속하면 '비로그인' 상태가 되는 파국이 발생합니다. 수평 확장은 단순히 버튼을 눌러 서버를 복제하는 마법이 아니라, 애플리케이션 코드 내부에서 모든 상태(State)를 뜯어내어 외부(Redis 등)로 격리시켜야만(Stateless) 성립하는 거대한 소프트웨어 재설계 과정임을 명확히 선을 긋습니다.

3. Counterexample

• DB 스케일 아웃의 환상: "트래픽이 늘었으니 웹 서버 늘리듯 DB도 스케일 아웃(Scale-out) 하자!"라며 MySQL 마스터 서버를 5대로 늘리려 합니다. 웹 서버는 무상태(Stateless)라 무한히 늘릴 수 있지만, RDBMS 마스터를 여러 대 두면 데이터 동기화와 트랜잭션 락(Lock) 경합 때문에 오히려 성능이 폭락하거나 데이터 정합성이 깨집니다. 관계형 DB의 1차 확장 전략은 언제나 스케일 업(Scale-up)과 읽기 복제(Read Replica)이며, 분산 마스터(Sharding)는 인류 최후의 수단이라는 사실을 잊은 치명적 실수입니다.
• 비용 곡선(Cost Curve)의 무지: 트래픽이 평소보다 2배 늘었다고 AWS에서 제일 비싼 128코어 인스턴스로 스케일 업(Scale-up)을 때렸습니다. 인스턴스 스펙이 2배 좋아질 때 가격은 2배가 아니라 4배, 8배로 수직 상승합니다(비선형 비용 곡선). 반면 4코어짜리 싼 서버를 여러 대 띄우는 스케일 아웃은 선형적인 비용(Linear Cost)을 가집니다. 비용 효율성 분석 없이 맹목적인 스케일 업을 하다 월말 클라우드 청구서에 파산하는 안티 패턴입니다.

4. Prerequisites

• 운영체제 메모리 관리 (Basic): RAM과 CPU의 물리적 한계. (03-01 OS Core)
• 네트워크 로드 밸런싱 기초 (Basic): 트래픽 분산 개념. (08-01 OSI Model)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 몬스터 서버를 만들어라, 수직 스케일링 (Vertical Scaling)

• Why to Learn: 분산 아키텍처의 복잡성(분산 트랜잭션, 데이터 동기화)을 겪지 않고, 코드를 1줄도 수정할 필요 없이 돈으로 성능을 사는 가장 빠르고 안전한 해결책의 가치를 인정하기 위함입니다.
• What to Learn:
  • Concepts: Vertical Scaling (Scale-up), CPU/RAM 증설, In-memory 처리량 증가, 락(Lock) 효율성.
  • Skills: 애플리케이션 코드를 건드리지 않는 즉각적인 인프라 대응(Scale-up) 결정.
• How to Learn:
  • 1단계: 코딩 0줄의 기적: 쿼리가 느립니다. 분산 캐시를 도입하고 아키텍처를 갈아엎느라 3개월을 쓰는 대신, DB 서버 램을 16GB에서 128GB로 꽂아버리면 1시간 만에 쿼리가 RAM에서 다 돕니다. "엔지니어의 인건비가 서버비보다 비싸다"는 경제학적 팩트를 해부합니다.
  • 2단계: DB와의 찰떡궁합: 수직 확장은 노드 간 네트워크 통신을 유발하지 않습니다. 로컬 RAM과 로컬 디스크에서 모든 트랜잭션 락(Lock)과 동시성을 제어하므로, RDBMS(Master) 성능을 쥐어짜는 최고의 전략임을 뜯어봅니다.
• Implement: 로컬 벤치마크 테스트. SQLite에 100만 건 데이터를 밀어 넣고 쿼리 벤치마크. 파이썬 프로세스 메모리 제한을 100MB로 뒀을 때(Disk I/O 폭발, 30초 소요)와 메모리 제한을 2GB로 풀었을 때(메모리 캐싱, 1초 소요)의 극적인 Scale-up 성능 차이 렌더링.

Recommended

Core Topic 02: 천장과 아킬레스건 (The Hardware Ceiling & SPOF)

• Why to Learn: 수직 확장이 무한히 지속될 수 없는 하드웨어 제조사의 물리적 장벽과, 한 대가 죽으면 모든 게 끝나는 단일 장애점의 치명적 리스크를 장악하기 위함입니다.
• What to Learn:
  • Concepts: Hardware Ceiling (하드웨어 한계), Non-linear Cost Curve (비선형 비용 곡선), SPOF (Single Point of Failure), Downtime.
  • Skills: 스케일 업 한계점 도달 전 클라우드 아키텍처 전환 시점(Threshold) 예측.
• How to Learn:
  • 1단계: 비용의 폭주: 4코어 서버 2대 빌리는 비용이 100원이라면, 8코어 서버 1대 빌리는 비용은 300원입니다. 단일 칩에 집적도를 높이는 하드웨어 한계 때문에 일정 스펙을 넘어가면 성능 대비 가격 곡선이 비선형(기하급수적)으로 폭발하는 한계를 해부합니다.
  • 2단계: SPOF (Single Point of Failure): 몬스터 서버 하나에 모든 트래픽을 의존합니다. 파워 서플라이가 고장 나거나 메인보드가 타버리면? "99.99% 가용성(High Availability)"이라는 엔터프라이즈의 절대 목표가 불가능해지는 물리적 취약점을 뜯어봅니다.
• Implement: 가격 곡선 렌더링 스크립트. x축(성능), y축(비용). 싼 장비를 여러 대 묶는 Scale-out 방식의 $y=ax$ 1차 함수 그래프와, 최고급 장비를 사는 Scale-up 방식의 $y=a^x$ 지수 함수 그래프를 겹쳐 그려, 특정 트래픽(Threshold) 이후 Scale-up이 파산의 지름길임을 시각화.

Practical

Core Topic 03: 무한한 분신의 군대, 수평 스케일링 (Horizontal Scaling)

• Why to Learn: 클라우드 시대의 패러다임인 "소 떼처럼 기르는(Cattle, not pets)" 값싸고 쉽게 교체 가능한 서버들의 병렬 확장 아키텍처를 설계하기 위함입니다.
• What to Learn:
  • Concepts: Horizontal Scaling (Scale-out), Load Balancer (로드 밸런서), Auto-scaling Group (ASG), Elasticity (탄력성).
  • Skills: NGINX/HAProxy 또는 클라우드 ALB를 앞단에 둔 트래픽 1/N 라우팅 아키텍처 구성.
• How to Learn:
  • 1단계: 1/N의 마법: 트래픽이 10,000 TPS로 터질 때 서버를 10대로 찢습니다. 앞단에 로드 밸런서(L4/L7)를 세워 트래픽을 라운드 로빈(Round Robin)으로 1,000 TPS씩 골고루 흩뿌리는 완벽한 부하 분산을 해부합니다.
  • 2단계: 고가용성(HA)과 오토스케일링: 서버 1번이 죽어도 로드 밸런서가 즉시 헬스체크(Health Check)로 알아채고 트래픽을 서버 2~10번으로 돌립니다. 이벤트 기간엔 서버 100대로 늘렸다가, 평소엔 2대로 줄이는(Elasticity) 완벽한 비용 최적화를 뜯어봅니다.
• Implement: 라운드 로빈 로드 밸런싱 모사 파이썬 스크립트. 가상의 백엔드 서버(['S1', 'S2', 'S3']). 클라이언트 요청 10개가 들어올 때 index = (index + 1) % len(servers) 로직을 통해 트래픽을 정확히 33%씩 균등 분배(Load Balancing)하는 콘솔 출력 봇.

Advanced

Core Topic 04: 서버를 찢는 대가, 무상태 설계 (The Cost of Statelessness)

• Why to Learn: 수평 스케일링을 위해선 반드시 서버의 메모리에서 상태(로그인 세션, 장바구니 등)를 제거해야 함을 깨닫고, 이를 극복하기 위한 외부 세션 클러스터링 인프라를 설계하기 위함입니다.
• What to Learn:
  • Concepts: Stateless Architecture (무상태 아키텍처), Sticky Session (세션 끈끈이), Session Clustering (세션 클러스터링 - Redis/Memcached).
  • Skills: 애플리케이션 메모리(Local State)에서 비즈니스 상태를 분리해 중앙 집중형 인메모리 DB로 외부화(Externalize)하는 리팩터링.
• How to Learn:
  • 1단계: 상태(State)의 반역: 유저가 A 서버에서 로그인했습니다(세션 생성). 다음번 클릭 때 로드 밸런서가 트래픽을 B 서버로 보냅니다. B 서버에는 세션이 없으므로 "로그인하세요"라는 에러가 터집니다. 서버를 늘릴수록 유저가 튕기는 분산 환경의 역설을 해부합니다.
  • 2단계: 세션 클러스터링(Redis): 로드 밸런서에 'Sticky Session(같은 IP는 같은 서버로만 보냄)'을 설정하면 부하 분산이 박살 납니다. 정답은 10대의 서버가 세션을 로컬 메모리에 저장하지 않고, 뒤편에 거대한 단일 Redis 서버를 띄워 공용 메모리로 사용하는 'Stateless 웹 서버' 아키텍처를 뜯어봅니다.
• Implement: Stateless vs Stateful 시뮬레이터. 서버 3대를 파이썬 딕셔너리로 구현. 1) Stateful: 각 딕셔너리에 세션 저장 $\rightarrow$ 트래픽 분산 시 세션 Miss 에러 발생. 2) Stateless: 세션 딕셔너리(Redis_Mock)를 전역(Global) 1개로 뺌. 모든 서버가 이 전역 딕셔너리에 접근하여 트래픽이 맘대로 섞여도 100% 히트(Hit)하는 캐시 외부화 데모.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - System Architecture (Scalability)
• [P5] SFIA - Enterprise IT Architecture (ARCH) - Scalable Systems Design

Secondary

• [Designing Data-Intensive Applications] Martin Kleppmann - Scalability, Reliability, and Maintainability
• [The Art of Scalability] Martin L. Abbott - Scale-Up vs Scale-Out, AKF Scale Cube

Industry

• [AWS Well-Architected Framework] - Reliability and Performance Efficiency Pillars
• [Google Cloud Architecture Center] - Best Practices for Compute Engine Region/Zone

9. Final Checklist

Primary

• 데이터베이스 마스터 서버의 트래픽이 몰릴 때, 섣불리 스케일 아웃(Scale-out)을 하기보다 스케일 업(Scale-up)을 1차 방어선으로 삼아야 하는 트랜잭션 락(Lock) 경합 관점의 이유를 설명할 수 있는가?
• 클라우드 벤더(AWS, GCP)의 가격표를 분석할 때, 128코어 인스턴스 1대(Scale-up)와 16코어 인스턴스 8대(Scale-out)의 가격 곡선이 어떻게 비선형적으로 벌어지는지 증명할 수 있는가?

Secondary

• 트래픽이 10배 뛰었을 때 웹 서버(API 서버)를 10대로 증설(Scale-out)했으나, 유저들이 자꾸 로그인에서 튕기는 현상의 원인을 상태(State) 불일치 관점으로 해부할 수 있는가?
• 로드 밸런서에서 Sticky Session(세션 고정)을 켜면 왜 부하 분산(Load Balancing)의 균형이 무너지고 특정 서버에만 핫스팟(Hotspot) 부하가 몰리는지 논증할 수 있는가?

Industry

• 완전한 무상태(Stateless) 아키텍처를 달성하기 위해, 로컬 세션을 버리고 Redis 기반의 중앙 집중형 세션 클러스터링이나 클라이언트 주도형 JWT(JSON Web Token)로 전환하는 아키텍처를 설계할 수 있는가?
• Scale-out 환경에서 오토스케일링 그룹(ASG)이 CPU 80% 도달 시 서버를 1대 늘리는 이벤트를 발생시킬 때, 런타임(Java Spring)의 무거운 콜드 스타트(Cold Start) 지연 시간을 어떻게 튜닝할지 평가할 수 있는가?