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

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

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

方法の決定

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

チューニング

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

表2Web3層構成のシステムにおけるチューニング方法

 WebサーバAPサーバDBサーバ
OSカーネルパラメータの最適化
ミドルウェア同時接続クライアント数の最適化スレッド数の最適化
DB接続数の最適化
メモリ使用量の最適化
AP接続数の最適化
メモリ使用量の最適化
アプリケーション動的コンテンツの静的化余分な処理の削減インデックスの最適化
データベース実行計画の最適化
SQLの改善

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

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

※1)
Web層,アプリケーション層,データベース層の3層から成り立つシステム。論理的な概念なので,必ずしもサーバが3種類に分かれているわけではありません。

スケールアップ

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

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

図4 CPUスケーラビリティ

図4 CPUスケーラビリティ

またそれ以外にも,現在のサーバの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に,キャパシティ改善の方法についてまとめます。

表3 キャパシティ改善方法

 チューニングスケールアップスケールアウトサーバリプレース
改善対象ソフトウェアハードウェアハードウェアハードウェア
方法非効率な処理の削減リソース増設/交換サーバ増設サーバ交換
メリットソフトウェアの変更だけで済むリソースを増設/交換するだけで済む安価なサーバを増設するだけで済む大幅なキャパシティ改善が見込める
デメリット場合によっては調査、改修コストが高くなる改善に限界がある場合があるサーバ台数が多すぎると管理が煩雑になるためコスト増左記に加え,サーバ再構築のコストがかかる
適する用途Webサーバ
APサーバ
DBサーバ
DBサーバWebサーバ
Webサーバ
APサーバ
DBサーバ

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

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

著者プロフィール

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

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


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

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