ブログやショッピングサイト、オンライントレードなど、インターネットで「できること」は、ここ数年で大いに増えた。ビジネスにおいても、ブラウザ経由で社内のイントラネットにアクセスし、情報の共有が容易になっている。これらのwebサービスは、総じて「webアプリケーション」と呼ばれるシステムで動いている。インターネット上のサービスの進歩は、ひいてはwebアプリケーションの進歩と言い換えることもできるのだ 。

しかし、webアプリケーションには開発の段階で様々な「落とし穴」が存在しているのはご存知だろうか? 本企画では、webアプリケーションのテスト&監視ソリューションを展開するエンピレックス株式会社の取り組みを通じて、その落とし穴の現状を5回に渡り紹介してゆく。

サイトの「不具合」がもたらすさまざまな問題

webサービスを利用している際、ときおり「長いロード時間」に遭遇したことはないだろうか。たとえばショッピングサイトで購入するアイテムを選び、レジ画面に進む。諸々必要事項を入力して、いざ購入ボタンを押す。しばらくすると「完了しました」とメッセージが生じる。この「しばらく」が、数秒であればいいが、もしも1分間あったとしたらどうだろう。当然、ユーザーからすれば「エラーかな？」と思うはずだ。また、「完了しました」のページに移行せず、他のページが表示されたとしたら、確実にエラーだと感じるだろう。そして大抵の場合、そこで買い物を断念する。さらに面倒くささゆえ、こうした事態になったことをWeb管理者にメールで一報を入れるということも、あまりしないはずだ。波風が立つことはないまま、自然とサイトの客足は遠のいていく。そんなケースが実は意外と多発している。

波風が立つ場合も深刻だ。たとえばオンライントレードをしていて、自らが持つ株が下落した。今、このタイミングで売りたい。そんなときにサイトが機能せず、受発注ができないとなれば、ユーザーはカンカンになってクレームを入れてくるはずだ。サイトの信用問題に直結し、運営側としてはビジネスどころではなくなってしまう。

“機能”だけではく“性能”も意識したサービスを

にもかかわらず、このような問題は後を絶たないのはなぜだろうか？エンピレックスの副社長、山岡英明氏に話を聞いた。

『一言でいえば、システムを開発する側、開発を依頼する側の双方が“機能”ばかりに着目し、“性能”をおろそかにしがちな風潮があるからだと思います』

自動車にたとえてみるとわかりやすい。ハンドル式ではなくボタン式のパワーウィンドウを車に搭載したい。これは“機能”の要望だ。そして実際にパワーウィンドウが搭載されたが、ウィンドウが全開するまでに1分間かかったとする。これは“性能”の問題だ。性能が伴わなければ、どんな高度な機能であっても無に帰ってしまう。

『性能については“ユーザーが快適に使えるように”といった抽象的なリクエストが暗に発せられるようなケースがほとんどです。そのため、システム開発全体において“快適か否か”は後回しにされてしまう。サービスの本格運用の直前、わずかな猶予しかない期間でテストを実施するスケジューリングも、じつは大問題といえます』

性能テスト実施そのものは1日あれば出来るという。しかしその結果を検証し、性能の最適化を行なうチューニングの期間が充分に確保されていないかぎり、テストは意味をなさなくなる。さらに時間だけでなく、しっかりと検証し、解析できるノウハウを持ったプロも少ない。 インターネットそのものの歴史の浅さに加え、「プロ」が分野ごとに分散している現状がある。単体のシステムとしては正常でも、2つのシステムを統合することによって生じる不具合などは、全体を俯瞰できないと感知できないというわけだ。

『テストは合否を出すもの、と捉えている方もいますが、私たちの経験上、性能テストでは“100％合格”というのはありえません。また、テストで見つかった不具合の種類によっては、サイトの構造を根本から考え直さないといけないケースもあります。サービス開始は来週に迫っているが、開発の初期工程まで遡らざるを得ない不具合が見つかり、結局サービス開始が1年半も延びたことも実際にありました』

開発の最終段階でのテスト、それがいかにリスクが高いかを物語る事例といえる。そのためエンピレックスでは、テストおよび検証を行なうプロフェッショナル集団を「ボトルネックバスターズ」と銘打ち、ツールの提供だけでなく、初期段階から”性能”を意識した開発をおこなうためのセミナー、また性能に関するコンサルティングサービスを実施している。

起こりうる状況をテストで忠実に再現

もうひとつの課題は、テストの「やり方」だ。これもプロフェッショナルな人材がなかなかいないため、「一応やりました」という体裁を整えるためのテストが多いという。結果、サービス開始後に痛手を負ってしまう。

『一人の人間が1時間に5万回アクセスするのと、一斉に5万人の人がアクセスするのとでは負荷のかかり方がまったく違います。でも、前者のテストで良しとしてしまうケースもあるようです。私どもの場合は後者、つまり実際の運営後のシーンを想定し、ツールを使って検証しています』

検証も、経験値の高い人間でない限り、なかなかピンポイントで問題点は指摘できない。特に、サーバがまるごとダウンするような症状ならいざ知らず、「たまにしか生じない」ようなエラーの原因を探ることがとりわけ難しいという。また、「これだけの人間が一斉にサイトを訪問したら、現状のサーバでは厳しくなる」という“システムの限界”を知っておくことも重要だ。もし限界がわかれば、そこに達する前にサーバを増設したり、ユーザーにメンテナンスのアナウンスをすることもできる。サーバがダウンしてから手を打つのでは遅く、信用を損ねることにつながってしまうだろう。

ともあれ世の中のサービスを見渡すと、たとえば自動車や飛行機は、どの開発工程においても性能を意識し、テスト期間も充分に確保している。その体制に比べ、現在のWebサービスにおける性能への意識は格段に低いといえる。“機能”も大事だが、“性能”にも改めて着目し、ユーザーに快適さを感じてもらうことが、サービスを提供する側の義務といえるだろう。

エンピレックス「ボトルネックバスターズ」の取り組み2回目は機能面ばかりに目を取られ、実は気づいていない性能問題の落とし穴について言及してゆく。

闘うボトルネットバスターズの活躍をわかりやすいマンガで紹介しています。

Coryright(C) 2008 Digital Advantage Corp.

(マイコミジャーナル 広告企画)