千趣会は2000年5月,通販サイト「bellne.com」を日本IBMのサーバー製品群を使ったシステムにリニューアルした。しかし,アクセス数と注文数は当初の予想以上に増加。そのため,千趣会ではシステムの増強を段階的に継続している。2001年5月には,顧客から見たレスポンス時間を把握しサイトのサービス・レベルを改善するため,Webサイトのレスポンス時間を測定するサービスを導入した。
BtoC(企業対消費者)のEC(電子商取引)サイトが成功すると,短期間に驚くほどのアクセス増に直面し,サイトのパフォーマンスが低下してしまう。千趣会の通販サイト「bellne.com」(http://www.bellne.com/)もそんなサイトのひとつだ。平時もアクセス数・注文数は増え続けているが,カタログやチラシの配布後には予想以上のアクセスが集中する。2000年末以降,2度のパフォーマンス低下に見舞われ,システム増強やボトルネックの発見作業を継続し,アクセス増と闘い続けている。
リニューアルでレスポンス向上へ
bellne.comは,2001年5月現在で登録ユーザー数47万人,掲載商品数1万1000点以上を持つ。1日に15万~20万のアクセス,1カ月に7万件の注文がある(写真1)。Webからの注文は郵便,電話,FAXを含めた全注文数の7%。この割合は,2000年5月のリニューアル以降,月に0.5%の勢いで伸びている。
現在のシステムは,2000年5月にリニューアルしたもの(図1[拡大表示])。Windows NTサーバー1台でWebサーバーとデータベース・サーバーを運用していたシステムを,日本IBMのRS/6000を5台使ったシステムに変更した。
負荷分散用ソフトとしてWebSphere Performance Packを使い,アクセスを2台のロータス ドミノ Go Webserverに振り分ける。このWebサーバー上でECサイト用のミドルウエア「Net.Commerce V3.2 for AIX」を稼働,さらにその上でカタログ表示や注文などを処理するアプリケーションが動く。ユーザー情報(注文に必要),商品情報,注文情報を格納するデータベース・サーバーは,DB2を使う。このデータベース・サーバーと従来から稼働している基幹系システムとを接続,連携させている。
このシステムによって,「トップページから注文終了まで5分,購入商品をカートに入れてから注文終了までは4分」(千趣会 デジタルメディア開発部 マネージャーの星野 裕幸氏)を実現しようと考えた。システム的には,ユーザーの注文はまずMQSeriesを使いデータベース・サーバーに送り,そこから連携する基幹系システムに対して在庫照会や発注に伴う在庫変更などのリクエストを出す。基幹系システムはこのリクエストを処理し,bellne.comを通してユーザーのブラウザに注文完了のメッセージを出力するといった流れとなる。
bellne.comは,アクセスや注文が印刷物のカタログ配布後に一時的に急増する。「URLを記載したカタログ1億冊を年3回配布しているが,このカタログが顧客に届き始めたときから,通常よりもアクセス増の波が激しくなり,時には予想がつかなくなる」(星野氏)。増えつづけるアクセスや注文を処理でき,かつそれが一時的に急増してもサイトのパフォーマンスが著しく低下しないようにする必要がある。
|
レスポンス測定サービスを導入
bellne.comのアクセス増は,リニューアル当初の予想を超えるものだった。2000年12月頃から,注文に時間がかかるというクレームが増えてきたのである。千趣会では,レスポンス時間が遅延するボトルネック探しとシステム増強に着手した。
第1段階として,システムの導入と保守を依頼している業者に相談し,サーバーの過負荷軽減に着手した。まず,ハードウエアのモニタリング結果を参考に,Webサーバーのメモリー増設とハブの交換を実施した。一方で,顧客がサイトにアクセスし注文を終えるまでどれだけの時間を要するかを知るため,社員がブラウザを使いbellne.comにインターネットからアクセスして,レスポンス時間を手作業で測定する作業を毎日23時前後に実施した。
しかし,1日中継続して測定しているわけではなく,たまたまその回のレスポンス時間が長かった可能性もある。また,どこが遅くてどのくらいかかるのかという具体的な分析が難しい。手作業の測定ではあまり効果が得られなかった。そのころ,2001年2月に,NTTコムウェアとBMCソフトウェアの共同事業であるWebレスポンス測定サービス「SiteAngel」の商談がNTTコムウェアから持ち込まれた。
SiteAngelは,ユーザーの一連の操作をシナリオ化し,その実行時間を一定時間間隔で測定するサービス。ユーザーの操作結果を表示するページやフレームごとに操作ステップを設定し,ステップごとにレスポンス時間を測定することもできる。その際,ステップごとにDNSルックアップからHTMLファイルを要求するまで,HTMLファイルのダウンロードが始まるまで,HTMLファイルのダウンロードが終わるまで,画像ファイルなどその他のコンポーネントのダウンロードが終わるまで,の各時間に分けて測定する。
これらの測定データを分析することで,レスポンス時間を遅らせるボトルネックをある程度絞り込めるようになる。測定結果はグラフを用いたレポートにして提供する(写真2)。また,レスポンス時間が想定した以上かかった場合,サイト担当者にアラート・メールで通知する機能を持つ。