LLM WikiAccess-protected knowledge portal

WIKI

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

요약 Apache Cassandra 6.0 2026년 5월 1일 alpha1 릴리스 은 CEP 15로 제안된 Accord 프로토콜을 통해 스트릭트 직렬화 Strict Serializable ACID 트랜잭션을 도입했습니다. Cassandra는 원래 AP 가용성·분할 허용 시스템으로 설계되어 단일 파티션을 넘나드는 원자적 트랜잭션이 불가능했습니다. Accord는 리더 선출 없이 어떤 노드든 코디네이터가 될 수 있는 합의 구조로,

경로human/study/content/database-frontier/114-cassandra-6-accord-acid-transactions-leaderless-consensus.md
카테고리Study
태그#accord #acid #consensus #leaderless #mysql #study #transactions

요약

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 기반 선형화 트랜잭션 로그로 교체합니다.

Accord 아키텍처

Accord 합의 흐름 클라이언트 코디네이터 노드 (임의의 모든 노드 가능) 레플리카 A 레플리카 B 레플리카 C CMS (CEP-21) 클러스터 토폴로지 패스트 패스 (Fast Path) — 경합 없을 때 1 왕복 통신 ① 코디네이터 → 레플리카: PreAccept(txn_id, deps, HLC 타임스탬프) ② 레플리카 → 코디네이터: AcceptOK(txn_id) — 과반 응답 시 커밋 결정 ③ 코디네이터 → 레플리카: Commit(txn_id) — 레플리카가 실행 후 응답 → 레플리카가 커밋 순서에 따라 적용 (리오더 버퍼 활용) 슬로우 패스 (Slow Path) — 경합 또는 장애 시 Paxos 형태 추가 단계 ① Propose 단계 추가: 코디네이터가 충돌 트랜잭션의 순서를 조율 ② 재배열 가능한 트랜잭션은 리오더 버퍼에서 최종 순서 결정 ③ 확정 후 Commit → Apply — 직렬화 가능성을 보장하며 커밋 (슬로우 패스는 경합 · 네트워크 파티션 · 일부 장애 시에만 발동) 토폴로지 조회
그림 1. Accord 합의 흐름: 패스트 패스(Fast Path)와 슬로우 패스(Slow Path)

핵심 설계 원칙

리더 없는 합의 (Leaderless Consensus)

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

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

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

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

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

의존성 추적

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

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;

기존 LWT와의 비교

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

운영 가이드

업그레이드 전 체크리스트

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

# 상태 확인
nodetool accordstatus

모니터링 지표

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

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

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

요점 정리

References