Loading article…
パフォーマンスエンジニアリングとは、システム開発ライフサイクルにおいて、スループット、レイテンシ、メモリ使用量などの非機能要件を満たすために適用される技術の総称です。システムエンジニアリングにおいてはシステムパフォーマンスエンジニアリング、ソフトウェアエンジニアリングにおいてはソフトウェアパフォーマンスエンジニアリングまたはアプリケーションパフォーマンスエンジニアリングと呼ばれることもあります。
アプリケーションの成功とビジネスの成功との関連性が、特にモバイル分野でますます認識されるようになるにつれ、アプリケーションパフォーマンスエンジニアリングは、ソフトウェア開発ライフサイクルにおいて予防的かつ改善的な役割を担うようになりました[ 1 ]。そのため、この用語は通常、非機能要件を効果的にテストし、サービスレベルの遵守を確保し、展開前にアプリケーションのパフォーマンスを最適化するために必要なプロセス、人材、およびテクノロジーを説明するために使用されます。
パフォーマンスエンジニアリングという用語は、ソフトウェアやサポートインフラストラクチャだけでなく、より広範な領域を包含するため、マクロ的な視点から見るとパフォーマンスエンジニアリングという用語の方が適切です。非機能要件への準拠は、本番システムを監視することによって、導入後にも検証されます。これはITサービスマネジメントの一部です（ ITILも参照）。
パフォーマンスエンジニアリングは、多くの大企業において独立した専門分野として確立されており、その業務内容はシステムエンジニアリングとは別個でありながら並行して進められている。パフォーマンスエンジニアリングは組織全体に浸透しており、複数の組織部門の人々が関わっているが、特に情報技術部門においてその役割が顕著である。
この手法は複数の方法論に適用されるため、以下の活動はそれぞれ異なるフェーズで行われます。ただし、合理的統一プロセス（RUP）のフェーズを枠組みとして使用する場合は、活動は次のように行われます。
プログラムまたはプロジェクトの最初の概念化フェーズでは、重要なビジネスプロセスが特定されます。通常、収益価値、コスト削減、またはその他の割り当てられたビジネス価値に基づいて、重要なプロセスとして分類されます。この分類は、IT組織ではなく、ビジネスユニットによって行われます。システムパフォーマンスに影響を与える可能性のある高レベルのリスクが、この段階で特定され、記述されます。たとえば、特定のベンダーシステムの既知のパフォーマンスリスクなどが挙げられます。最後に、詳細化フェーズに向けて、パフォーマンス活動、役割、および成果物が特定されます。活動とリソースの割り当ては、詳細化フェーズのプロジェクト計画に組み込まれます。
この定義段階では、重要なビジネスプロセスが重要なユースケースに分解されます。必要に応じて、プローブケースはさらに分解され、単一ページ（画面）遷移にまで細分化されます。これらは、スクリプト駆動型のパフォーマンス テストの対象となるユースケースです。
パフォーマンスエンジニアリングに関連する要件は、非機能要件（NFR）と呼ばれます。機能要件は、どのような業務操作を実行するかに関するものですが、パフォーマンス関連の非機能要件は、定義された条件下でその業務操作がどれだけ速く実行されるかに関するものです。
このフェーズの初期段階では、パフォーマンスツールに関連するいくつかの活動が必要となります。これには以下が含まれます。
パフォーマンス テスト チームは通常、開発環境ではなく、計画された本番環境にできるだけ近いように構成された専用の事前展開環境でパフォーマンス テストを実行します。このチームはテスト ケースに対してパフォーマンス テストを実行し、重要なユース ケースが指定された非機能要件に準拠していることを検証します。チームは、通常想定される負荷 (中央値) とピーク負荷の両方に対して負荷テストを実行します。また、システムのボトルネックを特定するためにストレス テストを実行することもよくあります。収集されたデータと分析結果は、パフォーマンス チューニングを行うグループにフィードバックされます。必要に応じて、システムはチューニングされ、非機能要件に準拠していないテストが適合するように調整されます。
これまでのプロジェクトの各イテレーションおよびフェーズにおいて、パフォーマンスエンジニアリングが適切に適用されていれば、システムがパフォーマンス認証を取得できるはずです。しかし、何らかの理由（例えば、適切なパフォーマンスエンジニアリングの作業手順が適用されなかった場合など）で、コンプライアンスに適合するように調整できないテストがある場合は、システムの一部を開発部門に戻してリファクタリングを行う必要があります。場合によっては、ハードウェアを追加することで問題を解決できますが、ハードウェアを追加してもすぐに効果が薄れてしまいます。
この最終段階では、システムが本番環境に展開されます。そのためには、いくつかの準備手順が必要です。これには以下が含まれます。
新システムが導入されると、継続的な運用では、以下のようなパフォーマンス活動が行われます。
運用領域（本番環境への展開後）におけるパフォーマンスエンジニアリングは、主にサービスレベル管理、キャパシティ管理、問題管理の3つの分野に焦点を当てています。
サービスレベル管理の分野において、パフォーマンスエンジニアリングは、サービスレベル契約（SLA）および、サービスレベル遵守の検証、問題の検出、傾向の特定に役立つ関連システム監視に関係します。例えば、リアルユーザー監視（RUM）を導入すると、ユーザー取引が指定された非機能要件に準拠して実行されていることを確認できます。取引応答時間はデータベースに記録され、そのデータに対してクエリやレポートを実行できます。これにより、キャパシティ管理に役立つ傾向分析が可能になります。ユーザー取引が規定の範囲外になった場合、アラートが生成され、状況に注意を払うことができます。
キャパシティ管理において、パフォーマンスエンジニアリングは、システムがパフォーマンス基準を満たす状態を維持することに重点を置いています。これは、過去の監視データに基づいて傾向分析を実行し、将来的に基準を満たさなくなる時期を予測することを意味します。例えば、システムがトランザクション処理速度の低下傾向を示している場合（データセットのサイズの増大、同時ユーザー数の増加、その他の要因が原因となる可能性があります）、いずれシステムはサービスレベル契約で規定された基準を満たさなくなります。キャパシティ管理は、その時点に先立って追加のキャパシティ（CPUの追加、メモリの増設、データベースの新規インデックス作成など）を確保し、傾向線をリセットしてシステムが規定されたパフォーマンス範囲内に収まるようにする役割を担っています。
問題管理の領域において、パフォーマンスエンジニアリングの手法は、パフォーマンス関連の問題の根本原因を解決することに重点を置いています。これには通常、システムチューニング、オペレーティングシステムやデバイスのパラメータ変更、あるいは設計不良やコーディングミスによるパフォーマンス低下を解消するためのアプリケーションソフトウェアのリファクタリングなどが含まれます。
システムがNFRで規定された性能指標を満たしていることを検証する適切なフィードバックを確保するため、主要なシステムには監視サブシステムが必要です。監視サブシステムの計画、設計、設置、構成、および制御は、適切に定義された監視プロセスによって規定されます。その利点は以下のとおりです。
このトレンド分析機能の重要性は過小評価できません。この機能を適切に実装することで、ユーザー負荷とデータセットが徐々に増加するアプリケーションが、特定のユースケースにおける非機能要件を超える時期を予測することが可能になります。これにより、システムを非機能要件の範囲内で稼働させ続けるために必要なリソースの適切な管理、予算編成、調達、および展開が可能になります。