메시지 브로커는 두 개의 기본 메시지 배포 패턴 또는 메시징 스타일을 제공합니다.

포인트-투-포인트 메시징: 메시지의 송신자와 수신자가 일대일 관계인 메시지 큐에서 사용되는 배포 패턴입니다. 큐의 각 메시지는 하나의 수신자에게만 전송되며, 오직 한 번만 이용됩니다. 포인트-투-포인트 메시징은 메시지가 한 번만 실행되어야 하는 경우에 호출됩니다. 이 메시징 스타일의 적합한 사용사례로는 급여 및 재무 트랜잭션 처리를 들 수 있습니다. 이러한 시스템에서는 송신자와 수신자 모두 각 지불이 오직 한 번만 전송될 것이라는 보장이 필요합니다.

발행/구독 메시징: 이 메시지 배포 패턴(대개 "pub/sub"라고 함)에서 각 메시지의 생성자는 이를 토픽에 발행하고, 다수의 메시지 이용자는 메시지를 수신하고 싶은 토픽을 구독합니다. 어떤 토픽에 대해 발행된 모든 메시지는 이를 구독한 모든 애플리케이션에 배포됩니다. 즉, 메시지의 발행자와 이용자 사이에 일대다 관계가 형성되는 브로드캐스트 스타일의 배포 방법입니다. 만약 항공사에서 항공편의 착륙 시간 또는 지연 상태에 관한 업데이트를 배포할 경우, 여러 관계자가 이 정보를 활용할 수 있습니다. 지상 팀은 항공기 정비 및 급유를 진행하고 수화물 팀, 승무원, 조종사는 비행기의 다음 일정을 준비하며 비주얼 디스플레이 운영 팀은 공항 이용객에게 이 정보를 공지합니다. 발행/구독 메시징 스타일은 이러한 시나리오에 적절합니다.

클라우드 네이티브 애플리케이션은 유연성, 확장성 및 신속한 배치 등 클라우드 컴퓨팅의 고유한 장점을 활용하도록 설계됩니다. 이러한 애플리케이션은 마이크로서비스라고 하는 작고 개별적이고 재사용 가능한 구성요소로 구성됩니다. 각 마이크로서비스는 배치되어 다른 서비스와 독립적으로 실행될 수 있습니다. 그러면 시스템의 다른 서비스에 영향을 주지 않으면서 업데이트, 확장, 재시작하는 것이 가능해집니다. 대개 컨테이너의 형태로 패키지화되는 마이크로서비스는 서로 연동하면서 하나의 애플리케이션을 구성할 수 있습니다. 단, 각자 저마다의 스택이 있습니다. 이를테면 각자 사용하는 데이터베이스와 데이터 모델이 서로 다를 수 있습니다.

마이크로서비스끼리 원활한 연동을 위해 상호 통신하는 수단이 필요합니다. 메시지 브로커는 이러한 공유 통신 백본을 구현하는 데 쓰이는 메커니즘 중 하나입니다.

메시지 브로커는 종종 하이브리드 클라우드 환경에서 온프레미스 시스템과 클라우드 구성요소 간의 통신을 관리하는 데 사용됩니다. 메시지 브로커를 사용하면 서비스 간 통신을 더 효과적으로 제어할 수 있습니다. 즉, 데이터가 애플리케이션의 구성요소 간에 안전하고 안정적이며 효율적으로 전송되도록 보장합니다. 메시지 브로커는 멀티클라우드 환경의 통합에서도 이러한 역할을 수행할 수 있습니다. 상이한 플랫폼에 상주하는 워크로드와 런타임 간의 통신이 가능하게 합니다. 이는 또한 개별 클라우드 호스팅 서비스가 사전 요청 기반의 온디맨드 방식으로 실행되는 서버리스 컴퓨팅에서 사용하기에도 매우 적합합니다.

REST API가 마이크로서비스 간의 통신에 흔히 사용됩니다. REST(Representational State Transfer)라는 용어는 웹 서비스를 빌드할 때 개발자가 따를 수 있는 일련의 원칙과 제한조건들을 정의합니다. 이를 준수하는 모든 서비스는 동일한 공유의 상태 없는 운영자 및 요청 세트를 통해 통신할 수 있습니다. API(Application Programming Interface)는 REST 규칙을 준수하는 경우 서비스가 서로 간에 대화할 수 있도록 허용하는 기본 코드를 의미합니다.

REST API는 HTTP(Hypertext Transfer Protocol)를 사용하여 통신합니다. HTTP가 공용 인터넷의 표준 전송 프로토콜이므로 REST API는 널리 알려져 있고, 자주 사용되며, 광범위한 상호운용이 가능합니다. 그러나 HTTP는 요청/응답 프로토콜이므로, 이는 동기식 요청/응답을 호출하는 상황에서 최적으로 사용됩니다. 이는 REST API를 통해 요청을 작성하는 서비스가 즉각적인 응답을 기대하도록 설계되어야 함을 의미합니다. 응답을 수신하는 클라이언트가 작동 중지된 경우, 전송 서비스는 응답을 기다리는 동안 차단됩니다. 장애 조치와 오류 처리 로직은 두 서비스 모두에 빌드되어야 합니다.

메시지 브로커는 송신 서비스가 수신 서비스의 응답을 기다릴 필요 없는, 서비스 간의 비동기 통신을 가능하게 합니다. 이렇게 하면 이를 채택한 시스템에서 결함 허용과 복원력이 개선됩니다. 또한 발행/구독 메시징 패턴이 변화하는 수의 서비스를 즉시 지원할 수 있으므로, 메시지 브로커를 사용하면 시스템을 보다 손쉽게 확장할 수 있습니다. 메시지 브로커 역시 이용자의 상태를 추적합니다.

메시지 브로커가 메시지 큐와 발행/구독을 포함하여 둘 이상의 메시징 패턴을 지원할 수 있는 한편, 이벤트 스트리밍 플랫폼은 pub/sub 스타일의 배포 패턴만 제공합니다. 대량의 메시지와 함께 사용하도록 설계된 이벤트 스트리밍 플랫폼은 즉시 확장이 가능합니다. 이는 레코드 스트림을 토픽이라고 하는 카테고리로 정렬하고, 사전 설정된 기간 동안 이를 저장할 수 있습니다. 그러나 메시지 브로커와는 달리, 이벤트 스트리밍 플랫폼은 메시지 딜리버리를 보장하거나 메시지를 수신한 이용자를 추적할 수 없습니다.

이벤트 스트리밍 플랫폼은 메시지 브로커보다 많은 확장성을 제공하지만, 제한적인 메시지 라우팅 및 큐잉 기능은 물론 결함 허용(예: 메시지 재전송)을 보장하는 기능은 더 적습니다.

이벤트 기반 아키텍처에 관해 자세히 알아보세요.

 ESB(Enterprise Service Bus)는 엔터프라이즈에서 구현된 서비스 지향 아키텍처(SOA)에서 종종 활용되는 아키텍처 패턴입니다. ESB에서, 중앙 집중화된 소프트웨어 플랫폼은 통신 프로토콜과 데이터 포맷을 아키텍처의 모든 서비스와 애플리케이션이 공유할 수 있는 "공통 언어"와 결합합니다. 예를 들어, 이는 하나의 프로토콜(예: XML)에서 수신하는 요청을 다른 프로토콜(예: JSON)로 변환할 수 있습니다. ESB는 자동화된 프로세스를 사용하여 메시지 페이로드를 변환합니다. 중앙 집중화된 소프트웨어 플랫폼은 또한 연결성, 라우팅 및 요청 처리 등의 기타 오케스트레이션 로직도 처리합니다.

그러나 ESB 인프라는 복잡하고, 통합이 까다로우며, 유지보수에 비용이 많이 들 수 있습니다. 이는 프로덕션 환경에서 문제가 발생했을 때 문제점 해결이 어렵고, 확장이 용이하지 않으며, 업데이트에 시간이 많이 소요됩니다.

메시지 브로커는 보다 간편하고 보다 저렴한 비용으로 유사한 기능(서비스 간 통신을 위한 메커니즘)을 제공하면서도 "가벼운" ESB 대안입니다. ESB의 인기가 가라앉은 상황에서 더욱 널리 보급된 마이크로서비스 아키텍처에 사용하기에 매우 적합합니다.

메시지 브로커를 구현하면 다양한 기업 컴퓨팅 환경 내에서 그리고 여러 업종에서 각종 비즈니스 요구사항을 해결할 수 있습니다. 이는 신뢰할 수 있는 애플리케이션간 통신과 보증된 메시지 전달이 요구되는 모든 시점과 모든 위치에서 유용합니다.

메시지 브로커는 종종 다음과 같은 방식으로 사용됩니다.

• 금융 거래 및 지불 처리: 단 한 번만 지불이 이루어지게 하는 것이 중요합니다. 메시지 브로커를 사용하여 이러한 트랜잭션 데이터를 처리하면 지불 정보가 유실되거나 실수로 복제되지 않는다는 보장이 제공됩니다. 또한 수신 증명이 제공되며, 중간 네트워크가 작동 중지된 경우에도 시스템이 안정적으로 통신할 수 있도록 허용됩니다.
  
  
• 전자상거래 주문 처리 및 이행: 온라인으로 비즈니스를 수행하는 경우, 브랜드 평판은 웹 사이트와 전자상거래 플랫폼의 신뢰성에 달려 있습니다. 결함 내구성을 향상시키고 메시지가 단 한 번만 사용되도록 보장하는 메시지 브로커의 기능은 온라인 주문을 처리할 때 이를 자연스럽게 선택하도록 만듭니다.
  
  
• 매우 민감한 데이터를 저장하고 전송할 때의 보호: 엄격한 규제를 받는 업종이거나 해당 기업이 심각한 보안 위험에 직면한 경우에는 엔드-투-엔드 암호화 기능을 갖춘 메시징 솔루션을 선택하십시오.