Info
25년 9월 작업 중 겪었던 내용을 간략하게 요약한 글입니다.
회사에서 RabbitMQ 클러스터를 이전해야 하는 상황이 생겨서, 서비스 중단 없이 Migration을 수행하기 위해 조사한 내용을 정리한 글입니다.
이 문서는 CloudAMQP 사용을 기준으로 작성되었습니다.
마이그레이션 계획
1. 새 클러스터 생성
Admin 권한이 있는 계정으로 CloudAMQP에 접속하여 새 클러스터를 생성합니다.
- 새 클러스터는 따로 설정하지 않으면 최신 RabbitMQ 버전을 사용합니다.
- 특히 버전 차이가 큰 경우 클러스터를 새로 생성하는 것이 더 효율적일 수 있습니다. 이는 CloudAMQP에서 RabbitMQ 버전 업데이트가 단계적으로 이루어지기 때문입니다. (예: 3.9.5 → 3.9.x → 3.10.x → 3.11.3)
2. Queue Federation 설정
기존 클러스터의 관리자 콘솔에서 “Queue Federation” 정책을 설정합니다.
- Queue Federation 동작 방식은 다음과 같습니다.
- 새 클러스터의 메시지를 먼저 조회
- 메시지가 없다면 기존 클러스터의 메시지를 조회하여 가져옴
- 이렇게 하면 중복 메시지 없이, 새 클러스터에서도 기존 클러스터의 메시지를 조회 가능합니다.
- 클러스터 전체를 옮기는 작업이므로, 모든 큐에 설정하였습니다.
3. Consumer 애플리케이션 설정 변경
Consumer 애플리케이션들의 RabbitMQ 설정을 새 클러스터로 먼저 변경합니다.
- Consumer 애플리케이션은 Rolling Update 중에도 요청을 정상적으로 처리합니다.
- 기존 클러스터 설정이라면 직접 조회
- 새 클러스터 설정이라면 새 클러스터에서 기존 클러스터의 메시지를 끌어옴
- 단, Graceful Shutdown과 Retry 로직 등 확인은 필요합니다.
4. Producer 애플리케이션 설정 변경
웹 애플리케이션 등 Producer의 설정을 새 클러스터로 변경합니다.
Consumer보다 나중에 변경하여 기존 메시지 누수가 없도록 합니다.
5. 정리 작업
기존 클러스터의 큐가 모두 소비된 것을 확인한 후, 기존 클러스터를 삭제합니다.
실제 작업
Queue Federation이 제대로 동작하지 않거나, 더 세밀한 제어가 필요할 경우 Shovel을 사용할 수 있습니다.
단, 다음 사항을 주의해야 합니다.
- Shovel은 큐별로 지정해야 합니다.
- Wildcard를 지원하지 않습니다.
기타 고려사항
- Federation에는 크게 두 가지가 있습니다.
- Queue Federation: 사용한 방식, 새 클러스터에서 기존 클러스터의 메시지를 가져옵니다.
- Exchange Federation: 기존 클러스터의 메시지를 새 클러스터에 복제하는 방식입니다. 여기서는 사용하지 않았습니다.
- 트래픽이 적은 시간대(주말 등)에 진행하여 예기치 못한 데이터 유실을 최소화합니다.