CloudWatch EventsはAmazon EventBridgeになるらしい

-

まえおき

　最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。


グーグル翻訳先生に翻訳をお願いすると

CloudWatch Events is now Amazon EventBridge

Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications.

CloudWatch EventsがAmazon EventBridgeになりました

Amazon EventBridge（以前のCloudWatch Events）は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。

らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。(Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合)

 

Cloudwatch EventsとAmazon EventBridgeの違い

　全く同じサービスであるというと若干違うみたい。AWSのAmazon EventBridge のよくある質問をみると、

Q: Amazon EventBridge は CloudWatch Events とどのように関連していますか?
Amazon EventBridge は、CloudWatch Events をベースに構築された、CloudWatch Events を拡張するサービスです。Amazon EventBridge では、CloudWatch Events と同じサービス API とエンドポイント、同じ基盤となるサービスインフラストラクチャを使用します。これまで CloudWatch Events を使用しているお客様にとっては、何も変わることはありません。これまでと同じ API、CloudFormation テンプレート、コンソールを引き続き使用できます。お客様からの報告によれば、CloudWatch Events はイベント駆動型アーキテクチャを構築するための理想的なサービスです。そのため、AWS ではお客様が独自のアプリケーションとサードパーティーの SaaS アプリケーションからデータを接続できるようにする新しい機能を構築しました。AWS は、この機能を CloudWatch サービス内にとどめておくのではなく、Amazon EventBridge という新しい名前でリリースしました。この機能が、CloudWatch Events が開発された目的であるモニタリングユースケースを超えた拡張であることを示すためです。

と書いてあった。EventsがAWSリソース中でのイベントに利用するサービスというと、EventBridgeはAWSを超えてサードパーティー製品ともイベントでつながる拡張版だといえると理解した。だから、名前がCloudWatch EventsからAmazon EventBridgeに変わったのかな。そういえば、CloudWatchはAWSもAmazonもついてない。なぜなんだろう…？(参考：AWSのサービス名がAWS始まりとAmazon始まりの謎【解決】)

 

変わるところはあるか

　続けて、AWSのAmazon EventBridge のよくある質問を読むと、もともとEnventを利用していた人はEventBridgeに変わることで特に何かする必要はなく、そのまま利用すればいいと書かれている。ただし、名称はCloudwatch EventsからAmazon EventBridgeに変わっていくらしい。

Q: 現在 Amazon CloudWatch Events を使用しており、Amazon EventBridge の機能をぜひ試してみたいと考えています。Amazon CloudWatch Events のルールとアクセス許可を Amazon EventBridge に移動させる必要がありますか?
いいえ。Amazon CloudWatch Events ユーザーは新しい Amazon EventBridge コンソールと API または Amazon CloudWatch Events コンソールと API で、既存のデフォルトのバス、ルール、イベントにアクセスできます。

Q: 現在 Amazon CloudWatch Events を使用しており、Amazon EventBridge の機能は必要ありません。Amazon EventBridge で何か変わることはありますか?
何も変わることはありません。Amazon EventBridge では同じ Amazon CloudWatch Events API を使用するため、既存のすべての CloudWatch Events API の使用に変化はありません。

Q: Amazon CloudWatch Events は将来廃止される予定ですか?
いいえ。API またはサービス自体を廃止する予定はありません。Amazon EventBridge では Amazon CloudWatch Events と同じ API を使用していますが、それに他の機能が追加されています。将来的に、Amazon CloudWatch Events の名称は Amazon EventBridge に置き換えられる予定です。

 

　実際に、よく使っているBoto3(AWSのPython SDK)のドキュメントの若干古いバージョンと最新バージョンをみると、EventsのページがEventBridgeに変わっていることがわかる。しかし、clientで設定するサービス名は「events」で変わらないことがわかる。ドキュメントのURLも「https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/events.html」で変わらない。最初はタイトルだけみて、「Eventsのところ全部EventBreigeに変えないといけない!? どうしよう!!!」と慌てていた。まあ、今サービス名を変えてしまうと世界中が大混乱になる(笑)

 

 

まとめ

　Cloudwatch EventsはAmazon EventBridgeと名前を変え、AWS内のサービスだけではなくサードパーティー製品を含んだイベント駆動型アーキテクチャの設計が可能になった。今はEventBridgeの新機能を使うことはないが、今後機会があればつかってみたい。(機会があればではなく、機会を作らないと…)

Popular Posts

PythonのDict型をDynamoDB形式のJsonに変換する

-
pythonでDynamoDB関連操作をするとき、難しい点の一つは一つは以下のようなDynamoDBの独特なJSON形式だと思います。 { "id": { "N": 12345 }, "name": { "S": "TanakaTaro" } } Python用のAWS SDKであるBoto3にはDynamoDB形式のJsonをPythonのDictに変換できる TypeSerializer と TypeDeserializer があります。 https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html TypeSerializer PythonのDictをDynamoDB形式のJsonに変換します。個人的には変換結果で最初の{"M": ...}はなくしてほしいですが… TypeDeserializer DynamoDB形式のJsonをPythonのDictに変換します。こちらも一気に変換はできず、各Keyごとに変換が必要です。 まとめ＆蛇足 TypeSerializerとTypeDeserializerはDynamoDBのデータをpythonで処理したいときや処理後にまたDynamoDBにアップロードしたいときに有効に利用できそうです。 ただ、そのまま利用するよりは、利用しやすくカスタム関数やクラスを作成したほうがよさそうです。 JavaScriptのSDKにもConverterというものがあるようです https://aws.amazon.com/jp/blogs/developer/announcing-the-amazon-dynamodb-document-client-in-the-aws-sdk-for-javascript/
続きを読む

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった

-
イメージ
まえおき 今週あったチーム先輩(Aさん)との会話 私　：CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。 　　　これが私がCDKを押す理由の一つなんですよ。 Aさん：LambdaみたいにS３バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私　：あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん：うん?これでできないんだけ？(CloudFormationのドキュメントURLを共有) 私　：できるじゃん!? 　送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備 　State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)   　jsonファイルで保存し、S3のバケットに保存する。 　これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備 　 CloudFormationの StepFunctions::StateMachineのドキュメントペ
続きを読む