Webシステムはアクセス数が増加することで性能が悪化する。ボトルネックの大半はデータベース・サーバー（DBサーバー）とアプリケーション・サーバー（APサーバー）にある。
性能を改善する方法は，ハードウエアの拡張とミドルウエアのチューニングが王道。従来，DBサーバーの拡張はサーバー機自体の入れ替えに頼っていたが，ここへ来てDBサーバーの負荷分散やDBアクセスのキャッシュが現実味を帯びてきた。
（日川 佳三＝hikawa@nikkeibp.co.jp）
費用対効果の高いWebシステムを構築する---。エンジニアが抱える永遠のテーマである。高い費用対効果を維持するためには，設計工程時のサイジングとテスト工程時の負荷テスト，カットオーバー後の性能監視を怠らないことが不可欠である＊1。
Webシステムの性能はビジネスに直結する。「以前のシステムは稼働前の負荷テストを怠った。結局，性能が出ずにWebサイトでの売り上げを落としてしまった」（ムラウチの橋本昌巳情報システム室マネージャー）という実例もある。
最近では，製品の充実により，以前よりはWebシステムの性能を維持しやすくなってきた。例えばOracleのRAC＊2によって，DBサーバーの性能を拡張しやすくなった。DBアクセスを経て動的に作られたコンテンツをキャッシュしてWebシステムの性能を高める製品も選べるようになった。
DBの足を引っ張るな
一般にWebシステムは，インタフェース，ロジック，データを別々の層で提供する（図1[拡大表示）。Webブラウザが発行したトランザクションは，DBアクセスを経てHTMLとして戻る。この一連の流れの間に，DBアクセスに限らず，DBへのクエリーを決めるまでのアプリケーション・ロジックや，問い合わせのキューイングなど，様々な処理を実行する。
Webシステムをサイジングする際には，全サーバーが性能を出し切れるように各サーバー性能のバランスを調整することが大切である。「WebサーバーやAPサーバーの性能が低くてDBサーバーの足を引っ張る状態は避けなければならない」（日立ソフトウェアエンジニアリングの紀平篤志インターネットビジネス部長）。高額な投資をかけたDBサーバーの能力を使い切る前にWebシステム全体の性能が頭打ちになってしまっては，せっかくの投資が無駄になってしまうからだ。
では現実に性能が低下する場合，ボトルネックが“正しく”DBサーバーで生じるようになっているのか---。Webシステムの負荷テスト・ツールを用いたコンサルティング・ベンダーであるエンピレックスの統計によると，「ボトルネック事例の40％がAPサーバーにあり，30％がDBサーバーにある」（山岡英明副社長）という。必ずしもDBサーバーがボトルネックになっている例ばかりではないのである。
ボトルネック解析では，フロントエンドから順番に調べる姿勢が必要である。「実際にはネットワークやWebサーバーがボトルネックとなっていて，容易に解決できるケースも多い」（マーキュリー・インタラクティブ・ジャパンの大西雅之コンサルタント）。
基本は機材の拡張と調整
ボトルネックを解消する方策は複数ある（図2[拡大表示）。最も簡単な方法は，(1)ハードウエアの拡張である。サーバー機の台数を増やしたり新機種へと置き換える。これに対し，(2)APサーバーやWebサーバーのパラメータを調整することで性能が向上する場合もある。
Webシステムの性能はパラメータ次第で大きく変わるため，テスト工程でのパラメータ・チューニングはおろそかにできない。個々の業務に合わせた適切なチューニングが必要である＊3。
さらに，(3)DBアクセスを経て動的に作られるページをキャッシュする手段も有効。キャッシュを導入すると処理の流れが複雑になり，以後の性能監視とチューニングが難しくなってしまうデメリットがあるが，既存システムに手を入れずにDBアクセスそのものを減らす効果は大きい。
いずれの場合においても，テスト工程の負荷テストは欠かせない。負荷テスト・ツールは，クライアントからのアクセスが集中した際にどこが性能のボトルネックになるのかを発見する手助けになる（表1[拡大表示）。
CPUとメモリーを効率よく使う
負荷テスト・ツールは，仮想ユーザーから実際にWebシステムにトランザクションを発行する仕組み。同時アクセス数を変えながら，HTMLページが返ってくるまでの応答時間を示す「レスポンス」と，Webシステムが返す処理結果の総量を示す「スループット」を計測する。サーバーのリソースを監視した測定データと照らし合わせることで，性能のボトルネックがどこにあるのかを突き止める＊4。理想的な性能グラフは図3[拡大表示の通りである。
チューニングに不備があるシステムでは，同時接続数がシステム性能の限界に達した後でスループットが急激に落ち込む場合がある。これは，処理できる数を超えたリクエストも受け付けており，メモリーのスワップなどの問題が発生しているケースである。
反対に，システムの限界点に達してもCPUとメモリーの使用率が低い場合がある。受け付けるリクエストの数を絞りすぎていてCPUやメモリーが無駄になっているケースである。WebサーバーがボトルネックになっていてAPサーバーやDBサーバーの能力を生かしていない場合もある。
Webシステムに限った話ではないが，負荷テストの前提として大切なことは，実稼働環境に近いテストを実施することである。例えば，可能であれば本番環境に近いダミー・データを整備するべきである。テストするシナリオも，実際の業務に合った適切な内容でなければならない。
負荷テストを入念に実施したユーザーの1つがECサイトを運営するムラウチ（画面1[拡大表示）。ボトルネックとなるDBサーバーがどれだけの負荷に耐えられるのかを，負荷テスト・ツール「Apache JMeter」で検証した。同時アクセス数に限らず，取り扱う商品の増加にともなってデータ件数が増えた場合のレスポンスとスループットまで計測した。システムの開発とテストはSIベンダーの日立ソフトウェアエンジニアリングが担当した。
