コンポーネントサービス
図 3–1 に Message Queue サービスを示します。第 2 章「クライアントプログラミングモデル」 では、プログラミングモデルの概要と、クライアントが Java および C API を使用して、クライアントアプリケーションからアクセス可能なメッセージサービスの一部であるクライアントランタイムと対話する方法について説明します。この章では、管理者がアクセス可能なメッセージサービスのコンポーネントおよびサービスを中心に説明します。
図 3–1 Message Queue サービス
Message Queue サービスは、ブローカのプロパティーを設定することによって管理します。これらのプロパティーは、特定のプロパティーによって影響を受けるサービスまたはブローカコンポーネントに応じていくつかのカテゴリに分類されます。ブローカサービスには次のものがあります。
以降の節では、これらの各サービスと、特定のニーズに合わせてサービスをカスタマイズするために使用するプロパティーの概要について説明します。
ブローカのプロパティーは、それぞれの設定ファイル内で定義されますが、ブローカを起動するために使用するコマンド行で定義することもできます。『Sun Java System Message Queue 3.7 UR1 管理ガイド』の第 4 章「Configuring a Broker」では、これらの設定ファイルと、1 ファイル内のプロパティー値を使用して別のファイル内で設定された値をオーバーライドするための優先順位について説明しています。起動コマンドを使用して設定されたプロパティーはほかのすべての設定をオーバーライドします。
コネクションサービス
コネクション関連のプロパティーを使用して、ブローカとそのクライアントの間の物理的な接続を設定および管理します。Message Queue クライアントで使用可能なコネクションサービスについては、「ブローカへの接続」で説明しています。この項では、使用可能なコネクションサービス、サービス名、サービスタイプ、および基礎となるプロトコルについて説明しています。コネクションサービスは、マルチスレッド化されており、専用のポート経由で使用できます。このポートは、ブローカのポートマッパーによって動的に割り当てることも、管理者が静的に割り当てることもできます。デフォルトでは、ブローカを起動すると、jms および admin サービスが稼働します。
すべてのコネクションには 2 つの端があるため、両側でコネクションの設定を行い、調整する必要があります。
-
クライアントは、コネクションファクトリオブジェクトの特定の属性を設定して、デフォルト以外のコネクションサービス、ホスト、およびポートの要求、異なるブローカへのコネクションが必要な場合に再接続するためのブローカのリストの指定、および再接続動作の設定を行う必要があります。クライアントはまた、失敗したコネクションをテストするための ping 間隔を指定することもできます。
-
管理者は、ブローカのプロパティーを使用して、デフォルト以外のコネクションサービスの有効化、必要に応じた静的なポートの割り当て、スレッドの設定、および複数のネットワークカードが使用された場合の接続先のホストの指定を行います。管理者はまた、クライアントがアクセス可能かどうかをテストするための ping 間隔を指定することもできます。これはリソースの管理に役立ちます。
クライアントは、ファイアウォール経由で Message Queue サービスに接続できます。これは、ファイアウォール管理者に特定のポートを開いてもらってからその (静的) ポートに接続するか、付録 B 「Message Queue の機能」で説明しているように、HTTP サービスまたは HTTPS サービスを使用して実現できます。
各コネクションサービスは、特定の認証および承認機能もサポートします。詳細は、「セキュリティーサービス」を参照してください。
ポートマッパー
コネクションサービスには、ブローカのメインポート 7676 に常駐する共通ポートマッパーによりポートが割り当てられます。Message Queue クライアントランタイムがブローカとの間でコネクションを設定する場合、最初にポートマッパーに接続し、選択したコネクションサービスのポート番号を要求します。
ポートマッパーは、jms、ssljms、admin、および ssladminの各サービスの設定時に、静的なポート番号を割り当てることによってオーバーライドできます。ただし、静的ポートは通常、ファイアウォールを通してコネクションを確立する場合のように特殊な状況でのみ使用され、一般的にはお勧めしません。
スレッドプール管理
各コネクションサービスは、複数のコネクションをサポートするマルチスレッドです。これらのコネクションに必要なスレッドは、プール内のブローカによって保持されます。スレッドの割り当て方法は、スレッドの最小数および最大数に指定した値、および選択したスレッドモデルによって決まります。
ブローカのプロパティーを設定してスレッドの最小数および最大数を指定できます。コネクションでスレッドが必要になると、コネクションをサポートするサービスのスレッドプールにスレッドが追加されます。最小数では、割り当てに使用できるスレッドの数を指定します。使用可能なスレッドの数がこの最小しきい値を超えると、システムはスレッドをシャットダウンします。スレッドは最小値に再び達するまで解放されるため、メモリーリソースが節約されます。負荷が大きい場合、プールの最大数に達するまでスレッドの数が増加する可能性があります。最大数に達すると、スレッドが使用可能になるまで新しい接続は拒否されます。
選択したスレッドモデルにより、スレッドが 1 つのコネクション専用か複数のコネクションで共有されるかが指定されます。
-
専用モデルでは、ブローカへのコネクションごとに 2 つのスレッドが必要になります。1 つは受信メッセージ用で、1 つは送信メッセージ用です。これにより、使用可能なコネクション数が制限されますがパフォーマンスが向上します。
-
共有モデルでは、メッセージを送受信するときに共有スレッドによってコネクションが処理されます。各コネクションに専用のスレッドが必要ないので、このモデルでは使用可能なコネクションの数が増加しますが、スレッド管理のオーバーヘッドが増えるためにパフォーマンスに影響します。
送信先とルーティングサービス
いったんクライアントがブローカに接続されると、メッセージのルーティングと配信を進めることができます。この段階では、メッセージの円滑な流れを確保し、リソースを効率的に使用するために、ブローカがさまざまなタイプの物理的な送信先を作成および管理します。ブローカは、ルーティングと配信に関連するブローカのプロパティーを使用して、アプリケーションのニーズに合った方法でこれらのタスクを管理します。
ブローカ上の物理的な送信先、つまりメッセージコンシューマに配信される前にメッセージが保存されるメモリーの場所の概念についてはすでに説明しました。次の 4 つのタイプの物理的な送信先があります。
-
管理者作成の送信先は、GUI (imqadmin) または imqcmd ユーティリティーを使用して管理者が作成します。この送信先は、プログラムによって作成される論理的な送信先か、管理者が作成しクライアントによって検索される送信先管理対象オブジェクトのどちらかに対応します。管理者作成の各送信先のプロパティーを設定または更新するには、imqcmd ユーティリティーを使用します。
-
自動作成の送信先は、メッセージのコンシューマまたはプロデューサが、存在しない送信先にアクセスしようとするたびにブローカによって自動的に作成されます。これらは一般的に開発中に使用されます。このような送信先の作成を許可しないようにブローカのプロパティーを設定できます。特定のブローカ上のすべての自動作成の送信先を設定するには、ブローカのプロパティーを設定します。
自動作成された送信先は、使用されなくなると、ブローカによって自動的に破棄されます。つまり、コンシューマクライアントを保持せず、メッセージを一切含まない状態になった場合です。ブローカの再起動の際、持続メッセージが含まれている場合にだけ、自動作成の送信先が再作成されます。
-
一時送信先は、メッセージに対する応答を受信するために送信先が必要な場合に、クライアントがプログラムによって明示的に作成および破棄します。名前でわかるように、これらの送信先は一時的であり、送信先が作成されたコネクションの存続期間中にだけ、ブローカによって保持されます。
一時送信先は、持続的には保持されず、ブローカの再起動時に作成し直されることもありません。ただし、管理ツールからは認識できます。
-
デッドメッセージキューは、ブローカの起動時に自動的に作成される特殊な送信先で、診断用のデッドメッセージを保管するために使用します。デッドメッセージキューのプロパティーを設定するには、imqcmd ユーティリティーを使用します。
送信先の管理
送信先を管理するには、imqcmd ユーティリティーを使用します。送信先の管理では、次の 1 つ以上のタスクを実行します。
-
送信先の作成、一時停止、再開、または破棄。
-
ブローカ上のすべての送信先の一覧表示。
-
送信先の状態とプロパティーに関する情報の表示。
-
送信先のメトリックス情報の表示。
-
送信先用のメッセージを保持するために使用されるディスクスペースの圧縮。
-
物理的な送信先のプロパティーの更新。
管理タスクは、管理される送信先のタイプ、つまり管理者作成、自動作成、一時、デッドメッセージキューによって異なります。たとえば、一時送信先は明示的に破棄する必要がありません。また自動作成されるプロパティーは、ブローカの設定プロパティーを使用して設定され、そのブローカ上のすべての自動作成される送信先に適用されます。
物理的な送信先の設定
最適なパフォーマンスを得るために、物理的な送信先を作成または更新するときにプロパティーを設定することができます。次のようなプロパティーを設定することができます。
-
送信先のタイプと名前。
-
送信先の個別の制限および全体の制限 (メッセージの最大数、最大合計バイト数、メッセージあたりの最大バイト数、プロデューサの最大数)。
-
個別の制限または全体の制限を超えた場合にブローカが実行する処理。
-
1 回のバッチで配信されるメッセージの最大数。
-
送信先用のデッドメッセージをデッドメッセージキューに送信するかどうか。
-
クラスタ化されたブローカで送信先をクラスタ内の他のブローカに複製するかどうか。
また、キュー送信先に対してバックアップコンシューマの最大数を設定したり、クラスタ化されたブローカに対してローカルキューへの送信を優先するかどうかを指定したりできます。
デッドメッセージキューの制限および動作を設定することもできます。ただし、このキューのデフォルトのプロパティーは、標準のキューのプロパティーとは異なっています。
メモリーの管理
送信先は、送信先が処理するメッセージの数とサイズ、および登録するコンシューマの数と永続性によっては、リソースを著しく消費する可能性があるので、メッセージサービスのパフォーマンスと信頼性を確保するために、送信先を綿密に管理する必要があります。
プロパティーを設定することで、ブローカが受信メッセージのために過負荷状態になったり、ブローカのメモリーが不足したりすることを防ぐことができます。ブローカは、送信先の制限、システム全体の制限、およびシステムメモリーのしきい値という 3 つのメモリー保護レベルを使用して、リソースが少なくなったときにもメッセージサービスの動作を維持します。送信先の制限とシステム全体の制限が適切に設定されている場合、重要なシステムメモリーのしきい値を超えないようにするのが理想的です。
送信先のメッセージ制限
送信先の属性を設定して、送信先ごとにメモリーとメッセージフローを管理することができます。たとえば、送信先で許容されるプロデューサの最大数、送信先で許容されるメッセージの最大数 (または、サイズ)、および任意のメッセージの最大サイズを指定できます。
また、これらの制限に達した場合のブローカの対応方法 (プロデューサの動作を遅くする、もっとも古いメッセージを破棄する、優先度がもっとも低いメッセージを破棄する、最新のメッセージを拒否する) を指定できます。
システム全体のメッセージ制限
プロパティーを使用してブローカ上のすべての送信先に適用される制限を設定することもできます。メッセージの総数とすべてのメッセージによって消費される総メモリー量を指定できます。どちらかのシステム全体のメッセージ制限に達した場合、ブローカは新しいメッセージを拒否します。
システムメモリーのしきい値
最後に、プロパティーを使用して、ブローカが段階的に深刻なアクションを実行するしきい値を設定し、メモリーの過負荷を避けるようにすることができます。実行されるアクションは、メモリーリソースの状態によって異なります。green (使用可能なメモリーが十分にある)、yellow (ブローカのメモリーが減っている)、orange (ブローカのメモリーが不十分である)、red (ブローカのメモリーが不足している) といった状態です。ブローカのメモリーの状態が green から red へと進むにつれ、ブローカは次のタイプの深刻なアクションを段階的に実行します。
-
データストアの持続メッセージのメモリー内コピーを廃棄する。
-
非持続メッセージのプロデューサを減らし、最終的にブローカへのメッセージのフローを停止する。持続メッセージのフローは、各メッセージがブローカによって通知される要件によって自動的に制限される。
持続サービス
障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。そのためには、状態情報をデータストアに保存する必要があります。ブローカが再起動されると、保存されているデータを使用して送信先および永続サブスクリプションを再作成し、持続メッセージを復元し、開いているトランザクションをロールバックし、未配信メッセージのルーティングテーブルを再作成します。その後ブローカは、メッセージの配信を再開します。
Message Queue サービスは、ファイルベースの持続モジュールと JDBC 準拠の持続モジュールの両方をサポートしていますが (図 3–2 を参照)、デフォルトではファイルベースの持続を使用します。
図 3–2 持続サポート
ファイルベースの持続
ファイルベースの持続は、個々のファイルを使用して持続データを保存するメカニズムです。ファイルベースの持続を使用する場合は、次のタスクを実行するようにブローカのプロパティーを設定できます。
-
メッセージが追加および削除されたときの断片化を減らすために、データストアを圧縮する。
-
書き込みのたびにメモリー内の状態と物理的なストレージデバイスとを同期する。この同期化により、システム破壊によるデータの損失をなくすことができます。
-
データストアファイルへのメッセージの割り当てを管理し、ファイルの管理および保存に必要なリソースを管理する。
通常、ファイルベースの持続の方が、JDBC ベースの持続より処理速度が速くなりますが、JDBC 準拠のストアによる冗長性および管理制御を好むユーザーもいます。
JDBC ベースの持続
JDBC の持続 は、Java Database Connectivity (JDBCTM) インタフェースを使用して、ブローカと JDBC 準拠のデータストアを接続します。ブローカが JDBC ドライバを介してデータストアにアクセスできるようにするには、次のことを実行する必要があります。
-
JDBC関連ブローカ設定プロパティーを設定します。これらのプロパティーを使用して、使用する JDBC ドライバの指定、JDBC ユーザーとしてのブローカの認証、必要なテーブルの作成などを行います。
-
imqdbmgr ユーティリティーを使用して適切なスキーマでデータストアを作成します。
これらのタスクの実行手順および関連する設定プロパティーについて詳しくは、『Sun Java System Message Queue 3.7 UR1 管理ガイド』の第 4 章「Configuring a Broker」を参照してください。
セキュリティーサービス
Message Queue サービスは、各ブローカインスタンス用の認証および承認 (アクセス制御) をサポートし、暗号化もサポートしています。
-
認証により、検証されたユーザーだけがブローカとのコネクションを確立できるようにします。
-
承認により、リソースにアクセスし、特定の操作を実行する権限を持つユーザーまたはグループを指定します。
-
暗号化により、コネクションを通して配信されるときに改ざんされないよう、メッセージを保護します。
認証と承認は、メッセージングシステムのユーザーに関する情報、つまり名前、パスワード、グループ (group) メンバーシップなどを含むリポジトリによって異なります。また、ユーザーまたはグループによる特定の操作を承認するには、ブローカはユーザーまたはグループが実行できる操作を指定するアクセス制御プロパティーファイルをチェックする必要があります。ブローカがユーザーを認証してユーザーの操作を承認するために必要な情報は、管理者が設定する必要があります。
図 3–3は、ブローカが認証と承認を与えるために必要とするコンポーネントを示しています。
図 3–3 セキュリティーマネージャーのサポート
図 3–3 に示すように、Message Queue サービスに付属している単層型ファイルユーザーリポジトリにユーザーデータを保存するか、既存の LDAP リポジトリにプラグインすることができます。ブローカのプロパティーを設定して、自分の選択を指定します。
-
単層型ファイルリポジトリを選択する場合は、imqusermgr ユーティリティーを使用してリポジトリを管理する必要があります。これは、使いやすい組み込みユーティリティーです。
-
既存の LDAP サーバーを使用する場合は、LDAP ベンダーによって提供されているツールを使用して、ユーザーリポジトリの値の入力と管理を行います。また、ブローカが LDAP サーバーに対してユーザーおよびグループに関する情報を照会できるように、ブローカインスタンス設定ファイル内でプロパティーを設定する必要があります。
スケーラビリティーが重要な場合やさまざまなブローカでリポジトリを共有する必要がある場合は、LDAP オプションの方が適しています。ブローカクラスタを使用する場合などが、これに該当します。
認証と承認
クライアントがコネクションを要求する場合、ユーザー名とパスワードを入力する必要があります。ブローカは、指定されたユーザー名とパスワードをユーザーリポジトリ内に格納されているものと比較します。クライアントからブローカにパスワードが送信される場合、パスワードは、Base64 か、メッセージダイジェスト (MD5) ハッシュのどちらかを使用して暗号化されます。単層型ファイルリポジトリでは MD5 が使用され、LDAP リポジトリでは Base64 が必要です。LDAP を使用する場合は、セキュリティー保護された TLS プロトコルを使用する方がよいでしょう。ブローカのプロパティーを設定して各コネクションサービスで使用する暗号化のタイプを 1 つずつ設定するか、あるいはブローカ単位で暗号化を設定することができます。
ユーザーが何らかの操作を実行しようとすると、ブローカは、ユーザーリポジトリ内のユーザー名とグループのメンバーシップを、アクセス制御プロパティーファイル内にある、その操作へのアクセス権が与えられているユーザー名とグループのメンバーシップと照らし合わせます。アクセス制御プロパティーファイルでは、次の操作に対するユーザーまたはグループのアクセス権を指定します。
-
ブローカへの接続
-
送信先へのアクセス: 特定の送信先、またはすべての送信先に対してのコンシューマ、プロデューサ、またはキューブラウザの作成
-
送信先の自動作成
ブローカのプロパティーを設定して、次の情報を指定します。
暗号化
クライアントとブローカ間で送信されるメッセージを暗号化するには、 Secure Socket Layer (SSL) 標準に基づいたコネクションサービスを使用する必要があります。SSL は、SSL 対応のブローカとクライアント間で暗号化されたコネクションを確立して、コネクションレベルのセキュリティーを提供します。
ブローカのプロパティーを設定して、使用する SSL キーストアのセキュリティープロパティーおよびパスワードファイルの名前と場所を指定できます。
監視サービス
ブローカにはアプリケーションとブローカのパフォーマンスを監視および診断するコンポーネントが含まれています。たとえば、次のようなコンポーネントが含まれています。
-
データを生成するコンポーネント (イベントを記録するメトリックスジェネレータとブローカコード)。
-
多数の出力チャネルに対して情報を書き込むロガーコンポーネント。
-
メトリックス情報を含む JMS メッセージを、JMS 監視クライアントによってコンシュームさせるためにトピック送信先へ送るメッセージプロデューサ。
この仕組みの概略を、図 3–4 に示します。
図 3–4 監視サービスのサポート
メトリックスジェネレータ
メトリックスジェネレータは、ブローカとの間で入出力されるメッセージフロー、ブローカメモリー内のメッセージ数とそれらが消費するメモリー量、開かれているコネクションの数、使用中のスレッドの数など、ブローカの動作に関する情報を提供します。
ブローカのプロパティーを設定して、メトリックスデータの生成をオン、またはオフにすることも、メトリックスレポートを生成する頻度を指定することもできます。
ロガー
Message Queue のロガーは、ブローカコードとメトリックスジェネレータによって生成された情報を取得し、標準出力 (コンソール)、ログファイル、および SolarisTM プラットフォームではエラーの場合に syslog デーモンプロセスなどにそれらの情報を書き込みます。
ブローカのプロパティーを設定して、ロガーが収集する情報のタイプと、各出力チャネルに書き込む情報のタイプを指定できます。ログファイルに出力する場合、ログファイルを閉じて新しいファイルに出力がロールオーバーされる時点を指定できます。ログファイルが指定したサイズや有効期間に達すると、そのファイルは保存されて、新しいログファイルが作成されます。
ロガーの設定方法およびロガーによるパフォーマンス情報の入手方法についての詳細は 『Sun Java System Message Queue 3.7 UR1 管理ガイド』の「Configuring and Using Broker Logging」を参照してください。
メトリックスメッセージプロデューサ
図 3–4 に示すメトリックスメッセージプロデューサは、定期的にメトリックスジェネレータから情報を受け取り、その情報をメッセージに書き込みます。その後、そのメッセージは、メッセージに含まれるメトリックス情報のタイプに応じて、多数あるメトリックストピック送信先の 1 つに送信されます。
これらのメトリックストピック送信先にサブスクライブされた Message Queue クライアントは、メッセージをコンシュームし、メッセージに含まれるメトリックスデータを処理できます。これにより開発者は、カスタム監視ツールを作成してメッセージングアプリケーションをサポートできます。各タイプのメトリックスメッセージで報告されるメトリックスの数量についての詳細は『Sun Java System Message Queue 3.7 UR1 管理ガイド』の第 18 章「Metrics Reference」を参照してください。メトリックスメッセージのプロデュースの設定方法に関する詳細は、『Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients』の第 4 章「Using the Metrics Monitoring API」および『Sun Java System Message Queue 3.7 UR1 管理ガイド』の「Writing an Application to Monitor Brokers」を参照してください。
- © 2010, Oracle Corporation and/or its affiliates