アジャイルプロジェクトにおけるパフォーマンスエンジニアリング

作者 Vikas Hazrati , 翻訳者 畠山 貴 - (株)永和システムマネジメント 投稿日 2009年4月17日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

Scrum ,

Agile in the Enterprise ,

性能評価 ,

パフォーマンス&スケーラビリティ ,

Agile

共有 |

原文(投稿日：2009/3/25)へのリンク

パフォーマンスエンジニアリング(リンク)は重要なソフトウェア開発規律のひとつだ。パフォーマンスエンジニアリングはアプリケーションがパフォーマンスを考慮したうえで設計、製造、テストされていることを保証する。 しかしながら、従来的なプロジェクトでのパフォーマンスエンジニアリング活動はパフォーマンステストのみに限られているようだ。作業負荷パターンの識別 や、より良いパフォーマンスを引き出すためのプロセス改善が行われることはない。行われることといえば、ストップウォッチを使って特定の条件下でのパ フォーマンスを計測することだけだ。 Balasubramanian氏はスクラムでのパフォーマンスエンジニアリング(リンク)に関して面白い視点を提供している。

Balasubramanian氏はパフォーマンスエンジニアリングで行うべきことの大枠として以下をあげている。

• 非機能要件の収集とその妥当性の検証
• 分析モデルの開発
• パフォーマンステスト戦略の立案
• パフォーマンスベストプラクティスが満たされていることを確認するための、アーキテクチャとアプリケーションコードのレビュー
• アプリケーションが正しく配備されていることのレビュー
• 既存のアプリケーションに対する適切なチューニングを行うための設計とコードのレビュー

パフォーマンスエンジニアリングはアジャイル開発に欠くことのできない活動だと氏は主張しており、その理由として以下のものをあげている。

• パフォーマンスエンジニアリングはシステムに対する迅速なフィードバックをスプリント毎に提供する
• パフォーマンスは誤った印象を与えやすい：アジャイルプロジェクトではさらにそれが顕著である。それぞれのイテレーション内に達成されるいくつものビジネス価値に目を奪われてしまうため、システムの品質に関しては見落とされがちになってしまう。
• リファクタリングによってパフォーマンスの劣化が引き起こされる可能性がある。
• アジャイル開発のゴールは出荷可能かつ製品レベルのクオリティのコード：このゴールへと至るためには、サービスの品質要件を満たすようにシステムが設計さ れ製造され検証されていることを保証する必要がある。そのための手助けをするのがパフォーマンスエンジニアリングである。

Balasubramanian氏はパフォーマンスエンジニアリングをスクラムプロジェクトへ導入するための手引きとして、以下に示す4つのフェーズとフェーズ毎のチェックリストを紹介している(PDF)。

I. 計画ステージ

性能要件を理解するとともに、パフォーマンスエンジニアリングの作業計画を立てる。

• ユースケースとパフォーマンス：すべてのユースケースに対して、どの程度のパフォーマンスが求められているかを理解する。
• パフォーマンステスト戦略：インフラ要件、ツール、許容できるコスト、メトリクスとテスト結果のフォーマットなど、パフォーマンステストの大枠を決める。
• 行うべきパフォーマンスエンジニアリングタスクはプロダクトバックログへ：作業負荷見積り、パフォーマンステスト、パフォーマンス評価などのパフォーマンスエンジニアリング的なタスクは、忘れてしまわないように必ずバックログへ入れておくこと。

II.  システムアーキテクチャフェーズ

機能やビジネスからの要求からだけでなく、システムの品質の観点からもアーキテクチャを検証する。

• アーキテクチャ評価とその観点：品質から目を離さないこと。そのためにも、アーキテクチャは以下の観点から評価されなければならない。
  • Architecture Tradeoff Analysis Method
  • Cost Benefit Analysis Method
  • Active Reviews for Intermediate Design

III. スプリント時

出荷可能で高品質なソフトウェアをスプリント期間内に作りあげるためには以下を行う必要がある。

• 正しくコードを書く：パフォーマンスエンジニアリングの枠内では、通常のコーディングガイドラインとは異なる良いパフォーマンスを出すためのガイドラインが必要となる。
• パフォーマンスユニットテストを作成する：アプリケーションのパフォーマンスをテストするユニットテストをスプリント中に開発者は作成しなければならない。 プロジェクト初期段階ではシステムの進化のスピードが速いため、パフォーマンスユニットテストによって得ることの出来る利益は小さいかもしれない。 しかしシステムが成熟してくるに従ってパフォーマンスユニットテストは段々とその利便性を増してくる。
• 設計とコードをレビューする：JProbeやFxCop(リンク)などのツールを利用してコードレビューを自動化する。また、それを利用してプログラムコードに由来するパフォーマンス問題を事前に検知する。
• パフォーマンステスト実施箇所の特定と自動化：パフォーマンステストを行う箇所の特定とその自動化を事前に行うこと。N回目のスプリントに対しての特定と自動化はN-1回目のスプリントで行うと良いだろう。
• ボトルネックの識別とパフォーマンスの改善：N回目のスプリントで見つかったパフォーマンス上の問題点はN+1回目のスプリントで改善を行うこと。
• パフォーマンスエンジニアリングスプリント：最後に、チームはパフォーマンスエンジニアリングのみを集中して行うスプリントの導入を検討すること。スプリントを2、3回まわす毎にパフォーマンスエンジニアリングスプリントを1回行う。

IV. プロジェクト終盤

完成したアプリケーションを本番環境へとデプロイする。

• パフォーマンスモニタリングシステムのセットアップ：JAMon(リンク)のようなツールを利用したパフォーマンスをリアルタイムにモニタリングする仕組みを本番環境は備えていなければならない。

パフォーマンスエンジニアリングをより導入しやすいものとするために、Scott Barber氏はパフォーマンススペシャリスト向けの詳細なTips(リンク)を提供している。その中で氏はアジャイルプロジェクト内でいかにしてパフォーマンスを 保証するか、いかにして生産性を上げるかについて言及している。

パフォーマンスエンジニアリングの文化をプロジェクトへ根付かせようとするとき、あらゆるプロジェクトが乗り越えなければならない、いくつかの課題があることをBalasubramanian氏は認めている。 その中でももっとも大きな課題は、システムの機能を見るのと同じようにシステムの品質へ目を向ける、というマインドセットの変更である。 だがその報酬は大きい。パフォーマンスエンジニアリングをプロジェクト開始時から適用した場合、投資したコストをはるかに上回る利益が得られるうえに、その利益はスプリントを経るごとに雪だるま式に増加してゆくだろう。