지금까지 카산드라의 내부 아키텍처와 데이터 모델링에 대해 배웠습니다. 이제는 실제 운영 환경에서 클러스터를 건강하게 유지하고, 문제가 발생했을 때 해결하는 실무적인 기술을 익힐 차례입니다. 안정적인 서비스 운영은 이론만큼이나 중요합니다.
카산드라 클러스터의 상태를 파악하기 위해 반드시 주시해야 할 핵심 지표들입니다. 이 지표들은 그라파나(Grafana)와 프로메테우스(Prometheus)를 사용하여 시각화하는 것이 일반적입니다.
| 지표 종류 | 핵심 메트릭 | 의미 및 확인 사항 |
|---|---|---|
| 지연 시간 (Latency) | Read/Write Latency (99th, 95th Percentile) | 사용자가 체감하는 성능과 직결됩니다. 특정 시점부터 지연시간이 급증했다면, 과도한 툼스톤, GC(Garbage Collection) 문제, 컴팩션 부하 등을 의심해야 합니다. |
| 작업 처리량 (Throughput) | Pending/Blocked Compactions, Pending Flushes | 컴팩션이나 플러시 작업이 계속 쌓이고 있다면(Pending), 쓰기 속도를 시스템이 감당하지 못하고 있다는 위험 신호입니다. 디스크 I/O 성능을 점검하거나 컴팩션 전략 튜닝이 필요합니다. |
| JVM & GC | Heap Usage, GC Pause Time (특히 ParNew, CMS) | 힙 메모리 사용량이 비정상적으로 높거나 GC로 인한 Stop-the-world 시간이 길어지면 클러스터 전체의 성능 저하로 이어집니다. JVM 튜닝이 필요할 수 있습니다. |
| 디스크 & SSTable | Disk Usage, SSTable Count, Live/Tombstone Scanned per Read | 디스크 사용량 증가는 당연하지만, SSTable 개수가 과도하게 많거나 읽기 당 스캔하는 툼스톤 수가 많아지면 읽기 성능이 급격히 저하됩니다. 컴팩션이 제대로 동작하는지 확인해야 합니다. |
| 노드 상태 | Node Status (Up/Down) | 가십 프로토콜을 통해 확인되는 노드의 상태입니다. 다운된 노드가 발생하면 즉시 원인을 파악하고 복구해야 합니다. |
nodetool은 카산드라 클러스터의 상태를 확인하고 관리하는 가장 기본적인 CLI(Command-Line Interface) 도구입니다. 모든 카산드라 운영자는 이 도구와 친숙해져야 합니다.
# 클러스터의 전체 노드 상태, 데이터 소유량, 랙/DC 정보 확인
nodetool status
# 특정 테이블의 상세 정보 (SSTable 개수, 평균 파티션 크기, 툼스톤 정보 등) 확인
nodetool tablestats <keyspace>.<table>
# 현재 진행 중이거나 대기 중인 컴팩션 작업 확인
nodetool compactionstats
# 노드를 클러스터에서 안전하게 제거 (데이터를 다른 노드로 이전)
nodetool decommission
# 모든 노드의 데이터를 일관성 있게 맞춰주는 복구 작업 실행 (필수!)
nodetool repair -prRead Repair나 Hinted Handoff는 데이터 불일치를 해소하는 데 도움을 주지만, 한계가 명확합니다.
Anti-Entropy Repair는 이러한 문제를 해결하기 위한 근본적인 해결책입니다. nodetool repair 명령어로 실행하며, 클러스터의 모든 복제본 노드 간의 데이터를 비교하여 불일치를 찾아내고 수정하는 백그라운드 프로세스입니다.
카산드라를 안정적으로 운영하기 위해서는 반드시 주기적으로(e.g., 매주) `nodetool repair`를 실행해야 합니다. 이 작업을 소홀히 하면 시간이 지남에 따라 데이터 불일치가 누적되어 복구 불가능한 상태가 될 수 있습니다. Reaper와 같은 자동화 도구를 사용하여 repair 작업을 관리하는 것이 일반적입니다.
gc_grace_seconds는 테이블 옵션 중 하나로, 툼스톤(삭제 표시)이 컴팩션에 의해 최종적으로 삭제되기 전까지 대기하는 시간을 의미합니다. 이 설정은 데이터 정합성과 직접적인 관련이 있어 매우 신중하게 다루어야 합니다.
Q: "카산드라 클러스터의 읽기 지연시간이 갑자기 급증했습니다. 어떤 것들을 순서대로 확인하시겠습니까?"
A: "먼저, 특정 노드에서만 문제가 발생하는지 클러스터 전반의 문제인지 확인하기 위해 `nodetool status`로 노드 상태를 확인하고, 모니터링 시스템에서 노드별 지연시간 그래프를 비교하겠습니다. 전반적인 문제라면, 1) GC Pause Time이 급증했는지 확인하여 JVM 문제를 의심하고, 2) Pending/Blocked Compaction 수가 증가했는지 확인하여 컴팩션 부하를 의심합니다. 3) `nodetool tablestats`를 통해 특정 테이블의 'Live/Tombstone Scanned per Read' 메트릭이 비정상적으로 높은지 확인하여 툼스톤 문제를 의심할 수 있습니다. 만약 특정 테이블의 문제라면, 데이터 모델링이나 쿼리 패턴의 변경이 있었는지 확인하고, 과도한 툼스톤이 원인이라면 수동 컴팩션을 고려해볼 수 있습니다."
Q: "Read Repair만으로는 데이터 일관성을 완전히 보장할 수 없습니다. 그 이유는 무엇이며, 근본적인 해결책은 무엇인가요?"
A: "Read Repair는 읽기 요청이 발생했을 때만 동작하기 때문에, 거의 읽히지 않는 데이터는 노드 간 불일치가 발생해도 영원히 수정되지 않을 수 있습니다. 또한, Hinted Handoff는 노드 장애가 길어지면 힌트가 유실되어 데이터가 누락될 수 있습니다. 이에 대한 근본적인 해결책은 `nodetool repair`를 통한 Anti-Entropy Repair입니다. 이 작업은 클러스터의 모든 데이터를 대상으로 복제본 간의 불일치를 능동적으로 찾아내고 복구해주므로, 장기적인 데이터 정합성을 보장하기 위해 반드시 주기적으로 실행해야 합니다."
Q: "테이블의 `gc_grace_seconds` 값을 줄이면 툼스톤이 빨리 제거되어 성능에 좋을 것 같은데, 왜 함부로 줄이면 안 되나요?"
A: "`gc_grace_seconds`는 다운된 노드가 복구될 시간을 벌어주는 안전장치 역할을 하기 때문입니다. 만약 이 값을 `nodetool repair` 주기보다 짧게 설정하면, repair가 실행되기 전에 툼스톤이 먼저 영구적으로 삭제될 수 있습니다. 이 상태에서 오랫동안 다운되었던 노드가 복구되면, 해당 노드는 자신이 가진 (이미 삭제된) 낡은 데이터를 최신 데이터로 착각하고 클러스터에 다시 퍼뜨리게 됩니다. 이 '좀비 데이터'는 삭제해도 계속 살아나는 심각한 데이터 불일치 문제를 야기하므로, `gc_grace_seconds`는 반드시 repair 주기보다 길게 설정해야 합니다."