コードジンのヘッダーが入ります
「システムの機能要件と性能要件は相反する関係にあり、機能的に複雑になるほど性能は落ちます。本来は両者をバランスよく満たすシステム設計が必要なのですが、多くの場合、性能要件が忘れ去られている、もしくは後まわしにされているのが実情です」。エンピレックス 副社長の山岡英明氏は、Webアプリケーションの性能問題の前提をそう指摘した上で、同社が性能検証を担当したいくつかの事例を紹介した。
ほとんどのプロジェクトにおいて、性能テストはテスト工程の最終フェーズで実施される。そのため、問題が発見されても当初の開発期間内に解決できるケースはほとんどない。たとえば、ある大手エンドユーザーからリリース4ヵ月前に性能検証依頼を受けた事例では、アプリケーションサーバの致命的な問題が発覚したが、その不具合解決に4ヵ月を要したため、リリースを当初の予定から大幅に遅らせなければならなかった。このケースでは、そもそも上流工程で性能要件の打ち合わせ自体が行われなかったという。
また、性能要件が「非機能要件」として扱われることから問題が発生したケースもあった。非機能要件は設計段階で数値化されないため、プログラム設計の設計書には性能要件がまったく反映されないことになる。この結果、エンドユーザーとシステムインテグレータの間では性能目標が設定されていたものの、実際に開発を担当したチームにはそれが伝わらず、機能要件のみを満たすプログラムが作成された。やはりエンピレックスの性能検証で不具合が発見され、6ヵ月かけて修正することになったという。
このような事態を未然に防ぐためには、「まず、上流工程で性能要件を明確に定義すること。つまり要件定義から性能管理を始めることが必要です」と、山岡氏は語る。そして、性能要件の定義で決定すべき主な項目としては、「最大同時アクセスユーザー数」、「1秒あたりの最大処理ページ数」、「主要なページの平均応答時間」、「高負荷時に許容されるエラー率」を挙げた。最大同時アクセスユーザー数はメモリに直接依存し、1秒あたりの最大処理ページ数はCPUの能力に関係する。つまり、システム設計段階から性能要件を考慮してサーバスペックを決定する必要があるということだ。
そして、Webアプリケーションの性能問題を解決するもう1つのポイントが、負荷テスト(性能テスト)で十分な検証を行うことである。この負荷テストでは、単に○か×かを判別するのではなく、Webアプリケーションの限界性能値を見極めてボトルネックを検出し、性能最適化を図ることが重要な目的となる。山岡氏は負荷テストにおける留意点として、テスト期間を最低2週間は確保すること、アプリケーション開発者やDB開発者、ネットワーク管理者もテストに立ち会い、その場で問題を切り分けること、ボトルネック検出のための情報収集は基本的なサーバリソース計測から始めて、詳細な情報は次のステップで収集すること、などを挙げた。
こうした負荷テストのための専用ツールとして、エンピレックスでは「e-Load」を提供。同分野において国内トップシェアの製品として知られている。「エンピレックスのWebサイト」では、e-Loadをはじめとしたテストツールの無償評価版や、我々のノウハウをまとめたホワイトペーパーなどのダウンロードサービスをご用意しています。ぜひ、ご利用ください」と山岡氏は最後に紹介し、セッションを結んだ。