エンピレックス株式会社
副社長
現在のシステム構築では、ブラウザの画面を介したアプリケーションの作成が"当たり前"になっている。その一方、Webアプリケーションの複雑化により、ソフトウェア開発側にはマルチベンダーのプラットフォーム、多重階層への対応、機能要求の多様化への対応という課題が発生した。当然、複雑な機能要件になるほど、性能は落ちる。「ところが性能が本当に意識されるのは、開発の後半か、リリース後というのが現実」とエンピレックスの山岡英明氏は指摘する。
山岡氏はこれまで約10年にわたり、性能の問題に取り組んできた。なぜこだわったのかといえば、性能障害が発生すると多大なコストがかかるからだ。この問題は、インプットに対して求めるアウトプットが常に出ないといった、機能的な不具合とは異なる。たとえば利用者が少ないと通常に動作するのに、ユーザー数が一定数を超えると、突然パフォーマンスが極端に落ちるのが性能障害だ。しかも一見同じ条件で、必ず発生するとは限らない。
性能問題に関する経験が豊富な山岡氏でも「さまざまな機能を組み込んでから行う最後の総合テストや、運用に入ってからのテストをして性能問題の不具合の原因を突き止めるのは一番難しい」と話す。そして性能障害が発生する原因は「テスト不足」と断言する。
性能テストは、性能の不具合を発見し、最終的に性能の最適化、チューニングを行うために行う。当然、プラスαのコストがかかる。たとえば数万のユーザーが同時にアクセスした場合の負荷テストは、エンピレックスのe-Loadのようなツール無しにはできない。そしてテスト自体は短時間で終了するが、テストのシナリオとなるスクリプトを作成するには3日から1週間はかかる。さらに、テスト結果を元にしたチューニングや不具合の修正、再テストによる検証を何回も繰り返す必要がある。山岡氏は「性能の検証、負荷テストは1～2日では絶対終わらない。最低でも二週間というスケジュール組む必要がある」と強調する。
山岡氏は開発の各段階で性能に関するチェックを行わず、最後の本番テストに実施する性能検証の結果は「必ず×になる」と断言する。性能問題の解決を難しくしているのは、状況の再現が困難なことにある。そのため性能の検証では、各部門の担当者がテストに臨席して確認し、その場で解決していく必要がある。
そして山岡氏はツールを使った負荷テストでは「一般ユーザーが使う流れでテストケースを作成する」ことが必要だと指摘する。たとえばコールセンターのシステムであれば、始業と同時にオペレーターが一斉にログインし、検索などの作業が繰り返され、ログアウトは最後になる。テストを実施するためには以上の流れをスクリプト化できなければならない。
一方、負荷テストツールには、フリーのものを含めて各種ある。しかし、ボトルネックを検知すると同時に、クライアントサイドの応答時間、ネットワーク機器や各種サーバーのCPU使用率、メモリーの状態などの情報を取得し、グラフ化して表示するなどの支援機能があるのはやはり、エンピレックスのe-Loadのような有償の製品になる。
ただ、特に最初のテストでは「情報を取得しすぎないこと」がポイントだという。一定の経験を積めば、ページの応答時間やCPUとメモリー、DBではディスクのI/Oぐらいに絞り込んでも、性能のボトルネックがどこに出たか十分に分かる。そこでたとえば問題がAPサーバーにあると分かったら、今度はミクロの情報を取っていけばいい。
Webアプリケーションにおける性能障害は、アーキテクチャの設計にまで戻らなければ修正できないことも珍しくない。山岡氏は「性能目標は、要件定義の時から話し合い、上流工程から組み上げていく必要がある」と提言して、セッションを締めくくった。
エンピレックス株式会社
〒150-0021 東京都渋谷区恵比寿西1-10-11 フジワラビルディング7F
URL http://www.empirix.co.jp/
E-mail eTestJapan@empirix.com
