キャパシティ プランニングとパフォーマンス チューニング

     前  次    新しいウィンドウで目次を開く   
ここから内容

キャパシティ プランニング プロセス

キャパシティ プランニング プロセスはいくつかの手順で構成されます。以下の節では、これらの手順について説明します。

注意 : このガイドで説明するテストは、適切に管理された環境で実行したものです。個別環境でテストを実行した場合に得られる数値は、ここに示されているテスト結果の数値と異なる場合があります。これらの数値は、キャパシティ プランニング プロセスを分かりやすく説明するためのものです。

 


WLI アプリケーションの設計

ここでは、アーキテクトや開発者が WLI アプリケーションを設計する際に、パフォーマンスの面で留意すべき事項について説明します。

通常、非同期処理は、時間のかかるプロセスで大きな効果を発揮します。一方、同期処理は、あまり時間のかからないタスクに向いています。ただし、同期プロセスがブロックされるアプリケーションではそれがボトルネックとなり、サーバで必要以上のスレッドが使用される結果になる場合があります。

注意 : パフォーマンスに影響する可能性のある設計上の留意事項については、『WLI アプリケーション ライフ サイクルのベスト プラクティス』および「WLI のチューニング」で詳しく説明しています。

 


環境のチューニング

WLI アプリケーションのパフォーマンスは、アプリケーションの設計だけでなく、それを実行する環境にも大きく左右されます。

環境には、WLI サーバ、データベース、オペレーティング システムとネットワーク、および JVM が含まれます。良好なパフォーマンスを実現するには、すべての構成要素を適切にチューニングする必要があります。

 


アプリケーションのパフォーマンス テストの準備

アプリケーションのパフォーマンス テストを実行したり、負荷生成スクリプトでアプリケーションを呼び出したりするには、アプリケーションを少し変更しなければならない場合があります。

どの程度の変更が必要になるかは、アプリケーションの性質、ロード ジェネレータの性能、キャパシティ プランニング プロセスにどのような成果を期待するか、などによって異なります。

以下に、必要となる変更の例を示します。

 


作業負荷の設計

パフォーマンス テストの品質は、使用する作業負荷によって大きく左右されます。

作業負荷は、システムが完了できると想定される処理の量です。つまり、システムでどのくらいのアプリケーションを実行できるか、何人のユーザがシステムに接続して処理を実行できるかです。

作業負荷は、できるだけプロダクション環境に近い状態になるように設計する必要があります。

作業負荷を設計する際は、以下の要素を考慮に入れる必要があります。

次の節では、作業単位と SLA を定義します。

 


作業単位と SLA の定義

サービス レベル アグリーメント (SLA) とは、許容できる (許容できない) サービス レベルを定義したもので、サービスのプロバイダとコンシューマの間で契約として締結します。通常、SLA は応答時間やスループット (1 秒あたりのトランザクション数) を基準として定義されます。

同期型のシステムの場合、応答時間の要件 (現実的にはトランザクションの 95% 程度) を満たしたうえで、最大のスループットを達成できるようにシステムをチューニングすることが目標となります。したがって、応答時間が SLA になります。非同期型のシステムの場合は、スループットまたは 1 秒あたりのメッセージ数が SLA になります。

キャパシティ プランニングの目的に照らすと、キャパシティ プランニングに基づいて SLA を定義する前に、作業単位 (各トランザクションに含まれるアクティビティのセット) を定義することが重要になってきます。

次の図に示す注文アプリケーションを考えてみましょう。

図 2-2 作業単位 : 注文アプリケーション

作業単位 : 注文アプリケーション

各ノードは JPD です。すべての JPD は、注文処理に必要なプロセスです。このケースでは、作業単位 (トランザクション) の定義として以下が考えられます。

各 JPD ではなく、ビジネス処理のフロー全体を単一の作業単位とみなすことをお勧めします。

次の手順では、負荷生成スクリプトを設計します。

 


負荷生成スクリプトの設計

負荷生成スクリプトは、テストを実行する際に、設計した負荷をサーバにかけるために必要となります。

注意 : テストの実行方法の詳細については、「ベンチマーク テストの実行」および「スケーラビリティ テストの実行」を参照してください。

負荷生成スクリプトの記述にあたっては、以下の点に留意する必要があります。

各仮想ユーザは処理中のリクエストを 1 つしか持たないと制限することで、負荷レベルの把握と管理が容易になります。リクエストの送信率を制御できないと、フロー バランスを超えるペースで送信され続け、キュー オーバーフローなどの問題につながる可能性があります。

次の図には、単一のユーザが、以前のリクエストがサーバによって処理された後にのみ、次のリクエスト送信する場合を示します。

図 2-3 バランスのよい負荷生成スクリプト

バランスのよい負荷生成スクリプト

この方法であれば、同時ユーザの数を増やすことで、システムでの受信率 (システムへの負荷) を増やすことができます。システムに悪影響を及ぼすことがないため、システムの性能を正確に計測できます。

次の図には、単一のユーザが、以前のリクエストの処理をサーバが完了するのを待つことなく、新しいリクエストを送信する場合を示します。

図 2-4 制限が設けられておらず、スループットよりも受信率が大きいスクリプト

制限が設けられておらず、スループットよりも受信率が大きいスクリプト

この方法では、キュー オーバーフローなどの問題が発生し、システムの性能を見誤るおそれがあります。

バランスのよい負荷生成スクリプトを設計することをお勧めします。

 


テスト環境のコンフィグレーション

外部要因による影響を排除してテスト結果の信頼性の高めるため、以下の説明に従ってテスト環境をコンフィグレーションする必要があります。

 


ベンチマーク テストの実行

ベンチマーク テストを実行すると、システムのボトルネックを特定し、システムを適切にチューニングできるようになります。

ベンチマーク テストでは、スループットがそれ以上増えなくなるまで、徐々にシステムへの負荷を増やしていきます。

注意 : ベンチマーク テストの目的に照らし、テストする WLI アプリケーションがシステム リソースを必要とするあらゆる要因を想定した負荷にします (同時ユーザの数、ドキュメントのサイズなど)。
注意 : 負荷を徐々に大きくすることで、システムに急激に大きな負荷をかけないようにする必要があります。
注意 : ベンチマーク テストは、単一の WLI マシンで思考時間なしで実行します。

スループットがこれ以上大きくならなくなると、以下のいずれかの現象が発生します。

次の図に、Mercury LoadRunner による始動スケジュールを示します。最初の 10 分間は、同時ユーザ 10 人でのウォーミングアップ テストです。その後、15 分ごとに 10 人ずつ同時ユーザを追加して負荷を徐々に増やしていきます。

図 2-5 始動スケジュールのテスト

始動スケジュールのテスト

テストの実行中に以下のデータを記録する必要があります。

次の図に、ベンチマーク テストの結果を示します。

図 2-6 ベンチマーク テストの結果

ベンチマーク テストの結果

ユーザを追加するにつれ、平均 TPS (トランザクション/秒) が増大しています。いずれかのハードウェア リソース (ここでは CPU) の使用率が 100% に達すると、平均 TPS もピークに達します。その時点の応答時間が最適解です。さらにユーザを追加すると TPS は減少し始めます。TPS は、負荷が大きくなるにつれほぼ線形に増大しますが、CPU や入出力の制限によってシステムが飽和状態になるとピークに達し、それ以降は減少傾向になることが分かりました。応答時間は、システムが飽和状態になるまでほぼ線形に増大し、その後は非線形に増大します。

このようなテストを実行することで、リソースの使用率が最大値に達したとき、システムがどのように動作するかが分かります。

次の節では、ベンチマーク テストの結果を検証します。

リトルの法則に基づく結果の検証

テスト結果を分析する前に、リトルの法則に基づいて検証し、そのテスト設定におけるボトルネックを特定する必要があります。テスト結果は、リトルの法則を適用した場合の結果と大きく食い違うべきではありません。

複数ユーザ システムの応答時間の算出式は、リトルの法則を用いて導出できます。平均思考時間 z のユーザ n 人が、応答時間 r の任意のシステムに接続しているとします。各ユーザは、思考と応答待ちを繰り返します。したがって、ユーザとコンピュータ システムから構成されるこのメタシステム内のジョブの総数は定数 n となります。

n = x (z + r)

r = n/x - z

n はユーザ数として表される負荷、z + r は平均応答時間、x はスループットです。

注意 : 単位の整合性を維持するようにしてください。たとえば、スループットを TPS で表すのであれば、応答時間は秒で表す必要があります。

結果のスループットを検証するためのヒント

結果の解釈

結果の解釈にあたっては、安定状態のシステムの値のみを考慮します。始動段階や終了段階をパフォーマンス メトリクスに含めないようにしてください。

CPU、メモリ、ハード ディスク、ネットワークなどのリソースの使用率は、スループットが飽和するときにピークになるようにする必要があります。いずれかのリソースがピークに達しない場合は、システムのボトルネックを分析してチューニングしなおします。

ボトルネックの分析とチューニングのヒント

スレッド プールが飽和した時点でリソースにボトルネックが存在しない場合は、アプリケーションやシステムのパラメータがボトルネックになっている可能性があります。こうしたボトルネックの原因としては以下が考えられます。

 


スケーラビリティ テストの実行

新たなハードウェア リソースを追加したときに、それに見合った分確実にパフォーマンスが向上するようであれば、そのシステムはスケーラブルであると考えられます。このようなシステムであれば、ある程度負荷が増大してもパフォーマンスが低下することはありません。負荷の増大に対応するには、ハードウェア リソースを追加する必要があるかもしれません。

アプリケーションについては、マシンを追加することで水平スケーラビリティを強化でき、同じマシンにリソース (たとえば CPU) を追加することで垂直スケーラビリティを強化できます。

水平スケーラビリティと垂直スケーラビリティ

次の表に、水平スケーラビリティと垂直スケーラビリティそれぞれの利点を示します。

表 2-1 水平スケーラビリティと垂直スケーラビリティの相対的な利点
垂直スケーラビリティ
(1 つのマシン内のリソースを増設する)
水平スケーラビリティ
(マシンを増設する)
  • 運用が容易になる
  • 管理しやすくなる
  • システム リソース間の相互接続が効率化される
  • 可用性が高い
  • スケーラビリティに上限がない

アプリケーションのスケーラビリティを強化する必要がある場合は、そのときの要件に応じて水平スケーラビリティ、垂直スケーラビリティ、またはこれらの組み合わせを選択できます。

次の図に、WLI をクラスタ化されていない 4 CPU のマシン 1 台で稼働させた場合 (垂直スケーラビリティ) と、クラスタ化された 2 CPU のマシン 2 台で稼働させた場合 (水平スケーラビリティ) の比較結果を示します。

図 2-7 水平スケーラビリティと垂直スケーラビリティ

水平スケーラビリティと垂直スケーラビリティ

水平スケーラビリティ (2 CPU のマシン 2 台) の場合のパフォーマンスは、垂直スケーラビリティ (4 CPU のマシン 1 台) の場合に比べ少し劣っています。これは、水平スケーラビリティの場合、ロード バランシングとクラスタリングによるオーバーヘッドが余分にかかるためです。しかし、水平スケーラビリティ システムなら、マシンを追加することでキャパシティを広げることができます。これは垂直スケーラビリティ システムでは不可能です。

スケーラビリティ テストの実行

スケーラビリティ テストを実行すると、システムの水平スケーラビリティや垂直スケーラビリティを強化したときに、アプリケーションのスケーラビリティがどうなるかが分かります。この情報に基づいて、特定の状況に対応するためには、どのくらいのハードウェア リソースを追加する必要があるかを推定できます。

スケーラビリティ テストでは、SLA が満たされるか、目標とするリソース使用率に達するまで、徐々に負荷を増やします。

注意 : 一方、ベンチマーク テストでは、スループットがそれ以上増えなくなるまで負荷を増やします。

スケーラビリティ テストを実行する場合は、できるだけプロダクション環境に近い負荷を再現する必要があります。ユーザの介在が必要なく、プロセスの呼び出しをプログラム的に発生させる場合は、ベンチマーク テストの場合のように思考時間をゼロとみなす手法をお勧めします。

SLA を満たす前に目標とするリソース使用率に達した場合は、システムに新たなリソースを追加する必要があります。追加のリソース (垂直スケーラビリティ) またはマシン (水平スケーラビリティ) は、1、2、4、8 のような順序で追加する必要があります。

注意 : キャパシティの推定式の導出には、少なくとも 3 つのデータ ポイントを使用する必要があります。

ベンチマーク テストの実行中に記録されたすべてのデータは、スケーラビリティ テストの実行中にも捕捉する必要があります。詳細については、「ベンチマーク テストの実行」を参照してください。

注意 : 追加のリソース要件を推定する場合は、リソース使用率が目標レベルに最も近づいたときに記録されたデータを使用する必要があります。

テストを実行したら、ベンチマーク テストと同じように検証と分析を行います。追加のリソース要件を推定する必要がある場合は、次の節の説明に従ってください。

 


リソース要件の推定

キャパシティ プランニングを実施すると、現時点での SLA と将来の負荷に基づいて、現在および将来のリソース要件を推定できます。キャパシティ プランを作成するためには、システムの負荷モデルを作成する必要があります。

テスト結果は、この負荷モデルを作成するためのデータ ポイントを提供します。テスト結果から得られる曲線の式を導出し、これを使って必要となる追加ハードウェア リソースを推定します。線形回帰や曲線適合などの手法に基づいて、必要となるリソースを予測します。Microsoft Excel のようなスプレッドシート アプリケーションを使用すると、これらの手法の精度を上げることができます。

注意 : 予測の精度は、負荷モデルの正確さに左右されます。負荷モデルは、アプリケーションの各リソース (CPU など) に基づいて正確に作成する必要があります。
注意 : 過去のパフォーマンス データを使ってモデルを検証することも可能です。

次の図に、水平スケーラビリティ テストの結果を示します。

図 2-8 キャパシティ推定 : 水平スケーラビリティ

キャパシティ推定 : 水平スケーラビリティ

このグラフには、クラスタのノード数が異なると、CPU 使用率 70% の時点での平均 TPS がどう変化するかが示されています。

このスケーラビリティ テストの結果には、線形方程式が最も適合します。最も適合する曲線 R2 は、単位元 (値 1) に近似していなければなりません。

平均 TPS を y、ノード数を x とすると、式は y = 12.636x + 4.065 となります。

注意 : 水平でも垂直でも、リソースを新たに追加することで TPS を上げることはできますが、特定の応答時間を実現したい場合は意味がないかもしれません。そのような場合は、より高速な CPU を検討してください。

スケーラビリティ テストの結果に基づいてチューニングを実施し、要求されるレベルを実現できたら、プロダクション環境にデプロイできるようにアプリケーションをコンフィグレーションします。

注意 : プロダクション環境用に購入することになったリソースとスケーラビリティ テストに使用したリソースでタイプやモデルが異なる場合は、次の式を使ってリソース要件を推定できます。
注意 : E x T1 / T2
注意 : E = スケーラビリティ テストの推定値
注意 : T1 = テストを実行したマシンの SPECint レート
注意 : T2 = 購入したいマシンの SPECint レート
注意 : この式は、CPU 数に基づくスケーラビリティにのみ適用できます。
注意 : SPECint レートを使用した推定はあくまでも概算です。キャパシティ プランニングは、プロダクション環境と同じハードウェア、同じコンフィグレーションで実施することをお勧めします。SPECint レートの詳細については、http://www.spec.org を参照してください。

  ページの先頭       前  次