ボトルネック ハード増強 だけじゃ無理

 システムに性能トラブルが発生した場合、ボトルネックの見極めが必要になる。このとき、安易にハードウエア資源を追加することで、解決しようとしていないだろうか。

 もちろんそれで解決する性能トラブルもあるが、筆者の周辺で発生している性能トラブルの多くはアプリケーションに起因している。アプリケーションも含めたボトルネック評価がITアーキテクトには求められる。

単体性能か多重性能かを見極める

 ボトルネックの見極めの第一歩は、一つのトランザクションのレスポンスが問題になっているのか、複数のトランザクションを同時に処理する際に問題になっているのか、を判断することだ。前者は単体性能、後者は多重性能と呼ぶ。どちらのボトルネックであるかによって、対処方法は異なる。

 まず、単体性能について解説する。一つのトランザクションといっても、その中には複数の処理が含まれている。大まかにはクライアント、ネットワーク、画面/帳票、アプリロジック、ファイルI/O、データベースでの処理に分けられる。これらうち、どこの処理がボトルネックなのかを突き止める。

 クライアントでは、サーバとの役割分担や画面項目数が性能を決める。ユーザーインタフェース(UI)を充実させる昨今では、WebシステムであってもJavaScriptの処理がボトルネックになることがある。

 クライアントにおけるボトルネックの代表的な状況は、セッション情報の代わりに非表示の項目を大量にやり取りしている、項目ごとの背景色を描画する、HTML5のローカルストレージを頻繁にアクセスしている、といったことだ。ちなみに、これらはクライアント/サーバー時代の初期によく発生したボトルネックと類似した現象だ。

 ネットワークも、UIの充実に起因してボトルネックになりうる。特に画像点数が多いときは、レスポンスの劣化を招きやすい。そのような場合は、キャッシュプロキシーなどで回避できるだろう。