3 パフォーマンス計画

パフォーマンス向上のために何を犠牲にするのかを判断するには、パフォーマンス目標の達成に向けて明確に定義された計画が不可欠です。

親トピック: 概要

3.1 パフォーマンス計画について

パフォーマンスを最大化するには、アプリケーションで使用されるすべてのコンポーネントのモニタリング、分析およびチューニングを行う必要があります。

通常、パフォーマンス・チューニングには一連のトレードオフが伴います。ボトルネックの原因を特定した後、他の分野のパフォーマンスを調整しないと、期待される成果が得られない場合もあります。ただし、パフォーマンス目標の達成に向けての明確な計画があれば、最も重要な分野がはっきりするため、パフォーマンス向上のために何を犠牲にするかを判断しやすくなります。

3.2 パフォーマンス計画の方法

Fusion Middlewareコンポーネントは、パフォーマンスおよびスケーラビリティを考慮して構築されています。アプリケーションのパフォーマンス機能を最大限に高めるには、パフォーマンスおよびスケーラビリティを設計に組み込む必要があります。パフォーマンス計画は、現在のパフォーマンス要件を満たし、既知の問題(ボトルネックやハードウェア・リソースの不足など)を解決し、負荷、ユーザーまたはプロセスの予期される変化に対応するものであることが必要です。また、パフォーマンスに影響を与えることなく、ピーク時にコンポーネントを拡張する方法も示す必要があります。

3.2.1 ステップ1: パフォーマンス目標の定義

アプリケーションのパフォーマンス・チューニングを始める前に、まず達成しようとするパフォーマンス目標を明確化する必要があります。パフォーマンス目標を決定するには、デプロイするアプリケーションおよびシステムの環境面での制約を理解する必要があります。

パフォーマンス目標は、次のような制約によって制限されます。

ハードウェアおよびソフトウェアの構成(CPUタイプ、ディスク・サイズ、ディスクの処理速度、十分なメモリーなど)。

ハードウェア要件を決定する式は、1つではありません。アプリケーションのニーズを十分に満たすために必要なハードウェアおよびソフトウェアの構成を決定するプロセスをキャパシティ・プランニングと呼びます。

キャパシティ・プランニングでは、システムのパフォーマンス目標の評価およびアプリケーションの理解が必要です。サーバーのハードウェアのキャパシティ・プランニングでは、最大パフォーマンス要件に重点をおく必要があります。
ピーク使用量やレスポンス時間に対応した高可用性アーキテクチャの構成。Oracle Fusion Middlewareアプリケーションに高可用性機能を実装する方法の詳細は、『高可用性ガイド』を参照してください。
ドメイン間での相互運用、レガシー・システムの使用、およびレガシー・データのサポートが可能かどうか
開発、実装、およびメンテナンスの費用

これらの制約とそれぞれの影響を理解することで、レスポンス時間、スループット、特定のハードウェアにかかる負荷など、アプリケーション環境にとって現実的なパフォーマンス目標を確実に設定できます。

3.2.1.1 運用要件の定義

Oracle Fusion Middlewareにアプリケーションをデプロイしてチューニングする作業を始める前に、運用環境を明確に定義しておくことが重要です。運用環境は、次のような大まかな制約および要件によって決まります。

アプリケーション・アーキテクチャ
セキュリティ要件
ハードウェア・リソース

3.2.1.2 パフォーマンス目標の明確化

新しいシステムを設計するのか、既存のシステムをメンテナンスするのかにかかわらず、具体的なパフォーマンス目標を設定して、最適化の方法と対象を知っておいてください。パフォーマンス目標を決定するには、デプロイするアプリケーションおよびシステムの環境面での制約を理解する必要があります。

アプリケーションのコンポーネントの条件にかなうアクティビティのレベルに関する情報を収集してください。これには次のものが含まれます。

予想ユーザー数
リクエストの数およびサイズ
データの量および一貫性
目標とするCPU使用率

3.2.1.3 ユーザーの期待の理解

アプリケーション開発者、データベース管理者およびシステム管理者は、ユーザーのパフォーマンスへの期待を注意深く適切に設定する必要があります。システムで特に複雑な処理を実行している場合は、単純な処理を実行している場合よりレスポンス時間が長くなります。ユーザーには、どの処理に時間がかかるかを知らせておく必要があります。

たとえば、ユーザーの90%に対するレスポンス時間を5秒以内、すべてのユーザーに対する最大レスポンス時間を20秒に抑えようと考えているとします。通常、これは簡単なことではありません。アプリケーションでは様々な処理が実行され、特性も許容されるレスポンス時間も処理ごとに異なります。各処理について、測定可能な目標を設定する必要があります。

負荷の変動がレスポンス時間に与える影響も調べる必要があります。たとえば、ユーザーによるシステムへのアクセスが午前9時から10時の間に集中し、午後1時から2時の間に再度集中するとします(図3-1のグラフを参照)。負荷のピークが定期的に(毎日、毎週など)発生する場合は、システムの構成およびチューニングを負荷のピーク時の要件に合せて行うのが一般的です。オフピーク時にアプリケーションにアクセスしたユーザーに対するレスポンス時間は、ピーク時のユーザーの場合より短くなります。負荷のピークが頻繁に発生しない場合は、負荷のピーク時のレスポンス時間が長くなっても許容し、小規模なハードウェア構成でコストを削減することも考えられます。

図3-1 キャパシティおよび機能面での需要の調整

「図3-1 キャパシティおよび機能面での需要の調整」の説明

3.2.1.4 パフォーマンス評価の実施

パフォーマンス目標およびパフォーマンスへの期待が明確に定義されていれば、パフォーマンスのチューニングが成功したかどうかを容易に判断できます。成功を左右するのは、ユーザー・コミュニティに対して設定した機能面での目標、基準が満たされたかどうかを判断する能力、および例外事項を解決するための対策を講じる能力です。

継続的にパフォーマンスをモニタリングすることで、十分にチューニングされたシステムを維持できます。アプリケーションのパフォーマンスの履歴を記録することで、有効な比較が可能になります。様々な負荷に対する実際のリソース消費データを使用すれば、客観的なスケーラビリティ調査を実施し、その結果から予想される負荷のボリュームに合せたリソース要件を予測することができます。パフォーマンス評価の詳細は、モニタリングを参照してください。

3.2.2 ステップ2: パフォーマンスおよびスケーラビリティを考慮したアプリケーションの設計

優れたパフォーマンスの鍵となるのは優れた設計です。アプリケーション開発サイクルにおける設計フェーズは、継続的なプロセスとして実施する必要があります。アプリケーション開発サイクルの中で計画、モニタリング、チューニングのフェーズを繰り返すことは、Fusion Middlewareのデプロイメント全般にわたって最適なパフォーマンスを得るうえで不可欠です。反復型の設計手法を使用することで、パフォーマンス目標に影響を与えずにワークロードの変化に対応できます。

3.2.3 ステップ3: パフォーマンス・メトリックのモニタリングおよび測定

Oracle Fusion Middlewareには、サーバーとアプリケーションのパフォーマンスのモニターに使用できる各種テクノロジおよびツールが用意されています。モニタリングを行うことで、サーバー・アクティビティの評価、傾向の観察、システムのボトルネックの診断、パフォーマンスに問題のあるアプリケーションのデバッグ、およびシステムのチューニングに役立つデータの収集が可能になります。詳細は、モニタリングを参照してください。

パフォーマンス・チューニングの内容は、システムにデプロイしたアプリケーションやリソースによって異なります。一般的なチューニング分野については、主なパフォーマンス分野で説明しています。

注意:

Oracle WebLogic Serverのパフォーマンスのチューニング

『Oracle Fusion Middlewareの管理』