|
| |
| Sun Java System Message Queue 3 2005Q4 管理ガイド | |
第 11 章
メッセージサービスの分析と調整この章では、Message Queue サービスの分析と調整を行い、メッセージングアプリケーションのパフォーマンスを最適化する方法に関連するさまざまなトピックを取り上げます。次のトピックが含まれます。
パフォーマンス関連この節では、パフォーマンス調整の背景について説明します。
パフォーマンス調整プロセス
メッセージングアプリケーションのパフォーマンスは、アプリケーションと Message Queue サービスの相互関係に左右されます。そのため、パフォーマンスを最大化するには、アプリケーション開発者と管理者が協力し合う必要があります。
パフォーマンスを最適化するプロセスは、アプリケーションの設計から始まります。アプリケーションが配置されたあとも、継続してメッセージサービスの調整を行います。パフォーマンス調整プロセスには、次の段階があります。
通常は、上記に概略したプロセスを繰り返し実行します。アプリケーションの配置時に、Message Queue 管理者は、メッセージサーバーの適合性を評価し、アプリケーションの全般的なパフォーマンス要件を満たしているかどうかを判断します。ベンチマークテストがこれらの要件を満たす場合は、この章で説明するとおり、管理者はシステムの調整段階に入ることができます。一方、ベンチマークテストがパフォーマンス要件を満たしていない場合は、アプリケーションの再設計や配置アーキテクチャーの変更が必要となる場合があります。
パフォーマンスのさまざまな側面
一般に、パフォーマンスの基準は、メッセージサービスがプロデューサからコンシューマへメッセージを配信するときの速度と効率です。ただし、パフォーマンスには、ニーズに応じて重要度が変わるさまざまな側面があります。
接続の負荷: メッセージプロデューサまたはメッセージコンシューマの数、もしくは、システムがサポート可能な同時接続の数です。
メッセージのスループット メッセージングシステムが 1 秒間に扱えるメッセージ数、またはメッセージのバイト数です。
遅延 特定のメッセージがメッセージプロデューサからメッセージコンシューマへ配信されるまでに要する時間です。
安定性: メッセージサービス全体の可用性、つまり過負荷や障害による影響をどれだけ抑えられるかです。
効率: メッセージ配信の効率。使用するコンピュータリソースに関係する、メッセージスループットの評価です。
パフォーマンスのこれらの異なる評価基準は、一般に相互に関連しています。メッセージスループットが高い場合、メッセージがメッセージサーバーへバックログされることは、ほとんどありません。その結果、遅延も短くなり、シングルメッセージはすぐに配信されます。ただし、遅延はさまざまな要因に左右されます。そのような要因の例としては、通信リンクの速度、メッセージサーバーの処理速度、クライアントの処理速度などがあります。
どのような場合でも、パフォーマンスには複数の異なる側面があります。一般に、その中でどれがもっとも重要となるかは、特定のアプリケーションの要件によって決まります。
ベンチマーク
ベンチマークとは、使用中のメッセージングアプリケーション用のテスト群を作成し、このテスト群を用いてメッセージスループットや、そのほかの観点からパフォーマンスを評価するプロセスです。
たとえば、複数のプロデューシングクライアントを対象に、複数の、接続、セッション、メッセージプロデューサを使用し、標準サイズの持続メッセージまたは持続性のないメッセージを一部のキューやトピック (すべてメッセージングアプリケーションの設計に依存) へ一定レートで送信するテスト群を作成できます。同様に、特定の通知モードでテスト群の物理的送信先においてメッセージを消費する複数の接続、セッション、および特定タイプのメッセージコンシューマを使用し、複数のコンシューミングクライアントをテスト群に含められます。
標準のテスト群を使用することで、メッセージが生成されてから消費されるまでに要する時間やメッセージの平均スループットレートを測定したり、システムを監視して、接続スレッド使用率、メッセージストレージデータ、メッセージフローデータ、そのほかの関連するメトリックスを監視したりできます。その後、パフォーマンスに悪影響が出る上限まで、メッセージの生成レート、メッセージプロデューサの数、その他の変数を増加させることができます。実現可能な最大スループットが、メッセージサービス設定のベンチマークになります。
このベンチマークを基に、テスト群の特性の一部を変更できます。パフォーマンスに影響しそうな要因すべてを慎重に制御すれば (「パフォーマンスに影響するアプリケーション設計の要因」を参照)、これらの要因の変化によるベンチマークへの影響を理解できます。たとえば、接続数またはメッセージ数を 5 倍もしくは 10 倍に増やし、パフォーマンスに与える影響を調べることができます。
逆に、アプリケーションベースの要因を一定に保ち、たとえば、接続プロパティー、スレッドプールプロパティー、JVM メモリー制限、制限の動作、ファイルベースの持続と JDBC ベースの持続などを変更するといった、制御方法でブローカ設定を変更して、これらの変更がパフォーマンスに及ぼす影響を判断することもできます。
アプリケーションのこのようなベンチマークから、メッセージサービスを調整して配置済みのアプリケーションのパフォーマンスを向上させたいときに有用な情報を得られます。ベンチマークによって、1 か所の変更や一連の変更による影響を正確に予測できます。
原則として、ベンチマークは、管理されたテスト環境で、メッセージサービスを安定させるため長期間実施する必要があります。Java コードをマシンコードに変換する JIT コンパイルによる起動時には、パフォーマンスに悪影響が及びます。
基準になる使用パターン
メッセージングアプリケーションが配置され稼働されたあとは、基準になる使用パターンを確立することが重要となります。要求のピークがいつ発生するか把握し、その要求の定量化を図ります。たとえば、通常、要求はエンドユーザー数、アクティビティレベル、時間帯、またはこれらすべてによって左右されます。
基準になる使用パターンを確立するには、メッセージサーバーを一定期間監視して、次のようなデータを調べる必要があります。
また、メトリックスデータにより提供される平均値とピーク値を使用することもできます。
これらの基準になるメトリックスを設計時の期待値と比較することが重要です。それによって、クライアントコードが正常に動作していることを確認します。たとえば、接続が開いたままになっている、または、消費されたメッセージが未通知のままになっているといった状態を確認できます。これらのコーディングエラーはメッセージサーバーのリソースを消費し、パフォーマンスに大きな影響を及ぼします。
基準になる使用パターンは、最適なパフォーマンスを得るためにシステムを調整する方法を決定する上で役立ちます。たとえば、次のように指定します。
一般に、使用パターンをより綿密に理解しているほど、より適切に、使用パターンに応じてシステムを調整し、将来ニーズに合わせてプランニングすることができます。
パフォーマンスに影響する要因メッセージの遅延とメッセージのスループットは、2 つの主要なパフォーマンスの評価基準です。これらは一般に、標準的なメッセージがメッセージ配信プロセスの各手順を完了するまでに要する時間に依存します。メッセージを持続的で信頼できる方法で配信する場合の各手順は次のとおりです。各手順を以下で図示します。
図 11-1 Message Queue サービスを使用したメッセージの配信
- メッセージはプロデューシングクライアントからメッセージサーバーへ配信される。
- メッセージサーバーはメッセージの内容を読み取る。
- メッセージは、信頼性を維持するために持続ストレージに配置される。
- メッセージサーバーは、信頼性を維持するためにメッセージの受信確認を発行する。
- メッセージサーバーは、メッセージのルーティングを決定する。
- メッセージサーバーはメッセージを書き込む。
- メッセージはメッセージサーバーからコンシューミングクライアントへ配信される。
- コンシューミングクライアントは、信頼性を維持するためにメッセージの受信確認を発行する。
- メッセージサーバーは、信頼性を維持するために、クライアントの通知を処理する。
- メッセージサーバーは、クライアントの通知が処理されたことを通知する。
これらの手順は順次実行されるため、プロデューシングクライアントからコンシューミングクライアントへメッセージを配信する際には、どの手順もボトルネックとなる恐れがあります。これらの手順の大半は、メッセージングシステムの物理的な特性に依存しています。物理的な特性には、ネットワーク帯域幅、コンピュータの処理速度、メッセージサーバーのアーキテクチャーなどが含まれます。ただし、一部の手順は、メッセージングアプリケーションの特性と必要とされる信頼性のレベルにも依存しています。
次の節では、アプリケーション設計の要因とメッセージングシステムの要因の両方がパフォーマンスに及ぼす影響について説明します。アプリケーション設計の要因とメッセージングシステムの要因はメッセージの配信に密接に関係しますが、各カテゴリは個別に考慮します。
パフォーマンスに影響するアプリケーション設計の要因
アプリケーション設計の決定は、メッセージングのパフォーマンス全体に大きく影響することがあります。
パフォーマンスに影響するもっとも重要な要因は、メッセージ配信の信頼性に影響を及ぼす要因です。次のような要因が含まれています。
そのほかに、パフォーマンスに影響するアプリケーション設計の要因には、次のものがあります。
以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。原則として、パフォーマンスと信頼性は相反しています。つまり、信頼性が高くなるとパフォーマンスは低下します。
表 11-1 は、さまざまなアプリケーション設計の要因が一般にどのようにメッセージングパフォーマンスに影響するかを示しています。表には、信頼性が高くパフォーマンスが低いシナリオと、パフォーマンスが高く信頼性の低いシナリオの 2 つのシナリオと、それぞれを特徴付ける主要なアプリケーション設計の要因を示します。これらの極端なシナリオの間には、信頼性とパフォーマンスの両方に影響する、多数の選択肢と兼ね合いがあります。
注
以下のグラフのパフォーマンスデータは、2 基の CPU を搭載した 1002 MHz の Solaris 8 システムでファイルベースの持続を使用して生成されたものです。パフォーマンステストでは、JIT コンパイラにより、システムを最適化し、持続データベースの準備をするために、最初に Message Queue ブローカを起動しました。
ブローカを起動したあと、1 つのプロデューサと 1 つのコンシューマが作成され、メッセージが 30 秒間生成されました。コンシューマがすべての生成されたメッセージを受信するために要した時間が記録され、スループットレートつまり 1 秒あたりのメッセージ数が計算されました。このシナリオは、表 11-1 に示すアプリケーション設計の要因の異なる組み合わせで繰り返し実行されました。
配信モード (持続的/持続性のないメッセージ)
持続メッセージはメッセージサーバーの障害時にもメッセージの配信を保証します。すべての対象のコンシューマが、メッセージを消費したことを通知するまで、ブローカはメッセージを持続ストアに格納します。
持続メッセージのブローカの処理速度は、次の理由から、持続性のないメッセージの場合より低速です。
持続モードと非持続モードではパフォーマンスに大きな差が生じることがあります。図 11-2 は、信頼できる配信を行う 2 つのケースで、持続メッセージと持続性のないメッセージのスループットを比較したものです。2 つのケースとは、永続サブスクリプションを使用して 10K バイトのメッセージをキューに配信した場合とトピックに配信した場合です。どちらの場合も AUTO_ACKNOWLEDGE 通知モードを使用しています。
図 11-2 配信モードによるパフォーマンスへの影響
トランザクションの使用
トランザクションとは、処理済みセッションで生成されたすべてのメッセージと処理済みセッションで消費されたすべてのメッセージが、一体として処理されるか、または一体として処理されない、つまりロールバックされることを保証するものです。
Message Queue では、ローカルと分散の両方のトランザクションがサポートされます。
処理済みセッションでのメッセージの生成または通知の処理速度は、次の理由から、処理済みでないセッションの場合より低速です。
通知モード
JMS メッセージの配信の信頼性を保証する手段の 1 つは、Message Queue メッセージサーバーによってクライアントへ配信されたメッセージの消費をクライアントに通知するという方法です。
クライアントがメッセージを通知することなくセッションが閉じられた場合や、通知が処理される前にメッセージサーバーに障害が生じた場合には、ブローカはメッセージを再配信して JMSRedelivered フラグをセットします。
処理済みでないセッションの場合、クライアントは、それぞれ固有のパフォーマンス特性をもつ 3 つの通知モードの中から 1 つを選択できます。
- AUTO_ACKNOWLEDGE。コンシューマがメッセージを処理したあと、システムは自動的にメッセージを通知します。このモードでは、プロバイダで障害が生じたあとは、多くても 1 つのメッセージの再配信を保証するだけです。
- CLIENT_ACKNOWLEDGE。アプリケーションは、メッセージが通知されるポイントを制御します。直前の通知以降にそのセッションで処理されたすべてのメッセージが通知されます。一連の通知の処理中にメッセージサーバーに障害が生じた場合は、そのグループ内の複数のメッセージが再配信されることがあります。
- DUPS_OK_ACKNOWLEDGE。このモードは、時間をかけてメッセージを通知するようにシステムに指示します。プロバイダに障害が生じたあとでも、複数のメッセージを再配信できます。
CLIENT_ACKNOWLEDGE モードの使い方はトランザクションの使い方に似ています。ただし、処理中にプロバイダに障害が生じた場合に、すべての通知が一括して処理されることを保証していない点を除きます。
次の理由により、通知モードはパフォーマンスに影響します。
- AUTO_ACKNOWLEDGE モードと CLIENT_ACKNOWLEDGE モードでは、ブローカとクライアント間で特別な制御メッセージが必要です。追加の制御メッセージは、処理オーバーヘッドを高め、JMS ペイロードメッセージに干渉して処理遅延を引き起こすことがあります。
- AUTO_ACKNOWLEDGE モードと CLIENT_ACKNOWLEDGE モードでは、ブローカがクライアントの通知を処理したことを確認するまで、クライアントは待機する必要があります。その後、クライアントは追加メッセージを消費できるようになります。このブローカの確認によって、何らかの理由でブローカがこれらのメッセージを再配信しないように保証します。
- Message Queue 持続ストアは、コンシューマが受信したすべての持続メッセージに関する通知情報を使って更新する必要があります。そのため、パフォーマンスは低下します。
永続サブスクリプションと永続的でないサブスクリプション
トピック送信先へのサブスクライバは、永続サブスクリプションをもつものと、永続的でないサブスクリプションをもつものの 2 つのカテゴリに分かれます。
永続サブスクリプションでは、次の理由により、信頼性が高まりますが、スループットが遅くなります。
- Message Queue メッセージサーバーは、メッセージサーバーに障害が生じた場合でも回復後にリストを使用できるように、各永続サブスクリプションに割り当てられたメッセージのリストを持続的に格納する必要があります。
- メッセージサーバーに障害が生じた場合でも、回復後に、対応するコンシューマがアクティブになったときに、メッセージを引き続き配信できるように、永続サブスクリプションの持続メッセージは持続ストアに格納されます。対照的に、永続的でないサブスクリプションの持続メッセージは持続ストアには格納されません。したがって、メッセージサーバーに障害が生じると、対応するコンシューマ接続は失われ、メッセージは配信されません。
図 11-3 では、 10K バイトの持続メッセージと持続性のないメッセージの 2 とおりのケースで、永続サブスクリプションと永続的でないサブスクリプションを使用したトピック送信先のスループットを比較しています。どちらの場合も AUTO_ACKNOWLEDGE 通知モードを使用しています。
図 11-3 から、パフォーマンスへの影響が顕著となるのは、永続サブスクリプションを使用した持続メッセージの場合だけであることがわかります。上記のとおり、この場合の影響は、永続サブスクリプションを使用したときに持続メッセージだけが持続ストアに格納されることに起因しています。
図 11-3 サブスクリプションタイプによるパフォーマンスへの影響
セレクタの使用 (メッセージのフィルタリング)
アプリケーション開発者は、通常、特定のコンシューマへの一連のメッセージを対象にしています。それは、一意の物理的送信先への一連のメッセージごとを対象とするか、単一の物理的送信先を使用しコンシューマごとに複数のセレクタを登録することで実現できます。
セレクタは文字列であり、この文字列に一致するプロパティー値を持ったメッセージだけを特定のコンシューマに配信します。たとえば、セレクタ NumberOfOrders >1 は、NumberOfOrders プロパティー値が 2 以上のメッセージだけを配信します。
コンシューマにセレクタを登録すると、各メッセージを取り扱うために追加処理が必要となり、複数の物理的送信先を使用する場合に比べ、パフォーマンスは低下します。以降のメッセージを比較する際にも構文解析できるセレクタを使用する必要があります。さらに、各メッセージがルーティングされるたびに、各メッセージのメッセージプロパティーを読み取り、比較する必要があります。ただし、セレクタを使用すると、メッセージングアプリケーションの柔軟性が向上します。
メッセージのサイズ
メッセージのサイズはパフォーマンスに影響します。プロデューシングクライアントからブローカへ、さらにブローカからコンシューミングクライアントへは、より多くのデータを渡す必要があり、持続メッセージの場合はサイズの大きいメッセージを格納する必要があるからです。
ただし、複数のサイズの小さいメッセージを 1 つのメッセージにまとめることで、個々のメッセージの転送と処理を最小限に抑え、パフォーマンス全体を向上させることができます。この場合、個々のメッセージの状態に関する情報は失われてしまいます。
図 11-4 は、持続メッセージと持続性のないメッセージの 2 とおりのケースで、1K、10K、および 100K バイトのメッセージのスループットを 1 秒あたりの K バイト数で比較したものです。どのケースも、メッセージはキュー送信先へ送信し、AUTO_ACKNOWLEDGE 通知モードを使用しています。
図 11-4 は、両方のケースで、小さいサイズのメッセージの場合に比べ、よりサイズの大きいメッセージを配信するほどオーバーヘッドが低くなることを示しています。また、1K バイトと 10K バイトのメッセージの場合は、持続メッセージと持続性のないメッセージを比べたパフォーマンスの上昇は約 50% ですが、100K バイトのメッセージの場合、この差が維持されないことがわかります。おそらくこれは、100K バイトの場合には、ネットワークの帯域幅がメッセージスループットのボトルネックになるからでしょう。
図 11-4 メッセージのサイズによるパフォーマンスへの影響
メッセージ本体のタイプ
JMS がサポートするメッセージ本体のタイプ 5 種類の概要を複雑な順に次に示します。
一般に、メッセージのタイプはアプリケーションのニーズによって決定され、MapMessage や ObjectMessage などのより複雑なタイプほどパフォーマンスは低下します。データのシリアライズとデシリアライズがパフォーマンスを低下させます。パフォーマンスは、データがどの程度単純か、またはどの程度複雑かによって異なります。
パフォーマンスに影響するメッセージサービスの要因
メッセージングアプリケーションのパフォーマンスは、アプリケーション設計だけでなく、メッセージのルーティングと配信を実行するメッセージサービスによっても影響を受けます。
次の節では、パフォーマンスに影響することのあるさまざまなメッセージサービスの要因について説明します。これらの要因の影響を理解しておくことは、メッセージサービスの内容を変更したり、配置済みのアプリケーションで発生することのあるパフォーマンスボトルネックを診断し解決したりする上で重要となります。
Message Queue サービスのパフォーマンスに影響するもっとも重要な要因は、次のとおりです。
以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。
ハードウェア
Message Queue メッセージサーバーとクライアントアプリケーションのどちらの場合も、CPU の処理速度と使用可能なメモリーはメッセージサービスのパフォーマンスを決定する主要な要因となります。処理性能を強化して、多数のソフトウェア制限をなくす一方で、メモリーを追加して処理速度と能力を増加させることができます。ただし、一般に、単にハードウェアをアップグレードするだけでボトルネックを解消すると多額の費用がかかります。
オペレーティングシステム
同じハードウェアプラットフォームを前提とした場合でも、異なるオペレーティングシステムの効率によって、パフォーマンスも変わってきます。たとえば、オペレーティングシステムが採用しているスレッドモデルが、メッセージサーバーがサポート可能な同時接続数に大きく影響することがあります。一般に、すべてのハードウェアが同じであれば、Solaris は通常 Linux より高速で、Linux は Windows より高速です。
Java 仮想マシン (JVM)
メッセージサーバーは、ホスト JVM 内で実行され、ホスト JVM によってサポートされる Java プロセスです。そのため、JVM 処理は、メッセージサーバーがメッセージをいかに早く効率良くルーティングし配信できるかを決定する重要な要因となります。
特に、JVM のメモリーリソースの管理が不可欠となる場合があります。増加し続けるメモリーの負荷に対応するには、JVM に十分なメモリーを割り当てる必要があります。さらに、JVM は定期的に未使用のメモリーを再利用します。このメモリー再利用がメッセージの処理を遅らせることがあります。JVM のメモリーヒープが大きくなるほど、メモリー再利用時に経験することのある、潜在する遅延も長くなります。
接続
クライアントとブローカ間の接続の数と速度は、メッセージサーバーが処理可能なメッセージ数とメッセージ配信速度に影響することがあります。
メッセージサーバーの接続の制限
メッセージサーバーへのアクセスはすべて、接続経由で行われます。同時接続数の制限によって、メッセージサーバーが同時に使用できるプロデューシングクライアントまたはコンシューミングクライアントの数が左右されることがあります。
メッセージサーバーへの接続の数は、一般に、使用可能なスレッド数によって制限されます。Message Queue は、専用スレッドモデルまたは共有スレッドモデルのどちらかをサポートするように設定できます (「スレッドプール管理」を参照)。
専用スレッドモデルは、各接続が専用のスレッドを持つため非常に高速ですが、接続の数は使用可能なスレッド数によって制限されます。この場合、接続ごとに、入力スレッドと出力スレッドが 1 つずつ必要です。共有スレッドモデルには、接続数の制限はありませんが、多数の接続でスレッドを共有するため、オーバーヘッドが増え、スループットが悪化します。これは、多くの接続が使用中のとき特に顕著になります。
トランスポートプロトコル
Message Queue ソフトウェアを使うと、クライアントは各種の低レベルのトランスポートプロトコルを使用してメッセージサーバーと通信できます。Message Queue は、「接続サービス」で説明する接続サービスとそれに対応するプロトコルをサポートします。
暗号化、ファイアウォールを介したアクセスなどのプロトコルは、アプリケーション要件に基づいて選択されますが、選択結果はパフォーマンス全体に影響を及ぼします。
図 11-5 トランスポートプロトコルの速度
図 11-5 は、さまざまなプロトコルテクノロジのパフォーマンス特性を示しています。
図 11-6 は、2 つのケースでの TCP と SSL のスループットを比較したものです。2 つのケースとは、1K バイトの持続メッセージを、永続サブスクリプションと AUTO_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信する高信頼性シナリオと、1K バイトの持続性のないメッセージを、永続サブスクリプションと DUPS_OK_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信するハイパフォーマンスシナリオです。
図 11-6 は、高信頼性ケースの方がプロトコルによる影響は少ないことを示します。これは、高信頼性のケースで必要な持続メッセージのためのオーバーヘッドの方が、プロトコルの速度より、スループットを制限する重要な要因となるからです。
図 11-6 トランスポートプロトコルによるパフォーマンスへの影響
メッセージサーバーのアーキテクチャー
メッセージサーバーは、シングルブローカ、または複数の連結されたブローカインスタンスであるブローカクラスタとして実装できます。
ブローカに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカは最終的に、ファイル記述子、スレッド、メモリーの制限などのリソースの限界を超えてしまいます。増え続ける負荷に対処するための 1 つの方法は、Message Queue メッセージサーバーにブローカインスタンスを追加して、クライアントの接続とメッセージのルーティングおよび配信を複数のブローカに分散することです。
一般に、ブローカインスタンスの追加は、クライアント、特にメッセージプロデューシングクライアントがクラスタ間で均等に分散されている場合に最適に動作します。クラスタ内のブローカ間でのメッセージ配信にはオーバーヘッドが伴うため、接続数とメッセージ配信レートが制限されているクラスタでは、シングルブローカよりパフォーマンスが低くなります。
また、ブローカクラスタを使用してネットワークの帯域幅を最適化することもできます。たとえば、クラスタ内の一連のリモートブローカ間で、速度の遅い、長距離のネットワークリンクを使用する一方で、個々のブローカインスタンスへのクライアントの接続に、高速なリンクを使用することができます。
クラスタの詳細については、第 9 章「ブローカクラスタを使用した作業」を参照してください。
ブローカの制限と動作
メッセージを処理するためにメッセージサーバーに要求されるメッセージスループットは、メッセージサーバーがサポートするメッセージングアプリケーションの使用パターンによって異なります。ただし、メッセージサーバーでは、メモリーや CPU サイクルなどのリソースに制限があります。リソースの制限により、メッセージサーバーは、過負荷となり、無応答または不安定となるポイントに達してしまうことがあります。
Message Queue メッセージサーバーには、メモリーリソースを管理し、ブローカのメモリー不足を防ぐためのメカニズムが組み込まれています。これらのメカニズムに含まれるのは、ブローカまたは個々の物理的送信先が保持できるメッセージ数またはメッセージのバイト数についての設定可能な制限と、物理的送信先の制限に達したときに起動できる一連の動作です。
これらの設定可能なメカニズムを使用して、システムが過負荷にならないように、メッセージの受信と送信のバランスを取ることができますが、これには注意深い監視と調整が必要です。これらのメカニズムは、オーバーヘッドを増加させ、メッセージのスループットを制限することがありますが、それでも動作の完全性を維持します。
データストアのパフォーマンス
Message Queue は、ファイルベースの持続モジュールと JDBC ベースの持続モジュールの両方をサポートしています。ファイルベースの持続モジュールでは、持続データを格納するために個別のファイルを使用します。JDBC ベースの持続では、JDBCTM (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアを必要とします。一般的に、ファイルベースの持続は、JDBC ベースの持続よりも高速です。ただし、JDBC 互換のストアによって提供される冗長性や管理機能を好むユーザーもいます。
ファイルベースの持続の場合は、持続的な操作によりメモリー内の状態とデータストアとを同期化するように指定することで、信頼性を高められます。この同期化は、システム破壊によるデータの損失をなくす上で役立ちますが、パフォーマンスが犠牲になります。
クライアントランタイムの設定
Message Queue クライアントランタイムは、クライアントアプリケーションに Message Queue メッセージサービスへのインタフェースを提供します。クライアントランタイムでは、物理的送信先にメッセージを送信し、物理的送信先からメッセージを受信する場合に、クライアントに必要なすべての処理をサポートします。クライアントランタイムは、接続ファクトリ属性値を使って設定可能で、パフォーマンスとメッセージスループットを向上させるように、接続フロー測定、コンシューマフローの制限、接続フロー制御などのプロパティーと動作を設定できます。これらの機能とそれを設定するために使用される属性の詳細は、「クライアントランタイムのメッセージフローの調整」を参照してください。
パフォーマンスを改善するための設定の調整システムの調整
次の節では、オペレーティングシステム、JVM、および通信プロトコルで実行できる調整について説明します。
Solaris での調整: CPU 使用率、ページング/スワッピング/ディスク I/O
オペレーティングシステムの調整については、システムのマニュアルを参照してください。
Java 仮想マシン (JVM) の調整
デフォルトでは、ブローカは 192M バイトの JVM ヒープサイズを使用します。通常、大量のメッセージ負荷がある場合はこのサイズでは小さ過ぎるため、大きくする必要があります。
Java オブジェクトが使用する JVM のヒープ容量を使い果たしそうになると、ブローカは、フロー制御やメッセージスワップなどのさまざまな技術を使用して、メモリーを解放します。極端な状況のもとでは、メモリーを解放し、メッセージの流入を減少させるために、クライアント接続を閉じることもあります。このような状況を避けるため、最大 JVM ヒープ容量を十分に高く設定するようお勧めします。
ただし、Java の最大ヒープ容量がシステムの物理メモリーに対して高くしすぎた場合、ブローカは Java ヒープ容量を増加し続け、システム全体のメモリーを使い果たしてしまうことがあります。これは、パフォーマンスの低下、予期しないブローカのクラッシュにつながり、そのシステムで実行されているほかのアプリケーションやサービスの動作にも影響を与える場合があります。一般に、オペレーティングシステムとそのほかのアプリケーションをマシン上で実行させるために十分な物理メモリーを使用させる必要があります。
一般に、通常時とピーク時のシステムメモリーフットプリントを評価して、十分なパフォーマンスを得られて、しかもシステムメモリーに問題を生じさせるほどではない大きさに Java ヒープサイズを設定するのがよい方法です。
ブローカの最小ヒープサイズと最大ヒープサイズを変更するには、ブローカの起動時に -vmargs コマンド行オプションを使用します。たとえば、次のように指定します。
このコマンドは、起動時の Java ヒープサイズを 256M バイトに、最大 Java ヒープサイズを 1G バイトに設定します。
- Solaris や Linux では、/etc/rc*、つまり /etc/init.d/imq を介してブローカを起動する場合には、/etc/imq/imqbrokerd.conf (Solaris) ファイルまたは/etc/opt/sun/mq/imqbrokerd.conf (Linux) ファイルにブローカコマンド行引数を指定します。詳細については、そのファイルのコメントを参照してください。
- Windows では、ブローカを Windows のサービスとして起動する場合には、imqsvcadmin install コマンドに -vmargs オプションを使用して JVM 引数を指定します。第 13 章「コマンド行のリファレンス」の「サービス管理ユーティリティー」を参照してください。
どのような場合でも、ブローカのログファイルを確認するか、imqcmd metrics bkr -m cxn コマンドを使用して設定を検証します。
トランスポートプロトコルの調整
アプリケーションのニーズを満たすプロトコルが選択されたら、選択されたプロトコルに基づいて調整を加えることでパフォーマンスを改善できます。
プロトコルのパフォーマンスは、次の 3 つのブローカプロパティーを使用して修正できます。
TCP と SSL プロトコルの場合、これらのプロパティーがクライアントとブローカ間のメッセージ配信の速度に影響します。HTTP プロトコルと HTTPS プロトコルの場合は、これらのプロパティーが、Web サーバー上で実行している Message Queue トンネルサーブレットとブローカ間のメッセージ配信の速度に影響します。HTTP/HTTPS プロトコルの場合、そのほかにもパフォーマンスに影響することのあるプロパティーがあります (「HTTP/HTTPS の調整」を参照)。
プロトコルを調整するためのプロパティーについては、次の節で説明します。
nodelay
nodelay プロパティーは、特定のプロトコルの Nagle のアルゴリズム、つまり TCP/IP 上の TCP_NODELAY ソケットレベルのオプションの値に影響します。Nagle のアルゴリズムは、広域ネットワーク (WAN) などの低速接続を使用しているシステム上で TCP パフォーマンスを改善するために使用されます。
このアルゴリズムが使用されている場合、TCP は、データをサイズの大きいパケットにバンドルすることで、複数の小さいデータの塊がリモートシステムへ送信されるのを防ぎます。ソケットに書き込まれたデータが必要なバッファーサイズを満たしていない場合、プロトコルは、バッファーが満たされるか、一定の遅延時間が経過するまで、パケットの送信を遅らせます。バッファーがいっぱいになるか、タイムアウトが発生すると、パケットが送信されます。
大半のメッセージングアプリケーションでは、パケットの送信に遅延がない、つまり Nagle のアルゴリズムが無効な場合にパフォーマンスは最適となります。これは、クライアントとブローカ間の大半の対話が、要求/応答型の対話だからです。つまり、クライアントはデータのパケットをブローカへ送信し、その応答を待ちます。たとえば、典型的な対話には次のものがあります。
これらの対話では、大半のパケットがバッファーサイズより小さいサイズです。つまり、Nagle のアルゴリズムが使用されている場合は、ブローカは数ミリ秒遅れて、コンシューマに応答を送信します。
ただし、Nalge のアルゴリズムは、接続が低速でブローカの応答が必要ない状況で、パフォーマンスを改善することができます。これは、クライアントが持続性のないメッセージを送信する場合や、クライアント通知がブローカによって確認されない場合 (DUPS_OK_ACKNOWLEDGE セッション) です。
inbufsz/outbufsz
inbufsz プロパティーは、ソケットからのデータを読み取る入力ストリームのバッファーサイズを設定します。同様に、outbufsz は、ブローカがデータをソケットに書き込むために使用する出力ストリームのバッファーサイズを設定します。
一般に、どちらのパラメータも受信パケットまたは送信パケットの平均サイズより多少大きい値に設定する必要があります。経験上、これらのプロパティーはパケットの平均サイズに 1K バイトを足した値 (K バイト単位で四捨五入) に設定すると良いでしょう。
たとえば、本体が 1K バイトのパケットをブローカで受信している場合、パケット全体のサイズ (メッセージ本体 + ヘッダー + プロパティー) は約 1200 バイトです。inbufsz を 2K バイト (2048 バイト) にすると、妥当なパフォーマンスが得られます。
inbufsz または outbufsz をそのサイズより大きくすると多少パフォーマンスは改善しますが、接続ごとに必要なメモリーも増えます。
図 11-7 は、1K バイトのパケットの inbufsz を変更した結果を示しています。
図 11-7 1K バイト (1024 バイト) パケットの inbufsz を変更した結果
図 11-8 は、1K バイトのパケットの outbufsz を変更した結果を示しています。
図 11-8 1K バイト (1024 バイト) パケットの outbufsz を変更した結果
HTTP/HTTPS の調整
前の 2 つの節で説明した一般的なプロパティーに加え、HTTP/HTTPS のパフォーマンスは、Message Queue トンネルサーブレットをホスティングする Web サーバーへの HTTP 要求をクライアントが作成する速度によっても制限されます。
Web サーバーは、シングルソケットで複数の要求を処理するように最適化する必要があります。JDK バージョン 1.4 以降では、Web サーバーが複数の HTTP 要求を処理する際に使用するリソースを最小限にするために、Web サーバーへの HTTP 接続 (Web サーバーへのソケット) は開かれたままになっています。JDK 1.4 を使用しているクライアントアプリケーションのパフォーマンスが JDK の旧リリースで稼働している同じアプリケーションより低速な場合は、パフォーマンスを改善するために Web サーバーのキープアライブ設定パラメータの調整が必要となることがあります。
このような Web サーバーの調整に加え、クライアントが Web サーバーをポーリングする頻度を調整することもできます。HTTP は要求ベースのプロトコルです。つまり、HTTP ベースのプロトコルを使用しているクライアントは、メッセージが待機中かどうかを判断するたに Web サーバーを定期的に確認する必要があります。imq.httpjms.http.pullPeriod ブローカプロパティーとそれに対応する imq.httpsjms.https.pullPeriod プロパティーは、Message Queue クライアントが Web サーバーをポーリングする頻度を指定します。
pullPeriod 値が -1 (デフォルト値) の場合、クライアントランタイムは直前の要求が戻るとすぐにサーバーをポーリングし、個々のクライアントのパフォーマンスを最大化します。その結果、各クライアント接続が Web サーバー内の要求スレッドを 1 つずつ占有するため、Web サーバーのリソースにかなりの負荷がかかる場合があります。
pullPeriod 値が正の数字である場合、クライアントランタイムは要求を定期的に Web サーバーへ送信し、データが保留されているかどうかを確認します。この場合、クライアントは Web サーバーの要求スレッドを占有しません。したがって、多数のクライアントが Web サーバーを使用している場合は、pullPeriod を正の値に設定することで Web サーバーのリソースを節約できます。
ファイルベースの持続ストアの調整
ファイルベースの持続ストアの調整については、「持続サービス」を参照してください。
ブローカの調整
次の節では、パフォーマンスを改善するためにブローカのプロパティーに対して実行できる調整について説明します。
メモリー管理: 負荷のある状態でブローカの安定性を高める
メモリー管理は、送信先単位で、またはシステム全体に対してすべての送信先を一括で、設定できます。
物理的送信先の制限の使い方
物理的送信先の制限については、第 6 章「物理的送信先の管理」を参照してください。
システム全体の制限の使い方
メッセージプロデューサの処理速度がメッセージコンシューマの処理速度を上回る傾向がある場合には、メッセージをブローカに蓄積できます。ブローカにはメモリーが不足した場合に、プロデューサの処理速度を低下させ、アクティブメモリーからメッセージをスワップさせるメカニズムが組み込まれていますが、ブローカが保持可能なメッセージの合計数とメッセージのバイトの合計数に厳密な制限を設定した方が賢明です。
imq.system.max_count ブローカプロパティーと imq.system.max_size ブローカプロパティーを設定して、これらの制限を制御します。
たとえば、次のように指定します。
上記で定義された値は、ブローカが未配信/未通知のメッセージを最大 5000 までしか保持しないことを示しています。それ以上のメッセージが送信されると、メッセージはブローカによって拒否されます。メッセージが持続的な場合は、プロデューサがメッセージを送信しようとすると例外を受け取ります。メッセージが持続的でない場合は、ブローカは暗黙のうちにメッセージを廃棄します。
メッセージの送信時に例外が戻った場合、クライアントは一時停止してから、送信を再試行します。この例外は、メッセージ受信に関するブローカの障害が原因ではありません。発生した例外は、送信側のクライアントだけが検出します。
複数のコンシューマキューのパフォーマンス
複数のキューコンシューマがキュー送信先でメッセージを処理する能率は、次の設定可能キュー送信先属性によって決まります。
最適なメッセージスループットを実現するには、十分な数のアクティブコンシューマがキューでのメッセージの生成に遅れずに対応し、消費する割合を最大にするような方法で、キュー内のメッセージをルーティングし、アクティブコンシューマへ配信しなければなりません。メッセージ配信を複数のコンシューマに分散させる一般的なメカニズムについては、『Sun Java System Message Queue 技術の概要』で説明されています。
メッセージがキューに蓄積している場合、メッセージ負荷を処理するアクティブコンシューマの数が不十分であることが考えられます。また、複数のメッセージがバッチサイズでコンシューマに配信されるため、メッセージがコンシューマ上でバックアップされていることも考えられます。たとえば、バッチサイズ (consumerFlowLimit) が大き過ぎる場合は、あるコンシューマがキュー内のすべてのメッセージを受信し、そのほかのコンシューマは何も受信していないことがあります。コンシューマが非常に高速であれば、これは問題にはなりません。
ただし、コンシューマが比較的低速で、メッセージをコンシューマに均等に分散させたい場合は、バッチサイズを小さくする必要があります。バッチサイズが小さいほど、メッセージをコンシューマへ配信するのに必要なオーバーヘッドは増加します。それでも、低速なコンシューマの場合は、一般に、小さいバッチサイズを使用した方がパフォーマンスは向上します。
クライアントランタイムのメッセージフローの調整
この節では、パフォーマンスに影響するフロー制御の動作について説明します (「クライアントランタイムの設定」を参照)。これらの動作は、接続ファクトリの管理対象オブジェクトの属性として設定されます。接続ファクトリ属性の設定方法については、第 8 章「管理対象オブジェクトの管理」を参照してください。
メッセージフロー測定
クライアントによって送受信されるメッセージ (ペイロードメッセージ) と Message Queue 制御メッセージは、同じクライアントとブローカ間の接続を使って伝送されます。ブローカ通知などの制御メッセージの配信における遅延は、ペイロードメッセージの配信によって制御メッセージが保留された場合の結果として生じます。このようなネットワークの輻輳を防止するため、Message Queue は接続全体のペイロードメッセージのフローを測定します。
ペイロードメッセージは、接続ファクトリ属性 imqConnectionFlowCount の指定に従い、設定した数のみが配信されるようにバッチされます。バッチが配信されたあと、ペイロードメッセージの配信は中断され、保留中の制御メッセージのみが配信されます。ペイロードメッセージの追加のバッチが配信されるときも、このサイクルが繰り返され、保留中の制御メッセージが続きます。
クライアントが、ブローカからの多数の応答を必要とする操作を実行している場合、たとえば、クライアントが CLIENT_ACKNOWLEDGE または AUTO_ACKNOWLEDGE モード、持続メッセージ、トランザクション、キューブラウザを使用している場合や、クライアントがコンシューマを追加または削除している場合などには、imqConnectionFlowCount の値を小さいままにしておく必要があります。一方、クライアントが DUPS_OK_ACKNOWLEDGE モードを使用しており、接続上に単純なコンシューマしかいない場合は、パフォーマンスを犠牲にすることなく imqConnectionFlowCount の値を増やすことができます。
メッセージフロー制限
Message Queue クライアントランタイムがメモリーなどのローカルリソースの上限に達する前に処理可能なペイロードメッセージの数には制限があります。この数に達すると、パフォーマンスに悪影響が出ます。したがって、Message Queue では、コンシューマあたりのメッセージ数または接続あたりのメッセージ数を制限できます。この制限は、接続を介して配信し、クライアントランタイムにバッファリングし、消費を待機できるメッセージの数を示しています。
コンシューマフローの制限
クライアントランタイムへ配信されたペイロードメッセージの数が、いずれかのコンシューマの imqConsumerFlowLimit 値を超えた場合、そのコンシューマへのメッセージ配信は停止します。そのコンシューマの消費されないメッセージの数が、imqConsumerFlowThreshold で設定された値を下回った場合にだけ、配信処理が再開されます。
次の例は、これらの制限の使い方を示しています。トピックコンシューマのデフォルト設定値を前提としています。
imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50
コンシューマが作成され、1000 のメッセージがあれば、ブローカはこれらのメッセージを最初のバッチとしてコンシューマに配信します。このとき一時停止はありません。1000 メッセージの送信後、ブローカはクライアントランタイムが追加のメッセージを要求するまで、配信を停止します。アプリケーションがこれらのメッセージを処理するまで、クライアントランタイムはそれらを保持します。その後、クライアントランタイムは、アプリケーションがメッセージバッファー容量の 50% (imqConsumerFlowThreshold) つまり 500 メッセージ以上を消費するのを待ってから、ブローカに次のバッチを送信するように要求します。
同じ状況で、しきい値が 10% の場合、クライアントランタイムは、アプリケーションが少なくとも 900 メッセージを消費してから、次のバッチを要求します。
次のバッチサイズの計算方法:
そのため、imqConsumerFlowThresholdが 50% の場合、次のバッチサイズは、アプリケーションがメッセージを処理する速度に応じて 500 〜 1000 の間になります。
imqConsumerFlowThreshold がかなり高く (100% 近くに) 設定された場合、ブローカは比較的小さいサイズのバッチを送信するため、メッセージのスループットは低下することがあります。値が低過ぎる (0% に近い) 場合は、クライアントは次のセットを配信する前に残りのバッファリングされたメッセージの処理を完了してしまい、やはりメッセージスループットを低下させることがあります。一般に、特定のパフォーマンスや信頼性を考慮しないかぎり、imqConsumerFlowThreshold 属性のデフォルト値を変更する必要はありません。
コンシューマベースのフロー制御、特に、imqConsumerFlowLimit は、クライアントランタイム内のメモリーを管理する最適な手段です。一般に、クライアントアプリケーションに応じて、接続でサポートする必要のあるコンシューマの数、メッセージのサイズ、クライアントランタイムで使用可能なメモリー総量がわかります。
接続フローの制限
一部のクライアントアプリケーションでは、エンドユーザーの選択によって、コンシューマの数が不確定な場合があります。そのような場合は、引き続き、接続レベルのフロー制限を使用してメモリーを管理できます。
接続レベルのフロー制御は、接続上のすべてのコンシューマについてバッファリングされたメッセージの合計数を制限します。この数が imqConnectionFlowLimit の値を超えると、合計数が接続の制限を下回るまで、接続経由のメッセージの配信は停止します。imqConnectionFlowLimit 属性は、imqConnectionFlowLimitEnabled を true に設定した場合にだけ使用できます。
1 つのセッションでキューに入るメッセージの数は、そのセッションを使用するメッセージコンシューマの数と、各コンシューマのメッセージ負荷によって決まります。クライアント側のメッセージの生成またはメッセージの消費に遅延が発生する場合は、通常は、アプリケーションを再設計し、より多くのセッションにメッセージプロデューサとメッセージコンシューマを分散し、またはより多くの接続にセッションを分散してパフォーマンスを改善できます。
