クライアント数またはコネクション数が増加するにつれ、ボトルネックを解消し、パフォーマンスを向上させるために、メッセージサービスを拡張する必要が生じる場合があります。Message Queue メッセージサービスでは、ユーザーのニーズに応じた拡張オプションを多数用意しています。これらは、便宜上、次のカテゴリに分類されます。
垂直方向の拡張は、より高い処理能力を追加し、利用可能なリソースを拡張することによって実現できます。この拡張を行うには、プロセッサまたはメモリーを追加するか、共有スレッドモデルへ切り替えるか、または Java VM を 64bit モードで実行します。
ポイントツーポイントドメインを使用している場合は、複数のコンシューマからのキューへのアクセスを有効にすることにより、コンシューマ側を拡張できます。この方式を使用すると、アクティブおよびバックアップコンシューマの最大数を指定できます。ロードバランスメカニズムでも、コンシューマの現在の容量とメッセージ処理速度を考慮します。これは Message Queue の機能です。JMS 仕様で規定しているメッセージング動作は、1 つのコンシューマのみがキューにアクセスしている場合のものです。複数のコンシューマを許可するキューの動作は、プロバイダ固有の機能です。『Message Queue developer guide』で、この拡張オプションの詳細について説明しています。
ステートレスな水平方向の拡張は、追加ブローカを使用して、これらのブローカに既存のクライアントを分散することにより実現できます。この方式は実装が簡単ですが、独立した作業グループにメッセージング操作を分割できる場合にのみ適しています。
ステートフルな水平方向の拡張は、複数のブローカを接続してクラスタを構成することにより実現されます。ブローカクラスタでは、各ブローカは、クラスタ内のほかのすべてのブローカ、およびローカルアプリケーションクライアントにも接続します。ブローカは、同一ホスト上に置くことも、ネットワーク上に分散させることもできます。送信先とコンシューマに関する情報は、クラスタ内のすべてのブローカで複製されます。送信先またはサブスクライバに対する更新も伝えられます。これにより、各ブローカは、直接接続しているプロデューサから、クラスタ内のほかのブローカに接続しているコンシューマへ、メッセージをルーティングできます。バックアップコンシューマが使用されている状況では、1 つのブローカまたはコネクションに障害が発生した場合、アクセスできないコンシューマへ送信されたメッセージを、別のブローカ上のバックアップコンシューマに転送できます。
ブローカまたはコネクションに障害が発生した場合、持続エンティティー (送信先および永続サブスクリプション) に関する状態情報が同期されなくなる可能性があります。たとえば、クラスタ化したブローカが停止し、送信先がクラスタ内の別のブローカ上に作成された場合、最初のブローカが再起動されると新しい送信先が不明になります。この問題に対処するために、クラスタ内の 1 つのブローカをマスターブローカとして指定することができます。このブローカは、マスター設定ファイルでの送信先と永続サブスクリプションに対するすべての変更を追跡し、一時的にオフラインになっているクラスタ内のブローカを更新します。詳細は、第 4 章「ブローカクラスタ」を参照してください。
マスターブローカを使用した場合でも、Message Queue ではサービスの可用性しか向上しません。ブローカまたはコネクションに障害が発生した場合、データの可用性は確保されません。たとえば、クラスタ化したブローカが利用できなくなった場合、そのブローカが保持しているすべての持続メッセージは、そのブローカが復元されるまで利用できません。現在のところ、データの可用性を確保する唯一の手段は、SunCluster Message Queue エージェントを使用するというものです。この場合、持続ストアが共有ファイルシステム上に保持されます。ブローカに障害が発生した場合、2 番目のノード上の Message Queue エージェントがブローカを起動して、このブローカが共有ストアを引き継ぎます。クライアントはそのブローカに接続し直されます。この結果、サービスの継続と持続データへのアクセスの両方が確保されます。