시스템 디자인 0-to-1: 왜 세계에서 가장 큰 앱들은 수평적으로 확장되는가
Source: Dev.to
“하드웨어 벽”의 현실
첫 번째 에피소드에서 우리는 단일 서버가 얼마나 빨리 과부하될 수 있는지 살펴보았습니다. 더 큰 컴퓨터를 사서(수직 스케일링) 해결할 수는 있지만 결국 물리적 한계에 부딪히게 됩니다—무한히 많은 RAM이나 1,000코어 CPU를 살 수는 없죠. Netflix나 WhatsApp 같은 서비스를 만들려면 horizontal scaling이라는 다른 전략이 필요합니다.
Horizontal Scaling이란?
Horizontal scaling, 혹은 “scale out”은 기존 서버를 업그레이드하는 대신 리소스 풀에 더 많은 머신(인스턴스)을 추가하는 과정입니다. 하나의 거대한 “슈퍼 서버” 대신, 작고 동일한 서버들(S1, S2, S3…)을 병렬로 운영하는 군대를 만드는 것입니다.
- Fault tolerance – 서버가 하나뿐이고 그 서버가 죽으면 애플리케이션도 죽습니다. Horizontal 구성에서는 Server 1이 다운돼도 Server 2‑10이 계속 동작하므로 사용자는 전혀 눈치채지 못합니다.
- Infinite scalability – 단일 마더보드의 크기에 제한받지 않습니다. 더 많은 성능이 필요하면 클라우드에서 인스턴스를 50개 더 띄기만 하면 됩니다.
- Cost efficiency – 고가의 특수 메인프레임 하나보다 여러 대의 “일반” 서버를 운영하는 것이 보통 더 저렴합니다.
새롭게 등장한 도전 과제
시스템 설계에는 언제나 대가가 따릅니다. Horizontal scaling을 하면 두 가지 새로운 과제가 생깁니다:
- The Traffic Cop – 서버 앞에 로드 밸런서를 두어 들어오는 요청을 분산시켜야 합니다. 그래야 어느 하나의 인스턴스가 과부하되지 않죠.
- Data consistency – 여러 서버가 존재하므로, 예를 들어 사용자가 Server A에서 프로필을 업데이트하면 Server B가 즉시 이를 알아야 합니다.
실제 사례: Netflix
Netflix는 하나의 거대한 컴퓨터에서 동작하지 않습니다. 수천 대의 작은 서버 인스턴스를 사용합니다. 새로운 시즌의 Stranger Things가 공개되고 수백만 명이 동시에 “재생” 버튼을 누르면, 시스템은 부하를 감지하고 자동으로 더 많은 horizontal 인스턴스를 추가해 스파이크를 처리합니다. 이것이 분산 아키텍처의 힘입니다.
Horizontal scaling은 신뢰성과 장기적인 성장에 관한 것입니다. 매우 빠른 자동차를 만드는 것과 트럭 함대를 구축하는 것의 차이와 같습니다—하나는 인상적이지만, 다른 하나는 세상을 움직입니다.
다음 이야기
이제 서버 군대가 준비되었습니다. 트래픽을 어디로 보낼지 누가 결정할까요? 다음 에피소드에서는 Horizontal scaling의 가장 핵심 요소인 the load balancer에 대해 깊이 파헤쳐 보겠습니다.