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

アーキテクチャの選択肢が広がる熱いアップデートです！！

#AWS Step Functions

#AWS

岩田智哉

2021.05.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

【アップデート】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の実行履歴を確認します。