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

第2回 キャパシティ改善計画【分析フェーズ】

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

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

対象のシステム

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

表1 対象のシステム

サイト名せいのう.jp
サイト内容オンラインショッピングサイト
業務の種類商品検索,商品閲覧
目標レスポンスタイム5秒
システム構成Web/APサーバ×1,DBサーバ×1
システム稼働期間2008年1月~2009年12月
現在の年月2009年2月

図1 対象のシステム

図1 対象のシステム

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

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

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

図2 分析フェーズの流れ

図2 分析フェーズの流れ

システムの現状把握

現状把握の考え方

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

① 性能データについて

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

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

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

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

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

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

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

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

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

図3 アクセス数のピーク

図3 アクセス数のピーク

著者プロフィール

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

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


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

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

コメント

コメントの記入