에포크 기반 낙관적 동시성 제어

에포크는 여러 트랜잭션이 조정 비용을 나누게 하지만, 클라이언트 응답은 여전히 전역 커밋을 기다립니다.

커밋 경로에 끼어드는 광역 왕복

여러 리전에 리더를 두는 다중 리더(multi-leader) 데이터베이스는 어느 리전에서든 쓰기를 받아 가용성을 높입니다. 모든 복제본에 걸쳐 ACID를 지키려면 전역 동시성 제어가 필요합니다. 동기화 프로토콜은 대개 여러 차례 통신합니다. 각 통신 라운드는 커밋 경로에 광역 네트워크(Wide-Area Network, WAN) 지연을 더합니다.

기존 해법은 조정을 수행하는 시점에 따라 나뉩니다.

각 설계에는 여전히 조정 단계가 남습니다. Mao 외가 2026-02에 제안한 Minerva는 데이터 전파를 배치하고 Raft로 전역 에포크 경계를 합의합니다. 로컬 실행과 전역 커밋을 분리하되 합의 자체는 유지합니다.

에포크로 묶는 커밋과 복제

낙관적 동시성 제어(Optimistic Concurrency Control, OCC)는 트랜잭션을 락 없이 실행합니다. 커밋 직전에 읽은 데이터가 그사이 바뀌었는지 검증하고, 바뀌었으면 abort시켜 재시도합니다. 지리 분산 환경에서는 이 검증을 어디서 하느냐가 문제가 됩니다. 검증이 원격 리전의 상태를 봐야 한다면 커밋 경로에 다시 왕복이 들어옵니다.

각 복제본은 트랜잭션을 로컬에서 실행하고 결과를 미커밋 임시 상태에 기록합니다. 논문은 15ms 에포크와 4MB 크기 또는 5ms 타임아웃의 전송 배치를 사용합니다. 로컬 실행이 끝나도 클라이언트에 성공을 확정할 수는 없습니다.

Raft는 각 복제본의 배치 로그에서 어느 지점까지 에포크에 포함할지 전역 cut을 합의합니다. 많은 트랜잭션이 이 합의를 공유하므로 건당 조정 비용을 줄일 수 있습니다. 개별 트랜잭션은 복제와 에포크 검증을 거쳐 전역 커밋된 뒤에 응답합니다.

서로 다른 리전이 같은 레코드에 충돌하는 임시 결과를 만들 수 있습니다. 에포크 검증은 전역 커밋 전에 그 충돌을 처리합니다. 재실행 대상은 추측 실행 결과이며, 성공 응답을 보낸 확정 트랜잭션을 사후에 뒤집는 구조는 아닙니다.

sequenceDiagram
    participant C as 클라이언트
    participant R as 로컬 복제본
    participant Q as 복제본과 Raft
    C->>R: 트랜잭션 요청
    R->>R: 임시 상태에 실행
    R->>Q: 배치 복제
    Q->>Q: 에포크 cut 합의
    Q->>R: 검증과 충돌 재실행
    R->>R: 전역 커밋
    R-->>C: 확정 결과 응답

Abort 대신 결정론적 재실행

전통적 OCC라면 여기서 충돌한 트랜잭션을 abort시킵니다. Minerva는 재실행을 택하고, 에포크 커밋 시점에 다섯 단계를 거칩니다.

flowchart TD
    A["에포크 write-set 도착"] --> B["트랜잭션 체인 구성<br/>의존 관계로 이어진 트랜잭션 묶기"]
    B --> C["Staleness 검사<br/>read-set 항목의 epoch id 비교"]
    C --> D["충돌 그래프 구성<br/>정점은 체인, 간선은 쓰기 충돌"]
    D --> E["MWIS 계산<br/>임시 결과를 유지할 체인 선택"]
    E --> F["나머지 체인 재실행<br/>tid와 복제본 우선순위 순서"]

트랜잭션 체인(transaction chain)은 같은 배치 안에서 의존 관계로 연결된 트랜잭션 묶음입니다. Minerva는 개별 트랜잭션이 아닌 체인 단위로 판정합니다. 앞선 트랜잭션이 무효가 되면 뒤따르는 트랜잭션도 무효 후보가 됩니다.

Staleness 검사는 체인의 read-set에 기록된 epoch id가 현재 epoch id보다 오래됐는지 확인합니다. 선행 트랜잭션의 abort 여부도 확인합니다. 판정에는 타임스탬프 대신 epoch id를 사용합니다. 물리 시계를 비교하지 않으므로 Network Time Protocol(NTP) 동기화 오차는 판정에 영향을 주지 않습니다.

충돌 그래프는 체인을 정점으로 놓고 데이터 충돌을 간선으로 놓습니다. 정점 가중치는 체인에 든 트랜잭션 수이며, 최대 가중치 독립 집합(Maximum Weight Independent Set, MWIS)으로 서로 호환되는 체인을 고릅니다.

논문은 정수 선형계획법(Integer Linear Programming, ILP)의 정확해와 greedy 근사해를 비교합니다. 낮은 충돌에서 ILP, 높은 충돌에서 greedy로 자동 전환하는 운영 정책을 확정한 실험은 아닙니다.

독립 집합에 포함되지 않은 체인은 재실행합니다. 정렬 기준은 트랜잭션 id(tid)와 원본 복제본의 정적 우선순위입니다. 모든 복제본이 같은 규칙으로 정렬하므로 추가 합의 없이 같은 순서를 얻습니다.

재실행에는 Calvin 방식의 결정론적 락킹을 사용합니다. 이 시점에는 read/write set을 이미 알고 있으므로 교착이 생기지 않습니다.

Calvin과의 차이는 결정론을 적용하는 범위입니다. Calvin은 실행 전에 모든 트랜잭션의 read/write set을 알아야 하지만, Minerva는 일단 실행한 뒤 충돌이 확인된 트랜잭션만 결정론적 재실행 대상으로 좁힙니다.

충돌률에 따라 이동하는 비용

논문의 Table 1은 500ms 지연 환경의 포화 상태에서 에포크 커밋 시간을 구간별로 나눕니다.

총 시간은 두 경우 모두 약 32.5ms로 거의 같은데, 그 안에서 비용이 이동합니다. 충돌이 드물면 staleness 확인과 그래프 구성(각각 6.84ms, 5.62ms)에 비용이 몰리고 재실행은 1ms 미만입니다. 충돌이 잦으면 재실행이 17.53ms로 전체의 절반을 넘습니다.

충돌이 적을 때 MWIS 최적화는 불필요한 abort를 막습니다. 충돌이 많아지면 최적화보다 재실행에 드는 비용이 커집니다.

재실행이 얼마나 발생하는지는 워크로드의 접근 분포가 정합니다. YCSB-A에 Zipfian 분포를 준 실험(논문 그림 10)에서 계수가 올라갈수록 재실행 비율이 늘어납니다.

실험에서는 Zipfian 계수 1.2를 넘는 구간에 high-contention mode가 관찰됩니다. 이 모드는 로컬 OCC를 우회해 결정론적 실행으로 바로 보냅니다. 약 35%는 실측 재실행 비율이며, 고정 상한이나 보편적인 전환 임계값이 아닙니다.

어떤 워크로드에서 이기는가

논문은 GeoGauss, Ocean Vista, CockroachDB, COCO, CalvinDB를 완전 복제·디스크 영속화 비활성 조건에서 비교합니다. TPC-C에서 Payment와 NewOrder를 사용한 워크로드이며 비교 구현에도 차이가 있습니다. 따라서 결과를 전체 TPC-C나 제품 기본 설정의 성능으로 일반화할 수 없습니다.

단위는 txns/sec이며 논문 그림 6에서 읽은 근사값입니다. 복제본 간 네트워크 지연 200ms에서 Minerva의 처리량은 CalvinDB의 약 3.8배입니다. 표의 값은 실험에서 주입한 네트워크 지연으로, 왕복시간(Round-Trip Time, RTT)과 같은 값이라고 단정하지 않습니다.

복제본 3개에서 15개로 늘리는 확장 실험은 별도의 LAN 환경에서 수행했습니다. 그림 9에서는 복제본 15개에서 약 12,000 txns/s를 기록하고, TPC-C 기반 지연 중앙값은 17ms에서 18ms로 변합니다. 이 지연값은 네트워크 지연 200ms 실험의 응답 시간이 아닙니다.

적용에 유리한 조건은 두 가지입니다. 리전 간 RTT가 커서 커밋별 왕복이 비용을 지배해야 합니다. 충돌률도 재실행 비용을 감당할 수 있는 수준이어야 합니다. 커밋은 에포크 경계에서 확정되므로 개별 트랜잭션의 응답 시간이 최우선인 워크로드에는 맞지 않습니다.

남는 제약

MWIS는 일반적으로 NP-hard이므로 조밀한 충돌 그래프의 정확해를 구하는 비용이 큽니다. high-contention mode로 로컬 추측 실행을 줄일 수 있지만 효과는 워크로드에 달려 있습니다. 한 실험에서 관찰한 Zipfian 계수를 운영 전환 기준으로 그대로 사용할 수는 없습니다.

15ms 에포크는 실험 설정이며 응답 지연 보장값이 아닙니다. 논문은 합의 지연이 에포크 간격을 넘으면 합의가 병목이 된다고 설명합니다. 네트워크 상태와 배치 부하, 클라이언트의 커밋 지연 목표를 함께 보고 길이를 정해야 합니다.

tid와 복제본 우선순위로 정렬하면 NTP에 의존하지 않습니다. 다만 우선순위가 낮은 리전의 트랜잭션은 재실행 순서에서 반복해서 밀릴 수 있습니다. 논문은 이 가능성이 리전 간 공정성 문제로 이어지는지 다루지 않았습니다.

정리

에포크 기반 OCC는 여러 트랜잭션이 복제와 조정 비용을 나누도록 묶습니다. Minerva는 임시 실행 뒤 Raft로 전역 에포크 cut을 합의하고, 충돌을 처리한 다음 커밋을 확정합니다.

논문은 네트워크 지연이 큰 조건에서 처리량 이득을 보였으며, 17~18ms 지연값은 별도의 LAN 실험 결과입니다. 클라이언트는 전역 커밋을 기다리므로 실제 부하에서 배치와 재실행 비용을 함께 평가해야 합니다.