| ||
|
できるだけコストを最小限に抑えながら，急増するアクセスに対処していかなければならない。しかし，DBサーバーのマシンを置き換えたり，アプリケーションをチューニングしたりしても，アクセス増で処理性能がすぐに頭打ちになってしまった。最終的にキャッシュ・サーバーを2003年7月末に導入して解決した。
ハードを替えても長持ちしない
同社は「lmelo.net」と呼ぶWebサイトで，auの携帯電話端末を対象としたいわゆる「着うた」のダウンロード・サービスを提供している。ApacheとPHPで構築したWeb/APサーバーが2台，Sybase Adaptive Server Enterpriseを搭載したDBサーバーが1台の構成で，2002年12月から提供を開始した。当時は「着うた」を利用できる端末が少なかったこともあり，この構成で十分だった。
しかしその後，端末の利用者が増え，アクセス増の対処に毎月悩まされることになる。2003年3月はサービス開始当初の約4.6倍，4月には約6倍のアクセス数になった。アクセス増に備えて4月末にDBサーバーのマシンを置き換えたが，効果は長持ちしなかった（図1[拡大表示]）。アクセス増は続き，翌月には別の対策を考えなければならなくなった。
とはいえ，「アクセス数の増加に合わせて，高価なサーバーを導入していくわけにはいかない。ハードウエアのスペックを次々に上げていくと，アクセス増で得られる収益以上にコストがかかる。いずれにしても，アクセス数と競争するとコストがかかるのは目に見えていた」（テクニカルスーパーバイザー 牧野一憲氏）。
チューニングで2カ月しのぐ
そこで実施した対策が，データベースまわりのチューニングである。というのも，ユーザーは「楽曲を検索→紹介ページを表示→ダウンロード」という操作が中心になる。検索はもちろん，ダウンロードする前に表示する紹介ページもWebアプリケーションで動的に生成しているため，DBサーバーに負荷が集中していたからだ。
DBサーバーの負荷を低減するために実施したのは，(1)DBのインデックスの見直し，(2)DB側で実施していた処理をPHPアプリケーション側の処理に変更する，(3)無駄なクエリーを減らす，(4)動的なWebページの静的化――などである（次ページの図2[拡大表示]）。
(1)は見直した結果，ほとんど問題なかった。(2)は，DB側で行っているソートやジョインなどの処理を，PHPアプリケーション側で処理するというもの。「結局はDBサーバーに負荷をかけるか，Webサーバーに負荷をかけるかのどちらかの選択になる。Webサーバー側にできるだけ処理をもっていった」（牧野氏）。(3)は，無駄なクエリーを減らしていき，最終的に約5％のクエリーを削減した。
(4)は，Webアプリケーションで動的にページを生成するのをやめ，あらかじめHTMLページとして作成しておく方法。2003年4月末から5月にかけて負荷テストを実施し，負荷の高い動的ページを静的化した。具体的には，「アクセス・ログで調べたページごとのアクセス数」と「負荷テストで得たレスポンス・タイム」の積を計算し，値の大きいページから順に静的化を検討していった。
作業工数の問題もあり，これらの作業は7月前半までかけて少しずつ取りかかっていった。こうした苦労の甲斐もあり，5月と6月は無事に乗り切ることができた。
