"이론은 완벽했는데..." 카산드라 카운터 믿었다가 프로덕션 터진 썰

요약 실시간 메시징 인프라 기업 Ably가 공유한 아파치 카산드라(Apache Cassandra) 운영 장애 회고입니다. 무한 확장이 가능하다고 알려진 카산드라를 메시지 영구 저장소로 적극 활용하던 Ably는 2020년 초 사흘 저녁에 걸쳐 심각한 클러스터 중단 장애를 겪었습니다. 노드를 늘리거나 스펙을 키우는 표준적인 해결책조차 전혀 먹히지 않는 초유의 상황이었습니다. 원인을 파악하기 위해 카산드라의 기본 동작 원리를 추적했습니다. 카산드라는 기본적으로 파티션 내 셀(cell) 단위의 업서트(upsert)와 최종 쓰기 승리(LWW) 방식을 기반으로 하는 결과적 일관성(Eventual Consistency) 시스템입니다. 하지만 파티션 내 셀 개수를 세는 쿼리는 O(N)의 비용이 들어 매우 비효율적이었고, Ably는 푸시 디바이스 등록 샤딩 전략을 위해 O(1) 수준의 카운팅 방법이 필요했습니다. 이때 도입한 것이 카산드라의 '카운터 컬럼(Counter Column)'이었습니다. 이론상 카운터 컬럼은 CRDT 기반으로 동작하여 분산 환경에서도 가용성과 성능을 보장하는 우아한 해법처럼 보였습니다. 하지만 실전 적용에는 상당한 제약이 따랐습니다. 카운터 컬럼은 오직 카운터 컬럼만으로 구성된 별도 테이블에서만 생성 가능해 데이터 모델이 복잡해졌고, 카운터 테이블로 한 번 선언되면 삭제조차 불가능했습니다. 게다가 실제 프로덕션 환경의 카운터 업데이트 동작 방식에서 발생하는 구조적 한계가 대규모 장애의 직접적인 불씨가 되었습니다. 분산 시스템에서 이론적 모델만 믿고 프로덕션에 도입했을 때 어떤 위험이 발생하는지 경각심을 주는 기술적 사례입니다.