リッチ・クライアントの思わぬ落とし穴

たしかに便利にはなった。しかし・・・

そうは言っても、初めて使う技術ですから、知識や経験の不足からいろいろと技術的につまずくことはありました。ですが、まだ若いのにずっと同じシステムの保守を続けてきて新しい技術に飢えていたBさんは、貪欲（どんよく）に知識を吸収して、むしろ当初想定していた以上のものに仕上げてきました。

Aさんにプロトタイプを見せながら、「あんなこともしたい」「こんなこともできる」、と盛り上がるうちに、商談相手の企業情報に含まれる住所からGoogle Mapsで地図を表示したり、最寄り駅やそこまでの経路／運賃を表示できるようにしたり、FlexのみならずAjaxも活用したグラフィカルで便利な画面になったのです。

世の中にはいろいろ便利なコンポーネントやサービスが公開されていて、簡単にアプリケーションに組み込めるので、開発するのも手早いものでした。Aさんは「これがマッシュアップか、確かにすごいな」と驚嘆しきりです。

もちろん、主な目的だった操作性の改善についても、入力補完やフォーカス遷移によるバリデーションを提供したり、タブや表のコントロールを用いて1画面中に多くの情報を表示／編集できるようにしたりと、大きな進歩が見られました。一通りのテストを終えて営業部のリーダーに見せたところ大変な喜びようで、Bさんは「あぁ、システム開発の仕事っていいものだなぁ」と思ったものです。

早速、営業部にお披露目をして、使い始めてもらうことになりました。当初は営業部の人とすれ違うたびに喜びの言葉をもらっていたのですが、数日するうちに、今度は「新しいシステムね、あれ、カッコいいし便利なんだけど、やたらと“重い”んだよね。外出先からモバイルで使おうとしたりしたら、使い物にならないんだよ」と新たな苦情が舞い込んできました。

“重い”から、結局は残したままの古い画面を使っている、という話で、慌ててサーバーのログを調べると、最初の1日2日こそ多くの人が新画面を使っていましたが、それ以降は旧画面のログばかり。「前の画面も使えるままだし、そちらの方が軽い」と口コミで広まったそうです。

AさんとBさんはがくぜんとして顔を見合わせました。

画面を出すのに40リクエスト

AさんとBさんは、モバイルの通信カードを借り出して、実際にVPN（仮想プライベート・ネットワーク）を介して画面を表示してみました。すると、商談管理画面を表示し終わるまで、早くて2分、通信状態が悪い時などは、5分たっても表示が終わらないことがありました。

早いネットワークの下で開発／検証していたから気づきませんでしたが、確かにこれでは使い物にならないと言われてもしかたのないところです。今回、技術的には新しい、大きく変わる改修ですが、ユース・ケースの範囲としては小規模な改修という扱いから、パフォーマンス・テストやストレス・テストを省略していたのが失敗でした。

過去の反省はともかく、なぜこれほどまでに“重い”のか、原因を探るのが先決です。まずは検証環境のサーバーを監視して、負荷の掛かり方を確認してみることにします。Webアプリケーションが重いとなれば、アプリケーション・サーバーのCPU負荷か、データベース・サーバーのディスクI/OやCPU負荷が限界に至っていることを疑うのが常道です。

しかし今回は、サーバーの負荷を見ていても、CPUやディスクI/Oには余裕があります。それほどの負荷がかかっているようには見えません。ただ、あらためて1つ気付いたことに、アプリケーション・サーバーのログがやたらと大量に流れています。

この企業のシステム構成では、フロントにWebサーバーを置いて静的コンテンツを処理させ、アプリケーション・サーバーへは動的な処理だけを委譲することになっています。通常のWebアプリケーションなら、1画面を表示するのに1リクエスト、多くてもリダイレクトを含めて2リクエストくらいしかアプリケーション・サーバーへは到達しないものです。

それが、今回は1画面で20リクエスト以上のアクセスがアプリケーション・サーバー側で記録されています。サーバーの負荷としては特に高くはなってはいませんが、複数ユーザーが同時に操作することを思えば無視できませんし、すべての処理が終わるまでには2分以上がかかっています。非同期通信が中心とはいえ、全部の処理が終わるまでは操作できないようにしているため、これでは確かに重いと感じられるはずです。

今度は、クライアント側でHTTPリクエストを監視してみるため、クライアント・マシンのローカルにHTTPプロキシを用意しました。すると、1画面を表示するまでに、社内のサーバーに20リクエスト、マッシュアップしている各種のWebサービスへ20リクエスト、都合40リクエストほどが発行されていたのです。そうしたWebサービスの中には、非常にレスポンスが遅いものもありました。

次ページでは、この“重い”アプリケーションをどう改善したのかを解説します。