📕 개요
기존 단일 도메인만 구동하던 서비스에서, 서버의 부담을 줄이기 위해 비동기로 처리 되는 부분을 보조 서버에서 처리하도록 변경하려 하였다.
때문에, RabbitMQ 의 메세지를 보조 서버가 우선적으로 수신할 필요가 있었다.
🔍 RabbitMQ
RabbitMQ 는 기본적으로 메세지가 쌓이면, 해당 큐를 구독 하고 있는 어플리케이션에게 메세지를 전달(Push) 하는 방식으로 구성되어 있다.
이때, 기본적으로는 라운드 로빈 방식으로 메세지를 균등하게 배분하도록 설정 되어 있으며 이러한 방식을 직접 커스텀 하기에는 많은 제약이 있었다.
( ex. 특정 서버의 CPU/Memory 사용량이 많을 시 메세지를 배분하지 않도록 한다던가.. )

또한, 인프라 자체의 설정을 변경하게 되면 모든 서비스에 이러한 영향이 전파가 되며 이후 관리 포인트가 증가하는 문제도 발생하였기에 관련된 사항들은 어플리케이션 단에서 관리하는 방향으로 고민을 하게 되었다.
🔍 단일 컨슈머
위와 같은 사항을 해결하는 가장 간단한 방식으로, 메인 서버의 컨슈머를 제거하여 메세지를 보조 서버만 수신하도록 구성하는 것이었다.
이 방식은 모든 메세지 관련 책임을 보조 서버에 위임하여 구조를 단순하게 할 수 있었지만, 보조 서버의 장애가 발생했을 경우 대처할 수 있는 방법이 존재하지 않았다는 문제가 발생하였고, 때문에 메인 서버와 보조 서버의 컨슈머를 모두 유지하는 방식으로 고민하기 시작하였다.
🔍 메세지 우선 수신 후, 어플리케이션에서 메세지를 반환
결국 메인 서버에서 처리 비용, 부담 등을 줄이는 것에 목표를 두고 있기에 메세지를 수신해도, 이를 처리하지 않고 바로 RabbitMQ 로 반환하여 보조 서버로 메세지를 전달하는 방식을 고려하게 되었다.
1. 메인 서버 메세지 수신
2. 어플리케이션 단에서 보조 서버가 정상 동작 중인지 확인
2-1. 보조 서버 정상 동작 시, 메세지 반환 (drop)
2-2. 보조 서버 장애 시, 메인 서버에서 메세지 처리
이러한 바식은 비교적 간단한 구조로, 보조 서버로 메세지를 우선적으로 전달하며 메인 서버의 컨슈머를 동작시킬 수 있다는 장점이 있었다.
하지만, 메인 서버가 메세지를 수신하고 이를 반환하는 과정에서 불필요한 네이트워크 및 처리 비용이 발생하여 비동기 처리 성능이 전체적으로 저하되는 문제가 발생하였다.
🔍 MessageListenerContainer 를 활용한 동적 수신
최종적으로 어플리케이션에서 RabbitMQ 의 MessageListenerContainer 를 직접 제어 하여, 특정 서버의 메세지 수신 여부를 동적으로 설정할 수 있도록 하였다.
보조 서버가 정상 동작 시에는, 메인 서버가 메세지를 수신하지 않도록 설정함으로 별도의 네트워크/처리 비용 없이 메세지 처리를 보조 서버에 우선적으로 전달할 수 있었다.
보조 서버 정상 동작을 확인하는 방식으로 스케쥴러를 통해 주기적으로 확인하는 방법도 고려할 수 있었지만, 해당 방식은 비동기 작업이 없을 때에도 불필요한 자원을 소모할 수 있다는 단점이 존재하였기에 메세지를 발행할 때마다 일정 시간 동안 메인 서버가 메세지를 수신하지 않는 방식을 선택하게 되었다.
1. 메세지 발행 전, AOP 를 활용해 요청을 가로챔
2. Local-Cache 를 확인하여, 최신 보조 서버 검사 타임 스탬프 확인
3. N분 이내에 검사가 진행되지 않았을 시, 보조 서버의 작동 여부를 RabbitMQ Management 를 활용해 검사
4. 보조 서버 작동 여부를 타임 스탬프와 함께 저장(업데이트)
5. 보조 서버가 정상 작동 시, 메인 서버의 컨슈머를 비활성화
6. 메세지 발행
'기술적 고민' 카테고리의 다른 글
| 외부 API 연동 서비스의 안정성 확보 (0) | 2025.12.23 |
|---|---|
| (MSA) 주문 및 결제에 이벤트 기반 SAGA 패턴을 활용한 이유 (0) | 2025.04.26 |
| 동시성 제어에 캐시와 분산락 Redisson 을 도입한 이유 (1) | 2025.04.09 |
| 예약 관리 서비스에 RabbitMQ 를 도입하게 된 이유 (0) | 2025.03.26 |
| 데이터 유실 방지 - 외부 저장소(S3) 장애 대응 (0) | 2025.03.04 |