メッセージキューは、独立したアプリケーションやサービスが情報を交換できるようにするメッセージング・ミドルウェア・ソリューションのコンポーネントです。
メッセージ・キューには、消費側アプリケーションが処理できるまで、アプリケーションが送信された順序で使用できるように作成する「メッセージ」またはデータのパケットが保管されます。これにより、メッセージは受信アプリケーションの準備が整うまで安全に待機できるため、ネットワークや受信アプリケーションに問題が発生した場合でも、メッセージ・キュー内のメッセージが失われません。
非同期メッセージングと呼ばれるこのモデルは、データの損失を防ぎ、プロセスまたは接続が失敗した場合でもシステムが継続することを可能にします。これにより、開発者はプロセスとアプリケーションを分離し、通信を自己完結型かつイベント駆動型に保ち、アーキテクチャの信頼性を高めることができます。
メッセージ・キューは、最適化された物理アプライアンス、クラウド・サービス、メインフレーム、ソフトウェア形式など、多数のデプロイメント・オプションにわたるメッセージング・ソリューションで利用できます。
The DX Leaders
「The DX Leaders」は日本語でお届けするニュースレターです。AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。
メッセージ・キューイング・ソリューションは、さまざまな業種・業務で広く使用されています。開発者にもシステム管理者にも、以下のようなさまざまなメリットがあります。
- 信頼性の高いメッセージ配信：メッセージ・キューを使用することで、アプリケーション間のビジネスクリティカルなメッセージが失われず、それらが受信者に一度だけ配信される状態を確保します。この機能があれば、追加の重複排除や損失防止ロジックは不要です。
- アプリケーション間の接続： 一部のメッセージ・キュー・ソリューションは、アプリケーションとサービス間のメッセージ暗号化、トランザクション性、その他の通信的側面を処理できます。これにより、アプリケーションの開発が簡素化され、異種のアーキテクチャーの連携が可能になります。
- 汎用性：メッセージキュー・ソリューションは、Java 、Node.js、COBOL、C/C++、Go、.NET、Python、Ruby、およびC#などの複数の言語をサポートできます。また、MQTT、AMQP、RESTなど、多数のアプリケーション・プログラミング・インターフェース（API）とプロトコルもサポートできます。
- 弾力性：非同期メッセージングにより、アプリケーション固有の障害がシステムに影響を与えません。システム内の1つのコンポーネントが停止しても、他のすべてのコンポーネントがキューと対話を継続し、メッセージを処理できます。これにより、ある部品の故障によってシステム全体の安定性が影響を受ける可能性が低くなります。
- セキュリティの向上：メッセージ・キューはすべてのメッセージを識別し、認証できます。一部のメッセージ・キュー・ソリューションでは、保存中、転送中、またはエンドツーエンドのメッセージを暗号化するように設定できます。この設定により、アプリケーションとインフラの全体的なセキュリティを強化できます。
- 統合ファイル転送：一部のメッセージ・キュー・ソリューションには、ファイル転送機能などの追加機能が含まれています。これは、このようなソリューションが使用されている企業内でFTPの代替として使用できます。
今日のエンタープライズ・コンピューティング環境は複雑で、高度に分散化されています。メッセージングは、堅牢で安全な単一の共有メッセージング・バックボーンを提供することで、さまざまなプラットフォームに、アプリケーションとサービスを簡単に統合できます。これにより、データ損失を防ぎ、接続が不安定な場合でもシステムが機能し続けることが保証されます。
メッセージ・キューは、オンプレミスのバックエンド・システムとクラウドサービスの統合において特に適しています。クラウド・アーキテクチャでは、多くの場合、アプリケーションは小さな独立したコンポーネントに分割されます。これにより、設計とコーディングが容易になり、またパフォーマンスの管理も容易になります。メッセージ・キューを使用すると、これらの分離されたクラウドベースのアプリケーションは、相互に通信したり、オンプレミス・システムと通信したりできます。
メッセージ・キューイングは、メッセージに永続性があるため、アーキテクチャーのレジリエンスを高めます。つまり、メッセージを受信したサービスが処理を確認するまで、それらのメッセージはディスクに保管されます。メッセージング・キューは、金融トランザクション処理、航空旅行の予約、医療患者記録の更新など、高レベルのセキュリティー、フォールト・トレランス、正確性が必要なシナリオで使用できます。
メッセージ・キューを使用すると、異なるクラウド（パブリッククラウドまたはプライベートクラウド）に存在するアプリケーションやシステムが、異なる国または地域や遠隔地にある場合でも通信できるようになります。メッセージ・キューを使用するとフォールト・トレランスが向上し、地理的および技術的に異種のシステム間でのデータの重複や損失を防ぐために使用できます。システム内の各サービスは切り離され、つまり論理的に分離されているため、他のサービスやアプリケーションが障害を起こしたり停止したりしても、それぞれのサービスは機能し続けることができます。
メッセージ・キューは、モバイル、IoT、従来のトランザクション・システム・レコードなどのさまざまなアプリケーション間で機能します。また、仮想マシンやコンテナなどのさまざまなプラットフォームをサポートし、レガシー・アプリケーションと今日の最新ソリューションとの統合を可能にします。
メッセージ・キューと公開／サブスクリプション
メッセージ・キューは、あるアプリケーション（送信者と呼ばれる）がキューにメッセージを送信し、別のアプリケーション（受信者と呼ばれる）がそのキューからメッセージを取得して使用する、ポイントツーポイントのメッセージング・パターンを使用します。送信者と消費者の間には、緊密に結合された1対1の関係が必要であり、各メッセージは1回だけ使用されます。
アプリケーションで複数の当事者にメッセージを配布する必要がある場合は、複数のメッセージ・キューを組み合わせるか、出版-購読（Pub/Sub）メッセージング・モデルを使用できます。
出版-購読メッセージングでは、メッセージを生成するアプリケーションはパブリッシャーと呼ばれ、それを使用するアプリケーションはサブスクライバーと呼ばれます。各メッセージはトピックに分類され、そのトピックをサブスクライブするすべてのアプリケーションは、発行されるすべてのメッセージのコピーを取得します。
ほとんどのメッセージング・ミドルウェア・ソリューションは、メッセージ・キュー（ポイントツーポイント）と出版-購読メッセージング・モデルの両方をサポートしています。
メッセージ・キューとメッセージ・バスの違い
メッセージ・バスは、エンタープライズ・サービス・バス（ESB）の一種であり、サービスがデータにユビキタスにアクセスできるようにすると同時に、分散システム・アーキテクチャー内で分離され、独立して機能することを保証します。メッセージ・バスを採用する場合、すべてのサービスまたはアプリケーションで共通のデータ型、共通のコマンド・セット、および共通の通信プロトコルを共有する必要があります（ただし、それらは異なる言語で記述されている場合があります）。エンド・ユーザーは、メッセージの使用方法を決定できます。
分離されたアプリケーションがメッセージ・バスを通じて通信する場合、メッセージはすべて同じタイプになるように変換する必要があります。対照的に、メッセージ・キューは、同じ種類か異なる種類かに拘らずメッセージを転送します。
メッセージ・キューとWebサービスの違い
アプリケーションは、メッセージング・ミドルウェアを経由する代わりに、Simple Object Access Protocol（SOAP）やHTTPなどの標準プロトコルに基づくWebサービスまたはAPIを介して直接通信できます。Webサービスは分散システムで広く使用されており、比較的シンプルで実装が簡単であるため、特定のユースケースやシナリオではメッセージ・キューに代わる利用可能なサービスです。
ただし、メッセージ・キューとは異なり、Webサービスはメッセージの配信を保証することはできません。サーバーまたは接続に障害が発生した場合は、クライアント内でエラーを処理する機能を構築する必要があります。Webサービスには、pub/sub配信モデルもありません。メッセージング・ミドルウェアは、耐障害性が高く、大量のトラフィックやアクティビティー・バーストを処理する能力が向上します。
APIを使用するタイミング、メッセージングを使用するタイミング、またはその両方を使用するタイミングの詳細については「APIとメッセージングの概要」を参照してください。
メッセージ・キューとデータベースの違い
データベースは、特定の状況ではメッセージ・キューの代わりとして使用できます。ただし、それらの目的は異なっており、ほとんどの場合、容易に入れ替えることはできません。データベースはストレージとして最も一般的に使用され、同じ情報に何度もアクセスできます。メッセージ・キューはストレージ目的では使用できません。メッセージが消費されると、そのメッセージはキューから削除されます。
メッセージ・キューのような機能をデータベースに設計することは可能ですが、多くのコーディング作業と知識が必要です。データベースは、単純なキュー構造を複製するためにのみ使用可能であり、大規模なアプリケーションにおいてはスケーラブルではありません。
データベースとその機能の詳細については、「データベース・ランドスケープの概要」を参照してください。
メッセージ・キューイングは、従来、IT部門内の専任チームによって管理されていました。しかし、クラウドでホストされるメッセージ・キューを使用した「as-a-service」配信では、個人または基幹業務（LOB）ユーザーがポータルを通じてメッセージング・インフラストラクチャーへの変更を独自にリクエストできるため、俊敏性が向上します。
Message-queuing-as-a-serviceは、クラウドネイティブ開発で一般的なサーバーレス・アーキテクチャーまたはマイクロサービス・アーキテクチャー内で問題なく機能します。クラウド・ホスト型サービス・モデルで提供されるため、メッセージング・インフラストラクチャーのプロビジョニング、インストール、保守はすべてクラウド・プロバイダーが処理し、クラウドでホストされます。
IBM® MQを介して通信するアプリケーションの開発を初めて行う場合は、次のチュートリアルが役立ちます。
これらの追加リソースでは、より包括的な概要が得られます。
参考情報
AIを活用した自動化機能で、API、アプリケーション、イベント、ファイル、B2B/EDIにおいて俊敏性を促進します。
アプリケーションとシステムを接続して重要なデータに迅速かつ安全にアクセスする IBM 統合ソリューションにより、ビジネスの可能性を最大限に引き出します。
IBM Cloudコンサルティング・サービスで新しい機能を解き放ち、ビジネスの俊敏性を高めましょう。ハイブリッドクラウド戦略と専門家のパートナーシップを通じて、ソリューションを共創し、デジタル・トランスフォーメーションを加速させ、パフォーマンスを最適化する方法をご覧ください。