岡崎 俊二氏 マーキュリー・インタラクティブ・ジャパン副社長
|
|
図2 B社の負荷テストの手順 B社ではトラフィック・パターンを予測し，パターンの異なる二つのピーク時を想定してテストした。その結果，トラフィックが小さなピーク時にレスポンスが悪化しそうなことを突き止めた。 |
B社はまず，ユーザーがどのようなアクセス・パターンでWebサイトに接続するかを検討した。その結果，アクセスのピークは毎日午後11時で，アクセスの種類はチケットの予約が40％，空席照会が30％，そのほかの閲覧が30％の割合と予想した（図2[拡大表示]）。
さらに負荷テスト・ツールで発生させるトラフィックの割合を，実際のピーク時に予想される割合に合わせた。測定の結果，B社のWebサイトは午後11時のピーク時には問題なく処理ができそうなことが判明した。
処理負荷とアクセス数のピークは別
B社は念のため，もう一つ異なるトラフィック・パターンで性能を測定してみることにした。
実はB社へのアクセスには，ほかの時間帯とアクセス・パターンが異なる小さなピークがあった。B社では，チケットを3カ月前の午前9時に売り出す。このため，毎日午前9時に予約の割合が圧倒的に大きいピークがあることが予想された。こちらのアクセス数は午後11時のピークの7割ほどだが，予約の割合が70％と突出して高い。
B社では，予約のトランザクションを7割まで高めて負荷テストを試みた。すると，午後11時のアクセスのピーク時より，はるかに少ない処理しかできないことが判明した。最大のピークでは処理性能に問題が無かったが，予約が集中する小さなピークで性能が限界に達してしまったのだ。
負荷テストの結果を分析すると，B社のWebサイトのボトルネックは予約用のアプリケーション・サーバーにあることが分かった。B社は，予約する路線でアプリケーション・サーバーを2台に分けることにより，Webサイト全体の性能を向上させることにした。この結果，B社では大きなトラブルも無く，予約サイトを立ち上げることができた。
負荷テストで考慮する必要があるのは，Webサイトへのアクセスだけではない。例えばWeb以外の基幹情報システムがデータベースにアクセスする場合，その負荷によってWebサイトの性能が低下することがある。特に日次処理などで短時間にデータベースにアクセスするアプリケーションが存在する場合，Webサイトの負荷テストもそのことを考慮して設計する必要がある。
