コラム連載版の2回目になりますが、前回は性能監視のポイントとして、マルチベンダー・マルチインフラデバイスを「俯瞰的」に把握し、システムの「ウィークポイント」を発見することであると挙げさせていただきました。

複雑に増え続けるインフラ環境を俯瞰的に把握するには、当然さまざまなテクニックが必要になります。
今回のコラムはアイビーシーの性能監視の分析の考え方を少しご紹介させていただきます。

弊社では、コンサルティングサービスの一環で、さまざまなインフラシステムの性能分析を実施しておりますが、分析の際には必ず、現状の業務システムの稼働状況や過去のトラブル例、最近のイベント等を確認させていただき、その内容とICTインフラの構成から、分析ポイントを絞り込みます。

当月内にシステム変更を行った場合や、利用ユーザーが増えた、ならびにシステムの遅延が発生した等があれば、対象や関連するホストのイベント日時の前後での性能情報データから、何が問題だったのか、今後問題となりうるのか、そして今後のシステム変動予測等を割り出します。

システムの稼働状況を正確に把握することができる場合は、上記にあるようにポイントを絞り込み、関連する性能データを確認する為に調査対象を広げていくといったことができますが、まったく状況が把握できない場合もあります。

その場合には、我々の分析の手法として、性能情報データの中から、「品質」に関連するものからチェックをいたします。
分かりやすい例で言えば、ユーザー観点からみるとWeb系システムの分析であれば http や DNS Request に対する応答時間が「品質」の対象となり、ネットワーク観点では、Error Packet や TCP Retransmission の発生になります。
ちなみに「品質」以外の性能情報としては、CPU使用率やDisk I/O、Traffic使用量があり、我々は「性能」と位置付けています。

少し強引な話をしますと、「性能」がどれだけ負荷が高い状態でも、Webシステムの応答が良いといった「品質」が良好であれば、システム的には問題はありません。
その観点から、まずは「品質」というポイントを把握し、品質の劣化があった際の要因を特定するということで、「性能」データを確認します。
ネットワーク遅延を把握した際に、その要因がTraffic情報から帯域の不足なのか、CPU等のリソースの問題なのか、といった見方になります。

そして、それぞれの手法に共通して言えることは、http応答時間が400msであったり、CPU 60% や Traffic 50Mbpsといった、現行でのリソース値や応答時間といった数値だけでは判断が付かない場合が多数ある為に、先月の同時間と比べてどうか、昨年の同月と比べてどうかといった「傾向」から、システムの変化を把握することが重要になります。

以上が我々の性能分析の考え方になりますが、そもそも、性能情報データの精度やデータ蓄積、そしてシステム全体の情報を取得するといった性能監視の基本的な部分は最低限網羅している必要はありますが、その性能情報データを活用しなければ性能監視として意味がありません。

性能監視・性能分析の運用方法としてのお勧めは、まずはデータを取得し続け、「傾向」を把握することで、自社システムの「基準値」を策定することです。
机上で多数の性能情報データを「性能」「品質」として区分けを行うことや、現行システムから性能監視ポイントを策定することはできても、上記の「基準値」は稼働していているシステムから性能情報データを取り続け、そこから割り出すことしかできません。

性能監視の目的でもある「システムの予兆検知」や「キャパシティ管理」の効果を得るためにも、まずはシステム全体の性能情報データを取得し続けることが、最初のスタートであります。

次回は、性能分析で重要と記載した「品質」を捉える手法の詳細について、もう少し詳しく記載いたします。

by 技術部　塚本 浩之