sklass의 s-class 프로그래밍 blog

마이크로서비스에서 RabbitMQ를 쓰는 이유 본문

MSA

마이크로서비스에서 RabbitMQ를 쓰는 이유

sklass 2021. 12. 17. 13:14

마이크로서비스는 어떻게 연결될까?

마이크로서비스라 함은, 둘 이상의 소규모 서비스(Microservices)로 구성된 단일 애플리케이션이라고 할 수 있습니다. 이런 구조에서 여러개의 소규모 서비스들은 서로 분리되어 있지만 여전히 통신할 수 있어야 합니다.

 

마이크로서비스에서 교차 종속성, 즉 다른 서비스의 도움 없이는 단일 서비스를 수행할 수 없는 것은 일반적입니다.

 

그래서 마이크로서비스간 연결을 도와줄 서비스들과 방법들이 고안되었고, 아래에 서비스들이 현재 대표적으로 쓰입니다.

  • Brokers, Message Queuing (비동기적 연결, RabbitMQ나 Kafka)
  • Remote Procedure Calls (RPC)
  • REST APIs (동기적 연결)

Message Queuing 이란?

Message Queues를 사용하면 응용 프로그램의 일부가 메시지를 대기열에 비동기식으로 푸시하고 올바른 대상으로 전달되는지 확인할 수 있습니다.

 

Message queuing을 구현하려면 RabbitMQ와 같은 메시지 브로커가 좋은 옵션입니다.

 

메시지 브로커는 수신 서비스가 사용 중이거나 연결이 끊어졌을 때 임시 메시지 저장소를 제공합니다

브로커와의 통신 처리

메시지 브로커는 마이크로서비스의 중개자 역할을 하며, 한 애플리케이션(producers)에서 메시지를 수신하여 다른 애플리케이션(consumers)에게 메시지를 전달하여 작업을 수행합니다.

 

예를 들어, RabbitMQ 메시지 브로커를 사용하면 메시지가 큐에 직접 게시되지 않지만 producers가 exchange으로 메시지를 보냅니다.

exchange의 작업은 consumers가 응용 프로그램의 메시지를 수락하고 올바른 메시지 큐로 전달하는 것입니다.

 

메시지는 consumers가 처리하여 제거할 때까지 대기열에 남아 있습니다.

 

선택할 수 있는 메시지 브로커로는 RabbitMQ와 Apache Kafka 이렇게 두 가지가 있고, 브로커 중 하나를 선택할 때는 요구 사항을 정확히 파악해야 합니다.

 

Microservices 아키텍처에서 브로커 역할을하는 RabbitMQ

RabbitMQ는 비동기 처리를 가능하게합니다. 즉, 메시지를 즉시 처리하지 않고 큐에 넣을 수 있습니다.

 

따라서 RabbitMQ는 장기 실행 작업(long-running tasks) 또는 차단 작업(blocking tasks)에 이상적이며, 웹 서버가 현장에서 계산 집약적인 작업(computationally intensive tasks)을 수행하지 않고 요청에 신속하게 응답 할 수 있습니다.

 

RabbitMQ는 단순히 메시지를 저장하고 준비가되면 consumers에게 전달합니다.

 

RabbitMQ로 확장

메시지가 consumer가 처리 할 수있는 속도보다 더 빠른 속도로 큐에 전달되는 경우 큐는 계속 증가합니다.

 

다행히도 확장은 아래의 두 가지 방법으로 수행 할 수 있습니다.

  • consumer를 쉽게 추가하거나 제거
  • 브로커가 확장 (CPU / 디스크 / 메모리를 통해 더 많은 리소스 추가)하도록 허용하여 큐에서 더 많은 메시지를 처리

그러나 RabbitMQ는 짧은 대기열에서 가장 빠르게 작동합니다.

 

RabbitMQ 사용사례

예를 들어, 직방과 같은 기업에서 부동산 중개업자가 여러개의 방 사진을 올렸다고 생각해봅시다. 중개업자가 올린 사진들의 규격은 제각각일 것이므로, 서버에서 데이터베이스에 저장하기 전 사진들의 규격을 알맞게 수정해야합니다. 하지만 API서버에서 이 일을 처리하기에는 중개업자가 사진을 올리고 일이 완료되었다는 메시지를 받기까지 너무 오래걸려서 중개업자가 더 이상 직방을 쓰기 싫을 수도 있습니다. 

 

해결책으로 RabbitMQ가 사용되는데, 과정은 아래와 같습니다.

  1. 중개업자가 올린 여러개의 사진들을 API 서버가 받음
  2. API 서버는 RabbitMQ를 통해서 사진들을 사진 규격을 처리하는 서비스로 보냄. (Publish)
  3. 사진 규격을 처리하는 서비스는 API서버와 다른 서버로, API 서버는 사진 규격 처리가 완료된것과 무관하게 중개업작에게 완료 메시지를 보냄
  4. 사진 규격을 처리하는 서비스에서 APIT서버로 부터 받은 사진들의 규격을 처리 비동기적으로 처리(Consume)
  5. 사진 규격처리가 완료되면 해당 서비스의 데이터베이스에 저장하고, 만약 API서버가 독립적인 데이터베이스를 사용한다면 RabbitMQ를 사용하여 API서버의 데이터베이스와 해당 서비스의 데이터베이스를 동기화 시켜줌.

더 많은 사례는 아래의 동영상으로 확인 가능합니다.

https://www.youtube.com/watch?v=oq1fOr6Ryws 

References

https://velog.io/@cckn/%EB%B2%88%EC%97%AD%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-RabbitMQ%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0

 

(번역)마이크로서비스 - RabbitMQ를 사용하는 이유

이 글은 Microservices - why use RabbitMQ?를 번역한 글입니다.다소 오역이 있을 수 있습니다.RabbitMQ as a Service를 제공하는 CloudAMQP의 글이기 때문에 RabbitMQ를 사용하는 경우의 장점이 다소 부각되어 있을

velog.io

 

'MSA' 카테고리의 다른 글

MicroService Architecture VS Monolithic Architecture  (0) 2021.12.17