114편 · 약 17분

Apache Cassandra 6.0 Accord: 리더 없는 합의 프로토콜로 ACID 트랜잭션을 구현하는 방법

요약

Apache Cassandra 6.0(2026년 5월 1일 alpha1 릴리스)은 CEP-15로 제안된 Accord 프로토콜을 통해 스트릭트 직렬화(Strict Serializable) ACID 트랜잭션을 도입했습니다. Cassandra는 원래 AP(가용성·분할 허용) 시스템으로 설계되어 단일 파티션을 넘나드는 원자적 트랜잭션이 불가능했습니다. Accord는 리더 선출 없이 어떤 노드든 코디네이터가 될 수 있는 합의 구조로, 패스트 패스(Fast Path)에서는 한 번의 왕복 통신만으로 커밋을 완료합니다. 또한 CEP-21 클러스터 메타데이터 서비스(CMS)를 선행 조건으로 함께 도입해 고시프(Gossip) 기반 클러스터 토폴로지 정보를 트랜잭션 로그 기반으로 대체했습니다.

주의: Cassandra 6.0은 alpha1 단계입니다. Accord는 기본 비활성화(opt-in)이며, 혼합 버전 클러스터 중 활성화를 지원하지 않습니다. 프로덕션 도입 전 반드시 릴리스 노트를 확인하십시오.

배경

Cassandra의 원래 트랜잭션 한계

Cassandra는 Dynamo 스타일의 분산 키-값 저장소에서 출발했습니다. 각 파티션은 독립적으로 LWT(Lightweight Transactions, Paxos 기반)를 지원했지만 여러 파티션을 원자적으로 수정하거나 읽는 기능은 없었습니다.

기능	Cassandra 5.x 이하	Cassandra 6.0 Accord
단일 파티션 비교-교체(CAS)	LWT (Paxos)	Accord Fast Path
멀티-파티션 원자 쓰기	불가	Accord 트랜잭션
ACID 격리 수준	없음 (최종적 일관성)	Strict Serializable
리더 선출	LWT에서 불필요; 전용 코디네이터	없음 (임의 노드 코디네이터)
트랜잭션 활성화 여부	—	기본 비활성, opt-in

CEP-21: 클러스터 메타데이터 서비스(CMS)

Accord가 동작하려면 모든 노드가 동일한 클러스터 토폴로지를 보아야 합니다. 기존 Gossip은 수렴 시간이 수 초에 달하고 파티션 분할 시 뷰 불일치가 발생할 수 있습니다.

CMS는 Gossip을 Accord 기반 선형화 트랜잭션 로그로 교체합니다.

노드 추가·제거·교체가 CMS 트랜잭션으로 기록됩니다.
모든 노드가 동일한 에포크(epoch)를 관찰하므로 Accord 코디네이터가 신뢰할 수 있는 토폴로지를 얻습니다.
Cassandra 6.0 업그레이드 시 CMS는 Accord 활성화 여부와 무관하게 자동으로 도입됩니다.

Accord 아키텍처

그림 1. Accord 합의 흐름: 패스트 패스(Fast Path)와 슬로우 패스(Slow Path)

핵심 설계 원칙

리더 없는 합의 (Leaderless Consensus)

전통적인 Raft나 Multi-Paxos에서는 리더 노드가 모든 쓰기 요청을 통과해야 합니다. 리더 장애 시 새 리더를 선출하는 동안 지연이 발생하고, 리더에 부하가 집중됩니다.

Accord는 리더 선출 자체를 하지 않습니다.

어떤 노드든 코디네이터가 될 수 있습니다. 클라이언트는 요청을 직접 받은 노드에서 즉시 트랜잭션을 시작합니다.
코디네이터 장애 시 재시도만 하면 됩니다. 새 코디네이터가 같은 트랜잭션 ID로 이어받습니다.
패스트 패스 일렉토레이트(Fast Path Electorate): 최악의 허용 장애(f개 노드)에서도 패스트 패스가 가능하도록 미리 구성된 서브-쿼럼입니다. 쿼럼 크기는 2f+1 (슬로우 패스)와 3f+1 (패스트 패스) 사이에서 조정됩니다.

혼합 논리 시계(Hybrid Logical Clock, HLC)와 리오더 버퍼

분산 시스템에서 글로벌 순서를 정하려면 시계 동기화가 필요합니다. Accord는 HLC(물리 시간 + 논리 카운터)를 사용합니다.

각 트랜잭션에 (물리 시간, 노드 ID, 카운터) 형태의 타임스탬프를 부여합니다.
레플리카는 리오더 버퍼에 수신 트랜잭션을 타임스탬프 순서대로 쌓습니다.
이미 커밋된 더 오래된 타임스탬프가 도착하더라도 버퍼에서 올바른 위치에 삽입합니다.
리오더 버퍼 덕분에 네트워크 지연으로 순서가 뒤바뀌어 도착한 트랜잭션도 직렬 순서를 유지할 수 있습니다.

리오더 버퍼 예시:
  [t=100, txnA] → 적용
  [t=102, txnB] → 버퍼 대기 (t=101이 아직 없음)
  [t=101, txnC] → 도착 → t=101 적용, t=102 txnB 적용 → 순서 보장

의존성 추적

Accord의 핵심은 의존성(dependency) 그래프입니다.

코디네이터는 PreAccept 단계에서 해당 트랜잭션이 읽거나 쓰는 모든 키를 포함하는 현재 진행 중인 트랜잭션 목록을 레플리카에게 요청합니다.
레플리카는 해당 키에 걸쳐 있는 deps 목록을 반환합니다.
코디네이터는 deps를 병합해 실행 순서를 결정합니다.
직렬화 가능성: 동일 키를 건드리는 트랜잭션들은 deps 그래프에서 연결되어 있어, 총 순서를 결정할 수 있습니다.

CQL 트랜잭션 문법

Cassandra 6.0은 Accord 트랜잭션을 위한 새로운 CQL 블록 문법을 도입했습니다.

-- 계좌 이체 예시 (멀티 파티션 ACID 트랜잭션)
BEGIN TRANSACTION
  LET sender = (SELECT balance FROM accounts WHERE id = 'alice');
  LET receiver = (SELECT balance FROM accounts WHERE id = 'bob');
  SELECT sender.balance, receiver.balance;
  IF sender.balance >= 1000 THEN
    UPDATE accounts SET balance -= 1000 WHERE id = 'alice';
    UPDATE accounts SET balance += 1000 WHERE id = 'bob';
  END IF
COMMIT TRANSACTION;

BEGIN TRANSACTION ... COMMIT TRANSACTION 블록 내부의 모든 읽기·쓰기가 원자적으로 처리됩니다.
LET 바인딩으로 읽기 결과를 조건문에 활용합니다.
IF ... THEN ... 조건부 쓰기가 서버 측에서 평가됩니다.

기존 LWT와의 비교

항목	LWT (Paxos)	Accord
적용 범위	단일 파티션 CAS만	멀티 파티션 트랜잭션
왕복 횟수	4 (Prepare→Promise→Accept→Commit)	패스트 패스 1회, 슬로우 패스 2회
리더 선출	없음 (Paxos 자체)	없음
-	격리 수준	직렬화 가능 (단일 파티션만)	Strict Serializable (멀티 파티션)
기본 활성화 여부	기본 활성	기본 비활성 (6.0 alpha1 기준)

운영 가이드

업그레이드 전 체크리스트

혼합 버전 클러스터 불허: Accord를 활성화하기 전에 모든 노드를 6.0으로 업그레이드해야 합니다. 5.x → 6.0 롤링 업그레이드 중에 Accord를 켜면 안 됩니다.
CMS 자동 도입: 6.0으로 업그레이드하면 CMS가 자동으로 활성화됩니다. Gossip은 하위 호환 기간 동안 병행 실행됩니다.
Accord 별도 활성화: 업그레이드 후 운영 데이터를 확인하고 별도로 Accord를 활성화합니다.

# nodetool로 Accord 활성화 (6.0 기준, 변경될 수 있음)
nodetool enableaccord

# 상태 확인
nodetool accordstatus

모니터링 지표

지표	의미
`accord.fast_path_rate`	패스트 패스 비율. 낮으면 경합이 많음
`accord.slow_path_latency_p99`	슬로우 패스 p99 지연. 네트워크 파티션 지표
`accord.dependency_conflict_rate`	deps 충돌 비율. 높으면 핫 파티션 가능성
`cms.epoch_lag`	CMS 에포크 뒤처짐. 0이 정상

알려진 제한 사항 (6.0 alpha1 기준)

FP8·FP16 등 비표준 타입 컬럼에서 Accord 트랜잭션이 테스트되지 않았습니다.
카운터(counter) 컬럼은 Accord 트랜잭션 대상에서 제외됩니다.
시계열 워크로드처럼 타임스탬프 단조 증가가 보장되지 않는 패턴에서 리오더 버퍼 메모리 압력이 발생할 수 있습니다.

Open question: GA(정식 릴리스) 일정 및 프로덕션 권장 설정은 확정되지 않았습니다. alpha1 릴리스 노트와 Apache Cassandra 개발자 메일링 리스트를 모니터링하십시오.

요점 정리

Cassandra 6.0은 CEP-15(Accord)로 최초의 멀티 파티션 ACID 트랜잭션을 지원하며, 격리 수준은 Strict Serializable이다.
Accord는 리더 선출 없이 임의 노드가 코디네이터 역할을 맡아 경합 없을 때 1회 왕복 통신(Fast Path)으로 커밋을 완료한다.
혼합 논리 시계(HLC)와 리오더 버퍼가 글로벌 커밋 순서를 보장한다.
CEP-21(CMS)이 Gossip 기반 클러스터 메타데이터를 트랜잭션 로그로 대체해 Accord의 선행 조건이 된다.
6.0 alpha1에서 Accord는 기본 비활성(opt-in)이며, 혼합 버전 클러스터에서 활성화를 지원하지 않는다.
BEGIN TRANSACTION ... COMMIT TRANSACTION CQL 블록으로 멀티 파티션 원자 읽기·쓰기가 가능해졌다.

References

Apache Cassandra 6.0 Release Announcement (2026-05-01): https://cassandra.apache.org/news/2026/05/01/cassandra-6-0-alpha1.html
CEP-15: Accord Consensus Protocol Proposal: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Transactions
CEP-21: Cluster Metadata Service (CMS): https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Cluster+Metadata+Service
Accord: A Distributed Transaction Protocol (Blake & Leclercq, 2023): https://dl.acm.org/doi/10.1145/3547326
Apache Cassandra Improvement Proposals (CEPs): https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Improvement+Proposals
Instaclustr: What's New in Cassandra 6.0: https://www.instaclustr.com/blog/apache-cassandra-6-0-whats-new/
Hybrid Logical Clocks (HLC) — Kulkarni et al.: https://cse.buffalo.edu/tech-reports/2014-04.pdf