 |
| 図3●最終的にキャッシュ・サーバーを導入 テスト環境で検証した結果では，DBサーバーのCPU使用率が90%になる負荷をかけても，キャッシュの効果で15%程度で済むことが判明した。アクセス数が増えてもキャッシュ・サーバーの負荷が増えるだけで，導入後はDBサーバーのCPU使用率が20%程度で落ち着くようになった |
「ついに追いつかれた」
その一方で，チューニングの限界も近づいていた。同社では，負荷分散装置で最大コネクション数を制限しており，その値を超えるアクセスが来た場合はサイトが混雑している旨を告げるページを表示するようにしている。最大コネクション数は，「（Apacheに設定した）MaxClientsの合計に，少しだけ余裕を持たせて決めている」（浅沼氏）。これにより，アクセスの集中によるサーバー・ダウンを防いでいるわけだが，「7月1日がぎりぎりだった」（牧野氏）。負荷分散装置のログを確認したところ，混雑を告げるページをかなりの回数表示していた。
同社のサービスでは，毎月1日になるとアクセス数が通常の1.5～2倍に急増する。この原因は不明だが，ユーザーが「月の初めとなる1日に新しい楽曲が追加されるはず」と考え，アクセスが集中しているものと思われる。
7月のピークとなる7月1日はなんとか大丈夫だったが，次のピークとなる8月1日は乗り切れそうにない。過去の傾向からもアクセス増は確実で，夏休みでさらに増えることが予想された。しかし，「打てる対策は尽くした。これまで先手先手で対処してきたが，ついに追いつかれた」（牧野氏）。
キャッシュ・サーバーを導入
そうはいっても，何か対策を打たなければならない。混雑を告げるページを表示することは，販売機会の損失を意味する。アクセスできなければユーザーからクレームが来るほか，楽曲を同社に提供しているレコード会社からも突き上げられる。8月1日まで1カ月もないとなると，チューニングなど時間のかかる対策では駄目だ。すぐに効果が期待できるハードウエア製品を導入するしかないと考えた。
そこで真っ先に思い浮かんだのが，キャッシュ・サーバーだ。いくつかの製品を検討した結果，マクニカが販売する米Warp Solutionsのキャッシュ・サーバー「WARP 2063e」を採用することにした。
同製品を選んだ理由は主に2つ。一つは，動的コンテンツをキャッシュする機能を備えており，設定が容易だったこと。牧野氏が別の仕事でWARPとは異なるキャッシュ・サーバーを利用した経験では，「キャッシュするコンテンツのURLを正規表現で指定しなければならず結構大変だった。正規表現で指定するとパフォーマンスが落ちるという話を聞いたこともあった」。これに対してWARPの場合は，正規表現を使わずに簡単に設定できた。
もう一つは，導入が容易なこと（図3[拡大表示]）。「Webサーバーにプラグインをインストールすると自動的にキャッシュ・サーバーとやりとりしてくれる」（牧野氏）。1台ずつ導入していき，何か問題があればプラグインを削除すればよい。これにより，サービスを停止せずに導入できる。キャッシュ・サーバーがダウンした場合は自動的にプラグインが無効になり，サービスの提供を継続できる点も好印象だった。
早速，7月10日ごろからテスト環境で検証を開始した。検証した結果では，DBサーバーのCPU使用率が通常90％になる負荷をかけても，キャッシュの効果で15％程度で済むことが分かった。導入後も20％程度で落ち着いている。ピーク時のレスポンスも良くなり，これまでは10秒程度かかることがあったが，1～2秒で応答できるようになった。
もともとはDBサーバーの負荷を低減する目的で導入したが，Webサーバーの負荷が低減する効果もあった。Webサーバーにインストールするプラグインでもキャッシュを保持しており，「キャッシュがある場合はPHPアプリケーションを起動する前に応答してくれる」（浅沼氏）。導入前のWebサーバーのCPU使用率は25％程度だったが，導入後は10％程度に低減した。
こうした効果が出たことから，一度は静的化したページを動的なページに戻した。同時に，負荷分散装置の最大コネクション数も見直した。ApacheのMaxClientsの値を約40％増やしたほか，2003年4月末までDBサーバーに使っていたマシンをWebサーバーとして再利用し，全体で処理できるアクセス数を増やした。2003年10月1日は420万ページビューのアクセスがあったが，全く問題なかった。
