メッセージ・キューとは、独立したアプリケーションとサービスが情報を交換できるようにするメッセージング・ミドルウェア・ソリューションのコンポーネントです。 メッセージ・キューは、アプリケーションが、他のアプリケーションの消費用に作成したパケット・データである「メッセージ」を、消費するアプリケーションが処理できるようになるまで、送信された順に保存します。 これにより、受信アプリケーションの準備が整うまでメッセージは安全に待つことができ、ネットワークや受信アプリケーションに問題が発生しても、メッセージ・キュー内のメッセージが失われることはありません。
非同期メッセージングと呼ばれるこのモデルは、プロセスや接続に障害が発生しても、データの損失を防ぎ、システムを継続的に機能させることができます。 これにより、開発者はプロセスとアプリケーションを分離し、これらの通信を自己完結的かつイベント・ドリブンに保ち、アーキテクチャーの信頼性を高めることができます。
メッセージ・キューは、最適化された物理的なアプライアンス、クラウド・サービス、メインフレーム、またはソフトウェアなど、さまざまな導入方法があるメッセージング・ソリューションで利用できます。
メッセージ・キューイング・ソリューションは、産業界で広く利用されており、開発者やシステム管理者に以下のようなさまざまなメリットをもたらします。
- 信頼性の高いメッセージ配信：メッセージ・キューを使用することで、アプリケーション間でビジネス上重要なメッセージが失われることなく、また、受信者に1度しか配信されないことが保証されます。 この機能があれば、重複排除や紛失防止のためのロジックを追加する必要はありません。
- アプリケーション間の接続性：メッセージ・キュー・ソリューションの中には、メッセージの暗号化、トランザクション、およびその他のアプリケーションやサービス間の通信を処理できるものがあります。 これにより、アプリケーションの開発が容易になり、異種アーキテクチャーの連携が可能になります。
- 汎用性：メッセージ・キュー・ソリューションは、Java、Node.js、COBOL、C/C++、Go、.NET、Python、Ruby、およびC#など、複数の言語に対応しています。 また、MQTT、AMQP、およびRESTなど、数多くのアプリケーション・プログラミング・インターフェース（API）やプロトコルにも対応しています。
- レジリエンス：非同期メッセージングにより、アプリケーション固有の障害がシステムに影響を与えることはありません。 システム内の1つのコンポーネントが停止しても、他のコンポーネントはキューとの対話やメッセージの処理を続けることができます。 これにより、一部の障害がシステム全体の安定性に影響を与える可能性が低くなります。
- セキュリティーの強化：メッセージ・キューは、すべてのメッセージを識別し、認証できます。また、メッセージ・キュー・ソリューションの中には、保存中、転送中、またはエンドツーエンドでメッセージを暗号化するように設定できるものもあります。 これにより、アプリケーションやインフラストラクチャーの全体的なセキュリティーに貢献することができます。
- 統合されたファイル転送：メッセージ・キュー・ソリューションの中には、ファイル転送機能などの追加機能を備えたものがあります。 企業内でFTPに代わるソリューションとして利用することができます。
今日のエンタープライズのコンピューティング環境は、複雑で高度に分散化されています。 メッセージングは、単一の、堅固で、安全な共有メッセージング・バックボーンを提供することで、多様なプラットフォーム上のアプリケーションとサービスの統合を容易にします。 これにより、データの損失を防ぎ、接続が不安定な状態でもシステムの機能を維持することができます。
メッセージ・キューは、オンプレミスのバックエンド・システムをクラウド・サービスに連携させるのに特に適しています。 クラウド・アーキテクチャーでは、アプリケーションは多くの場合、小さくて独立したコンポーネントに分割されます。 これにより、設計やコーディングが容易になり、パフォーマンスの管理もしやすくなります。 メッセージ・キューは、これらの分離されたクラウド・ベースのアプリケーションが、相互に、あるいはオンプレミスのシステムと通信することを可能にします。
メッセージ・キューイングは、メッセージに永続性を持たせることができるため、アーキテクチャーのレジリエンスが向上します。 これは、メッセージを受け取ったサービスが処理を確認するまで、ディスクに保存されることを意味します。 メッセージング・キューは、金融取引の処理、航空券の予約、または患者の医療記録の更新など、高度なセキュリティー、フォールト・トレランス、および正確性が要求される場面で使用することができます。
また、メッセージ・キューを利用することで、パブリッククラウド かプライベートクラウドかを問わず、異なる国や大陸に存在するアプリケーションやシステムの通信が可能になります。 メッセージ・ キューを使用することで、フォールト・トレランスが向上し、地理的、技術的に異なるシステム間でのデータの重複や消失を防ぐことができます。 システム内の各サービスは、他のサービスから切り離されているか、または論理的に分離されているため、他のサービスやアプリケーションで障害や停滞が発生しても、各サービスは機能し続けることができます。
メッセージ・キューは、モバイル、IoT、および従来のトランザクション・システムの記録など、異なるアプリケーション間で動作します。 また、仮想マシンやコンテナなどのさまざまなプラットフォームに対応しており、レガシー・アプリケーションと今日の最新のソリューションとの統合を可能にします。
メッセージ・キューとpub/sub
メッセージ・キューは、あるアプリケーション（送信者と呼ばれる）がメッセージをキューに送信し、別のアプリケーション（受信者と呼ばれる）がキューからメッセージを取得して消費するという、ポイント・ツー・ポイントのメッセージング・パターンを採用しています。 送信者と消費者の間には密接に結びついた1対1の関係があり、各メッセージは一度だけ消費されるものでなければなりません。
複数の相手にメッセージを配信する必要があるアプリケーションでは、複数のメッセージ・キューを組み合わせるか、パブリッシュ／サブスクライブ（pub/sub）メッセージング・モデルを使用します。
pub/subメッセージングでは、メッセージを作成するアプリケーションをパブリッシャーと呼び、メッセージを消費するアプリケーションをサブスクライバーと呼びます。 各メッセージはトピックに公開され、そのトピックを購読しているすべてのアプリケーションは、そのトピックに公開されたすべてのメッセージのコピーを取得します。
ほとんどのメッセージング・ミドルウェア・ソリューションは、メッセージ・キュー（2地点間）とpub/subメッセージング・モデルの両方をサポートしています。
メッセージ・キューとメッセージ・バス
エンタープライズ・サービス・バス、またはESBの一種であるメッセージ・バスは、サービスがデータに自由にアクセスすることを可能にする一方で、分散型システム・アーキテクチャーの中で各サービスが分離され、独立して機能する状態を維持することができます。 メッセージ・バスを採用した場合、すべてのサービスやアプリケーションは、共通のデータ・タイプ、共通のコマンド・セット、および共通の通信プロトコルを共有する必要があります（ただし、それぞれが異なる言語で書かれている場合もあります）。 消費者はメッセージの使用方法を決定できます。
分離されたアプリケーションがメッセージ・バスを介して通信する場合、メッセージはすべて同じタイプになるように変換する必要があります。 一方、メッセージ・キューは、同じ種類でも、異なる種類でも、メッセージを転送します。
メッセージ・キューとWebサービス
アプリケーションは、メッセージング・ミドルウェアを介さずに、Simple Object Access Protocol（SOAP）やHTTPなどの標準プロトコルに基づくWebサービスやAPIを介して直接通信することができます。 Webサービスは、分散システムで広く使われており、比較的シンプルで実装が容易なため、特定のユースケースやシナリオでは、メッセージ・キューに代わる有力な手段となります。
しかし、メッセージ・キューとは異なり、Webサービスはメッセージの配信を保証することはできません。 サーバーや接続に失敗した場合、クライアント内でエラーを処理する機能を構築する必要があります。 また、Webサービスには、pub/subの配信モデルがありません。 メッセージング・ミドルウェアは、フォールト・トレランスが高く、重いトラフィックやアクティビティーのバーストへの対応力に優れています。
APIを使用する場合、メッセージングを使用する場合、または両方を使用する場合の詳細については、「APIとメッセージングの概要」を参照してください。
メッセージ・キューとデータベース
データベースは、特定の状況下ではメッセージ・キューの代替として使用することができますが、ほとんどの場合、両者の用途は異なるので、容易に入れ替えることはできません。 データベースはストレージに最も一般的に使われ、同じ情報に何度もアクセスすることができます。 メッセージ・キューはストレージの目的では使用できません。 メッセージが消費されると、そのメッセージはキューから削除されます。
メッセージ・キューのような機能をデータベースに設計することは可能ですが、それには膨大なコーディングの労力と知識が必要です。 データベースは、単純なキュー構造の複製にしか使用できず、大規模なアプリケーションに対応できるほどの拡張はできません。
データベースとその機能について詳しくは、「データベース・ランドスケープの概要」（英語）を参照してください。
メッセージ・キューイングは、従来、IT内の専任チームによって管理されていました。 しかし、クラウド・ホスティングのメッセージ・キューを利用した「サービスとして」のデリバリーでは、個人や基幹業務（LOB）ユーザーがポータルを介して独自にメッセージング・インフラストラクチャーの変更を要求することができ、俊敏性を高めることができます。
サービスとしてのメッセージ・キューイングは、クラウドネイティブ開発で一般的なサーバーレス・アーキテクチャーやマイクロサービス・アーキテクチャー内で自然に機能します。 クラウド・ホスティング・サービス・モデルで提供されるため、メッセージング・インフラストラクチャーのプロビジョニング、インストール、およびメンテナンスはすべてクラウド・プロバイダーが行い、クラウド上でホストされます。
これらのチュートリアルは、IBM MQを介して通信するアプリケーションを初めて開発する場合に役立ちます。
その他以下の参考情報から、より包括的な概要を知ることができます。
IBM Cloud Pak for Integrationは、AIによる自動化と一連の包括的な統合ツールを組み合わせることで、あらゆるクラウド環境、またはオンプレミス環境のアプリケーションとデータを接続します。
IBM Cloudで構築されたハイブリッドクラウド・ソリューションは、クラウドへの移行、既存のアプリケーションのモダナイゼーション、新しいクラウドネイティブ・アプリケーションの構築を支援します。