システムは変化し続ける――キャパシティプランニング攻めの性能マネジメント

システムがひとたびリリースされた後も、性能問題のリスクは常に残っている。そうした芽を早く摘み取るためには、性能監視に加えて分析が欠かせない。今回はキャパシティプランニングの基本的な考え方を紹介する。

» 2007年12月13日 12時00分 公開
[三由研一,NTTデータ]

キャパシティプランニングの背景

 第4回「失敗事例に学ぶ運用性能品質向上策」では、運用工程でのポイントの1つとして、性能監視と診断の大切さを紹介しました。今回は、安定運用に求められるシステム処理能力を確保するという観点に着目して、一歩掘り下げて考えていきます。

 システムの最大処理能力は、設計時にシステム構成を確定した段階で決まっています。第3回「ハード性能以上の性能は出ないんです」では、業務要件からIT基盤要件を求め、システム構成を決定するプロセスを紹介しました。そして、それらは仮置きした前提条件など不確定な要素を含んでいることを説明しました。

 実際のシステムでは、すべての前提条件が満たされているとは限りません。また時間と共に変わってしまう場合もあります。例えば、アプリケーションの度重なる修正や、新機能の追加によって、アプリケーションの処理内容が次第に重くなったり、業務の利用パターンが変わったりするのはまれなことではありません。また、インターネットを介した一般利用者向けのシステムや、スモールスタートでビジネスをしているシステムでは、何らかのきっかけで突然業務量が急増するような事態も起こり得ます。

 このようなときに CPU、メモリ、ディスクなどのシステムリソースがどの程度使われているか把握できないと、迅速な対処が行えません。システムに求められる処理能力は常に変わるという認識を持ち、サービス品質を維持するための柔軟性を備えておくことが大切です。システムの性能を継続的に把握して、必要なシステムリソースが着実に提供できる仕組みを用意する、これがキャパシティプランニングと呼ばれる取り組みとなります。

まずは情報収集

 キャパシティプランニングの第一歩は、性能評価に必要な監視項目や判断基準、そしてサーバ追加などの対処を実施するタイミングを規定した性能管理計画を立案し、実装することから始まります。

 第4回で、システムの性能は、業務性能とシステム統計情報の2つの視点から監視できることをお伝えしました。業務性能の監視項目や判断基準は、通常は性能要件と照らし合わせて設定されます。例えば性能要件の中で、オンラインレスポンスタイムの目標値を5秒と定めているのであれば、それに準じた監視項目を設定する必要があるでしょう。

 一方、システム統計情報の判断基準は、システムが提供するサービスの処理方式によって異なってきます。以下では、オンライン処理とバッチ処理を対象に、それらの特徴と代表的なシステム統計情報であるシステムリソースの判断基準を確認しておきます。

 オンライン処理の場合は、以下のような特徴があります。

  • 処理開始のタイミングは利用者からのアクセスによって決められる
  • 一定の確率で複数の処理のタイミングの重なりが発生する
  • その場合でも、一定のレスポンスタイム内に収めることが求められる

 従って、複数の処理タイミングが重なる場合に備えて、システムリソース使用率には余裕を持っておく必要があります。具体的には、CPU使用率を70%以下に抑えるといった基準になります。一方、バッチ処理の場合は特徴が異なります。

  • 処理開始のタイミングや、複数の処理の重なりはあらかじめ決められている
  • 所定時間内にすべての処理が完了することが求めらる

 従って、判断基準はオンラインよりも緩やかになります。バッチ処理の並列度を上げて、CPU使用率が100%とする判断もあり得ます。

 両者の処理が混在するシステムの場合はどうすればよいでしょうか。その場合は、バッチ処理の実行中でも、オンライン処理が影響を受けないよう、バッチ処理の並列度を少なくするなどの配慮が必要になります。

比較によって問題の予兆を見つける

 性能監視を通じて性能情報が収集されたら、次のステップはそれらの情報の分析です。分析の目的は、システム外部や内部の環境の変化を読み取り、性能問題の予兆を検出することです。このアプローチは、性能が徐々に変化していく場合に有効です。

 具体的な分析の観点として、以下に代表的な2つの観点を紹介します。

1)時系列の変化を読み取る

 ここでは業務量を例にとって説明します。通常、業務量は時間と共に変動します。そこで、業務量の時系列の変化を読み取ることが分析の第一歩となります。ここでは時系列の変化を、3つの要素に分解して考えてみます。

  • トレンド――直線的に変化する全体の変化の方向。例えば、前年比で何パーセント増えているという傾向
  • サイクル――周期性を持って変化する要素。例えば、季節や曜日によって業務量が定期的に変わる場合
  • イベント――突発的な変化を伴う要素。例えば、新商品の発売開始時やキャンペーン期間などに起こる
ALT 時系列の変化を3つの要素に分解して考える

 こうした要素に分解することができれば、トレンドやサイクルをもとに当初の業務量予測と実際の乖離(かいり)はどの程度あるか、また現在の傾向が続くと仮定したときに、いつまで安定的にシステムを運用できるか、といった診断を行うことができます。また、イベント型の変化についても、過去の発生状況とその理由を分析することで、次回イベントが発生した場合の影響の程度を見極めることが可能となります。

2)システム特性の関連性を読み取る

 異なる分析の観点としては、業務量、CPU使用率などの個々の性能データの関連性を比較する方法もあります。通常、大量の業務を処理するには、より多くのシステムリソースが必要になります。つまり業務性能とシステム統計情報は相互に関連していますので、以下のような分析が可能となります。

  • 業務量の増加に対して、レスポンスタイムあるいは処理時間はどのように変化しているか
  • 業務量の増加に対して、CPU使用率などリソースはどのように変化しているか

 こうした分析を、過去の分析結果と比較することで、システム内部の振る舞いの変化を読み取ることができます。特に、アプリケーションの修正が行われた場合は、これらの関係が変わることがありますので、注意して分析する必要があります。

早めの対策を

 次のステップは、分析結果に対して対策を講じるチューニングになります。チューニングの目的は、システムを最適化して、求められる業務性能を達成することですが、対応方法はさまざまです。

 例えば、業務量が急激に増加していれば、システム増強の時期を見直す必要があるかもしれません。イベント型の業務量増加が問題となっている場合は、新商品の発売時期をずらすなどイベントの発生時期をコントロールする対策も有効でしょう。システム特性の変化が起きている場合は、ミドルウェアのパラメータ変更、アプリケーションの修正といった対処の有効性を検証することも考えられます。

 いずれにしても、過去の分析との比較が、原因の絞り込みや対策の立案に役立ちます。対策の立案と並行して、新たな監視項目の追加や閾(しきい)値の見直しを検討することで、性能管理の仕組みをブラッシュアップしていくことができます。

問題がなくても繰り返すことが大事

 これまで述べた性能監視、分析、チューニングと実装の一連の作業が、キャパシティプランニングの基本サイクルとなります。キャパシティプランニングは、品質管理における PDCA サイクルであり、繰り返しが大切です。システムの状態を継続的に計測・把握するという活動は、即座に価値を生み出すものではありません。最悪の事態に備えるために一定の対価を払うという意味で、保険と似ています。問題が顕在化してから対処して、再発防止策を講じるといった方法だけでは、限界があります。システムライフサイクルの中で問題が発生する可能性やその際の影響を考慮して、適切な性能管理を検討することが肝要です。

 次回は、ベストプラクティスとして、性能マネージメントのプロセス全体を総括していきます。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ