메시지 큐

메시징 미들웨어 솔루션의 구성요소이다.

미들웨어? 미들웨어는 분산 네트워크에서 애플리케이션 또는 구성 요소 간에 하나 이상의 종료의 통신 또는 연결을 가능하게 하는 소프트웨어로, 기본적으로 다른 시스템을 하나로 묶는 소프트웨어 접착제를 생성한다.

• 일종의 통신에 중점을 둔 메시지 브로커 또는 트랜잭션 처리 모니터이다.
• 특정 유형의 앱을 구축하는데 필요한 모든 통신 및 연결 기능을 제공하는 WAS 또는 모바일 디바이스
• 클라우드 기반 (iPaaS) 또는 기업 내 모든 구성 요소를 연결하는 중앙 집중식 통합 허브 역할을 하는 엔터프라이즈 서비스 버스 이다.

독립적인 애플리케이션과 서비스에서 정보를 교환할 수 있도록 지원한다. 메시지 큐는 ‘메시지’, 즉 애플리케이션에서 다른 애플리케이션이 이용할 수 있도록 생성하는 데이터 패킷을 전송되는 순서대로 이용하는 애플리케이션에서 해당 메시지를 처리할 수 있는 상태가 될 때까지 저장한다. 그러면 메시지는 수신 App에서 준비될 때까지 안전하게 대기할 수 있다. 즉, 네트워크나 수신 애플리케이션에 문제가 생기더라도 메시지 큐에 있는 메시지는 사라지지 않는다.

비동기식 메시징이라고 하는 이 모델은 데이터 손실을 방지하고 프로세스나 연결이 중단되더라도 시스템이 계속 동작할 수 있게 한다. 따라서 개발자는 프로세스와 애플리케이션을 분리하여 통신을 자체 포함하고 이벤트 기반으로 유지하여 아키텍처의 안정성을 강화한다.

장점

• 안정적인 메시지 전달

  메시지 큐를 사용하면 App 간의 비즈니스 크리티컬 메시지가 사라지지 않고 수신 App에 단 한번만 전달되도록 할 수 있다. 별도의 중복 제거나 손실 방지 로직이 필요하지 않게 된다.

• 애플리케이션 간 연결성

  일부 MQ 솔루션에서는 메시지 암호화, 트랜잭션 속성을 비롯하여 App과 서비스 간의 각종 통신 요소를 다룰 수 있다.

• 다기능

  Java, Node.js, C/C++, Go, .NET, python, C# 등 다양한 언어를 지원할 수 있다. MQTT, REST 등 다양한 App 프로그래밍 인터페이스와 프로토콜도 지원할 수 있다.

• 복원성

  비동기식 메시징에서는 App 관련 오류가 시스템에 영향을 미치지 않도록 보장한다. 시스템의 한 구성요소가 멈추더라도 나머지 다른 구성요소는 계속 큐와 연결하면서 메시지를 처리할 수 있다.

• 강화된 보안

  모든 메시지를 식별하고 인증할 수 있다. 일부 메시지 큐 솔루션은 메시지가 저장, 전송될 때 혹은 아예 처음부터 끝까지 메시지를 암호화하도록 설정할 수 있다.

• 통합 파일 전송

  파일 전송같은 부가 기능도 제공한다.

사례

온프레미스 백엔드 시스템과 클라우드 서비스를 통합하는데 특히 적합하다. 클라우드 아키텍처에서는 대개 애플리케이션이 작고 독립적인 구성요소로 나뉜다. 그러면 설계 및 코딩, 그리고 성능 관리까지 더 용이해진다. 이처럼 디커플링된 클라우드 기반 App은 메시지 큐를 통해 서로 통신하거나 온프레미스 시스템과 통신할 수 있다.

메시지 큐 및 기타 메시징 모델 비교

메시지 큐 및 pub/sub 비교

메시지 큐에서는 지점간 메시징 패턴을 사용한다. 여기서는 한 애플리케이션(발신자)이 큐에 미시지를 보내고 다른 App(수신자)이 큐에서 메시지를 받아 이용한다. 발신자와 소비자 간에는 강력하게 커플링된 일대일 관계가 성립하며 각 메시지는 한 번만 이용해야 한다.

애플리케이션에서 여러 당사자에게 메시지를 배포해야 하는 경우, 여러 개의 메시지 큐를 조합하거나 발행/구독 메시징 모델을 사용할 수 있다.

pub/sub 메시징에서는 메시지를 생성하는 App이 발행자, 이용하는 App이 구독자이다. 각 메시지는 하나의 토픽에 발행된다. 그 토픽을 구독하는 모든 App이 토픽에 발행된 모든 메시지의 사본을 받는다.

대부분 메시징 미들웨어 솔루션은 메시지 큐와 pub/sub 메시징 모델 둘 다 지원한다.

메시지 큐 및 메시지 버스 비교

메시지 버스는 엔터프라이즈 서비스 버스의 유형 중 하나로서 서비스가 분산형 시스템 아키텍처 내에서 디커플링된 상태로 독립적으로 작동하면서 유비쿼터스 방식으로 데이터에 액세스할 수 있게 한다. 메시지 버스를 사용할 경우에는 모든 서비스 또는 App이 공통 데이터 유형, 단일 공통 명령 세트 그리고 공통 통신 프로토콜을 공유해야한다. 소비자가 메시지 사용 방법을 결정할 수 있다.

디커플링된 App에서 메시지 버스를 통해 통신하는 경우에는 메시지가 모두 같은 유형이 되도록 변환해야 한다. 이와 달리 메시지 큐에서는 메시지가 같은 유형이든 다른 유형이든 상관없이 메시지를 전송한다.

웹 서비스와 비교

메시징 미들웨어를 거치지 않고 App에서 직접 웹 서비스를 통해 통신하거나 SOAP(Simple Ombject Access Protocol), HTTP 등과 같은 표준 프로토콜 기반 API를 통해 통신할 수 있는데, 웹 서비스는 분산형 시스템에서 널리 쓰이며 비교적 간단하고 구현이 용이하기 때문에 일부 사용 사례 및 시나리오에서 메시지 큐의 대안이 되곤 한다. 그러나 메시지 큐와 달리 웹 서비스에서는 메시지 전달을 보장할 수 없다. 서버나 연결이 실패하면 클라리언트 내에서 오류를 처리할 수 있도록 빌드해야 하며, 또한 웹 서비스엔 pub/sub 배포 모델이 없다.

메시징 미들웨어는 더 강려한 내결함성을 제공하며, 대규모 트래픽이나 활동 버스트를 더 효과적으로 처리한다.

데이터베스와 비교

서로 쉽게 대안이 될 수 없다. DB는 저장소로 가장 많이 쓰이며 같은 정보에 대한 반복적인 액세스를 가능하게 한다. 메시지 큐는 저장소 용도로는 사용할 수 없으며 일단 이용된 메시지는 큐에서 삭제된다.

메시지 큐와 비슷한 기능을 DB에 설계하는 것은 가능하나, 상당한 지식과 작업이 필요하다. DB는 단순한 큐 구조를 복제하는 용도로만 사용할 수 있으며, 대규모 App에 맞게 확장할 수 없다.