효과적인 RabbitMQ 바인딩 전략을 통한 메시지 라우팅

바인딩은 RabbitMQ 라우팅이 실제로 작동하는 부분입니다. 프로듀서는 익스체인지에 게시하고, 컨슈머는 큐에서 읽으며, 바인딩은 어떤 큐가 어떤 메시지를 수신할지 결정합니다. 라우팅 설계가 깔끔하면 프로듀서는 얼마나 많은 컨슈머가 있는지 알 필요가 없으며, 컨슈머는 게시자 코드를 변경하지 않고 추가할 수 있습니다. 반면 지저분하면 메시지가 라우팅 불가능한 경로로 사라지고, 큐는 처리할 수 없는 작업을 수신하며, 모든 배포가 추측 게임으로 변합니다.

RabbitMQ 바인딩 전략에 대해 생각하는 가장 유용한 방법은 "어떤 익스체인지 유형이 가장 좋은가?"가 아닙니다. "메시지 전달에 대해 어떤 약속을 하고 있는가?"입니다. 청구 이벤트, 감사 로그, 캐시 무효화, 재시도 메시지는 모두 서로 다른 라우팅 요구 사항을 가집니다. 바인딩은 그 의도를 명확하게 해야 합니다.

이벤트의 형태부터 시작하세요

라우팅 키는 메시지의 안정적인 사실을 설명할 때 가장 잘 작동하며, 임시 구현 세부 사항은 피해야 합니다. orders.created와 같은 키는 애플리케이션의 여러 버전에서도 살아남을 가능성이 높습니다. worker-3.fast-path와 같은 키는 그렇지 않을 것입니다.

토픽 익스체인지의 경우, 작고 일관된 계층 구조를 사용하세요:

domain.entity.action
orders.invoice.created
orders.invoice.paid
orders.shipment.failed
users.account.disabled

컨슈머는 인보이스 이벤트를 위해 orders.invoice.*에 바인딩하거나, 모든 주문 도메인 이벤트를 위해 orders.#에 바인딩하거나, 운영 실패 처리를 위해 #.failed에 바인딩할 수 있습니다. 이는 동일한 익스체인지에 new_order, invoice.paid, shipping-error를 혼합하는 것보다 훨씬 이해하기 쉽습니다.

다이렉트 바인딩: 정확한 작업을 위한 정확한 이름

다이렉트 익스체인지는 게시자가 정확한 작업 클래스를 알고 있고, 각 큐가 하나 이상의 정확한 키를 원할 때 적합합니다.

rabbitmqadmin declare exchange name=orders.events type=direct durable=true
rabbitmqadmin declare queue name=billing.invoice-created durable=true
rabbitmqadmin declare queue name=audit.order-events durable=true

rabbitmqadmin declare binding source=orders.events destination=billing.invoice-created routing_key=invoice.created
rabbitmqadmin declare binding source=orders.events destination=audit.order-events routing_key=invoice.created
rabbitmqadmin declare binding source=orders.events destination=audit.order-events routing_key=invoice.paid

메시지가 invoice.created로 게시되면 두 큐 모두 복사본을 받습니다. shipment.created로 게시되면 다른 바인딩이 없는 한 어떤 큐도 수신하지 않습니다. 그 정확성이 핵심입니다.

명령형 작업 큐, 명확한 이벤트 이름, 작은 라우팅 키 집합에 다이렉트 바인딩을 사용하세요. 목록이 수십 개의 거의 중복된 키로 늘어날 때 토픽 라우팅의 대체재로 사용하지 마십시오. 그 시점에서는 수동으로 취약한 라우팅 테이블을 유지 관리하게 됩니다.

토픽 바인딩: 게시자 변경 없이 유연한 구독

토픽 익스체인지는 일반적으로 이벤트 기반 시스템에서 가장 실용적인 기본값입니다. 게시자는 하나의 라우팅 키를 보냅니다. 각 큐는 구독의 범위를 결정합니다.

rabbitmqadmin declare exchange name=platform.events type=topic durable=true
rabbitmqadmin declare queue name=fraud.orders durable=true
rabbitmqadmin declare queue name=ops.failures durable=true
rabbitmqadmin declare queue name=analytics.all-events durable=true

rabbitmqadmin declare binding source=platform.events destination=fraud.orders routing_key=orders.payment.*
rabbitmqadmin declare binding source=platform.events destination=ops.failures routing_key=#.failed
rabbitmqadmin declare binding source=platform.events destination=analytics.all-events routing_key=#

와일드카드 규칙은 정확합니다:

• *는 점 사이의 정확히 한 단어와 일치합니다.
• #는 0개 이상의 단어와 일치합니다.

따라서 orders.*.failed는 orders.payment.failed와 일치하지만 orders.eu.payment.failed와는 일치하지 않습니다. orders.#는 orders, orders.created, orders.eu.payment.failed와 일치합니다.

토픽 익스체인지의 주요 위험은 의도치 않은 과도한 구독입니다. #에 바인딩된 큐는 익스체인지에 게시된 모든 것을 수신합니다. 이는 분석 또는 아카이브 시스템에는 괜찮을 수 있지만, 하나의 메시지 스키마만 이해하는 서비스에는 좋지 않은 놀라움입니다. 광범위한 바인딩은 드물게 유지하고 해당 큐의 이름을 정직하게 지정하세요.

팬아웃 바인딩: 라우팅 키 논쟁 없는 브로드캐스트

팬아웃 익스체인지는 모든 메시지를 바인딩된 모든 큐에 보내고 라우팅 키를 무시합니다. 따라서 캐시 무효화, 로컬 개발 탭 큐, "모든 하위 시스템이 들어야 하는" 알림에 탁월합니다.

rabbitmqadmin declare exchange name=deploy.notifications type=fanout durable=true
rabbitmqadmin declare queue name=slack.deploys durable=true
rabbitmqadmin declare queue name=audit.deploys durable=true

rabbitmqadmin declare binding source=deploy.notifications destination=slack.deploys
rabbitmqadmin declare binding source=deploy.notifications destination=audit.deploys

라우팅 키가 불편하다는 이유로 팬아웃을 사용하지 마세요. 10개의 컨슈머 중 3개만 메시지가 필요하다면 다이렉트 또는 토픽 라우팅을 사용하세요. 팬아웃은 의도적으로 무딥니다: 바인딩된 모든 큐가 복사본을 받습니다.

헤더 바인딩: 유용하지만 지루하게 유지하세요

헤더 익스체인지는 라우팅 키 대신 메시지 헤더를 기준으로 라우팅합니다. x-match 바인딩 인수를 사용하여 모든 헤더 또는 모든 헤더와 일치할 수 있습니다.

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

channel.exchange_declare(exchange='documents', exchange_type='headers', durable=True)
channel.queue_declare(queue='pdf-invoices', durable=True)

channel.queue_bind(
    exchange='documents',
    queue='pdf-invoices',
    arguments={'x-match': 'all', 'format': 'pdf', 'type': 'invoice'}
)

channel.basic_publish(
    exchange='documents',
    routing_key='ignored',
    body=b'...',
    properties=pika.BasicProperties(headers={'format': 'pdf', 'type': 'invoice'})
)

connection.close()

헤더 라우팅은 이미 의미 있는 메타데이터를 전달하는 시스템에서 메시지가 올 때 유용합니다. 또한 불투명해지기 쉽습니다. 큐 바인딩에서 라우팅 규칙을 빠르게 이해할 수 없다면 토픽 키를 선호하세요.

실제 장애를 일으키는 바인딩 실수

가장 흔한 바인딩 실수는 vhost 불일치입니다. RabbitMQ 객체는 가상 호스트 내에 존재합니다. /의 orders.events라는 익스체인지는 prod의 orders.events와 동일한 객체가 아닙니다. CLI 도구를 사용할 때 항상 -V 또는 -p로 확인하세요.

rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments

다음 실수는 다이렉트 익스체인지가 토픽 익스체인지처럼 동작한다고 가정하는 것입니다. orders.*의 다이렉트 바인딩은 리터럴 키 orders.*와만 일치합니다. orders.created와는 일치하지 않습니다. 와일드카드가 필요하면 익스체인지 유형이 topic이어야 합니다.

또 다른 일반적인 실수는 큐를 재시도 익스체인지에 동일한 라우팅 키로 바인딩하여 즉시 자신에게 다시 보내는 것입니다. 이는 빠른 재시도 루프를 만들 수 있습니다. 재시도의 경우 경로를 명시적으로 만드세요: 활성 큐 -> 재시도 익스체인지 -> 지연 큐 -> 원래 익스체인지, 마지막 시도 후 파킹 큐를 사용하세요.

마지막으로, 자동화로 인한 중복 바인딩을 주의하세요. RabbitMQ는 동일한 속성을 가진 중복 바인딩을 멱등적으로 처리하지만, 거의 중복된 바인딩은 여전히 다릅니다. orders.created와 order.created는 누군가가 메시지의 절반이 잘못된 서비스로 가고 있음을 알아차리기 전까지 몇 달 동안 나란히 존재할 수 있습니다.

간단한 검토 체크리스트

라우팅 변경 사항을 배포하기 전에 다음 질문에 답하는 것이 좋습니다:

• 게시를 수신하는 익스체인지는 무엇인가요?
• 프로듀서가 보낼 정확한 라우팅 키 또는 헤더는 무엇인가요?
• 어떤 큐가 하나의 복사본을 수신해야 하나요?
• 어떤 큐가 수신해서는 안 되나요?
• 일치하는 바인딩이 없으면 어떻게 되나요?
• 라우팅 불가능한 메시지를 위한 대체 익스체인지 또는 게시자 반환 처리가 있나요?
• 재시도 및 데드 레터 바인딩이 단방향인가요, 아니면 루프가 발생할 수 있나요?

그런 다음 배포된 토폴로지를 확인하세요:

rabbitmqctl -p prod list_exchanges name type durable arguments
rabbitmqctl -p prod list_queues name durable arguments
rabbitmqctl -p prod list_bindings source_name source_kind destination_name destination_kind routing_key arguments

좋은 RabbitMQ 바인딩 전략은 일반적으로 지루합니다. 이름은 예측 가능하고, 와일드카드는 의도적이며, 실패 경로는 명확합니다. 프로듀서가 자정에 배포하고 큐 그래프가 회의 없이 스스로를 설명해야 할 때 정확히 필요한 것입니다.