ScyllaDB 2026.2: Trie SSTable 인덱스 기본화·Raft 강한 일관성·DynamoDB 스트림 GA

Cassandra가 물려준 유산과 ScyllaDB가 해결하려는 것

Apache Cassandra는 아마존의 Dynamo 논문(2007)과 Google Bigtable을 결합한 설계다. 고가용성과 수평 확장을 극적으로 단순화했지만, 그 대가로 "결과적 일관성(eventual consistency)"을 기본으로 삼았다. 동일한 키에 두 노드가 서로 다른 값을 가질 수 있고, 클라이언트가 QUORUM을 지정해야 비로소 일관성에 근접할 수 있다.

ScyllaDB는 C++로 Cassandra를 재구현해 처리량을 대폭 높였지만, 초기에는 아키텍처 원칙을 그대로 이어받았다. 2023년부터 ScyllaDB는 체계적으로 이를 바꿔나갔다. 스키마 관리에 Raft를 먼저 적용하고(5.2), 클러스터 토폴로지 변경을 Raft로 직렬화했으며(6.0), 이제 2026.2에서 사용자 데이터 플레인에까지 Raft를 확장하는 실험적 기능을 내놓았다.

같은 2026.2 릴리스에는 읽기 성능을 최대 3배 높이는 Trie 기반 SSTable 인덱스가 기본값으로 승격됐고, DynamoDB 호환 API인 Alternator의 Streams(변경 데이터 캡처) 기능이 GA로 전환됐다.

Trie 기반 SSTable 인덱스: 왜 기존 방식이 느렸나

기존 Index.db + Summary.db 구조

Cassandra에서 물려받은 SSTable 인덱스는 두 파일로 구성된다.

Index.db: 파티션 키 → SSTable 내 바이트 오프셋 매핑. 키 단위 순차 정렬.
Summary.db: Index.db를 일정 간격으로 샘플링한 요약 파일. 메모리에 적재.

포인트 쿼리 흐름:

[클라이언트 요청]
→ Summary.db (메모리) 에서 근접 범위 탐색
→ Index.db (디스크) 에서 선형 스캔 (수백~수천 바이트)
→ Data.db에서 실제 행 읽기

이 구조의 문제는 Index.db 디스크 스캔 단계다. 파티션 키가 긴 경우나 파티션이 많을수록 스캔 범위가 커지고, 캐시 활용이 어렵다. 특히 SSD가 아닌 환경에서 랜덤 I/O 비용이 크다.

Trie 인덱스: 공유 접두사 제거와 캐시 친화적 접근

Trie(접두사 트리, Prefix Tree)는 키를 문자(또는 바이트) 단위로 분해해 공유되는 경로를 하나만 저장하는 자료구조다. user:alice, user:bob, user:charlie라는 키가 있으면 user: 경로를 한 번만 저장한다.

기존 Index.db (선형 정렬)

user:alice → offset 12000

user:bob → offset 14500

user:charlie → offset 17200

…(공유 접두사 중복 저장)

↓ 탐색: 선형 스캔 필요

→

Trie 인덱스 (접두사 공유)

루트 → "user:"

→ "alice" → 12000

→ "bob" → 14500

→ "charlie" → 17200

↓ 탐색: O(key_length), 캐시 재사용 ↑

처리량: +20~230% / 지연: -31~63% (ScyllaDB 공식 벤치마크)

SSTable 인덱스: 기존 선형 스캔 vs Trie 구조 비교

ScyllaDB의 Trie 인덱스는 파티션 인덱스와 클러스터링 키 인덱스 모두에 적용된다. 기존 Summary.db + Index.db 조합 대신 Trie 최적화된 새 파일 포맷(ms 포맷)을 사용한다. 공유 접두사를 단일 경로로 압축하므로 파일 크기가 줄어들고, 디스크 I/O 패턴이 보다 순차적이 되어 캐시 히트율이 높아진다.

ScyllaDB 2025.4에서 실험적으로 도입됐던 이 인덱스 포맷이 2026.2에서 기본값으로 승격됐다.

마이그레이션 시 확인 사항

기존 SSTable은 자동 컴팩션이 발생할 때 새 포맷으로 전환됨 (즉시 변환 아님)
다운그레이드 경로: 구 버전 ScyllaDB로 롤백 시 새 인덱스 포맷을 읽지 못할 수 있으므로 롤백 계획 사전 수립 필요
커스텀 파티셔너 사용 시 Trie 인덱스 동작 검증 권장

Raft 기반 강한 일관성 테이블: Cassandra의 결정적 차이

기존 LWT와 새 Raft 방식의 비교

Cassandra와 ScyllaDB는 강한 일관성을 위해 LWT(Lightweight Transactions) — Paxos 기반 — 을 제공했다. 하지만 Paxos는 하나의 쓰기 작업에 3번의 라운드트립이 필요하다. 쓰기 지연이 크고, 충돌이 발생하면 재시도 비용이 높다.

방식	라운드트립	일관성	성능
최종 일관성 (기본)	1	약함 (stale read 가능)	빠름
QUORUM 읽기/쓰기	1 (복수 노드 확인)	준강함	중간
LWT (Paxos)	3	강함 (linearizable)	느림
Raft 강한 일관성 (2026.2 실험)	1	강함 (linearizable)	LWT보다 빠름

Tablet-per-Raft-Group 설계

ScyllaDB 6.0에서 도입된 Tablet은 기존 vNode와 달리 토큰 링의 고정 파티션이 아니라 동적으로 분할·이동 가능한 데이터 단위다. 핵심 장점은 각 Tablet이 자체 Raft 그룹을 가질 수 있다는 점이다.

강한 일관성 Keyspace (실험적 — 2026.2)

Tablet A

Raft 리더 (Node 1)

팔로워 (Node 2)

팔로워 (Node 3)

→ 단일 라운드트립 커밋

Tablet B

Raft 리더 (Node 2)

팔로워 (Node 1)

팔로워 (Node 3)

→ 독립적 Raft 그룹

Tablet C

Raft 리더 (Node 3)

팔로워 (Node 1)

팔로워 (Node 2)

→ 병렬 처리 가능

각 Tablet의 Raft 리더가 해당 Tablet의 선형화 가능 커밋을 책임짐 (Paxos LWT의 3-라운드트립 제거)

ScyllaDB Raft 강한 일관성: Tablet별 Raft 그룹 아키텍처

이 설계는 기존 Paxos LWT 대비 두 가지 이점을 준다. 첫째, 라운드트립 수가 1로 줄어든다(Raft 리더가 과반 동의만 받으면 커밋). 둘째, Tablet별로 독립적인 Raft 그룹을 갖기 때문에 서로 다른 Tablet에 대한 쓰기가 병렬로 진행된다.

운영자가 알아야 할 제약

강한 일관성 테이블은 실험적 기능이며, 2026.2에서는 다음 조건이 필요하다.

Raft-managed topology가 활성화된 클러스터 (ScyllaDB 6.0 이상)
Tablet 기반 Keyspace에서만 사용 가능 (vNode Keyspace 불가)
CREATE KEYSPACE 시 WITH TABLETS = {'enabled': true} AND CONSISTENCY = 'STRONG' 지정 (구문은 공식 문서 확인)
리더 선출 지연 동안 일시적 쓰기 차단 가능 (Raft 리더 페일오버 시)

Alternator Streams GA: DynamoDB CDC를 ScyllaDB에서 운영하기

Alternator는 ScyllaDB가 DynamoDB API를 호환하는 레이어다. 2026.2에서 DynamoDB Streams에 해당하는 기능이 GA(General Availability)로 전환됐다.

기능 개요

Alternator Streams는 테이블의 항목 수준(item-level) 변경 이벤트를 순서가 보장된 스트림으로 제공한다. DynamoDB Streams와의 호환성 덕분에 기존 DynamoDB Streams 소비자 코드를 최소 변경으로 ScyllaDB에 적용할 수 있다.

이벤트 타입	내용
`INSERT`	신규 항목 삽입
`MODIFY`	기존 항목 업데이트 (이전 이미지/신규 이미지 포함 가능)
`REMOVE`	항목 삭제

사용 시나리오:

CDC 파이프라인: ScyllaDB → Kafka → 데이터 레이크
이벤트 드리븐 아키텍처: 테이블 변경 → Lambda / Worker 트리거
크로스-리전 복제: Alternator Streams를 소스로 사용

기존 DynamoDB Streams와의 차이

DynamoDB AWS에서 ScyllaDB Alternator로 마이그레이션하는 팀이 확인해야 할 사항:

Shard 동작: DynamoDB Streams의 샤드 분리 방식과 내부 구현이 다를 수 있음 — 소비자의 병렬 처리 로직 검증 필요
보존 기간: DynamoDB Streams는 24시간 보존이 기본; Alternator Streams의 보존 설정은 ScyllaDB 설정으로 제어
TTL 기반 삭제: TTL로 만료된 항목이 REMOVE 이벤트를 발생시키는 동작은 공식 문서에서 확인 필요 (Open question)

vNode-to-Tablet 온라인 마이그레이션: 왜 중요한가

기존 ScyllaDB 클러스터(6.0 이전)는 Cassandra의 vNode 방식을 사용한다. Tablet은 더 나은 탄력적 확장과 핫스팟 재분배를 제공하지만, vNode 클러스터를 Tablet으로 전환하려면 기존에는 다운타임이 필요했다.

2026.2는 vNode에서 Tablet으로 무중단 온라인 마이그레이션을 실험적 기능으로 제공한다. 마이그레이션 절차는:

클러스터를 Raft-managed topology 모드로 전환(6.0에서 완료했어야 함)
테이블 단위로 Tablet 포맷으로 전환 시작
내부적으로 Tablet 단위 데이터 이동이 진행되는 동안 읽기/쓰기 계속 서비스
완료 후 Tablet 기반 스케줄러가 핫스팟 재분배 담당

Before (vNode)

토큰 링 고정 파티션

핫스팟 재분배 어려움

Raft 강한 일관성 불가

→

마이그레이션 중 (무중단)

읽기/쓰기 서비스 유지

내부: Tablet 단위 데이터 이동

테이블별 순차 전환

→

After (Tablet)

동적 분할/이동 가능

Raft 강한 일관성 지원

핫스팟 자동 재분배

실험적 기능 — 프로덕션 적용 전 스테이징에서 충분히 검증 필요

vNode → Tablet 온라인 마이그레이션 흐름

마이그레이션 전 확인 사항

현재 vNode 모드 클러스터: Raft-managed topology 활성화 여부 확인 (SELECT * FROM system.scylla_local WHERE key='raft_topology_enabled')
이미 Tablet 기반인 클러스터는 마이그레이션 불필요
실험적 기능이므로 ScyllaDB 엔터프라이즈 지원 계약 확인 후 프로덕션 적용 검토

Connection Storm 완화: P99 지연 5초 → 3.5밀리초

2026.2는 대규모 서비스 재시작 또는 클라이언트 파드 롤아웃 시 발생하는 Connection Storm 문제를 완화하는 메커니즘을 추가했다. ScyllaDB 측 발표에 따르면 Connection Storm 상황에서 P99 지연이 5초에서 3.5밀리초로 개선됐다.

구체적 메커니즘(예: 연결 수락 속도 제한, 큐잉 전략)은 공식 문서에서 상세히 공개하지 않았다. 대규모 쿠버네티스 클러스터에서 파드 롤아웃 시 ScyllaDB가 순간 연결 폭증을 겪는 환경에서 특히 관련성이 높다.

운영 체크리스트

2026.2 업그레이드 시

[ ] Trie SSTable 인덱스 (기본 활성화): 컴팩션 이후 자동 마이그레이션 — 컴팩션 주기와 용량 계획 확인
[ ] 구 버전 롤백 계획: 새 인덱스 포맷이 기록된 후 구 버전으로 롤백 불가 여부 사전 확인
[ ] Alternator Streams: GA 전환 확인, 기존 스트림 소비자 호환성 테스트
[ ] 강한 일관성 테이블: 실험적 기능 — 프로덕션 직접 적용 금지, 스테이징에서만 검증
[ ] vNode-to-Tablet 마이그레이션: 실험적 기능 — 클러스터 전체 테스트 환경 복제 후 검증

성능 모니터링

Trie 인덱스 도입 후 scylla_storage_proxy_coordinator_read_latency P99 개선 여부 측정
Connection storm 지표: scylla_transport_connections 급증 시 P99 지연 관찰
Alternator Streams: 스트림 지연(GetRecords 응답 시간) 및 샤드 균형 모니터링

DynamoDB → ScyllaDB Alternator 마이그레이션 팀

Streams 소비자 코드: DynamoDB Streams SDK가 Alternator Streams와 호환되는지 통합 테스트
이전 이미지(OLD_IMAGE) 포함 스트림 뷰 타입 동작 검증
파티션 키 해시 방식 차이로 인한 쿼리 패턴 검토