확장을 고려하는 Scale Up 방법들 : (Servers, DBs, LBs, SPOFs)

이 글은 주니어 개발자가 일반적으로 구축하는 단일 서버 아키텍처에서 시작하여, 시니어 엔지니어가 고려하는 확장 가능하고 안정적인 시스템 아키텍처로 발전시키는 과정을 설명한다.

1단계: 시작 (단일 서버)

모든 프로젝트는 보통 하나의 서버로 시작한다. 이 서버는 애플리케이션(백엔드)과 데이터베이스(DB)를 모두 실행한다.

• 문제점: 이 구조는 '단일 장애 지점'(SPOF, Single Point of Failure)이라는 치명적인 약점을 가진다. 서버에 하드웨어 고장이 발생하거나 트래픽이 몰려 다운되면, 서비스 전체가 즉시 중단된다.

2단계: 데이터베이스 분리

가장 먼저 해야 할 일은 애플리케이션 서버와 데이터베이스 서버를 물리적으로 분리하는 것이다.

• 구조: [서버 1: 애플리케이션] <-> [서버 2: 데이터베이스]
• 장점:
  1. 리소스 확보: 앱 서버와 DB 서버가 CPU, 메모리, 디스크 I/O 등의 리소스를 두고 경쟁하지 않는다. 각 서버가 모든 리소스를 독점하므로 성능이 향상된다.
  2. 독립적 확장: 앱 서버의 사양과 DB 서버의 사양을 트래픽 패턴에 맞게 독립적으로 최적화하고 스케일링할 수 있다.
• 남아있는 문제: 여전히 앱 서버와 DB 서버 각각이 SPOF이다. 둘 중 하나라도 다운되면 서비스는 멈춘다.

3단계: 애플리케이션 서버 이중화 및 로드 밸런서 도입

애플리케이션 서버의 SPOF 문제를 해결하기 위해 여러 대의 서버(이중화)를 추가한다.

• 구조: [클라이언트] -> [로드 밸런서 (LB)] -> [앱 서버 1], [앱 서버 2], [앱 서버 3] ... -> [DB 서버]
• 로드 밸런서 (Load Balancer, LB):
  • 모든 클라이언트 요청을 받는 진입점 역할을 한다.
  • 들어온 트래픽을 뒤따르는 여러 대의 앱 서버들에게 "공평하게" 분산시킨다. (예: Round Robin 방식)
  • 특정 서버가 다운되었는지 헬스 체크(Health Check)를 통해 감지하고, 다운된 서버로는 트래픽을 보내지 않는다.
• 장점:
  1. 고가용성 (High Availability): 앱 서버 한 대가 다운되어도, LB가 자동으로 감지하여 다른 정상 서버로만 요청을 보낸다. 서비스 중단이 발생하지 않는다.
  2. 수평적 확장 (Horizontal Scaling): 트래픽이 증가하면 앱 서버를 더 추가하기만 하면 된다. 시스템 전체의 처리량이 증가한다.

     

• 남아있는 문제: 이제 데이터베이스와 로드 밸런서가 새로운 SPOF가 되었다.

 

4단계: 데이터베이스 확장 (Primary-Replica)

애플리케이션은 확장되었지만, 모든 쓰기(Write)와 읽기(Read) 요청이 여전히 단 하나의 DB 서버로 집중된다. 이는 병목 현상(bottleneck)이자 SPOF이다.

데이터베이스 확장은 복잡하며, 일반적으로 'Primary/Replica' (또는 Master/Slave) 구조를 사용한다.

• 구조:
  • Primary DB (Master): 오직 1대만 존재한다. 모든 '쓰기(Write)' 작업(INSERT, UPDATE, DELETE)을 처리한다.
  • Replica DB (Slave): 여러 대 존재할 수 있다. Primary DB의 데이터를 실시간으로 복제(Replication)한다. 모든 '읽기(Read)' 작업(SELECT)을 처리한다.
• 동작 방식:
  1. 애플리케이션은 쓰기 요청은 무조건 Primary DB로 보낸다.
  2. Primary DB는 변경 사항을 Replica DB들에게 전파(복제)한다.
  3. 애플리케이션은 읽기 요청은 여러 Replica DB들로 분산하여 보낸다. (읽기 부하 분산)
• 장점:
  • 읽기/쓰기 분리 (Read/Write Splitting): 대부분의 웹 서비스는 쓰기보다 읽기 작업이 훨씬 많다. 읽기 작업을 Replica로 분산시켜 DB의 전체적인 부하를 크게 낮춘다.
  • 읽기 성능의 수평적 확장: 읽기 트래픽이 많아지면 Replica DB를 더 추가하면 된다.
• 남아있는 문제:
  1. Primary DB의 SPOF: Primary DB가 다운되면, '쓰기' 작업이 불가능해진다. (읽기는 Replica를 통해 가능할 수 있다.)
  2. LB의 SPOF: 로드 밸런서 자체가 다운되면 모든 트래픽의 진입점이 사라져 서비스 전체가 마비된다.

5단계: 다음 단계 (진정한 시니어 레벨)

위 4단계의 아키텍처는 확장 가능한 시스템의 기본 토대이다. 하지만 여전히 남아있는 SPOF(LB와 Primary DB)를 해결해야 한다.

• LB 이중화: LB 역시 여러 대를 클러스터로 구성하여 한 대가 다운되어도 다른 LB가 즉시 작업을 이어받도록 설정한다. (예: VRRP, DNS 기반 분산 등)
• DB 장애 조치 (Failover): Primary DB가 다운되었을 때, Replica DB 중 하나를 즉시 새로운 Primary DB로 승격시키는 자동화된 '장애 조치' 매커니즘을 구현해야 한다.

결론

시니어 엔지니어는 단순히 기능이 동작하게 만드는 것을 넘어, 시스템의 모든 구성 요소에서 발생할 수 있는 '단일 장애 지점(SPOF)'을 식별하고, '이중화(Redundancy)'와 '부하 분산(Load Balancing)'을 통해 이를 제거하려 노력한다. 이러한 수평적 확장 구조는 시스템이 트래픽 증가에 유연하게 대응하고 장애 발생 시에도 중단 없이 서비스를 제공할 수 있게 하는 핵심이다.

 

-----

참조 : https://levelup.gitconnected.com/how-to-scale-like-a-senior-engineer-servers-dbs-lbs-spofs-78a8e624955b

How to Scale Like a Senior Engineer (Servers, DBs, LBs, SPOFs)