42 パフォーマンスとスケーラビリティの評価

多くの場合、Coherenceの分散キャッシュは既存のローカル・キャッシュと比較して評価されます。ローカル・キャッシュは一般的に、インプロセス・ハッシュ・マップの形式になります。Coherenceにはインプロセスの非クラスタ・キャッシュに対応する機能を備えていますが、ローカル・キャッシュと分散キャッシュのパフォーマンスを直接比較するのは現実的ではありません。分散キャッシュはプロセス外という特性があるため、シリアライズとネットワーク転送を実行する必要があります。これと引き換えに、キャッシュ・データのクラスタ全体における一貫性、および単一のJVMまたはマシンで対応できる能力を超えるデータと問合せのスケーラビリティが得られます。これは、分散キャッシュの使用で非常に優れたパフォーマンスを実現することが不可能なのではなく、適切なコンテキストでの評価が必要という意味です。

待機時間とスループットの測定

パフォーマンスの評価時には、待機時間とスループットの2つについて確認します。単純なパフォーマンス分析テストでは、タイトなループで、一連の時限式キャッシュ・アクセスを実行しようとする場合があります。このテストでは、待機時間は正確に測定できますが、分散キャッシュの最大スループットを測定するには、キャッシュに同時にアクセスする複数のスレッドをテストで利用する必要があり、可能であれば複数のテスト・クライアントも利用します。単一のスレッドによるテストでは、クライアント・スレッドは当然、所要時間の大半をネットワークでの単純な待機に費やします。複数のクライアントとスレッドを実行すると、複数のリクエストを並列的に発行することによって、使用可能な処理能力をより効率的に利用できます。各処理のデータ密度を向上させるには、バッチ処理を使用することもできます。スレッドを追加すると、CPUまたはネットワークの利用が最大限度に達するまで、その期間の全体的な待機時間が一定に保たれ、スループットが引き続き向上することがわかります。

スケーラビリティの実証

クラスタ・サイズの拡大に応じた真に直線的なスケーラビリティを示すには、単にJVMをクラスタに追加するのみでなくハードウェアの追加もできるように準備する必要があります。単一のマシンにJVMを追加しても、CPUまたはネットワークを最大限に活用する程度までのスケール・アップしかできません。

3台以上のキャッシュ・サーバー(記憶域が有効なノード)を使用したクラスタのテストを計画します。キャッシュ・サーバーを1台から2台に拡張した場合と2台から4台に拡張した場合とでは、示されるスケーラビリティが異なります。その理由は、デフォルトのCoherenceでは、キャッシュに書き込まれたデータのそれぞれに対してバックアップ・コピーが1つ保持されるためです。バックアップの保持プロセスは、記憶域が有効なノードがクラスタ内に2つ存在する場合にのみ開始されます(バックアップを配置する場所が必要です)。このため、1台から2台に移行すると、put操作のように変化が生じる操作に要する作業量が実際に2倍になりますが、3台以上になると作業量は変動せず、ノード全体に均等に分散されます。

環境のチューニング

クラスタを最大限に活用するには、環境およびJVMをチューニングしておくことが重要です。第45章「パフォーマンス・チューニング」は、環境を最大限に利用するための良い手引きとなります。たとえば、CoherenceにはWindows用のレジストリ・スクリプト(optimize.reg)があり、これによっていくつかの重要な設定が調整され、Windowsのデータ速度を大幅に上げることができます。

大規模なクラスタでの測定

次のグラフは、100台のマシンで構成される環境における1つのクラスタのスケール・アウトの結果を示しています。この環境でCoherenceは、ネットワークの切替えインフラストラクチャの限度までスケーリングできました。ここでは、12台までのマシンで構成されたセットが8つあり、それぞれのセットには中央のスイッチに対して4GBのリンクが設定されました。したがってこのテストでは、Coherenceのネットワーク・スループットが、使用可能な帯域幅が最大限度になる32台のマシンまでスケール・アップし、33台以上になると、合計のデータ容量において引き続きスケーリングされています。

図42-1 Coherenceのスループットとマシン台数の比較

図42-2 Coherenceの待機時間とマシン台数の比較

ペイロードが次のペイロード・サイズの1000倍であるため、10MBの操作の待機時間(300ミリ秒まで)は、表示上の理由によりグラフに含まれていません。