【AWS】SAA資格取得のための学習用備忘録(運用支援サービス)

AWSにおける運用支援サービス

システムは作って終わりではない。

むしろ、世の中に公開してからが本番。

システム運用を安定的に行えるか、その上で利用者の声を聞き日々機能を改善していけるかなど、運用フェーズに入ってからが重要。

この運用フェーズを支援するサービスもAWSには存在する。

代表的なサービスは以下の2つ。

・Amazon CloudWatch

・AWS CloudTrail

CloudWatchは、定期的にAWSリソースの状態を取得し、問題がある場合はそれを運用者に通知するサービス。

何を「問題がある」とするかは、利用者側で定義することができる。

また、ミドルウェアやアプリケーションのログを監視する機能や、独自にトリガーを定義し、そのトリガーが発生したら後続の処理を行う機能も提供されている。

運用のための機能は非常に重要。

しかし、ビジネスの差別化繋がるものではないため、できれば工数をかけたくないという声もよく聞く。

AWSの提供するこれらのマネージドな運用サービスを使うことで、ものジレンマを解消することができる。

ソリューションアーキテクトとして、「システムが動く」だけでなく「安定的に動く」設計をするために、運用サービスについて理解を深める。

CloudWatch

CloudWatchは、運用監視を支援するマネージドサービス。

システムのリリース後、安定した運用をすることで利用者の満足度を上げていくことが非常に重要で、運用がうまくいっていないと新しい機能開発に工数を割くことができない。

この安定運用のサポートをするのがCloudWatch。

CloudWatchには、中核となる3つの機能と、比較的最近追加された4つの機能がある。

・CloudWatch

・CloudWatch Logs

・CloudWatch Events

・CloudWatch Synthetics

・CloudWatch ServiceLens

・Container Insight

・Contributor Insights

CloudWatch

メイン機能のCloudWatchは各AWSリソースの状態を定期的に取得する。

この状態のことをメトリクスと呼ぶ。

例えば、EC2インスタンスのCPU使用率であったり、Lambda関数ごとのエラー回数などが定義されている。

このような、AWSがあらかじめ定義しているメトリクスを標準メトリクスと呼ぶ。

一方、利用者が定義した値をCloudWatchに渡すことで、独自のメトリクスを作ることもできる。

このようなメトリクスをカスタムメトリクスと呼ぶ。

CloudWatchでは、これらのメトリクスを選択し、アラームを定義することができる。

例えば、次のような条件でアラームを設定する。

・Webサーバー用のEC2インスタンスのCPU使用率が80%を上回った時

・定期実行するLambda関数が一定期間に3回以上エラーを出した時

このアラームの条件を満たした時に別サービスのSNSに通知するように設定することができる。

SNSは通知を受けてメールを飛ばしたり、Lambda関数を呼び出したりできる。

これらの機能を組み合わせて、CPU利用率が高い状態を検知して運用担当者にメールを送ったり、呼び出されたLambdaからAWSリソースの設定を変更したりできる。

CloudWatch Logs

CloudWatch Logsは、アプリケーションログやApacheログなどのログをモニタリングするサービス。

CloudWatch Logsを利用するには、独自のエージェントをインストールする必要がある。

このエージェントを介して、各EC2インスタンスのログをCloudWatch Logsに収集する。

この時、送信元のインスタンスにCloudWatchのIAM権限を付与する必要があるため、IAMロールで設定する。

CloudWatch Logsでは、収集したログに対してアラームを設定することができる。

例えば、アプリケーションログに「[ERROR]」から始まる行があった時、あるいは「[WARN]」から始まる行が一定時間に3行以上あった時、というような閾値でアラームを設定できる。

CloudWatchと同様に、このアラームをトリガーにして何かしらの処理を行える。

CloudWatch Logsを使うことでアプリケーションレイヤーの監視もでき、システムをより安定して運用することが可能になる。

CloudWatch Events

CloudWatch Eventsは、独自のトリガーと何かしらの後続アクションを定義するサービス。

独自のトリガーをイベントソースと呼び、後続アクションをターゲットと呼ぶ。

CloudWatch Eventsを使うことで、AWSの各サービスをシームレスに連携することができる。

イベントソースには大きく2つの種類がある。

1つはスケジュールで、もう1つは各AWSリソースのイベント。

スケジュールは「3時間おきに」「金曜日の朝7時に」といった期間・時間ベースのトリガー定義。

後者のAWSリソースのイベントは、「Auto Scalingがインスタンスを増減させたら」「Code Buildの状態が変わったら」といった、AWSリソースの状態変化をトリガーにする。

ターゲットには既存のAWSリソースに対するアクションを定義する。

「Lambda関数をキックする」「CodePipelineを実行する」といったアクションを設定できる。

1つのイベントソースに対して複数のターゲットを定義することもできる。

また、後からターゲットを追加することもでき、より疎結合な形でサービス感連携を実現できる。

なお、CloudWatch Eventsと同じAPIを使い、機能が追加されたEventBridgeが登場している。

将来的にCloudWatch EventsはEventBridgeに統合予定。

このように、CloudWatchには様々な機能がある。

システムがまずい状態であることを通知するのみならず、それに対するアクションまで定義できるのがCloudWatchの良いところ。

リリース後、何もトラブルが起きないサービスはまずない。

CloudWatchを用いて、トラブルが起きた時に自動的に復旧する、あるいは不具合を最小限に留めるようなフォールトトレラントな設定ができるようにしていく。

★CloudWatchのメイン機能は、AWSリソースの状態(メトリクス)を定期的に取得すること

★CloudWatch Logsは、アプリケーションログやApacheログなどのログをモニタリングするサービス

★CloudWatch Eventsは、独自のトリガー(イベントソース)と何かしらの後続アクション(ターゲット)との組み合わせを定義するサービス

CloudTrail

CloudTrailは、AWSに関する操作ログを自動的に取得するサービス。

AWSではマネジメントコンソールの操作やCLIやSDKを用いたAPIによる操作によって、AWSリソースを操作したり、AWSリソースからデータを取得したりできる。

サービスを運用する中で、意図的かそうでないかは問わず、リソースを誤って消してしまったり、データを不正に持ち出してしまったりすることがある。

結果として、それが重大な障害やセキュリティインシデントに繋がる可能性があり、「誰が」「いつ」「どのような操作をしたか」といった監視ログを記録しておくことは非常に重要。

CloudTrailを利用すると、このような監査情報を簡単に取得できる。

CloudTrailで取得できるログの種類

CloudTrailで取得できる操作(イベント)には、管理イベントとデータイベントがある。

・管理イベント：マネジメントコンソールへのログイン、EC2インスタンスの作成、S3バケットの作成など

・データイベント：S3バケット上のデータ操作、Lambda関数の実行など

CloudTrailでは管理イベントの取得のみがデフォルトで有効になっており、過去90日分のログをマネジメントコンソール上で確認できる。

過去90日より前の情報も保持した場合は、S3に証跡を残すように　設定することもできる。

データイベントの取得は、デフォルトでは有効になっていないが、設定を変更することで、管理イベントと同様にS3にログを保管することができる。

★管理イベントの取得はデフォルトで有効。データイベントの取得はデフォルトで無効

CloudWatch Logsとの連携

CloudTrailで監査ログを取得することで、何か問題が発生した時に各ユーザーの操作を追跡することができる。

これだけでも十分に意味があるが、できればユーザーが不正な操作をしたことを自動的に検知したいところ。

そのような時に利用できるのが、CloudWatch Logsとの連携機能。

事前にキーワードを設定しておき、ログにその文字列が出てきたら通知する機能がCloudWatch Logs。

この機能を有効にすることで、事前に不正な操作(のログメッセージ/文字列)を登録しておき、ユーザーがそれに該当する行動をした時に検知することができる。

インシデントに繋がる操作を早期発見することができるため、非常に有用な機能。

★CloudTrailとCloudWatch Logsとを連携させることで、不正な操作を早期に発見できる

まとめ

運用支援サービス

・CloudWatchとCloudTrailは、システムを安定的に動かす上で重要な役割を果たす

・CloudWatchは、定期的にAWSリソースの状態を取得し、問題がある場合はそれを運用者に通知するサービス。取得された問題に応じて実行すべきアクションを定義することもできる

・CloudWatchのメイン機能は、AWSリソースの状態(メトリクス)を定期的に取得すること

・CloudWatch Logsは、アプリケーションログやApacheログなどのログをモニタリングするサービス

・CloudWatch Eventsは、独自のトリガー(イベントソース)と何かしらの後続アクション(ターゲット)との組み合わせを定義するサービス

・CloudTrailは、AWSリソースの作成やマネジメントコンソールへのログインなどの操作を記録するサービス。これによって、監査情報を簡単に取得できる

・CloudTrailとCloudWatch Logsとを連携させることで、不正な操作を早期に発見できる