KahaDB 아카이브(Archive) 기능을 통한 사후 분석 데이터 보관법?

KahaDB 아카이브(Archive) 기능을 통한 사후 분석 데이터 보관법?

엔터프라이즈 환경에서 운영되는 메시지 브로커의 대원칙은 '수신 확인(ACK)이 끝난 데이터는 미련 없이 버린다'입니다. 디스크 I/O와 스토리지 용량을 최적화하기 위해, 브로커는 컨슈머가 정상적으로 처리를 완료한 메시지들을 가비지 컬렉션(GC)의 대상으로 삼아 즉시 물리적 디스크에서 지워버립니다.

하지만 금융권의 컴플라이언스(법적 규제) 준수, 보안 감사(Security Audit), 혹은 컨슈머 애플리케이션의 치명적인 버그로 인해 '이미 소비되어 사라진 원본 메시지 페이로드'를 다시 추적하고 복원해야 하는 사후 분석(Post-mortem) 상황이 발생한다면 어떻게 될까요? 이미 지워진 로그 파일 앞에서는 그 어떤 뛰어난 엔지니어도 원인을 규명할 수 없습니다.

이러한 딜레마를 해결하기 위해 ActiveMQ의 KahaDB 스토리지 엔진은 지워질 운명에 처한 저널 파일들을 안전한 곳으로 빼돌려 보관하는 '데이터 아카이브(Data Archive)' 기능을 제공합니다. 이 가이드에서는 찰나의 순간에 휘발되는 메시지들을 영구적인 분석 자산으로 탈바꿈시키는 아카이브의 동작 원리와 설정법, 그리고 운영 상의 주의점을 상세히 해부합니다.

---

1. KahaDB의 기본 동작: 무자비한 가비지 컬렉션(GC)

아카이브 기능을 이해하려면 먼저 KahaDB가 평상시에 디스크를 어떻게 청소하는지 알아야 합니다.

KahaDB는 메시지가 유입되면 db-1.log, db-2.log 와 같은 32MB 크기의 저널(Journal) 파일에 순차적으로 데이터를 기록합니다. 백그라운드의 정리(Cleanup) 스레드는 주기적으로 이 파일들을 스캔합니다. 만약 db-1.log 파일 내부에 기록된 모든 메시지가 컨슈머에 의해 정상적으로 처리(ACK)되었다고 판단되면, 브로커는 디스크 공간 확보를 위해 해당 파일을 OS의 파일 시스템에서 영구적으로 삭제(Delete) 처리합니다.

이 메커니즘 덕분에 브로커는 적은 디스크 용량으로도 무한대에 가까운 트래픽을 처리할 수 있지만, 한 번 삭제된 데이터는 복구 소프트웨어를 돌리지 않는 이상 영영 되찾을 수 없는 비가역적 상태가 됩니다.

---

2. 'archiveDataLogs'의 구원: 삭제 대신 격리(Move)

이 무자비한 삭제 프로세스를 우아한 보관 프로세스로 바꿔주는 스위치가 바로 archiveDataLogs 옵션입니다.

이 옵션을 활성화하면, KahaDB의 정리 스레드는 더 이상 쓸모없어진 저널 파일을 마주했을 때 rm(삭제) 명령을 내리지 않습니다. 대신 운영체제의 mv(이동) 명령을 사용하여 해당 로그 파일을 브로커의 메인 동작과 완전히 격리된 별도의 '아카이브 디렉토리'로 이동시킵니다.

아키텍처적 이점:
파일을 복사(Copy)하는 것이 아니라 동일한 디스크 볼륨 내에서 이동(Move)시키는 것이기 때문에, 디스크의 I/O 대역폭을 추가로 소모하지 않으며 파일의 메타데이터(Inode)만 변경되어 극단적으로 빠르게 격리 작업이 완료됩니다. 브로커의 메인 라우팅 성능(TPS)에는 사실상 어떠한 악영향도 미치지 않으면서 완벽한 감사 추적(Audit Trail) 환경을 구축할 수 있습니다.

---

3. activemq.xml 핵심 설정 가이드

아카이브 기능을 활성화하는 방법은 매우 직관적입니다. ActiveMQ의 메인 설정 파일인 activemq.xml의 <persistenceAdapter> 블록을 다음과 같이 수정합니다.

<persistenceAdapter>
    <kahaDB directory="${activemq.data}/kahadb" 
            journalMaxFileLength="32mb"
            archiveDataLogs="true" 
            directoryArchive="${activemq.data}/kahadb/archive" />
</persistenceAdapter>

핵심 파라미터 분석:

• archiveDataLogs="true": 기본값인 false를 엎고, 폐기 대상 저널 파일을 삭제하지 않고 보관하겠다는 명시적인 선언입니다.
• directoryArchive: 보관될 저널 파일들이 위치할 절대 물리 경로를 지정합니다. 가급적 메인 KahaDB 디렉토리 외부의, 백업 에이전트가 쉽게 접근할 수 있는 경로로 지정하는 것이 좋습니다. 지정하지 않으면 기본적으로 KahaDB 데이터 폴더 하위에 archive라는 이름의 폴더가 자동 생성됩니다.

---

4. 아카이빙 데이터의 사후 분석 및 활용 전략

격리된 db-*.log 파일들은 단순한 텍스트 파일이 아니라 KahaDB 고유의 바이너리 포맷으로 압축되어 있습니다. 따라서 cat이나 vim 명령어로는 내부 페이로드를 읽을 수 없습니다. 이를 비즈니스 가치로 환산하기 위해서는 다음과 같은 분석 도구와 전략이 필요합니다.

A. KahaDB Export 도구를 통한 덤프(Dump)
바이너리 로그 파일을 사람이 읽을 수 있는 XML이나 JSON 형태, 혹은 다른 브로커로 주입할 수 있는 포맷으로 변환해야 합니다. ActiveMQ 커뮤니티에서 제공하는 KahaDB Export 유틸리티나 커스텀 파서(Parser) 프로그램을 작성하여 특정 시간대의 아카이브 파일을 스캔하고, 의심되는 페이로드 본문(Body)과 헤더(Header) 정보를 추출해 냅니다.

B. 장애 복기(Post-mortem) 및 재생(Replay)
결제 시스템에 버그가 발생하여 컨슈머가 메시지를 잘못된 로직으로 처리(ACK)해 버렸다면, 데이터베이스의 정합성은 완전히 깨지게 됩니다. 이때 아카이브 폴더에 보관된 해당 시간대의 로그 파일을 테스트 브로커 인프라에 복사한 뒤, B-Tree 인덱스를 강제로 재생성하여 당시의 큐 상태를 100% 동일하게 복원(Point-in-Time Recovery)할 수 있습니다. 이를 통해 버그가 수정된 컨슈머 애플리케이션으로 과거의 트래픽을 그대로 다시 흘려보내는(Replay) 강력한 복구 파이프라인 구축이 가능해집니다.

---

5. 운영 시 주의사항 (Disk Full의 저주와 라이프사이클 관리)

archiveDataLogs 기능은 훌륭한 보험이지만, 치명적인 독소 조항을 하나 품고 있습니다. 바로 브로커 스스로는 아카이브 폴더에 쌓인 파일들을 절대 알아서 지워주지 않는다는 점입니다.

초당 수천 건의 메시지가 오가는 환경에서 이 기능을 켜두고 한 달만 방치하면, 아카이브 폴더에는 수백 기가바이트에서 수 테라바이트에 달하는 .log 파일들이 무한정 쌓이게 됩니다. 결국 서버의 전체 디스크 공간이 고갈(Disk Full)되며 브로커는 패닉 상태에 빠져 모든 서비스를 멈추게 됩니다.

따라서 아카이브 기능을 프로덕션에 도입할 때는, 반드시 OS 레벨의 파일 삭제 스케줄러(Cronjob)를 병행하여 구축해야만 인프라의 붕괴를 막을 수 있습니다.

[리눅스 Crontab 방어 로직 예시]
컴플라이언스 규정이 "메시지 로그를 7일간 의무 보관하라"고 명시했다면, 서버의 크론탭에 다음과 같은 스크립트를 등록하여 매일 새벽마다 7일이 지난 오래된 아카이브 파일들을 운영체제가 물리적으로 청소하도록 강제해야 합니다.

# 매일 새벽 3시에, archive 폴더 내에서 수정된 지 7일이 지난 파일만 찾아 영구 삭제
0 3 * * * find /opt/activemq/data/kahadb/archive -name "db-*.log" -type f -mtime +7 -exec rm -f {} \;

---

결론적으로 KahaDB의 아카이브 기능은 맹렬하게 흘러가는 비동기 메시징의 찰나를 영구적인 감사 로그로 박제해 주는 강력한 무기입니다. 디스크 용량의 한계를 명확히 인지하고 외부 스크립트 기반의 라이프사이클 정책을 단단하게 결속하여, 어떤 장애 상황에서도 원본 데이터를 추적해 낼 수 있는 견고한 데이터 거버넌스(Governance)를 완성하시기 바랍니다.