【アップデート】Step Functionsから直接EventBridgeにカスタムイベントを発行できるようになりました

【アップデート】Step Functionsから直接EventBridgeにカスタムイベントを発行できるようになりました

CX事業本部@大阪の岩田です。タイトルそのままなのですが、本日のアップデートでStep FunctionsがEventBridgeとのサービス統合をサポートしました。

従来もサービス統合としてSNSがサポートされていましたが、EventBridgeにはSNSと比較して

• 設定可能なターゲットが多い
• アプリケーションが発行するイベント以外にAWS上のイベントやサードパーティ製品のイベントもキャプチャ可能　※Step Functionsとの統合には無関係ですが
• メッセージのフィルタ機能がSNSに比べて優秀
• スキーマレジストリが利用可能
• イベントデータの変換が可能

といったメリットがあります。

5 reasons why you should use EventBridge instead of SNS

EventBridgeのサポートによって、Step Functionsを用いたシステムのアーキテクチャとしてより多くのパターンが選択可能になりました。

EventBridge統合の概要

サポートされるサービス統合

StepFunctionsとEventBridgeの統合は、サービス統合として

• リクエストレスポンス
• コールバックまで待機 (.waitForTaskToken)

の2種類をサポートします。Job の実行 (.sync)はサポートされません。EventBridgeというサービスの特性を考えると妥当ですね。

Supported AWS Service Integrations for Step Functions

サポートされるEventBridgeのAPI

サポートされるEventBrdgeのAPIはPutEvents1つです。PutEventsが叩ければイベントを発行できるので、特に困ることはないでしょう。TaskのParametersとしてはEntriesというパラメータが指定可能で、このEntriesにPutEventsのイベントの詳細をセットします。タスクのサンプルは以下のような形になります

{
  "Type": "Task",
  "Resource": "arn:aws:states:::events:putEvents",
  "Parameters": {
    "Entries": [
      {
        "Detail": {
          "Message": "MyMessage"
        },
        "DetailType": "MyDetailType",
        "EventBusName": "MyEventBus",
        "Source": "my.source"
      }
    ]
  },
  "End": true
}

エラーハンドリング

PutEventsのレスポンスは以下のような形式です。

{
   "Entries": [ 
      { 
         "ErrorCode": "string",
         "ErrorMessage": "string",
         "EventId": "string"
      }
   ],
   "FailedEntryCount": number
}

FailedEntryCountには受け付けたエントリのうち失敗したエントリの数がセットされます。Step FunctionsFailedEntryCountをチェックし、値が0より大きい場合はEventBridge.FailedEntryというエラーを発生させます。Step FunctionsのCatch機構と組み合わせることで、簡単にリトライ処理が実装できます。

やってみる

すでにAWSブログの方でStep FunctionsとEventBridgeの統合について紹介されているので、こちらの内容に沿って試してみます。

金融機関における本人確認のフローを模したようなフローになっています。

※画像は上記AWSブログより引用

アカウントサービスからEventBridgeに発行されたイベントをトリガーにステートマシンが起動し、各タスク完了毎にEventBridgeにイベントを発行。カスタマーサービスのシステムが各Eventを処理するといったアーキテクチャです。

サンプルアプリをデプロイ

まずはGitHubで公開されているサンプルをクローン

$ git clone https://github.com/aws-samples/aws-stepfunctions-examples.git

このサンプルはSAMを利用しているので、sam buildでビルドします。

$ cd aws-stepfunctions-examples/sam/app-kyc-with-eventbridge/
$ sam build

デプロイします

$ sam deploy -g

Configuring SAM deploy
======================

	Looking for config file [samconfig.toml] :  Not found

	Setting default arguments for 'sam deploy'
	=========================================
	Stack Name [sam-app]: sf-eventbridge
	AWS Region [ap-northeast-1]:
	Parameter ParameterInstancePrefix [kyc]:
	#Shows you resources changes to be deployed and require a 'Y' to initiate deploy
	Confirm changes before deploy [y/N]:
	#SAM needs permission to be able to create roles to connect to the resources in your template
	Allow SAM CLI IAM role creation [Y/n]:
	Save arguments to configuration file [Y/n]:
	SAM configuration file [samconfig.toml]:
	SAM configuration environment [default]:

	Looking for resources needed for deployment: Found!

		Managed S3 bucket: aws-sam-cli-managed-default-samclisourcebucket-xxxxxxxxxxx
		A different default S3 bucket can be set in samconfig.toml

	Saved arguments to config file
	Running 'sam deploy' for future deployments will use the parameters saved above.
	The above parameters can be changed by modifying samconfig.toml
	Learn more about samconfig.toml syntax at
	https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-config.html

Uploading to sf-eventbridge/e84ab113661d2cad6a68128cd16f5c73  3619 / 3619  (100.00%)

	Deploying with following values
	===============================
	Stack name                   : sf-eventbridge
	Region                       : ap-northeast-1
	Confirm changeset            : False
	Deployment s3 bucket         : aws-sam-cli-managed-default-samclisourcebucket-xxxxxxxxxxx
	Capabilities                 : ["CAPABILITY_IAM"]
	Parameter overrides          : {"ParameterInstancePrefix": "kyc"}
	Signing Profiles             : {}

Initiating deployment
=====================
Uploading to sf-eventbridge/2c254d0784725dc5603e34b965b24ea8.template  5541 / 5541  (100.00%)

Waiting for changeset to be created..
...略

デプロイが完了すると以下のステートマシンがデプロイされています。

EventBridgeのルールも合計4つデプロイされています。1つはアカウントサービスから発行されたイベントをトリガーにステートマシンを起動するルール

残り3つはStep Functionsから発行されたイベントをトリガーにCloudWatch Logsにログを書き込むルールです。実際のユースケースではこの部分がカスタマーサービスのAPI呼び出し等に置き換わる想定です。

ステートマシンを起動

サンプルアプリがデプロイできたのでアカウントサービスからのイベント発行をシミュレーションし、ステートマシンを起動してみます。

$aws events put-events --entries file://put_events.json

{
    "FailedEntryCount": 0,
    "Entries": [
        {
            "EventId": "86c1bbdd-eabf-e87a-83b5-ba44d7b9a857"
        },
        {
            "EventId": "fc2d4595-7b78-cfa4-8e0c-eb423c8068da"
        }
    ]
}

Step Functionsの実行履歴を確認します。

ステートマシンが起動し、EventBridgeにイベントが発行されていることが分かります。

CloudWatchのログを確認してみましょう

EventBridge経由でログが出力されていることが分かります

まとめ

イベントドリブンなシステムのアーキテクチャが広がる熱いアップデートです。これまでLambda等を用いてサービス間連携を実現していた箇所もノーコーディングでEventBridegeに置き換えられる可能性があるので、ぜひ利用をご検討下さい。