CloudWatch

介護要因系アラフィフ未経験転職者２年生の…「いとあたらし」です。

当初は慣れない操作等に苦労しましたが、周りの方には面倒見のいい方が多く、いろいろな経験を積むことができ、かなり慣れる事ができました。

業務中の空き時間には自己学習も可能な環境ですので、PCの操作や学習が好きで、パソコンの操作や処理の待ち時間が苦にならない人には、非常にいい職場だと思います。

インフラ設計における5つの観点

1.可用性：サービスにおける利用継続性

2.性能拡張性：用途を満たす性能であり、将来必要な性能への拡張性を備えているか

3.運用保守性：適切な運用保守対応が可能か

4.セキュリティ：情報の安全性が担保されているか

5.移行性：現行システムから他のシステムへの移行がしやすいか

CloudWatchは上記における３番目の運用保守性の観点において、

運用自体や運用時間の監視やメンテナンス、バックアップ等を視覚化する機能です。

システム監視をする事により、障害発生の即応性の確保を可能にします。

→異常を検知した際に、すぐに確認し、復旧に取り掛かれるようにします。

①    正常な状態を定義(監視項目、どの状態が正常か？)

②    正常な状態で無い場合を監視

③    正常な状態であることを確認

④    ②を監視した場合に通知し、正常な状態への復旧を促します。

ざっくり言うとCloudWatchはシステムのモニタリングに特化した運用管理ツールです。

→ログ解析とモニタリングをし、それらを集約化することができます。

→運用状況を確認し、閾値を超えた場合は、トラブルシューティングを実施するための自動アクションが実行可能です。

CloudWatchの代表的な用途とは

→AWSの監視やモニタリングを実現するためのサービスです。

①    AWSのリソースの状態(メトリクス)を監視できます。

②    メトリクスにおける閾値を設定し、条件を満たせばアラームを発報することが可能です。

AmazonSNSという通知サービスを使用して発報をさせます。

→トピック作成、パブリッシャーがメッセージ送信、サブスクライバーが通知を受信するための通信チャネルとして介在します。

CloudWatchを使用する際の大まかな流れの全体像です

データリソース：EC2(CloudWatchエージェント)

↓→CloudWatchLogs→CloudWatchLogs Insights(クエリによって可視化したグラフ等のログ分析結果の取得がダッシュボードにて可能です。)

↓　

→CloudWatchメトリクス →CloudWatchダッシュボードもしくはCloudWatchアラーム

　　↓　　　　　　　　　   

　　Lambda関数等を実行させて、簡単なアプリケーションの実行をさせます。

CloudWatchの詳細な機能について

ざっくり言うと…AWSのリソースや実行しているアプリケーションについてのモニタリングを実現するもので、様々なメトリクスやログの取得が可能です。

1.CloudWatchアラーム：CloudWatchメトリクスに基づいた数式の結果の監視のためのメトリクスアラームの通知や自動アクションの設定をすることが可能です。

→AmazonSNSのメール通知機能を設定することにより、担当者へのメール通知が可能となります。

→単純なアラームから複数のアラームを掛け合わせた複合アラームとしての監視設定も可能です。

→メトリクス：リージョン毎のメトリクス取得を、時系列のデータポイントで設定します。

→名前空間：CloudWatchメトリクスのコンテナを示します。名前空間の異なるメトリクスは相互に分離されます。(名前空間によってメトリクスの領域を分ける事が可能です。)

→ディメンジョン：メトリクスを識別できる名前と値のペアを示します。

→正常値、OK：定義された閾値に入っている状態です。

→異常値、ALARM：定義された閾値を超過した状態です。

→判定不能、INSUFFICENT_DATA：データ不足の為判定ができない状態です。

2.CloudWatchメトリクス：EC2を初めとするAWSリソースを監視できるサービスです。

→死活監視、性能監視、キャパシティ等の監視を実施します。

→標準メトリクス：CPUUtilization、ディスク利用率、読み取りIOPS(１秒当たり可能な回数)など、一般的なメトリクスの多くが無料で予め備わった機能として取得させる事が可能です。(取得間隔は5秒間隔)

→カスタムメトリクス：有料枠を実行する場合のみ設定が可能です。

　高解像度で１秒から60秒間隔でのメトリクス取得が可能となります。

　メモリの利用率は標準メトリクスの設定ができなくなっていますので、カスタムメトリクスでの設定が必要となります。

3.CloudWatchLogs：CloudWatchと連動するログを収集し、可視化や分析をさせる事に対応した機能です。

→EC2インスタンス上のOS等の内部のアプリケーションログやRDS等のデータベースの実行ログやフローログ等のトラフィック関連のログ取得をさせる事が可能です。

→ログデータは、1日から永久にて保存期間の設定が可能です。

→CloudWatchLogsを構成する3つのレイヤー構成：ロググループ(設定を共有するグループ)＞ログストリーム(タイムスタンプ順にて複数のログイベントで構成)＞ログイベント(イベント発生時のタイムスタンプとイベントメッセージで生成)

4.CloudWatchEvents(現在では統合されたAmazon Event Bridgeにて実行できるそうです)：AWSリソースに対するイベントがトリガーとなり、メッセージを送ったり、Lambda関数を実行させて簡単なアプリケーション機能を実行させる等のアクションを実行させます。

CloudWatchを使用した一般的な監視の種類について

・死活監視

→システムの動作が正常な状態か？

・メトリクス(AWSの状態を定期的に取得する状態のことです。)の監視

→定量的なパフォーマンス確認

→指標が閾値内であるかを確認する。

※監視項目は最低限からスタートし必要に応じて追加してゆくことが望ましいです。

→最初はあれこれ多数の設定はせずCPU、メモリ、ネットワーク、ストレージの使用率と枯渇状況くらいからスタートするのが望ましいと考えられます。

※AWS EC2は、デフォルトでCPU使用率やネットワーク使用率をモニタリングすることができますが、メモリ使用率はモニタリングできません。 そこで、CloudWatchを使用することでメモリ使用率やディスク使用率などもモニタリングできるようになります。

CloudWatchの拡張モニタリングを有効化した場合について

→OSメトリクスが50種類以上から選択できます。

→メトリクス取得は１秒から60秒間隔にての設定が可能となります。

→取得したメトリクスはCloudWatchLogsに保存されます。

→料金は、Amazon CloudWatchLogsの無料利用枠を超過した場合にのみ発生します。

→現在db.m1.small以外の全てのDBインスタンスでの有効化が可能となっています。

→APIのトラブル(スロットリング)発生時のサーバーダウンの対策がされています。

まとめ

CloudWatchとは

トリガー：AWS上リソースにおける変更等を指すシステムイベントの発生

ターゲット：ダッシュボードやログ表示、Lambda、Amazon SNS etcの様々なAWSサービスの実行が可能です。

トリガーとして、予め閾値等のルールを設定しておいた上で…ターゲットとして指定するイベント処理させるためのシステムモニタリングに特化した運用管理ツールです。