メッセージキュー

コンピュータ サイエンスでは、メッセージ キューとメールボックスは、通常、プロセス間通信(IPC) または同じプロセス内のスレッド間通信に使用されるソフトウェア エンジニアリング コンポーネントです。これらは 、制御またはコンテンツの受け渡しである メッセージングにキューを使用します。グループ通信システムも同様の機能を提供します。

メッセージ キュー パラダイムは、パブリッシャー/サブスクライバーパターンの兄弟であり、通常は、より大きなメッセージ指向ミドルウェアシステムの一部です。ほとんどのメッセージング システムは、 APIでパブリッシャー/サブスクライバー モデルとメッセージ キュー モデルの両方をサポートしています(例: Java Message Service (JMS))。

競合コンシューマーパターンにより、複数のコンシューマーが同じメッセージキュー上のメッセージを処理できるようになります。^[1]

メッセージキューは、2つ以上のプロセス/スレッド間の非同期通信パターンを実装します。これにより、送信側と受信側が同時にメッセージキューとやり取りする必要がなくなります。キューに配置されたメッセージは、受信者が取得するまで保存されます。メッセージキューには、1つのメッセージで送信できるデータのサイズと、キューに未処理のまま残されるメッセージの数に暗黙的または明示的な制限があります。^[2]

メッセージキューの実装の多くは、オペレーティングシステム内またはアプリケーション内で内部的に機能します。このようなキューはそのシステムのみを目的として存在します。^{[3] [4] [5]}

他の実装では、異なるコンピュータ システム間でメッセージを渡すことができ、複数のアプリケーションと複数のオペレーティング システムを接続する可能性があります。^[6]これらのメッセージ キューイング システムは、通常、システム障害が発生した場合にメッセージが「失われる」ことがないように、回復力機能を 提供します。この種のメッセージ キューイングソフトウェア(メッセージ指向ミドルウェアとも呼ばれる)の商用実装の例には、 IBM MQ (旧称 MQ シリーズ) やOracle Advanced Queuing (AQ) などがあります。Java Message Serviceと呼ばれるJava標準があり、これにはいくつかの独自のソフトウェア実装とフリー ソフトウェア実装があります。

VxWorksやQNXなどのリアルタイム オペレーティング システム(RTOS) では、プロセス間またはスレッド間の主な通信メカニズムとしてメッセージ キューの使用が推奨されています。これにより、メッセージ パッシングと CPU スケジューリングが統合されます。スレッド間通信にメッセージ キュー ベースを推奨した商用 RTOS の初期の例としては、 1980 年代初頭に登場したVRTXやpSOS + などがあります。Erlangプログラミング言語では、プロセスを使用して並行性を実現しています。これらのプロセスは、メッセージ キューを使用して非同期で通信します。

メッセージ キュー ソフトウェアは、独自のもの、オープン ソースのもの、またはその両方の組み合わせのいずれかです。オンプレミスのプライベート サーバーまたは外部のクラウド サーバー (メッセージ キュー サービス) で実行されます。

• 独自のオプションは最も長い歴史があり、IBM MQなどのメッセージ キューイングの誕生当初からの製品や、 Microsoft Message Queuing (MSMQ)などの特定のオペレーティング システムに関連付けられた製品が含まれます。クラウド サービス プロバイダーも、 Amazon Simple Queue Service (SQS)、StormMQ、Solace、IBM MQなどの独自のソリューションを提供しています。
• オープン ソースのメッセージングミドルウェアシステムとしては、Apache ActiveMQ、Apache Kafka、Apache Qpid、Apache RocketMQ、Enduro/X、JBoss Messaging、JORAM、RabbitMQ、Sun Open Message Queue、Tarantoolなどがあります。

ハードウェアベースのメッセージング ミドルウェアベンダーの例としては、 Solace、Apigee、IBM MQなどがあります。

一般的なメッセージ キューイングの実装では、システム管理者がメッセージ キューイング ソフトウェア (キュー マネージャーまたはブローカー)をインストールして構成し、名前付きメッセージ キューを定義します。または、メッセージ キューイング サービスに登録します。

次に、アプリケーションは、キューに配置されたメッセージを「リッスン」するソフトウェア ルーチンを登録します。

2 番目以降のアプリケーションはキューに接続し、そこにメッセージを転送できます。

キュー マネージャー ソフトウェアは、受信側アプリケーションが接続して登録されたソフトウェア ルーチンを呼び出すまでメッセージを保存し、受信側アプリケーションは適切な方法でメッセージを処理します。

メッセージ パッシングの正確なセマンティクスに関しては、次のような多数のオプションが存在します。

• 耐久性 -信頼性の必要性から、よりリソースを消費するソリューションが必要な場合は、メッセージをメモリに保存したり、ディスクに書き込んだり、DBMSにコミットしたりすることもできます。
• セキュリティ ポリシー - どのアプリケーションがこれらのメッセージにアクセスできるか?
• メッセージ消去ポリシー - キューまたはメッセージには「有効期間」がある場合があります。
• メッセージ フィルタリング - 一部のシステムでは、データのフィルタリングをサポートしているため、加入者は事前に指定された関心基準に一致するメッセージのみを表示できます。
• 配信ポリシー – メッセージが少なくとも 1 回配信されることを保証する必要がありますか、それとも 1 回以上配信されないことを保証する必要がありますか?
• ルーティング ポリシー - 多数のキュー サーバーを備えたシステムでは、どのサーバーがメッセージまたはキューのメッセージを受信する必要がありますか?
• バッチ処理ポリシー - メッセージはすぐに配信する必要がありますか? それとも、システムは少し待ってから一度に多くのメッセージを配信しようとしますか?
• キューイング基準 – メッセージが「キューに入れられた」とみなされるのはいつですか? 1 つのキューにメッセージがある場合ですか? または、少なくとも 1 つのリモート キューに転送された場合ですか? あるいは、すべてのキューに転送された場合ですか?
• 受信通知 – パブリッシャーは、一部またはすべてのサブスクライバーがメッセージを受信したことを知る必要がある場合があります。

これらはすべて、トランザクションのセマンティクス、システムの信頼性、およびシステムの効率に大きな影響を与える可能性のある考慮事項です。

歴史的に、メッセージ キューイングでは独自のクローズド プロトコルが使用されており、異機種環境セット内で異なるオペレーティング システムやプログラミング言語が対話する能力が制限されていました。

メッセージ キューイングをより普及させるための初期の試みは、クライアントAPIのJavaのみの抽象化を提供するSun MicrosystemsのJMS仕様でした。これにより、Java 開発者は、 SQLデータベースを使用する開発者と同様の方法で、メッセージ キューイングのプロバイダーを切り替えることができました。しかし、実際には、メッセージ キューイングの手法とシナリオの多様性を考えると、これは必ずしも実用的ではありませんでした。

オープンソースのメッセージ キュー実装で使用される 3 つの標準が登場しました。

1. 高度なメッセージ キュー プロトコル(AMQP) – 機能豊富なメッセージ キュー プロトコル。2014 年 4 月から ISO/IEC 19464 として承認されています。
2. ストリーミングテキスト指向メッセージングプロトコル（STOMP） – シンプルなテキスト指向のメッセージプロトコル
3. MQTT (旧称 MQ Telemetry Transport) – 組み込みデバイス向けの軽量メッセージ キュー プロトコル

これらのプロトコルは、標準化と採用の段階が異なります。最初の 2 つはHTTPと同じレベルで動作し、 MQTT はTCP/IPのレベルで動作します。

一部の独自実装では、 AmazonのSQSなどの一部の実装でメッセージ キューイングを提供するために HTTP も使用します。これは、リクエスト/レスポンス セマンティクスを使用して、同期プロトコルの上に非同期動作 (メッセージ キューイングに必要な動作) を重ねることが常に可能であるためです。ただし、このような実装は、この場合、基盤となるプロトコルによって制約されるため、上記のメッセージ パッシングに必要な完全な忠実度やオプション セットを提供できない可能性があります。

現在広く使用されている通信プロトコルの多くは、同期して動作します。World Wide WebやWeb サービスで使用される HTTP プロトコルは 、ユーザーが Web ページのリクエストを送信し、応答を待つというわかりやすい例です。

ただし、同期動作が適切でないシナリオも存在します。たとえば、AJAX (Asynchronous JavaScript and XML ) を使用すると、テキスト、JSON、または XML メッセージを非同期に送信して、Web ページの一部をより関連性の高い情報で更新できます。Google は、このアプローチを Google サジェストに使用しています。これは、ユーザーが部分的に入力したクエリを Google のサーバーに送信し、ユーザーが入力中に関心を持つ可能性のある完全なクエリのリストを返す検索機能です。このリストは、ユーザーが入力すると非同期で更新されます。

その他の非同期の例としては、イベント通知システムやパブリッシュ/サブスクライブシステムなどがあります。

• アプリケーションは、イベントが発生したことを別のアプリケーションに通知する必要がある場合がありますが、応答を待つ必要はありません。
• パブリッシュ/サブスクライブ システムでは、アプリケーションは任意の数のクライアントが読み取れる情報を「公開」します。

上記の両方の例では、たとえば受信者の 1 人がクラッシュした場合に、情報の送信者が待機しなければならないのは意味がありません。

アプリケーションは、同期または非同期のみである必要はありません。対話型アプリケーションでは、リクエストの特定の部分 (販売リクエストが受け入れられたことを顧客に通知する、在庫を引き出す約束を処理するなど) にすぐに応答する必要がありますが、他の部分 (請求の計算を完了する、中央会計システムにデータを転送する、その他さまざまなサービスを呼び出すなど) は後で実行するためにキューに入れることがあります。

これらすべての状況において、メッセージ キューイングを実行するサブシステム (またはブロードキャスト メッセージング システム) を使用すると、システム全体の動作を改善するのに役立ちます。

UNIXには、一般的なメッセージ キューの実装が 2 つあります。1 つは SYS V API の一部であり、もう 1 つはPOSIXの一部です。

UNIX SYS V は、リンクされたリストの配列をメッセージキューとして保持することでメッセージパッシングを実装しています。各メッセージキューは配列内のインデックスによって識別され、一意の記述子を持ちます。指定されたインデックスには複数の記述子を持つことができます。UNIX はメッセージパッシング機能にアクセスするための標準関数を提供します。^[7]

msgget()

このシステム コールは、キーを引数として受け取り、一致するキーが存在する場合は、そのキーを持つキューの記述子を返します。キューが存在せず、フラグIPC_CREATが設定されている場合は、指定されたキーを持つ新しいメッセージ キューを作成し、その記述子を返します。

msgrcv()

指定されたキュー記述子からメッセージを受信するために使用されます。呼び出し元プロセスはキューの読み取り権限を持っている必要があります。2つのタイプがあります。^[8]

• 受信をブロックすると、要求されたメッセージ タイプが見つからない場合、子プロセスはスリープ状態になります。キューに別のメッセージが投稿されるまでスリープ状態になり、その後起動して再度チェックします。
• 非ブロッキング受信は、失敗したことを通知して、すぐに呼び出し元に戻ります。

msgctl()

所有者などのメッセージ キュー パラメータを変更するために使用されます。最も重要なのは、IPC_RMIDフラグを渡すことによってメッセージ キューを削除するために使用されることです。メッセージ キューは、作成者、所有者、またはスーパーユーザーのみが削除できます。

POSIX.1-2001 メッセージ キュー API は、2 つの UNIX メッセージ キュー API のうち、後者です。SYS V API とは異なりますが、同様の機能を提供します。UNIX のマニュアル ページには、mq_overview(7)POSIX メッセージ キューの概要が記載されています。

グラフィカルユーザーインターフェース（GUI）は、マウスクリック、キーボードイベント、その他のユーザー入力などのグラフィカル入力アクションをアプリケーションプログラムに渡すために、イベントキューまたは入力キューとも呼ばれるメッセージキューを使用します。^[9]ウィンドウシステムは、タイマーティックや他のスレッドから送信されたメッセージなど、ユーザーイベントやその他のイベントを示すメッセージをメッセージキューに配置します。GUIアプリケーションは、イベントループでと呼ばれるルーチンまたは同様のルーチンを呼び出すことによって、これらのイベントを1つずつ削除し、そのイベントを処理する適切なアプリケーションルーチンを呼び出します。^[10]getNextEvent()