RabbitMQ 리드·아키텍트 배포·운영 면접

먼저 RabbitMQ 버전 간 호환성 매트릭스를 확인하여 직접 업그레이드 가능 여부를 판단합니다. 3.8에서 3.12로의 직접 업그레이드가 가능하다면 롤링 업그레이드 방식을 채택하되, 클러스터의 한 노드씩 순차적으로 업그레이드하며 각 노드가 안정화된 후 다음 노드로 진행합니다. 업그레이드 전 모든 큐를 quorum queue로 마이그레이션하여 데이터 안정성을 확보하고, feature flag를 활용해 새 기능을 점진적으로 활성화합니다. 각 단계마다 메시지 처리율, 큐 길이, 클러스터 상태를 모니터링하며, 이상 징후 발견 시 즉시 이전 버전으로 롤백할 수 있도록 각 노드의 데이터 디렉토리 백업을 유지합니다. Producer와 Consumer 클라이언트 라이브러리도 새 버전과 호환되는지 사전 검증하고, 필요시 클라이언트 업그레이드를 서버 업그레이드 전에 선행합니다. 최종적으로 전체 업그레이드 완료 후 1-2주간 모니터링 기간을 두고, 문제 없을 시 백업 데이터를 정리합니다.

먼저 Pod Topology Spread Constraints를 설정하여 RabbitMQ Pod들이 각 가용영역에 균등하게 분산되도록 하고, podAntiAffinity를 통해 동일 노드에 여러 RabbitMQ Pod가 배치되지 않도록 합니다. 스토리지는 각 가용영역별로 Local Persistent Volume을 사용하거나, 가용영역 제약이 있는 StorageClass를 정의하여 Pod와 PVC가 항상 같은 영역에 유지되도록 nodeAffinity를 설정합니다. RabbitMQ의 peer discovery는 Kubernetes API 기반 플러그인을 사용하여 Pod 재시작 시 자동으로 클러스터에 재조인되도록 구성하고, readinessProbe와 livenessProbe를 적절히 설정하여 클러스터 동기화 완료 전에는 트래픽을 받지 않도록 합니다. Init Container를 활용해 클러스터 조인 전 필요한 전제조건을 체크하고, PreStop Hook을 통해 Pod 종료 시 graceful shutdown을 보장합니다. 추가로 Operator 패턴(예: RabbitMQ Cluster Operator)을 도입하여 클러스터 상태 모니터링, 자동 복구, 설정 관리를 자동화하고, 장애 시 수동 개입을 최소화합니다.

먼저 RabbitMQ Prometheus Exporter를 통해 노드 레벨 메트릭(메모리 사용률, 디스크 여유 공간, file descriptor 사용량, connection/channel 수)과 큐 레벨 메트릭(메시지 적재량, publish/deliver rate, consumer 수, unacked 메시지 수)을 수집합니다. 메모리 사용률이 80% 초과 시 경고, 90% 초과 시 긴급 알림을 발송하고, 디스크 여유 공간이 20% 미만일 때 알림을 설정합니다. 큐별로 메시지 적재량이 평소 대비 3배 이상 증가하거나, consumer가 0인 상태가 5분 이상 지속되면 알림을 발생시킵니다. Connection 수가 설정된 최대치의 80%에 도달하면 사전 경고를 보내고, unacked 메시지가 일정 시간 이상 증가 추세를 보이면 consumer 장애로 판단합니다. 자동화된 대응으로는 메모리 임계치 도달 시 Kubernetes HPA를 통해 consumer Pod를 자동 스케일 아웃하거나, 특정 큐의 메시지가 과도하게 쌓이면 Lambda/Cloud Function을 트리거하여 임시 consumer를 생성하는 시나리오를 구현할 수 있습니다. 또한 PagerDuty나 Opsgenie와 연동하여 escalation policy를 설정하고, Runbook 자동화를 통해 일반적인 장애 대응 절차를 코드화합니다.