RabbitMQ 리드·아키텍트 트러블슈팅 면접
새 면접Q. 프로덕션 환경에서 RabbitMQ 클러스터의 메모리 사용률이 급격히 증가하여 메모리 알람이 발생하고, 이후 publisher들이 connection blocked 상태가 되었습니다. 모니터링 결과 특정 큐에 수백만 개의 메시지가 쌓여있고 consumer는 정상 작동 중입니다. 이 상황에서 장애 원인을 진단하고 즉각적인 대응 방안과 재발 방지 전략을 설명해주세요.
메시지가 쌓이는 속도와 소비되는 속도의 불균형, 그리고 메시지 특성에 주목하세요.
먼저 rabbitmqctl list_queues 명령으로 메시지 적재 속도와 소비 속도를 비교하고, 메시지 크기를 확인합니다. Consumer의 prefetch count 설정이 너무 작거나, consumer 처리 로직에 병목이 있어 ack 속도가 느린 것이 원인일 가능성이 높습니다. 즉각 대응으로는 consumer 인스턴스를 스케일 아웃하고, prefetch count를 적절히 증가시키며, 필요시 lazy queue로 전환하여 메시지를 디스크로 이동시킵니다. 중장기적으로는 메시지 TTL 설정, dead letter exchange 구성, consumer 성능 최적화, 그리고 메시지 크기 제한 정책을 수립해야 합니다. 또한 메모리 high watermark를 적절히 설정하고, 알람 임계값을 낮춰 조기 경보 체계를 구축합니다.
- • 메시지 적재/소비 속도 불균형 진단 및 prefetch count 최적화
- • 즉각 대응: consumer 스케일 아웃, lazy queue 전환으로 메모리 압박 완화
- • 재발 방지: TTL, DLX, 메모리 임계값 설정 및 모니터링 체계 강화
대용량 이벤트 처리 시스템에서 갑작스런 트래픽 증가로 메시지가 적재되어 메모리 부족 장애가 발생하는 상황
lazy queue와 일반 queue의 성능 트레이드오프는 무엇이며, 어떤 상황에서 lazy queue 전환을 결정하시겠습니까?
Q. 3노드로 구성된 RabbitMQ 클러스터에서 네트워크 순간 단절 후 split-brain 상황이 발생했습니다. 클러스터가 두 개의 파티션으로 나뉘었고, 각 파티션에서 독립적으로 메시지를 처리하다가 네트워크가 복구되었습니다. 현재 클러스터 상태 확인 시 일부 노드가 정상 조인되지 않고 있습니다. 파티션 모드 설정에 따른 영향을 분석하고, 이 상황에서의 복구 절차와 향후 아키텍처 개선 방안을 제시해주세요.
pause_minority, autoheal, ignore 모드의 동작 방식과 데이터 일관성 측면을 고려하세요.
먼저 rabbitmqctl cluster_status로 파티션 상태를 확인하고, 설정된 partition handling 모드를 점검합니다. pause_minority 모드라면 소수 파티션이 중지되어 데이터 손실은 없지만, autoheal이나 ignore 모드에서는 데이터 불일치가 발생했을 수 있습니다. 복구는 정상 노드를 기준으로 문제 노드를 완전히 리셋(rabbitmqctl forget_cluster_node, stop_app, reset, start_app)하여 재조인시킵니다. 아키텍처 개선으로는 quorum queue를 도입하여 Raft 기반 복제로 일관성을 보장하고, 네트워크를 다중화하며, 홀수 노드 구성과 적절한 파티션 모드(pause_minority 권장)를 설정합니다. 또한 헬스체크와 자동 페일오버 메커니즘을 강화하고, 정기적인 장애 시뮬레이션 훈련을 수행합니다.
- • 파티션 모드별 동작 방식 이해 및 데이터 일관성 영향 분석
- • 문제 노드 리셋 및 재조인을 통한 클러스터 복구
- • quorum queue 도입, 네트워크 다중화, pause_minority 모드 설정으로 재발 방지
멀티 AZ 구성에서 네트워크 장애로 인한 클러스터 분리 및 데이터 불일치 문제 발생 시나리오
classic mirrored queue와 quorum queue의 네트워크 파티션 처리 방식의 차이점과 각각의 장단점을 설명해주세요.
Q. 금융 결제 시스템에서 RabbitMQ를 사용 중인데, 일부 결제 메시지가 유실되는 장애가 간헐적으로 발생했습니다. 로그 분석 결과 publisher는 메시지를 보냈다고 기록하고 있으나 consumer에서 해당 메시지를 받지 못한 경우가 확인되었습니다. RabbitMQ 서버 재시작 이력도 있었고, 일부 consumer에서 exception 발생 후 재시작된 기록도 있습니다. 메시지 유실의 가능한 원인들을 분석하고, 각 지점에서의 내구성 보장 방법과 end-to-end 메시지 신뢰성 확보 전략을 설명해주세요.
publisher, queue, consumer 각 단계에서의 내구성 설정과 확인 메커니즘을 점검하세요.
메시지 유실은 여러 지점에서 발생할 수 있습니다. Publisher 측에서는 publisher confirm 미사용, queue 측에서는 durable=false 설정이나 non-persistent 메시지, 미러링 미설정, consumer 측에서는 auto-ack 사용이나 예외 처리 미흡이 원인입니다. 해결책으로 publisher에는 confirm mode와 mandatory flag를 활성화하고, queue는 durable로 선언하며 메시지는 persistent로 발행합니다. Quorum queue나 classic queue의 경우 적절한 복제 설정을 구성하고, consumer는 manual ack를 사용하며 처리 완료 후에만 ack를 보냅니다. End-to-end 신뢰성을 위해 멱등성 키 기반 중복 제거, 재시도 메커니즘, dead letter queue 구성, 그리고 메시지 추적 로깅 시스템을 구축합니다. 정기적인 메시지 감사와 reconciliation 프로세스도 필요합니다.
- • publisher confirm, durable queue, persistent message, manual ack 등 각 단계별 내구성 설정
- • quorum queue 또는 미러링을 통한 복제 보장
- • 멱등성 키, DLQ, 메시지 추적 시스템을 통한 end-to-end 신뢰성 확보
결제, 주문 등 크리티컬한 비즈니스 데이터를 처리하는 시스템에서 메시지 유실로 인한 데이터 불일치 문제
publisher confirm과 transaction 방식의 성능 차이와 각각의 적합한 사용 시나리오를 설명해주세요.
Q. 마이크로서비스 환경에서 RabbitMQ 서버의 connection 수가 설정된 최대치에 도달하여 새로운 클라이언트가 연결할 수 없는 장애가 발생했습니다. 모니터링 결과 대부분의 connection이 ESTABLISHED 상태이며, 일부 서비스는 connection을 정상적으로 닫지 않고 있는 것으로 보입니다. 또한 일부 connection은 idle 상태로 오랜 시간 유지되고 있습니다. 이 상황의 원인을 진단하고, 즉각적인 해결 방법과 애플리케이션 레벨 및 인프라 레벨에서의 개선 방안을 제시해주세요.
connection과 channel의 올바른 관리 패턴과 connection pooling 전략을 고려하세요.
rabbitmqctl list_connections 명령으로 connection별 channel 수, 상태, idle 시간을 분석합니다. 원인은 애플리케이션에서 connection을 요청마다 생성하거나, 예외 발생 시 close하지 않거나, connection pool 미사용 또는 잘못된 설정 때문입니다. 즉각 대응으로는 zombi connection을 강제 종료하고, connection limit을 임시 증가시킵니다. 애플리케이션 레벨에서는 connection pooling을 구현하여 connection을 재사용하고, channel을 thread-local로 관리하며, try-finally로 자원을 확실히 해제합니다. 인프라 레벨에서는 heartbeat 설정으로 dead connection을 감지하고, connection timeout과 idle timeout을 설정하며, 서비스별 connection quota를 관리합니다. HAProxy나 로드밸런서를 통한 connection 분산도 고려합니다.
- • connection 재사용을 위한 connection pooling 구현 및 channel의 적절한 생명주기 관리
- • heartbeat, timeout 설정으로 dead connection 자동 정리
- • 서비스별 connection quota 관리 및 모니터링 강화
MSA 환경에서 서비스 수 증가로 인한 connection 고갈 및 신규 서비스 배포 실패 상황
connection과 channel의 차이점과 각각의 올바른 사용 패턴, 그리고 멀티스레드 환경에서의 주의사항을 설명해주세요.
Q. 실시간 알림 서비스에서 RabbitMQ를 통한 메시지 전달 지연이 평소 수십 ms에서 수 초로 증가하는 성능 저하가 발생했습니다. CPU와 메모리는 여유가 있지만, disk I/O 사용률이 높고, management UI 접속도 느려졌습니다. 큐에는 수십만 개의 메시지가 쌓여있고, message rate는 높지만 처리량이 기대치에 못 미칩니다. 이 성능 저하의 원인을 다각도로 분석하고, 병목 지점 파악 방법, 튜닝 포인트, 그리고 아키텍처 레벨의 개선 방안을 제시해주세요.
paging, flow control, disk I/O, 그리고 메시지 persistence와의 관계를 살펴보세요.
높은 disk I/O는 메모리 부족으로 인한 메시지 paging 때문일 가능성이 높습니다. rabbitmqctl list_queues memory를 통해 메모리 사용을 확인하고, 큐가 메모리 임계값을 넘어 디스크로 paging되는지 점검합니다. Management plugin도 부하를 유발하므로 비활성화를 고려합니다. 병목 해결을 위해 lazy queue로 전환하여 메시지를 디스크에 저장하되 sequential I/O를 활용하고, vm_memory_high_watermark를 조정하며, queue sharding을 통해 부하를 분산시킵니다. Persistent 메시지의 경우 fsync 빈도를 조절하고, SSD 사용을 검토합니다. 아키텍처적으로는 메시지 크기 최적화, batch publishing, consumer prefetch 튜닝, 그리고 캐싱 레이어 도입을 고려합니다. 모니터링은 Prometheus + Grafana로 메트릭을 수집하고 bottleneck을 시각화합니다.
- • 메모리 paging과 disk I/O 병목 관계 파악 및 lazy queue 전환
- • queue sharding, prefetch 튜닝, fsync 최적화를 통한 성능 개선
- • 메시지 크기 최적화, batch 처리, 모니터링 강화를 통한 전체 처리량 향상
실시간 알림, 이벤트 스트리밍 시스템에서 메시지 적재로 인한 지연 증가 및 사용자 경험 저하 상황
대용량 메시지 처리 시스템에서 RabbitMQ와 Kafka 중 선택해야 한다면, 어떤 기준으로 판단하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!