【AWS発表】CloudWatch Events – AWSリソースの変更を監視

AWS上で稼働するアプリケーションをみると、その時々で様々なことがおこっています。システムの負荷に応じAuto Scalingポリシーを利用しEC2を作成・削除させることもありますし、DynamoDBのテーブルやSNSトピック、SNSのキューが作成・削除されることもあります。既存のリソースに関しても、AWSマネジメントコンソース、AWS API、AWS Command Line Interface (CLI) から属性が変更されることもあると思います。

お客様の多くは、独自の高機能ツールを開発しAWS環境の全体状況をトラッキング、監視し運用をしています。そしてこういったツールは今のところポーリング形式で稼働しています。言い換えると、定期的にDescribeInstances、DescribeVolumes、およびListQueues（ここではEC2インスタンス、EBSボリューム、およびSQSキュー）といったAWS関数を呼び出すことで様々な種類のAWSリソースをリスト表示し状態をトラッキングしていました。リストを取得し、別のAPIを呼ぶことで追加情報を取得し、過去のデータと比較することで変更を検知しアクションをとる必要がありました。そのためシステムがより大きく、より複雑に成長するに従い、ポーリングと状態管理が面倒になりがちでした。

新機能 CloudWatch Events

AWSリソースの状態変更をより簡単にかつ効率的に管理できるよう、本日CloudWatch Eventをリリースしました。 CloudWatch EventはAWSリソースの変更情報をタイムリーにストリーム伝達します。簡単なルールでしたら数分で簡単に作成でき、幾つかのターゲットに対しファンクションと取ることが可能になります。(AWS Lambda、Amazon Kinesis Stream、Amazon SNS, Bullet-in ターゲット連携することができます)。

CloudWatch Eventは、AWS環境においては中枢神経系のようなものだとお考え下さい。隅から隅まで環境の変更を検知するよう繋がっています。ルールに従いファンクションを実行することで、状態確認し是正処置をとるためにメッセージを送ります。

本日のリリースでは代表的なAWSサービスに対応する形でのリリースになりますが、残りのサービスも来年一年をかけ対応してく予定です。

 CloudWatch Eventsの利用

CloudWatch Eventsを利用するにあたり、イベント、ターゲット、ルールの３つのコンポーネントについて理解しておく必要があります。

イベント(JSONで返されるblob)は４つの方法で作成されます。まず１つ目としてAWS環境において状態が変更した時に作成されます。例えばEC2のステータスがPendingからrunningに変更したときであったり、AutoScalingによりEC2が作成された時などです。２つ目はAPIによりコールされるイベント、サインイン イベントはCloudTrialを経由しCloudWatch Eventに配信されます。３つ目として、独自コードがアプリケーションレベルのイベントを作成しCloudWatch Eventへの配信が挙げられます。そして４つ目としてスケジュールベースに一定間隔でクーロンのような形でのイベント作成も可能です。

そして作成されたイベントとルールがマッチする場合、ターゲットに対し処理が実行されます。またルールの適用に特に決まった順番があるわけでもありません。イベントに合致したすべてのルールが適用されます（そうすることで独立してイベントをプロセッシングします）。

ルールで設定されたイベント処理がターゲットに渡されます。４つのターゲットタイプを準備しています。Built-in、Lambdaファンクション、Kinesis StreamとSNSトピックが対応となりますが、その他のターゲットも計画中です。一つのルールで複数のターゲットを設定することも可能です。すべてのイベントはJSON形式でターゲットに渡され、ターゲットに渡すJSONを加工することも可能です。イベントをそのまま渡すことも可能ですし、特定のKey（紐づくValue値も一緒）を渡したり、文字列を渡すことも可能です。

CloudWatch Eventsのアクション

早速幾つかルールを作成してみましょう。SomethingHappenedというLambda関数を利用します。これはイベント内容を残します。

そしてCloudWatch Eventsのコンソールに移り、"Create Rule" からイベントソースを選択します（選択肢がメニューとして表示されます）。

つぎに進む前に少し補足です。いくつかのAWSサービスはイベントが直接作成され、それらはトップメニューに表示されます。その他にもCloudTrailのログをベースに作成されるものもあるためサービスによってはCoudTrailを有効にする必要があります。

"EC2 Instances" を選択し、トリガーさせる状態遷移を選択しルールを作成します。

新たに作成されるインスタンスが "running" になるのを監視します。リージョン内のインスタンス全体にも適用できますし、特定のインスタンスにも適用できます。下記が今回の設定になります。

そして何をするかを設定します。今回はターゲットを選択します。下記のようになります。

Lambdaを選択し、Lambdaファンクションを選択します。

もうちょっとで終わります。ルールに名前とコメントを残しレビューを行います。

 

"Create Role" をクリックし、これで準備は完了です。

EC2インスタンスを起動し、テストをしてみます。実際にはコードを確認するために5台のインスタンスを起動しました。数分後インスタンスが起動し初期化され、その後Lambda ファンクションが実行されていることを確認できます。

うまく動いているようです（一つ前の山は事前に行ったテストによるものです）。CloudWatch Logsからファンクションのログを確認できます。

ご覧の通りイベントには新しく作成されたインスタンスに関する基本情報が含まれます。AWSファンクションをコールするようにコーディングすることで何が起きているかを確認することもできます。例えばDescribeInstancesをコールすることで新たに作成されたインスタンスの情報を取得できます。

実際にはファンクションにはより多くの設定を入れると思います。必ずタグを入れるようにしたり、動的に可視化の変更を行ったり、SNS経由でメールを送るかもしれません。もちろんこういったことを実装されたい場合は事前にIAMの設定が必要になります。その他の状態遷移を監視したい場合はルールをもう少し汎用的なものにするといいでしょう。

ルール実行のスケジュール化

定期的、もしくは一定間隔でクーロン設定によりルールを実行することもできます。以下の様にになります。

API アクセス

 大抵のAWSサービスと同様にCloudWatch EventにはAPI経由でアクセスすることも可能です。下記代表的なファンクションになります。

• PutRuleはルールを作成し、PutTargetでターゲットを作成できます
• PutTargets、RemoveTargetsでルールとターゲットの紐付け、解消ができます
• ListRules、ListTargetsByRule、DescribeRuleで既存のルールを表示できます
• PutEventsで CloudWatch Events にイベント送信します。アプリケーションレベルのイベントを送りたい場合はこのファンクション（またはCLI）を利用します。

イベントのメトリックス

CloudWatchからのメトリックに CloudWatch Event も対応しており、AWS/Events名前空間が準備されています。ルールが想定通りに動いているかをこれらメトリックを使い確認することができ、全体的にルールのアクティビティを確認することができます。以下は全体メトリックとして確認頂けます。

• Invocations - ターゲットが実行された回数
• FailedInvocations - ターゲットの実行が失敗した回数
• MatchedEvents - ルールにマッチした回数
• TriggeredRules - トリガーされた回数

以下はルール毎に確認できます。

• Invocations - あるルールのターゲットが実行された回数
• TriggeredRules - あるルールがトリガーされた回数

多くのAWSサービスと同等に今回の初期リリースでは代表的なサービス（インフラ）に対応し、CloudFormation対応含め大きな計画があります。皆さんのフィードバックを基に対応しますが、最終的にはAWSすべてのサービスにまで広げられればと考えています。継続し準備を進め、ご報告できればと考えています。

始めてみましょう

CloudWatch Eventは、US East (バージニア)、US West (オレゴン)、Europe (アイルランド)、Asia Pacific (東京)で利用可能です。是非お使いください。

- Jeff（翻訳はParter SA酒徳が対応しました。本文はこちら：https://aws.amazon.com/blogs/aws/new-cloudwatch-events-track-and-respond-to-changes-to-your-aws-resources/ ）