前回の「kanshi de mirai」では、弊社の性能監視の基本的な考え方をご紹介いたしました。今回はもう少し的を絞って、データセンターやサービス事業者様を対象とした、「大規模システム」に対しての我々の監視の考え方についてお話ししたいと思います。

大規模の定義はいろいろありますが、例えば数千台のホストを監視する際の課題として

• システム全体を包括的に把握する
• 詳細な情報を一元的に収集する
• 膨大な監視ホスト・監視項目からいち早く問題点を把握する
• 傾向把握をおこなえる
• 障害の予兆を確実に検知する

といったことをよくお聞きいたします。

また、その中でもデータセンター特有の監視要件としては下記の点が挙げられます。

• オペレータ、管理者での統一指標での状況把握
• 監視情報を活用したサービス展開の容易性
• 自社以外のシステムも包括的に監視 (例：顧客向け監視サービス)

大規模システムによって運用されている監視システムでは、課題の根本的な要因はほぼ統一されており、「ツールの乱立」ならびに「属人化」がキーワードとなります。

なぜ「ツールの乱立」や「属人化」が発生するのかは、各システムを運用されている部門の運用手法や慣習にもよりますが、キーワードから3つの問題点が挙げられます。

1つ目の問題は「ツール」です。監視ツールは非常に多種多様ですが、システムを稼働させる際に例えばデーターベースサーバーやアプリケーションサーバー等のシステムを稼働させるためのメインとなる仕組みは真っ先に選定され、付随するネットワーク機器もそのスペックに合わせて検討が入ります。残念なことに我々が手掛ける監視の分野は検討の最後となるケースが多数で、本番稼働直前に選定が始まるケースもあります。何を監視すべきかといったシステム全体の監視の「目的」が明確ではなく、個々のシステムでツールを検討し、「手段」となるツールありきで監視手法を検討することで、システム毎の個別最適によりツールが乱立し、複雑な運用が必要となるケースもございます。

2つ目の問題は「人」で、監視をおこなうオペレータが複数人いるのに、監視ツールに対して新しいホストの登録や項目の設定、監視ツールで状態確認ができる人が限られている、または1名しかいないといった、「属人化」の問題がございます。こちらは監視ツールにOSSをご利用されているお客様からよくお聞きいたします。

3つ目の問題は「コスト」で、初期コストというよりも、ランニングコストが非常に負担となっているケースです。ここでいうランニングコストとはツールの費用だけでなく、設定や監視状況を把握する際に発生する人的なコストも含みます。トラブル対応の長期化による経営的な損害も含めるとより現実的になります。

この3つの問題をまとめてみると、

• 現在の経済事情の中でICTインフラの予算縮小もあり、システム導入時に「コスト」をベースにした「ツール」の選定をおこない、導入後実際に運用を始めると「人」の負担が非常に増えてしまった。
• 「ツール」選定時は対象システムのみの最適化のため、既存システムや今後予定するシステムへの展開が出来ず、新たなツールを個別に運用する必要があり、更に「人」への負担が増えていく。
• 現状運用をされているオペレータや運用管理者はシステムをいかに安定的に稼働させるかといったことよりも、とにかく現状のトラブルを解決するために「時間」と「リソース」を調整することが先決となっている。

といった具体例として多くの方からお聞きいたします。

大規模システム向けの監視ツールは多数ございますが、基本的に「性能監視」は「死活監視」のオプションであることが多く、あくまで補助的な扱いとなっておりますが、我々はICTサービスの本来の監視は「性能を把握すること」が一番重要であると考えております。

性能を把握することの目的は、現状の稼働状況（正常に稼働しているか）は当然のこと、取得した性能情報から今後のトラブルを未然に防ぐ「予防保守」ならびに、限られたシステムのリソースを有効的に活用するための「キャパシティ管理」を実施することが本来の「監視」ではないでしょうか？

我々は大規模システムの監視の課題解決として、前回のコラムでもご紹介いたしました「System Answer G2」を発売しました。

1つの監視システムで多数の監視が可能になるといった単純なことだけでなく、膨大な監視対象から何を確認する必要があるのか、いつもどおりの稼働状況なのか、先週や先月、昨年以降と比べて傾向はどうか、別システムと比べてどうなのか、といった運用目線で必要な情報を瞬時に把握できる機能を含めております。

大規模システム向けの新たな機能の中から1つだけご説明いたしますと、大規模システムでは「いつもどおりの稼働状況なのか」を把握することが一番重要な位置付けとなります。一般的な死活監視や性能監視ツールでは、特定の値を定義してその値を上回った、または下回った場合にアラートとするしきい値監視が一般的です。これはバーストと呼ばれる性能変化には非常に有効な手法ですが、大規模システムでデータが集中する箇所ではバーストは発生しないのが現状です。

少し古いのですが、Alcatel-Lucent社 Bell研究所 から発表されている内容を下記に抜粋いたします。

「通常はトラフィックのバーストは多数発生するが、同時接続数が増大すればするほどネットワークの核となる部分ではランダム性が増し、規則正しく滑らかになる為、バーストは発生しない」（出展：Bell Labs Internet Traffic Research）

また、この内容は実際に我々の多数の性能分析からも傾向が出ており、「規則正しく滑らかになる」といった周期的な稼働状態から大きく変動があった場合は何らかのトラブルが発生していることも多数ございました。

我々はこのような状態の把握、ならびに予兆検知の観点から、新たな監視手法として、「ベースライン監視」機能を G2 で搭載いたしました。この機能は取得した性能情報からシステムの周期性を学習し、いつもどおりの稼働状況から大きく乖離した場合に、システムの異常が発生したのではと判断してアラート状態とするものです。大規模システムでの活用としては、コアネットワークでのトラフィック・パケットの推移や、負荷が集中するサーバのリソース、データセンターの監視サービスになりますと、提供ユーザーの稼働状況を把握した上でしきい値を予測することはかなり困難ですが、「いつもどおりではないので、何かあったのでは？」という観点から障害通知をお客様に提示するといったサービス提供にも活用いただけます。

大規模になればなるほどトラブル対応は非常に時間がかかります。

まずは障害予兆を正確に把握し、事前に対応できる問題点を適切に改善することで、現在の運用者の負担の半分はクリアできると考えております。問題点についても、System Answer G2という「ツール」を活用して、乱立したツールの整理から始めることで、効率化の中から対応を実施する「人」や、全体的な「コスト」を抑制することが可能となります。その後に「人」をシステムの最適化のためにリソースを割り当て、更なる安定稼働に導くことが可能となります。

なぜ監視をおこなうべきか、ICTサービス全体最適という「目的」を明確にし、現在の運用を見直すことがシステムの安定稼働の一番の近道であると考えております。