キュー宛先のあるワークロード共有

区画に分割されたキュー宛先へのメッセージの送信

通常、単一のサーバーでキューのメッセージ処理負荷に対応できない場合に、スケーラブルなクラスター・バス・メンバーを作成して、 キュー宛先を区画に分割します。 効果的に使用するには、区画に分割されたキューで、複数のコンシューマーが必要です (少なくとも 1 つのコンシューマーが各区画からコンシュームしている状態にする必要があります)。 典型的な使用例としては、メッセージ駆動型 Beans (MDBs) の クラスターが挙げられます。 MDB がクラスター宛先からコンシュームする方法について詳しくは、 メッセージ駆動型 Bean がクラスター内で接続する方法を参照してください。

プロデューサー・アプリケーションが、キュー宛先をホストするクラスター・バス・メンバーのメッセージング・エンジンに接続されている場合の、メッセージング・システムのデフォルトの動作

デフォルトでは、プロデューサー・アプリケーションは、すべてのメッセージをローカル・キュー・ポイントに送信しようとします。 この動作により、メッセージがキュー・ポイントに到達するまでの距離を最小化することによって、メッセージ配信のパフォーマンスが最大化されます。

ローカル・キュー・ポイントが使用できない場合は、メッセージは、ローカル・キュー・ポイントが存在しないものとして処理されます。 キュー・ポイントは、以下の場合、新しいメッセージで使用できません。

• キュー・ポイントを所有するメッセージング・エンジンが使用できない (例: メッセージング・エンジンが停止している)。
• キュー・ポイントが最大メッセージしきい値に到達している。
• キュー・ポイントでメッセージを送信する機能が使用不可になっている。

プロデューサー・アプリケーションが、キュー宛先をホストしていないバス・メンバーのメッセージング・エンジンに接続されている場合の、メッセージング・システムのデフォルトの動作

デフォルトでは、メッセージング・システムのメッセージのワークロードは、複数の使用可能なキュー・ポイントで分散されます。

この図では、プロデューサー・アプリケーションは、キュー宛先をホストしていないバス・メンバーのメッセージング・エンジンに接続され、そのメッセージのワークロードは複数の使用可能なキュー・ポイント間で分散されます。

プロデューサー・アプリケーションが、キュー宛先をホストするバス・メンバーのメッセージング・エンジンに接続されている場合の、構成可能な動作

キュー・ポイントを持つメッセージング・エンジンに接続されている場合でも、プロデューサー・アプリケーションからのすべてのメッセージがキュー宛先のすべてのキュー・ポイントでワークロード・バランシングされるようにするには、メッセージ・プロデューサーでデフォルトの Prefer local queue point 構成オプションを無効にすることを検討してください。 このオプションは、JMS メッセージ・プロデューサー、および WebSphere® Application Server バージョン 7.0 以降を使用する外部バス接続からのインバウンド・メッセージで使用可能です。

この図では、プロデューサー・アプリケーションは、キュー宛先をホストするバス・メンバーのメッセージング・エンジンに接続されています。 プロデューサー・アプリケーションでは、 Prefer local queue point オプションが無効になっています。 メッセージのワークロードは、すべてのキュー・ポイントで分散されます。

ただし、バス・メンバー内のすべてのメッセージング・エンジンで多数のプロデューサー・アプリケーションの接続のワークロード・バランシングも行われる場合は、パフォーマンス上の理由から、デフォルトの Prefer local queue point 動作を保持することを検討してください。 これは、デフォルトの動作が以下のとおりであるからです。

• すべてのプロデューサー・アプリケーションからのメッセージのワークロードをすべてのキュー・ポイントで分散する
• 接続されたメッセージング・エンジンからのメッセージを同じクラスター・バス・メンバー内の別のメッセージング・エンジンに送信する必要が最小化する

プロデューサー・アプリケーションが、キュー宛先をホストしていないクラスター・バス・メンバーのメッセージング・エンジンに接続されている場合の、構成可能な動作

アプリケーション・プロデューサーの単一セッション中に生成されたすべてのメッセージを同じキュー・ポイントに送信する場合は、 Message affinityを構成できます。 その場合、メッセージのワークロードは、複数のキュー・ポイントで分散されなくなります。

コンシューマーの単一インスタンスによって順番に処理される同じキュー・ポイントにメッセージ・セットを送信する場合は、アプリケーション用に Message affinity を構成することを検討してください。 システムは、そのアプリケーション・プロデューサーの Prefer local queue point 構成オプションに基づいて、すべてのメッセージの送信先となる単一キュー・ポイントを選択します。 このオプションは、JMS メッセージ・プロデューサー、および WebSphere Application Server バージョン 7.0 以降を使用する外部バス接続からのインバウンド・メッセージで使用可能です。

この図では、プロデューサー・アプリケーションは、キュー宛先をホストしていないバス・メンバーのメッセージング・エンジンに接続します。 プロデューサー・アプリケーションには、メッセージ・アフィニティーが構成されています。 すべてのメッセージは、1 つのキュー・ポイントに送信されます。

選択したキュー・ポイントが使用できなくなると、このアプリケーションから送信されたそれ以降のメッセージは、 選択したキュー・ポイントに転送中のキューに入れられるか、送信操作が拒否されます。 この動作は、単一のキュー・ポイントを持つキュー宛先にメッセージを送信する場合と同じです。

区画に分割されたキュー宛先からのメッセージのコンシューム

コンシューマー・ セッションが作成されると、コンシューマーは宛先のいずれかの区画に関連 付けられます。 コンシューマーが、宛先のローカル区画を 備えたメッセージング・エンジンに接続 している場合、コンシューマーはその区画に関連付けられます。 コンシューマーが、 宛先の区画を持たないメッセージング・エンジンに 接続している場合、コンシューマーはワークロード・マネージャーによって 動的に選択される別のメッセージング・エンジン内の 区画に関連付けられます。 関連づけが行われると、コンシューマーは関連付けられた 区画からのみメッセージを受け取ります。 デフォルトでは、コンシューマーが関連付けられた区画に メッセージがない場合、コンシューマーは代替区画からメッセージを受け取りません。 そのような代替区画にメッセージが含まれている場合でもメッセージを受け取り ません。

区画に分割された宛先を、 ローカル・コンシューマーを備えていないクラスターに構成する場合、 すべてのメッセージが使用されるように、宛先の区画ごとに少なくとも 1 つ のコンシューマーを配置することが重要です。 これは、個々のコンシューマーが、キュー・ポイントを持つ特定のメッセージング・エンジンに接続するようにさせることによって実現できます。 MDB は、特定のタイプのメッセージ・コンシューマーです。 パーティション化された宛先からコンシュームする場合の動作について詳しくは、 メッセージ駆動型 Bean がクラスター内で接続する方法を参照してください。

コンシューマーが、 宛先の使用可能なすべてのキュー・ポイントからメッセージを受信する必要がある場合は、 メッセージ・コンシューマーを構成します。

容量の小さなメッセージが多数あり、 MDB が少量の処理しか実行しない場合は、このトピックの説明に従って、ワークロード・バランスのとれたメッセージング・エンジンを、分割キューと同時に使用することができます。 ただし、MDB が数は少なく処理量が多いようなメッセージの処理を実行する場合は、メッセージング・エンジンは 1 つあればよいのですが、MDB をできるだけ多くのサーバーにデプロイする必要があります。 その際、それらのサーバーにメッセージング・エンジンがあるかないかには関係なく、それらのサーバーが同じセルのメンバーでなくてもかまいません。 代表的なのは、MDB がユーザー・データベースを更新する場合です。 複数のサーバーにわたる MDB デプロイメントの構成について詳しくは、 デフォルト・メッセージング・プロバイダーの MDB スロットルの構成を参照してください。

コンシューマーが分割宛先からコンシュームする場合のメッセージング・システムのデフォルトの動作

コンシューマー・アプリケーションのセッションが作成されると、そのセッションは、キュー定義のキュー・ポイントのいずれかに関連付けられます。 キュー宛先に複数のキュー・ポイントがある場合には、システムによって選択されます。 デフォルトでは、メッセージング・システムは、コンシューマーを、接続されているメッセージング・エンジン上のローカル・キュー・ポイントに関連付けようとします。 接続されているメッセージング・エンジン上に使用可能なローカル・キュー・ポイントがない場合、システムは、重み付きラウンドロビン・アルゴリズムを使用する WebSphere Application Server ワークロード・マネージャーを使用して、別のキューを選択します。

デフォルトの動作は、コンシューマーが使用できるメッセージを、コンシューマーに関連付けられたキュー・ポイント上のメッセージに制限することによって、キュー・ポイントからのメッセージ消費のパフォーマンスを最大限にしようとします。 関連付けられたキュー・ポイントにメッセージが存在せず、別のキュー・ポイントにメッセージが存在している場合でも、 コンシューマーは、他のキュー・ポイントからのメッセージをコンシュームすることはできません。

この図では、コンシューマー・アプリケーションは、ローカル・キュー・ポイントを持たないメッセージング・エンジンに接続されています。 1 つの関連付けられたキュー・ポイントからのメッセージのみがコンシュームされます。

コンシューマーが分割宛先からコンシュームする場合のメッセージング・システムの構成可能な動作

関連付けられたキュー・ポイントが宛先のすべての使用可能なキュー・ポイントからメッセージを収集して、そのメッセージをコンシューマーが見られるように、メッセージ・コンシューマーを構成することができます。

コンシューマーがパーティション化されたキューをパーティション化されていないキューとして扱うようにする場合は、 Message gathering を構成することを検討してください。 ただし、複数のキュー・ポイントからのメッセージの収集の場合、単一のキュー・ポイントからのコンシュームに比べて、動作速度が大幅に遅くなります。 そのため、可能な限り、宛先が単一のキュー・ポイントを持つように再構成するか、別名宛先を使用してメッセージのプロデューサーとコンシューマーを単一のキュー・ポイントに制限してください。 複数のキュー・ポイントのスケーラビリティーが必要で、パフォーマンスが重要な場合には、 メッセージの収集の代替ソリューションを検討してください。

Message gathering 操作モードでは、コンシューマーは、キュー・ポイントに保持されている順序でメッセージを表示しない場合があります。 そのため、メッセージの順番は保持されません。

このオプションは、JMS メッセージ・プロデューサー、および WebSphere Application Server バージョン 7.0 以降を使用する外部バス接続からのインバウンド・メッセージで使用できます。

この図では、コンシューマー・アプリケーションは、ローカル・キュー・ポイントを持たないメッセージング・エンジンに接続します。 コンシューマー・アプリケーションでは、メッセージの収集が使用可能になっています。 関連キュー・ポイントは、宛先のすべての使用可能なキュー・ポイントからメッセージを収集して、コンシューマーで使用できるようにします。