왜 지금 Disaggregated 아키텍처인가
클라우드 인프라가 성숙해지면서 "컴퓨트와 스토리지를 하나의 노드에 묶는" 전통적인 설계 방식에 균열이 생기고 있다. 클라우드 환경에서는 컴퓨트 자원과 스토리지 자원의 단가, 확장 속도, 장애 패턴이 서로 다르기 때문에, 이 둘을 물리적으로 분리해 독립적으로 운용하는 Disaggregated 아키텍처가 경제적·운영적으로 훨씬 합리적인 선택이 된다.
예를 들어 트래픽 급증 시 쿼리 처리(컴퓨트) 레이어만 수평 확장하고, 스토리지는 그대로 유지하는 방식이 가능해진다. 반대로 데이터 증가 시 컴퓨트를 건드리지 않고 스토리지만 늘릴 수 있다. 이 탄력적 확장(Elastic Scaling)은 온프레미스 환경에서는 구현 비용이 높았지만, 클라우드의 종량제 모델과 맞물리면서 현실적인 주류 설계로 부상했다.
Paxos가 이미 예고한 분리의 철학
흥미롭게도 Disaggregation의 개념은 완전히 새로운 것이 아니다. 고전적인 Paxos 합의 알고리즘은 Proposer, Acceptor, Learner라는 역할을 명확히 분리한다. 이 역할 분리는 각 컴포넌트가 서로 독립적으로 동작하고 확장될 수 있음을 전제로 한다. 즉, 분산 합의 알고리즘 설계 시점부터 이미 레이어 간 결합을 최소화하는 철학이 내포되어 있었던 셈이다.
현대 클라우드 데이터베이스들은 이 철학을 아키텍처 전반으로 확장했다. Aurora, Spanner 같은 시스템이 스토리지 레이어를 컴퓨트 노드에서 완전히 분리한 것이 대표적인 예다.
네트워크 레이턴시와 공유 메모리의 트레이드오프
Disaggregated 아키텍처가 장점만 있는 것은 아니다. 컴퓨트와 스토리지가 분리되면 매 I/O마다 네트워크를 경유해야 하므로 레이턴시 증가가 필연적으로 따라온다. 이 트레이드오프를 관리하기 위해 여러 접근이 활용된다.
[Query Layer] ---(네트워크)--- [Distributed Storage Layer]
↕ ↕
[로컬 캐시] [복제 + 장애 격리]
- 로컬 버퍼 캐시 강화: 컴퓨트 노드에 인메모리 캐시를 두어 네트워크 왕복을 줄임
- 공유 메모리 진화: 여러 컴퓨트 노드가 동일한 스토리지를 바라보는 구조에서 캐시 일관성 관리가 핵심 과제로 부상
- RDMA 활용: 네트워크 레이턴시 자체를 낮추는 하드웨어 수준 접근도 병행됨
장애 격리(Fault Isolation) 측면에서는 분리 구조가 명확한 이점을 제공한다. 컴퓨트 노드 장애가 스토리지 데이터 손실로 이어지지 않으며, 스토리지 레이어 장애 역시 컴퓨트 레이어의 부분 동작을 보장할 수 있다.
Self-Assembling 데이터베이스: 설계의 다음 단계
Disaggregated 아키텍처의 진화 방향 중 하나는 Self-Assembling 데이터베이스다. 이는 컴퓨트·스토리지·로깅 등 각 컴포넌트가 필요에 따라 동적으로 조합되고, 워크로드 변화에 맞춰 스스로 재구성되는 설계를 의미한다.
// 개념적 예시: 레이어별 독립 스케일링
ComputeCluster.scale(replicas = 10); // 쿼리 급증 대응
StorageLayer.expand(volumeGB = 5000); // 데이터 증가 대응
// 두 레이어는 서로 독립적으로 조작 가능
백엔드 개발자 입장에서 이 패턴이 중요한 이유는, 서비스 설계 시 "데이터베이스를 하나의 덩어리"로 보는 시각에서 벗어나 각 레이어의 특성과 확장 전략을 분리해서 사고해야 한다는 점이다. 관리형 클라우드 DB를 사용하더라도, 내부 구조가 어떻게 분리되어 있고 그것이 레이턴시·가용성·비용에 어떤 영향을 미치는지 이해하는 것이 장애 대응과 성능 최적화에 직결된다.
정리
- 컴퓨트와 스토리지를 분리하는 Disaggregated 아키텍처는 탄력적 확장과 장애 격리를 동시에 실현하는 클라우드 데이터베이스의 주류 설계 방향이다.
- 네트워크 레이턴시 증가는 필연적 트레이드오프이며, 로컬 캐시·RDMA 등으로 보완하는 전략이 함께 요구된다.
- 백엔드 개발자는 사용 중인 DB의 내부 레이어 분리 구조를 이해함으로써 성능 튜닝과 장애 대응 역량을 한 단계 높일 수 있다.