第3回では，キャパシティ改善の要となる「キャパシティ改善計画」の「対策立案フェーズ」について解説していきます。

キャパシティ改善計画 －対策立案フェーズ とは

さて，キャパシティ改善の分析フェーズの次は，対策立案フェーズに入っていきます。ここでは，分析フェーズで得られた将来のキャパシティ限界の結果から，それに対する対策案を考えます。以下に，対策立案フェーズの流れを図でまとめます。

今回は図1の「目標の決定」「⁠方法の決定」について説明します。「⁠サイジング」については次回第4回で説明します。

目標の決定

対策立案フェーズでは，まず，キャパシティ改善の目標を決定します。物事のはじめに目標を決めるというのはよく言われることですが，なぜ対策立案の初めにキャパシティ改善の目標を決める必要があるのでしょうか。それは，適正なキャパシティ改善を実施するためです。実際にキャパシティ改善を始めると，際限なくキャパシティを改善させることが可能なことが分かってきます。例えば，この後に紹介するチューニングやハードウェア増設は，お金や時間さえ掛ければ，いくらでもキャパシティ改善が可能です。しかしながら，キャパシティ改善にかけられるお金と時間には限りがあり，さらに，求められるキャパシティにも適正な値があります。つまり，求められる以上のキャパシティ改善はお金と時間の無駄なのです。際限なくキャパシティ改善をしたくなるのはエンジニアの性ですが，これに歯止めを掛けられるよう，キャパシティ改善の目標を決定しておく必要があります。

具体的には，目標として以下の3つの目標を決定します。

1. アクセスのピーク時に，ユーザからのリクエストを単位時間当たり何リクエスト処理することができるか（スループット目標）
2. 1．の条件下で，各リクエストについて何秒以内にレスポンスを返すことができるか（レスポンスタイム目標）
3. 1．2．の条件下で，ハードウェアのリソース使用率は何％以内に収まっているか（リソース使用率目標）

それでは，今回の例である「せいのう.jp」の目標を見ていきましょう。以下に，第2回で紹介した「せいのう.jp」の将来の性能を予測した図を掲載します。

まず，このシステムのレスポンスタイム目標は5秒ですので，2．の目標は5秒になります。また，アクセス数の増加が一定のため，スループットの増加も一定だと予測できるので，システム終了日に必要なスループットは約36,000リクエスト／5分間だと予測できます。ですので，1．の目標は36000リクエスト／5分間となります。最後にリソース使用率ですが，今回はDBのCPU使用率が80%に達するとレスポンスの遅延が始まるということでしたので，余裕を見て70%を③の目標とします。以下に，せいのう.jpの改善目標と，仮に2009年2月にキャパシティ改善を実施した際の，キャパシティ改善後の理想的なグラフを掲載します。