분산 데이터베이스의 파티셔닝과 샤딩 설계
Cassandra, DynamoDB, Spanner의 파티셔닝과 샤딩 방식, 일관성 모델, 키 설계와 운영 고려사항을 비교한다.
2026-08-14 · 최초 발행 2025-10-14
파티션 키가 분산 데이터베이스의 동작을 결정한다
분산 데이터베이스에서 파티셔닝과 샤딩은 하나의 논리 테이블 또는 키 공간을 여러 물리 파티션에 배치해 수평 확장을 구현하는 방식이다. 일관된 해시(Consistent Hashing)나 키 범위 분할(Key-range Split)을 사용할 수 있으며, 복제와는 별도의 계층에서 고가용성과 읽기 스케일아웃에 관여한다.
선택의 기준은 단순히 저장소 유형이 아니다. 데이터 모델, 읽기와 쓰기 경로, 요구하는 일관성 수준, 장애 상황에서 감수할 수 있는 지연과 가용성의 균형이 함께 설계 대상이다.
일관성 모델은 최종적 일관성(Eventual), 가변 일관성(Tunable), 강한 일관성(Strong)으로 구분된다. 합의 방식인 Paxos/Raft와 TrueTime 같은 타임소스, 쓰기 처리 경로는 레이턴시와 가용성의 트레이드오프를 만든다.
Cassandra는 와이드-컬럼 모델에서 파티션 키 중심으로 읽기 패턴을 설계한다. DynamoDB는 파티션 키와 정렬 키를 사용하는 완전관리형 키-값/문서 스토어이며, Spanner는 SQL·스키마·트랜잭션을 제공하는 분산 RDBMS로 전역 동기 복제를 사용한다.
Cassandra는 토큰 링과 일관성 레벨을 함께 다룬다
Cassandra에서는 노드가 토큰 범위를 맡고 파티션 키의 해시값으로 데이터를 배치한다. vNode(가상 노드)는 토폴로지가 변할 때 리밸런싱 비용을 완화한다.
Coordinator 노드는 복제 팩터(RF)에 해당하는 노드로 쓰기를 병렬 전송하며, 데이터는 Commit Log → Memtable → SSTable 경로를 따른다. ONE, QUORUM, ALL 같은 일관성 레벨을 선택해 지연과 내구성의 균형을 조정한다.
장애 이후에는 Hinted Handoff, Read Repair, Anti-Entropy(Repair)를 통해 최종적 일관성 상태로 수렴한다. 토폴로지 변경 시 리밸런싱도 자동화 대상이다.
DynamoDB는 자동 샤딩 아래의 키 분포를 설계한다
DynamoDB는 파티션 키 해시를 기준으로 요청을 파티션에 라우팅한다. 용량 초과 시 자동 분할과 병합이 이뤄지고, Adaptive capacity는 핫 파티션을 완화한다.
기본 읽기 모델은 Eventually이며, Strongly consistent read 옵션도 제공한다. LSI와 GSI로 조회 패턴을 확장할 수 있지만 GSI의 쓰기 비용은 별도로 고려해야 한다.
운영 측면에서는 온디맨드와 프로비저닝 방식의 서버리스 과금 모델을 제공하고, 멀티-AZ 복제와 백업, Point-in-time Recovery를 내장한다.
Spanner는 전역 트랜잭션과 데이터 지역성을 맞춘다
Spanner는 TrueTime API의 글로벌 타임 바운드와 Paxos 합의를 결합한다. 2PC와 동기 복제를 통해 트랜잭션 원자성을 제공한다.
데이터는 정렬된 키 범위로 분할되고, 리더 배치를 통해 지연을 조정한다. 따라서 데이터 지역성을 고려한 파티셔닝 계획이 필요하다.
RDBMS 친화적인 DDL과 쿼리, 세컨더리 인덱스를 제공하며 리전 또는 멀티리전 인스턴스 구성으로 SLA를 높일 수 있다. 다만 전역 강한 일관성이 필요한 워크로드에서는 리전과 키 범위 설계의 복잡성이 남는다.
요청은 시스템별 일관성 경로를 거쳐 응답한다
Cassandra는 일관성 레벨을 충족하지 못하면 Unavailable 예외가 발생할 수 있다. 재시도와 백오프, 다른 Coordinator로의 전환을 고려하고 Read Repair로 사후 수렴한다.
DynamoDB에서는 프로비저닝 초과 시 Throttling이 발생할 수 있다. 지수 백오프와 재시도를 적용하고, 파티션 키 재분포가 필요한지 검토한다.
Spanner는 트랜잭션 충돌 시 Abort될 수 있어 지수 백오프 후 재시도가 필요하다. TrueTime 대기(commit wait)는 직렬화 보장에 사용된다.
같은 분산 구조라도 운영 성격은 다르다
| 지표 | Cassandra | DynamoDB | Spanner |
|---|---|---|---|
| 성능 | 쓰기 지향, 고속 Append 경로 | 예측가능한 지연, 파티션 단위 탄력 처리 | 강한 일관 + 글로벌 합의로 지연 증가, 일관 쿼리 우수 |
| 확장성 | 선형 확장, vNode로 리밸런스 용이 | 완전관리형 무중단 확장 | 노드/리전 수평 확장, 스플릿 자동화 |
| 일관성 | Tunable(ONE~ALL), 기본 최종적 일관 | 옵션(Strong/Eventually) | 전역 강한 일관성(Serializable) |
| 안정성 | RF로 장애 허용, 수리 작업 필요 | 멀티-AZ 내장 복제, 자동 백업 | Paxos 동기 복제, 멀티리전 SLA |
| 운영 편의 | 자가 운영/튜닝 필요 | 서버리스/완전관리형 | 관리형이지만 스키마/리전 설계 복잡성 존재 |
워크로드가 제품 선택의 기준이 된다
시계열, 로그, IoT 텔레메트리처럼 쓰기량이 큰 데이터에는 Cassandra가 적합하다. 순차적인 TTL과 컴팩션 전략으로 비용 효율을 확보하고, 파티션 키에는 디바이스ID와 시간 버킷을 결합하는 패턴을 적용한다.
전자상거래나 게임 세션 스토어처럼 단일 키 접근이 많고 트래픽 변동이 큰 워크로드는 DynamoDB와 맞는다. 온디맨드 모드와 GSI를 사용해 여러 조회 패턴을 지원할 수 있다.
금융 원장, 전역 카탈로그, Cross-region OLTP처럼 여러 리전에 걸친 강한 일관성과 트랜잭션이 필요한 경우에는 Spanner가 대상이 된다. 이때 키 설계는 데이터 지역성을 반영해 지연을 줄여야 한다.
키 설계부터 관측 정책까지 연결한다
워크로드 프로파일에는 QPS, 읽기:쓰기 비율, 키 분포, p95/p99 SLA, 핫키 존재 여부를 포함한다. 이를 바탕으로 균등 해시 키를 쓸지, 범위 키와 버킷팅을 조합할지 정하고 보조 인덱스의 필요성을 검토한다.
일관성과 가용성 정책도 저장소별로 다르게 정한다. Cassandra에서는 Consistency Level, RF, 리드와 라이트 경로를 결정한다. DynamoDB에서는 Strong과 Eventually, GSI/LSI의 비용·지연 영향을 평가한다. Spanner에서는 리전 토폴로지, 리더 배치, 트랜잭션 경계를 설계한다.
스토리지 증가율과 쓰기증폭, 컴팩션, 프로비저닝 또는 온디맨드 모델을 비용 계획에 반영한다. 배포와 마이그레이션의 롤링 절차, PITR·스냅샷, 스키마 변경의 점진적 롤아웃도 준비한다. 운영 지표는 CPU, 스토리지, Compaction, Throttle, Abort를 포함하며 재시도, 백오프, 서킷브레이커 정책과 연결한다.
파티션 키와 스키마를 코드로 확인한다
전제: 테스트 환경 기준, 실제 운영은 버전/리전/한도 최신 정보 확인 필요.
Cassandra 4.x, cqlsh:
-- 파티션 키와 클러스터링 키 분리 설계
CREATE KEYSPACE demo WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '3'};
CREATE TABLE demo.events (
device_id text,
bucket_day date,
ts timestamp,
payload text,
PRIMARY KEY ((device_id, bucket_day), ts)
) WITH CLUSTERING ORDER BY (ts DESC);DynamoDB, AWS CLI v2:
aws dynamodb create-table \
--table-name Orders \
--attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S \
--key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE \
--billing-mode PAY_PER_REQUEST
# 파티션 키 설계 예: pk=ORDER#<region>#<hash(userId)> , sk=TS#<epoch>Cloud Spanner, DDL:
CREATE TABLE Customers (
CustomerId STRING(36) NOT NULL,
Region STRING(16),
Name STRING(128),
) PRIMARY KEY (CustomerId);
CREATE TABLE Orders (
OrderId STRING(36) NOT NULL,
CustomerId STRING(36) NOT NULL,
CreatedAt TIMESTAMP OPTIONS (allow_commit_timestamp=true),
) PRIMARY KEY (CustomerId, OrderId),
INTERLEAVE IN PARENT Customers ON DELETE CASCADE; -- 지역성 향상분산 배치의 효과와 남는 운영 과제
균등한 파티션 설계는 수평 확장의 선형성을 확보하고, 핫 파티션을 제거해 p99 지연이 급증하는 상황을 막는다. 요구 수준에 맞춘 일관성 정책은 데이터 무결성을 강화하며, Spanner는 전역 직렬화를 보장한다.
자동화된 복제, 백업, 리밸런스를 도입하면 장애 복구 RTO/RPO를 단축할 수 있다. 관리형 서비스를 선택하면 운영 인건비도 줄일 수 있다. 액세스 패턴에 맞는 설계와 인덱스 최소화는 저장·요청 비용을 낮추고, 온디맨드와 프로비저닝을 혼합하면 피크 비용을 제어할 수 있다.