KahaDB 인덱스 복구(Cleanup) 시 발생하는 성능 지연 시간은?

KahaDB 인덱스 복구(Cleanup) 시 발생하는 성능 지연 시간은?

엔터프라이즈 메시징 환경에서 ActiveMQ Classic을 운영하다 보면 가장 당혹스러운 순간 중 하나가 바로 브로커의 비정상 종료 후 재시작(Restart) 과정에서 발생합니다. 평소라면 수 초 만에 기동되어야 할 브로커 서버가, 로그에 "Recovering KahaDB" 혹은 "Building index"라는 메시지를 띄운 채 수십 분에서 심지어 수 시간 동안 멈춰있는 현상입니다.

이 엄청난 성능 지연 시간(Latency)은 시스템의 가용성(Availability)을 심각하게 훼손하며, 페일오버(Failover) 클러스터링 환경에서 연쇄적인 타임아웃 장애를 유발합니다. 이 가이드에서는 KahaDB의 인덱스 복구 작업이 왜 그토록 오랜 시간을 소모하는지, 내부 복구 메커니즘과 지연 시간을 결정짓는 핵심 변수들을 상세히 분석합니다.

---

1. 인덱스 붕괴(Corruption)의 원인과 복구 트리거

정상적인 브로커 종료 시, KahaDB는 메모리에 있는 B-Tree 인덱스의 최신 상태를 db.data 파일에 안전하게 플러시(Flush)하고 파일 핸들을 깔끔하게 닫습니다.

하지만 서버의 전원 차단, OS 패닉, 혹은 kill -9 명령어로 인한 강제 종료나 JVM OOM(Out of Memory)이 발생하면 db.data 파일은 미처 다 쓰이지 못한 채 손상된(Corrupted) 상태로 남게 됩니다.

이후 브로커가 다시 기동될 때, KahaDB 엔진은 시작 단계에서 db.data 파일의 체크섬(Checksum)을 검사합니다. 손상이 감지되면, 브로커는 잘못된 인덱스를 믿고 라우팅을 진행할 수 없으므로 기존의 db.data 파일을 아카이브 폴더(Corrupt 디렉토리)로 격리하거나 삭제해 버립니다. 그리고 원천 데이터인 저널 파일(db-*.log)들을 바탕으로 B-Tree 인덱스를 백지상태에서 완전히 재구축(Rebuild)하는 길고 고통스러운 작업에 돌입합니다.

---

2. 복구 작업(Index Rebuild)의 내부 병목 메커니즘

인덱스 복구 작업이 시작되면 브로커 내부에서는 디스크와 CPU를 극한으로 쥐어짜는 엄청난 연산이 발생합니다.

A. 저널 파일의 순차적 전체 스캔 (Full Sequential Scan)
브로커는 data 디렉토리에 남아있는 가장 오래된 저널 파일(예: db-1.log)부터 가장 최신 파일까지, 단 1바이트도 빠짐없이 처음부터 끝까지 순차적으로 읽어 들입니다. 저널 파일 안에는 아직 컨슈머가 소비하지 않은 유효한 메시지도 있지만, 이미 처리가 완료되어 쓸모없어진 과거의 메시지와 ACK(수신 확인) 마커들도 혼재되어 있습니다. 브로커는 이 모든 데이터를 하나하나 파싱하여 현재 유효한 메시지가 무엇인지 걸러내야 합니다.

B. B-Tree 노드의 무한 재구성 (CPU 연산 및 메모리 압박)
저널 파일에서 유효한 메시지를 하나 발견할 때마다, 브로커는 메모리상에 B-Tree 인덱스 노드를 생성하고 해당 메시지의 오프셋(위치) 포인터를 기록합니다.
수백만 개의 메시지가 복구되는 동안 B-Tree는 끊임없이 노드를 분할(Split)하고 병합(Merge)하며 트리 균형을 맞추는 복잡한 알고리즘을 수행합니다. 이는 극심한 CPU 연산 부하를 일으키며, 거대한 인덱스 트리가 JVM 힙 메모리에 한꺼번에 적재되면서 가비지 컬렉션(GC) 스파이크를 유발합니다.

---

3. 지연 시간(Latency)을 결정짓는 3가지 핵심 변수

복구에 걸리는 시간은 1분이 될 수도, 3시간이 될 수도 있습니다. 이는 다음의 물리적, 논리적 환경에 의해 결정됩니다.

1. 누적된 저널 파일의 총용량 (가장 절대적인 요인):
   컨슈머가 제때 메시지를 처리하지 않아 디스크에 수백 개의 db-*.log 파일이 쌓여 총 100GB의 용량을 차지하고 있다면, 브로커는 기동 시 100GB의 파일을 모두 디스크에서 읽어내야 합니다.
2. 디스크 I/O 처리량 (HDD vs SSD/NVMe):
   만약 초당 100MB를 읽을 수 있는 일반 HDD 환경이라면, 100GB의 로그를 단순히 '읽는 데만' 1,000초(약 16분) 이상이 소요됩니다. 여기에 B-Tree 구성 연산 시간이 추가되므로 지연 시간은 기하급수적으로 늘어납니다. 고성능 NVMe SSD를 사용한다면 이 스캔 시간을 획기적으로 단축할 수 있습니다.
3. 메시지의 단편화(Fragmentation) 상태:
   저널 파일 용량은 큰데 실제 살아있는 메시지는 적고 쓰레기 데이터(이미 처리된 내역)가 파일 곳곳에 흩어져 있는 단편화가 심한 상태라면, 브로커의 파싱 오버헤드가 증가하여 복구 효율이 극도로 떨어집니다.

---

4. 아키텍처 관점에서의 연쇄 장애 위험성

이 긴 복구 시간 동안 브로커는 클라이언트의 연결을 받을 수 없는 '좀비' 상태가 됩니다. 여기서 시스템 아키텍처를 위협하는 심각한 사이드 이펙트가 발생합니다.

• Failover 핑퐁 현상: 마스터 브로커가 강제 종료 후 재시작하면서 인덱스 복구에 30분을 쓴다면, 슬레이브 브로커가 마스터로 승격하여 트래픽을 처리하게 됩니다. 하지만 기존 마스터가 복구를 끝내고 다시 락(Lock)을 쟁취하려 시도하면서, 클라이언트 커넥션이 양쪽 브로커를 오가며 끊어지는 혼란이 발생할 수 있습니다.
• 커넥션 타임아웃 폭주: 애플리케이션 서버(Tomcat 등)들은 브로커가 살아난 줄 알고 연결을 시도하지만, 브로커 내부는 복구 연산으로 블로킹되어 있어 응답을 주지 못합니다. 이로 인해 앱 서버의 스레드 풀이 고갈되는 2차 장애로 이어질 확률이 매우 높습니다.

---

5. 인덱스 복구 지연을 최소화하는 방어 및 튜닝 전략

이러한 지연 시간을 완벽하게 없앨 수는 없지만, 인프라 설계와 KahaDB 설정을 통해 피해를 최소화할 수 있습니다.

• 가비지 컬렉션(GC) 최적화로 저널 파일 억제: 가장 확실한 방법은 애초에 복구할 파일의 양을 줄이는 것입니다. KahaDB가 이미 소비된 저널 파일을 신속하게 삭제하도록 튜닝하여, 평상시 디스크에 유지되는 db-*.log 파일의 총용량을 수 GB 이내로 타이트하게 관리해야 합니다.
• 우아한 종료(Graceful Shutdown) 보장:
  서버 배포나 패치 작업 시 절대 브로커 프로세스를 강제 종료(kill -9)해서는 안 됩니다. 브로커가 진행 중인 트랜잭션을 마무리하고 db.data 인덱스를 디스크에 안전하게 동기화할 수 있도록 정상적인 종료 시그널(kill -15)을 보내고 끝날 때까지 기다리는 셧다운 훅(Shutdown Hook) 파이프라인을 구축해야 합니다.
• 저장소의 물리적 분리:
  하나의 브로커에 너무 많은 큐와 트래픽을 몰아넣기보다, 비즈니스 도메인별로 브로커 인스턴스(JVM)를 물리적으로 분리하는 멀티 테넌트(Multi-tenant) 아키텍처를 적용하여 장애 반경과 인덱스 복구 시의 스캔 범위를 최소화해야 합니다.

---

결론적으로 KahaDB의 인덱스 복구 지연 현상은 순차적 로그 스캔과 B-Tree 재구축이라는 아키텍처의 필연적 결과입니다. 이 지연 시간을 견딜 수 있는 초고속 디스크 인프라를 도입하거나, 평상시 저널 파일이 비대해지지 않도록 컨슈머의 처리 속도와 브로커 스토리지를 철저히 모니터링하는 것이 유일한 해법입니다.