Super Disk로 견고하고 고성능인 ScyllaDB 클러스터 구축하기

Hyperconnect는 전사 NoSQL 데이터베이스로 ScyllaDB를 약 4년간 운영해 왔고, ML feature store를 포함한 다양한 서비스의 고성능 요구를 충족해 왔다. 하지만 최근 장애 모의 훈련에서 cluster rolling update 시 node 복구 시간이 너무 길다는 문제가 드러났다.

문제의 핵심은 Local NVMe SSD를 쓰는 i4i 인스턴스의 특성이었다. ScyllaDB는 Cassandra처럼 Linux page cache에 크게 의존하지 않고 embedded cache와 디스크 I/O 성능에 더 직접적으로 좌우되기 때문에, 인스턴스 재부팅 시 로컬 디스크가 사라지면 다른 node에서 데이터를 다시 가져오는 복구 과정이 길어질 수밖에 없었다. 실제로 node 하나를 교체하는 데 18~24시간, 데이터가 많은 경우 node 복구는 3~4시간, 최대 12시간까지 걸렸다.

이를 해결하기 위해 도입한 해법이 Super Disk다. Discord 사례를 참고해 Local SSD + EBS를 RAID1으로 묶고, write-mostly 설정으로 읽기는 Local SSD에서만 수행하도록 구성했다. 이렇게 하면 EBS는 영속성을 담당하고, 읽기 지연은 Local SSD가 흡수한다.

PoC는 같은 스펙의 i4i.4xlarge cluster 두 개를 만들어 비교하는 방식으로 진행했다.

• ScyllaDB 버전: 5.4.9
• pod CPU: 14
• pod memory: 110Gi
• scylla embedded memory size: 100G
• EBS 용량: 3492GB
• 초기 적재 데이터: 7억 Row, 약 node당 1.5TB

장애 시나리오도 검증했다. EBS를 force detach했을 때 RAID는 degraded 상태가 되었지만 [_U] 상태로 read/write가 정상 동작했다. 반대로 i4i instance 자체를 강제로 종료한 뒤 새 instance에 EBS를 붙여 RAID를 재구성했을 때는 복구에 약 1시간이 걸렸고, 이후 ScyllaDB를 재시작하면 cluster에 정상 합류했다. RAID 복구 중에는 EBS와 Local SSD 자원을 모두 사용하므로, 복구가 끝난 뒤 ScyllaDB를 올리는 편이 더 효율적이었다.

성능도 기대 이상으로 유지됐다. YCSB와 Latte를 이용해 실제 운영에 가까운 read/write 비율로 측정한 결과, Super Disk를 적용한 cluster와 그렇지 않은 cluster 사이의 throughput, write latency, 전반적 latency 차이가 거의 없었다. compaction 타이밍에 따라 read latency가 잠깐 튀는 경우는 있었지만, 전체적으로는 성능 저하가 미미했다.

결론적으로 Super Disk는 영속성과 빠른 복구, 그리고 기존과 유사한 성능을 동시에 확보하는 현실적인 대안이었다. 이런 판단을 바탕으로, Kubernetes 환경에서 Super Disk를 더 효율적으로 관리하기 위한 Windmill 기반 자동화까지 이어서 정리한다.