시스템 규모 확장 전략: 스케일 업부터 샤딩까지

시스템 규모 확장(Scaling)은 사용자와 트래픽이 늘어날 때 서비스가 성능과 안정성을 유지하도록 처리 용량을 키우는 설계 전략이다. 확장 방향은 서버 한 대의 사양을 높이는 스케일 업(Scale Up)과 서버 수를 늘리는 스케일 아웃(Scale Out)으로 나뉘며, 스케일 아웃을 제대로 하려면 무상태 설계, 로드 밸런싱, 캐시, 데이터베이스 분산까지 함께 고려해야 한다. 시스템 설계 면접의 거의 모든 문제가 이 확장 전략을 뼈대로 삼는다.

스케일 업과 스케일 아웃

스케일 업은 수직 확장(Vertical Scaling)이라고도 하며, 기존 서버의 CPU, 메모리, 디스크를 더 좋은 것으로 교체하는 방식이다. 애플리케이션 구조를 바꿀 필요가 없어 가장 간단하지만, 하드웨어 성능에는 물리적 상한이 있고 사양이 올라갈수록 비용이 비선형적으로 커진다. 무엇보다 서버가 한 대뿐이므로 그 서버가 죽으면 서비스 전체가 멈추는 단일 장애점(Single Point of Failure)이 된다.

스케일 아웃은 수평 확장(Horizontal Scaling)으로, 비슷한 사양의 서버를 여러 대 추가해 부하를 나눠 받는 방식이다. 이론상 서버를 계속 추가할 수 있어 확장 한계가 훨씬 높고, 일부 서버가 죽어도 나머지가 트래픽을 받아내므로 가용성(availability)이 좋아진다. 대신 여러 서버가 하나의 서비스처럼 동작해야 하므로 설계 복잡도가 올라간다.

구분	스케일 업	스케일 아웃
방법	서버 사양 향상	서버 대수 증가
확장 한계	하드웨어 상한 존재	이론상 거의 무제한
장애 내성	단일 장애점	일부 장애 시에도 서비스 유지
설계 난이도	낮음	무상태 설계, 분산 처리 필요
적합한 대상	관계형 데이터베이스, 초기 서비스	웹, API 서버, 대규모 트래픽

무상태 설계가 전제 조건인 이유

스케일 아웃이 성립하려면 어떤 서버가 요청을 받아도 같은 결과를 내야 한다. 이를 위해 서버는 요청 처리에 필요한 상태를 자기 메모리에 담아 두지 않는 무상태(Stateless) 구조여야 한다. 대표적인 문제가 로그인 세션이다. 세션을 서버 메모리에 저장하면 사용자가 다음 요청에서 다른 서버로 연결될 때 로그인이 풀려 버린다.

해결책은 세 가지가 있다. 로드 밸런서가 같은 사용자를 항상 같은 서버로 보내는 고정 세션(Sticky Session)은 구현이 쉽지만 부하가 고르게 분산되지 않고 서버 장애 시 세션이 사라진다. 세션 저장소를 레디스(Redis) 같은 외부 스토리지로 분리하면 모든 서버가 세션을 공유할 수 있어 가장 널리 쓰인다. 아예 서버에 상태를 두지 않는 JWT(JSON Web Token) 같은 토큰 방식은 토큰 자체에 인증 정보를 담아 검증만 하면 되므로 확장에 가장 유리하다.

로드 밸런싱과 자동 확장

서버가 여러 대가 되면 트래픽을 나눠 주는 로드 밸런서(Load Balancer)가 필요하다. 로드 밸런서는 라운드 로빈(Round Robin), 최소 연결(Least Connections) 같은 알고리즘으로 요청을 분배하고, 주기적인 헬스 체크(health check)로 비정상 서버를 분배 대상에서 자동 제외한다. 덕분에 서버 추가와 제거가 사용자 모르게 이루어진다.

여기에 오토 스케일링(Auto Scaling)을 결합하면 CPU 사용률이나 요청 수 같은 지표를 기준으로 서버 대수를 자동 조절할 수 있다. 트래픽이 몰리는 시간대에는 서버를 늘리고 새벽에는 줄여서 비용과 성능의 균형을 맞춘다. 이 자동화가 매끄럽게 동작하려면 앞서 말한 무상태 설계가 반드시 전제되어야 한다.