|
| |
| Sun Java System Message Queue 3 2005Q1 技術の概要 | |
第 4 章
メッセージサーバー「メッセージサーバー」で紹介されている Message Queue メッセージサーバーは、メッセージのルーティングと配信を実行する、1 つのブローカまたは協調動作するブローカセット (ブローカクラスタ) で構成されています。
この章では、ブローカの内部構造について解説し、ブローカのさまざまなコンポーネントについて述べ、開発環境と運用環境でブローカを設定および管理するために必要なステップについて概要を示します。この章は以下の節で構成されています。
ブローカの機能要素について理解すれば、必要なブローカの動作を設定し、動作を拡張し、パフォーマンスを最適化しやすくなります。そのためこの章は、アプリケーション開発者よりも管理者向けの内容になっています。
ブローカのアーキテクチャメッセージ配信を実行するため、ブローカは、クライアントとの通信チャネルの設定、認証と承認、適切なメッセージルーティング、信頼性の高い配信の保証、およびシステムパフォーマンスを監視するためのデータの提供を行う必要があります。
この複合的なな機能の組み合わせを実行するために、ブローカはさまざまな内部コンポーネントを使用します。各コンポーネントには、配信プロセスにおける特定のロールが割り当てられています。図 4-1 にブローカのコンポーネントを、表 4-1 にはそれらのコンポーネントの概要を示します。メッセージルーターコンポーネントがメッセージルーティングと配信サービスを主に実行し、それ以外のコンポーネントは、メッセージルーターが依存する重要なサポートサービスを提供しています。
図 4-1 ブローカのコンポーネント
ブローカを設定する場合は、負荷状態やアプリケーションの複雑さなどに応じて、実際にはこれらのサービスを設定してブローカのパフォーマンスを最適化していることになります。
ブローカのコンポーネント以下の節では、図 4-1 に示すブローカの各コンポーネント、コンポーネントの機能、およびコンポーネントの動作について説明します。それぞれのプロパティと設定手順については、『Message Queue 管理ガイド』を参照してください。
コネクションサービス
Message Queue ブローカは、アプリケーションクライアントと管理クライアントの両方との通信をサポートしています。各コネクションサービスは、サービスタイプとプロトコルタイプで指定されます。
サービスタイプ サービスが、JMS メッセージ配信サービス (NORMAL) を提供するのか、管理ツールをサポートする Message Queue 管理サービス (ADMIN) を提供するのかについて指定します。
プロトコルタイプ サービスをサポートする基礎となるトランスポートプロトコルレイヤーを指定します。
Message Queue ブローカで現在使用できるコネクションサービスを、表 4-2 に示します。
ブローカを設定して、これらのコネクションサービスの一部、またはすべてを実行することができます。各コネクションサービスは、特定の認証および承認 (アクセス制御) 機能をサポートします (「セキュリティマネージャ」を参照)。各コネクションサービスは、複数のコネクションをサポートするマルチスレッドです。
各コネクションサービスは、ブローカのホスト名とポート番号で指定した特定のポートで使用できます。ポートを動的に割り当てることもできれば、コネクションサービスが使用可能なポートを指定することもできます。この仕組みの概略を、図 4-2 に示します。
図 4-2 コネクションサービスのサポート
ポートマッパー
コネクションサービスには、共通ポートマッパーによりポートが割り当てられます。ポートマッパー自体は、標準のポート番号 7676 に常駐します。Message Queue クライアントランタイムは、ブローカとの間でコネクションを設定する場合、最初にポートマッパーに接続し、必要とするコネクションサービスのポート番号を要求します。
ポートマッパーは、jms、ssljms、admin、および ssladmin の各コネクションサービスの設定時に、静的なポート番号を割り当てることによってオーバーライドできます。ただし、静的ポートは通常、ファイアウォールを通してコネクションを確立する場合のように特殊な状況でのみ使用され (「HTTP/HTTPS サポート」を参照)、一般的にはお勧めしません。
スレッドプールマネージャ
各コネクションサービスは、複数のコネクションをサポートするマルチスレッドです。これらのコネクションに必要なスレッドは、スレッドプールマネージャのコンポーネントが管理するスレッドプールに保存されます。スレッドプールマネージャを設定して、スレッドプールに保持されるスレッドの最小数と最大数を指定することができます。コネクションでスレッドが必要になると、スレッドプールにスレッドが追加されます。スレッドの最小数より少なくなると、システムは最小数のしきい値になるまでスレッドをシャットダウンして、スレッドを解放します。これによってメモリーのリソースが節約されます。スレッドプール内のスレッドは、1 つのコネクションだけに割り当てるか、必要に応じて、複数のコネクションに割り当てることができます。
HTTP/HTTPS サポート
HTTP/HTTPS サポートにより、Message Queue クライアントは、直接 TCP コネクションを使用する代わりに HTTP プロトコルを使用してブローカと通信できます。クライアントをファイアウォールによってブローカと分離する必要がある場合、ファイアウォールを通しての通信が可能なので HTTP/HTTPS サービスを使用できます。
図 4-3 に、HTTP/HTTPS サポートの提供に関連する主なコンポーネントを示します。
図 4-3 HTTP/HTTPS サポートのアーキテクチャ
- Message Queue クライアント側では、HTTP または HTTPS の転送ドライバが MJS メッセージを HTTP 要求にカプセル化し、これらの要求が正しい順序で Web サーバーに確実に送信されるようにします。
- クライアントは、HTTP プロキシサーバーをオプションで使用して、必要に応じて Web サーバーとやり取りできます。
- HTTP または HTTPS トンネルサーブレット (どちらも Message Queue にバンドルされている) は、Web サーバーに読み込まれ、JMS メッセージがブローカに転送される前に、その JMS メッセージをクライアント HTTP 要求から取り出します。HTTP/HTTPS トンネルサーブレットも、ブローカ応答をクライアントに返信します。1 つの HTTP/HTTPS トンネルサーブレットを使用して、複数のブローカにアクセスできます。
- ブローカ側では、ブローカの起動時に、トンネルサーブレットへのブローカコネクションが確立されます。メッセージが HTTP または HTTPS トンネルサーブレットから送信されるとき、httpjms または httpsjms コネクションサービスは、それぞれメッセージのラップを解除し、ブローカのメッセージルーターコンポーネントにサブミットします。
図 4-3 に示す HTTP と HTTPS のアーキテクチャは、非常によく似ています。主な相違点は、HTTPS (httpsjms コネクションサービス) の場合、トンネルサーブレットにクライアントとブローカの両方へのセキュリティ保護されたコネクションがあることです。
Message Queue の HTTPS トンネルサーブレットは、自己署名証明書を、コネクションを要求している任意のブローカに渡します。ブローカは証明書を使用して、HTTPS トンネルサーブレットへの暗号化されたコネクションを設定します。このコネクションが確立されれば、Message Queue クライアントとトンネルの間の安全なコネクションをネゴシエーションできます。
httpjms サービスと httpsjms サービスは、『Message Queue 管理ガイド』で説明されるプロパティを使用して設定されます。
メッセージルーター
サポートされているコネクションサービスを使用して、クライアントとブローカ間でコネクションが確立されると、メッセージのルーティングおよび配信が処理できます。
Message Queue のメッセージングは、メッセージの 2 段階配信を前提としています。まず、プロデューシングクライアントからブローカの物理的送信先に、次にブローカの物理的送信先から 1 つ以上のコンシューミングクライアントに送られます。メッセージルーターは、適切な送信先に到着したメッセージを収容し、その後適切なコンシューマにメッセージをルーティングして配信するプロセスを管理します。
この節では、さまざまな種類の送信先およびそれらの送信先のメモリーリソース管理について、個別に、および総合的に説明します。メッセージのルーティングと配信のメカニズムについては、第 3 章「信頼性の高いメッセージ配信」を参照してください。
物理的な送信先
物理的な送信先は、受信メッセージがコンシューミングクライアントにルーティングされる前に、着信メッセージを保管するブローカの物理メモリーの場所を表しています。
送信先は、作成方法と作成目的に応じて、管理者作成、自動作成、一時、デッドメッセージキューなどの多くのカテゴリに分類されます。
管理者作成の送信先
管理者作成の送信先は、Message Queue 管理ツールを使用して管理者が作成します。この送信先は、プログラムによって作成される論理的な送信先か、クライアントが検索する送信先管理対象オブジェクトのどちらかに対応します。
Message Queue メッセージサーバーは、メッセージングシステムの中心的なハブなので、そのパフォーマンスと信頼性はエンタープライズアプリケーションの成功にとって重要です。送信先は、送信先が処理するメッセージの数とサイズ、および登録するメッセージコンシューマの数と永続性によっては、リソースを著しくコンシュームする可能性があるので、メッセージサーバーのパフォーマンスと信頼性を確保するために、送信先を綿密に管理する必要があります。したがって、アプリケーションのための送信先の作成、送信先の監視、必要に応じたリソース要件の再構成が、管理者の基本的な業務になります。
自動作成の送信先
自動作成の送信先は、管理者の介入なしに、必要に応じてブローカが自動的に作成します。特に、自動作成の送信先は、メッセージコンシューマまたはメッセージプロデューサが、存在しない送信先へのアクセスを試みる場合にはいつでも作成されます。自動作成の送信先は、一般に開発とテストサイクルの期間に、送信先を動的に作成する必要がある場合に使用されます。自動作成機能を有効または無効にするように、ブローカを設定することができます。
送信先が自動的に作成されると、同じ送信先名を使用する異なるクライアントアプリケーションどうしの間でクラッシュが発生したり、送信先をサポートするために必要なリソースによってシステムのパフォーマンスが低下したりする可能性があります。このため、自動作成された送信先は、それ以降使用されない状態、つまり、それ以降メッセージコンシューマクライアントを保持せず、メッセージを一切含まない状態になると、ブローカによって自動的に破棄されます。ブローカが再起動すると、持続メッセージが含まれている場合にだけ、自動作成された送信先が再び作成されます。
一時送信先
一時送信先は、ほかのクライアントに送信したメッセージに対する応答を受信するために送信先が必要な場合に、クライアントが JMS API を使用して明示的に作成および破棄します。これらの送信先は、送信先が作成されたコネクションの存続期間中にだけ、ブローカによって保持されます。管理者が一時送信先を破棄することはできません。また、一時送信先が使用されている間、つまりアクティブなメッセージコンシューマの場合は、クライアントアプリケーションによって破棄されることもありません。管理者が作成した送信先や自動作成された送信先 (持続メッセージを保持する) と違って、一時送信先は、継続的には格納されず、ブローカの再起動時に作成し直されることもありません。ただし、Message Queue 管理ツールからは認識できます。
デッドメッセージキュー
デッドメッセージキューは、ブローカの起動時に自動的に作成される特殊な送信先で、診断用のデッドメッセージを保管するために使用します。デッドメッセージは、通常の処理または明示的な管理操作以外の理由でシステムから削除されるメッセージです。メッセージは、有効期限が切れたり、メモリー限界を上回るために送信先から削除されたり、配信処理に失敗したりしたときにデッドメッセージと見なされます。
メッセージは、次の 2 つの方法でデッドメッセージキューに入れることができます。
メッセージをデッドメッセージキューに入れると、追加のプロパティ情報がそのメッセージに書き込まれ、デッドメッセージになった原因に関する情報が残されます。
メモリーリソース管理
メッセージサーバーには、メモリーや CPU サイクルなどのリソースにおいて制限があります。そのためメッセージサーバーは、ブローカがサポートするメッセージングアプリケーションの使用方法に応じて、応答しなくなったり安定性を失ったりするほどの過負荷状態に陥る可能性があります。これは特に、送信先へのメッセージのプロデュース速度が、コンシューム速度よりはるかに速い場合に問題になります。
メッセージルーターには、メモリーリソースを管理し、ブローカのメモリー不足を防ぐためのメカニズムが組み込まれています。この場合ルーターは、送信先のメッセージ制限、システム全体の制限、およびシステムメモリーのしきい値という 3 つのメモリー保護レベルを使用して、リソースが少なくなったときにもシステムの動作を維持します。
送信先のメッセージ制限
メッセージは長期間送信先に残ることがあるので、メモリーリソースが問題になる可能性があります。送信先に割り当てるメモリーが多すぎると、システムメモリーのサイズが制限され、少なすぎると、メッセージが拒否されます。
各送信先の負荷要求に基づいて柔軟な対応ができるようにするため、各送信先のメモリーリソースとメッセージフローを管理するプロパティを設定できます。たとえば、送信先で許容されるプロデューサの最大数、送信先で許容されるメッセージの最大数 (または、サイズ)、および任意のメッセージの最大サイズを指定できます。
また、これらの制限値に達したときにメッセージルーターが示す応答を、4 つの応答方法から指定することもできます。4 種類の制限の動作は次のとおりです。
システム全体のメッセージ制限
システム全体のメッセージ制限は、第 2 の保護手段です。システム全体の制限を指定すると、ブローカのすべての送信先に対して一括して適用され、メッセージの総数とすべてのメッセージによって使用される総メモリー量が制限されます。どちらかのシステム全体のメッセージ制限に達した場合、メッセージルーターは新しいメッセージを拒否します。
システムメモリーのしきい値
システムメモリーのしきい値は、第 3 の保護手段です。ブローカがさらに深刻な状況に陥ったときに、メモリーの過負荷を避けるためのアクションを実行できるように、使用可能なシステムメモリーのしきい値を指定できます。実行するアクションは、green (使用可能なメモリーが十分にある)、yellow (ブローカのメモリーが減っている)、orange (ブローカのメモリーが不十分である)、red (ブローカのメモリーが不足している) といったメモリーリソースの状態によって異なります。ブローカのメモリーの状態が green から yellow、orange、red へと進むにつれ、ブローカは次のタイプの本格的なアクションを段階的に実行します。
これらのアクションはどちらもパフォーマンスを低下させます。
システムメモリーのしきい値に達した場合は、送信先ごとのメッセージ制限とシステム全体のメッセージ制限が適切に設定されていません。場合によっては、潜在するメモリーの過負荷をしきい値がタイミングよく指摘できないことがあります。したがって、この機能に依存せず、代わりに送信先を個別および全体的に設定して、メモリーリソースを最適化してください。
注意深い監視と調整により、送信先ベースの制限と動作を使用して、システムが過負荷にならないようにメッセージの受信と送信のバランスを取ることができます。これらのメカニズムは、オーバーヘッドを増加させ、メッセージのスループットを制限することがありますが、それでも動作の完全性を維持します。
持続マネージャ
障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。この場合、ブローカは、すべての持続メッセージを重要な転送情報および配信情報とともにデータストアに保存する必要があります。復元するには、ブローカが次のタスクも実行する必要があります。
持続マネージャは、このすべての状態情報の格納および検索を管理します。
ブローカは、再起動すると、持続マネージャによって管理されるデータを使用して送信先と永続サブスクリプションを再作成し、持続メッセージを復元し、開いているトランザクションをロールバックし、未配信メッセージのルーティングテーブルを再作成します。その後ブローカは、メッセージの配信を再開します。
Message Queue は、組み込み持続モジュールとプラグイン持続モジュールの両方をサポートしています (図 4-4 を参照)。組み込み持続は、ファイルベースのデータストアです。プラグイン持続は、JDBC (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアを必要とします。通常、組み込み持続の方が、プラグイン持続より処理速度が速くなりますが、JDBC 互換のデータベースシステムによる冗長性および管理制御を好むユーザーもいます。
図 4-4 持続マネージャのサポート
組み込み持続性 デフォルトの Message Queue 持続ストレージソリューションは、ファイルベースのデータストアで、個々のファイルを使用して持続データを保存します。メッセージが追加および削除されたときの断片化を減らすために、ファイルベースのデータストアを圧縮できます。信頼性を最大にするため、持続操作によりメモリー内の状態と物理的なストレージとを同期するように指定できます。この同期化により、システム破壊によるデータの損失をなくすことができますが、パフォーマンスが低下します。データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが格納されることがあるため、権限のないアクセスからデータストアのファイルを保護してください。
プラグイン持続 JDBC ドライバを介してアクセスが可能な任意のデータストアにアクセスするように、ブローカを設定することができます。この作業では、さまざまな JDBC 関連ブローカ設定プロパティを設定し、Message Queue Database Manager ユーティリティを使用し、適切なスキーマでデータストアを作成します。手順および関連する設定プロパティについての詳細は、『Message Queue 管理ガイド』を参照してださい。
セキュリティマネージャ
Message Queue では、認証および承認 (アクセス制御) 機能が用意されており、暗号化機能もサポートされています。
認証機能と承認機能はユーザーリポジトリによって異なります (図 4-5 を参照)。ユーザーリポジトリとしては、メッセージングシステムのユーザーに関する情報 (名前、パスワード、グループメンバーシップなど) を含むファイル、ディレクトリ、またはデータベースがあります。ユーザー名とパスワードはブローカへのコネクションが要求されたときに、ユーザーを認証するために使用されます。ユーザー名とグループのメンバーシップは、送信先のプロデューシングメッセージ、またはコンシューミングメッセージなどの操作を承認するために、アクセス制御ファイルと一緒に使用されます。
Message Queue 提供のユーザーリポジトリに値を入力するか、前から存在する LDAP ユーザーリポジトリをブローカにプラグインすることができます。単層型ファイルのユーザーリポジトリは容易に使用できますが、セキュリティ攻撃に対して脆弱なため、評価および開発を目的とする場合にだけ使用してください。LDAP ユーザーリポジトリはセキュリティ保護されているので、プロデュース目的に最適です。
以下の項では、認証、承認、および暗号化について説明します。詳細は、『Message Queue 管理ガイド』を参照してください。
認証
Message Queue のセキュリティは、パスワードベースの認証がサポートしています。クライアントがブローカへのコネクションを要求する場合、ユーザー名とパスワードを入力する必要があります。セキュリティマネージャは、クライアントから提示されたユーザー名とパスワードをユーザーリポジトリ内に格納されているものと比較します。クライアントからブローカにパスワードが送信される場合、パスワードは、Base-64 か、メッセージダイジェスト (MD) のどちらかを使用して暗号化されます。セキュリティ保護された送信については、「暗号化」を参照してください。各コネクションサービスで使用する暗号化のタイプを 1 つずつ設定するか、あるいはブローカ単位で暗号化を設定することができます。
承認
クライアントアプリケーションのユーザーが認証されると、ユーザーはさまざまな Message Queue 関連のアクティビティを実行することを承認されます。セキュリティマネージャは、ユーザーベースとグループベースの両方のアクセス制御をサポートしています。ユーザー名、またはユーザーリポジトリでユーザーに割り当てられているグループに応じて、ユーザーは特定の Message Queue 操作を実行するためのアクセス権を付与されます。これらのアクセス制御は、アクセス制御プロパティファイルで指定します (図 4-5 を参照)。
図 4-5 セキュリティマネージャのサポート
ユーザーが何らかの操作を実行しようとすると、セキュリティマネージャは、ユーザーリポジトリ内のユーザー名とグループのメンバーシップを、アクセス制御プロパティファイル内にある、その操作へのアクセス権が与えられているユーザー名とグループのメンバーシップと照らし合わせます。アクセス制御プロパティファイルでは、次の操作に対するアクセス権を指定します。
グループを定義し、ユーザーリポジトリ内のそれらのグループとユーザーを関連付けることができます。ただし、グループは単層型ファイルのユーザーリポジトリで完全にはサポートされません。次に、アクセス制御プロパティファイルを編集することにより、ユーザーまたはグループがアクセスしてプロデュース、コンシューム、またはブラウズできる送信先を指定できます。個々の送信先、またはすべての送信先を、特定のユーザーまたはグループだけがアクセスできるようにすることも可能です。
さらに、ブローカを設定して、送信先の自動作成 (「自動作成の送信先」を参照) を許可する場合、ブローカが送信先を自動作成するユーザーを、アクセス制御プロパティファイルを編集して管理することができます。
暗号化
クライアントとブローカ間で送信されるメッセージを暗号化するには、SSL (Secure Socket Layer) 標準に基づいたコネクションサービスを使用する必要があります。SSL は、SSL 対応のブローカとクライアント間で暗号化されたコネクションを確立して、コネクションレベルのセキュリティを提供します。
監視サービス
ブローカには、ブローカの動作を監視および診断するためのさまざまなコンポーネントが用意されています。たとえば、次のようなコンポーネントが含まれています。
この仕組みの概略を、図 4-6 に示します。
メトリックスジェネレータ
図 4-6 に示すメトリックスジェネレータは、ブローカとの間で入出力されるメッセージフロー、ブローカメモリー内のメッセージ数とそれらが消費するメモリー量、開かれているコネクションの数、使用中のスレッドの数など、ブローカの動作に関する情報を提供します。
メトリックスデータの生成をオン、またはオフにすることも、メトリックスレポートを生成する頻度を指定することもできます。
図 4-6 監視サービスのサポート
ロガー
図 4-6 に示す Message Queue のロガーは、ブローカコードとメトリックスジェネレータによって生成された情報を取得し、標準出力 (コンソール)、ログファイル、および SolarisTM プラットフォームでは syslog デーモンプロセスなどの多くの出力チャネルにそれらの情報を書き込みます。
ロガーが収集する情報のタイプと、各出力チャネルに書き込む情報のタイプを指定できます。ログファイルに出力する場合、ログファイルを閉じて新しいファイルに出力がロールオーバーされる時点を指定できます。ログファイルが指定したサイズや有効期間に達すると、そのファイルは保存されて、新しいログファイルが作成されます。
ロガーの設定方法およびロガーによるパフォーマンス情報の入手方法についての詳細は、『Message Queue 管理ガイド』を参照してください。
メトリックスメッセージプロデューサ (Enterprise Edition)
図 4-6 に示すメトリックスメッセージプロデューサのコンポーネントは、定期的にメトリックスジェネレータのコンポーネントから情報を受け取り、その情報をメッセージに書き込みます。その後、そのメッセージは、メッセージに含まれるメトリックス情報のタイプに応じて、多数あるメトリックストピック送信先の 1 つに送信されます。
これらのメトリックストピック送信先にサブスクライブされた Message Queue クライアントは、送信先内のメッセージをコンシュームし、メッセージに含まれるメトリックス情報を処理できます。これにより開発者は、カスタム監視ツールを作成してメッセージングアプリケーションをサポートできます。各タイプのメトリックスメッセージで報告されるメトリックスの数量についての詳細は、Message Queue クライアントを開発してメトリックスメッセージをコンシュームする方法について説明した、『Message Queue Developer's Guide for Java Clients』を参照してください。メトリックスメッセージのプロデュースの設定方法に関する詳細は、『Message Queue 管理ガイド』を参照してください。
開発環境と運用環境メッセージングアプリケーションを開発およびテストし、運用環境にそれらのアプリケーションを配備して管理するには、Message Queue サービスによって提供されるメッセージングインフラストラクチャが必要です。
この節では、開発環境と運用環境で Message Queue を使用する場合の異なる手法を紹介します。次のトピックが含まれます。
運用環境とタスクを設定および管理する責任が委ねられているのは管理者ですが、運用環境の各部を設定および構成し、クライアントが期待通りに動作するかどうかを判断するために必要な情報を管理者に提供するために、運用環境について理解することは開発者にとっても重要です。
開発環境とタスク
開発環境では、作業は Message Queue のクライアントアプリケーションのプログラミングに重点が置かれます。Message Queue サービスは、主にテストのために必要となります。
出荷状態の設定
Message Queue 製品は、出荷状態で使用できるように設計されています。デフォルト値でブローカを起動すれば、デフォルトのデータストア、ユーザーリポジトリ、およびアクセス制御プロパティファイルを使用することができます。
デフォルトのユーザーリポジトリは、デフォルトエントリと一緒に作成され、管理者による介入なしでインストール後すぐに Message Queue ブローカを使用できます。言い換えれば、ユーザーやパスワードの初期設定を行わなくても、ブローカを使用することができます。デフォルトのユーザー名 (guest) とパスワード (guest) を使用して、クライアントユーザーを認証できます。
サンプルアプリケーションも数多く用意されているので、これを利用して新規アプリケーションを開発できます。
開発手法
開発環境では、柔軟性が重視され、通常は次の手法を取り入れます。
- 開発者がテストで使用するブローカを起動する程度に、管理の手間を最小限に抑えます。
- データストア (ファイルベースの組み込み持続)、ユーザーリポジトリ (ファイルベースのユーザーリポジトリ)、アクセス制御プロパティファイルのデフォルトの環境を使用します。通常の開発テストでは、これらのデフォルトの実装で十分です。
- 目的に合ったディレクトリを作成することにより、単純なファイルシステムオブジェクトストアを使用してそこに管理対象オブジェクトを保管するか、クライアントコードの管理対象オブジェクトをインスタンス化してオブジェクトストアをまったく使用しないようにします。
- 複数のブローカのテストを実行する場合は、マスターブローカを使用しません (「クラスタの同期化」を参照)。
- 一般に、明示的に作成した送信先ではなく、自動作成された送信先を使用します。
運用環境とタスク
運用環境では、アプリケーションを配備、管理、および調整して、最大限のパフォーマンスを引き出す必要があります。そのような状況では、メッセージングインフラストラクチャの管理と調整は、必要不可欠ではないとしても、重要な要件となります。
また、導入段階では、スケーラビリティと可用性の両方における企業の要件に対応する必要があります。これには、メッセージサービスのカスタマイズされた設定とセットアップ、パフォーマンスの調整とシステムの拡張による増大する負荷への対処、およびメッセージサービスリソースとアプリケーション固有リソースの両方に対する毎日の監視と管理の実行が必要です。したがって管理タスクは、メッセージングシステムの複雑さとメッセージングシステムがサポートするアプリケーションの複雑さによって異なります。以下の節では、管理タスクをセットアップ操作とメンテナンス操作に分類しています。これらのタスクを実行するために要求される手順については、『Message Queue 管理ガイド』を参照してください。
セットアップ操作
運用環境では、セキュリティ保護アクセスのセットアップ、コネクションファクトリと送信先オブジェクトの設定、クラスタのセットアップ、持続ストアの設定、およびメモリー管理を行う必要があります。
運用環境を設定するには
通常、次のセットアップ操作のうち少なくとも一部を実行する必要があります。
メンテナンス操作
運用環境では、Message Queue メッセージサーバーのリソースを監視および制御する必要があります。アプリケーションのパフォーマンス、信頼性、およびセキュリティが重視されるため、次に示すさまざまな運用タスクを Message Queue の管理ツールを使用して実行する必要があります。
運用環境を設定するには
