CockroachDB 26.x: Leader Lease·값 분리(Value Separation)·FIPS 140-3으로 분산 SQL의 운영 경계를 다시 그은 방식

왜 지금 봐야 하나

CockroachDB v26.2가 2026년 5월 22일에 공개됐다. v26.1이 2026년 2월 18일 출시됐으므로, 두 릴리스를 합치면 지난 5개월 동안 분산 SQL 운영에서 가장 중요한 세 문제를 한꺼번에 해결했다.

쓰기 증폭(Write Amplification): 값 분리(Value Separation)가 v25.4에서 GA되고 v26.x에서 기본값이 됐다. Pebble 스토리지 엔진에서 블롭 파일을 이용해 256 바이트 이상의 값을 키에서 분리해 쓰기 증폭을 최대 50% 줄인다.
합의 레이어 스케일: Leader Lease가 v25.2에서 도입되고 SIGMOD 2026에서 발표된 논문으로 검증됐다. Raft 리더가 Lease도 동시에 보유해, 리스 협상의 추가 라운드트립을 제거하고 장애 복구 속도를 높인다.
엔터프라이즈 보안·규정 준수: v26.1에서 FIPS 140-3 네이티브 지원(Go 1.24 암호화), JWT/OIDC SSO 역할 자동 동기화, CDC Protobuf 직렬화가 한 번에 들어왔다.

CockroachDB를 이미 운영 중이거나, PostgreSQL 호환 분산 SQL을 도입 검토 중인 팀이라면 이 세 변화가 아키텍처 결정에 직접 영향을 준다.

v26.1은 90일 창(2026-04-22) 밖인 2026-02-18 출시였으나 180일 창 이내다. v26.2는 2026-05-22 출시로 90일 창 이내다. 이 장은 두 릴리스를 함께 다루며, v26.2를 주 대상으로 한다.

CockroachDB 핵심 아키텍처 한눈에 보기

계층	구성 요소	역할
SQL 레이어	DistSQL / Vectorized Engine	SQL → KV 연산 변환, 분산 실행 계획
KV 레이어	Range, Raft Group, Leaseholder	데이터를 레인지(~128MB)로 분할, Raft로 복제
스토리지 레이어	Pebble (LSM-tree 기반)	로컬 KV 저장, 압축, 값 분리(blob files)

CockroachDB 아키텍처와 v26.x 주요 변화

CockroachDB v26.x: 레인지·Raft·Pebble 계층과 Leader Lease·값 분리 동작

1. Leader Lease: Raft 합의와 읽기 서빙을 통합한 이유

기존 구조의 문제

CockroachDB는 데이터를 레인지(Range)라는 단위로 분할한다. 기본 크기는 약 128MB며, 각 레인지는 독립적인 Raft 복제 그룹으로 관리된다. 읽기와 쓰기는 Leaseholder라고 불리는 특정 복제본이 처리한다.

문제는 Raft 리더와 Leaseholder가 반드시 같은 노드일 필요가 없다는 점이었다. Raft 리더가 노드 A에 있고 Leaseholder가 노드 B에 있으면, 쓰기 시 리더가 제안(Propose)한 후 Leaseholder에게 별도로 전달해야 했다. 또한 Lease 갱신 자체가 Raft 로그 항목으로 처리되면서 수십만 개 레인지를 가진 클러스터에서 CPU를 크게 소모했다.

Leader Lease의 동작 원리

v25.2에서 도입된 Leader Lease는 단순한 원칙을 적용한다. Raft 리더가 항상 해당 레인지의 Leaseholder가 된다.

이 변화의 효과는 세 가지다.

쓰기 경로 단순화: 리더가 제안과 서빙을 모두 처리한다. Leaseholder 에게 추가 라운드트립이 없다.
장애 복구 가속: 리더 장애 시 Raft 선출과 동시에 새 리더가 Lease도 인수한다. 기존에는 Lease 만료와 갱신 대기 시간이 따로 존재했다.
CPU 절감: 수십만 개 레인지의 Lease 갱신을 Raft 로그 항목으로 별도 처리하지 않아도 된다.

단, Lease 전송(transfer)이 필요한 경우는 있다. 특정 레인지를 가까운 리전에서 더 효율적으로 서빙해야 할 때다. 이 경우 leader preference 설정으로 제어한다.

-- 레인지의 리더 선호 노드 확인
SHOW RANGES FROM TABLE orders WITH DETAILS;

-- 특정 존에 리더를 배치
ALTER TABLE orders CONFIGURE ZONE USING
  lease_preferences = '[[+zone=us-east1]]';

SIGMOD 2026 논문

Leader Lease의 설계는 2026년 SIGMOD에서 발표된 "Scalable Leader Leases For Multi Consensus Groups in CockroachDB"에 상세히 기술됐다. 핵심 기여는 수십만 개의 Raft 그룹을 가진 클러스터에서 리스 관리가 전체 CPU의 병목이 되는 문제를 "Leader = Leaseholder" 불변 조건 하나로 해결했다는 점이다. 불변 조건 유지를 위한 Raft 프로토콜 수정과 리더십 안정 메커니즘이 포함됐다.

2. 값 분리(Value Separation): Pebble 스토리지 최적화

LSM-tree의 쓰기 증폭 문제

Pebble은 RocksDB에서 영감을 받은 LSM-tree(Log-Structured Merge-tree) 기반 스토리지 엔진이다. LSM-tree는 쓰기를 빠르게 처리하지만 컴팩션(Compaction) 이라는 배경 작업에서 데이터를 여러 번 재기록한다. 이를 쓰기 증폭(Write Amplification)이라 한다.

문제는 레인지의 값이 크면 클수록 컴팩션이 더 많은 데이터를 재기록한다는 점이다. 예를 들어 각 키에 1KB 이상의 JSON 값이 붙어 있으면, 압축(L0→L6) 과정에서 이 값들이 반복적으로 읽히고 다시 쓰인다. 이는 디스크 I/O를 소진하고 지연 스파이크를 유발한다.

blob 파일로 분리하는 원리

값 분리는 LevelDB/RocksDB 계열에서 WiscKey(2016)가 제안한 아이디어를 Pebble에 맞게 구현한 것이다. 핵심은 다음과 같다.

256 바이트 이상의 값은 SST 파일에 인라인으로 저장하지 않고 별도의 blob 파일에 저장한다.
SST 파일의 키 항목에는 blob 파일 내 위치를 가리키는 포인터만 남는다.
컴팩션은 SST 파일 안의 키만 재정렬한다. blob 파일은 건드리지 않는다.
blob 파일은 별도의 가비지 컬렉션 프로세스가 관리해 참조되지 않는 값을 회수한다.

기존 구조 (값 인라인):
  SST L4: [key1 → value(2KB)], [key2 → value(3KB)], ...
  컴팩션: 키와 값을 모두 재기록 → WA 높음

값 분리 구조:
  SST L4: [key1 → blob_ref], [key2 → blob_ref], ...
  blob 파일: [value(2KB)], [value(3KB)], ...
  컴팩션: 키와 blob_ref만 재기록 → WA 낮음

실측 효과

Cockroach Labs의 내부 벤치마크에 따르면, 쓰기 집약적이고 값이 넓은(wide-row) 워크로드에서 처리량이 최대 50% 향상됐다. 읽기 성능은 거의 영향을 받지 않았다. blob 파일은 키 조회 시 추가 I/O가 필요하지만, 대부분의 경우 OS 페이지 캐시가 이를 흡수한다.

반면, 값이 작고(256B 미만) 읽기가 많은 워크로드에서는 효과가 미미하다. 값 분리는 쓰기 집약적이고 값이 큰 컬럼이 많은 테이블에서 가장 효과가 크다.

v26.x 기준으로 값 분리는 기본값으로 켜져 있다. 필요시 클러스터 설정으로 제어할 수 있다.

-- 값 분리 임계 크기 확인 (기본값: 256 bytes)
SHOW CLUSTER SETTING storage.value_separation.minimum_size;

-- 값 분리 비활성화 (비추천)
SET CLUSTER SETTING storage.value_separation.enabled = false;

3. v26.1 보안·규정 준수: FIPS 140-3, JWT/OIDC, CDC Protobuf

v26.1은 2026년 2월 출시됐다. 핵심은 엔터프라이즈 보안 요건 세 가지를 공식 지원한 것이다.

FIPS 140-3 네이티브

기존 FIPS 지원은 OpenSSL BoringCrypto를 외부 라이브러리로 연결하는 방식이었다. 성능 오버헤드와 빌드 복잡성이 있었다. v26.1은 Go 1.24의 crypto/fips140 패키지를 사용해 FIPS 140-3을 완전히 네이티브로 구현했다.

이 변화의 운영 의미는 크다. 미국 연방 규정(NIST 2026년 9월 기한)이나 금융권 PCI DSS가 FIPS 140-3을 요구하는 경우, 외부 라이브러리 없이 표준 CockroachDB 바이너리 하나로 컴플라이언스를 충족한다.

# FIPS 모드 확인
cockroach version --details | grep -i fips

JWT/OIDC SSO 역할 자동 동기화

기존에는 OIDC로 로그인한 사용자에게 DB 역할을 수동으로 부여해야 했다. v26.1부터 IdP(Identity Provider)의 그룹 클레임(Group Claims)을 CockroachDB 역할 멤버십으로 자동 동기화한다.

예를 들어 Okta나 Azure AD에서 사용자가 db-admin 그룹에 속해 있으면, CockroachDB에서 자동으로 admin 역할이 부여된다. 온보딩·오프보딩 시 DB 역할 관리 작업이 사라진다.

-- OIDC 설정 확인
SHOW CLUSTER SETTING server.oidc_authentication.provider_url;

-- 그룹 → 역할 매핑 확인
SELECT * FROM system.role_members WHERE role = 'db-admin';

CDC Protobuf 직렬화

Kafka를 프로토버프(Protocol Buffers)로 표준화한 조직에서는 CockroachDB의 JSON/Avro 기반 CDC가 변환 레이어를 강제했다. v26.1부터 CDC(Changefeed)가 Protobuf를 직접 직렬화 포맷으로 지원한다.

CREATE CHANGEFEED FOR TABLE orders
INTO 'kafka://kafka:9092'
WITH format = 'protobuf',
     confluent_schema_registry = 'http://registry:8081';

4. v26.2 운영 개선: MAINTAIN 권한과 IMPORT 성능

MAINTAIN 권한

기존에는 Materialized View를 REFRESH하려면 소유자이거나 슈퍼유저여야 했다. 운영팀이 개발팀 소유의 View를 갱신하거나 자동화 스크립트가 주기적으로 갱신하는 경우에 권한 충돌이 생겼다.

v26.2의 MAINTAIN 권한은 이 문제를 해결한다.

-- analytics_team에 Materialized View 갱신 권한 부여
GRANT MAINTAIN ON MATERIALIZED VIEW daily_summary TO analytics_team;

-- 부여 후 소유자가 아니어도 갱신 가능
REFRESH MATERIALIZED VIEW daily_summary;

테이블에도 MAINTAIN 권한을 부여할 수 있어, 통계 갱신이나 vacuum 작업 자동화에 활용된다.

분산 IMPORT Merge

대용량 IMPORT 작업에서 새 실행 경로가 추가됐다.

기존: IMPORT 프로세서가 SST 파일을 작성하고 즉시 인제스트. v26.2: 프로세서가 로컬 스토리지에 SST를 먼저 쓰고, 코디네이터 노드가 이를 병합한 뒤 인제스트.

이 방식은 L0 SST 파일 수를 줄여 컴팩션 백로그를 방지한다. 특히 TB 단위 대용량 마이그레이션에서 IMPORT 완료 후 발생하던 성능 저하를 완화한다.

-- 분산 IMPORT merge 활성화 (기본값: off, 대용량 IMPORT 시 권장)
SET CLUSTER SETTING bulkio.import.distributed_merge.mode = 'on';

5. CockroachDB를 선택하는 기준과 피해야 할 경우

CockroachDB가 강점을 발휘하는 조건이 명확하다.

적합한 경우:

멀티 리전 배포가 필요하고, 리전 장애 시에도 트랜잭션 ACID를 유지해야 할 때
PostgreSQL 호환 SQL을 유지하면서 수평 확장이 필요할 때
FIPS 140-3, PCI DSS, HIPAA 같은 규정 준수 요건이 있는 엔터프라이즈 환경

피해야 할 경우:

쓰기 지연(latency)이 수 밀리초 이하여야 하는 경우: Raft 합의로 인해 단일 노드 대비 쓰기 지연이 높다.
복잡한 JOIN이 많은 OLAP 워크로드: DistSQL 오버헤드가 전통적인 OLAP 엔진보다 불리하다.
팀 운영 역량이 PostgreSQL에 깊이 박혀 있고 단일 리전으로 충분한 경우: 불필요한 복잡성이다.
외래키 + 인덱스가 복잡한 스키마: 크로스-레인지 트랜잭션 빈도가 높아지면 지연이 급격히 오른다.

6. 운영 체크리스트 (v26.x 기준)

업그레이드 전

[ ] v25.4 이상에서 이미 값 분리가 켜져 있는지 확인 (SHOW CLUSTER SETTING storage.value_separation.enabled)
[ ] v26.1+ 업그레이드 시 FIPS 요건 여부 확인; FIPS 모드 필요 시 빌드 플래그 문서 참조
[ ] v26.1 CDC Protobuf 도입 시 Kafka 스키마 레지스트리 버전 호환성 확인
[ ] v26.2 MAINTAIN 권한 활용 전 기존 소유자 기반 자동화 스크립트 감사

값 분리 운영

[ ] wide-row 테이블(값 크기 256B+)에서 컴팩션 I/O와 처리량 baseline 측정
[ ] blob GC 주기 모니터링 (cockroach debug zip으로 Pebble 통계 수집)
[ ] 읽기 집약·소형 값 워크로드에서는 값 분리의 영향이 미미함을 팀 내 공유

Leader Lease 운영

[ ] 멀티 리전 클러스터에서 리더 선호 설정(lease_preferences) 명시
[ ] SHOW RANGES 출력에서 Leader와 Leaseholder가 동일 노드인지 정기 확인
[ ] 리더 선출 이벤트(/crdb-internal/cluster_events)를 알림으로 모니터링

성능 및 모니터링

[ ] Grafana crdb_builtin 대시보드에서 L0 SST count, compaction debt, lease latency 지표 추가
[ ] 대용량 IMPORT 작업 시 bulkio.import.distributed_merge.mode = 'on' 설정
[ ] EXPLAIN ANALYZE 출력에서 cross-range scan 비율 확인; 높으면 파티셔닝 재검토

결론

CockroachDB v26.x는 분산 SQL의 세 가지 오래된 약점을 한 번에 다뤘다. Leader Lease는 합의 레이어의 스케일 제약을 완화했고, 값 분리는 쓰기 집약 워크로드의 스토리지 병목을 50% 줄였다. v26.1의 FIPS 140-3 네이티브 지원과 JWT/OIDC 역할 동기화는 엔터프라이즈 보안 도입의 마지막 장벽을 제거했다.

운영자가 이 릴리스에서 먼저 볼 것은 성능 수치가 아니라 자신의 워크로드 프로파일이다. 값이 크고 쓰기가 많은 테이블이라면 값 분리의 효과가 바로 보인다. 멀티 리전이고 리더 선출 이벤트가 성능 지표에 찍혔다면 Leader Lease 동작을 확인할 차례다. 그리고 규정 준수 요건이 있는 조직이라면, v26.1의 FIPS 140-3과 SSO 개선이 도입 결정을 바꿀 수 있다.