RabbitMQ 시작하기

 

추석을 맞아 인프런의 향로님께서 추석 완강 챌린지를 열어주셨습니다.

ㄹㅇㅋㅋ

 

그래서 이참에 관심있었던 강의 하나를 완주해보기로 했습니다.

 

바로 메시지큐 라이브러리인 RabbitMQ입니다.

 

사실 예전에 AI 기반 일기 서비스인 '토닥' 에서 실시간 알림을 개발할 때 레빗엠큐 도입을 좀 고민했었는데요, 결국엔 안했습니다.

 

이유는

1. 레디스 Pub/Sub으로 어느정도 알림 기능 구현이 커버 될 것 같았고

2. 괜히 도입했다가는 견고하게 구현하지 못하고 오버엔지니어링이 될 것

같았기 때문입니다.

 

어쨌든 이번에 산 강의는 코드빌런 님의

RabbitMQ를 이용한 비동기 아키텍처 한방에 해결하기

입니다.

개요

RabbitMQ는 메시지 전송 브로커 오픈소스로 시스템간에 비동기 메시징으로 서비스간 통신을 안정적으로 그리고 효율적으로 처리할 수 있게 해줍니다.

 

이벤트 기반 아키텍쳐, 로그 및 모니터링, 채팅 및 알람 그리고 최근에는 MSA 환경에서 가장 일반적으로 쓰이는 기술이라 합니다.

 

설치 방법에는 brew나 직접 설치 등 여러가지가 있는데요, 저는 도커로 설치해서 사용했습니다.

docker run -d --name rabbitmq \
-p 5672:5672 -p 15672:15672 \
rabbitmq:4.0-management

 

이러면 http://localhost:15672 로 접근해서 초기 계정인 guest/guest로 로그인할 수 있습니다.

로그인 후에는 admin 권한을 갖는 다른 계정을 추가해주고 초기 계정인 guest를 삭제해주시면 됩니다.

메시지 큐를 사용하는 이유

이유 중 하나는 바로 성능 때문입니다. 비동기 처리를 큐를 통해 분리함으로써 병목을 제거하기 위함이죠.

 

그리고 데이터를 메모리 대신에 디스크에 저장하기 때문에 데이터 유실을 방지할 수 있습니다. 메시지가 제대로 처리 되지 않아도 나중에 다시 처리할 수 있으며, 메시지 영구 저장, 메시지 확인 등을 통해 메시지의 신뢰성을 보장할 수 있습니다.

 

그리고 여러 노드에 걸쳐 쉽게 확장이 가능하기 때문에 높은 가용성을 제공해줄 수 있습니다.

 

기본적으로 AMQP(Advanced Message Queuing Protocol)을 사용하고, 여러 프로토콜, 그리고 여러 언어를 지원한다고 합니다.

AMQP

AMQP는 일반적인 메시지 큐의 표준 프로토콜을 의미합니다.

 

간단히 말하자면 위와 같이 메시지를 생성하는 Producer와 이를 특정 규칙에 따라 큐에 분배해주는 Exchange 그리고 Exchange에 바인딩된 Queue들이 존재하고 이를 Consumer가 소비하여 클라이언트로 데이터를 전달해주는 구조입니다.

Routing Model Components

AMQP의 라우팅 모델은 Exchange, Queue, Binding 이 세 컴포넌트들을 중심으로 구성됩니다.

 

1. Producer

• 메시지를 생성하고 RabbitMQ에 전송하는 애플리케이션. 즉 특정 Exchange에 메시지 전송

2. Exchange

• Publisher로 부터 받은 메시지를 적절한 큐 혹은 다른 Exchange로 분배하는 라우터 역할
• Exchange 유형 :
  • Direct : 특정 라우팅 키와 정확히 일치하는 큐에 메시지 전송
  • Fanout : 모든 큐에 메시지 브로드 캐스트
  • Topic : 라우팅 키 패턴을 기반으로 메시지 전송
  • Headers : 메시지 헤더 속성에 따라 메시지 라우팅

3. Queue

• 메모리나 디스크에 메시지를 저장하고 이를 Consumer에게 전달
• 비동기적으로 동작하며, 여러 Consumer가 동시에 메시지 소비 가능
• 하나의 메시지가 여러 소비자에게 중복으로 전달될 수는 없음
• 동일한 메시지를 수신하려면 Fanout Exchange 방식 + 여러 개의 큐로 동작해야 함

4. Binding

• Exchange와 Queue와의 관계를 정의한 일종의 라우팅 테이블. 이때 Routing Key에 의해 매칭 여부를 파악한다.

5. Routing Key

• Routing Key는 Publisher(Producer)로 부터 발행된 메시지 헤더에 포함됨.

6. Consumer

• 큐에서 메시지를 가져와 처리하는 어플리케이션
• 여러 소비자가 있으면 RabbitMQ에서 메시지를 로드 밸런싱 할 수 있음
• 메시지를 받아와서 처리하면 그에 대한 확인으로 ACK(acknowledgement) 전송
• ACK을 못받으면 메시지 브로커가 메시지를 재전송하거나 다른 Consumer에게 전송

7. Prefetch Count

• Consumer가 한번에 받을 수 있는 최대 메시지 수
• 한 번에 많은 양의 메시지를 처리하지 않도록 하여 성능 최적화 가능

8. Virtual Host

• RabbitMQ 내에 메시지 큐, Exchange, 사용자 권한 등을 구분하는 논리적인 구획
• 하나의 RabbitMQ 서버 내에 여러 가상 호스트를 배치하여 서로 다른 애플리케이션의 메시지 격리 가능

9. Dead Letter Queue

• 메시지가 처리 되지 못하거나 유효 기간이 지난 경우에 이동되는 별도의 큐

Exchange 종류

1. Direct Exchange

• 메시지가 정확히 Routing Key와 매칭되는 큐에만 전달되는 방식
• 주문 상태 처리, 결제 처리, 사용자 알림 시스템 등에 활용 가능

2. Topic Exchange

• 패턴 기반으로 Routing Key를 처리하여 메시지를 여러 큐에 유연하게 전달하는 방식
• * : 하나의 단어를 대체. ex) log.info, log.warn, log.error -> log.*
• # : 0개 이상의 단어를 대체. ex) app.order.success, app.payment.success -> #.success

3. Fanout Exchange

• 브로드 캐스트 방식으로 메시지를 모든 바인딩된 큐에 전달

4. Headers Exchange

• 메시지의 헤더에 기반한 복잡한 라우팅이 필요할 때
• ex) 다국어 서비스에서 language가 "ko", "en"에 따라 라우팅 가능