はじめてのキャパシティ改善 ─稼働中のシステムを飽和させないために

第3回 キャパシティ改善計画【対策立案フェーズ 1】

この記事を読むのに必要な時間:およそ 3 分

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

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

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

図1 対策立案フェーズの流れ

図1 対策立案フェーズの流れ

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

目標の決定

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

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

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

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

図2 将来の性能予測グラフ

図2 将来の性能予測グラフ

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

表1 せいのう.jpのキャパシティ改善目標

1.スループット目標36,000リクエスト/5分間
2.レスポンスタイム目標5秒
3.リソース使用率目標DBサーバCPU使用率70%

図3 キャパシティ改善後の理想像

図3 キャパシティ改善後の理想像

著者プロフィール

堀江幸紀(ほりえ ゆきのり)

(株)NTTデータ 基盤システム事業本部所属。Webシステムのインフラ設計に関する研究開発を経て,現在はシステム開発の全工程における性能管理を支援する「性能プロフェッショナルサービス」のプロモーションと人材育成を担当。


三浦隆志(みうらたかし)

(株)NTTデータ 基盤システム事業本部所属。NTTデータ入社より「性能プロフェッショナルサービス」のサービスに従事。現在は性能問題が発生した際の原因特定と問題解決をする「性能問題解決支援サービス」を担当。

コメント

コメントの記入