← 목록으로
📅 2026.05.15
ActiveMQ KahaDB 디스크 고갈 문제와 발송 속도 제어(Rate Limit) 전략
TroubleshootingActiveMQKahaDBDisk FullRate LimitBackpressure

대용량 메시징 시스템에서 영속성(Persistence)을 위해 파일 기반 저장 방식을 채택할 때, 예상치 못한 디스크 사용량 급증 현상을 겪을 수 있습니다.
이번 글에서는 ActiveMQ의 KahaDB 블록 문제를 진단하고, Throttling 및 Timeout 최적화를 통해 시스템 셧다운을 막아낸 해결 과정을 작성했습니다.

1. 현상: 처리량은 유지되는데 디스크가 풀(Full) 차는 이유

대용량 콘텐츠(최대 10MB)를 포함한 이메일 발송 시, 수신 서버와의 레이턴시 차이로 인해 디스크 공간이 빠르게 부족해지는 현상이 발생했습니다.

원인 분석: KahaDB의 16MB 블록 관리
ActiveMQ의 기본 저장소인 KahaDB는 데이터를 16MB 단위의 로그 파일(Data Log Files)로 저장합니다.

문제의 핵심
특정 로그 파일 내에 포함된 단 하나의 메시지라도 소비(Dequeue)되지 않고 남아 있다면, 해당 16MB 블록 전체가 삭제되지 않고 디스크에 계속 머물게 됩니다.

결과
대용량 데이터가 포함된 메시지들이 여러 블록에 걸쳐 쌓이면서, 실제 대기 중인 메시지 양보다 훨씬 많은 디스크 공간을 점유하는 '임시 데이터 누적' 현상이 발생했습니다.

2. 병목 구간 진단: Queue 적재량과 Dequeue 속도 불균형

모니터링 결과, 근본적인 원인은 Queue 적재량이 Dequeue 속도를 압도하는 데 있었습니다.

속도 불균형
시간당 20만 건의 요구사항을 맞추기 위해 Queue에 과도하게 데이터를 밀어 넣었으나, 수신 서버의 응답 지연으로 인해 소비 속도가 이를 따라가지 못함.

네트워크 타임아웃
일부 수신 서버의 세팅이 최대 5분까지 대기하도록 설정되어 있어, 통신이 사실상 종료된 상태에서도 MQ 자원이 해제되지 않고 레이턴시를 유발함.

3. 해결 전략: 단계별 시스템 최적화

3-1. Threshold 기반의 Backpressure(역압) 도입
시스템 자체 다운을 방지하기 위해 Pusher 측에 임계치(Threshold) 제어 로직을 추가했습니다.

작동 원리
관리자 페이지의 Queue 카운팅 정보를 실시간 모니터링하여, 적재된 MQ가 설정한 임계값(20,000건)을 초과하면 Pusher 작업을 지정된 시간동안 지연시킵니다.

3-2. 통신 구간별 타임아웃(Timeout) 세밀화
수신 서버와의 불필요한 대기시간을 줄이기 위해 각 통신 단계별로 타임아웃을 재설정했습니다.

효과
비정상적인 세션을 빠르게 정리하여 Dequeue 처리 효율을 높이고 리소스 점유 시간을 최소화

4. 최종 결과 및 수치화된 성과

논리적인 흐름에 따라 최적화를 진행한 결과, 물리적인 사양 증설 없이도 안정적인 서비스가 가능해졌습니다.

항목설정 및 결과
목표 처리량시간당 200,000건 (성공)
인프라 구성35 TCP * 2 Pushers / 100GB Disk
관리 임계치20,000 MQ (Threshold 설정)
안정성리소스 부족으로 인한 셧다운 현상 제거

결론: 이번 사례를 통해 얻은 가장 큰 교훈은 "리소스 증설은 최후의 수단"이어야 한다는 점입니다.
데이터 크기와 생성 속도 제어, MQ 저장 방식의 특성 이해, 네트워크 통신 최적화라는 세 가지 관점에서 순차적으로 병목을 해소함으로써 비용 효율적인 해결책을 찾을 수 있었습니다.