第2回では、キャパシティ改善の最初のステップである「キャパシティ改善計画─分析フェーズ」について解説していきます。

対象のシステム

これからキャパシティ改善の説明をするにあたり、下記のシステムを想定して話を進めていきます（表1、図1⁠）⁠。

さて、「⁠せいのう.jp」の管理者であるあなたは、ある日サイトのアクセス状況を調査したところ、アクセス数の伸びが想定していたものよりも多いことがわかりました。このままでは、近々にでもアクセス数がキャパシティを上回ってしまう恐れがあります。しかし、あなたは、アクセス数がキャパシティをいつ上回ってしまうのか、また、上回ってしまわないよう何をどうすればいいのかが全くわからない状況です。でも焦ってはいけません。キャパシティ改善のステップを着実に踏み、これらの不明点を明確にしていきましょう。

キャパシティ改善計画・分析フェーズ

まず、キャパシティ改善で最初にやるべきことは「分析」です。分析フェーズでは、性能データからシステムの現状を把握し、その結果からシステムの将来の性能を予測し、システムのキャパシティ限界到達時期とその原因を把握します。この結果を元に、次のフェーズでキャパシティ改善の対策を考えます。図2に、分析フェーズの流れをまとめます。

システムの現状把握

現状把握の考え方

まずはシステムの現状把握をします。システムの現状把握を行う前に、現状把握を行う上での基本的な3つの考え方を説明します。

① 性能データについて

システムの現状把握は、基本的に稼働中のシステムから取得した性能データを元に行います。性能データとは、後ほど紹介するアクセスログやリソース使用率のログ等です。逆に言うと、性能データを取得していないと、現状分析は行えませんし、さらに言えばキャパシティ改善も行うことができません。こうなっては後の祭になってしまいます。ですので、稼働中のシステムでは必ず性能データを取得しておくようにしましょう。ただ、そうは言っても、性能データがない状態でキャパシティ改善をしなければいけないこともあると思います。その際は、まずその日からでもいいので、システムの性能データの取得を始めましょう。データ量は少ないですが、それなりの現状把握はできるはずです。

また、キャパシティ改善が緊急の場合や、数日のデータでは現状把握をできない場合もあります。その際によく行う代替案としては、検証環境や開発環境で性能測定を実施して性能データを取得する、または稼働中のシステムを停止させ、本番環境で性能測定を実施する等が挙げられます。前者では環境の差分で発生する性能データの誤差のリスクがありますし、後者ではシステムを停止させた分の損失が発生する恐れがあります。また、両者とも、負荷生成ツールなどで仮に発生させたアクセスの下での性能データのため、それによる性能データの誤差も生じてしまいます。ですので、このようなことがないよう、常日ごろから性能データを取得しておく必要があります。

② 性能データの集計単位について

システムの現状把握をするにあたり、性能データを集計する必要がありますが、これらの集計の単位に注意する必要があります。どう注意する必要があるかというと、各データの集計単位を揃える必要があるのです。

たとえば、ある性能データが10分ごとの平均で、もう1つの性能データが30秒ごとの合計値であった場合、これらのデータは単純に比較することができないため、これでは現状把握をすることができません。ですので、必ず集計前に集計単位を決めておきましょう。今回の例では、5分ごとの平均で見ていくことにします。

③ アクセス数のピークについて

システムの現状把握では、基本的にアクセス数のピーク時の性能データを使用します。キャパシティ改善の目的は、アクセス数がキャパシティを上回らないようにすることです。しかし、アクセス数はいつでも同じ数というわけではありません。アクセス数が少ない時間帯もあれば、多い時間帯もあります。では、どの時間帯のアクセス数を確認すればよりのでしょうか。それは、アクセス数の最大時、つまりピークで考える必要があります。なぜなら、ピーク時にシステムのキャパシティを上回らないことを確認しておけば、基本的にはアクセスがキャパシティの限界まで到達することはないと言えるからです。ですので、現状把握では、アクセス数のピークを使用します。

また、ピークにはシステムによってさまざまな特性があり、その特性によってピークの見方を変える必要があります。

たとえば、ユーザが主に月末に処理を行うようなシステムでは、ピークは月末に発生し、ピークは月単位で見ていく必要があります。また、今回のようなオンラインショッピングサイトのようなシステムでは、ピークは夜間帯に発生することが多く、ピークは日単位で見ていく必要があります。ですので、まずは現状分析を始める前に、システムのピークの特性を把握しましょう。今回の例では、「⁠せいのう.jp」はオンラインショッピングサイトですので、本来はピークを日単位で見ていくべきですが、今回は説明を簡単にするため月単位で見ていくこととします。以下に、アクセス数のピークについて図でまとめます。

システムの現状を把握するための4つの観点

それではシステムの現状把握を始めましょう。システムの現状把握では「業務」「⁠リソース」「⁠サービスレベル」「⁠ライフサイクル」の4つの観点に分けて情報を整理し、グラフを作成します。以下、それぞれについて説明します。

業務

業務とは、ユーザがシステム上で行う処理のことです。これらに関する「量」と「種類」を把握します。なぜ単純に量だけで把握しないかというと、業務の種類によって性能に与えるインパクトが異なることがあるからです。これらは基本的にはWebサーバやAPサーバのアクセスログから集計します。今回の例では、せいのう.jpでは商品検索と商品購入の2種類の処理があるため、この2種類に分けてアクセス数を把握します。

また業務の観点では、データベース内のデータ量、種類も把握する必要があります。なぜなら、データ量は検索などの処理時間に影響を及ぼすことがあるからです。今回の例では、商品検索の処理時間に影響すると思われる商品データ量を見ていくことにします。

リソース

リソースとは、サーバに搭載されている「CPU」「⁠メモリ」「⁠ディスク」「⁠ネットワーク」のことを指します。これらのリソースの使用率を把握します。リソース使用率のデータは、一般的にはWindowsならパフォーマンスモニタ、Unix系ならstat系のプログラムで取得します。今回は話を簡単にするため、一番キャパシティ限界の原因になることが多い「CPU」に絞って話を進めていきます。

サービスレベル

サービスレベルとは、ユーザに業務を提供しているレベルを表す指標です。これらは「スループット」「⁠レスポンスタイム」の2つで表されます。これらは性能指標値と呼ばれることもあります。スループットとは、システムがユーザのアクセスに対し、時間単位辺りにどれくらいのレスポンス数を返しているかを表す値です。例えば、1秒間に10個のレスポンスを返していれば、スループットは10レスポンス/秒となります。

また、レスポンスタイムとは、システムにユーザのアクセスが到着してから、レスポンスを返すまでにどれくらいの時間が掛っているかを表す値です。これらの値は、一般的にはWebサーバやAPサーバのアクセスログから集計します。

なお、レスポンスタイムの値を見る際には1つ注意点があります。それは、基本的にレスポンスタイムの値は平均ではなく、90%ileで把握するということです。なぜかというと、Webシステムのレスポンスタイムは、キャパシティの限界に到達していなくても、極端に遅いレスポンスタイムが僅かながら存在する可能性があるからです。この原因は主に、インターネット網の遅延や、JavaアプリケーションであったらGCによるアプリケーションの一時停止などが挙げられます。これにより、レスポンスタイムの平均値は極端に遅いレスポンスに引きずられ、正確でない値を示すことが多いので、レスポンスタイムを見る上で平均値は基本的には使用しません。そこで何を使用するのかというと、経験則で90%ileの値を使用することが多いのです。

90%ileとは、値を小さい順に並べた時に90％番目に来る値のことです。たとえば、90%ileレスポンスタイムが3秒であったとすると、90％のレスポンスは3秒以内に収まっているということがわかります。今回の例でも、レスポンスタイムは90%ileで把握していきます。

ライフサイクル

最後に、システムのライフサイクルを確認します。ここでは、システムに起きる将来のイベントを把握しておきます。

まずはじめにシステム終了日を把握する必要があります。システム終了日とは、そのシステムが現在の構成で稼動する最終日のことで、主にシステムの更改日のことを指します。システム終了日を把握する理由は、キャパシティ改善のゴールを見定めるためです。

第1回でも説明したとおり、キャパシティ改善のゴールは「目標レスポンスタイムを満たした状態で、システム使用終了日までシステム運用できる状態」を実現させることでした。システム終了日がわかれば、アクセス数が増加傾向にあっても、どこまでキャパシティを改善すればよいかが確認できます。仮にシステム終了日がなく、アクセス数が増加傾向にあれば、要求されるキャパシティは際限なく上がっていくので、キャパシティ改善のサイクルを定期的に回していく必要があります。

また、業務追加の予定を把握しておく必要があります。なぜなら、業務を追加するということは、業務の種類が増えるということになり、これに対する性能のインパクトも考慮する必要があるからです。但し、追加された業務については、蓄積された性能データが存在しないため、これに関しては性能測定を実施して、性能データを取得する必要があります。今回の例では、話を簡単にするために、業務追加はないこととします。

さらに、データ量の増加に関しても予定を把握しておく必要があります。これは上記で説明したとおり、データ量の増加が性能に影響を与える可能性があるからです。今回の例では、毎年6月に商品データ量が増加することとします。

最後に、アクセス傾向の変化についても押さえておく必要があります。オンラインショッピングの例ですと、何かしらのキャンペーンを実施するといったことがそれにあたります。キャンペーンを実施すると、一時的にアクセス数が増加することが考えられます。これらの増加は、性能データの傾向からは予測することができません。ですので、キャンペーンなどの予定をあらかじめ把握し、将来の予測に反映させる必要があります。今回の例では、説明を簡単にするために、アクセス傾向の変化は無いものとします。

以下に、4つの観点についてまとめます。

次に、今回の例である、せいのう.jpの現状把握のグラフをまとめます。グラフは、毎月のピーク時のデータをプロットしたものです。2軸グラフになっていて、左の縦軸が「アクセス数」「⁠データ量」「⁠スループット⁠」⁠、右の縦軸が「CPU使用率」「⁠レスポンスタイム」を表しています。なお、第1回でせいのう.jpのアクセス数の話をしましたが、今回のグラフはその時のアクセス数と違うものになっているのでご注意ください。

将来の性能予測

さて、システムの現状把握ができたら、次はその結果を使用し、将来の性能を予測します。ここでは、アクセス数やデータ量、リソース使用率の伸び傾向から、いつシステムがキャパシティの限界を迎えるか、そしてその時の原因が何であるかを予測します。キャパシティの限界はリソース使用率が限界付近に達したところで判断します。CPU使用率の観点だと、一般的にWebシステムではCPU使用率が80％を超えたあたりから、レスポンスタイムの悪化が見られるため、CPU使用率の限界を80％として見ることが多いです。但し、システムの稼働前に性能試験を実施し、システムのリソース使用率の限界を把握している場合は、そちらの値を使用してください。今回の例では、CPU使用率の限界を80％として見ていきます。

以下に、上記の現状把握の結果から予測した将来の性能を掲載します。尚、スループット、レスポンスタイムの値は、過去の性能データから予測することが出来ないため、あくまで参考値としてとらえてください。

まず、結論としては、2009年7月の時点で目標レスポンスタイムである5秒を達成できなくなっているため、キャパシティ限界を迎えています。ですので、せいのう.jpはこのまま運用を続けていくと、2009年7月にはユーザへのレスポンス遅延が生じる可能性があることがわかります。また、キャパシティ限界を迎えた原因は、DBサーバのCPU使用率が80％に達したことだと予測されます。また、DBサーバのCPU使用率を増加させている原因は、月ごとに増加傾向にある商品検索と商品注文のアクセス数だと予測できます。なぜなら、両業務のアクセス数の増加とDBのCPU使用率の増加に相関関係が見られるからです。ただし、この業務は両方とも増加傾向にあるため、どちらのアクセスの増加がDBのCPU使用率の増加に影響しているかはこのグラフからは読み取れません。

また、商品データが2008年6月、2009年6月の2回に渡って増加していることがわかりますが、これは性能にはあまり影響がないと予測できます。なぜなら、2008年6月のデータ量増加時に、他の性能データに影響を与えている傾向が見られないためです。なお、キャパシティの限界を迎えると共に、スループットが頭打ちになっているのがわかります。これはキャパシティ限界を迎えたことにより、システムがユーザに返却できるレスポンスの数が頭打ってしまったことを意味します。

結果をまとめると、せいのう.jpは2009年7月にキャパシティの限界に到達し、その原因はDBのCPU使用率が80％に達することだと予測されます。なお、この予測はあくまでも机上のものなので、データの確度は高いとは言えません。ですので、この結果を目安に、余裕をもったキャパシティ改善の対策を考える必要があります。

今回はキャパシティ改善計画の分析フェーズについて説明しました。次回第3回では、分析フェーズでの結果から具体的な対策案を考える、キャパシティ改善計画の対策立案フェーズについて詳しく説明します。