RabbitMQ란?
모든 클라우드 네이티브 앱에서 마이크로서비스는 사용자에게 응답하는 데 필요한 모든 정보를 얻기 위해 통신을 해야 합니다. 통합 간에 네트워크 문제나 장애가 발생하더라도 이 메시징이 견고하게 유지되도록 해야 합니다. RabbitMQ는 메시징의 안정성을 높이는 데 사용할 수 있는 도구 중 하나입니다.
아웃도어 장비 소매업체는 마이크로 서비스를 통해 빠르게 발전하고 있습니다. 그러나 애플리케이션 테스트에서 한 마이크로서비스에서 다른 마이크로서비스로의 일부 호출이 손실되는 경우가 있습니다. 회사의 평판이 걸려 있는 프로덕션 환경에서는 이러한 문제가 발생하지 않도록 하고 싶을 것입니다.
이 단원에서는 RabbitMQ가 어떻게 마이크로서비스를 위한 유연하고 탄력적인 커뮤니케이션 플랫폼을 만들 수 있는지 살펴봅니다.
클라우드 네이티브 앱에서 메시지 브로커를 사용하는 이유는 무엇인가요?
클라우드 네이티브 앱은 독립적인 마이크로 서비스로 구성되며, 종종 별도의 팀과 다양한 기술 및 언어를 사용하여 빌드됩니다. 각 팀마다 자체 개발 스프린트 및 업그레이드 일정이 있으며 수정 사항과 새로운 기능을 지속적으로 배포할 수 있습니다. 그러나 사용자로부터 요청이 도착하면 이를 수신하는 마이크로 서비스는 거의 항상 다른 마이크로 서비스 및 지원 서비스를 호출하고 전체 응답을 작성하기 위해 회신을 받아야 합니다.
물론 이러한 서비스 간 요청 및 응답의 형식과 스키마는 개발팀 간에 합의되어야 하며 거의 변경되지 않습니다. 일반적으로 REST API로 구현됩니다. 기존 메서드 및 매개 변수를 변경하지 않고 각 인터페이스의 새 기능을 우선적으로 구현해야 합니다. 그러나 마이크로 서비스가 직접 통신하도록 선택하는 경우 다음과 같은 몇 가지 문제가 발생할 수 있습니다.
- 대상 마이크로 서비스가 오프라인이거나 사용량이 많은 경우 전송되는 메시지는 어떻게 되나요? 메시지가 손실되면 어떻게되나요?
- 동일한 메시지를 둘 이상의 대상에 어떻게 보낼 수 있나요?
- 마이크로 서비스가 둘 이상의 컨테이너에서 실행되는 경우 어떤 컨테이너에 메시지를 보내야 하나요?
메시지 브로커는 이러한 문제를 해결하는 미들웨어입니다. 서비스는 대상에 직접 메시지를 보내는 대신 메시지 브로커에 메시지를 보냅니다. 브로커는 도착하는 순서대로 큐에 저장합니다. 대상 서비스는 이러한 큐를 구독하고 한 번에 하나씩 메시지를 선택하여 처리합니다.
대상 서비스를 사용할 수 없는 경우에도 보내는 마이크로서비스는 메시지를 큐에 넣을 수 있습니다. 대상이 다시 시작되면 동일한 지점에서 큐의 메시지를 계속 수신합니다. 보낸 사람이 더 오래 기다려야 하지만 메시지가 손실되지는 않습니다.
둘 이상의 대상에서 큐를 구독할 수 있으므로 하나의 메시지를 둘 이상의 마이크로서비스에서 수신할 수 있습니다. 또한 여러 컨테이너가 단일 마이크로서비스의 인스턴스를 호스팅하는 경우, 사용 가능한 첫 번째 인스턴스가 메시지를 수신합니다. 브로커는 메시지를 인스턴스에 자동으로 배포하여 부하를 분산합니다.
RabbitMQ란?
RabbitMQ는 가장 인기 있는 메시지 브로커 중 하나이며 클라우드 네이티브 앱에서 통신을 처리하기에 이상적인 많은 기능을 갖추고 있습니다. 다음을 포함합니다.
- 큐를 호스트하는 RabbitMQ 서버입니다. 서버는 고가용성을 위해 클러스터링 및 장애 조치(failover)를 지원하며 컨테이너에서 실행할 수 있습니다.
- AMQP(고급 메시지 큐 프로토콜), STOMP(단순 텍스트 지향 메시지 프로토콜) 및 MQTT(메시지 큐 원격 분석 전송)의 구현입니다.
- .NET, Java 및 Erlang에서 사용할 수 있는 AMQP 클라이언트 라이브러리입니다.
RabbitMQ 개념
RabbitMQ 용어로, 메시지를 주고받는 마이크로서비스는 클라이언트 입니다. 메시지를 보내는 클라이언트를 메시지 생산자라고 합니다. 메시지를 수신하는 클라이언트는 메시지 소비자 입니다. RabbitMQ 서비스는 메시지 브로커 입니다.
메시지를 보내는 방법
RabbitMQ는 다목적이며 다양한 큐 모델을 구현할 수 있습니다. 몇 가지 인기 있는 패턴을 살펴보겠습니다.
단일 생산자와 단일 소비자가 있는 경우 단일 큐를 사용하며 모든 메시지가 동일한 대상에 도달합니다. 이 간단한 구성에서도 중단을 원활하게 처리하는 강력한 메시징 시스템을 빌드합니다.
경쟁 소비자에게 메시지 보내기
경쟁 소비자 모델에서는 생산자가 단일 작업 큐에 메시지를 보냅니다. 둘 이상의 소비자가 큐에서 메시지를 검색합니다. 각 메시지는 단일 소비자만 검색할 수 있으므로 소비자는 메시지를 검색하기 위해 경쟁합니다.
이 패턴은 클라우드 네이티브 앱에서 용량을 늘리기 위해 여러 컨테이너에서 호스팅되는 소비성 마이크로서비스가 있는 경우에 유용합니다. 각 메시지는 소비자의 인스턴스 하나에만 도달하므로 한 번만 처리됩니다. 작업이 중복되지 않습니다.
게시 및 구독
생산자가 여러 소비자에게 단일 메시지를 보내려면 게시/구독 모델을 사용하세요. 프로듀서가 Exchange에 메시지를 보냅니다. 각 소비자는 해당 Exchange의 메시지를 구독합니다. 구독할 때 RabbitMQ는 해당 구독에 대한 새 작업 큐를 만듭니다. 각 메시지는 해당 Exchange의 모든 큐에 복사되며 구독한 모든 소비자가 수신합니다. 소비자는 각 메시지를 위해 경쟁하지 않습니다. 대신 모든 메시지의 복사본을 받습니다.
게시/구독 모델은 모든 메시지를 모든 작업 큐에 복사하는 팬아웃 Exchange를 사용합니다.
이 패턴은 각 메시지를 여러 마이크로 서비스에서 처리하려는 경우에 유용합니다. 예를 들어 고객이 장바구니를 체크 아웃할 때 고객이 구매한 각 제품의 개수에 대한 메시지를 보낼 수 있습니다. 이 메시지는 배송 마이크로서비스에 전달되어 창고에 소포를 포장하도록 지시하고 재고 마이크로서비스에 전달되어 재고 수를 줄이고 공급 업체에 주문을 트리거할 수 있습니다.
메시지 및 토픽 라우팅
단일 메시지를 여러 소비자에게 배포하고 싶지만 각 소비자마다 필터를 적용해야 하는 경우가 있습니다. 이 패턴을 메시지 라우터라고 합니다. 게시/구독 모델에서와 마찬가지로, 소비자는 Exchange를 구독하여 여러 개의 작업 큐를 생성합니다. 그러나 이 모델은 팬아웃 Exchange 대신 직접 Exchange를 사용합니다. 이 Exchange를 사용하면 각 구독에 바인딩 키가 있습니다. 라우팅 키가 바인딩 키와 일치하는 메시지만 이 구독으로 전송됩니다. 다른 항목은 필터링됩니다.
이 패턴은 일부 소비자가 메시지 스트림의 하위 집합만 처리해야 하는 경우에 유용합니다. 예를 들어 오류가 발생하면 메시지를 보내는 마이크로서비스가 있다고 가정해 보겠습니다. 모든 오류는 로깅 마이크로 서비스로 전송되어야 합니다. 위험한 오류는 엔지니어에게 문제를 해결하도록 경고하는 관리 마이크로 서비스로 전송되어야 합니다.
직접 Exchange는 단일 조건에 따라 메시지를 라우팅합니다. 더욱 유연하게 만들기 위해 토픽 Exchange를 사용할 수 있습니다. 각 메시지에 대해 점으로 구분된 여러 개의 용어가 포함된 라우팅 키를 사용할 수 있습니다. 바인딩 키에서 와일드카드 *을(를) 사용하여 정확히 한 단어로 대체하거나 #을(를) 사용하여 0개 이상의 단어로 대체할 수 있습니다.
참고 항목
RabbitMQ의 대안으로는 Apache Kafka 및 Azure Service Bus가 있습니다. 이 두 메시지 브로커는 모두 .NET Aspire의 전용 통합에서 지원됩니다. 이 학습 경로의 이후 모듈에서 Azure Service Bus에 대해 배우게 됩니다.