Apache Cassandra 성능/특성 정리: partition key/모델링/tombstones/compaction

Apache Cassandra 성능/특성 정리: partition key/모델링/tombstones/compaction

이 글은 Apache Cassandra를 성능/운영 관점에서 길게 정리한 개인 노트입니다. 목표는 "지금 느린 이유"를 증거로 좁히고, 재발을 줄이는 체크리스트를 갖추는 것입니다.

전제: 성능은 DB만으로 결정되지 않습니다. 쿼리 패턴, 데이터 분포, 인덱스/스키마, 애플리케이션 트랜잭션 경계, 인프라(IO/네트워크)가 함께 결정합니다. 그래서 이 글은 '성능 모델(어디서 시간이 쓰이나) -> 설계/쿼리 -> 설정 -> 운영' 순서로 정리합니다.

Cassandra는 '파티션 키 설계 + compaction/tombstone 관리'가 성능의 대부분입니다. SQL처럼 자유롭게 조회하려고 하면 반드시 아픕니다.

이 DB를 언제 선택하나

정답은 항상 케이스 바이 케이스지만, 선택을 빠르게 만들기 위해 기준을 먼저 둡니다. 아래에 해당이 많을수록 이 DB를 고려할 만합니다.

- 대규모 쓰기/시간 순 데이터에서 수평 확장이 필수인 경우
- 쿼리 패턴이 파티션 키 기반으로 명확한 서비스
- 분산 시스템 수준의 고가용성을 운영하려는 경우

성능 모델: 어디서 시간이 쓰이나

Cassandra는 쓰기가 빠른 구조(memtable -> SSTable) 덕분에 대규모 ingest에 강합니다. 대신 읽기는 여러 SSTable을 합쳐야 할 수 있어 compaction 상태와 SSTable 수가 큰 영향을 줍니다.

삭제는 즉시 제거가 아니라 tombstone으로 남고, 이후 compaction으로 정리됩니다. tombstone이 많아지면 읽기 비용이 폭증해 지연/타임아웃으로 이어질 수 있습니다.

결론적으로 Cassandra는 데이터 모델링(파티션/클러스터링 키)이 곧 성능입니다. 쿼리 최적화보다 모델링이 먼저입니다.

핵심 용어 빠른 사전

성능/장애 분석에서 자주 쓰는 단어는 팀마다 다르게 이해되기 쉽습니다. 용어를 짧게 정의하고, 어떤 지표/증상과 연결되는지 같이 적어둡니다.

용어	설명	실무에서 연결되는 것
Coordinator	요청을 받아 라우팅/집계하는 노드	노드/네트워크 지연이 전체 지연으로 반영
SSTable	불변(immutable) 스토리지 파일	SSTable이 많으면 읽기 증폭 증가
Memtable	메모리 상의 쓰기 버퍼	flush 빈도/디스크 IO와 연결
Compaction	SSTable 병합/정리	backlog가 쌓이면 읽기/디스크가 같이 악화
Tombstone	삭제/TTL의 흔적	삭제가 많으면 읽기 비용 폭증
Hot partition	특정 파티션에 트래픽 집중	한 파티션이 병목이 되어 전체 지연 증가

옵션/핵심 요소(3~6)

자주 부딪히는 핵심 요소를 표로 먼저 고정해 두면, 장애/튜닝 때 팀 커뮤니케이션이 빨라집니다.

항목	의미	언제 쓰는지(실무 상황)
Partition Key	데이터 분산/조회 단위	핫 파티션을 피하면서 쿼리의 기준을 잡을 때
Clustering Key	파티션 내 정렬/범위 조회	시간순 조회 등 범위를 빠르게 뽑을 때
Tombstone	삭제/만료의 흔적	삭제가 많은 테이블에서 읽기 성능이 깨질 때
Compaction	SSTable 병합/정리	읽기 성능과 디스크 증폭을 관리할 때
Consistency Level	일관성/가용성 선택	요구사항에 맞는 읽기/쓰기 레벨을 정할 때

실무 튜닝 포인트(설정/옵션별)

설정에는 정답이 없습니다. 워크로드(읽기/쓰기/동시성/데이터 크기) 기준으로 관측하고 조정합니다. 아래는 실무에서 가장 자주 만지는 레버를 '항목별'로 정리한 것입니다.

compaction strategy
의미: SSTable 병합 전략
언제 만지나: 쓰기/읽기/TTL 패턴에 맞게 선택
주의/트레이드오프: 잘못 고르면 읽기 증폭/디스크 증폭 증가

gc_grace_seconds
의미: tombstone 보존(복구) 기간
언제 만지나: 삭제 후 복구/일관성 요구에 맞출 때
주의/트레이드오프: 너무 낮추면 불일치 위험, 너무 높으면 tombstone 누적

default_time_to_live
의미: 기본 TTL
언제 만지나: 시간 기반 데이터 만료가 기본인 테이블
주의/트레이드오프: TTL/삭제가 compaction 부담을 키울 수 있음

concurrent_compactors
의미: 동시 compaction 수
언제 만지나: compaction backlog가 쌓일 때
주의/트레이드오프: IO 병목이면 오히려 지연 악화

bloom_filter_fp_chance
의미: 블룸 필터 오탐률
언제 만지나: 읽기 IO를 줄이고 싶을 때
주의/트레이드오프: 메모리 사용량 증가

read_repair
의미: 읽기 시 불일치 수정
언제 만지나: 일관성 레벨과 함께 정합성을 유지
주의/트레이드오프: 읽기 비용 증가 가능

memtable flush
의미: memtable/flush 관련
언제 만지나: 쓰기 burst와 flush 빈도를 조절
주의/트레이드오프: 메모리/디스크 IO 트레이드오프

tombstone_threshold
의미: tombstone 경고/임계치
언제 만지나: tombstone 폭증을 조기 감지
주의/트레이드오프: 단순 설정이 아니라 모델/패턴 개선이 핵심

쿼리/스키마 설계에서 성능이 갈리는 지점

Cassandra는 파티션 키로 접근하는 쿼리만 빠르다고 생각하는 편이 안전합니다. 필요한 조회 패턴이 여러 개면 정규화보다 조회 패턴별 테이블을 만든다는 사고가 필요합니다.

TTL/삭제가 많은 테이블은 tombstone이 누적되기 쉬워 읽기 지연이 급증할 수 있습니다. 이 경우 파티션 크기, compaction 전략, TTL 분포를 같이 검토해야 합니다.

CREATE TABLE events_by_user (
  user_id text,
  day text,
  created_at timestamp,
  event_type text,
  payload text,
  PRIMARY KEY ((user_id, day), created_at)
) WITH CLUSTERING ORDER BY (created_at DESC);

SELECT * FROM events_by_user WHERE user_id = 'u42' AND day = '2026-03-02' LIMIT 50;

진단 명령/쿼리 모음(바로 실행용)

장애 때는 문서 찾을 시간이 없습니다. 아래는 현장에서 자주 쓰는 '첫 5분' 진단 명령/쿼리만 모은 것입니다. 환경/권한에 따라 일부는 제한될 수 있습니다.

# 노드 상태
nodetool status

# 테이블 통계(읽기/쓰기/탐스톤 힌트)
nodetool tablestats keyspace_name table_name

# compaction 상태
nodetool compactionstats

자주 하는 실수(운영/튜닝)

실수 체크리스트:
- 파티션 키 없이 다양한 WHERE 조건으로 조회하려는 습관(SQL처럼 사용)
- 파티션이 과도하게 커지거나 핫 파티션이 생기도록 모델링한다
- 삭제/TTL을 많이 쓰면서 tombstone/compaction 모니터링을 하지 않는다
- compaction backlog가 쌓였는데도 단순히 노드만 늘리고 모델을 안 바꾼다
- 일관성 레벨을 요구사항 없이 관성으로 고정한다
- 조회 패턴이 늘었는데도 '한 테이블로 다 해결'하려고 한다(패턴별 테이블 설계 회피)

운영/모니터링 체크리스트

운영에서는 compaction backlog, tombstone 경고/읽기 지연, SSTable 수, 핫 파티션(특정 키 집중), 디스크 사용량/IO를 핵심으로 봅니다.

갑자기 읽기가 느려졌다면 compaction이 밀리는지, tombstone이 누적됐는지부터 확인하는 편이 빠릅니다.

공통 체크리스트:
- 느린 쿼리 top N을 지속 수집(시간/호출수/총시간)
- 지연(p95/p99)과 오류율을 애플리케이션 지표와 함께 본다
- 캐시/메모리/디스크 IO 중 무엇이 병목인지 먼저 분리한다
- 복제/HA를 쓰면 일관성 요구가 높은 기능을 분리한다
- 튜닝/변경 후에는 동일 조건으로 재측정해 회귀를 막는다

트러블슈팅 루틴(순서 고정)

장애 때는 선택지가 너무 많아서 흔히 길을 잃습니다. 아래 순서를 팀 표준으로 정해두면, 원인 추적이 빨라지고 '감으로 설정만 만지는' 일을 줄일 수 있습니다.

1) 느린 패턴이 파티션 키 기반인지 확인한다
2) 특정 파티션이 과도하게 큰지(핫/와이드) 확인한다
3) tombstone 경고/TTL/삭제 패턴을 점검한다
4) compaction backlog/SSTable 수를 확인한다
5) compaction 전략과 gc_grace_seconds/TTL을 재설계한다
6) 필요하면 조회 패턴별 테이블로 모델을 바꾼다

문제 상황(정확히 1개)

상황 -> 삭제/TTL이 많은 테이블에서 읽기 지연이 점점 늘고, 특정 시점부터 타임아웃이 발생한다.
원인 -> tombstone이 누적되고 compaction이 따라가지 못해 읽기 시 확인해야 하는 데이터가 폭증했다.
해결 -> tombstone/TTL 분포를 분석하고 파티션 크기를 줄이며, compaction 전략과 관련 설정을 조정하거나 테이블 모델을 재설계한다.
예방 팁 -> TTL/삭제가 많은 테이블은 초기부터 tombstone/compaction을 모니터링하고, 조회 패턴별 테이블 모델링을 팀 규칙으로 둔다.

참고/출처

정확한 동작/버전별 차이는 공식 문서를 기준으로 확인합니다. 실무에서는 버전 차이가 곧 성능/장애 차이입니다.

• Apache Cassandra Documentation
• Cassandra: Data Modeling