Medium에 작성했던 The Scale Cube: 세 가지 관점의 규모 확장성 모델을 블로그로 옮겨 정리한 글이다.
Scale Cube는 애플리케이션을 확장하는 방법을 세 가지 축으로 나누어 설명하는 모델이다. 시스템이 커질 때 단순히 서버 사양을 올리는 것만 생각하기 쉽지만, 실제로는 복제, 기능 분리, 데이터 분리처럼 서로 다른 방향의 확장 전략이 존재한다.
Scale Cube에서는 이를 X축, Y축, Z축 확장으로 설명한다.
X축 확장
X축 확장은 같은 애플리케이션 인스턴스를 여러 개 띄우고, 로드밸런서를 통해 요청을 분산하는 방식이다.
가장 익숙한 수평 확장 방식이다. 하나의 애플리케이션 서버가 모든 기능을 가지고 있고, 같은 역할을 하는 서버를 여러 대 두어 전체 처리량을 늘린다. 서버가 N대라면 이상적으로 각 서버는 전체 요청의 1/N 정도를 나누어 처리하게 된다.
이 방식은 구조가 단순하고 적용하기 쉽다. 특히 모놀리식 애플리케이션에서 먼저 고려하기 좋은 확장 방식이다.
다만 모든 인스턴스가 같은 기능과 같은 데이터 접근 책임을 가진다. 따라서 애플리케이션 자체의 복잡도를 낮춰주지는 못하고, 캐시나 데이터 접근 패턴에 따라 전체 메모리 사용량이 늘어날 수도 있다.
Y축 확장
Y축 확장은 애플리케이션을 기능 단위로 나누는 방식이다.
하나의 큰 애플리케이션을 여러 서비스로 분리하고, 각 서비스가 특정 책임을 맡도록 만든다. 예를 들어 주문, 결제, 회원, 알림처럼 도메인이나 기능 경계를 기준으로 나눌 수 있다.
서비스를 나누는 방식은 크게 두 가지 관점으로 생각할 수 있다.
첫 번째는 동사를 기준으로 나누는 방식이다. 예를 들어 결제하기, 체크아웃하기처럼 사용자 행동이나 유스케이스 중심으로 서비스를 정의할 수 있다.
두 번째는 명사를 기준으로 나누는 방식이다. 회원, 상품, 주문처럼 주요 엔티티를 중심으로 책임을 분리하는 방법이다.
Y축 확장은 기능별 독립성을 높이고, 팀이나 배포 단위를 나누기 좋다. 하지만 서비스 간 통신, 데이터 일관성, 운영 복잡도도 함께 증가한다.
Z축 확장
Z축 확장은 같은 기능을 가진 서버를 여러 개 두되, 각 서버가 데이터의 일부만 책임지도록 나누는 방식이다.
X축 확장이 모든 서버가 같은 데이터를 볼 수 있다고 가정한다면, Z축 확장은 데이터 자체를 분할한다. 샤딩이나 파티셔닝이 대표적인 예다. 요청이 들어오면 라우터나 애플리케이션 로직이 어떤 데이터가 어느 서버에 있는지 판단해 적절한 곳으로 보낸다.
Z축 확장은 데이터 처리량을 늘리고 장애 범위를 줄이는 데 도움이 된다. 특정 데이터 그룹에 문제가 생겨도 전체 시스템으로 번지는 영향을 줄일 수 있다.
하지만 데이터가 나뉘면 조회, 집계, 트랜잭션, 운영 난이도가 올라간다. 그래서 단순한 트래픽 증가만으로 바로 선택하기보다는 데이터 규모와 접근 패턴을 함께 보고 판단해야 한다.
정리
Scale Cube는 확장을 한 방향으로만 보지 않게 해준다.
X축은 같은 것을 복제해 처리량을 늘리는 방식이고, Y축은 기능 책임을 나누는 방식이며, Z축은 데이터 책임을 나누는 방식이다.
실제 시스템에서는 세 가지 중 하나만 고르는 것이 아니라, 현재 병목과 조직 상황에 맞게 조합한다. 트래픽이 늘어서 서버 처리량이 부족한지, 기능 복잡도가 커져서 분리가 필요한지, 데이터 규모가 커져 분산이 필요한지를 먼저 구분하는 것이 중요하다.