RabbitMQ의 지속형 vs. 임시 큐: 어떤 것을 선택해야 할까?

RabbitMQ 지속형 큐는 브로커 재시작 후에도 유지됩니다. 임시 큐는 그렇지 않습니다. 간단해 보이지만, 많은 장애는 팀이 큐를 지속형으로 만들고 메시지에 자체 지속성 설정이 필요하다는 것을 잊어버리기 때문에 발생합니다.

작업 큐, 알림 팬아웃, 이벤트 파이프라인을 설계할 때 이 차이점을 활용하세요. 올바른 선택은 유지보수 또는 충돌 중에 큐 정의나 전송 중인 메시지의 손실이 허용 가능한지 여부에 따라 달라집니다.

큐 지속성 정의

RabbitMQ에서 지속성은 큐 구조와 메타데이터가 브로커 재부팅 또는 재시작 후에도 유지되는 능력을 의미합니다. 큐가 지속형으로 선언되면 RabbitMQ는 큐 정의(이름, 인수, 바인딩)가 디스크에 기록되도록 보장합니다.

RabbitMQ 서버가 종료되면 지속형 큐는 시작 시 자동으로 다시 생성되어 바인딩을 유지합니다. 그러나 큐 지속성만으로는 메시지 지속성을 보장하지 않는다는 점을 기억하는 것이 중요합니다. 이를 위해서는 개별 메시지에 적용되는 별도의 구성 설정이 필요합니다.

지속형 큐: 지속성과 신뢰성

지속형 큐는 데이터 손실이 허용되지 않는 애플리케이션의 표준 선택입니다. 원시 속도보다 신뢰성을 우선시합니다.

지속형 큐의 특징

1. 재시작 생존: 큐 정의가 브로커 재시작 후에도 유지됩니다.
2. 디스크 지속성: 큐 메타데이터가 디스크에 지속적으로 저장됩니다.
3. 성능 절충: 필요한 디스크 I/O로 인해 선언 및 복구 프로세스가 약간 느립니다.
4. 리소스 사용: 특히 지속형 메시지와 결합할 경우 브로커가 지속적인 저장소를 관리하므로 일반적으로 더 높은 리소스 요구 사항이 있습니다.

지속형 큐를 사용해야 하는 경우

큐 구조가 브로커 인스턴스의 수명 주기 동안 반드시 유지되어야 하고 일반적으로 중요한 데이터와 결합될 때 지속형 큐를 사용하세요.

• 중요 워크플로: 금융 거래, 주문 처리, 작업을 잊어서는 안 되는 중요 비즈니스 로직 처리.
• 장기 실행 작업: 유지보수 기간보다 오래 걸리거나 잠재적인 브로커 다운타임을 포함하는 작업.
• 보장된 전달 시스템: 높은 수준의 메시지 전달 보장을 달성하기 위한 기반으로 필요(지속형 메시지와 결합 시).

지속형 큐 선언

대부분의 클라이언트 라이브러리에서 지속성은 선언 중 부울 플래그를 통해 설정됩니다.

# Pika(Python 클라이언트 라이브러리) 사용 예시
channel.queue_declare(queue='order_processing', durable=True)

⚠️ 경고: 큐 재선언

기존 큐를 다른 지속성 설정으로 재선언하려고 하면 RabbitMQ는 채널 예외(PRECONDITION_FAILED)를 발생시킵니다. 큐가 지속형(또는 임시)으로 정의되면 큐를 먼저 삭제하지 않고는 유형을 변경할 수 없습니다.

임시(비지속형) 큐: 속도와 유연성

임시 큐(비지속형 큐라고도 함)는 수명이 짧은 임시 워크플로를 위해 설계되었습니다. RabbitMQ 4.x는 임시 비독점 클래식 큐를 더 이상 사용하지 않으므로 새 시스템을 설계하기 전에 브로커 버전을 확인하세요.

임시 큐의 특징

1. 재시작 시 손실: 큐 구조는 브로커 종료 또는 재시작 시 즉시 손실됩니다.
2. 본질적으로 일시적: 일반적으로 임시 소비자, 응답 큐 및 다시 생성할 수 있는 데이터에 유용합니다.
3. 재시작 안전성 부족: 브로커 재시작 시 큐와 그 내용이 사라진다고 가정해야 합니다.
4. 버전에 민감함: 새로운 RabbitMQ 버전은 일부 임시 클래식 큐 패턴을 권장하지 않습니다.

임시 큐를 사용해야 하는 경우

임시 큐는 전달하는 데이터를 쉽게 재생성할 수 있거나 현재 큐 내용의 손실이 허용 가능하여 속도와 낮은 대기 시간을 우선시할 때 이상적입니다.

• 실시간 알림: 약간 오래된 데이터가 빠르게 덮어쓰여지거나 재생성되는 라이브 업데이트, 채팅 메시지 또는 주식 시세 데이터 배포.
• 임시 작업 큐: 소비자가 연결을 다시 설정하고 큐를 다시 선언(필요한 경우)해야 하는 임시 소비자 또는 작업자 풀에서 사용.
• 팬아웃/브로드캐스트: 메시지가 많은 임시 소비자에게 브로드캐스트되고 큐 바인딩 손실이 시스템에 중요하지 않은 경우.

임시 큐 선언

임시 큐는 durable 플래그를 False로 설정하거나(또는 생략, False가 기본값인 경우가 많음) 선언됩니다.

# Pika(Python 클라이언트 라이브러리) 사용 예시
# durable=False를 명시적으로 설정
channel.queue_declare(queue='live_notifications', durable=False)

# 또는 기본값(보통 False)에 의존
channel.queue_declare(queue='temp_session_logs')

중요한 차이점: 큐 지속성 vs. 메시지 지속성

큐 지속성과 메시지 지속성은 신뢰할 수 있는 시스템을 달성하기 위해 올바르게 구성해야 하는 두 가지 독립적인 설정이라는 점을 이해하는 것이 중요합니다.

기능	설정	영향	기본 설정
큐 지속성	queue_declare의 durable=True/False	큐 구조가 재시작 후에도 유지되는지 여부를 결정합니다.	일반적으로 False (임시)
메시지 지속성	basic_publish의 delivery_mode=2 (지속형) 또는 1 (임시)	메시지 페이로드가 디스크에 기록되는지 여부를 결정합니다.	일반적으로 1 (임시)

메시지 지속성 요구 사항

메시지 페이로드가 브로커 재시작 후에도 유지되려면 두 가지 조건이 충족되어야 합니다:

1. 메시지를 수신하는 큐는 지속형이어야 합니다.
2. 메시지 자체는 지속형으로 게시되어야 합니다.

지속형 메시지를 임시 큐로 보내면 메시지는 큐 자체가 삭제될 때까지만 유지됩니다(브로커 재시작 시 즉시 발생). 마찬가지로 임시 메시지를 수신하는 지속형 큐는 재시작 후에도 유지되지만 모든 메시지는 손실됩니다.

# 완전한 지속성 달성 (큐 유지 + 메시지 유지)
# 1. 큐는 지속형이어야 함
channel.queue_declare(queue='fully_persistent_queue', durable=True)

# 2. 메시지는 지속형이어야 함 (delivery_mode=2)
channel.basic_publish(
    exchange='',
    routing_key='fully_persistent_queue',
    body='Critical Data Payload',
    properties=pika.BasicProperties(delivery_mode=2) # 2는 지속형을 의미
)

결정 프레임워크: 올바른 유형 선택

지속형 큐와 임시 큐 중에서 선택하려면 성능 요구 사항 및 사용 가능한 리소스에 대한 데이터의 중요성을 평가해야 합니다.

결정 기준	지속형 큐 선택	임시 큐 선택
데이터 중요성	높음 (금융 데이터, 주문, 필수 작업).	낮음 (로그, 임시 상태, 실시간 업데이트).
브로커 다운타임	브로커 재시작/업그레이드 후에도 유지되어야 함.	큐 구조 및 메모리 내용 손실 허용 가능.
지속성 필요성	지속형 메시지와 함께 사용해야 함.	필요하지 않음; 메시지는 종종 임시적이거나 수명이 짧음.
성능 목표	신뢰성이 최대 속도보다 중요함.	최대 처리량과 가장 낮은 대기 시간이 필요함.
리소스 사용	더 높은 메모리 및 디스크 사용 (허용 가능한 오버헤드).	더 낮은 메모리 사용; 지속적인 디스크 활동 방지.

모범 사례 요약

1. 지속성 우선시: 신뢰성 필요성에 대해 의심이 든다면 기본적으로 지속형 큐와 지속형 메시지를 사용하세요. 성능이 병목 현상이 되면 나중에 항상 임시 큐를 최적화할 수 있습니다.
2. 혼합 사용: 동일한 시스템 내에서 핵심 처리 파이프라인에는 지속형 큐를 사용하고 보조, 모니터링 또는 알림 서비스에는 임시 큐를 사용하세요.
3. 손실 대비 설계: 임시 큐를 사용하는 경우 소비자 또는 업스트림 시스템에 손실된 데이터를 재처리하거나 재시작 후 누락된 메시지를 정상적으로 처리하는 메커니즘이 있는지 확인하세요.

핵심 요점

중요한 작업의 경우 지속형 큐를 선언하고 게시자 확인이 활성화된 지속형 메시지를 게시하세요. 임시 또는 일회성 흐름의 경우 애플리케이션이 큐를 다시 생성하고 손실된 메시지를 허용할 수 있는 경우에만 임시 패턴을 사용하세요.

주요 규칙은 간단합니다. 큐 지속성은 큐 정의를 보존하고 메시지 지속성은 메시지 페이로드를 보존합니다. 메시지가 브로커 재시작 후에도 유지되려면 둘 다 필요합니다.