クラウド監視ツールの決め方とおすすめツール

監視ツール選びの基本

クラウド環境の監視において、監視ツールはどのように選定すべきでしょうか。ここでは、監視ツール選びにおける基本的な考え方を説明します。

監視要件を整理する

監視ツールを選定する前に、まずは監視要件を整理する必要があります。要件が整理できていないと、監視対象とする情報やその監視頻度も明確にならず、適切な監視ツールを選定することができません。

最初に監視の要件をきちんと定義し、システムに関わるメンバーの間で共有しておきましょう。

例えば、監視要件として以下のような項目を挙げることができます。

• 死活監視を行うか。
• リソース監視を行うか。行う場合、その指標はどうするか。
• OS上のサービスやプロセスの監視を行うか。
• フロントエンド監視を行うか。
• アプリケーション監視を行うか。
• 通知を行う監視項目や通知先は決まっているか
• 通知方法は決まっているか

これらの監視要件（何を監視するか、どのように監視するか）のイメージを明確にすることで、その後のシステムの設計や構築もスムーズに進みます。システムの運用が始まった際に監視すべきものが監視できていないといった要件漏れも防ぐことができます。

監視要件を定義する

監視要件を整理した後、それをきちんと定義する必要があります。「整理」と「定義」は違うのかという疑問が出てきそうですが、ここでは「整理」を “イメージを明確にすること”と意味付け、それをより具体的かつ実現可能な形でアウトプットすることを「定義」と意味付けさせてください。この「定義」は、システム開発における「設計」のインプット材料となります。

今回は監視に焦点を置いて話を進めていますが、システムの新規導入やリプレイスを計画する際は、監視も含めたシステムの要件を定義するのが一般的です。機能個別で考えた要件も、システム全体で見ると他機能の要件との兼ね合いやコスト面で実現が困難な場合もあるからです。

それでは、どのようにシステムの要件を定義すればいいのでしょうか。ここでお勧めしたいのが、非機能要件との照合です。非機能要件とは、システムの機能面ではなくシステムが動作する方法に関する要件を定義したものです。

非機能要件は、独立行政法人「情報処理推進機構（IPA）」のサイトで公開されている非機能要求グレード表を入手することで確認できます。

情報処理推進機構 システム構築の上流工程強化（非機能要求グレード）紹介ページ

非機能要求グレードは、上記ページにて、以下赤枠で囲ったリンクのどちらかをクリックすることで入手可能です。”2018”とありますが、現時点で最新版となります。

　２つのリンクのうち、ZIPファイルの方を入手することをお勧めします。ZIPファイルの方には、非機能要求グレード表だけではなく、利用ガイドや活用シートも含まれるためです。

　非機能要件グレード表では、項番 C.1.3.1、C.1.3.2、C.4.4.1、E.7.1.1 ～ E.7.1.5 が監視関連の要件に該当します。

クラウド監視におけるツール選択

監視要件を定義できれば、いよいよ監視ツールの選定に進みます。監視要件を満たし、且つ監視以外の要件やコスト等を複合的に考慮して最適なツールを選びましょう。

クラウド構成別の検討

クラウド構成には、次のような種類があります。

パブリッククラウド

全てのクラウドリソースがクラウドサービスプロバイダによって管理・提供され、インターネット経由で提供される構成

プライベートクラウド

単独の企業や組織が専用的に使用するクラウドリソースよる構成

ハイブリッドクラウド

パブリッククラウドとオンプレミス、パブリッククラウドとプライベートクラウド、あるいは複数のパブリッククラウドを組み合わせた構成

これらのクラウド構成を考慮したうえで、監視ツールを選択する必要があるでしょう。

簡潔に言えば、オンプレミスや他クラウドを含むハイブリッドクラウドで、それらも監視対象に含める必要がある場合は、オンプレミスや他クラウドも監視可能なツールを選択しなければならないということです。

監視ツール一覧

クラウドベンダ提供の監視ツール

Amazon CloudWatch

はじめに、AWSが提供する監視サービスである「Amazon CloudWatch（以降 CloudWatch と記載します）」を紹介します。Cloud Watchは、他の様々なAWSサービスに加え、オンプレミスも含めたあらゆる情報を監視できるサービスです。監視対象の状態異常やしきい値超過を検知し、管理者への通報も可能です。

CloudWatchでは、次の監視を実現できます。

• ログ監視および収集
• メトリクス収集
• アラーム機能による通知やアクション実行
• ダッシュボードでのGUI管理

ログ監視および収集

AWSのサービスは勿論、他のクラウドから取得されるログや独自アプリケーションのログも監視できます。また、CloudWatch Logsというサービスを使用すれば、あらゆるAWSクラウドサービスのログを収取し、一元管理することも可能です。

収集したログの保存先としては、CloudWatch Logs以外にAWSのストレージサービスであるAmazon S3や、同じくAWSのストリーミング配信サービスである Kinesis Data Firehose を利用できます。

メトリクス収集

システムのパフォーマンスに関するデータを「メトリクス」といい、AWSが提供するあらゆるサービスを対象としてメトリクスを時系列で収集することができます。

「標準メトリクス」と「カスタムメトリクス」の２種類があり、標準メトリクスは無料で利用できますが、カスタムメトリクスは定義する数やAPIの呼び出し回数によって利用料金が発生します。

アラーム機能による通知やアクション実行

監視するメトリクスに関して、状態異常やしきい値を超過した場合に検知する条件や、検知後に実行したいアクションを「アラーム」として定義できます。

例えば、ＣＰＵ使用率などメトリクスに対して、監視間隔5分間の平均使用率が８０％を超過した場合に異常として検知することができます。

アラームにアクションを指定することもでき、アラームが発生した場合に、管理者へのメール通報やAWS Lambdaと連携してコードを実行することも可能です。

ダッシュボードでのGUI管理

ダッシュボード画面を利用すれば、ログやメトリクスを画面上でまとめて監視できます。ログやメトリクスなどの監視情報がグラフ等で可視化されるため、より直感的にリソース状況を確認できます。

AWSクラウドを利用する際は、監視ツールとしてCloudWatchを利用することをお勧めします。他のAWSサービスとの親和性を考えると、やはりCloudWatchを選択することは避けられません。

参考リンク（Amazon CloudWatchユーザーズガイド）

Azure Monitor

次に、Microsoft Azureが提供する監視サービスである「Azure Monitor」を紹介します。

Azure Monitorもまた、Amazon CloudWatchと同様にクラウド環境とオンプレミス環境の両方を監視できるサービスです。

Azure Monitorでは、次の監視を実現できます。

• アプリケーション監視
• 死活監視
• インフラストラクチャ監視
• ログ監視
• リソース監視
• アラート機能

アプリケーション監視

Azure Monitor の拡張機能である Application Insights を使用すれば、実行中のアプリケーションの使用状況とパフォーマンスを監視・分析できます。Azure上のアプリケーションだけでなく、Azure外部のアプリケーションも監視可能です。

死活監視

サーバーやネットワーク機器などが正常に動作しているかどうか、ネットワークを介して確認します。ネットワークの監視や、検知した問題の診断ができます。

インフラストラクチャ監視

Azure上で利用されているインフラリソースの状況を可視化します。Azure VM（仮想マシン）、Azure Storage を含むデータベース、Azure Kubernetes Service（AKS）などの監視が可能です。

ログ監視

さまざまなハードウェア（サーバ、ネットワーク機器、ストレージ等）、ソフトウェア（OS、アプリケーション等）のログを監視できます。機械学習アルゴリズムを用いれば、収集したログの分析や問題の検知も可能です。

リソース監視

サーバーのCPU使用率やメモリ使用率、ディスク空き容量やネットワーク帯域といったリソース使用量を監視できます。

アラート機能

監視対象より異常が発見された際に、アラートを発行することができます。

監視対象にエージェントをインストールするタイプの監視サービスなので、Azureだけでなく、他のクラウドやオンプレミスに対して、これらの監視を実現することができます。

AzureサブスクリプションやAzure ADの監視も可能であるため、Azureクラウドを利用する際は、監視ツールとしてAzure Monitorを利用するのがお勧めです。

クラウドプロバイダ以外が提供する監視ツール

パブリッククラウドを利用しない場合や、パブリッククラウドを利用する環境でもクラウドプロバイダが提供するツールのみでは監視要件を実現できそうにない場合は、クラウドプロバイダ以外が提供する監視ツールの導入を検討します。

Zabbix

Zabbixは、オープンソースの統合監視ツールとしてよく知られており、この製品ひとつでサーバ、ネットワーク、アプリケーションなどシステムを幅広く監視できます。

複雑なカスタマイズが可能であることが魅力であり、これは複雑な監視要件を実現できるということでもあります。しかし、”複雑なカスタマイズが可能”＝”監視における設計や構築、運用に高いスキルが求められる”という側面もあり、上級者向きのソフトウェアです。

また、オープンソースソフトウェアであることも Zabbix が持つ特徴の1つです。オープンソースソフトウェアのためライセンス費用が不要となり、監視運用に掛かるコストを大幅に抑えられる可能性を秘めています。

この他にも、製品として長い歴史があり、日本国内での利用例も多く、豊富なドキュメントやナレッジ情報を日本語で参照することができるのも良い点です。有料で厚いサポートサービスを受けることも可能ですし、セキュリティパッチ等のモジュールリリースもしっかり行われているため、長期にわたって安心して運用を継続できる点も魅力でしょう。LinuxをOSとするマシンが含まれるシステムとは、特に相性が良いです。

オンプレミス環境をクラウド化する流れは確実に進んでいますが、例えば、既に複雑な仕組みで運用されているオンプレミス環境をクラウドへ移行するのは大変困難です。このようなケースの場合、AWSサービスと連携できる且つ複雑なカスタマイズが可能なサードパーティ製品は重宝され、そのなかでもZabbixは人気があります。

▼参考リンク
Zabbix公式サイト
https://www.zabbix.com/jp

Mackerel

国内企業である「株式会社はてな」が提供する、SaaS型の監視ツールです。シンプルな作りで他の監視ツールと比べて複雑な操作を要求されないため、開発担当者と運用担当者どちらの立場でも使い易いのが特徴です。SaaS製品のため、Mackerelが動作するインフラ基盤については、ユーザ側で責任を持つ必要もありません。

導入方法は実に簡単で、エージェントソフトウェアを監視対象のサーバにインストールするだけで、管理コンソールから統合監視を開始することができます。エージェント型の監視ツールであるため、マルチクラウドのシステム監視にも対応可能です。
Mackerelが提供する「AWSインテグレーション」、「Azureインテグレーション」を利用することで、AWS製品やAzure製品をMackerelのホストとして管理、監視することができます。また、Google Cloud にも対応しており、「Google Cloud インテグレーション」を利用して Google Cloud と連携することもできます。

▼参考リンク
Mackerel公式サイト
https://ja.mackerel.io/

まとめ

今回はクラウド監視におけるお薦め監視ツールを紹介してみましたが、いかがでしたでしょうか。

実に様々な会社や組織がさまざまな監視ツールを世に提供しており、どの監視ツールを利用すればいいのか、選択肢の多さゆえに悩ましく感じることもあると思います。

しかし、まずは監視要件を基本とし、要件を実現できるかどうかを判断基準にして監視ツールの検討をすることで、ツールを誤って選択してしまう事態は回避できるでしょう。

監視要件を実現することができるかどうかを第一の基準とし、その次の基準で投入可能なコストをクリアしているかやクラウド構成との親和性といったステップを踏んでいくことをお薦めします。

また、パブリッククラウドを利用している場合は、親和性の観点から、そのパブリッククラウドが提供する監視サービスを利用することを勧めます。パブリッククラウドのみで実現不可能な要件や、システムを置く環境特有の条件がある場合は、クラウドプロバイダ以外が提供する監視ツールの導入を検討する必要があるかもしれません。

システムによっては特別に考慮しなければならない条件や制約を抱えている場合もあるかもしれませんが、何よりも監視要件が実現できるかを優先し、実現可能な範囲の中で最適な監視ツールを選択しましょう。