 |
1.右肩上がりのアクセス増にレスポンスが悪化。ボトルネックはDBサーバー 2. もろもろの対策が実を結ばず，アクセス制限で急場をしのぐ 3.「余裕を持ったスケールアップがベスト」との結論にたどり着く |
 |
夏休み前に発生するアクセス数の急増が，「旅ぷらざ」のシステム担当者にとって頭痛の種だった。旅ぷらざは，日本旅行が提供する宿泊や交通の予約サイト。夏休み前は宿泊の空き情報を検索するユーザーが殺到するため，例年，アクセス数が跳ね上がる。
その結果，サーバーがリクエストを処理できず，ユーザーへのレスポンスが悪化する（図1）。数十秒も待たせたり，ページが見つからないことを示す「404エラー」を返したりすることも珍しくなかった。
 |
| 図1●日本旅行が運営するWebサイト「旅ぷらざ」が直面した問題 毎年，夏休み前になるとアクセスが急増する。数十秒もレスポンスを返せないことも珍しくなかった。2004年7月～2005年2月はアクセス制限を実施していたため，潜在的なアクセスはさらに多い [画像のクリックで拡大表示] |
「できることは何でもやろう」。2004年4月，山本康二郎氏（営業企画本部 メディアミックス営業部 旅ぷらざチーム 係長）をリーダーとするチームの奮闘が始まる。この年は夏休みを越えてもアクセス数が沈静化せず，秋から冬へと右肩上がりでアクセス数が増え続けた（図1グラフ）。1日平均のCPU使用率が60％になるというシビアな状況が続いた。2004年4月から約10カ月をかけ，今年2月にようやく大変な状況を脱した。
解決策(1) まずはDBをスケールアップ
レスポンス悪化の主な原因は，DBサーバーの処理能力不足である。2004年4月ごろの実測値では，同時トランザクションが20を超えるとCPU使用率が100％に達し，応答時間の平均は3秒になった。同時トランザクションが100の場合の応答時間の平均は15秒，200の場合は30秒だった。
ピーク時の同時トランザクションは50～100になることが多いが，アクセス数は増える傾向にある。このままアクセス数が増えていくと，いつかDBサーバーが応答不能に陥り，サイト全体の停止を引き起こす恐れもある。
そこで，2004年の夏前に，DBサーバーのリプレースを実施した（図2）。旧マシン（Sun Fire V480）のCPUはUltraSPARCIII 900MHzが4基。それに対して，新マシン（Sun Fire V880）はUltraSPARCIII 900MHzを8基搭載する。
 |
| 図2●2004年夏を乗り切るために実施した解決策 3つの解決策を実施した。そのうち2つの解決策は一定の効果を上げたが，抜本的な解決にはならなかった。また，アクセス制限は，ビジネス機会の損失の観点から好ましくなかった [画像のクリックで拡大表示] |
このスケールアップにより処理能力は理論上2倍近くになったが，こうした方法では「この先もこまめにハードウエアのリプレースを続けていかなければならない」（山本氏）という不安が膨らんだ。旅ぷらざチームは，このスケールアップが決定打になるとは思っていなかった。事実，この年は夏休み以降もアクセスが収束せず，秋を越え冬になっても，CPU使用率との闘いは続くことになる。
解決策(2) 動的キャッシュは誤算
DBサーバーの増強だけでなく，DBサーバーへのアクセス数そのものを減らせないだろうかと考えた。そこで検討したのが，動的キャッシュ・サーバーの導入である。動的なコンテンツをキャッシュできるため，特に参照系の処理が多いアプリケーションで有効である。これによって，劇的な効果を上げているサイトもいくつかある。参照系の処理が多い旅ぷらざには打って付けの方法だと言えた。
これも2004年4月から検証を開始し，7月に間に合わせるべく急ピッチで作業を進めた。ところが，旅ぷらざでは効果的に動作せず，期待したほど性能は向上しなかった。メーカーを交じえ，秋までかけて原因を追及したが，結論は出なかった。
解決策(3) アクセス制限で急場をしのぐ
(1)(2)と並行して，Webサーバーでのアクセス制限も実施した。負荷の重い宿泊関連のWebサーバーは2台で構成している。この2台のWebサーバーに，セッション数の制限を設けた。
Apacheの設定項目であるMaxClientsに値を設定すれば，最大セッション数を制御できる。サーバー1台当たり400セッション，2台で800セッションを上限とした。また，ビジー画面を新たに作成し，別のサーバーに配置。最大セッションの上限を超えるアクセスがあると，別のサーバーからビジー画面を応答させた。
アクセス制限は，ユーザーに確実に画面を表示させるという意味では最も堅実な方法と考えられる。だが売り上げ機会の損失と見ることもできるため，望ましい方法とは言えない。急場しのぎの策として実施した。
解決策(4) アプリの書き換えを実施
ハードウエアによる対策と並行し，アプリケーションのチューニングにも取り組んだ。
最もリソースを消費するのは，宿泊の空き情報を検索する処理である。ソフト開発会社の協力を仰ぎながら，検索処理の回数を減らす工夫や，1回の検索にかかる負荷を減らす工夫を次々に盛り込んでいった。
例えば，JavaScriptによって検索ボタンのリロードを抑制した。レスポンスが悪化してくると，ユーザーは検索ボタンを何回も押す傾向がある。それがさらに負荷を高めてしまう。そこで，同じ条件の検索の場合は検索ボタンを機能させないようにした。
大掛かりな変更としては，画面の遷移を見直した。従来は，照会から予約までのフローの間で複数回の検索処理が実行されるようなサイトの構成になっていた。そこで予約までのフローを簡素化し，検索の回数を減らした。
また，カレンダー表示の照会を簡略化した。従来はデフォルトで4週間の表示だったが，それを2週間に変更して参照するデータ量を減らした（図3）。
 |
| 図3●アプリケーションのチューニングも実施 DBサーバーへのアクセスを減らすようにアプリケーションを変更した。これも抜本的な解決にはならなかった [画像のクリックで拡大表示] |
こうしたアプリケーションのチューニングは一定の効果を発揮したと見られるが，CPU使用率を見る限り目覚ましい改善とはいかなかった。解決策(3)で実施したMaxClientsの値はCPU使用率の推移を見ながら緩めていったものの，結局，完全に解除することはできなかった。
