메시지 큐는 메시징 미들웨어 솔루션의 구성요소이며 독립적인 애플리케이션과 서비스에서 정보를 교환할 수 있도록 지원합니다. 메시지 큐는 "메시지", 즉 애플리케이션에서 다른 애플리케이션이 이용할 수 있도록 생성하는 데이터 패킷을, 전송되는 순서대로, 이용하는 애플리케이션에서 해당 메시지를 처리할 수 있는 상태가 될 때까지 저장합니다. 그러면 메시지는 수신 애플리케이션에서 준비될 때까지 안전하게 대기할 수 있습니다. 즉, 네트워크나 수신 애플리케이션에 문제가 생기더라도 메시지 큐에 있는 메시지는 사라지지 않습니다.
비동기식 메시징이라고 하는 이 모델은 데이터 손실을 방지하고, 프로세스나 연결이 중단되더라도 시스템이 계속 작동할 수 있게 합니다. 따라서 개발자는 프로세스와 애플리케이션을 분리하여 통신을 자체 포함하고 이벤트 기반으로 유지하여 아키텍처의 안정성을 강화할 수 있습니다.
메시지 큐는 최적화된 물리적 어플라이언스, 클라우드 서비스, 메인프레임, 소프트웨어 형태 등 다양한 배포 옵션에서 메시징 솔루션에 포함되어 제공됩니다.
메시지 큐잉 솔루션은 다양한 업종에서 광범위하게 쓰이며, 개발자와 시스템 관리자에게 다음과 같은 여러 장점을 제공합니다.
- 안정적인 메시지 전달: 메시지 큐를 사용하면 애플리케이션 간의 비즈니스 크리티컬 메시지가 사라지지 않고 수신 애플리케이션에 단 한 번만 전달되도록 할 수 있습니다. 이러한 기능이 있으면 별도의 중복 제거나 손실 방지 로직이 필요하지 않습니다.
- 애플리케이션 간 연결성: 일부 메시지 큐 솔루션에서는 메시지 암호화, 트랜잭션 속성을 비롯하여 애플리케이션과 서비스 간의 각종 통신 요소를 다룰 수 있습니다. 그러면 애플리케이션 개발이 간소화되고, 상이한 아키텍처 간의 연동이 가능해집니다.
- 다기능: 메시지 큐 솔루션은 Java, Node.js, COBOL, C/C++, Go, .NET, Python, Ruby, C# 등 다양한 언어를 지원할 수 있습니다. MQTT, AMQP, REST 등 다양한 애플리케이션 프로그래밍 인터페이스(API)와 프로토콜도 지원할 수 있습니다.
- 복원성: 비동기식 메시징에서는 애플리케이션 관련 오류가 시스템에 영향을 미치지 않도록 보장합니다. 시스템의 한 구성요소가 멈추더라도 나머지 다른 구성요소는 계속 큐와 연결하면서 메시지를 처리할 수 있습니다. 그러면 시스템 전체의 안정성이 어느 한 부분의 오류로 인해 영향을 받을 가능성이 줄어듭니다.
- 강화된 보안: 메시지 큐에서는 모든 메시지를 식별하고 인증할 수 있습니다. 일부 메시지 큐 솔루션은 메시지가 저장될 때, 전송될 때, 또는 아예 처음부터 끝까지(end-to-end) 메시지를 암호화하도록 설정할 수도 있습니다. 이는 애플리케이션 및/또는 인프라 전반의 보안에 기여할 수 있습니다.
- 통합 파일 전송: 일부 메시지 큐 솔루션은 파일 전송과 같은 부가 기능도 제공합니다. 이는 파일 전송 솔루션이 쓰이는 엔터프라이즈 환경에서 FTP의 대안이 될 수 있습니다.
오늘날의 엔터프라이즈 컴퓨팅 환경은 복잡하고 지극히 분산화되어 있습니다. 메시징을 통해 안정적이고 안전한 단일 공유 메시징 백본을 제공함으로써 각기 다른 플랫폼의 애플리케이션과 서비스를 더 수월하게 통합할 수 있습니다. 그러면 데이터가 유실되지 않으며, 연결이 불안정하더라도 시스템이 계속 작동할 수 있습니다.
메시지 큐는 온프레미스 백엔드 시스템과 클라우드 서비스를 통합하는 데 특히 적합합니다. 클라우드 아키텍처에서는 대개 애플리케이션이 작고 독립적인 구성요소로 나뉩니다. 그러면 설계 및 코딩, 그리고 성능 관리까지 더 용이해집니다. 이처럼 디커플링된 클라우드 기반 애플리케이션은 메시지 큐를 통해 서로 통신하거나 온프레미스 시스템과 통신할 수 있습니다.
메시지 큐잉으로 아키텍처 복원성이 향상됩니다. 메시지가 지속성을 가질 수 있기 때문입니다. 즉, 메시지를 수신하는 서비스에서 처리를 확인할 때까지 메시지가 디스크에 저장됩니다. 메시징 큐는 높은 수준의 보안, 내결함성, 정확성이 요구되는 시나리오, 이를테면 금융 거래 처리, 항공편 예약, 의료 기관의 환자 기록 업데이트 등에 쓰일 수 있습니다.
서로 다른 클라우드(퍼블릭 클라우드 또는 프라이빗 클라우드)에 상주하는 애플리케이션과 시스템이 심지어 서로 다른 국가와 대륙에 있더라도 메시지 큐를 사용하여 통신할 수 있습니다. 메시지 큐를 사용하면 내결함성이 향상됩니다. 그리고 지리적으로, 기술적으로 상이한 시스템 간에 데이터가 중복되거나 손실되는 것을 예방할 수 있습니다. 시스템에 포함된 각 서비스가 디커플링되어 있거나 논리적으로 상호 분리되어 있으므로, 다른 서비스나 애플리케이션이 실패하거나 중지하더라도 계속 작동할 수 있습니다.
메시지 큐는 모바일, IoT, 기존 트랜잭션 시스템 레코드 등 상이한 애플리케이션 사이에서 작동합니다. 그리고 가상 머신, 컨테이너 등 다양한 플랫폼을 지원하며 레거시 애플리케이션과 최신 솔루션 간의 통합도 가능하게 합니다.
메시지 큐 및 pub/sub 비교
메시지 큐에서는 지점간(point-to-point) 메시징 패턴을 사용합니다. 여기서는 한 애플리케이션(발신자)이 큐에 메시지를 보내고, 다른 애플리케이션(수신자)이 큐에서 메시지를 받아 이용합니다. 발신자와 소비자 간에는 강력하게 커플링된 일대일 관계가 성립하며, 각 메시지는 한 번만 이용해야 합니다.
애플리케이션에서 여러 당사자에게 메시지를 배포해야 하는 경우, 여러 개의 메시지 큐를 조합하거나 발행/구독(pub/sub) 메시징 모델을 사용할 수 있습니다.
pub/sub 메시징에서는 메시지를 생성하는 애플리케이션이 발행자, 이용하는 애플리케이션이 구독자입니다. 각 메시지는 하나의 토픽에 발행됩니다. 그 토픽을 구독하는 모든 애플리케이션이 토픽에 발행된 모든 메시지의 사본을 받습니다.
대부분 메시징 미들웨어 솔루션은 메시지 큐(point-to-point)와 pub/sub 메시징 모델 둘 다 지원합니다.
메시지 큐 및 메시지 버스 비교
메시지 버스는 엔터프라이즈 서비스 버스(ESB)의 유형 중 하나로서 서비스가 분산형 시스템 아키텍처 내에서 디커플링된 상태로 독립적으로 작동하면서 유비쿼터스 방식으로 데이터에 액세스할 수 있게 합니다. 메시지 버스를 사용할 경우에는 모든 서비스 또는 애플리케이션이 공통 데이터 유형, 단일 공통 명령 세트, 그리고 (서로 다른 언어로 작성되더라도) 공통 통신 프로토콜을 공유해야 합니다. 소비자가 메시지 사용 방법을 결정할 수 있습니다.
디커플링된 애플리케이션에서 메시지 버스를 통해 통신하는 경우에는 메시지가 모두 같은 유형이 되도록 변환해야 합니다. 이와 달리 메시지 큐에서는 메시지가 같은 유형이든 다른 유형이든 상관없이 메시지를 전송합니다.
메시지 큐 및 웹 서비스 비교
메시징 미들웨어를 거치지 않고 애플리케이션에서 직접 웹 서비스를 통해 통신하거나, SOAP(Simple Object Access Protocol), HTTP 등과 같은 표준 프로토콜 기반 API를 통해 통신할 수 있습니다. 웹 서비스는 분산형 시스템에서 널리 쓰이는데, 비교적 간단하고 구현하기 용이하기 때문에 일부 사용 사례 및 시나리오에서 메시지 큐의 대안이 되곤 합니다.
그러나 메세지 큐와 달리 웹 서비스에서는 메시지 전달을 보장할 수 없습니다. 서버나 연결이 실패하면 클라이언트 내에서 오류를 처리할 수 있도록 빌드해야 합니다. 웹 서비스에는 pub/sub 배포 모델도 없습니다. 메시징 미들웨어는 더 강력한 내결함성을 제공하며, 대규모 트래픽이나 활동 버스트를 더 효과적으로 처리합니다.
어떤 경우에 API를 사용할지, 메시징을 사용할지 또는 둘 다 사용할지에 관해서는 "API 및 메시징 입문"을 참조하세요.
메시지 큐 및 데이터베이스 비교
데이터베이스는 경우에 따라 메시지 큐 대신 쓰일 수 있으나, 대개는 용도가 다르기 때문에 서로 쉽게 대안이 될 수 없습니다. 데이터베이스는 저장소로 가장 많이 쓰이며, 같은 정보에 대한 반복적인 액세스를 가능하게 합니다. 메시지 큐는 저장소 용도로는 사용할 수 없습니다. 일단 이용된 메시지는 큐에서 삭제됩니다.
메시지 큐와 비슷한 기능을 데이터베이스에 설계하는 것은 가능하지만, 상당한 코딩 작업과 지식이 필요합니다. 데이터베이스는 단순한 큐 구조를 복제하는 용도로만 사용할 수 있으며, 대규모 애플리케이션에 맞게 확장할 수 없습니다.
"데이터베이스 환경 개요"에서 데이터베이스와 그 기능에 관해 자세히 알아보세요.
지금까지는 IT 팀 내의 전담 팀에서 메시지 큐잉을 관리했습니다. 그러나 클라우드 호스팅 메시지 큐를 사용하는 "as-a-service" 전달 방식에서는 개인이나 LOB(line-of-business) 사용자가 포털을 통해 직접 메시징 인프라에 대한 변경을 요청할 수 있으며, 이로서 더 우수한 민첩성을 발휘할 수 있습니다.
Message-queuing-as-a-Service는 클라우드 네이티브 개발에서 흔히 볼 수 있는 서버리스 또는 마이크로서비스 아키텍처에서 자연스럽게 잘 작동합니다. 클라우드 호스팅 서비스 모델에 제공되므로, 클라우드 제공자가 메시징 인프라의 프로비저닝, 설치, 유지 보수를 모두 담당하며, 클라우드에서 호스팅됩니다.
IBM MQ를 사용하여 통신하는 애플리케이션 개발의 입문자라면 다음 튜토리얼을 참조하세요.
아래에서는 더 포괄적인 개요를 제공합니다.
IBM® Cloud Pak for Integration은 AI 자동화와 포괄적인 통합 툴 세트를 결합하여 클라우드 또는 온프레미스 환경에서 애플리케이션과 데이터를 연결할 수 있게 합니다.
IBM Cloud에서 구축된 하이브리드 클라우드 솔루션을 활용하여 기업이 클라우드로 마이그레이션하고 기존 앱을 현대화하며 신규 클라우드 네이티브 앱을 구축하는 방법을 살펴봅니다.