| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース1(11.1.1) B61006-04 |
|
 前 |
 次 |
キャパシティ・プランニングとは、アプリケーションのニーズを満たすために必要なハードウェアおよびソフトウェアの構成を決定するプロセスのことです。パフォーマンス計画と同様、キャパシティ・プランニングは反復型のプロセスです。優れたキャパシティ管理計画は、負荷データを長期的に監視および測定し、パフォーマンスに影響を与えることなく変化に対処できる柔軟なソリューションを実装するという作業に基づいています。
|
注意: この章の内容は、効果的なキャパシティ管理計画を作成するうえで利用可能な各種手法の概要を示すことを目的としています。実行するステップ、および最終的に作成する計画は、個々の要件やデプロイメント構造によって異なります。 |
次の各項でキャパシティ・プランニングについて概説します。
パフォーマンス・チューニングが既存のシステムを最適化してパフォーマンスを改善することであるのに対し、キャパシティ・プランニングでは、平常時とピーク時両方のパフォーマンスを維持するにはシステムに何が(いつ)必要かを決定します。
キャパシティ・プランニングには、ソリューションの設計および構成のテストに加えて、ビジネスの見通し、周期的な需要の変動、およびアプリケーションの制約を特定する作業が伴います。注意深く計画を立てて、丁寧にテストを行い、パフォーマンスに焦点を当てた設計原則を採用する必要があります。本番環境にアプリケーションをデプロイする前に、アプリケーションに対して厳密なパフォーマンス・テスト・サイクルを実施してください。効果的なキャパシティ管理計画を作成するには、パフォーマンス計画を作成するときと同じステップをいくつか実行します。
ステップ1: パフォーマンス目標の決定
ステップ2: パフォーマンス・メトリックの測定
ステップ3: システムのボトルネックの特定
ステップ4: キャパシティ管理計画の実施
計画を作成する前に、デプロイメント方針を裏付けるデータを集める必要があります。キャパシティ管理計画が効果的なものになるよう、次に示す項目について確認し、得られた情報を注意深く分析してください。
効果的なキャパシティ管理計画を作成するための最初のステップは、ネットワーク負荷およびパフォーマンス目標を決定することです。デプロイするアプリケーション、およびシステムにおける環境面の制約を理解する必要があります。アプリケーションのコンポーネントが達成することを求められるアクティビティ・レベルについて、次のような情報を収集しておくのが理想的です。
予想ユーザー数。
同時セッション数。
必要なSSL接続の数。
リクエストの数およびサイズ。
データの量および一貫性。
目標とするCPU使用率の決定。
パフォーマンス目標は、次のような制約によって制限されます。
ハードウェアおよびソフトウェアの構成(CPUタイプ、ディスク・サイズとディスクの処理速度の比較、十分なメモリーなど)。
ドメイン間の相互運用、レガシー・システムの使用、およびレガシー・データのサポートが可能かどうか。
セキュリティ要件とSSLの使用。SSLには大量の計算処理が伴うため、SSLプロトコルでの暗号化処理をサポートする場合はWebLogic Serverのパフォーマンスに影響が出る可能性があります。
開発、実装およびメンテナンスのコスト。
この情報を基に、レスポンス時間、スループット、特定のハードウェアにかかる負荷など、アプリケーション環境にとって現実的なパフォーマンス目標を設定できます。
28.2項「パフォーマンス目標の決定」でパフォーマンス基準を決定したら、パフォーマンス目標を定量化するためのメトリックを測定します。キー・パフォーマンス・インジケータのベンチマーク・テストを実施することで、パフォーマンスの指針が得られます。Oracle Fusion Middlewareアプリケーションにおけるパフォーマンス・メトリックの測定の詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。
ボトルネック(著しいパフォーマンス低下が見られる分野)は、キャパシティ管理計画の作成中に対処する必要があります。可能であれば、アプリケーションのプロファイリングを行ってボトルネックを正確に特定し、アプリケーションのパフォーマンスを改善します。Oracleでは、次のプロファイラを用意しています。
Oracle JRockit Mission Controlは、JRockit JVMを使用した処理のプロファイリング機能を備えています。
http://www.oracle.com/technology/products/jrockit/missioncontrol/index.html
Oracle Application Diagnosticsは、SUN JDKを使用したJava処理のプロファイリング機能を備えています。
http://www.oracle.com/technology/software/products/oem/htdocs/jade.html
ボトルネックを特定する目的は、ボトルネックをすべて解消することではなく、パフォーマンス目標を満たすことです。システム内のリソースは有限です。本質的に、1つ以上のリソース(CPU、メモリーまたはI/O)がシステムのボトルネックとなる可能性があります。たとえば、予想されるピーク使用量を考慮した計画を立てれば、ボトルネックがパフォーマンス目標に与える影響を最小限に抑えることができます。
システムのボトルネックに対処するにはいくつかの方法があります。一般的なソリューションを次に示します。
クラスタ構成では、複数の同一クラスタ・メンバー・インスタンスにワークロードが分散されます。そのため、分散処理に利用できるリソースの量が何倍にも増えるとともに、シームレスなフェイルオーバーが可能になり、高可用性が実現します。
詳細は、第29章「クラスタおよび高可用性機能の使用」を参照してください。
既存のデータベース接続を使用してパフォーマンスを改善できる場合があります。接続文字列を変更することで、接続数、セッションのタイミング、その他のパラメータを制限できます。
データベース接続プールの構成の詳細は、2.7項「データベース接続の再利用」を参照してください。
これは、ガベージ・コレクションの所要時間と同じハードウェア上で実行可能なJVMの数のトレードオフを可能にする、アプリケーション固有のチューニング項目です。ヒープ・サイズは、大きいほうが使用効率が高く、一般にガベージ・コレクションの回数も少なくなります。JVMプロセスが多ければ、フェイルオーバー・ポイントも多くなります。
詳細は、2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。
単一のハードウェア・リソースにメモリーまたはCPU(あるいはその両方)をより多く集約すれば、同じハードウェアを共有するインスタンス間の通信をローカルに行うことができます。単一マシンの物理メモリーおよび処理能力を増やすことで、JVM(特に64ビットのJVM)を拡張して、格段に大きく、より強力なインスタンスを実行できるようになります。JVMの規模が大きいと、メモリーの使用効率が高まり、ガベージ・コレクションの発生頻度が低下する傾向があります。場合によっては、CPUを追加するとマシンの処理装置で利用できる命令キャッシュおよびデータ・キャッシュが増え、処理効率がさらに向上します。
詳細は、2.2項「十分なハードウェア・リソースの確保」を参照してください。
ネットワーク負荷の高いアプリケーションは、ネットワークを使用する他のアプリケーションで重大なパフォーマンス上の問題が発生する原因となります。時間が重要な意味を持つアプリケーションのネットワーク・トラフィックを、ネットワーク負荷の高いアプリケーションから分離して、別のネットワーク・インタフェースへ転送すれば、パフォーマンスへの影響を軽減できます。様々なネットワーク・インタフェースからのトラフィックにそれぞれ異なる転送優先度を割り当てることも可能です。
特定のハードウェア・リソースで処理可能なキャパシティを計画する際には、オペレーティング・システムがJVMプロセスやその他のシステム・プロセスおよびハードウェア割込みハンドラを効率的にスケジューリングできない場合があることを理解することが重要です。JVMがハードウェア割込みハンドラとCPUコアの一部を共有している場合は、JVMのパフォーマンスに影響が出ることもあります。たとえば、ディスクおよびネットワークへの負荷の高いアプリケーションは、パフォーマンスに対して、CPUにかかる負荷と釣り合わないほどの影響を与えます。さらに、ハードウェア割込みが発生すると、アクティブなJavaスレッドがGCセーフ・ポイントまで効率的に到達できないことがあります。使用頻度の高いハードウェア割込みハンドラを、JVMプロセスを実行するCPUから分離することで、ガベージ・コレクションが開始されるまでの待ち時間を短縮できます。
マルチコア・マシンの複数のCPUを単一のJVM専用にすると、CPUキャッシュの効率が高まって効果的な場合もあります。複数のプロセスが同じCPUを共有する必要がある場合は、データ・キャッシュおよび命令キャッシュの中に両方のプロセスからのデータや命令が混在することになるため、効果的に使用されるキャッシュの量が減少します。ただし、プロセスを特定のCPUコアに割り当てれば、ピーク時の負荷急増の際に他のCPUコアを使用できるようになります。負荷が低いときのCPUの使用効率を高めるのか、それともアクティビティの急増に備えて余分なキャパシティを確保しておくのかを決め、それをキャパシティ管理計画に反映させてください。
パフォーマンス目標の定義、ワークロードの測定、およびボトルネックの特定が済んだら、キャパシティ管理計画を作成して実施する必要があります。計画の目的は、パフォーマンス目標を満たすか、それを上回るパフォーマンスを得ること(特にピーク時)、そして将来のワークロードの増加に対応できるようにすることです。パフォーマンス目標を達成するには、管理計画を実施し、第4章「Oracle Fusion Middlewareの監視」で説明したようにパフォーマンス・メトリックを継続的に監視する必要があります。
デプロイメントはそれぞれ異なるため、すべての構成に当てはまるキャパシティ管理計画の実施方法を説明することはほとんど不可能です。キャパシティ・プランニングは反復型のプロセスであり、計画はワークロードや環境の変化に合せて調整する必要があります。この後の項では、計画の中で考慮する必要のある主な要因を示します。
ハードウェア要件を決定するための唯一の公式などありません。ハードウェアおよびソフトウェアの構成を決定するプロセスでは、システムのパフォーマンス目標を評価し、アプリケーションについて理解することが必要です。サーバー・ハードウェアのキャパシティ・プランニングでは、最大のパフォーマンス要件に焦点を当てる必要があります。
現在のハードウェア要件は変化する可能性があります。計画は、ワークロードの増加、環境の変化(サーバーやサード・パーティ・サービスの追加など)、ソフトウェアのアップグレード(オペレーティング・システム、ミドルウェア、その他のアプリケーション)、ネットワーク接続およびネットワーク・プロトコルを考慮したものであることが必要です。
目標とするCPU使用率は、100%に設定するのではなく、アプリケーションのニーズ(ピーク時のCPUサイクルなど)に基づいて決定してください。通常負荷時のCPU使用率が100%になるように最適化した場合、ピーク時の負荷を処理するキャパシティは残っていません。待機時間の影響を受けやすく、高速のレスポンス時間を維持することが重要な意味を持つアプリケーションでは、CPU使用率が高い(100%に近づく)と、レスポンス時間が短くなる一方で、スループットは一定に保たれるか、向上します。これは、待機中の処理がサーバーにたまるためです。このようなアプリケーションの場合、推奨されるCPU使用率は70から80%です。待機時間の影響を受けないアプリケーションの場合は、90%程度を目標とすることをお薦めします。
メモリー要件は、同じハードウェア上のJVMごとに、ユーザーが使用するアプリケーションの最適なヒープ・サイズによって決まります。最適なヒープ・サイズに加えて、JVMごとに最大500MBが必要です。パフォーマンスへの実際の影響は、JVMのブランドおよび実行するアプリケーションのタイプによって変わります。たとえば、ロードされるJavaクラスが多いアプリケーションには、コンパイル済クラスのために多くの領域が必要になります。ハードウェア・アーキテクチャやオペレーティング・システムによって制限が課される場合、一部のアーキテクチャでは、32ビットのJVMは約3GBの制限を超えることができません。オペレーティング・システム、IOバッファおよび共有メモリー・デバイス用にある程度のメモリーを確保しておくことをお薦めします。
単一のJava仮想マシン(VM)が処理できるユーザー/プロセスの数は、リクエストのタイプおよび実行しているJVMのタイプによって大きく異なります。パフォーマンス監視およびベンチマーク・テストの手順の一環として、実行するプロセスの数および種類を調べ、ハードウェアが特定のJVMの要件を満たしているかどうかを見極めてください。
高いパフォーマンスと信頼性の両方を確保するために、クラスタ構成の複数のノードにわたって、複数の管理対象サーバーを使用することをお薦めします。ただし、管理対象サーバーが複数存在すると、使用するメモリーが増えることに注意してください。そのため、一部のアプリケーションでは特定の操作をメモリー内で最適化できるようになり、ディスク、データベースおよびネットワーク待機時間への影響が軽減されます。
クラスタ構成の使用の詳細は、『Oracle Fusion Middleware管理者ガイド』の管理対象サーバーと管理対象サーバー・クラスタの理解に関する項を参照してください。
持続的なパフォーマンスを確保するためには、アプリケーション・サーバー層の予定キャパシティが増加した場合に、それに合せて既存のデータベースを拡張できるようにする必要があります。データベース・パラメータをチューニングし、ピーク時のデータベース・メトリックを監視することで、既存のデータベース・リソースを拡張して負荷の増加に対処することが可能かどうかを判断できます。メモリーの追加やデータベース・ハードウェア構成のアップグレードが必要になることもあります。Oracleデータベースのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
ただし、メモリーの追加やCPUのアップグレードを行っても、データベースが負荷の増加を効果的に管理できない場合があります。このような状況では、Oracle Real Application Cluster(Oracle RAC)環境をデプロイして増加に対処することを検討してください。Oracle RAC構成は、パフォーマンスの強化だけでなく、信頼性およびスケーラビリティの向上も実現します。Oracle RACの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
