MENU

クラウド環境のモニタリング ~オンプレミス時代とは異なる監視の手法と実装

 

クラウド時代のモニタリング

 業務でクラウドサービスを利用する企業の割合は年々増加しており、その利用形態もサーバーからクラウド上のサービスまで数多い。

 そうしたクラウド利用のメリットとして、システム資産や保守体制を自社で準備・保有する必要のないこと、どこでもサービスを利用できることなどが挙げられる一方で、セキュリティやコスト面、既存システムとの連携など、多くの懸念事項も指摘される。

 なかでもユーザーへのサービス提供という観点から見ると、クラウド障害は大きな脅威となり得る存在であり、クラウド環境をどのようにモニタリングするかはクラウドサービスの利用に際して避けられない課題である。

 これまでのようなオンプレミス環境では、ネットワーク、ハードウェア、ストレージ、仮想化基盤、OS、ミドルウェア、アプリケーションなどといったシステムを構成する全コンポーネントをユーザーが自前で用意し、システムのモニタリングをはじめとする運用管理もユーザー自ら行うのが一般的であった。

 しかしクラウド環境では、クラウド利用者が自身で管理できるコンポーネントには限りがある。図表1にIaaS、PaaS、SaaSのクラウドサービス提供形態ごとに、システムを構成するコンポーネントのどこまでをクラウドベンダーが提供するかを示した。

 このうち濃いグレーのボックスは、クラウドサービス提供者によって提供・管理される部分である。よってクラウド利用者が自身で管理できるのは、「クラウド利用者管理」で示した薄いグレーのボックス部分に限られる。

 一般に「クラウド障害」というと、たとえばクラウド環境上で何らかのトラブルが発生し、クラウドサービス全体がダウンしたなどの大規模な障害をイメージするかもしれない。

 しかし本稿で取り上げるのはそうした大規模なクラウド障害ではなく、図表1の薄いグレーの部分、すなわちクラウド環境上に存在する仮想サーバーやアプリケーションのインスタンスといった、クラウド利用者自身が管理しているコンポーネントで障害が発生した場合に備え、どのようにモニタリングすべきかを解説する。

 

 

クラウド環境では
サービス監視の優先度が高まる

 クラウド環境の大きな特徴の1つとして、環境の構築・リリース後も、環境が動的に変化し得るという点が挙げられる。これは多くのクラウド環境が、サービスへの負荷に応じてサーバーやアプリケーション・インスタンス(以下、インスタンス)の数を増減させる「オートスケーリング機能」や、サーバーやインスタンスに障害があった際に自動的に別のサーバーやインスタンスが立ち上がり、そちらへ業務を引き継ぐ「自動フェールオーバー機能」を備えることに起因する(オンプレミス環境でも別途、自動化ツールなどを用いればこうした機能を実現できるが、クラウド環境では複雑な作り込みや設定をせずに実装できる)。

 従来のオンプレミス環境監視ではアプリケーション、ミドルウェア、OSなどといったシステムを構成する個々のコンポーネントをそれぞれ監視することが主流であった。これはシステムを構成するコンポーネントのいずれかで万一障害が発生した場合に、それを速やかに検知し対応することで、障害による影響がシステムやサービス全体に波及するのを防ぐためである。

 しかしクラウド環境のようにオートスケーリング機能や自動フェールオーバー機能が備わっている場合、これまでのように個々のコンポーネントがダウンしているかを細かく監視する必要性は薄れ、代わりにユーザーにきちんとサービスが提供できているかを監視するサービス監視の重要性が相対的に高まると考えられる。

 またこうした機能に加え、クラウド・ネイティブ(当初からクラウド上での利用を前提として設計されたシステムおよびサービス)ではDevOpsモデルでの開発が主流となり、アプリケーションの開発・リリースが短期間のサイクルで頻繁に実施されるようになったことも、クラウド環境の動的な変化の大きな要因になっている。

 このようにその時々の状況に応じて増えたり減ったりするサーバーやインスタンスのすべてに対し、監視機能をはじめとした運用管理機能を1つ1つ手作業で適用するのは現実的ではない。そのため、管理対象に向け運用管理機能を自動的にリリースできるような仕組みを整える必要がある。

 

従来の監視はどう変化するか

 従来のオンプレミス環境で行われていた監視は、クラウド環境ではどのように変化していくのだろうか。一般的な監視項目について考えられる変化を図表2に示した。それぞれの項目について見ていこう。

 

(1)死活監視

 前述のようにサービス監視の優先度が高まることで、クラウド上に存在する個々のサーバーに対する死活監視の優先度は相対的に下がると考えられる。またその実装方法についても、別途構築した監視サーバーからpingによる死活監視を行う従来の方法ではなく、クラウド管理基盤からクラウド上の仮想サーバーを監視する方法への変化が見られる。

(2)プロセス監視

 死活監視と同様に、サービス監視の優先度の上昇に伴いプロセス監視の優先度も下がると考えられる。ただし、たとえば自動フェールオーバー機能を使用して「特定のプロセスがダウンしたら、インスタンスをフェールオーバーさせる」といったように実装するなど、引き続きプロセス監視が必要な場面もある。

(3)リソース監視

 クラウド環境でのリソース監視では、ただリソースの使用状況を取得して監視するだけでなく、収集したリソースの使用状況を予兆検知に活かすケースも増えると考えられる。

 予兆検知とは、障害が発生してからそれを検知してユーザーに通知する事後検知に対し、過去に蓄積されたデータから障害が起きる前の予兆となり得る事象を予測して検知し、実際に障害が起きる前の対応を可能とする技術を指す。

 これまでのオンプレミス環境でも、予兆検知をまったく実施していなかったわけではない。しかし、たとえ将来リソースが不足すると予測された場合でも、オンプレミス環境ではすぐにリソースを追加するといった対応は現実的ではなかった。これに対して、クラウド環境ではオンプレミス環境と比較すると、より柔軟に環境構築ができるため、異常の兆候が見られた場合、すぐに対応が可能となる。

 こうした環境の変化もあり、クラウド環境の監視では予兆検知の分野が注目を集めている。

(4)ネットワーク監視

 図表1で示したように、どのクラウドサービス提供形態でもネットワーク部分の管理は基本的にはクラウドサービス提供者の責任範囲となり、クラウド利用者側では管理できない。そのため、クラウド環境のネットワーク監視はクラウドサービス提供者側で実施されるのが主流である。

(5)ログ監視

 クラウド利用者からはクラウドサービス提供者が管理しているコンポーネントのログを確認できず、基本的には利用者が管理責任をもつ部分(図表1の薄いグレーのボックスで示された部分)のログを監視する。

 また近年ではアナリティクス技術の向上に伴い、今後はログ監視の分野でも監視だけでなく、ログ分析を実行する場面が増えると予想される。

 ファイアウォールなどのネットワーク機器、ソフトウェアやアプリケーションから出力されたログを使って、さまざまなセキュリティ脅威を分析・調査することでセキュリティ面の強化につなげたり、大量のログを分析することでインシデントや問題の解決状況を把握してサービス提供における改善点を見つけたり、ユーザーのサービス利用の動向から新たなビジネスチャンスの糸口を探ったりと、その用途も多岐に渡る。

 

クラウドのモニタリングを
どう実装するか

 クラウド環境上で監視システムを実装する方法としては、以下の2つが考えられる。

 1つ目は、クラウドベンダーが自社クラウド環境監視のために提供しているツール群を使用する場合。たとえば IBMのクラウド・プラットフォームであるIBM Cloudでは、サービス監視にはAvailability Monitoring(図表3)、アプリケーションの実行状況やリソースの監視にはIBM Cloud Monitoring(図表4)、ログ監視・ログ分析にはLog Analysisといったツールが用意されている(図表5)

 

 

 

図表4 IBM Cloud Monitoringの画面

 

 2つ目は、クラウドベンダー提供ツールを使用するのではなく、クラウド利用者が自前の監視サービスを利用する場合。このグループは、さらに2つに分けられる。別途用意したサーバーに監視製品を導入して監視システムを構築するケースと、SaaS形態で提供されている監視サービスを利用するケース、すなわちMonitoring as a Serviceの形をとる場合の2つである。

 それぞれの実装方法のメリットとデメリットについても確認しておこう。

 クラウドベンダー提供ツールを使用した場合、およびMonitoring as a Serviceを使用する場合は、自ら監視サーバーを用意したり、監視システムを構築・管理する手間が省けるといったメリットがある。その一方、自身で構築した監視システムと比較すると、カスタマイズできる範囲が限られるというデメリットがある。

 また、ベンダーやサービスによっては監視ツールが無償版と有償版に分かれており、無償版では一部の機能しか使えない、あるいは機能が制限されることもあるため注意が必要だ。

 一方、自前の監視サービスを構築して利用する場合、監視項目や設定をフルにカスタマイズできる。その一方で、監視システムをゼロから構築し、またその後の運用・保守作業も必要となるので、その分のコストや工数が発生する。

 各プロジェクトの監視要件を鑑みて、最適な方法を取るのがよいだろう。

 以上本稿では、クラウド環境の監視で新たに求められる要素、およびこれまでオンプレミス環境で行われてきた従来の監視方法の変化、そして監視の実装方法について述べた。

 本稿の内容が、今後クラウド環境の監視を考えている人、実装を担当される人の参考となれば幸いである。

・・・・・・・・

著者|星 みなみ氏

日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・イノベーション
ITスペシャリスト

2014年、日本IBM システムズ・エンジニアリング入社。以来、主にTivoli製品を軸とした監視系システム構築プロジェクトに参画し、設計・構築・技術支援に数多く携わっている。近年ではZabbixなどOSS監視系製品も担当している。

[IS magazine No.21(2018年9月)掲載]