キュー宛先のあるワークロード共有
サーバー・クラスターをサービス統合バスに追加して、1 つ以上のメッセージング・エンジンをそのクラスターにデプロイすると、 スケーラビリティーのためにクラスター・バス・メンバーを構成することができます。クラスター・バス・メンバーのメッセージング・エンジンは、 そのクラスターにデプロイされたキュー宛先に関連したメッセージング・ワークロードを共有します。
ワークロードを共有するメッセージング・エンジンの 構成について詳しくは、サービス統合の高可用性とワークロード共有構成を参照してください。
- クラスター内にメッセージング・エンジンが 1 つだけ存在する場合、 宛先はそのメッセージング・エンジンによってローカライズされます。 宛先は分割されません。
- クラスター内に複数のメッセージング・エンジンが存在する場 合、宛先はクラスター内のすべてのメッセージング・エンジンで分割されます。各メッセージング・エンジンは、 その宛先で処理されるメッセージのサブセットを扱います。
区画に分割されたキュー宛先へのメッセージの送信
通常、単一のサーバーでキューのメッセージ処理負荷に対応できない場合に、スケーラブルなクラスター・バス・メンバーを作成して、 キュー宛先を区画に分割します。 効果的に使用するには、区画に分割されたキューで、複数のコンシューマーが必要です (少なくとも 1 つのコンシューマーが各区画からコンシュームしている状態にする必要があります)。 典型的な使用例としては、メッセージ駆動型 Beans (MDBs) の クラスターが挙げられます。MDB がクラスター化された宛先からコンシュームする方法の詳細については、 メッセージ駆動型 Bean がクラスター内で接続する方法を参照してください。
- プロデューサー・アプリケーションが、キュー宛先をホストするクラスター・バス・メンバーのメッセージング・エンジンに接続されている場合の、メッセージング・システムのデフォルトの動作
デフォルトでは、プロデューサー・アプリケーションは、すべてのメッセージをローカル・キュー・ポイントに送信しようとします。 この動作により、メッセージがキュー・ポイントに到達するまでの距離を最小化することによって、メッセージ配信のパフォーマンスが最大化されます。
図 1. デフォルトの動作: メッセージはローカル・キュー・ポイントに送信されるローカル・キュー・ポイントが使用できない場合は、メッセージは、ローカル・キュー・ポイントが存在しないものとして処理されます。 キュー・ポイントは、以下の場合、新しいメッセージで使用できません。- キュー・ポイントを所有するメッセージング・エンジンが使用できない (例: メッセージング・エンジンが停止している)。
- キュー・ポイントが最大メッセージしきい値に到達している。
- キュー・ポイントでメッセージを送信する機能が使用不可になっている。
- プロデューサー・アプリケーションが、キュー宛先をホストしていないバス・メンバーのメッセージング・エンジンに接続されている場合の、メッセージング・システムのデフォルトの動作
デフォルトでは、メッセージング・システムのメッセージのワークロードは、複数の使用可能なキュー・ポイントで分散されます。
この図では、プロデューサー・アプリケーションは、キュー宛先をホストしていないバス・メンバーのメッセージング・エンジンに接続され、そのメッセージのワークロードは複数の使用可能なキュー・ポイント間で分散されます。
図 2. デフォルトの動作: メッセージのワークロードはすべてのキュー・ポイントで分散される
- プロデューサー・アプリケーションが、キュー宛先をホストするバス・メンバーのメッセージング・エンジンに接続されている場合の、構成可能な動作
キュー・ポイントがあるメッセージング・エンジンに接続されている場合でも、 プロデューサー・アプリケーションからのすべてのメッセージのワークロードを、キュー宛先のすべてのキュー・ポイントで分散する場合は、メッセージ・プロデューサーのデフォルトの「ローカル・キュー・ポイントの優先」構成オプションを使用不可にすることを検討してください。 このオプションは、WebSphere® Application Server バージョン 7.0 以降 を使用する JMS メッセージ・プロデューサーおよび外部バス接続経由インバウンド・メッセージに使用可能です。
この図では、プロデューサー・アプリケーションは、キュー宛先をホストするバス・メンバーのメッセージング・エンジンに接続されています。プロデューサー・アプリケーションで、「ローカル・キュー・ポイントの優先」オプションが使用不可になっています。 メッセージのワークロードは、すべてのキュー・ポイントで分散されます。
図 3. 「ローカル・キュー・ポイントの優先」を使用不可に設定: メッセージのワークロードはすべてのキュー・ポイントで分散されるただし、複数のプロデューサー・アプリケーションの接続のワークロードもバス・メンバー内のすべてのメッセージング・エンジンで分散する場合には、 パフォーマンス上の理由のため、デフォルトの「ローカル・キュー・ポイントの優先」の動作を保持することを検討してください。 これは、デフォルトの動作が以下のとおりであるからです。- すべてのプロデューサー・アプリケーションからのメッセージのワークロードをすべてのキュー・ポイントで分散する
- 接続されたメッセージング・エンジンからのメッセージを同じクラスター・バス・メンバー内の別のメッセージング・エンジンに送信する必要が最小化する
- プロデューサー・アプリケーションが、キュー宛先をホストしていないクラスター・バス・メンバーのメッセージング・エンジンに接続されている場合の、構成可能な動作
アプリケーション・プロデューサーの単一セッションで生成されたすべてのメッセージを同じキュー・ポイントに送信する場合には、 「メッセージ・アフィニティー」を構成することができます。 その場合、メッセージのワークロードは、複数のキュー・ポイントで分散されなくなります。
メッセージ・セットを同じキュー・ポイントに送信して、コンシューマーの単一のインスタンスで順番に処理する場合には、 アプリケーションで「メッセージ・アフィニティー」を構成することを検討します。 システムは、アプリケーション・プロデューサーの「ローカル・キュー・ポイントの優先」構成オプションに基づいて、 すべてのメッセージを送信する先の単一のキュー・ポイントを選択します。 このオプションは、WebSphere Application Server バージョン 7.0 以降 を使用する JMS メッセージ・プロデューサーおよび外部バス接続経由インバウンド・メッセージに使用可能です。
この図では、プロデューサー・アプリケーションは、キュー宛先をホストしていないバス・メンバーのメッセージング・エンジンに接続します。プロデューサー・アプリケーションには、メッセージ・アフィニティーが構成されています。 すべてのメッセージは、1 つのキュー・ポイントに送信されます。
図 4. メッセージ・アフィニティー : 生成されたすべてのメッセージが同じキュー・ポイントに送信される選択したキュー・ポイントが使用できなくなると、このアプリケーションから送信されたそれ以降のメッセージは、 選択したキュー・ポイントに転送中のキューに入れられるか、送信操作が拒否されます。 この動作は、単一のキュー・ポイントを持つキュー宛先にメッセージを送信する場合と同じです。
区画に分割されたキュー宛先からのメッセージのコンシューム
コンシューマー・ セッションが作成されると、コンシューマーは宛先のいずれかの区画に関連 付けられます。コンシューマーが、宛先のローカル区画を 備えたメッセージング・エンジンに接続 している場合、コンシューマーはその区画に関連付けられます。コンシューマーが、 宛先の区画を持たないメッセージング・エンジンに 接続している場合、コンシューマーはワークロード・マネージャーによって 動的に選択される別のメッセージング・エンジン内の 区画に関連付けられます。関連づけが行われると、コンシューマーは関連付けられた 区画からのみメッセージを受け取ります。デフォルトでは、コンシューマーが関連付けられた区画に メッセージがない場合、コンシューマーは代替区画からメッセージを受け取りません。 そのような代替区画にメッセージが含まれている場合でもメッセージを受け取り ません。
区画に分割された宛先を、 ローカル・コンシューマーを備えていないクラスターに構成する場合、 すべてのメッセージが使用されるように、宛先の区画ごとに少なくとも 1 つ のコンシューマーを配置することが重要です。これは、個々のコンシューマーが、キュー・ポイントを持つ特定のメッセージング・エンジンに接続するようにさせることによって実現できます。 MDB は、特定のタイプのメッセージ・コンシューマーです。 分割宛先からコンシュームする場合の動作の詳細については、メッセージ駆動型 Bean がクラスター内で接続する方法を参照してください。
コンシューマーが、 宛先の使用可能なすべてのキュー・ポイントからメッセージを受信する必要がある場合は、 メッセージ・コンシューマーを構成します。
容量の小さなメッセージが多数あり、 MDB が少量の処理しか実行しない場合は、このトピックの説明に従って、ワークロード・バランスのとれたメッセージング・エンジンを、分割キューと同時に使用することができます。 ただし、MDB が数は少なく処理量が多いようなメッセージの処理を実行する場合は、 メッセージング・エンジンは 1 つあればよいのですが、MDB はできるだけ多くのサーバーにデプロイする必要があります。 これは、それらのサーバーにメッセージング・エンジンがあるかないかには関係なく、 それらのサーバーが同じセルのメンバーではない場合にも当てはまります。 代表的なのは、MDB がユーザー・データベースを更新する場合です。 複数サーバーでの MDB デプロイメントの構成について詳しくは、 デフォルト・メッセージング・プロバイダーの MDB スロットルの構成を参照してください。
- コンシューマーが分割宛先からコンシュームする場合のメッセージング・システムのデフォルトの動作
コンシューマー・アプリケーションのセッションが作成されると、そのセッションは、キュー定義のキュー・ポイントのいずれかに関連付けられます。 キュー宛先に複数のキュー・ポイントがある場合には、システムによって選択されます。 デフォルトでは、メッセージング・システムは、コンシューマーを、接続されているメッセージング・エンジン上のローカル・キュー・ポイントに関連付けようとします。 接続されているメッセージング・エンジン上に使用可能なローカル・キュー・ポイントがない場合、システムは、重み付きラウンドロビン・アルゴリズムを使用する、WebSphere Application Server のワークロード・マネージャーを使用して別のキューを選択します。
デフォルトの動作は、コンシューマーが使用できるメッセージを、コンシューマーに関連付けられたキュー・ポイント上のメッセージに制限することによって、キュー・ポイントからのメッセージ消費のパフォーマンスを最大限にしようとします。 関連付けられたキュー・ポイントにメッセージが存在せず、別のキュー・ポイントにメッセージが存在している場合でも、 コンシューマーは、他のキュー・ポイントからのメッセージをコンシュームすることはできません。
この図では、コンシューマー・アプリケーションは、ローカル・キュー・ポイントを持たないメッセージング・エンジンに接続されています。1 つの関連付けられたキュー・ポイントからのメッセージのみがコンシュームされます。
図 5. デフォルトの動作: 関連付けられたキュー・ポイントからのメッセージのみがコンシュームされる
- コンシューマーが分割宛先からコンシュームする場合のメッセージング・システムの構成可能な動作
関連付けられたキュー・ポイントが宛先のすべての使用可能なキュー・ポイントからメッセージを収集して、そのメッセージをコンシューマーが見られるように、メッセージ・コンシューマーを構成することができます。
コンシューマーが区画に分割されたキューを区画に分割されていないキューとして処理するようにする場合には、 「メッセージの収集」の構成を検討します。 ただし、複数のキュー・ポイントからのメッセージの収集の場合、単一のキュー・ポイントからのコンシュームに比べて、動作速度が大幅に遅くなります。 そのため、可能な限り、宛先が単一のキュー・ポイントを持つように再構成するか、別名宛先を使用してメッセージのプロデューサーとコンシューマーを単一のキュー・ポイントに制限してください。 複数のキュー・ポイントのスケーラビリティーが必要で、パフォーマンスが重要な場合には、 メッセージの収集の代替ソリューションを検討してください。
「メッセージの収集」操作モードでは、コンシューマーは、キュー・ポイントに保持された順番でメッセージを認識することができません。 そのため、メッセージの順番は保持されません。
このオプションは、WebSphere Application Server バージョン 7.0 以降 を使用して、 JMS メッセージ・プロデューサーおよび外部バス接続からのインバウンド・メッセージで使用可能です。
この図では、コンシューマー・アプリケーションは、ローカル・キュー・ポイントを持たないメッセージング・エンジンに接続します。コンシューマー・アプリケーションでは、メッセージの収集が使用可能になっています。 関連キュー・ポイントは、宛先のすべての使用可能なキュー・ポイントからメッセージを収集して、コンシューマーで使用できるようにします。
図 6. メッセージの収集: メッセージはすべてのキュー・ポイントからコンシュームされる