시스템 디자인 0-to-1: 수직 확장: 더 큰 것이 항상 더 좋은가? (Ep. 2)
Source: Dev.to
The Initial Struggle
우리의 지난 에피소드에서는 단일 서버가 결국 병목 현상이 된다는 점을 논의했습니다. 요청이 쌓이기 시작하면 서버의 CPU와 RAM이 도움을 외치기 시작합니다.
가장 직관적인 해결책? 서버를 더 강력하게 만드는 것입니다. 이것을 수직 확장(Vertical Scaling) 혹은 “스케일 업(Scaling Up)”이라고 부릅니다.
What is Vertical Scaling?
수직 확장은 서버에 스테로이드를 맞춰 주는 것과 같습니다. 애플리케이션의 동작 방식을 바꾸는 대신, 더 강력한 머신으로 옮기기만 하면 됩니다.
즉, 단일 노드의 용량을 다음을 추가함으로써 증가시키는 것입니다:
- 더 많은 RAM: 동시 작업을 더 많이 처리하기 위해.
- 더 빠른 CPU: 요청을 번개처럼 빠르게 처리하기 위해.
- 더 많은 스토리지/IOPS: 데이터를 더 빠르게 읽고 쓰기 위해.
Why Developers Love It (The Pros)
수직 확장은 초기 스타트업이나 작은 프로젝트에서 “가장 먼저 선택하는” 방법이 되는 이유가 몇 가지 있습니다:
- 단순성: 코드를 한 줄도 바꿀 필요가 없습니다. 아키텍처가 모놀리식 형태를 유지하므로, 분산 시스템보다 관리가 훨씬 쉽습니다.
- 데이터 일관성: 모든 작업이 하나의 머신에서 이루어지기 때문에 여러 서버 간 데이터 동기화에 대해 고민할 필요가 없습니다.
- 비용 효율성(초기 단계): 트래픽이 잠깐 급증할 때는 복잡한 로드밸런싱 시스템을 구축하기보다 클라우드 제공업체에서 “업그레이드” 버튼을 클릭하는 것이 더 저렴합니다.
The Catch: Why It’s Not a Forever Solution (The Cons)
분산 컴퓨팅 TA로서, 많은 학생들이 “스케일 업”을 영원히 할 수 있다고 착각하는 모습을 보았습니다. 하지만 세 가지 큰 함정이 있습니다:
1. The “Hardware Wall”
얼마나 많은 돈을 가지고 있든 물리적인 한계가 존재합니다. 무한한 RAM이나 5,000코어 CPU를 가진 서버를 살 수는 없습니다. 결국 현대 하드웨어가 할 수 있는 한계에 부딪히게 됩니다.
2. Single Point of Failure
하나의 “슈퍼 서버”가 고장 나면(전원 장애나 버그 등) 전체 애플리케이션이 100 % 사용자에게서 사라집니다. 백업이 없습니다.
3. Significant Downtime
서버 하드웨어를 업그레이드하려면 종종 재시작이 필요합니다. 24/7 가동을 기대하는 세상에서 5분의 다운타임도 큰 비용이 될 수 있습니다.
The Verdict
수직 확장은 초기 단계에 매우 훌륭합니다. 빠르고, 간단하며, 엔지니어링 오버헤드를 낮게 유지할 수 있습니다. 하지만 “하드웨어 벽”에 부딪히면 “수평” 확장을 바라볼 수밖에 없습니다.
What’s Next?
수직 확장이 벽에 부딪히면 넷플릭스 같은 거대 기업들은 어떻게 수백만 명의 사용자를 처리할까요? 내일은 대안인 **수평 확장(Horizontal Scaling, Scaling Out)**에 대해 살펴보겠습니다.