RabbitMQ 공식문서 번역
모니터링
- Grafana 대시보드는 여기 (opens in a new tab) 모여있음
- RabbitMQ는 기본적으로 15692 포트로 Prometheus 지표를 제공함
AMQP
RabbitMQ에서 사용하는 프로토콜.
네트워크는 신뢰할 수 없으며 애플리케이션이 메시지를 처리하지 못할 수 있기 때문에 AMQP 0-9-1 모델에는 메시지 확인이라는 개념이 있습니다. 메시지가 소비자에게 전달되면 소비자는 브로커에게 자동으로 또는 애플리케이션 개발자가 선택한 시점에 알립니다.
AMQP 0-9-1은 프로그래밍 가능한 프로토콜로, AMQP 0-9-1 엔티티와 라우팅 스킴은 주로 애플리케이션 자체에서 정의하며, 브로커 관리자에 의해 정의되지 않습니다. 따라서 큐와 교환기를 선언하고, 그 사이의 바인딩을 정의하고, 큐에 구독하는 등의 프로토콜 작업이 가능합니다.
특정 상황에서는, 예를 들어 메시지를 라우팅할 수 없는 경우, **메시지가 게시자에게 반환(nack)**되거나 제거되거나, 브로커가 확장을 구현한 경우, **"죽은 편지 큐(LXD)"**에 넣어질 수 있습니다. 게시자는 특정 매개변수를 사용하여 이러한 상황을 처리하는 방법을 선택합니다.
Exchange
- 교환기, 어떤 큐에 넣을지 라우팅 해주는 역할을 함
Direct exchange (Default Exchange)
기본 교환기는 이름이 없는 (빈 문자열) Direct exchange로, 브로커에 의해 사전에 선언됩니다. 이 교환기는 간단한 애플리케이션에 매우 유용한 한 가지 특별한 속성을 가지고 있습니다: 생성된 모든 큐는 기본 교환기에 큐 이름과 동일한 라우팅 키로 자동으로 바인딩됩니다.
예를 들어, "search-indexing-online"이라는 이름의 큐를 선언하면, AMQP 0-9-1 브로커는 "search-indexing-online"이라는 라우팅 키를 사용하여 기본 교환기에 바인딩합니다 (이 문맥에서는 바인딩 키라고도 합니다). 따라서 "search-indexing-online" 라우팅 키로 기본 교환기에 게시된 메시지는 "search-indexing-online" 큐로 라우팅됩니다. 즉, 기본 교환기를 사용하면 메시지를 큐에 직접 전달할 수 있는 것처럼 보이지만, 실제로는 그렇지 않습니다.
RabbitMQ에서 기본 교환기는 바인딩/바인딩 해제 작업을 허용하지 않습니다. 기본 교환기에 대한 바인딩 작업은 오류를 발생시킵니다.
Fanout exchange
팬아웃 교환기는 바인딩된 모든 큐에 메시지를 라우팅하며, 라우팅 키는 무시됩니다. 팬아웃 교환기에 N개의 큐가 바인딩된 경우, 새 메시지가 교환기에 게시되면 메시지의 복사본이 모든 N개의 큐에 전달됩니다. 팬아웃 교환기는 메시지의 브로드캐스트 라우팅에 이상적입니다.
팬아웃 교환기는 메시지를 바인딩된 모든 큐에 복사하여 전달하기 때문에, 사용 사례가 다음과 비슷합니다:
대규모 다중 사용자 온라인 게임(MMO)에서 리더보드 업데이트나 기타 글로벌 이벤트에 사용 스포츠 뉴스 사이트에서 모바일 클라이언트에게 점수 업데이트를 실시간으로 배포 분산 시스템에서 다양한 상태 및 구성 업데이트를 브로드캐스트 그룹 채팅에서 참가자 간에 메시지를 배포 (AMQP에는 존재 개념이 내장되어 있지 않으므로 XMPP가 더 나은 선택일 수 있음) 팬아웃 교환기는 다음과 같이 그래픽적으로 표현할 수 있습니다:
Topic exchange
토픽 교환기는 메시지 라우팅 키와 큐가 교환기에 바인딩될 때 사용된 패턴 간의 일치 여부를 기반으로 메시지를 하나 이상의 큐로 라우팅합니다. 토픽 교환기 유형은 다양한 게시/구독 패턴 변형을 구현하는 데 자주 사용됩니다. 토픽 교환기는 메시지의 멀티캐스트 라우팅에 일반적으로 사용됩니다.
토픽 교환기는 매우 광범위한 사용 사례를 가지고 있습니다. 여러 소비자/애플리케이션이 선택적으로 수신할 메시지 유형을 선택하는 문제가 있는 경우, 토픽 교환기의 사용을 고려해야 합니다.
예시
- * 는 정확히 한 단어를 대체.
- # 는 0개 이상의 단어를 대체.
예시 사용 사례
- 로그 시스템(Log Aggregation System)
- 바인딩 패턴 예시 : log.backend.* → 백엔드 로그만 수신
Headers exchange
헤더 교환기는 라우팅 키보다 메시지 헤더로 쉽게 표현할 수 있는 여러 속성을 기반으로 라우팅하도록 설계되었습니다. 헤더 교환기는 라우팅 키 속성을 무시합니다.
큐를 헤더 교환기에 바인딩할 때 일치 여부를 평가하기 위해 한 개 이상의 헤더를 사용할 수 있습니다. 이 경우, 애플리케이션 개발자는 "x-match" 바인딩 인수를 설정하여 메시지가 일치하는 방법을 지정해야 합니다. "x-match" 인수를 "any"로 설정하면, 하나의 일치하는 헤더 값만으로도 충분합니다. 반면에 "x-match"를 "all"로 설정하면 모든 값이 일치해야 합니다.
"x-match"가 "any" 및 "all"로 설정된 경우, "x-"로 시작하는 헤더는 일치 여부를 평가하는 데 사용되지 않습니다. "x-match"를 "any-with-x" 또는 "all-with-x"로 설정하면 "x-"로 시작하는 헤더도 일치 여부를 평가하는 데 사용됩니다.
헤더 교환기는 "강화된 다이렉트 교환기"로 생각할 수 있습니다. 헤더 값을 기반으로 라우팅하기 때문에 라우팅 키가 문자열일 필요가 없는 다이렉트 교환기로 사용할 수 있습니다. 예를 들어, 정수 또는 해시(딕셔너리)일 수 있습니다.
예시 사용 사례
- API 요청 라우팅 (API Gateway)
{
"service": "user",
"region": "korea"
}- x-match: all
- service=user
- region=korea
→ 한국 사용자 관련 요청을 User Service로 전달
- x-match: any
- service=order
- region=usa
→ 주문 서비스 요청이거나 미국 지역 요청이면 Order Service로 전달
- 사용자 권한 기반 메시지 필터링 (Role-Based Access Control, RBAC)
{
"role": "admin",
"permission": "write"
}- x-match: all
- role=admin
- permission=write
→ 관리자만 메시지 수신 가능
- x-match: any
- role=editor
- permission=read
→ 에디터 또는 읽기 권한이 있는 사용자 메시지 수신 가능