パフォーマンスエンジニアリング

パフォーマンス エンジニアリングには、システム開発ライフサイクル中に適用される、パフォーマンスの非機能要件(スループット、レイテンシ、メモリ使用量など) が満たされるようにする手法が含まれます。システム エンジニアリング内ではシステム パフォーマンス エンジニアリング、ソフトウェア エンジニアリング内ではソフトウェア パフォーマンス エンジニアリングまたはアプリケーション パフォーマンス エンジニアリングと呼ばれることもあります。

アプリケーションの成功とビジネスの成功のつながりが、特にモバイル分野で認識され続けるにつれて、アプリケーション パフォーマンス エンジニアリングは、ソフトウェア開発ライフサイクル内で予防的かつ完璧な^[1]役割を担うようになりました。そのため、この用語は通常、非機能要件を効果的にテストし、サービス レベルを遵守し、展開前にアプリケーション パフォーマンスを最適化するために必要なプロセス、人材、およびテクノロジを表すために使用されます。

パフォーマンス エンジニアリングという用語は、ソフトウェアとそれをサポートするインフラストラクチャだけを網羅するものではないため、マクロな観点からはパフォーマンス エンジニアリングという用語が適しています。非機能要件の遵守も、導入後に実稼働システムを監視することで検証されます。これはIT サービス管理の一部です( ITILも参照)。

パフォーマンス エンジニアリングは、多くの大企業で独立した分野となり、システム エンジニアリングとは別個に並行して業務を遂行しています。パフォーマンス エンジニアリングは広く普及しており、複数の組織単位の人々が関与していますが、主に情報技術組織内で行われています。

• システムが必要な時間枠内で取引を処理できるようにすることで、ビジネス収益を増加します。
• パフォーマンス目標の達成に失敗したためにシステム開発の努力を廃棄し損なう必要のあるシステム障害を排除する
• パフォーマンスの問題によるシステム導入の遅れを排除
• パフォーマンスの問題による避けられないシステム再作業をなくす
• 避けられないシステム調整作業を排除
• 追加の不要なハードウェア取得コストを回避する
• 運用時のパフォーマンス問題によるソフトウェア保守コストの増加を削減
• アドホックなパフォーマンス修正によって影響を受けるソフトウェアによるソフトウェア保守コストの増加を削減
• パフォーマンスの問題によるシステムの問題を処理するための追加の運用オーバーヘッドを削減
• プロトタイプのシミュレーションにより将来のボトルネックを特定する
• サーバー能力の向上

この分野は複数の方法論に適用されるため、次のアクティビティは、それぞれ異なるフェーズで発生します。ただし、合理的統合プロセス(RUP) のフェーズをフレームワークとして使用すると、アクティビティは次のように発生します。

プログラムまたはプロジェクトの最初の概念フェーズでは、重要なビジネス プロセスが特定されます。通常、これらは収益価値、コスト削減、またはその他の割り当てられたビジネス価値に基づいて重要として分類されます。この分類は、IT 組織ではなく、ビジネス ユニットによって行われます。この時点で、システム パフォーマンスに影響を与える可能性のある高レベルのリスクが特定され、説明されます。例としては、特定のベンダー システムの既知のパフォーマンス リスクが挙げられます。最後に、詳細化フェーズのパフォーマンス アクティビティ、役割、成果物が特定されます。アクティビティとリソースの負荷は、詳細化フェーズのプロジェクト計画に組み込まれます。

この定義フェーズでは、重要なビジネス プロセスが重要なユース ケースに分解されます。プローブ ケースは、必要に応じて、単一ページ (画面) 遷移にさらに分解されます。これらは、スクリプト駆動型パフォーマンス テストの対象となるユース ケースです。

パフォーマンス エンジニアリングに関連する要件の種類は、非機能要件 (NFR) です。機能要件はどのビジネス オペレーションを実行するかに関連しますが、パフォーマンス関連の非機能要件は、定義された状況下でそのビジネス オペレーションがどれだけ速く実行されるかに関連します。

このフェーズの早い段階では、パフォーマンス ツールに関連するいくつかのアクティビティが必要です。これには次のものが含まれます。

• 選択したツールに関する主題の専門家として主要な開発チーム メンバーを特定します。
• 開発/コンポーネント単体テスト環境のプロファイリングツールを指定します。
• 開発/コンポーネント ユニット テスト環境用の自動化されたユニット (コンポーネント) パフォーマンス テスト ツールを指定します。これは、開発中のコンポーネントを駆動するための GUI がまだ存在しない場合に使用されます。
• 開発/コンポーネント単体テスト環境のサーバー側ユニット (コンポーネント) を駆動するための自動化ツールを指定します。
• 開発/コンポーネント単体テスト環境用に、自動化されたマルチユーザー対応のスクリプト駆動型エンドツーエンド ツールを指定します。これは、画面駆動型のユースケースを実行するために使用されます。
• 開発/コンポーネント単体テスト環境用のデータベース テスト データ ロード ツールを特定します。これは、データベース オプティマイザーが正しい実行パスを選択し、必要に応じてデータベースの再初期化と再ロードを可能にするために必要です。
• 開発チーム向けのパフォーマンス ツールを展開します。
• 選択したツールについて、開発チームのメンバーにプレゼンテーションとトレーニングを行う必要があります。

パフォーマンス テスト チームは通常、開発環境でパフォーマンス テストを実行せず、計画された運用環境に可能な限り近くなるように構成された特殊な展開前環境で実行します。このチームは、テスト ケースに対してパフォーマンス テストを実行し、重要なユース ケースが指定された非機能要件に準拠しているかどうかを検証します。チームは、通常予想される (中央値) 負荷とピーク負荷に対して負荷テストを実行します。多くの場合、システムのボトルネックを特定するストレス テストを実行します。収集されたデータと分析は、パフォーマンス チューニングを行うグループにフィードバックされます。必要に応じて、非機能要件に準拠していないテストを非機能要件に準拠するようにシステムが調整されます。

パフォーマンス エンジニアリングがプロジェクトの各反復とフェーズでこの時点で適切に適用されていれば、システムがパフォーマンス認定を受けるにはこれで十分でしょう。ただし、何らかの理由 (適切なパフォーマンス エンジニアリング作業方法が適用されなかったなど) で、コンプライアンスに適合するように調整できないテストがある場合は、システムの一部を開発に返してリファクタリングする必要があります。ハードウェアを追加することで問題を解決できる場合もありますが、ハードウェアを追加するとすぐに収益が減少することになります。

この最終フェーズでは、システムが実稼働環境に導入されます。いくつかの準備手順が必要です。これには次のものが含まれます。

• 基本チェックリストとパフォーマンステスト環境で特定された最適化に従って、オペレーティングシステム、ネットワーク、サーバー（アプリケーション、Web、データベース、ロードバランサーなど）、およびメッセージキューイングソフトウェアを構成する
• すべてのパフォーマンス監視ソフトウェアが展開され、構成されていることを確認する
• 本番データのロードが完了した後にデータベースで統計を実行する

新しいシステムが導入されると、継続的な運用によって次のようなパフォーマンス アクティビティが開始されます。

• 週次および月次パフォーマンスレポートで、重要なユースケースが指定された非機能要件基準内で実行されていることを検証する
• ユースケースがNFR基準から外れている場合は、欠陥を提出する
• 月次および四半期レポートから予測される傾向を特定し、四半期ごとにキャパシティプランニング管理活動を実行します。

運用ドメイン (ポストプロダクション展開) では、パフォーマンス エンジニアリングは主に、サービス レベル管理、容量管理、問題管理の 3 つの領域に重点を置いています。

サービス レベル管理の分野では、パフォーマンス エンジニアリングは、サービス レベル契約と、サービス レベルのコンプライアンスの検証、問題の検出、傾向の特定に役立つ関連システム監視に関係します。たとえば、実際のユーザー監視を展開すると、ユーザー トランザクションが指定された非機能要件に従って実行されていることを確認できます。トランザクションの応答時間はデータベースに記録され、データに対してクエリやレポートを実行できます。これにより、キャパシティ管理に役立つ傾向分析が可能になります。ユーザー トランザクションが帯域外になった場合は、イベントによってアラートが生成され、状況に注意を向けることができます。

キャパシティ管理の場合、パフォーマンス エンジニアリングは、システムがパフォーマンス コンプライアンスの範囲内にとどまるようにすることに重点を置いています。つまり、過去の監視で生成されたデータに対して傾向分析を実行し、将来コンプライアンス違反が発生する時期を予測できるようにするということです。たとえば、システムでトランザクション処理が遅くなる傾向が見られる場合 (データ セットのサイズが大きくなる、同時ユーザー数が増える、その他の要因が原因の可能性があります)、ある時点でシステムはサービス レベル アグリーメントで指定された基準を満たさなくなります。キャパシティ管理の役割は、その時点より前に追加のキャパシティ (CPU の追加、メモリの増設、新しいデータベース インデックス作成など) を追加して、トレンド ラインをリセットし、システムが指定されたパフォーマンス範囲内にとどまるようにすることです。

問題管理の領域では、パフォーマンス エンジニアリングの実践は、パフォーマンス関連の問題の根本原因を解決することに重点を置いています。これには通常、システムのチューニング、オペレーティング システムまたはデバイスのパラメータの変更、さらにはアプリケーション ソフトウェアのリファクタリングが含まれ、設計不良やコーディング プラクティスの悪さによるパフォーマンス低下を解決します。

システムが NFR 指定のパフォーマンス メトリックを満たしていることを検証する適切なフィードバックを確実に得るには、主要なシステムには監視サブシステムが必要です。監視サブシステムの計画、設計、インストール、構成、および制御は、適切に定義された監視プロセスによって指定されます。利点は次のとおりです。

• ユースケース レベルでサービス レベル契約を確立することが可能です。
• 定期的なポイントで監視をオン/オフにしたり、問題解決をサポートしたりすることが可能。
• 定期的なレポートの生成が可能になります。
• これにより、ユーザー負荷の増加やデータセットの拡大がユースケース レベルのパフォーマンスに与える影響など、時間の経過に伴う傾向を追跡できるようになります。

このトレンド分析コンポーネントの価値は過小評価できません。この機能を適切に実装すると、徐々に増加するユーザー負荷と成長するデータ セットにさらされている特定のアプリケーションが、特定のユース ケースの指定された非機能パフォーマンス要件を超える時期を予測できるようになります。これにより、非機能パフォーマンス要件のパラメータ内でシステムを実行し続けるために必要なリソースの適切な管理予算、取得、および展開が可能になります。

• Java パフォーマンス
• スケーラビリティ
• ソフトウェアの品質
• ソフトウェアテスト
• ウェブパフォーマンス

• データベースパフォーマンスチューニングガイド
• 実践的なパフォーマンスアナリスト - パフォーマンスエンジニアリングコミュニティと知識体系
• パフォーマンスエンジニアリングの方法論
• パフォーマンスエンジニアリング戦略
• パフォーマンスプロセス成熟度モデル
• すべてのコンピュータのパフォーマンスブック
• パフォーマンスエンジニアリングのための UML の探求
• モデリングベースのパフォーマンスエンジニアリング入門
• ITILを活用してアプリケーションパフォーマンスを向上
• パターンと実践パフォーマンスエンジニアリング
• 分散ソフトウェアアーキテクチャのパフォーマンスとスケーラビリティ
• パフォーマンス エンジニアリングのベスト プラクティス (高レベル)
• ソフトウェアエンジニアリングとパフォーマンス: ロードマップ
• コンピュータシステムのパフォーマンスとIT運用コストの悪循環
• Microsoft Windows Server パフォーマンス チーム 2010-05-04 にWayback Machineでアーカイブ
• パフォーマンス要件の収集
• Web サービスのパフォーマンス テスト: 戦略とベスト プラクティス
• アプリケーション応答測定 (ARM) 標準を使用した航空管制システムのパフォーマンス評価
• ITILにおけるパフォーマンス管理の統合