Cassandra 툼스톤(Tombstone) 임계치 초과 장애와 지워진 좀비 데이터의 역습

글로벌 유저의 푸시 알림 이력 관리에 분산 스토리지인 Apache Cassandra를 도입했습니다. 며칠 뒤 "알림 삭제"를 무더기로 실행한 특정 권역의 유저들이 오히려 'ReadTimeoutException' 에러를 맞고 앱 접속이 불가해지는 역설적인 장애가 터졌습니다. 지운 데이터가 도리어 시스템을 조여오는 현상, 카산드라의 무덤, 바로 툼스톤(Tombstone) 때문이었습니다. 카산드라 같은 분산 마스터리스 아키텍처에서는 특정 노드에서 데이터 삭제(Delete) 명령이 떨어졌을 때, 이를 즉각 물리적으로 포맷해버리면 잠시 통신이 끊겼던 다른 노드들이 나중에 복구되었을 때 "어? 내 복제본에는 이 데이터가 있는데 너는 없네? 동기화(Repair) 시켜줄게" 라며 지워진 데이터를 부활시켜 버립니다. 이 좀비 현상을 막기 위해 카산드라는 데이터를 실버넷에서 지우는 대신, 해당 로우(Row) 위에 "이 데이터는 [2026-02-12]에 사망했음"이라는 묘비(Tombstone 마커)를 10일(gc_grace_seconds) 동안 강제로 덮어씌워 둡니다. 문제는 유저들이 알림을 10만 개나 밀어버리는 바람에, 데이터베이스가 SELECT 쿼리를 날릴 때 이 묘비 10만 개를 일일이 하나하나 밟고 지나가며 스캔하느라 CPU 사이클과 RAM 메모리를 다 태워버려 읽기 임계치(tombstone_failure_threshold)를 초과해 뻗어버린 것입니다. 저희는 이 무덤들 위로 쿼리가 지나가지 않도록 모델을 시계열 TTL로 재설계(Drop)하고, 묘비를 수동으로 압축 타파(Nodetool compaction)하는 강제 스크립트를 주입해 밤을 새워 무덤을 치웠습니다. 파편화된 분산 시스템에서 '삭제'라는 행위는 공간을 비우는 것이 아니라, 오히려 삭제되었다는 '새로운 상태'를 증폭 생성하는 것임을 뼈아프게 깨달았습니다.