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