불확실한 메시지 전송에서 신뢰성 있는 RabbitMQ Ack로 [2부]

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

개발 툴

대상자

RabbitMQ 및 Spring Framework를 활용한 메시지 시스템 개발자

• 중급~고급 수준 (publisher confirmations, 채널 관리, 비동기 처리 기술 필요)

핵심 요약

• waitForConfirmsOrDie() 사용: 메시지 전송 후 즉시 확인을 강제하여 신뢰성 확보
• 비동기 correlated ACK : CorrelationData로 메시지 추적, 채널 생성/폐기 오버헤드 최소화
• 채널 수 제한 설정 : checkout-timeout을 통해 OOM 예방 및 리소스 제어
• confirm-type: correlated 사용: confirmCallback과 호환되며 성능 향상

섹션별 세부 요약

1. Publisher Confirmations 기초

• Delivery Tag : 채널 범위 내 유일한 메시지 식별자 제공
• ACK/NACK 콜백 : 성공/실패 시 별도 처리 가능
• waitForConfirms() : 채널 캐시 반환 전 확인 처리 필수
• 예시 코드:

```kotlin

channel.waitForConfirmsOrDie(10_000)

```

2. 비동기 Correlated ACK 구현

• 비동기 처리 : invoke()로 채널 재사용, CorrelationData로 메시지 추적
• 재시도 가능 : 실패 메시지만 별도 처리 가능
• Spring 설정 예시:

```yaml

spring:

rabbitmq:

publisher-confirm-type: correlated

```

3. 채널 생성 과잉 문제 (Channel Churn)

• 문제점 : convertAndSend() 호출 시 채널 생성/폐기 반복 → OOM 위험
• 해결 방안 :

```kotlin

template.invoke { channel ->

messages.forEach { channel.convertAndSend(...) }

}

```

• Spring 캐시 설정 :

```yaml

spring:

rabbitmq:

cache:

channel:

size: 3

checkout-timeout: 5000

```

4. `simple` vs `correlated` confirm-type 선택

• simple : 채널 즉시 반환 → 성능 저하 가능성
• correlated : confirmCallback 사용 권장
• 주의 사항 : simple 설정 시 waitForConfirm() 호출 필수

5. 채널 수 제한의 영향

• 무제한 채널 : 메모리 사용량 증가, 고부하 시 OOM 위험
• 제한 채널 : 리소스 예측성 향상, 동시 전송 스레드 많을 때 유리
• 적용 시나리오:

- 제한 채널 : 고부하 시스템, 메모리 제어 필요 시

- 무제한 채널 : 개발/테스트 환경, 스레드 블록 불가능 시

결론

• 비동기 correlated ACK 사용으로 비동기 처리 효율성 극대화
• checkout-timeout 설정을 통해 채널 생성 과잉 방지
• Spring 설정에서 confirm-type: correlated 사용 권장
• 메시지 시스템 성능 향상을 위해 RabbitMQ 통계 모니터링 필수