RabbitMq 이해

RabbitMQ 기본 구조

Exchange (교환기)

---

메시지를 수신하고 특정 규칙에 따라 큐로 라우팅한다.

 

Queue

---

메시지를 저장하는 버퍼 공간, 메시지를 소비자가 가져갈 때까지 보관한다.

 

Binding

---

Exchange와 Queue를 연결하는 링크, 라우팅 규칙을 정의할 수 있다.

 

 

라우팅 규칙

• Direct
  • Routing key와 Binding key가 정확하게 일치해야 메시지가 큐로 전달된다.
  • 하나의 Queue는 여러 Binding key를 가질 수 있다.
  • 하나의 Binding key는 여러 Queue와 연결될 수 있다.
• Fanout
  • 조건 없이 모든 바인딩된 큐로 메시지를 브로드캐스트
• Topic
  • Binding key와 Routing key간의 패턴 매칭을 지원한다. 따라서 특정 이벤트를 더 세밀하게 라우팅이 가능하다.
  • 와일드 카드 지원
  • (한단어 매칭) : 특정 이벤트의 세부 카테고리 지정
    • ex) user.* → user.create, user.update와 매칭 가능
• • • #(0개 이상의 단어 매칭) : 더 넓은 범위의 이벤트를 포괄적으로 처리
      • order.# → order.created, order.updated.payment, order.deleted 등과 매칭
  • 새로운 이벤트 추가
    • 새로운 라우팅 키를 정의하면 기존 시스템에 영향을 주지 않고도 Queue 확장이 가능
  • Consumer 확장
    • 기존 Queue에 추가 바인딩을 정의하여 새로운 Consumer 연결이 가능
• Headers
  • 메시지에 첨부된 메타데이터로 key-value 쌍으로 구성
  • 바인딩 시 헤더 값의 조건을 정의하여 특정 조건과 일치하는 메시지를 라우팅
  • 라우팅 키가 필요 없으며, 메시지 헤더와 비인딩 조건을 비교하여 Queue로 전달
    • x-match : 조건 매칭 방식을 설정
    • all : 메시지 헤더가 바인딩된 모든 조건과 일치.(기본값)
    • any : 메시지 헤더가 하나 이상의 조건과 일치

Headers vs Topic 

공통점

• 이벤트 라우팅
  • 둘 다 메시지를 특정 조건에 따라 큐로 전달
  • 유연성: 다양한 방식으로 메시지를 분류하고 처리가능
  • 복잡한 이벤트 관리 : 다수의 이벤트 유형을 처리할 때 적합
• 차이점

특징	Headers Exchange	Topic Exchange
라우팅 기준	메시지 헤더의 키-값 쌍	라우팅 키 (패턴 기반)
조건 정의 방식	메시지 헤더 값 비교	라우팅 키 패턴 매칭
설정 복잡도	헤더 키-값을 정의해야 하므로 더 복잡	패턴 기반으로 상대적으로 단순
유연성	더 높은 유연성 (키-값 조건을 자유롭게 설정 가능)	유연하지만 라우팅 키 패턴에 의존
성능	헤더 비교로 인해 상대적으로 느릴 수 있음	라우팅 키 매칭은 더 빠름

 

어떤 상황에서 적합할까 ?

-Headers Exchange 사용이 적합한 경우

• 메타데이터 중심 라우팅 : 메시지 헤더에 복잡한 키-값 정보가 포함된 경우
• 동적 조건 라우팅 : 이벤트 조건이 자주 바뀌거나, 다양한 키-값 조건을 기반으로 라우팅 해야 하는 경우
• 다양한 조건 : 특정 이벤트에 대해 여러 조건이 동시에 적용되어야 하는 경우

-Topic Exchange 사용이 적합한 경우

• 정형화된 라우팅 키 : 라우팅 키가 미리 정해져 있고 패턴 매칭이 가능할 때
• 단순하고 효율적인 라우팅 : 조건이 라우팅 키 패턴으로 표현될 수 있는 경우
• 성능 중요 : 빠르고 간단한 조건 매칭이 요구될 때

예시

상황 : 쇼핑몰의 이벤트 처리 시스템

 

이벤트 종류

• order.created: 주문 생성 이벤트
• order.shipped: 주문 발송 이벤트
• user.signup: 사용자 가입 이벤트
• user.deleted: 사용자 삭제 이벤트

Topic Exchange로 처리

1. 설계:
   • 라우팅 키: order.*, user.*
   • Binding Key:
     • order.*: 주문 관련 이벤트 처리 큐
     • user.*: 사용자 관련 이벤트 처리 큐
2. 장점:
   • 라우팅 키 패턴만 정의하면 여러 이벤트를 효율적으로 처리.
   • 성능이 높고 간단한 구조.
3. 단점:
   • 라우팅 키에 포함되지 않은 조건(예: 우선순위, 지역 등)은 처리 불가.
   • 이벤트 이름이 라우팅 키 패턴과 일치해야만 매칭 가능.

Headers Exchange로 처리

1. 설계:
   • 메시지 헤더:
     • {"type": "order", "action": "created", "priority": "high"}
   • Binding 조건:
     • 큐 1: {"x-match": "all", "type": "order", "priority": "high"}
     • 큐 2: {"x-match": "any", "type": "user"}
2. 장점:
   • 복잡한 조건(우선순위, 타입 등)에 따라 라우팅 가능.
   • 라우팅 키와 관계없이 헤더를 활용해 유연한 처리 가능.
3. 단점:
   • 설정 복잡성 증가.
   • 헤더 비교로 인해 성능이 저하될 수 있음.

* 어떤 성능 저하?

상황 1.메시지가 10개의 헤더를 포함하고 있다. Queue가 100개가 있고, 각 Queue가 바인딩 조건을 가지고 있다.

→ 모든 헤더를 순차적으로 비교해야 한다.

상황 2.바인딩 조건에 "x-match": "all"이 설정된 경우

→ 각 Queue 마다 바인딩된 모든 조건을 하나씩 비교해야 하므로, 조건이 많을수록 비교 연산이 많아져 성능에 영향을 미친다.

 

무엇이 더 잘 어울릴까?

 

Topic Exchange가 더 적합한 경우

• 이벤트 이름이 규칙적으로 정해져 있고, 패턴 매칭으로 충분히 처리 가능할 때.
• 성능이 중요하거나 단순한 이벤트 라우팅이 필요할 때.

Headers Exchange가 더 적합한 경우

• 이벤트에 추가 메타데이터(예: 우선순위, 지역 등)를 포함하여 더 세밀한 조건 기반 라우팅이 필요할 때.
• 이벤트 이름만으로 라우팅 조건을 정의하기 어려울 때.