第 2 章   MQ メッセージングシステム


この章では、MQ メッセージングシステムについて説明します。図 2-1 に示すシステムの主要部分に重点を置き、確実なメッセージ配信を実現するための連動方法について説明します。

図 2-1    MQ システムアーキテクチャ

図 2-1 に示す MQ メッセージングシステムの主要部分は、次のとおりです。

• MQ メッセージサーバ

• MQ クライアントランタイム

• MQ 管理対象オブジェクト

• MQ Administration

最初の 3 項目については、次の節で説明します。最後の項目については、第 3 章「MQ の管理」で説明します。

MQ メッセージサーバ

---

この節では、図 2-1 に示される MQ メッセージサーバのさまざまな部分について説明します。次の項目が含まれます。

ブローカ   ブローカには、MQ メッセージングシステムの配信サービスが用意されています。メッセージ配信は、コネクションサービス、メッセージのルーティングと配信、持続性、セキュリティ、およびログ記録を処理するさまざまなサポートコンポーネントに依存します (詳細は、「ブローカ」を参照)。メッセージサーバでは、1 つまたは複数のブローカを使用できます (「複数ブローカの設定 (クラスタ)」を参照)。

物理的な送信先   メッセージは 2 段階のプロセスで配信されます。まず、プロデューシングクライアントから、ブローカが管理する物理的な送信先に配信されます。次に、送信先から1 つまたは複数のコンシューミングクライアントに配信されます。物理的な送信先は、ブローカの物理的なメモリまたは持続ストレージ、あるいはその両方の場所を表します (詳細は、「物理的な送信先」を参照)。

ブローカ

プロデューシングクライアントから送信先へ、さらに送信先から 1 つまたは複数のコンシューミングクライアントへ配信される MQ メッセージングシステムのメッセージ配信は、ブローカ (または、並行して動作するブローカのクラスタ) によって行われます。メッセージ配信を実行するには、ブローカはクライアントとの通信チャネルの設定、認証と承認、適切なメッセージルーティング、信頼性の高い配信の保証、およびシステムパフォーマンスを監視するためのデータの提供を行う必要があります。

この複雑な機能の組み合わせを実行するために、ブローカはさまざまなコンポーネントを使用します。各コンポーネントには、配信プロセスにおける特定のロールが割り当てられています。負荷状態やアプリケーションの複雑さなどに応じて、これらの内部コンポーネントを設定してブローカのパフォーマンスを最適化することができます。図 2-2 にブローカの主要なコンポーネントを示し、表 2-1 でそれらについて簡単に説明します。

図 2-2    ブローカのコンポーネント

表 2-1    ブローカの主要なコンポーネントと機能 

コンポーネント	説明 / 機能
コネクションサービス	ブローカとクライアント間の物理的な接続を管理し、送受信メッセージの転送を行う
メッセージルーター	メッセージのルーティングおよび配信を管理する。JMS メッセージと、JMS メッセージの配信をサポートするために MQ メッセージングシステムが使用するコントロールメッセージを含む
持続マネージャ	システム障害が発生しても、JMS メッセージが配信されるように、持続ストレージへのデータの書き込みを管理する
セキュリティマネージャ	ブローカへのコネクションを要求するユーザに認証サービスを提供し、認証されたユーザに承認サービス (アクセス制御) を提供する
ロガー	管理者がブローカを監視および管理できるように、監視情報や診断情報をログファイル、またはコンソールに出力する

次の節では、別のブローカのコンポーネントが実行する機能と、コンポーネントの動作に影響を及ぼす設定可能なプロパティについて、詳しく説明します。

コネクションサービス

MQ ブローカは、JMS クライアントと MQ 管理クライアントの両方の通信をサポートしています (「MQ 管理ツール」を参照)。各サービスは、サービスタイプとプロトコルタイプで指定されます。

サービスタイプ   JMS メッセージ配信 (NORMAL) サービス、または MQ 管理 (ADMIN) サービスのどちらを提供するのかを指定する

プロトコルタイプ   サービスをサポートする基礎となるトランスポートプロトコルレイヤを指定する

MQ ブローカで現在使用できるコネクションサービスは、表 2-2 に示されています。

表 2-2    ブローカでサポートされているコネクションサービス 

サービス名	サービスタイプ	プロトコルタイプ
jms	NORMAL (JMS メッセージ配信)	tcp
ssljms	NORMAL (JMS メッセージ配信)	tls (SSL ベースセキュリティ)
httpjms	NORMAL (JMS メッセージ配信)	http
httpsjms	NORMAL (JMS メッセージ配信)	https (SSL ベースセキュリティ)
admin	ADMIN	tcp
ssladmin	ADMIN	tls (SSL ベースセキュリティ)

ブローカを設定して、これらのコネクションサービスの一部、またはすべてを実行することができます。図 2-3 に示すように、各サービスはスレッドプールマネージャを保持し、共通のポートマッパーサービスにサービス自体を登録します。

図 2-3    コネクションサービスのサポート

各コネクションサービスは、ブローカのホスト名とポート番号で指定した特定のポートで使用できます。ポートは、静的または動的に割り当てることが可能です。MQ には、異なるコネクションサービスに動的に割り当てられたポートをマップするポートマッパーが用意されています。ポートマッパー自体は、標準のポート番号 7676 に常駐します。クライアントがブローカとコネクションをする場合、最初に、必要なコネクションサービスのポート番号を要求するポートマッパーに接続します。

jms、ssljms、admin、および ssladmin のコネクションサービスを設定する場合、これらのコネクションサービスに、静的なポート番号を割り当てることも可能ですが、これはお勧めしません。httpjms サービスと httpsjms サービスは、付録 B 「HTTP/HTTPS サポート」の表 B-1 と表 B-3 にそれぞれ示すプロパティを使用して設定します。

各コネクションサービスは、複数のコネクションをサポートするマルチスレッドです。これらのコネクションに必要なスレッドは、スレッドプールマネージャのコンポーネントが管理するスレッドプールに保存されます。スレッドプールマネージャを設定して、スレッドプールに保持されるスレッドの最小数と最大数を指定することができます。コネクションでスレッドが必要になると、スレッドプールにスレッドが追加されます。スレッドの最小数より少なくなると、システムは最小数のしきい値になるまで、スレッドをシャットダウンして、スレッドを解放します。これによってメモリのリソースが節約されます。新しいスレッドを頻繁に作成する必要がないように、最小数に十分な数を指定します。コネクションの負荷が重い場合、スレッドの数を最大数まで増やすことができます。それでも足らない場合、スレッドが利用できるようになるまで、コネクションは待機します。

スレッドプール内のスレッドは、1 つのコネクションだけに割り当てる (専用モデル) か、必要に応じて、複数のコネクションに割り当てる (共有モデル) ことができます。

専用モデル   専用モデルの場合、ブローカへのコネクションごとに、受信メッセージを処理するスレッドと、送信メッセージを処理するスレッドの 2 つのスレッドが必要になります。このため、コネクションの数は、スレッドプール内の最大スレッド数の半分に制限されますが、高いパフォーマンスを得られます。

共有モデル   共有スレッドモデルの場合、メッセージを送受信する場合にだけ、スレッドにコネクションを割り当てます。コネクションがスレッドを共有するので、コネクションサービス (および、ブローカ) がサポートできるコネクションの数は増えますが、パフォーマンスのオーバーヘッドが若干生じます。スレッドプールマネージャは、一連のディストリビュータスレッドを使用してコネクションのアクティビティを監視し、必要に応じてスレッドにコネクションを割り当てます。このディストリビュータスレッドが監視するコネクションの数を制限することによって、パフォーマンスを改善できます。

各コネクションサービスは、特定の認証および承認 (アクセス制御) 機能をサポートします (「セキュリティマネージャ」を参照)。

コネクションサービスに関する設定可能なプロパティを表 2-3 に示します。各プロパティの設定方法については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-3    コネクションサービスのプロパティ 

プロパティ名	説明
imq.service.activelist	ブローカの起動時にアクティブになる、コンマで区切られた、名前別のコネクションサービスのリスト。サポートされているサービスは、jms、ssljms、httpjms、httpsjms、admin、ssladmin 。デフォルトは jms、admin
imq.service_name. min_threads	指定したコネクションサービスが使用するスレッドプールに初めに保持されるスレッドの数を指定する。デフォルトは、コネクションサービスによって異なる (表 5-1 を参照)
imq.service_name. max_threads	指定したコネクションサービスが使用するスレッドプールに保持されるスレッドの最大数を指定する。新しいスレッドは、それ以上追加されなくなる。この数は、0 より大きく、min_threads の値よりも大きくする必要がある。デフォルトは、コネクションサービスによって異なる (表 5-1 を参照)
imq.service_name. threadpool_model	指定したコネクションサービスに対して、スレッドをコネクション専用 (dedicated) にするのか、あるいは必要に応じてコネクションで共有 (shared) するのかどちらかを指定する。共有モデル (スレッドプール管理) の場合、ブローカがサポートするコネクションの数が増えるが、jms コネクションサービスと admin コネクションサービスでしか実装されない。デフォルトは、コネクションサービスによって異なる (表 5-1 を参照)
imq.shared. connectionMonitor_limit	共有スレッドプールモデルの場合のみ、ディストリビュータスレッドで監視できるコネクションの最大数を指定する。(すべてのコネクションを監視するのに十分なディストリビュータスレッドをシステムが割り当てる。) この値が小さいほど、システムはより早くスレッドにアクティブコネクションを割り当てることができる。値を 0 に設定した場合、無制限になる。デフォルトは、オペレーティングシステムによって異なる (表 5-1 を参照)
imq.portmapper.port	ブローカのプライマリポート。ポートマッパーが常駐するポート。ホストで複数のブローカインスタンスを実行する場合、各ブローカインスタンスに、固有のポートマッパーポートを割り当てる必要がある。デフォルトは 7676
imq.service_name. protocol_type1.port	jms、ssljms、admin、および ssladmin のサービスの場合のみ、指定したコネクションサービスのポート番号を指定する。デフォルトは 0 (ポートは、ポートマッパーによって動的に割り当てられる) httpjms コネクションサービスと httpsjms コネクションサービスを設定する場合、付録 B 「HTTP/HTTPS サポート」を参照
imq.service_name. protocol_type*.hostname	jms、ssljms、admin、および ssladmin のサービスの場合のみ、複数のホストを使用できる際 (1 台のコンピュータに、複数のネットワークインタフェースカードがある場合など) に、指定したコネクションサービスが接続するホスト (ホスト名、または IP アドレス) を指定する。デフォルトは null (任意のホスト)

1 protocol_type は 表 2-2 に記載されています。

メッセージルーター

サポートされているコネクションサービスを使用して、クライアントとブローカ間でコネクションが確立されると、メッセージのルーティングおよび配信が処理できます。

基本的な配信メカニズム
通常、ブローカで処理されるメッセージは、2 つのカテゴリに分類されます。1 つ目は、プロデューサクライアントによって送信されるコンシューマクライアント向けの JMS メッセージ、すなわちペイロードメッセージです。2 つ目は、JMS メッセージの配信をサポートするために、クライアント間で送受信される多数のコントロールメッセージです。

受信メッセージが JMS メッセージの場合、送信先のタイプ (キュー、またはトピック) に基づいて、ブローカはメッセージをコンシューマクライアントにルートします。

• 送信先がトピックの場合、JMS メッセージは、すぐにトピックのすべてのアクティブサブスクライバにルートされます。ルート先がアクティブになっていない永続サブスクライバの場合、サブスクライバがアクティブになるまで、メッセージルーターはメッセージを保持し、後でそのサブスクライバにメッセージを配信します。

• 送信先がキューの場合、JMS メッセージは、対応するキューに配置され、メッセージがキューの先頭に来たときに、適切なコンシューマに配信されます。メッセージがキューの先頭に来る順番は、メッセージの到着順序と優先度によって変わります。

メッセージルーターは、意図したすべてのコンシューマにメッセージを配信すると、メモリからそのメッセージを消去します。また、メッセージが持続的 (「信頼性のあるメッセージング」を参照) である場合、ブローカの持続データストアから、そのメッセージを削除します。

信頼性の高い配信 : 通知およびトランザクション
信頼性の高い配信 (「信頼性のあるメッセージング」を参照) の要件を追加すると、前述した配信メカニズムはさらに複雑になります。信頼性の高い配信では、ブローカとのメッセージの配信が正常に終了することと、メッセージが実際に配信される前に、ブローカがメッセージや配信情報を失うことがないようにする 2 つの局面があります。

ブローカとのメッセージの配信を正常に行うために、MQ は通知と呼ばれる多数のコントロールメッセージを使用します。

たとえば、プロデューサが送信先に JMS メッセージ (ペイロードメッセージ) を送信した場合、ブローカは JMS メッセージを受信したことを示すコントロールメッセージ (ブローカの通知) を送り返します。実際には、プロデューサが JMS メッセージを持続的として指定している場合に限り、MQ はこれを実行します。プロデューシングクライアントは、送信先への配信を保証するために、ブローカの通知を使用します (「メッセージのプロデュース」を参照)。

同様に、ブローカが JMS メッセージをコンシューマに配信した場合、コンシューミングクライアントは、メッセージを受信および処理したことを示す通知を送り返します。クライアントは、セッションオブジェクトの作成時に、これらの通知を自動的に、またはどのくらいの頻度で送信するのかを指定します。原則として、メッセージルーターは、メッセージを配信した各メッセージコンシューマ (トピックの複数のサブスクライバなど) から通知を受信していない場合、メモリから JMS メッセージを削除しません。

トピックのサブスクライバが永続的な場合、メッセージルーターは、各 JMS メッセージをその送信先で保持し、各永続サブスクライバがアクティブなコンシューマになると、そのメッセージを配信します。メッセージルーターは、クライアントの通知を受信するたびにそれを記録し、すべての通知を受信すると、初めて JMS メッセージを削除します (ただし、この時点で JMS メッセージの有効期限が切れている場合は除く)。

さらに、メッセージルーターは、ブローカの通知をクライアントに送り返して、クライアントの通知を受信したことを確認します。コンシューミングクライアントは、ブローカの通知を使用して、ブローカが JMS メッセージを何度も配信しないようにします (「メッセージのコンシューム」を参照)。何らかの理由で、ブローカがクライアントの通知を受信し損なうと、JMS メッセージが繰り返し配信される可能性があります。

ブローカがクライアントの通知を受信しないで、JMS メッセージを再び配信する場合、メッセージに再配信フラグが付けられます。一般的に、ブローカがクライアントの通知を受信する前にクライアントのコネクションが閉じられて、新しいコネクションが開かれると、ブローカは JMS メッセージを再配信します。たとえば、メッセージが通知される前に、キューのメッセージコンシューマがオフラインになって、別のコンシューマがキューに登録された場合、ブローカは通知されていないメッセージを新しいコンシューマに再配信します。

前述のクライアントとブローカの通知プロセスは、トランザクションに分類される JMS メッセージの配信にも適用されます。この場合、クライアントとブローカの通知は、各 JMS メッセージレベルだけでなく、トランザクションレベルでも動作します。トランザクションがコミットされると、ブローカの通知が自動的に送信されます。

ブローカはトランザクションを追跡し、トランザクションがコミットされるか、あるいは障害が発生した場合にロールバックされるようにします。このトランザクション管理は、大規模な分散トランザクションの一部であるローカルトランザクションもサポートします (「分散トランザクション」を参照)。ブローカは、これらのトランザクションがコミットされるまで、トランザクションの状態を追跡します。デフォルトでは、ブローカは起動時に、コミットされていないすべてのトランザクションを調べて、PREPARED 状態以外のトランザクションをすべてロールバックします。

信頼性の高い配信 : 持続
信頼性の高い配信のもう 1 つの局面は、メッセージが実際に配信されるまで、ブローカがメッセージ、または配信情報を保持することです。通常、メッセージは配信されたり、有効期限が切れたりするまで、メモリ内に保持されます。ただし、ブローカで障害が発生すると、これらのメッセージは失われる可能性があります。

プロデューサクライアントは、メッセージを持続に指定することができます。そのように指定すると、メッセージルーターは持続マネージャ (「持続マネージャ」を参照) にメッセージを渡します。持続マネージャはそのメッセージをデータベースまたはファイルシステムに格納するので、ブローカで障害が発生しても、メッセージを復元することができます。

システムリソースの管理
ブローカのパフォーマンスは、使用できるシステムリソースとメモリなどのリソースの使用効率によって異なります。たとえば、メッセージルーターには、システムのメモリを監視するメモリ管理方式が用意されています。メモリリソースが不足すると、メモリを回復するメカニズム、つまり受信メッセージのフローを遅らせるメカニズムがアクティブになります。

メモリ管理メカニズムは、green (使用可能なメモリが十分にある)、yellow (ブローカのメモリが減っている)、orange (ブローカのメモリが不十分である)、red (ブローカのメモリが不足している) といったメモリリソースの状態によって異なります。メモリリソースの状態が、green から yellow や orange を経て red になると、ブローカはメモリを回復するための重大なアクション、つまり、メッセージプロデューサを徐々に減らし、最終的にブローカへのメッセージのフローを停止するアクションをとります。

プロパティを使用して、ブローカのメモリ管理機能を設定できます。プロパティでは、メモリ内のメッセージの総数やサイズを制限したり、メモリリソースの状態を更新する頻度を調整できます。

プロパティを表 2-4 に示します。これらのプロパティの設定については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-4    メッセージルーターのプロパティ 

プロパティ名	説明
imq.message.expiration. interval	有効期限が切れたメッセージを回復させる頻度を秒単位で指定する。デフォルトは 60
imq.system.max_count	メモリ内とディスク内の両方 (スワッピングのため) のメッセージの最大数を指定する。この値を超えるメッセージは拒否される。値を 0 に設定した場合、無制限になる。デフォルトは 0
imq.system.max_size	メモリ内とディスク内の両方 (スワッピングのため) のメッセージの最大合計サイズ (バイト単位で、K バイトまたは M バイト) を指定する。この値を超えるメッセージは拒否される。値を 0 に設定した場合、無制限になる。デフォルトは 0
imq.message.max_size	メッセージの本体の最大許容サイズ (バイト単位で、K バイトまたは M バイト) を指定する。このサイズを超えるメッセージは拒否される。値を 0 に設定した場合、無制限になる。デフォルトは 70m (M バイト)
imq.resource_state. threshold	指定したメモリリソースの状態で、そのメモリリソースがトリガーされるメモリの利用率を指定する。リソースの状態を表す値は、green、yellow、orange、および red 。デフォルトは、それぞれ 0、60、75、90 になる
imq.redelivered. optimization	再配信フラグを設定して、メッセージルーターがパフォーマンスを最適化するかどうか (true/false) を指定する。true の場合はメッセージが再配信されるたびに実行 、false の場合は論理的に必要がある場合にのみ実行。デフォルトは true
imq.transaction. autorollback	PREPARED 状態の分散トランザクションをブローカの起動時に自動的にロールバックするかどうかを指定する (true/false)。false の場合は、imqcmd を使用して、手動でトランザクションをコミット、またはロールバックする必要がある (「トランザクションの管理」を参照)。デフォルトは false

持続マネージャ

障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。この場合、ブローカは、すべての持続メッセージを重要な転送情報および配信情報とともにデータストアに保存する必要があります。持続マネージャのコンポーネントは、この情報の書き込みおよび検索を管理します。

障害が発生したブローカを復元する場合、配信されていないメッセージを復元するだけでは不十分です。ブローカは、次のタスクも実行する必要があります。

• 送信先の再作成

• 各トピックの永続サブスクリプションのリストの復元

• 各メッセージの通知リストの復元

• コミットされたすべてのトランザクションの状態の復元

持続マネージャは、このすべての状態情報の格納および検索を管理します。

ブローカが再起動すると、送信先と永続サブスクリプションの再作成、持続メッセージの復元、すべてのトランザクションの状態の復元、および配信されていないメッセージのルーティングテーブルの再作成が行われます。この後に、メッセージの配信を再開します。

MQ は、組み込み持続モジュールとプラグイン持続モジュールがサポートしています (図 2-4を参照)。組み込み持続は、単層ファイルのデータストアに基づいています。プラグイン持続は、JDBC インタフェースを使用し、JDBC 互換のデータストアを必要とします。通常、組み込み持続の方が、プラグイン持続より処理速度が速くなりますが、JDBC 互換のデータベースシステムを使用する冗長性および管理機能を好むユーザもいます。

図 2-4    持続マネージャのサポート

組み込み持続
デフォルトの MQ 持続ストレージソリューションは、単層ファイルストアです。この方法では、メッセージ、送信先、永続サブスクリプション、トランザクションなどの持続データを保存するために、個別のファイルを使用します。

単層ファイルのデータストアは、次の場所にあります。

IMQ_VARHOME/instances/brokerName/filestore/
(Solaris では、/var/imq/instances/brokerName/filestore/)

brokerName には、ブローカインスタンスを識別する名前が入ります。

ファイルベースのデータストアでは、持続メッセージは対応するファイルに 1 つずつ保存されます。ただし、送信先、永続サブスクリプション、およびトランザクションは、1 つのファイルにすべての送信先、別のファイルにすべての永続サブスクリプションといった具合に、それぞれのファイルにすべてが保存されます。

メッセージをデータストアに追加したり、データストアから削除したりするたびに、ファイルの作成または削除されると、ファイルシステムに負荷がかかります。このため、MQ 実装では、不必要になったファイルを削除する代わりに、再利用が可能な空きファイルのプールに追加して、これらのメッセージファイルを再利用します。このファイルプールのサイズは、設定することができます。また、単に再利用のためのタグを付ける (切り捨てられない) のに対して、ファイルプール内で削除する (サイズを 0 にする) 空きファイルの割合を指定することもできます。削除するファイルの割合が大きいほど、ディスク容量は小さくなりますが、ファイルプールを保持するためのオーバーヘッドが増えます。シャットダウン時に、タグの付いたファイルを削除するかどうかを指定することもできます。ファイルが削除されると、ファイルが使用するディスク容量が小さくなりますが、ブローカはシャットダウンに時間がかかるようになります。

単層ファイルストアにメッセージを格納する速度は、データストアで使用できるファイル記述子の数に影響されます。記述子の数が多いと、システムはより多くの持続メッセージをより迅速に処理することができます。ファイル記述子の増加については、『MQ リリースノート』の「技術的な注意点」の節を参照してください。

送信先ファイルストアの場合、送信先が追加されるたびに、ファイルのサイズを大きくするのではなく、固定サイズのファイルに送信先を追加する方がより効率的です。このため、最終的に送信先ファイルに保存されると思われる送信先の数に応じて、送信先ファイルのサイズを設定することでパフォーマンスを向上できます (各送信先は約 500 バイトをコンシュームします)。

データストアでは、機密情報を保持するメッセージが含まれるため、承認されていないアクセスから、brokerName/filestore/ ディレクトリを保護することをお勧めします。手順については、『MQ リリースノート』の「技術的な注意点」の節を参照してください。

プラグイン持続
JDBC ドライバを介してアクセスが可能な任意のデータストアにアクセスするように、ブローカを設定することができます。この作業には、さまざまな JDBC 関連のブローカ設定プロパティの設定、適切なスキーマでデータストアを作成する Database Manager ユーティリティ (imqdbmgr) の使用が含まれます。手順および関連する設定プロパティについては、付録 A 「プラグイン持続の設定」で説明します。

持続関連の設定プロパティを、表 2-5 に示します。これらのプロパティの設定については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-5    持続のプロパティ 

プロパティ名	説明
imq.persist.store	組み込みのファイルベース (file) の持続、またはプラグインの JDBC 互換 (jdbc) の持続のどちらをブローカが使用するのかを指定する。デフォルトは file
imq.persist.file. destination.file.size	組み込みのファイルベースの持続の場合、送信先を格納するファイルの初期サイズを指定する。デフォルトは 1m (M バイト)
imq.persist.file.message. filepool.limit	組み込みのファイルベースの持続の場合、ファイルプールで再利用できる空きファイルの最大数を指定する。この値が大きいほど、ブローカが持続データを処理する速度が速くなる。この値を超える空きファイルは削除される。この制限を越えると、ブローカは必要に応じて追加ファイルを作成および削除する。デフォルトは 10000
imq.persist.file.message. filepool.cleanratio	組み込みのファイルベースの持続の場合、クリーン状態 (サイズを 0 にする) で保持されるファイルプールの空きファイルの割合を指定する。この値が大きいほど、作業中にファイルを削除するのに必要なオーバーヘッドが増えるが、ファイルプールに必要なディスク容量は小さくなる。デフォルトは 0
imq.persist.file.message. cleanup	組み込みのファイルベースの持続の場合、ブローカのシャットダウン時に、ファイルストア内の空きファイルを削除するかどうかを指定する。値を false に設定すると、ブローカのシャットダウンが迅速化するが、ファイルストアのためのディスク容量がさらに必要になる。デフォルトは false
imq.persist.file.message. fdpool.limit	組み込みのファイルベースの持続の場合、開いたままにするデータファイルの最大数 (ファイル記述子プールのサイズ) を指定する。値が大きくなると、持続操作のパフォーマンスは向上するが、クライアントコネクションの作成のように、ファイル記述子を必要とするブローカ操作に負荷がかかる。デフォルトは Solaris および Linux の場合 25、Windows の場合 1024
imq.persist.file.sync. enabled	持続操作でメモリ内の状態を物理的なストレージと同期化させるかどうかを指定する。true の場合、システムクラッシュによるデータ損失は回避されるが、持続操作のパフォーマンスに負荷がかかる。デフォルトは false

セキュリティマネージャ

MQ では、認証および承認 (アクセス制御) 機能が用意されており、暗号化機能もサポートされています。

認証機能と承認機能は、ファイル、ディレクトリ、またはメッセージングシステムのユーザに関する情報 (ユーザ名、パスワード、およびグループのメンバーシップ) が保存されるデータベースなどのユーザリポジトリによって異なります (図 2-5 を参照)。ユーザ名とパスワードはブローカへのコネクションが要求されたときに、ユーザを認証するために使用されます。ユーザ名とグループのメンバーシップは、送信先のプロデューシングメッセージ、またはコンシューミングメッセージなどの操作を承認するために、アクセス制御ファイルと一緒に使用されます。

MQ の管理者は、MQ で提供されるユーザリポジトリ (「単層型ファイルユーザリポジトリを使用する」を参照) を生成するか、あるいは既存の LDAP ユーザリポジトリをセキュリティマネージャのコンポーネントに接続します。

認証
MQ のセキュリティは、パスワードベースの認証がサポートしています。クライアントがブローカへのコネクションを要求する場合、ユーザ名とパスワードを提示する必要があります。セキュリティマネージャは、クライアントから提示されたユーザ名とパスワードをユーザリポジトリ内に格納されているものと比較します。クライアントからブローカにパスワードが送信される場合、パスワードは、Base-64 暗号化か、メッセージダイジェストの MD5 のどちらかを使用して暗号化されます。セキュリティ保護された送信については、「暗号化」を参照してください。各コネクションサービスで使用する暗号化のタイプを 1 つずつ設定するか、あるいはブローカ単位で暗号化を設定することができます。

承認
クライアントアプリケーションのユーザが認証されると、ユーザはさまざまな MQ 関連のアクティビティを実行することを承認されます。セキュリティマネージャは、ユーザベースとグループベースの両方のアクセス制御をサポートしています。ユーザ名、またはユーザリポジトリでユーザに割り当てられているグループに応じて、ユーザは特定の MQ 操作を実行するためのアクセス権を付与されます。これらのアクセス制御は、アクセス制御プロパティファイルで指定します (図 2-5 を参照)。

ユーザがある操作を実行しようとすると、セキュリティマネージャが、ユーザリポジトリ内のユーザ名とグループのメンバーシップを、アクセス制御プロパティファイル内のユーザ名とグループのメンバーシップと照らし合わせます。アクセス制御プロパティには、操作に対するユーザのアクセス権が指定されています。アクセス制御プロパティファイルでは、次の操作に対するアクセス権を指定します。

• ブローカとのコネクションの確立

• 送信先へのアクセス : 特定の送信先、またはすべての送信先に対してのコンシューマ、プロデューサ、またはキューブラウザの作成

• 送信先の自動作成

図 2-5    セキュリティマネージャのサポート

MQ 3.0 の場合、デフォルトのアクセス制御プロパティファイルは、1 つのグループ admin だけを明示的に参照します (「グループ」を参照)。admin グループのユーザには、admin サービスコネクションのアクセス権が付与されます。admin サービスは、送信先の作成、ブローカの監視と制御などの管理機能を実行できます。その他のグループに定義されたユーザは、デフォルトでは admin サービスコネクションにアクセスできません。

MQ の管理者は、グループを定義し、ユーザリポジトリ内のそれらのグループとユーザを関連付けることができます (ただし、グループは単層ファイルのユーザリポジトリで完全にはサポートされません)。そうすると、アクセス制御プロパティファイルを編集してユーザ別およびグループ別に目的 (メッセージのプロデュースとコンシューム、またはキューの送信先のメッセージの参照) に応じて、送信先へのアクセスを指定できます。特定のユーザ、またはグループだけがアクセスできる個別の送信先、またはすべての送信先を作成できます。

さらに、ブローカを設定して、送信先の自動作成 (「自動作成 (および管理者によって作成) された送信先」を参照) を許可する場合、アクセス制御プロパティファイルを編集して、ブローカが送信先を自動作成できるユーザを制御することができます。

暗号化
クライアントとブローカ間で送信されるメッセージを暗号化するには、SSL (Secure Socket Layer) 標準に基づいたコネクションサービスを使用する必要があります。SSL は、SSL 対応のブローカとクライアント間で暗号化されたコネクションを確立して、コネクションレベルのセキュリティを提供します。

MQ の SSL ベースのコネクションサービスを使用するには、Key Tool ユーティリティ (imqkeytool) を使用して、非公開キーと公開キーのペアを生成します。このユーティリティは、自己署名付き証明書に公開キーを組み込んで、それを MQ のキーストアに配置します。MQ のキーストア自体は、パスワードによって保護されているため、起動時にキーストアのパスワードを入力して、ロックを解除する必要があります。詳細は、「暗号化 : SSL サービスの操作」を参照してください。

キーストアのロックが解除されると、ブローカは、コネクションを要求しているクライアントに証明書を渡すことができます。証明書を受け取ると、クライアントはその証明書を使用して暗号化されたブローカへのコネクションを設定します。

認証、承認、暗号化、およびその他のセキュリティ保護された通信に関する設定可能なプロパティを表 2-6 に示します。各プロパティの設定方法については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-6    セキュリティのプロパティ 

プロパティ名	説明
imq.authentication.type	パスワードを Base-64 コーディング (basic)、または MD5 ダイジェスト (digest) のどちらで送信するのかを指定する。ブローカでサポートされるすべてのコネクションサービスに対して、符号化を設定する。デフォルトは digest
imq.service_name. authentication.type	パスワードを Base-64 コーディング (basic)、または MD5 ダイジェスト (digest) のどちらで送信するのかを指定する。指定したコネクションサービスの符号化を設定して、ブローカ全体の設定をオーバーライドする。デフォルトは、imq.authentication.type に設定される値から継承される
imq.authentication. basic.user_repository	認証に使用される (Base-64 コーディング用の) ユーザリポジトリのタイプとして、ファイルベース (file)、または LDAP (ldap) のどちらかを指定する。その他の LDAP のプロパティについては、表 8-5 を参照。デフォルトは file
imq.authentication. client.response.timeout	ブローカからの認証要求に対するクライアントの応答をシステムが待機する時間を秒単位で指定する。デフォルトは 180 (秒)
imq.accesscontrol. enabled	ブローカでサポートされるすべてのコネクションサービスに対して、アクセス制御を設定する (true/false)。アクセス制御プロパティファイルに指定されているように、認証されたユーザが、コネクションサービスを使用するためのアクセス権、あるいは特定の送信先に対して特定の MQ 操作を実行するためのアクセス権を保持していることをシステムでチェックするかどうかを指定する。デフォルトは  true
imq.service_name. accesscontrol.enabled	指定したコネクションサービスに対して、アクセス制御を設定し (true/false)、ブローカ全体の設定をオーバーライドする。アクセス制御プロパティファイルに指定されているように、認証されたユーザが、指定したコネクションサービスを使用するためのアクセス権、あるいは特定の送信先に対して特定の MQ 操作を実行するためのアクセス権を保持していることをシステムでチェックするかどうかを指定する。 デフォルトは、imq.accesscontrol.enabled プロパティの値を継承する
imq.accesscontrol.file. filename	ブローカでサポートされるすべてのコネクションサービスに対して、アクセス制御プロパティファイルの名前を指定する。ファイル名には、IMQ_HOME/etc ディレクトリの相対ファイルパスを指定する。デフォルトは  accesscontrol.properties
imq.service_name. accesscontrol.file. filename	指定したコネクションサービスに対して、アクセス制御プロパティファイルの名前を指定する。ファイル名には、IMQ_HOME/etc ディレクトリの相対ファイルパスを指定する。デフォルトは、imq.accesscontrol.file.filename の値を継承する
imq.passfile.enabled	セキュリティ保護される通信用の (SSL、LDAP、JDBC の) ユーザパスワードをパスファイルで指定するどうか (true/false) を指定する。デフォルトは false
imq.passfile.dirpath	パスファイルが配置されているディレクトリへのパスを指定する。デフォルトは、IMQ_HOME/etc (Solaris では /etc/imq)
imq.passfile.name	パスファイル名を指定する。デフォルトは passfile
imq.keystore.property_name	SSL ベースのサービスの場合、SSL キーストアに関するセキュリティのプロパティを指定する。表 8-8 を参照

ロガー

ブローカには、ブローカの動作を監視および診断するためのさまざまなコンポーネントが用意されています。これらのコンポーネントの中には、データ (ブローカコード、メトリックスジェネレータ、およびデバッガ) を生成するコンポーネントや、多数の出力チャネル (ログファイル、コンソール、および Solaris syslog) を介して、情報を書き出すロガーコンポーネントがあります。このスキーマを、図 2-6 に示します。

図 2-6    ロギングスキーマ

メトリックスデータの生成をオン、またはオフにすることも、メトリックスレポートを生成する頻度を指定することもできます。

もっとも深刻で重要な情報 (エラー) から、重要度の低い情報 (メトリックスデータ) まで、ロガーのレベルを指定することもできます。情報のカテゴリを重要度の高い順に、表 2-7 に示します。

表 2-7    ロギングのカテゴリ 

カテゴリ	説明
ERROR	システム障害が生じる可能性のある問題点を示すメッセージ
WARNING	システム障害が生じる可能性はないが、留意すべき警告
INFO	メトリックスおよびその他の情報メッセージの報告

ロガーのレベルを設定するには、これらのカテゴリのどれかを指定します。ロガーは、指定されたカテゴリとそれより上のレベルのカテゴリのデータをすべて出力します。たとえば、ロギングに WARNING レベルを指定すると、ロガーは、WARNING 情報と ERROR 情報の両方を出力します。

ロガーは、標準出力 (コンソール)、ログファイル、syslog デーモンプロセス (Solaris プラットフォームの場合) などのさまざまな出力チャネルに、データを書き出すことができます。

各出力チャネルに対して、ロガーに設定されているカテゴリのうちどれを書き込むかを指定できます。たとえば、ロガーのレベルが ERROR の場合、エラーと警告だけをコンソールに出力し、情報 (メトリックスデータ) だけをログファイルに書き込むように指定することができます。Solaris syslog の設定および使用方法については、syslog(1M)、syslog.conf(4)、および syslog(3C) の Man ページを参照してください。

ログファイルに出力する場合、ログファイルを閉じて、新しいファイルに出力がロールオーバーされる時点を指定できます。ログファイルが指定したサイズや有効期間に達すると、そのファイルは保存されて、新しいログファイルが作成されます。ログファイルは、次の場所に保存されます。

IMQ_VARHOME/instances/brokerName/log/

新しいロールオーバーログファイルが作成されると、もっとも新しい 9 個のログファイルのアーカイブが保持されます。ログファイルは、次のように順番に名前が付けられるテキストファイルです。

log.txt
log_1.txt
log_2.txt
...
log_9.txt

log.txt がもっとも新しいファイルで、数字が大きくなるほど古いファイルになります。

ブローカによる情報の生成およびロギングを設定する設定可能なプロパティを表 2-8 に示します。各プロパティの設定方法については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-8    ロガーのプロパティ 

プロパティ名	説明
imq.metrics.enabled	メトリックス情報を収集するかどうかを指定する (true/false)。デフォルトは true
imq.metrics.interval	メトリックス情報が報告される間隔を秒単位で指定する。値を 0 に設定した場合は、情報が報告されない。デフォルトは 0
imq.log.level	ロガーのレベル (出力チャネルに書き込むことができる出力のカテゴリ) を指定する。指定したカテゴリとそれより上のレベルのカテゴリが含まれる。指定できる値は、高いレベルから順に ERROR、WARNING、INFO。デフォルトは INFO
imq.log.file.output	ログファイルに書き込むロギング情報のカテゴリを指定する。指定できる値は、縦線 (|) で区切ったロギングのカテゴリのセット、ALL または NONE。デフォルトは ALL
imq.log.file.dirpath	ログファイルが配置されているディレクトリへのパスを指定する。デフォルトは IMQ_VARHOME/instances/brokerName/log/
imq.log.file.filename	ログファイル名を指定する。デフォルトは log.txt
imq.log.file.rolloverbytes	新しいログファイルに出力がロールオーバーされるログファイルのサイズをバイト単位で指定する。値を 0 に設定した場合、ファイルのサイズに基づいたロールオーバーは行われない。デフォルトは 0
imq.log.file.rolloversecs	新しいログファイルに出力がロールオーバーされるログファイルの有効期間を秒単位で指定する。値を 0 に設定した場合、ファイルの有効期間に基づいたロールオーバーは行われない。デフォルトは 604800
imq.log.console.output	ログファイルに出力するロギング情報のカテゴリを指定する。指定できる値は、縦線 (|) で区切ったロギングのカテゴリのセット、ALL または NONE。デフォルトは ERROR| WARNING
imq.log.console.stream	コンソールの出力を標準出力 (OUT)、または標準エラー出力 (ERR) のどちらに書き込むかを指定する。デフォルトは ERR
imq.log.syslog.facility	(Solaris のみ) MQ ブローカが記録する syslog 機能を指定する。値は、syslog(3C) の Man ページに示される値をミラー化する。MQ で使用する適切な値は、LOG_USER、LOG_DAEMON、および LOG_LOCAL0 から LOG_LOCAL7 まで。デフォルトは、LOG_DAEMON
imq.log.syslog.logpid	(Solaris のみ) メッセージとともにブローカのプロセス ID を記録するかどうかを指定する (true/false)。デフォルトは true
imq.log.syslog.console	(Solaris のみ) メッセージを syslog に送信できない場合に、システムコンソールにメッセージを出力するかどうかを指定する (true/false)。デフォルトは false
imq.log.syslog.identity	(Solaris のみ) Syslog に記録される各メッセージの先頭に付加する識別情報文字列を指定する。デフォルトは、imqbrokerd_ の後にブローカインスタンス名
imq.log.syslog.output	(Solaris のみ) syslogd(1M) に書き込むロギング情報のカテゴリを指定する。指定できる値は、縦線 (|) で区切ったロギングのカテゴリのセット、ALL または NONE。デフォルトは、ERROR

物理的な送信先

MQ のメッセージングは、メッセージの 2 段階配信を前提としています。メッセージは最初にプロデューサクライアントから、ブローカの送信先に配信され、次にブローカの送信先から 1 つまたは複数のコンシューマクライアントに配信されます。送信先にはキュー (ポイントツーポイント配信モード) とトピック (パブリッシュ / サブスクライブ配信モデル) の 2 つのタイプがあります (「プログラミングドメイン」を参照)。これらの送信先は、受信メッセージがコンシューマクライアントにルーティングされる前に整列化するブローカの物理的なメモリの場所を表しています。

物理的な送信先を作成するには、MQ 管理ツールを使用します (「送信先の管理」を参照)。送信先は、「自動作成 (および管理者によって作成) された送信先」に示すように、自動的に作成することも可能です。

この節では、キューとトピックの 2 つのタイプの物理的な送信先のプロパティと動作について説明します。

キューの送信先

キューの送信先は、ポイントツーポイントメッセージングで使用されます。メッセージは、送信先に配信対象を登録している多数のコンシューマのうちの 1 つだけに最終的に配信されるようになっています。メッセージはプロデューサクライアントから到着すると、キューに入って、コンシューマクライアントに配信されます。

キューに入っているメッセージのルーティングは、キューの配信ポリシーによって異なります。MQ は、次の 3 つのキュー配信ポリシーを実装します。

• シングルこのキューでは、メッセージを 1 つのメッセージコンシューマだけにルートします。2 つ目のメッセージコンシューマが、キューに登録しようとすると拒否されます。登録されたメッセージコンシューマが接続を解除した場合、メッセージはルートされずに、新しいコンシューマが登録されるまで保存されます。

• フェイルオーバーこのキューでは、メッセージを複数のメッセージコンシューマにルートしますが、これはプライマリメッセージコンシューマ (ブローカに登録した最初のメッセージコンシューマ) が接続を解除したときだけ行われます。メッセージは、次に登録するメッセージコンシューマに移動し、そのコンシューマに障害などが発生しないかぎり、そのコンシューマにルートされ続けます。メッセージコンシューマが登録されていない場合は、コンシューマが登録されるまでメッセージは保存されます。

• ラウンドロビンこのキューでは、メッセージを複数のメッセージコンシューマにルートします。多数のコンシューマがキューに登録されている場合、キューの 1 番目のメッセージは、1 番目に登録されているメッセージコンシューマにルートされ、2 番目のメッセージは、2 番目に登録されているコンシューマに順番にルートされます。追加メッセージは、一連の同様のコンシューマに、同様の順序でルートされます。コンシューマがキューに登録する前に、多数のメッセージがキューに入っている場合、1 つのコンシューマにメッセージが集中するのを避けるため、メッセージはバッチにルートされます。メッセージコンシューマが接続を解除すると、そのコンシューマにルートされたメッセージは、残りのアクティブコンシューマに配信し直されます。このような再配信が発生するため、コンシューマへのメッセージの配信順序は、メッセージがキューに受信された順序と同じになるとはかぎりません。

メッセージは、長期間キューに存在することができるため、メモリリソースが問題になる可能性があります。キューに割り当てるメモリが、多すぎると、メモリが十分に利用されず、少なすぎると、メッセージが拒否されます。各キューのロード要求に基づいて柔軟性をもたせるために、キューの作成時に、キュー内のメッセージの最大数、キュー内のメッセージに割り当てられる最大メモリ、およびキュー内の任意のメッセージの最大サイズといった物理的なプロパティを設定できます (表 6-10 を参照)。

トピックの送信先

トピックの送信先は、パブリッシュ / サブスクライバメッセージングで使用されます。メッセージは、送信先に配信対象を登録しているすべてのコンシューマに最終的に配信されるようになっています。メッセージはプロデューサから送信されてくると、トピックをサブスクライブするすべてのコンシューマにルートされます。コンシューマがトピックの永続サブスクリプションを登録している場合、コンシューマは、トピックにメッセージが配信されるときに、アクティブになっている必要はありません。コンシューマが再びアクティブになるまで、ブローカがメッセージを保存し、配信するからです。

通常、メッセージはトピックの送信先に長期間保存されることがないため、メモリリソースは大きな問題にはなりません。しかし、送信先で受信されるメッセージの最大許容サイズを設定することは可能です (表 6-10 を参照)。

自動作成 (および管理者によって作成) された送信先

JMS メッセージサーバは、メッセージングシステムの中心的なハブであるため、そのパフォーマンスと信頼性が、エンタープライズアプリケーションの成功に向けての重要な鍵となります。送信先は、送信先が処理するメッセージの数とサイズ、および登録するメッセージコンシューマの数と永続性によっては、リソースを著しくコンシュームする可能性があるので、メッセージサーバのパフォーマンスと信頼性を確保するために、送信先を綿密に管理する必要があります。したがって、アプリケーションのための送信先の作成、送信先の監視、必要に応じたリソース要件の再構成が、MQ の管理者の基本的な業務になります。

しかし、送信先を動的に作成するのが望ましい場合もあります。たとえば、開発およびテストサイクル中に、管理者の介入なしで、必要に応じてブローカに送信先を自動的に作成させる必要がでてくる場合があります。

MQ は、この自動作成機能がサポートしています。自動作成を有効にすると、実在しない送信先に、MessageConsumer や MessageProducer がアクセスしようとしたときに、ブローカが送信先を自動的に作成します。ただし、クライアントアプリケーションのユーザは、自動作成の権限を保持する必要があります (「送信先自動作成アクセス制御」を参照)

送信先が明示的ではなく自動的に作成される場合、同じ送信先名を使用する異なるクライアントアプリケーション間でクラッシュが発生したり、送信先をサポートするのに必要なリソースによって、システムのパフォーマンスが低下したりする可能性があります。このため、MQ の自動作成された送信先は、使用されなくなると (すなわち、メッセージコンシューマクライアントがなくなり、メッセージが含まれていない場合)、ブローカによって自動的に破棄されます。ブローカが再起動すると、持続メッセージが含まれている場合にだけ、自動作成された送信先が再び作成されます。

表 2-9 に示すプロパティを使用して、自動作成機能を有効、または無効にするように、MQ メッセージサーバを設定することができます (各プロパティの設定方法については、第 5 章「ブローカの起動と設定」を参照)。

表 2-9    自動作成の設定プロパティ 

プロパティ名	説明
imq.autocreate.topic	ブローカでトピックの送信先の自動作成を許可するかどうかを指定する (true/false)。デフォルトは true
imq.autocreate.queue	ブローカでキューの送信先の自動作成を許可するかどうかを指定する (true/false)。デフォルトは true
imq.queue.deliverypolicy	自動作成されたキューのデフォルトの配信ポリシーを指定する。指定できる値は single、round-robin、または failover。デフォルトは single

一時送信先

一時送信先は、ほかのクライアントに送信したメッセージに対する応答を受信するために送信先が必要な場合に、クライアントアプリケーションによって、(JMS API を使用して) 明示的に作成および破棄されます。これらの送信先は、送信先が作成されたコネクションの存続期間中にだけ、ブローカによって保持されます。管理者が一時送信先を破棄することはできません。また、一時送信先が使用されている間、すなわち、アクティブなメッセージコンシューマがいる間は、クライアントアプリケーションが一時送信先を破棄することもできません。管理者が作成した送信先や自動作成された送信先 (持続メッセージを保持する) と違って、一時送信先は、継続的には格納されず、ブローカの再起動時に作成し直されることもありません。また、一時送信先は、MQ の管理ツールで認識できません。

複数ブローカの設定 (クラスタ)

MQ Enterprise Edition (「製品エディション」を参照) は、複数の連結したブローカ、すなわち、ブローカのクラスタを使用したメッセージサーバの実装がサポートしています。クラスタのサポートによって、メッセージサーバのスケーラビリティが提供されます。

ブローカに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカは最終的に、ファイル記述子やメモリの制限などのリソースの限界を超えてしまいます。増え続ける負荷に対処するための 1 つの方法は、MQ メッセージサーバにブローカを追加して、クライアントのコネクションとメッセージの配信を複数のブローカに分散することです。

また、複数のブローカを使用してネットワークの帯域幅を最適化することもできます。たとえば、一連のリモートブローカ間で、速度の遅い、長距離のネットワークリンクを使用する一方で、個々のブローカへのクライアントの接続に、速度の速いリンクを使用することができます。

異なるユーザリポジトリを保持するワークグループに対応したり、ファイアウォールの制限に対処したりする場合など、ブローカのクラスタを使用する理由はほかにも存在しますが、フェイルオーバーはこれに含まれません。クラスタ内の 1 つのブローカを、障害が発生した別のブローカの自動バックアップとして使用することはできません。ブローカの自動フェイルオーバー保護は、MQ 3.0 ではサポートされていません (ただし、カスタマイズしたフェイルオーバー方式を実装するために、複数のブローカを使用するようにアプリケーションを設計することは可能)。

ブローカのクラスタの設定および管理については、「ブローカクラスタの操作」で説明します。次の節では、MQ のブローカのクラスタのアーキテクチャと内部機能について説明します。

複数ブローカのアーキテクチャ

図 2-7 に示すように、複数ブローカのメッセージサーバを使用すると、クライアントのコネクションを多数のブローカに分散することができます。クライアント側から見た場合、各クライアントは個々のブローカ (クライアントの ホームブローカ) に接続し、ホームブローカがクラスタ内の唯一のブローカであるかのように、メッセージを送受信します。しかし、サーバ側から見た場合、ホームブローカは、クラスタ内のほかのブローカと並行して動作し、直接接続しているメッセージプロデューサとコンシューマに配信サービスを提供します。

通常、クラスタ内のブローカには、任意のトポロジで接続することが可能です。ただし、図 2-7 に示すように、MQ 3.0 は、完全に接続されたクラスタ、すなわち、各ブローカがクラスタ内のほかのすべてのブローカに直接接続するトポロジだけをサポートしています。

複数ブローカの設定では、各送信先のインスタンスは、クラスタ内のすべてのブローカに常駐します。また、各ブローカは、ほかのすべてのブローカに登録されたメッセージコンシューマを認識します。このため、各ブローカは、ブローカに直接接続しているメッセージプロデューサから、リモートのメッセージコンシューマにメッセージをルートし、リモートのプロデューサから、ブローカに直接接続しているコンシューマにメッセージを配信することができます。

クラスタ設定では、各メッセージプロデューサが直接接続しているブローカが、そのプロデューサによって送信されたメッセージのルートを行います。したがって、持続メッセージの格納とルートは、両方ともメッセージのホームブローカによって行われます。

図 2-7    複数ブローカ (クラスタ) のアーキテクチャ

管理者がブローカの送信先を作成、または破棄すると、この情報がクラスタ内のほかのすべてのブローカに自動的に伝えられます。同様に、メッセージコンシューマがホームブローカに登録された場合や、明示的、またはクライアントやネットワークの障害やホームブローカのダウンが原因で、コンシューマがホームブローカから接続を解除された場合に、コンシューマについての関連情報がクラスタ全体に伝えられます。永続サブスクリプションに関する情報も同じように、クラスタ内のすべてのブローカに伝えられます。

通常、送信先やメッセージコンシューマに関する情報を特定のブローカに伝える場合、共有リソースで変更が行われたときに、ブローカがオンラインになっている必要があります。ブローカがクラッシュして再起動していたり、新しいブローカをクラスタに動的に追加していたりして、ブローカがオフラインになっているときにこのような変更が行われると、どうなるかについて、次に説明します。

オフラインになっているブローカ (または、新規追加されたブローカ) に対応するために、MQ は、クラスタ内のすべての持続エンティティの変更記録、すなわち、作成または破棄されたすべての送信先と永続サブスクリプションの記録が保管されます。ブローカはクラスタに動的に追加されると、最初に、この 設定変更記録から送信先および永続サブスクライバの情報を読み取ります。ブローカはオンラインになったときに、現在のアクティブコンシューマに関する情報をほかのブローカと交換します。この情報を使用して、新しいブローカはクラスタに完全に統合化されます。

設定変更記録は、クラスタ内の 1 つのブローカ、すなわち、マスターブローカとして設定されているブローカで管理されます。クラスタにブローカを動的に追加する場合、マスターブローカがキーポイントになるため、常にこのブローカを最初に起動しておく必要があります。マスターブローカがオンラインになっていないと、クラスタ内のほかのブローカが初期化を実行できません。

マスターブローカがオフラインになると、ほかのブローカが設定変更記録にアクセスできなくなり、MQ は送信先と永続サブスクリプションをクラスタ全体に伝えられません。このような状況では、送信先または永続サブスクリプションを作成または破棄しようとすると (あるいは、永続サブスクリプションの再有効化のようなさまざまな関連操作を実行しようとすると)、例外が生じます。

基幹アプリケーション環境の場合、設定変更記録の偶発的な破損や、マスターブローカの障害に対応するために、設定変更記録を定期的にバックアップすることをお勧めします。これは imqbrokerd コマンドの -backup オプション (表 5-2 を参照) を使用すると実行できます。このオプションでは、設定変更記録を含んだバックアップファイルを作成する方法が提供されます。その後で、-restore オプションを使用して、設定変更記録を復元することができます。

必要に応じて、マスターブローカの役割を果たすブローカを変更することができます。これを実行するには、設定変更記録をバックアップし、適切なクラスタ設定プロパティ (表 2-10 を参照) を変更して新しいマスターブローカを指定した後、-restore オプションを使用して新しいマスターブローカを再起動します。

開発環境でのクラスタの使用

クラスタをテストに使用し、スケーラビリティやブローカの復元が重視されない開発環境では、マスターブローカはさほど必要ありません。マスターブローカなしで設定した環境の場合、MQ はほかのブローカを起動するために、マスターブローカを実行する要件を緩和し、送信先や永続サブスクリプションの変更を行って、この変更をクラスタ内で実行中のすべてのブローカに伝えることを許可します。ただし、ブローカがオフラインになって、その後で復元された場合、オフライン中に行われた変更は同期化されません。

通常、テスト環境の場合、送信先は自動作成 (「自動作成 (および管理者によって作成) された送信先」を参照) され、これらの送信先の永続サブスクリプションは、テストしているアプリケーションによって作成および破棄されます。送信先と永続サブスクリプションにおけるこれらの変更は、クラスタ全体に伝えられます。ただし、マスターブローカを使用する環境を再設定すると、MQ は送信先および永続サブスクリプションを変更し、クラスタ全体にこれらの変更を伝えるために、マスターブローカを起動しておく要件を再び強要するようになります。

クラスタ設定プロパティ

クラスタ内の各ブローカは、起動時に、クラスタ内のほかのブローカに関する情報 (ホスト名とポート番号) を受け取る必要があります。この情報は、クラスタ内のブローカ間で、コネクションを確立する際に使用されます。各ブローカは、マスターブローカ (使用している場合) のホスト名とポート番号についても把握する必要があります。

クラスタ内のすべてのブローカは、同じクラスタ設定プロパティを使用する必要があります。これは、各ブローカが起動時に参照する中央の 1 つの クラスタ設定ファイルに、クラスタ設定プロパティを配置することで実現できます。

これらの設定プロパティを複製して、各ブローカに配置することも可能ですが、クラスタ設定で不一致が生じる可能性があるため、お勧めしません。クラスタ設定プロパティを 1 つのファイルだけにすることで、すべてのブローカが同じ情報を読み取るようになります。

MQ のクラスタ設定プロパティを、表 2-10 に示します。これらのプロパティの設定については、「ブローカクラスタの操作」を参照してください。

表 2-10    クラスタ設定プロパティ 

プロパティ名	説明
imq.cluster.brokerlist	クラスタ内のすべてのブローカを指定する。host:port エントリのコンマで区切られたリストで構成される。host は、各ブローカのホスト名で、port はそのポートマッパーのポート番号
imq.cluster.masterbroker	クラスタ内のどのブローカをマスターブローカにするのかを指定する。マスターブローカは状態の変化を追跡する。プロパティは、host:port で構成される。host は、マスターブローカのホスト名で、port はそのポートマッパーのポート番号
imq.cluster.url	クラスタ設定ファイルの場所を指定する。クラスタのプロパティ値を個別に提供するのではなく、ブローカが中央の 1 つの設定ファイルを参照する場合に使用する。URL の文字列で設定される。Web サーバ上にある場合は、通常の http:URL を使用して、アクセスできる。共有ドライブ上にある場合は、file:URL を使用して、アクセスできる
imq.cluster.port	クラスタ内にある各ブローカに対して、クラスタコネクションサービスのポート番号の指定に使用される。クラスタコネクションサービスは、クラスタにあるブローカ間での内部通信に使用される。デフォルトは、0 (ポートは動的に割り当てられる)
imq.cluster.hostname	クラスタ内の各ブローカに対して、コンピュータに複数のネットワークインタフェースカードがある場合など、複数の使用可能なホストがある場合に、クラスタコネクションサービスのバインド先となるホスト (ホスト名または IP アドレス) の指定に使用される。クラスタコネクションサービスは、クラスタにあるブローカ間での内部通信に使用される。デフォルトは、null (すべての使用可能なホスト)

クラスタ設定ファイルは、一連のブローカに共通するすべてのブローカ設定プロパティを格納できます。本来、クラスタ設定ファイルは、クラスタを設定するためのものですが、クラスタ内のすべてのブローカに共通するほかのブローカのプロパティを格納するのにも使用できます。

MQ クライアントランタイム

---

MQ クライアントランタイムは、クライアントアプリケーションに MQ メッセージサーバへのインタフェースを提供します。つまり、クライアントランタイムによって、「JMS プログラミングモデル」に記載されるすべての JMS プログラミングオブジェクトがクライアントアプリケーションに提供されます。クライアントランタイムでは、クライアントが送信先にメッセージを送信し、送信先からメッセージを受信するために必要なすべての処理がサポートされます。

この節では、MQ クライアントランタイムの動作方法について詳しく説明します。クライアントランタイムのパフォーマンスに影響を与える要因については、クライアントアプリケーションの設計やパフォーマンスに影響するため、『MQ 開発者ガイド』で説明します。

図 2-8 に、クライアントアプリケーションと MQ クライアントランタイム間の対話におけるメッセージのプロデュースとコンシューム、および MQ クライアントランタイムと MQ メッセージサーバ間の対話におけるメッセージの配信について示します。

図 2-8    メッセージングの処理

メッセージのプロデュース

メッセージのプロデュースでは、メッセージはクライアントによって作成され、ブローカの送信先へのコネクションを介して送信されます。MessageProducer オブジェクトのメッセージ配信モードが、持続 (配信を 1 回だけ保証する) に設定されている場合、メッセージが送信先に配信されて、ブローカの持続データストアに格納されたことをブローカが通知するまで、クライアントスレッドはブロックされます。メッセージが持続的でない場合、ブローカの通知メッセージ (「ACK」というプロパティ名で呼ばれる) は返されず、クライアントスレッドはブロックされません。

メッセージのコンシューム

メッセージのコンシュームは、プロデュースより複雑です。ブローカの送信先に到着したメッセージは、次の条件に基づいて MQ クライアントランタイムへのコネクションを介して配信されます。

• クライアントが、特定の送信先のコンシューマを設定している

• コンシューマの選択基準が、特定の送信先に到着したメッセージの基準と一致している

• メッセージの配信を開始するように、コネクションが指示されている

図 2-9 に示すように、コネクションを介して配信されるメッセージは、適切な MQ セッションに分散されます。ここで、メッセージはキューに入れられて適切な MessageConsumer オブジェクトによってコンシュームされます。メッセージは、1 つずつ各セッションキューからフェッチされ (セッションはシングルスレッドになる)、receive メソッドを呼び出すクライアントスレッドによって同期的、または MessageListener オブジェクトの onMessage メソッドを呼び出すセッションスレッドによって非同期的にコンシュームされます。

図 2-9    MQ クライアントランタイムへのメッセージの配信

ブローカはクライアントランタイムにメッセージを配信する際、メッセージにマークを付けますが、メッセージが受信、またはコンシュームされたかどうかは実際には把握していません。このため、ブローカは、ブローカの送信先からメッセージを削除する前に、クライアントがメッセージの受信を通知するのを待ちます。

MQ 管理対象オブジェクト

---

管理対象オブジェクトを使用すると、クライアントアプリケーションコードがプロバイダに依存しなくなります。これはクライアントアプリケーションが使用するオブジェクトに、プロバイダに依存しない方法で、プロバイダ固有の実装と設定情報をカプセル化することによって実現できます。管理対象オブジェクトは、管理者が作成および設定し、ネームサービスに格納されます。クライアントアプリケーションは、標準 JNDI 検索コードを介して管理対象オブジェクトにアクセスします。

MQ には、ConnectionFactory と Destination の 2 つのタイプの管理対象オブジェクトが用意されています。どちらもプロバイダの固有情報をカプセル化し、クライアントアプリケーション内でいろいろな方法で使われます。ConnectionFactory オブジェクトは、メッセージサーバへのコネクションを作成する際に使用され、Destination オブジェクトは、物理的な送信先を識別する際に使用されます。

管理対象オブジェクトで、MQ メッセージサーバの制御および管理を非常に簡単に行うことができます。

• クライアントアプリケーションをあらかじめ設定した ConnectionFactory オブジェクト (「管理対象オブジェクトの属性」を参照) にアクセスさせることによって、コネクションの動作を制御できる

• 既存の物理的な送信先に対応するあらかじめ設定した Destination オブジェクトに、クライアントアプリケーションをアクセスさせることによって、物理的な送信先の拡散を制御できる。ただし、ブローカの自動作成機能を無効にしておく必要がある(「自動作成 (および管理者によって作成) された送信先」を参照)

• クライアントアプリケーションが設定したメッセージヘッダーの値をオーバーライド (「管理対象オブジェクトの属性」を参照) することによって、MQ メッセージサーバのリソースを制御できる

この仕組みによって、MQ の管理者はメッセージサーバの設定詳細を管理することが可能となり、同時に、クライアントアプリケーションがプロバイダに依存しなくなります。このため、クライアントアプリケーションは、プロバイダ固有の構文およびオブジェクトの命名規則 (「JMS プロバイダへの非依存性」を参照)、またはプロバイダ固有の設定プロパティを把握する必要がありません。

管理対象オブジェクトは、第 7 章「管理対象オブジェクトの管理」に示すように、MQ の管理ツールを使用して作成します。管理対象オブジェクトを作成する場合、オブジェクトを作成するときに設定した MQ 固有の設定値が、クライアントアプリケーションによって変更されないように、オブジェクトを読み取り専用に設定することができます。つまり、クライアントコードが読み取り専用の管理対象オブジェクトに、属性値を設定することはできませんし、「クライアントの起動時の属性値のオーバーライド」に示すように、管理者がクライアントアプリケーションの起動オプションを使用して、これらの値をオーバーライドすることもできません。

クライアントアプリケーションは、ConnectionFactory と Destination の両方の管理対象オブジェクトをインスタンス化することができますが、それは、管理対象オブジェクトの基本目的 (MQ の管理者が、アプリケーションに必要なブローカリソースの制御とそのパフォーマンスの調整を行えるようにする) が徐々に失われます。また、管理対象オブジェクトを直接インスタンス化すると、クライアントアプリケーションは、プロバイダに依存しないものではなく、プロバイダに依存したものになります。

コネクションファクトリ管理対象オブジェクト

ConnectionFactory オブジェクトは、クライアントアプリケーションと MQ メッセージサーバ間の物理的なコネクションを確立する場合に使用します。また、コネクションの動作や、ブローカにアクセスするためにコネクションを使用するクライアントランタイムの動作を指定する場合にも使用します。

分散トランザクション (「ローカルトランザクション」を参照) をサポートする必要がある場合、分散トランザクションをサポートする特殊な XAConnectionFactory オブジェクトを使用する必要があります。

ConnectionFactory 管理対象オブジェクトを作成する場合は、「コネクションファクトリ管理対象オブジェクトの追加」を参照してください。

ConnectionFactory 管理対象オブジェクトを設定して、オブジェクトがプロデュースするすべてのコネクションに共通する属性値 (プロパティ) を指定します。ConnectionFactory オブジェクトと XAConnectionFactory オブジェクトは、一連の同じ属性値を共有します。これらの属性値は、影響を及ぼす動作に基づいて、いくつかのカテゴリに分類されます。

• コネクションの指定

• 自動再接続の動作

• クライアントの識別

• メッセージヘッダーのオーバーライド

• 信頼性およびフローの制御

• キューブラウザの動作

• アプリケーションサーバのサポート

• JMS 定義されたプロパティのサポート

各カテゴリと対応する属性については、『MQ 開発者ガイド』で詳しく説明します。MQ の管理者は、これらの属性値の調整を行わなければならない場合もありますが、クライアントアプリケーションのパフォーマンスをチューニングするために、調整が必要な属性を判断するのは、通常、アプリケーション開発者です。表 7-3 に、属性の概要をアルファベット順に示します。

送信先管理対象オブジェクト

Destination 管理対象オブジェクトは、公に名前の付けられた Destination オブジェクトに対応するブローカの物理的な送信先 (キュー、またはトピック) を表しています。この 2 つの属性を表 2-11 に示します。Destination オブジェクトを作成すると、クライアントアプリケーションの MessageConsumer オブジェクトまたは MessageProducer オブジェクト、あるいはその両方が、対応する物理的な送信先にアクセスできるようになります。

Destintion 管理対象オブジェクトを作成する場合は、「トピックまたはキューの管理対象オブジェクトの追加」を参照してください。

表 2-11    送信先の属性

属性 / プロパティ名	説明
imqDestinationName	物理的な送信先のプロバイダ固有名を指定する。物理的な送信先を作成したときに、この名前を指定する。送信先名には、英数字 (空白文字は含まない) だけを使用する必要がある。送信先名は、英字や "_" および "$" で開始できる。 デフォルトは  Untitled_Destination_Object
imqDestinationDescription	オブジェクトの管理に役立つ情報を指定する。デフォルトは A Description for the Destination Object

クライアントの起動時の属性値のオーバーライド

Java アプリケーションの場合と同様に、コマンド行でシステムのプロパティを指定して、メッセージングアプリケーションを起動できます。この方法は、クライアントアプリケーションコードで使用されている管理対象オブジェクトの属性値をオーバーライドすることもできます。たとえば、JNDI 検索を介してアクセスするクライアントアプリケーションコードの管理対象オブジェクトの設定をオーバーライドすることが可能です。

クライアントアプリケーションの起動時に、管理対象オブジェクトの設定をオーバーライドするには、次のようなコマンド行の構文を使用します。

java [[-Dattribute=value ]...] clientAppName

attribute は、「コネクションファクトリ管理対象オブジェクト」に示す ConnectionFactory 管理対象オブジェクトの属性と一致します。

たとえば、クライアントアプリケーションをクライアントコードでアクセスされる ConnectionFactory 管理対象オブジェクトに指定されたブローカとは異なるブローカに接続する場合、別のブローカの imqBrokerHostName と imqBrokerHostPort を設定するために、オーバーライドのコマンド行を使用して、クライアントアプリケーションを起動することができます。

ただし、管理対象オブジェクトが読み取り専用に設定されている場合、オーバーライドのコマンド行を使用して、その属性値を変更することはできません。そのようなオーバーライドは、無視されます。