フェイス・ソリューション・テクノロジーズ株式会社IS本部OSユニットのmiyagiです。
今回はCloudWatchについて業務で触れる機会があったため、調べてみました！
はじめに
CloudWatchとは？
AWSが提供するフルマネージド型の運用監視サービスで、AWS上のリソースやアプリケーションをリアルタイムで監視することができます。
具体的には、CPU使用率などのメトリクスや、アプリケーションのログ、イベント情報などを収集して、システム全体のパフォーマンスを可視化し、問題を早期に発見・対応するためのサービスです。
フルマネージドであるため、インフラの構築や保守運用コストを抑えながら、高度な監視機能をすぐに利用できます。
参考サイト
CloudWatchの主要機能
CloudWatchの主要な機能は大きく4つです。
メトリクス監視
AWSリソースの性能指標を収集・追跡できるのが魅力です。たとえばEC2のCPU使用率や、RDSの接続数などが標準で取得できます。また、カスタムメトリクスを使うと、独自のアプリケーション指標（たとえばリクエスト数やエラー数など）もモニタリングできます。
さらに、最大15か月間のデータ保管期間があり、過去のトレンドと比較して異常値を検知するのに役立ちます。グラフ化や統計分析ができるので、ピーク時のパフォーマンスやリソースのボトルネックを把握しやすいのがメリットですね。
ログ分析
CloudWatch Logsを利用すると、EC2インスタンスやLambda関数などからのログを収集できます。収集したログをリアルタイムで分析したり、長期的に保存して後から検索することも可能です。
例えば、アプリケーションのエラーログを集約して、特定のエラーがどのくらい発生しているかを調べたり、システム全体の動きを可視化することができます。
また、CloudWatch Logs Insightsという機能を使えば、クエリベースで高速にログを検索・分析できますので、大量のログからでも必要な情報をすぐ抽出できる点が魅力です。
アラーム設定
CloudWatchでは、集めたメトリクスの値がしきい値を超えたらSNSを通じて通知したり、Auto Scalingなどの自動アクションをトリガーすることが可能です。
たとえば、EC2インスタンスのCPU使用率が80%を超えたらメールを送る、という設定が簡単にできます。
さらに最近は複合アラームもサポートされており、複数のメトリクスを組み合わせて、より精度の高い監視が可能になっています。
アラーム機能を活用することで、運用者が常にダッシュボードを見張っていなくても、問題が起きたときに自動で通知してくれるため、運用コストの大幅削減が期待できます。
ダッシュボード作成
CloudWatchでは、監視したいメトリクスやログ情報をまとめて一つの画面に表示できます。
複数のグラフを並べることで、システムの状態を俯瞰して把握しやすくなります。
これにより、運用担当者が1つの画面を見ればシステム全体の稼働状況がわかるので、迅速な意思決定やトラブルシューティングに役立ちます。
CloudWatchを利用するメリット・デメリット
CloudWatchを利用するメリット
リアルタイムモニタリングと長期トレンド分析
リアルタイムモニタリングが可能で、かつ長期トレンド分析にも対応しているので、瞬間的な異常から傾向的な問題まで把握できます。
運用の自動化及びコストの最適化
アラーム設定やAuto Scalingとの連携によって、運用を自動化しやすい点もメリットです。
また、リソース使用状況の把握を通じて、コスト最適化のアイデアを得られるのも大きいです。
トラブルシューティングの効率化・セキュリティの強化
ログ分析やアプリケーションのトラブルシューティング機能を活用することで、障害発生時の調査時間が短縮されるほか、セキュリティ面でも活用できます。
CloudWatchを利用するデメリット
メトリクスの保管期間に制限がある(1時間ごとのデータポイントは約15カ月)
メトリクスの保管期間に制限がある点です。例えば1時間ごとのデータポイントは約15カ月保持など、データの粒度によって制限が異なります。
単体でのアラート一時停止機能の制限
単体でのアラート一時停止機能が限定的で、たとえばメンテナンス中にアラームを止めるときは工夫が必要です。
高度な分析には他のサービスとの連携が必要なケースも
高度な分析を行うには、Athena や Elasticsearch など、他のサービスとの連携が必要になるケースもあります。
料金体系
メトリクス
基本メトリクス(初めから用意されてるもの)
・基本モニタリング(5分間隔)は無料
・詳細モニタリング(1分間隔)は10個まで無料
カスタムメトリクス(自分で作成するもの)
・10,000メトリクスまで：0.3ドル/個
・次の240,000メトリクス：0.1ドル/個
・次の750,000メトリクス：0.05ドル/個
・1,000,000を超えるメトリクス：0.02ドル/個
ログ
5GBまで無料
収集 (データインジェスト)
・スタンダード USD 0.76/GB
・低頻度アクセス USD 0.38/GB
保存 (アーカイブ)
・USD 0.033/圧縮された GB (圧縮されていない各バイトについて 0.15 の圧縮率)
クエリ (Logs Insights)
・USD 0.12/スキャンされたデータの GB
検出およびマスキング (データ保護)
・USD 0.12/スキャンされたデータの GB
分析 (Live Tail)
・0.01 USD/分
アラーム
10 アラームメトリクスまで無料 (メトリクスを直接リストアップし、Metrics Insights クエリを使用しない標準解像度アラームにのみ適用されます)
標準解像度
・直接表示されるメトリクスの料金 (/アラーム/月) USD 0.10/アラームメトリクス
・Metrics Insights クエリの料金 (/アラーム/月) USD 0.10/分析されたメトリクス
高解像度メトリクスアラーム
・直接表示されるメトリクスの料金 (/アラーム/月) USD 0.30/アラームメトリクス
複合アラーム
・複合アラーム USD 0.50/複合アラーム
ダッシュボード
1 か月あたり最大 50 メトリクスを参照する 3 つのカスタムダッシュボード。さらに、すべての自動ダッシュボードは無料
ダッシュボードの費用は、カスタムダッシュボードが存在する最初の 1 時間から時間単位で発生します。以下のダッシュボードの月額料金は、1 ヵ月間の使用料金を示していますが、1 ヵ月間のカスタムダッシュボードが存在する時間数に基づいて按分されます。さらに、カスタムダッシュボードを共有すると、共有バージョンのダッシュボードをレンダリングするために使用される GetMetricData API 呼び出しに対して課金されます。元のダッシュボードをレンダリングするための GetMetricData API 呼び出しには課金されないことに注意してください。ダッシュボードソース内の LAMBDA Metric Math 関数への参照は毎回 1 つのメトリクスとしてカウントされます。
ダッシュボード USD 3.00/ダッシュボード/月
コスト最適化のヒント
以上の料金体系を踏まえて、不要な項目は定期的に削除・アーカイブし、ログの肥大化を防ぎましょう。
また、ログの保持期間を短めに設定して、必要な期間だけをCloudWatch Logsに保存し、それ以降はS3などに移動して安価に保管する方法もあります。
カスタムメトリクスやアラームは、本当に必要なものに絞ることが大事です。
ダッシュボードも使わないものは削除し、1つのダッシュボードにまとめるなど、運用ルールを決めておくと良さそうです。
他のAWSサービスとの連携
AWS CloudTrail
AWS CloudTrailは、AWSアカウント内でのAPIコール履歴を記録するサービスです。
これによって、誰がいつどの操作を行ったかがわかり、セキュリティやコンプライアンス面で重要です。
CloudWatchと連携することで、特定のAPIコールをトリガーにアラームを発火させたり、ログ分析で不正アクセスを検知するなどの使い方が可能です。
CloudTrailとCloudWatchの連携がセキュリティをより強固なものにしてくれます。
AWS Config
AWSリソースの構成変更を追跡・記録するサービスです。
例えば、セキュリティグループのルールが変更されたり、EC2インスタンスのタグが変わった場合などを監視できます。
CloudWatchと連携すれば、Configルールに違反した変更が検出されたタイミングでアラームを出したり設定した自動修復アクションを行い自動修復することも可能です。
こうした仕組みを使うことで、セキュリティの一貫性やコンプライアンス要件を満たしやすくなります。
おわりに
今回はCloudWatchについてまとめてみました。
知らないことばかりで、非常に勉強になりました。
今後はさらにレベルアップした記事が書けるよう日々勉強していければと思います。
コメント