第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月にキャパシティ改善を実施した際の、キャパシティ改善後の理想的なグラフを掲載します。

方法の決定

キャパシティ改善の目標が決まったら、次はキャパシティ改善の方法を決めます。キャパシティ改善の方法としては主に「チューニング⁠」⁠、「⁠スケールアップ⁠」⁠、「⁠スケールアウト⁠」⁠、「⁠サーバリプレース」の4つがあります。以下、それぞれについて説明します。

チューニング

チューニングとは、ソフトウェア上の非効率な処理を排除することでキャパシティを改善する事を指します。ここで言うソフトウェアとは、OS、ミドルウェア、アプリケーション、データベース等の、ハードウェア以外の部分です。例えば、アプリケーション内で無駄にCPUを消費する処理があった場合、その無駄を省くとことでサーバのCPU使用率が低下し、システム全体のキャパシティを改善することができます。今回の例である「せいのう.jp」のようなWeb3層構成[1]のシステムでは、例として表2のようなチューニング方法が挙げられます。

このように、ソフトウェアの修正のみを行うだけでも、キャパシティを改善させることが可能です。しかしながら、ソフトウェアのチューニングでは、問題の調査や改修にかかるコストが大きくなることがあるため、後ほど紹介するハードウェアで対処案の方が安上がりになる可能性もあります。ですので、お勧めの方法としては、まずはチューニングを実施してみて、実際にチューニングでのキャパシティ改善は難しいとの判断ができれば、後ほど説明するハードウェアでの対処案をとるのが良いでしょう。

また、場合によっては、ソフトウェアの非効率な処理が原因で、サーバのリソースを殆ど使い切れないことがあります。たとえば、Webサーバに同時接続クライアント数が極端に低く、クライアントの接続待ち行列ができていたり、DBサーバにてデータベースの行ロックが多発していたりすると、このような現象が発生します。このような状態では、後ほど説明するハードウェアによる増強を実施しても、結局サーバのリソースをうまく使うことができず、キャパシティを改善することができません。ですので、このような現象が起きているときは、必ずチューニングにて問題を解消させておきましょう。

スケールアップ

スケールアップとは、サーバのリソース増設や、より処理能力の高いリソースへの交換によって、システムのキャパシティを向上することを指します。例えば、あなたが管理しているシステムでは、アクセスのピーク時にメモリ使用率が9割に達し、今後更なるユーザの増加も予想されます。さて、あなたならどうするでしょうか。このような状況を解決する選択肢の一つとして、スケールアップがあります。上記の例のような条件であれば、メモリの増設を検討します。また、これ以上メモリの増設ができない場合、より容量の多いメモリへの交換を検討します。

このようにスケールアップによるキャパシティ改善は簡単に行うことができますが、スケールアップには改善効果の限度がある場合があります。例えば、CPUを2個から4個に増設したとしても、キャパシティが2倍になるとは限りません。なぜなら、CPUが増えるにつれて、複数のCPU使用するコストが増大し、各CPUが持つ力を100%使用できなくなっていくからです。このコストはCPU数が増えれば増えるほど高くなっていきますので、逆に言うと、CPU数が増えれば増えるほど、キャパシティの改善効果も低くなっていきます。これをCPUのスケーラビリティと呼びます。ですので、CPUを増設する場合は、スケーラビリティを考慮して、余裕をもったスケールアップを実施する必要があります。ただし、CPUのスケーラビリティは、サーバ上で動作するソフトウェアによって傾向が変わるため、その傾向を把握した上でスケールアップを実施する必要があることに注意してください。CPUスケーラビリティについて図4にまとめます。

またそれ以外にも、現在のサーバのCPUソケットに搭載できるCPUの種類は限られていることや、ハードウェアを増設するソケット数の限界がある等物理的な問題があるために、スケールアップを行うことができない場合もあるので、注意が必要です。

スケールアウト

スケールアウトとは、キャパシティ限界の原因となっているサーバを増設し、処理を複数のサーバに分散させることにより、システム全体のキャパシティを向上させることを指します。たとえば「せいのう.jp」のWeb/APサーバのリソース使用率がキャパシティ限界の原因となっているとします。この場合、スケールアウトとして、Web/APサーバを1台増やすと、今まで1台で実施していた処理が2台に分散されるため、システム全体のキャパシティが向上します。

また、一般的にスケールアップよりスケールアウトのほうがコスト的に有利だと言うことがいえます。なぜなら、スケールアップでCPU等を増設していくことに比べて、安価なサーバを増設していくほうが一般的に安上がりなことが多いからです。ただし、スケールアウトでサーバを増設していくと、増えたサーバの管理が煩雑になってしまうので注意が必要です。

スケールアップ、スケールアウトの使い分け

それでは、どの種類のサーバがスケールアップ、スケールアウトに向いているのでしょうか。結論から言うと、スケールアップはDBサーバ、スケールアウトはWebサーバ、APサーバに向いていると言えます。

まずスケールアップですが、基本的に、スケールアップは主にDBサーバで行います。なぜなら、DBサーバは基本的にスケールアウトに向いていないからです。そもそも、DBサーバをスケールアップすることができるようになってきたのは最近の話で、たとえば、OracleだとOracle RAC、PostgreSQLだとPostgresForestのような製品がそれにあたります。

しかし、これらの技術にはまだいくつか課題があると言えます。たとえば、今回の「せいのう.jp」のようなオンラインショッピングサイトのようにデータベースの更新処理が頻繁にある場合は、商品の在庫数など、各DBサーバに存在する同じデータベースが一貫性を持つ必要があるため、この同期や連携がボトルネックとなり、思った通りの性能が出なくなってしまうことがあります。DBサーバのスケールアウトはこのような特徴を持っているため、DBサーバのハードウェアを決める際はリソース拡張の余地がある製品を買うことをお勧めします。

また、スケールアウトは主にWebサーバ及びAPサーバで行います。なぜなら、DBサーバと違い、WebサーバやAPサーバの処理は主にデータの同期や連携が必要ないことが多いので、サーバ増設でのキャパシティ改善が容易に可能だからです。もちろんスケールアップでのキャパシティ改善も可能ですが、一般的に安価なサーバを増設していくスケールアウトの方がコスト的に有利なため、Webサーバ、APサーバではスケールアップでキャパシティ改善を行うことが多いです。

サーバリプレース

サーバリプレースは、現在使用しているサーバをより高性能なサーバに更改することで、キャパシティ向上をすることを指します。サーバリプレースは、チューニングやスケールアウト、スケールアップではキャパシティ改善が見込めない場合（ハードウェアが古く、CPUを増設しても処理能力の向上があまり見込めない場合等）に行うことが多いです。サーバリプレースはキャパシティ改善効果が高いですが、すでに稼働しているサーバを再構築しなければいけないため、その分コストも高くなります。サーバを新しく購入するコストに加え、サーバ構築・動作確認コストなどがかかってきます。

表3に、キャパシティ改善の方法についてまとめます。

では、せいのう.jpの例で対策方法を考えてみましょう。今回の例では詳細な前提がないので何とも言えませんが、もしデータベースやSQLにチューニングの余地があるならチューニングを実施し、すでにチューニング済みでこれ以上チューニングの余地がないようなら、DBサーバのCPUの増設をするのが良いと思われます。ただし、CPUを増設する際は、前述したCPUスケーラビリティを考慮したスケールアップが必要になってくるので注意しましょう。

第3回ではキャパシティ改善 ─対策立案フェーズの「目標の決定」「⁠方法の決定」について説明しました。第3回では、キャパシティ改善するために十分なハードウェアの性能を決めるサイジングと、キャパシティ改善後の効果確認ついて説明していきます。