DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

RabbitMQ 메모리 알람 이해 및 효과적인 해결 방법

RabbitMQ 메모리 알람을 이해하고, 압력을 유발하는 큐나 클라이언트를 찾아내며, 근본 원인을 숨기지 않고 안전하게 메모리를 줄이는 방법을 알아봅니다.

RabbitMQ 메모리 알람 이해 및 효과적인 해결 방법

RabbitMQ는 강력하고 다재다능한 메시지 브로커로, 비동기 통신을 지원하여 현대 애플리케이션 아키텍처에서 중요한 역할을 합니다. 그러나 상당한 리소스를 관리하는 다른 소프트웨어와 마찬가지로 문제가 발생할 수 있습니다. 가장 중요하고 잠재적으로 파괴적인 문제 중 하나는 메모리 알람의 트리거입니다. 이러한 알람은 RabbitMQ 브로커가 메모리 부족으로 인해 불안정, 응답 없음 및 데이터 손실로 이어질 수 있는 상황을 방지하기 위해 설계되었습니다. 이 가이드에서는 RabbitMQ 메모리 알람의 원인, 해석 방법, 해결 및 예방을 위한 실용적이고 실행 가능한 단계를 제공하여 메시징 인프라의 원활한 운영을 보장합니다.

메모리 알람을 이해하는 것은 건강한 RabbitMQ 배포를 유지하는 데 중요합니다. RabbitMQ의 메모리 사용량이 미리 정의된 임계값을 초과하면 '위험' 상태가 되어 알람이 트리거됩니다. 이 상태는 게시자 차단, 새 연결 방지, 그리고 적시에 해결되지 않으면 브로커 충돌 가능성 등 다양한 결과를 초래할 수 있습니다. 사전 예방적 모니터링과 효과적인 문제 해결이 이러한 위험을 완화하는 핵심입니다.

RabbitMQ 메모리 알람이란?

RabbitMQ는 메모리를 사용하여 메시지를 버퍼링하고, 채널 상태를 저장하며, 연결을 관리하고, 내부 데이터 구조를 유지합니다. 브로커가 사용 가능한 모든 시스템 메모리를 소비하여 충돌을 일으키는 것을 방지하기 위해 RabbitMQ는 메모리 임계값 알람을 구현합니다. 이러한 알람은 사용 가능한 총 시스템 메모리를 기준으로 구성됩니다.

운영자가 주로 다루는 주요 임계값은 메모리 상위 워터마크입니다. RabbitMQ 메모리 사용량이 해당 워터마크에 도달하면 노드가 메모리 알람을 발생시키고 흐름 제어를 적용하기 시작하며, 가장 눈에 띄게 게시자를 차단합니다. 정확한 세부 사항은 RabbitMQ 버전 및 큐 유형에 따라 다를 수 있으므로 알람을 별도의 '경고' 및 '위험' 쌍이 아닌 보호적인 역압 신호로 취급하십시오.

이러한 알람은 RabbitMQ 관리 UI에서 볼 수 있으며 HTTP API 또는 명령줄 도구를 통해 모니터링할 수 있습니다.

RabbitMQ 메모리 알람의 원인

여러 요인이 RabbitMQ가 메모리 한도를 초과하고 알람을 트리거하는 데 기여할 수 있습니다. 이러한 근본 원인을 이해하는 것이 효과적인 해결의 첫 단계입니다.

1. 메시지 축적(확인되지 않은 메시지)

이는 아마도 가장 일반적인 원인일 것입니다. 메시지가 소비되는 속도보다 빠르게 큐에 게시되면 메시지가 메모리에 축적됩니다. RabbitMQ는 소비자가 확인할 때까지 메시지 내용을 메모리에 보관합니다. 특히 대용량 메시지의 경우 확인되지 않은 메시지가 많으면 사용 가능한 메모리가 빠르게 고갈될 수 있습니다.

2. 대용량 메시지 페이로드

빠르게 소비되더라도 매우 큰 메시지를 게시하면 브로커가 이러한 메시지를 버퍼링해야 하므로 상당한 메모리 부담이 발생할 수 있습니다. RabbitMQ는 다양한 메시지 크기를 처리하도록 설계되었지만, 예외적으로 큰 페이로드가 지속적으로 대량으로 발생하면 사용 가능한 메모리를 압도할 수 있습니다.

3. 메모리 누수 또는 비효율적인 소비자

덜 일반적이지만, 사용자 정의 플러그인, Erlang VM 자체의 메모리 누수 또는 비효율적인 소비자 로직(예: 필요 이상으로 메시지 객체를 보유)은 점진적인 메모리 증가에 기여할 수 있습니다.

4. 많은 수의 채널 또는 연결

각 연결과 채널은 소량의 메모리를 소비합니다. 일반적으로 자체적으로 알람의 주요 원인이 되지는 않지만, 매우 많은 수의 연결과 채널은 다른 요인과 결합되어 전체 메모리 사용량에 추가될 수 있습니다.

5. 비효율적인 큐 구성

특정 큐 구성, 특히 디스크로 페이지 아웃되는 많은 메시지가 있거나 상당한 메모리 내 상태가 필요한 기능을 사용하는 구성은 간접적으로 메모리 사용량에 영향을 미칠 수 있습니다.

6. 불충분한 시스템 메모리

때로는 가장 간단한 설명은 RabbitMQ를 호스팅하는 서버에 워크로드에 필요한 RAM이 충분히 할당되지 않았다는 것입니다. 이는 리소스 제한이 더 엄격할 수 있는 가상화 또는 컨테이너화된 환경에서 특히 관련이 있습니다.

메모리 사용량에 대한 주요 지표 모니터링

사전 예방적 모니터링은 필수적입니다. RabbitMQ는 메모리 사용량을 검사하는 여러 방법을 제공합니다. 가장 일반적인 방법은 다음과 같습니다.

1. RabbitMQ 관리 UI

관리 UI는 브로커 상태에 대한 시각적 개요를 제공합니다. '개요' 탭으로 이동하면 '노드 상태' 섹션이 표시됩니다. 메모리 알람이 활성화된 경우 빨간색 표시기와 함께 눈에 띄게 표시됩니다.

2. 명령줄 인터페이스(CLI) 도구

RabbitMQ는 시스템 관리를 위한 rabbitmqctl 명령을 제공합니다. 다음 명령이 특히 유용합니다.

  • rabbitmqctl status: 이 명령은 메모리 사용량을 포함한 브로커에 대한 풍부한 정보를 제공합니다. memory 및 mem_used 필드를 찾으십시오.

    rabbitmqctl status

    출력 예시:

    [...] 
node              : rabbit@localhost
core
  ...
memory
  total                     : 123456789 bytes
  heap_used                 : 98765432 bytes
  avg_heap_size             : 10000000 bytes
  processes_used            : 1234567 bytes
  ... 
...

  • rabbitmq-diagnostics memory_breakdown: 이 명령은 원시 환경 덤프보다 카테고리별로 메모리 사용량을 그룹화하기 때문에 종종 더 유용합니다.

    rabbitmq-diagnostics memory_breakdown

3. HTTP API

RabbitMQ는 메모리 사용량을 포함한 브로커 상태를 프로그래밍 방식으로 쿼리할 수 있는 포괄적인 HTTP API를 제공합니다.

  • 노드 세부 정보: GET /api/nodes/{node}

    curl http://localhost:15672/api/nodes/rabbit@localhost

    응답에서 mem_used, mem_limit 및 활성 알람 정보와 같은 필드를 찾으십시오. 필드 이름은 버전에 따라 다를 수 있으므로 설치된 RabbitMQ API 출력을 확인하십시오.

  • 메모리 알람: GET /api/overview 이 엔드포인트는 알람 상태를 포함한 노드 상태 요약을 제공합니다.

RabbitMQ 메모리 알람 해결

메모리 알람이 트리거되면 브로커를 정상 상태로 복원하고 추가 문제를 방지하기 위해 신속한 조치가 필요합니다. 일반적인 해결 단계는 다음과 같습니다.

1. 높은 메모리 사용량의 원인 식별

  • 큐 깊이 검사: 관리 UI 또는 rabbitmqctl list_queues name messages_ready messages_unacknowledged를 사용하여 특히 messages_unacknowledged 열에서 많은 수의 메시지가 있는 큐를 식별합니다.
    rabbitmqctl list_queues name messages_ready messages_unacknowledged
  • 메시지 크기 검사: 가능하면 문제가 있는 큐의 메시지 크기를 조사합니다. 이를 위해서는 생산자/소비자 수준에서 사용자 정의 모니터링 또는 로깅이 필요할 수 있습니다.
  • 소비자 활동 확인: 소비자가 메시지를 적극적으로 처리하고 신속하게 확인하고 있는지 확인하십시오. 느리거나, 차단되었거나, 중지된 소비자가 있는지 찾아보십시오.

2. 메모리 부하 감소

  • 소비자 확장: 메시지 축적을 줄이는 가장 효과적인 방법은 영향을 받는 큐에서 메시지를 처리하는 소비자 수를 늘리는 것입니다. 여기에는 소비자 애플리케이션의 인스턴스를 더 많이 배포하는 것이 포함될 수 있습니다.
  • 소비자 로직 최적화: 비효율성이 있는지 소비자 코드를 검토하십시오. 메시지가 성공적으로 처리되는 즉시 확인되고 필요 이상으로 메시지 객체를 보유하지 않도록 하십시오.
  • 문제가 있는 큐 지우기(주의해서): 큐에 더 이상 필요하지 않은 관리할 수 없는 수의 메시지가 축적된 경우 큐를 지우는 것을 고려할 수 있습니다. 이는 관리 UI 또는 rabbitmqctl purge_queue <queue_name>을 사용하여 큐를 비워 수행할 수 있습니다. 경고: 이 작업은 큐의 모든 메시지를 영구적으로 삭제합니다. 애플리케이션의 데이터 무결성에 안전한지 확인하십시오.
    rabbitmqctl purge_queue my_problematic_queue
  • 데드 레터링 및 TTL 구현: TTL(Time-To-Live) 및 DLX(Dead Letter Exchange)에 대한 정책을 구성하여 너무 오래 큐에 있거나 처리할 수 없는 메시지를 자동으로 만료시키거나 이동시킵니다. 이는 무한 축적을 방지합니다.

3. RabbitMQ 구성 조정

  • 메모리 워터마크 신중하게 증가: 서버 또는 컨테이너에 실제로 여유 RAM이 있는 경우 구성된 메모리 상위 워터마크를 높일 수 있습니다. 최신 RabbitMQ 구성에서는 일반적으로 rabbitmq.conf에서 설정합니다.

    vm_memory_high_watermark.relative = 0.5

    일부 이전 배포에서는 환경 파일이나 레거시 구성 형식을 사용합니다. 편집하기 전에 설치된 버전을 확인하십시오. 워터마크를 높이면 시간을 벌 수 있지만, 중단된 소비자, 과도하게 큰 페이로드 또는 무제한 큐를 해결하지는 않습니다.

  • Erlang VM 설정 조정: 고급 사용자의 경우 Erlang VM 가비지 수집 및 메모리 설정을 조정하면 추가 최적화를 제공할 수 있습니다.

4. 시스템 리소스 증가

  • RAM 추가: 가능하다면 RabbitMQ를 실행하는 서버에 사용 가능한 물리적 RAM을 늘리는 것이 가장 간단한 해결책입니다.
  • 부하 분산: 여러 노드에 RabbitMQ를 클러스터링하여 부하와 메모리 사용량을 분산하는 것을 고려하십시오.

향후 메모리 알람 방지

알람에 대응하는 것보다 예방하는 것이 항상 좋습니다. 다음 모범 사례를 구현하십시오.

1. 강력한 소비자 모니터링

소비자 처리량 및 확인 속도를 지속적으로 모니터링하십시오. 느린 소비자 또는 처리를 중지한 소비자에 대한 알림을 설정하십시오.

2. 속도 제한 구현

메시지 생성에 예측할 수 없는 급증이 있는 경우 생산자 측에서 속도 제한을 구현하거나 RabbitMQ의 흐름 제어 메커니즘을 사용하여 브로커에 과부하가 걸리는 것을 방지하십시오.

3. 정기적인 큐 감사

주기적으로 큐 깊이와 메시지 속도를 검토하십시오. 지속적으로 크게 증가하는 큐를 식별하고 해결하십시오.

4. 메시지 수명 주기 관리

TTL 및 DLX 정책을 활용하여 메시지가 불필요하게 큐에 영원히 남지 않도록 하십시오.

5. 리소스 계획

예상 워크로드를 기반으로 RabbitMQ 노드에 RAM이 적절하게 프로비저닝되었는지 확인하십시오. 급증에 대한 버퍼를 고려하십시오.

6. 정상 종료 절차

메시지를 게시하거나 소비하는 애플리케이션에 대한 정상 종료 절차를 구현하여 서비스가 다시 시작될 때 너무 많은 확인되지 않은 메시지가 남지 않도록 하십시오.

실제 알람의 의미

RabbitMQ 메모리 알람은 대시보드 경고만이 아닙니다. 브로커 동작을 변경합니다. 브로커는 메모리 사용량이 더 이상 증가하지 않도록 게시자에게 역압을 적용하여 스스로를 보호합니다. 생산자 측면에서 이는 느린 게시, 차단된 연결, 지연된 확인 또는 클라이언트 라이브러리 호출 내에서 대기하는 애플리케이션 스레드처럼 보일 수 있습니다.

이러한 동작은 의도적입니다. RabbitMQ가 운영 체제가 프로세스를 종료할 때까지 제한 없이 메시지를 수락했다면 결과는 더 나빴을 것입니다. 알람은 브로커가 "소비자가 따라잡아야 하고, 메시지를 디스크로 이동해야 하며, 게시자가 속도를 늦춰야 합니다"라고 말하는 것입니다.

이것이 첫 번째 반응이 "RabbitMQ 재시작"이 되어서는 안 되는 이유입니다. 재시작은 일시적으로 일부 메모리를 지울 수 있지만, 소비자를 중단시키고, 재전송을 트리거하며, 동일한 백로그가 문제를 재현하기 위해 기다리게 할 수 있습니다. 절충점을 이해하거나 노드가 이미 통제된 재시작이 최악의 선택이 아닐 정도로 불건전한 경우에만 재시작하십시오.

브로커를 변경하기 전에 큐를 찾으십시오

메모리 알람은 일반적으로 눈에 띄는 원인이 있습니다. 큐 깊이와 확인되지 않은 메시지부터 시작하십시오.

rabbitmqctl list_queues name durable type messages_ready messages_unacknowledged consumers memory

memory 열은 모든 버전에서 사용 가능하거나 큐 유형에 따라 다르게 동작하지 않을 수 있지만, 사용 가능할 때 유용한 힌트를 제공합니다. 또한 메시지 속도를 확인하십시오.

rabbitmqctl list_queues name \
  message_stats.publish_details.rate \
  message_stats.deliver_get_details.rate \
  message_stats.ack_details.rate

패턴은 무슨 일이 일어나고 있는지 알려줍니다.

  • messages_ready가 높고 전달 속도가 낮으면 소비자가 없거나, 중지되었거나, 너무 느리다는 것을 의미합니다.
  • messages_unacknowledged가 높으면 소비자가 메시지를 수신했지만 빠르게 확인하지 않고 있음을 의미합니다.
  • 게시 속도가 높고 확인 속도가 낮으면 시스템이 소비되는 것보다 빠르게 채워지고 있음을 의미합니다.
  • 명백한 큐 증가는 없지만 메모리가 높으면 많은 연결, 채널, 플러그인 또는 큰 진행 중인 메시지를 가리킬 수 있습니다.

vhost 소유권을 잊지 마십시오. 공유 RabbitMQ 클러스터에서 한 팀의 큐는 동일한 노드의 다른 워크로드에 대한 게시자를 차단하는 알람을 트리거할 수 있습니다.

확인되지 않은 메시지는 다른 문제입니다

준비된 메시지가 많은 큐는 RabbitMQ에서 작업이 대기 중임을 의미합니다. 확인되지 않은 메시지가 많은 큐는 작업이 소비자와 함께 있음을 의미합니다. 이 차이는 해결 방법을 변경합니다.

messages_unacknowledged가 높으면 더 많은 게시자를 추가하거나 큐 TTL을 변경해도 큰 도움이 되지 않습니다. 소비자를 살펴보십시오.

  • 다운스트림 데이터베이스나 API에 막혀 있습니까?
  • 배포 시 basic_ack 전에 버그가 발생했습니까?
  • 프리페치가 너무 높아 소수의 소비자가 너무 많은 작업을 보유하고 있습니까?
  • 소비자는 살아 있지만 스레드 부족이나 연결 풀 고갈로 인해 차단되었습니까?

프리페치를 낮추면 진행 중인 전달에 묶인 메모리 양을 줄이고 분배를 더 공평하게 만들 수 있습니다. 느린 비즈니스 로직을 빠르게 만들지는 않지만, 하나의 불량 소비자가 큐의 큰 부분을 독점하는 것을 방지할 수 있습니다.

한 번에 하나의 메시지를 처리하는 작업자의 경우 낮은 프리페치 값으로 충분한 경우가 많습니다. 내부 동시성이 있는 작업자의 경우 임의의 큰 숫자보다는 실제 병렬 처리와 일치하는 값을 선택하십시오.

대용량 페이로드 및 백로그

대용량 메시지는 진행 중이거나 버퍼링된 각 메시지의 가중치가 더 크기 때문에 메모리 알람 가능성을 높입니다. 메시지에 이미지, 보고서, 문서 또는 대용량 JSON 블롭이 포함된 경우 RabbitMQ는 객체 스토리지에서 더 잘 처리되는 작업을 수행하고 있을 수 있습니다.

일반적인 재설계는 페이로드를 다른 곳에 저장하고 RabbitMQ를 통해 작은 참조를 보내는 것입니다.

{
  "event": "report.ready",
  "report_id": "rpt_7782",
  "location": "s3://internal-reports/rpt_7782.json"
}

이 설계에는 여전히 정리 규칙과 액세스 제어가 필요하지만, 큐 백로그가 대용량 페이로드 스토리지 문제가 되는 것을 방지합니다.

백로그에는 정직한 비즈니스 결정도 필요합니다. 큐에 더 이상 유용하지 않은 오래된 상태 업데이트가 포함된 경우 TTL 정책이 적절할 수 있습니다. 고객 주문이 포함된 경우 삭제는 데이터 손실이 됩니다. 브로커가 이를 결정할 수 없습니다.

인시던트 중 메모리를 안전하게 줄이는 방법

알람이 활성화된 경우 가장 덜 파괴적인 방법부터 가장 파괴적인 방법까지 작업하십시오.

첫째, 소비자를 복원하십시오. 소비자가 중지된 경우 다시 시작하십시오. 프로비저닝이 부족한 경우 복제본을 추가하십시오. 다운스트림 서비스에 막힌 경우 비즈니스 프로세스가 허용한다면 해당 종속성을 수정하거나 우회하십시오.

둘째, 생산자를 늦추십시오. 많은 애플리케이션이 브로커 중단보다 일시적인 속도 제한을 더 잘 견딥니다. 생산자가 백오프를 지원하는 경우 켜거나 게시 속도를 낮추십시오.

셋째, 잘못된 메시지를 기본 경로에서 이동하십시오. 하나의 독성 메시지로 인해 소비자가 반복적으로 실패하는 경우 진행을 차단하는 대신 데드 레터링하십시오. DLQ가 모니터링되는지 확인하십시오.

넷째, 소유자가 데이터를 폐기 가능하다고 확인한 경우에만 삭제하십시오. 다음을 실행하십시오.

rabbitmqctl purge_queue queue_name

결과를 이해한 후에만 실행하십시오. 감사, 결제, 주문, 재고 및 보안 워크플로의 경우 삭제는 일반적으로 허용 가능한 첫 번째 대응이 아닙니다.

다섯째, 워크로드가 합법적이고 노드에 여유 공간이 있는 경우 워터마크를 높이거나 메모리를 추가하십시오. 컨테이너에서 RabbitMQ는 버전 및 cgroup 지원에 따라 메모리를 다르게 볼 수 있음을 기억하십시오. 명시적인 리소스 제한을 설정하고 브로커가 이를 어떻게 보고하는지 테스트하십시오.

지연 큐, 쿼럼 큐 및 버전 차이

일부 RabbitMQ 기능은 메모리 동작을 변경합니다. 지연 클래식 큐는 더 많은 메시지를 디스크에 유지하고 긴 백로그에 대한 메모리 압력을 줄이도록 설계되었습니다. 최신 RabbitMQ 버전에서는 큐 동작과 기본값이 발전했으며, 쿼럼 큐에는 자체 스토리지 및 복제 모델이 있습니다.

안전한 조언은 워크로드와 RabbitMQ 버전을 기반으로 큐 유형을 선택한 다음 실제 부하에서 백로그 동작을 테스트하는 것입니다. 1,000개의 작은 메시지로 빠른 큐는 수백만 개의 메시지 또는 더 큰 페이로드에서 매우 다르게 동작할 수 있습니다. 운영 단계와 실패 모드를 이미 알지 않는 한 인시던트 중에 큐 유형을 마이그레이션하지 마십시오.

실제로 작동하는 예방

최상의 예방은 단일 더 큰 워터마크가 아닙니다. 비즈니스와 일치하는 일련의 제한입니다.

  • 준비된 메시지 및 확인되지 않은 메시지에 대한 큐별 알림
  • 게시자 차단에 대한 알림
  • 소비자 지연 대시보드
  • 소유자 및 보존 규칙이 있는 DLQ
  • 폐기 가능한 메시지에 대한 TTL 정책
  • 오래된 메시지를 삭제하거나 데드 레터링하는 것이 허용되는 최대 길이 정책
  • 행복한 경로 처리량뿐만 아니라 소비자 중단을 포함하는 부하 테스트

각 중요한 큐에 대해 소비자가 10분, 1시간 또는 하루 동안 다운되었을 때 어떤 일이 발생해야 하는지 문서화하십시오. 일부 큐는 백로그를 흡수해야 합니다. 일부는 오래된 메시지를 버려야 합니다. 일부는 데이터가 뒤처지기에는 너무 중요하기 때문에 신속하게 사람에게 알려야 합니다.

최종 확인

RabbitMQ 메모리 알람이 발생하면 한도만 높여서 숨기지 마십시오. 노드를 역압 상태로 만든 큐, 클라이언트, 페이로드 또는 소비자 실패를 찾으십시오. 지속적인 수정은 일반적으로 세 가지 중 하나입니다. 작업을 더 빨리 소진하거나, 시스템이 처리할 수 있는 것보다 더 많은 작업을 수락하지 않거나, 영원히 기다려서는 안 되는 메시지의 수명 주기를 변경하는 것입니다.