PR

図1●アクセスが集中してWeb/APサーバーが次々にダウン
2003年3月2日の20時過ぎ,テレビ番組を見たユーザーからの大量アクセスが来てWeb/APサーバーがダウン。再起動してもすぐにダウンしてしまい,約30分間はアクセスできない状態が続いた。アクセス・ログを分析した結果では,通常の6倍以上のユーザーがアクセスしていた
 2003年3月2日20時過ぎ,ヘルシーネットが運営する健康関連商品のECサイト「ケンコーコム」にアクセスが殺到し,Web/APサーバーが次々にダウンするトラブルが発生した(図1[拡大表示])。「サーバーを再起動してもすぐにダウンしてしまう」(システム マネージャ 丸敬弘氏)状態が続き,約30分間アクセス不能になった。

TV番組を見てアクセスが殺到

 大量のアクセスが来たのは,あるテレビ番組で,花粉症に効果があるとして「シジュウム茶」が紹介されたのが原因。当時は「シジュウム茶」を販売しているECサイトがほとんどなく,Googleなどの検索サイトで調べると,同サイトがトップまたは上位に表示された。必然的にアクセスが集中することになる。

 そのテレビ番組の放映は20時から。「放送開始数分後にはサーバーがパンク状態になっていた」(丸氏)。携帯電話にアラートのメールが届き,Webブラウザでアクセスしてみると反応がない。メンテナンス回線を使ってサーバーに接続してみたものの,サーバーがハングアップ状態でなかなかログインできなかった。

 ログインができても状況は改善できなかった。APサーバーのWebLogic Serverが再起動できない。仕方なくOSごと再起動するが,アクセスの集中はやまず,またすぐにダウンするという繰り返し。正常に処理できるようになったのは20時30分過ぎだった。

 約30分間はアクセス不能の状態が続いたが,Web/APサーバーがダウンしている間は負荷分散装置が「Sorry Server」にアクセスをつなぐことで最悪の事態は回避できた。Sorry Serverではサイトが混雑していることを知らせ,同社のYahoo支店と楽天支店を案内する。自社サイトはダウンしたが,この2つの支店を含めて過去最高となる約2000万円を売り上げた。

 ただ,損害がまったくなかったわけではない。Yahoo支店や楽天支店は,売上高に応じて月額料金が決まる。これらの支店にユーザーを誘導することで購入の機会損失は防げたが,自社サイトで販売できなかった分だけ損をしたことになる。今後このような事態を避けるためにも,大幅なシステム強化が必要となった。

サーバー増強でキャパを2倍に

図2●サーバーの増強などを実施して従来の約2倍の処理性能を確保
サイト全体の処理能力を高めるため,(1)Web/APサーバーのメモリーを4Gバイトに増設,(2)サーバー機を1台追加,(3)クラスタ構成の変更,(4)管理サーバー・プロセスを別のサーバーに移動――という対策を実施した

 Webサーバーのアクセス・ログを調査した結果,3月2日20時~21時の訪問者数は約1万2000。通常時が2000前後であることを考えると,約6倍以上のアクセスが来ていたことになる。既存の約6倍の処理性能を目標に,システムを強化していくことにした。

 まず実施したのが,サーバーの増強だ(図2[拡大表示])。負荷分散装置の管理画面で最大コネクション数を調べてみると,サーバーが搭載するメモリー量と比例関係になっていることが分かった。それぞれの内訳は,(1)3.5Gバイトを搭載したマシンで最大3500コネクション/秒,(2)同2Gバイトで1900コネクション/秒,(3)同2Gバイトで2500コネクション/秒――である。同じメモリー量にもかかわらず(2)と(3)に差があるのは,(2)がWebLogic Serverのクラスタを管理する「管理サーバー・プロセス」を搭載しているためだ。

 大雑把ではあるが,メモリーが4Gバイトあれば,1台で最大4000コネクション/秒は処理できると想定し,すべてのサーバーのメモリーを4Gバイトに増設した。サーバー機も1台追加し,合計で1万6000コネクション/秒まで処理できる体制にした。

 同時にWebLogic Serverのクラスタ構成も見直した。従来は3台で1つのクラスタを構成していたが,1台追加して単純に4台で1つのクラスタにしたのでは無駄が多い。アットマーク・アイティ(@IT)に出ていた記事「事例に学ぶWebシステム開発のワンポイント(3)」(http://www.atmarkit.co.jp/fjava/rensai2/webopt03/webopt03.html)を参考にし,2台ずつで2つのクラスタにした方がトータルの処理量は多くなると判断した。

 管理サーバー・プロセスも別のサーバーに移した。メモリーの消費量を減らす目的もあるが,実はこの管理サーバー・プロセスが3月2日のサーバー・ダウン時に大きな問題となった。クラスタ構成にしている場合,管理サーバー・プロセスがダウンしていると,サーバーが起動できないのである。3月2日のダウン時も,まず管理サーバー・プロセスを起動してから他のWebLogic Serverを起動するという手順をとらなければならなかった。そのため,本来はユーザーからのアクセスを受けない別サーバーで管理サーバー・プロセスを動かすのが一般的になっている。


(榊原 康=sakakiba@nikkeibp.co.jp)