ブログ

AWS運用でのシステム監視実現に向けて

AWSにて稼働するシステムを運用する場合には、運用設計と共に、監視方式の検討が必要となるかと思います。AWS上で稼働するシステム監視を実施する場合には、各AWSサービスの監視項目の検討や、AWSにて提供されるCloudWatch、各種監視製品など監視ツールの選択、アラート通知方式の検討が必要となります。本ブログでは、対象をEC2サービス、監視ツールをCloudWatchとしたケースでの監視方式検討プロセスをご紹介致します。

オンプレミス運用とAWS運用でのシステム監視の違い

従来のオンプレミス環境では、ハードウェア(サーバー、ネットワーク、ストレージ機器)、ソフトウェア(OS、ミドルウェア、アプリケーション)双方各項目の監視を検討する必要がありました。しかしクラウドサービスであるAWSではハードウェア管理がAWSの担当である為、ハードウェアの運用監視は必要がありません。IaaSサービスのEC2であれば一部仮想基盤の監視は必要ですが、利用者側ではOS以上の各監視項目を検討するのみとなります。

また、フルマネージドサービスであればハードウェアはもちろんの事、OS(サービスによってはミドルウェア含む)の監視を考慮する必要もありません。

EC2監視のAWS運用の検討事項

AWSの代表的なサービスであるEC2を例に具体的な監視項目を検討をしてみます。

EC2はIaaSサービスである為、OS、ミドルウェア、アプリケーション層での監視については、オンプレミスサーバー、仮想基盤上で稼働するゲストOSと大きくは変わりません。主に検討される監視項目については以下に記載します。

  • 性能・キャパシティ監視
    • CPU
    • メモリ
    • ディスク
    • ネットワーク
  • プロセス(サービス)監視
    • OS
    • 各アプリケーション
  • ログ監視
    • OS
    • 各アプリケーション

上記以外にサーバーの稼働を監視する場合には通常、生死監視も検討されると思います。EC2の場合、ハードウェアはAWSの管理となる為、オンプレミスのサーバーの様に、IPアドレスにICMPポーリングを実施する方法とは違い、AWSにてEC2の状態を把握する機能があります。稼働状況の監視には2つの項目があり、EC2の稼働状態は「状態」で把握し、EC2が稼働している基盤上の状態は、「ステータスチェック」にて稼働状況を把握します。「状態」の種類、「ステータスチェック」の種類とチェック失敗となる事例について以下に記載します。

  • 状態
    • pending:起動中
    • running:実行(使用可能)
    • stopping:停止中
    • stopped:停止
    • shutting-down:削除準備中
    • terminated:削除済
  • ステータスチェック
    • システムステータス:EC2が実行されているAWSシステム(基盤)を監視します。
    • ネットワーク接続の喪失
    • システム電源の喪失
    • 物理ホストのソフトウェアの問題
    • ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題
  • インスタンスステータス:EC2のソフトウェアとネットワークの設定を監視します。
    • 失敗したシステムステータスチェック
    • 正しくないネットワークまたは起動設定
    • メモリの枯渇
    • 破損したファイルシステム
    • 互換性のないカーネル

AWS監視サービスCloudWatchとは?

CloudWatchは、AWSの各種サービスを監視するフルマネージドサービスであり、AWSでの運用を検討する場合には欠かせないサービスとなります。フルマネージドサービスである為、従来の監視システムの様に監視サーバーのセットアップ、運用も必要が無く、Pushモデルを採用している為、AWS上で起動されたサービスは自動的に監視対象となり情報収集が開始される事も大きな利点となります。また、各種AWSサービスと連携することにより、運用自動化も可能となります。EC2をCloudWatchで監視する場合は2点注意が必要となります。1点目は、メトリックには標準メトリックと拡張メトリックがあり、拡張メトリックを収集する場合は、CloudWatch Agentの導入が必要となります。2点目は、EC2でOS、アプリケーションのログを収集する場合、CloudWatch Logs Agentの導入が必要となります。

CloudWatchには大きく分類すると3つの機能があり、各機能の分類と機能概要について以下に記載します。また、CloudWatchにて状態遷移、閾値以上、ログフィルタにて発生したアラートはCloudWatch Alarmという機能を使用してアラート通知を実施します。

  • CloudWatch(システムリソース監視サービス)
    • AWSサービスの各種メトリック収集、監視
    • 各種メトリックグラフのコンソール表示機能
    • 各種メトリック閾値を利用したアラート通知機能
  • CloudWatch Logs(ログ管理サービス)
    • AWSサービスの各種ログ収集、保存
    • ログフィルタを利用したアラート通知機能
    • S3へのエクスポート機能
  • CloudWatch Events(イベントを起点としたアクション実行サービス)
    • 各種AWSサービスのイベントを起点としたアクション実行機能
    • スケジュールを起点としたアクション実行機能

AWS運用 AWSサービスを利用したアラート通知

AWS運用における各種サービスでのアラート通知ですが、こちらも要件としてはオンプレミスでの運用と大きく変わること無く、メール送信、インシデント管理ツール、チャットツール等のSaaSサービスへの通知・登録、アラートをトリガーとしたプログラム実行も検討される事が多いと思います。AWSでの監視を実現する為に、CloudWatchが準備されていたように、CloudWatchで検知したアラートを通知する場合にもAmazon SNSというフルマネージドのメッセージ通知サービスを利用します。AWS監視運用時のAmazon SNSの主な利用用途としては、CloudWatchから通知されたアラートを基にメール送信、AWS Lambda(サーバーレスのプログラム実行サービス)を利用したプログラム実行、HTTP/Sプロトコルを利用したSaaSサービスへの通知があります。

EC2監視の設計例

これまでご説明した内容を基に、AWS監視運用での標準的な構成をEC2運用時を例にして記載します。

  • 監視構成
    • 監視対象:EC2
    • 生死(状態)監視:CloudWatch
    • リソース監視:CloudWatch(Agent)
    • プロセス監視:CloudWatch(Agent)
    • ログファイル監視:CloudWatch Logs
    • アラート通知:メール、チャットツール(SaaS)

AWS運用でのシステム監視実現に向けて まとめ 

このようなAWS運用監視サービスをご紹介してきましたが、いかがでしたでしょうか?運用設計と共に監視方式の検討が重要なことがご理解いただけたと思います。皆さんの現場にのAWS運用監視に合ったサービスをご検討ください。

元記事発行日: 2020年07月31日、最終更新日: 2020年11月18日

Related Articles