[BE] RabbitMQ 장애 - 메시지 중복 처리, 메모리 부족, 디스크 공간 부족

저번 글에서 잠시 다루었지만, RabbitMQ를 쓰다보면 만날 수 있는 대표적인 장애 시나리오이다.

 

1. 메시지 중복 처리

메시지를 최소 한 번 이상 전달을 하기 위해서는 ack 신호를 메시지 브로커에 전달해야 한다.

하지만 메시지를 소비한 이후, 장애가 발생하여 ack 신호를 메시지 브로커에 전달하지 못하는 경우가 있다.

이런 경우 메시지 브로커는 큐에서 해당 메시지를 제거하지 않는다.

서버는 장애에서 회복된 후, 서버에서 메시지를 새로 꺼내서 소비하게되고 이런 시나리오에서 중복 처리가 발생할 수 있다.

 

2. 메모리 부족

큐에 쌓이는 메시지가 처리되는 메시지보다 많을 경우, 특히 non-persistent의 경우

많은 수의 연결과 채널이 존재하는 경우 메모리 부족 문제가 발생할 수 있다.

메시지를 가능한 한 디스크에 저장하는 Lazy Queues 사용을 고려하고, 메시지에 TTL(Time-To-Live) 등을 설정하는 방법도 있다.

또한 메시지를 소비자를 증설하거나 성능 개선이 필요하기도 하다.

 

무엇보다도 메모리 부족 알림을 받을 수 있게 모니터링을 수행해서 대비하는 것이 중요하다.

 

3. 디스크 공간 부족

Persistent 메시지가 큐에 계속 쌓이면서 디스크에 기록되는 경우

RabbitMQ의 로그파일의 크기가 늘어나는 경우 디스크 공간 부족이 발생할 수 있다.

 

이 역시 메시지의 소비를 증가시키고, 오래된 메시지를 처리하거나 삭제하는 정책이 필요하다.(TTL, Max-Length)

디스크 사용량을 모니터링하며 대비하는 것이 가장 중요하다.

 

---

RabbitMQ에는 자체적인 모니터링 도구가 존재한다.

 

1. RabbitMQ Management Plugin

가장 기본적인 모니터링 방법, 웹 UI에서 노드 상태, 메모리 사용량, 디스크 공간, 연결 수, 채널 수, 큐 메시지 수 등을 시각적으로 확인한다.

memory alarm, disk alarm 발생 여부도 바로 표시된다.

HTTP API도 제공하므로 다른 모니터링 시스템에서 이 API를 호출하여 정보를 가져올 수도 있다.

 

2. rabbitmqctl CLI 도구

커맨드 라인을 통해 서버 상태를 확인할 수 있다. 

ex: rabbitmqctl status : 메모리 및 디스크 알람 상태, rabbitmqctl list_queues name message memory

 

---

그 외에도 SpringBoot 시스템에서 많이 사용되는 모니터링 스택들과 연동할 수 있다.

 

1. Prometheus + Grafana 연동

이 조합은 실시간 메트릭 수집 및 시각화가 탁월하며, RabbitMQ 모니터링에도 널리 사용된다.

 

[사용 방법]

1) RabbitMQ Prometheus Plugin: 이 플러그인을 활성화하면, RabbitMQ의 다양한 내부 메트릭을 프로메테우스가 수집할 수 있다.

2) Prometheus: 설정된 주기로 RabbitMQ의 /metrics 엔드포인트를 스크래핑하여 매트릭을 수집하고 시계열 DB에 저장한다.

3) Grafana: 프로메테우스를 데이터 소스로 연결하여, 수집된 메트릭을 그래프, 대시보드 형태로 시각화한다. 다양한 템플릿이 존재한다.

4) Alertmanager: 프로메테우스와 연동하여 특정 메트릭 임계치에 도달하면 알림을 받을 수 있다.

 

 

 

2. ELK (Elasticsearch, Logstash, Kibana) 스택 연동

ELK 스택은 주로 로그 수집 및 분석에 사용되지만, 메트릭 수집 및 시각화도 가능하다.

 

[사용 방법 - 로그 기반]

1) Logstash: RabbitMQ 로그 파일을 수집한다. 로그에는 메모리/디스크 알람 발생, 해제, flow control 활성화 등의 중요 정보가 있다.

2) Elasticsearch: 수집된 로그를 저장하고 인덱싱한다.

3) Kibana: Elasticsearch에 저장된 로그를 검색, 분석하고 대시보드를 통해 시각화한다.

 

[사용 방법 - 메트릭 기반]

1) Metricbeat: Elastic Stack의 일부로, 경량 데이터 수집기이다. Metricbeat에는 RabbitMQ 모듈이 포함되어 있어, RabbitMQ Management Plugin의 HTTP API를 통해 메트릭을 주기적으로 수집하여 Elasticsearch로 직접 전송할 수 있다.

2) Elasticsearch: 수집된 메트릭을 저장한다.

3) Kibana: 메트릭 기반으로 대시보드를 구성하여 RabbitMQ 상태를 모니터링한다.

 

 

 

---

모니터링은 개발을 하면 할수록 중요성을 많이 느끼고 있다.

나는 주로 SI에서 일했다보니 로그를 분석하여 장애가 발생한 것을 시간에 따라 추적하는 것은 잘하는 편이다.

하지만, 실시간으로 장애가 발생하는 것을 대비하는 것은 약한 편이다.

 

모니터링은 노트북으로 직접 서버를 띄워두고 익숙해지기 위해 노력해야겠다.

만약 이런 도구를 조금 더 일찍 공부해서 사용했다면 이직할 때 더 많은 내용을 썼을텐데...

아쉽지만 지금이라도 공부해서 적용해야겠다.