第2回では,
対象のシステム
これからキャパシティ改善の説明をするにあたり,
表1 対象のシステム
サイト名 | せいのう.jp |
---|---|
サイト内容 | オンラインショッピングサイト |
業務の種類 | 商品検索, |
目標レスポンスタイム | 5秒 |
システム構成 | Web/ |
システム稼働期間 | 2008年1月~2009年12月 |
現在の年月 | 2009年2月 |
さて,
キャパシティ改善計画・分析フェーズ
まず,
システムの現状把握
現状把握の考え方
まずはシステムの現状把握をします。システムの現状把握を行う前に,
- ① 性能データについて
システムの現状把握は,
基本的に稼働中のシステムから取得した性能データを元に行います。性能データとは, 後ほど紹介するアクセスログやリソース使用率のログ等です。逆に言うと, 性能データを取得していないと, 現状分析は行えませんし, さらに言えばキャパシティ改善も行うことができません。こうなっては後の祭になってしまいます。ですので, 稼働中のシステムでは必ず性能データを取得しておくようにしましょう。ただ, そうは言っても, 性能データがない状態でキャパシティ改善をしなければいけないこともあると思います。その際は, まずその日からでもいいので, システムの性能データの取得を始めましょう。データ量は少ないですが, それなりの現状把握はできるはずです。 また,
キャパシティ改善が緊急の場合や, 数日のデータでは現状把握をできない場合もあります。その際によく行う代替案としては, 検証環境や開発環境で性能測定を実施して性能データを取得する, または稼働中のシステムを停止させ, 本番環境で性能測定を実施する等が挙げられます。前者では環境の差分で発生する性能データの誤差のリスクがありますし, 後者ではシステムを停止させた分の損失が発生する恐れがあります。また, 両者とも, 負荷生成ツールなどで仮に発生させたアクセスの下での性能データのため, それによる性能データの誤差も生じてしまいます。ですので, このようなことがないよう, 常日ごろから性能データを取得しておく必要があります。 - ② 性能データの集計単位について
システムの現状把握をするにあたり,
性能データを集計する必要がありますが, これらの集計の単位に注意する必要があります。どう注意する必要があるかというと, 各データの集計単位を揃える必要があるのです。 たとえば,
ある性能データが10分ごとの平均で, もう1つの性能データが30秒ごとの合計値であった場合, これらのデータは単純に比較することができないため, これでは現状把握をすることができません。ですので, 必ず集計前に集計単位を決めておきましょう。今回の例では, 5分ごとの平均で見ていくことにします。 - ③ アクセス数のピークについて
システムの現状把握では,
基本的にアクセス数のピーク時の性能データを使用します。キャパシティ改善の目的は, アクセス数がキャパシティを上回らないようにすることです。しかし, アクセス数はいつでも同じ数というわけではありません。アクセス数が少ない時間帯もあれば, 多い時間帯もあります。では, どの時間帯のアクセス数を確認すればよりのでしょうか。それは, アクセス数の最大時, つまりピークで考える必要があります。なぜなら, ピーク時にシステムのキャパシティを上回らないことを確認しておけば, 基本的にはアクセスがキャパシティの限界まで到達することはないと言えるからです。ですので, 現状把握では, アクセス数のピークを使用します。 また,
ピークにはシステムによってさまざまな特性があり, その特性によってピークの見方を変える必要があります。 たとえば,
ユーザが主に月末に処理を行うようなシステムでは, ピークは月末に発生し, ピークは月単位で見ていく必要があります。また, 今回のようなオンラインショッピングサイトのようなシステムでは, ピークは夜間帯に発生することが多く, ピークは日単位で見ていく必要があります。ですので, まずは現状分析を始める前に, システムのピークの特性を把握しましょう。今回の例では, 「せいのう.jp」 はオンラインショッピングサイトですので, 本来はピークを日単位で見ていくべきですが, 今回は説明を簡単にするため月単位で見ていくこととします。以下に, アクセス数のピークについて図でまとめます。