메시지 브로커가 제공하는 두 가지 기본 메시지 배포 패턴 또는 메시징 스타일:

점대점 메시징: 메시지 발신자와 수신자 간의 일대일 관계가 있는 메시지 대기열에서 사용하는 배포 패턴입니다. 대기열에 있는 각 메시지는 한 명의 수신자에게만 전송되며 한 번만 사용됩니다. 점대점 메시징은 메시지가 한 번만 작동해야 하는 경우에 호출됩니다. 점대점 방식이 적합한 예로는 급여 및 금융 거래 처리가 있습니다. 이 경우 발신인과 수신인 모두, 각 지불이 단 한 번만 이루어져야 한다는 보장을 필요로 하기 때문입니다.

게시/구독 메시징: 종종 "pub/sub"라고 하는 이 메시지 배포 패턴에서 각 메시지의 생성자는 주제에 메시지를 게시하고, 여러 메시지 소비자는 메시지를 수신하려는 주제를 구독합니다. 주제에 게시된 모든 메시지는 해당 주제를 구독하는 모든 애플리케이션에 배포됩니다. 이는 메시지 게시자와 소비자 간에 일대다 관계가 있는 브로드캐스트 스타일의 배포 방법입니다. 예를 들어, 항공사에서 항공편의 착륙 시간이나 지연 상태에 대한 업데이트를 전파하는 경우, 항공기 정비 및 급유를 수행하는 지상 승무원, 수하물 담당자, 다음 여행을 준비하는 승무원과 조종사, 대중에게 알리는 시각적 디스플레이 운영자 등 여러 당사자가 해당 정보를 활용할 수 있습니다. 이러한 시나리오에서는 pub/sub 메시징 스타일을 사용하는 것이 적합합니다.

클라우드 네이티브 애플리케이션은 유연성, 확장성, 신속한 배포 등 클라우드 컴퓨팅 고유의 이점을 활용할 수 있도록 구축되어 있으며 마이크로서비스 라고 부르는 작고, 개별적이며, 재사용 가능한 요소들로 구성됩니다. 마이크로서비스를 개별적으로 배포하고, 다른 마이크로서비스와 별개로 실행할 수 있습니다. 다시 말해, 시스템 내 다른 서비스에 영향을 주지 않고 하나의 서미스만 업데이트, 확장, 재시작할 수 있습니다. 마이크로서비스는 컨테이너에 패키징되는 경우가 많고, 여러 마이크로서비스가 모여 애플리케이션 전체를 구성하지만 각각은 서로 다른 데이터베이스와 데이터 모델 등 자체 스택을 가집니다.

마이크로서비스에는 서로 연계하여 작동하기 위한 통신 수단이 필요합니다. 메시지 브로커는 이 공유 통신 근간을 만드는 데 사용하는 하나의 메커니즘입니다.

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

REST API는 마이크로서비스 간의 통신에 일반적으로 사용됩니다. REST(Representational State Transfer)라는 용어는 개발자가 웹 서비스를 구축할 때 따라야 할 일련의 원칙과 제약 조건을 정의합니다. REST를 준수하는 모든 서비스는 일련의 균일한 공유 상태 비저장 연산자 및 요청을 통해 통신할 수 있습니다. API(애플리케이션 프로그래밍 인터페이스)는 REST 규칙을 준수하는 경우 서비스가 서로 통신할 수 있도록 하는 기본 코드를 나타냅니다.

REST API는 HTTP(Hypertext Transfer Protocol)를 사용하여 통신합니다. HTTP는 공개 인터넷의 표준 전송 프로토콜이기 때문에 REST API는 널리 알려져있고, 자주 사용되며, 광범위하게 상호 운용 가능합니다. 그러나 HTTP는 요청/응답 프로토콜이므로 동기 요청/응답이 필요한 상황에 가장 유용합니다. 즉, REST API를 통해 요청을 하는 서비스는 즉각적인 응답을 기대하도록 설계되어야 합니다. 응답을 받는 클라이언트가 다운되면, 답변을 기다리는 동안 전송 서비스가 차단됩니다. 두 서비스에 모두 장애 조치와 오류 처리 논리가 내장되어 있어야 합니다.

메시지 브로커는 송신 서비스가 수신 서비스의 응답을 기다릴 필요가 없도록 서비스 간의 비동기 통신을 가능하게 합니다. 이렇게 하면 브로커를 사용하는 시스템의 내결함성과 복원력이 향상됩니다. 또한 메시지 브로커를 사용하면 pub/sub 메시징 패턴이 변화하는 서비스들을 쉽게 지원할 수 있어 시스템 확장이 쉬워집니다. 메시지 브로커는 소비자의 상태도 추적합니다.

메시지 브로커는 메시지 대기열과 pub/sub을 비롯해 두 개 이상의 메시징 패턴을 지원할 수 있는 반면, 이벤트 스트리밍 플랫폼은 pub/sub 스타일 배포 패턴만 제공합니다. 이벤트 스트리밍 플랫폼은 다량의 메시지에 사용할 수 있도록 설계되어 있어 확장하기 용이하고, 레코드 스트림을 주제라는 카테고리로 정렬하고 미리 지정한 시간 동안 보관할 수 있습니다. 그러나 메시지 브로커와 달리, 이벤트 스트리밍 플랫폼은 메시지 전달을 보장하거나 어느 소비자가 메시지를 받았는지 추적할 수는 없습니다.

이벤트 스트리밍 플랫폼은 메시지 브로커보다 확장성이 뛰어나지만 메시지 재전송과 같은 내결함성장하는 기능이 적고 메시지 라우팅과 대기열 기능이 더 제한적입니다.

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

ESB(엔터프라이즈 서비스 버스)는 기업 전반에 걸쳐 구현된 SOA(서비스 지향 아키텍처)에서 사용되곤 하는 아키텍처 패턴입니다. ESB의 중앙 집중식 소프트웨어 플랫폼은 통신 프로토콜과 데이터 형식을 아키텍처 내 모든 서비스와 애플리케이션이 공유할 수 있는 '공통 언어'로 결합합니다. 예를 들면 하나의 프로토콜(예: XML)에서 받은 요청을 다른 프로토콜(예: JSON)로 변환합니다. ESB는 자동화된 프로세스를 사용하여 메시지 페이로드를 변환합니다. 중앙 집중식 소프트웨어 플랫폼은 연결, 라우팅, 요청 처리 같은 다른 오케스트레이션 논리도 처리합니다.

그러나 ESB 인프라는 복잡하고 통합이 까다로우며 유지 관리 비용이 많이 들 수 있습니다. 프로덕션 환경에서 문제가 발생하면 이를 해결하기 어렵고, 확장하기 쉽지 않으며, 업데이트가 지루하게 이어집니다.

메시지 브로커는 ESB의 '가벼운' 대안으로서, 비슷한 기능(서비스 간 통신 메커니즘)을 보다 간단하고 저렴한 비용으로 제공합니다. ESB의 인기가 떨어지면서 널리 보급되고 있는 마이크로서비스 아키텍처에서 사용하기에 매우 적합합니다.

메시지 브로커를 구현하면 산업 전반과 다양한 기업 컴퓨팅 환경에서 각종 비즈니스 요구 사항을 해결할 수 있습니다. 신뢰할 수 있는 애플리케이션 간 통신과 확실한 메시지 전달이 필요한 상황이라면 언제 어디서나 유용합니다.

메시지 브로커의 주된 채택 방식:

• 금융 거래 및 지불 처리: 결제는 단 한 번만 전송되도록 하는 것이 중요합니다. 이러한 거래 데이터 처리에 메시지 브로커를 사용하면 결제 정보가 손실되거나 실수로 복제되지 않고, 증빙 영수증이 제공되며, 중개 네트워크가 다운되더라도 시스템들이 안정적으로 통신할 수 있습니다.
  
  
• 전자상거래 주문 처리 및 이행: 온라인 사업을 하는 경우 웹사이트와 쇼핑몰 플랫폼의 신뢰성에 브랜드의 명예가 달려 있습니다. 메시지 브로커는 내결함성을 향상시키고 메시지가 한 번만 소비되도록 보장하기 때문에 온라인 주문 처리를 위한 때 자연스러운 선택입니다.
  
  
• 매우 민감한 미사용 및 전송 중 데이터 보호: 엄격한 규제를 받는 업계이거나 기업이 심각한 보안 위험에 직면해 있다면 엔드투엔트 암호화 기능을 갖춘 메시징 솔루션을 권장합니다.