메시지 브로커

menu icon

메시지 브로커

메시지 브로커는 클라우드 네이티브, 마이크로서비스 기반, 서버리스 및 하이브리드 클라우드 아키텍처를 지원하기 위한 공통 통합 메커니즘을 구축하는 데 도움이 되는 애플리케이션간 통신 기술입니다.

메시지 브로커란?

메시지 브로커는 애플리케이션, 시스템 및 서비스가 서로 간에 통신하고 정보를 교환할 수 있도록 해주는 소프트웨어입니다. 메시지 브로커는 정규 메시징 프로토콜 간에 메시지를 변환함으로써 이를 수행합니다. 이를 이용하여 상호 의존적인 서비스는 상이한 언어로 작성되거나 상이한 플랫폼에서 구현된 경우에도 서로 간에 직접 "대화"를 실시할 수 있습니다.

메시지 브로커는 메시징 미들웨어 또는 메시지 지향 미들웨어(MOM) 솔루션 내의 소프트웨어 모듈입니다. 이러한 유형의 미들웨어는 자체 코어 논리에만 집중할 수 있도록 애플리케이션의 컴포넌트 간에 데이터의 플로우를 처리하는 표준화된 수단을 개발자에게 제공합니다. 이는 다수의 플랫폼을 아우르는 애플리케이션이 내부적으로 통신할 수 있도록 허용하는 분산 통신 계층의 역할을 수행할 수 있습니다.

메시지 브로커는 메시지를 검증, 저장, 라우팅하고 이를 적절한 대상에 전달할 수 있습니다. 이는 다른 애플리케이션 간의 중개자 역할을 함으로써 수신자의 위치, 수신자가 활성인지 여부 또는 수신자의 수를 잘 몰라도 송신자가 메시지를 발행할 수 있도록 허용합니다. 이를 통해 시스템 내에서 프로세스와 서비스의 디커플링이 용이해질 수 있습니다.

신뢰할 수 있는 메시지 스토리지와 보장된 딜리버리를 제공하기 위해, 메시지 브로커는 이용하는 애플리케이션이 처리할 수 있을 때까지 메시지를 저장하고 순서화하는 메시지 큐라고 하는 하위 구조 또는 구성요소에 종종 의존합니다. 메시지 큐에서 메시지는 전송된 정확한 순서대로 저장되며, 인수되었는지 확인될 때까지 큐에 남아 있습니다.

비동기 메시징(15:11)은 메시지 브로커를 통해 가능한 애플리케이션간 통신의 유형을 나타냅니다. 이는 소중한 데이터의 유실을 방지하며, 공용 네트워크에서 흔하게 나타나는 단속적인 연결 혹은 지연 문제가 발생해도 시스템이 계속해서 작동될 수 있도록 보장합니다. 비동기 메시징은 메시지가 다른 메시지와 상대적인 올바른 순서로 단 한 번만 전달되도록 보장합니다.

메시지 브로커는 데이터 라우팅, 메시지 변환, 지속성 및 클라이언트 상태 관리 기능을 제공하는 서비스와 함께 다수의 메시지 큐 간의 상호작용을 처리하기 위한 큐 관리자로 구성될 수 있습니다.

메시지 브로커 모델

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

  • 포인트-투-포인트 메시징: 이는 메시지의 송신자와 수신자 간에 일대일 관계를 지닌 메시지 대기열에서 사용되는 분배 패턴입니다. 큐의 각 메시지는 하나의 수신자에게만 전송되며, 오직 한 번만 이용됩니다. 포인트-투-포인트 메시징은 메시지가 한 번만 실행되어야 하는 경우에 호출됩니다. 이 메시징 스타일의 적합한 유스케이스의 예로는 급여 및 재무 트랜잭션 처리를 들 수 있습니다. 이러한 시스템에서, 송신자와 수신자 모두에게는 각 지불이 오직 한 번만 전송되도록 하는 보장이 필요합니다.
  • 발행/구독 메시징: 이 메시지 분배 패턴(종종 "발행/구독"이라고 함)에서 각 메시지의 생성자는 이를 토픽에 발행하고, 다수의 메시지 이용자는 해당 메시지를 수신하고자 하는 토픽을 구독합니다. 토픽에 대해 발행된 모든 메시지는 이를 구독한 모든 애플리케이션에 분배됩니다. 이는 메시지의 발행자와 이용자 사이에 일대다 관계가 있는 브로드캐스트 스타일의 분배 방법입니다. 예를 들어, 항공사가 항공기의 착륙 시간이나 지연 상태에 대한 업데이트를 전파하려는 경우 다음의 여러 당사자가 해당 정보를 활용할 수 있습니다. 항공기 정비와 재급유를 수행하는 지상 근무자, 수하물 담당자, 항공기의 차기 운행을 준비하는 승무원과 조종사, 그리고 대중에게 알리는 시각적 디스플레이의 운영자. 발행/구독 메시징 스타일은 이러한 시나리오에서 사용하기에 적절합니다.

클라우드 아키텍처의 메시지 브로커

클라우드 네이티브 애플리케이션은 유연성, 확장성 및 신속한 배치를 포함하여 클라우드 컴퓨팅의 고유한 장점을 활용하도록 빌드됩니다. 이러한 애플리케이션은 마이크로서비스라고 하는 소형의 개별적이고 재사용 가능한 컴포넌트로 구성됩니다. 각 마이크로서비스는 배치되어 다른 서비스와 독립적으로 실행될 수 있습니다. 이는 시스템의 다른 서비스에 영향을 주지 않고도 이들 중 하나를 업데이트, 스케일링 또는 다시 시작할 수 있음을 의미합니다. 서로 간에 다를 수 있는 데이터베이스와 데이터 모델을 포함하여 각각 자체 스택을 보유함에도 불구하고, 종종 컨테이너에 패키징된 마이크로서비스는 함께 작동하여 전체 애플리케이션을 구성합니다.

마이크로서비스는 서로 알맞게 작동하기 위해 서로 간의 통신 수단을 갖추어야 합니다. 메시지 브로커는 이러한 공유 통신 백본을 작성하기 위해 사용되는 하나의 메커니즘입니다.

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

메시지 브로커 vs. API

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

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

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

메시지 브로커 vs. 이벤트 스트리밍 플랫폼

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

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

이벤트 기반 아키텍처에 대해 자세히 알아봅니다.

메시지 브로커 vs. ESB(엔터프라이즈 서비스 버스)

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

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

메시지 브로커는 보다 간편하고 보다 저렴한 비용으로 유사한 기능(서비스간 통신을 위한 메커니즘)을 제공하는 ESB에 대한 "경량"의 대체 기능입니다. 이는 ESB가 인기를 잃은 상태에서 더욱 널리 퍼지게 되었던 마이크로서비스 아키텍처에서 사용하기에 매우 적합합니다.

메시지 브로커 유스케이스

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

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

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

메시지 브로커 및 IBM Cloud

기업들이 클라우드로의 여정에서 애플리케이션을 현대화하면서, 메시지 브로커는 새로운 유형을 중요성을 간직하고 있습니다. Fortune 100대 기업의 85%를 포함하여, 전 세계에서 가장 성공한 기업들 중 다수는 오늘날의 애자일 개발 환경, 마이크로서비스 기반 및 하이브리드 클라우드 인프라, 그리고 다양한 시스템 유형 및 연결 요구사항을 지원할 수 있도록 구축된 IBM의 메시지 브로커 기능을 활용하고 있습니다.

차기 단계 진행: 첨단 엔터프라이즈 메시징 솔루션인 IBM MQ의 코어 기능 위에 구축된 IBM Cloud Pak for Integration에 대해 알아봅니다.

IBM Cloud 계정으로 지금 시작하세요.