ある芸能人の提供する情報をサービスするモバイル有料課金コンテンツ・サイトを運営していたが，該当芸能人がテレビ出演する都度，大量のアクセスが発生しサービス提供が困難となった．

　大量アクセス時には既存ユーザへ情報提供が行えない状態なのと，会員登録処理が行えない事による機会ロスが発生しているので，その改善．

• RedHat ES3
• Apache
• Tomcat
• Sybase Adaptive Server Enterprise 12.5
• Sybase Replication Server 12.5
• Spider Cache

　このプロジェクトの場合は，いくつかの段階を経ての対応となっている．

1. Webサーバ対応ボトルネックの解消
   • 高負荷状態になった時のサーバステータスを確認すると，明らかにWebサーバでの処理能力不足が発生していた．
   • よって，ロードバランサ配下へWebサーバを調達しスケールアウトを行い対応．
   • ただし，調達したWebサーバは他システムで導入された物やリースアップ前の低スペックなものも混在していた為，処理能力にばらつきがあった．
   • ロードバランスの手法はラウンドロビン方式．
   • 各サーバの性能別処理能力を計測・整理し，ランクを設け，バランスする際の最大セッション数の上限設定を行いサーバがストール(stall)しない程度に最大限活用できる様にした．
   • また，システム全体での最大アクセス数を設定し，それ以上のアクセスが行われた場合は，処理を受け付けない状態である事を示すSorryサーバを設置する事として，サーバを封鎖せずに安定処理が行える状態とした．
2. DBサーバのボトルネック解消
   • Webサーバ側の増設が完了する事で，同時ユーザアクセスを受けられる様になった．
   • これにより，負荷がバックエンド（データベースサーバ）に移動し，ロックウェイト等で処理が遅延が発生する状態となった．
   • データベース処理を分析すると，８割型が参照処理であり，一部の更新ロックによって参照処理がウェイトが発生している事が発見された．
   • 利用していたデータベースがSybase ASEだった為，この関連プロダクトとしてReplication Serverによってサーバをスケールアウト増設し，参照処理はレプリケーション先サーバで実施させる事としてシステム全体のパフォーマンスアップを実現した．
3. キャッシュサーバの導入
   • 会員数と会員によるアクセスが増え続ける都度，各サーバの増設を行っていたが，このまま増設を行うと，投資対効果が悪くなる．
   • サーバの新規増設をする際には，次の３点の問題がある．
   1. サーバの費用
   2. 設置の人件費
   3. 調達から投入までのタイムラグ
   • また，将来的な視点での以下の懸念点がある．
     1. ブーム終了時の過剰投資
     2. 似た様な状態の別システムが発生したときの対応
   • これらの問題を解決する為に，Webサーバの増設負荷を削減する目的で，Spider Cacheというアプライアンスサーバを導入．
   • このCacheサーバは「動的コンテンツ」のキャッシュを取り扱う為のルールベース設定が行える柔軟性と，実用テスト導入で80%越えの実績を出し，10台分以上のWebサーバ処理を行える事が試算され，コスト対効果から導入を行った．

　この案件は先進事例として日経システム構築　2004年10月号に特集されております．