Amazon Web Services ブログ
AWS Step Functions と Amazon EventBridge のサービス統合のご紹介
この記事は Sr Serverless Specialist SA, Stephen Liedig による寄稿の翻訳です。
AWS Step Functions が Amazon EventBridge と統合し、ワークフロー中でイベントを生成するためのシンプルなソリューションが提供可能になりました。
Step Functions を使用すると、AWS Lambda, Amazon SNS, Amazon DynamoDB などの AWS サービスを使用した、弾力性のあるサーバーレスオーケストレーションワークフローを構築できます。Step Functions の特定のステートマシンの実行履歴は、AWS マネジメントコンソールまたは Amazon CloudWatch Logs で確認できます。
EventBridge を使用すると、AWS サービス、連携済みの SaaS (Software as a service) アプリケーション、および独自のアプリケーション間でイベントをルーティングできます。イベントプロデューサーは、イベントバスに向けてイベントを発行します。イベントバスは、ルールを使用してそれらのイベントの送信先を決定します。ルールでは、他の AWS サービスまたは API destinations をターゲットとして複数指定できます。イベントのルーティングとフィルタリングを行うこのモデルによって、スケーラブルな分散サーバーレスアプリケーションの開発が容易になります。
新しい機能の紹介
EventBridge と Step Functions の新しい統合は、次の新規のリソースタイプを提供します – arn:aws:states:::events:putEvents
. これは、標準ワークフローと Express ワークフローの両方で使用可能です。これにより、お客様は次の2つの 統合パターン のいずれかを使用して、ワークフローから指定したイベントバスに直接イベントを発行できます。
- Request-Response: サービスを呼び出し、HTTP レスポンスを受信してから Step Functions を次のステートに進めます。このパターンは、標準ワークフローと Express ワークフローでサポートされています。
Send an EventBridge custom event: Type: Task Resource: 'arn:aws:states:::events:putEvents' Parameters: Entries: - Detail: Message: 'Hello from Step Functions!' DetailType: MyDetailType EventBusName: MyEventBusName Source: MySource Next: NEXT_STATE
- Wait-for-Callback: タスクトークンを使用してサービスを呼び出し、トークンがペイロードを伴って返されるまで Step Functions を待機させます。このパターンは、標準ワークフローでサポートされています。
Send an EventBridge custom event: Type: Task Resource: 'arn:aws:states:::events:putEvents.waitForTaskToken' Parameters: Entries: - Detail: Message: 'Hello from Step Functions!' TaskToken.$: $$.Task.Token DetailType: MyDetailType EventBusName: MyEventBusName Source: MySource Next: NEXT_STATE
新しい統合は、以下の Amazon States Language (ASL) パラメータフィールドで設定できます。
- Detail: 有効な文字列または JSON オブジェクト
- DetailType: イベントの詳細で必要なフィールドを決定するために使用される自由形式の文字列。
- EventBusName: イベントを受信するイベントバスの名前または ARN。このイベントバスに関連付けられているルールのみが、イベントの照合に使用されます。これを省略すると、デフォルトのイベントバスが使用されます。別のアカウントのイベントバスを ARN に指定することも可能です。
- Source: イベントのソース。
- Time: イベントのタイムスタンプ (オプション)
- Resources: イベントに関連するリソースを識別する ARN が含まれる JSON 配列 (オプション)。
EventBridge のフィールドとコンセプトの詳細については、ドキュメント をご覧ください。
使い方
この統合は、AWS Serverless Application Model (AWS SAM), AWS コマンドラインインターフェイス (AWS CLI), AWS CloudFormation, または AWS マネジメントコンソール から設定できます。
AWS マネジメントコンソールを使用する場合:
- Step Functions コンソール に移動します。
- [サンプルプロジェクトを実行] を選択し、[EventBridge にカスタムイベントを送信] を選択します。
- 定義 セクションには、サンプルワークフローを構成している ASL が表示されます。次の例は、新しい EventBridge リソースとそのパラメータを示しています。
- サンプルの 定義 を確認し、[次へ] を選択します。
- [リソースのデプロイ] を選択します。
これにより、標準の Step Functions ワークフローと EventBridge のイベントバス、および Step Functions から AWS Lambda 関数, Amazon SNS トピック、および Amazon SQS キューの3つのターゲットにイベントを送信するルールがデプロイされます。
Step Functions がイベントバスにメッセージを送信できるように、必要なアクセス許可を持つ IAM ロールをデプロイします。また、EventBridge が各ターゲットにイベントを送信できるように、ロールとリソースポリシーも作成されます。
ワークフローの実行
- Step Functions コンソール から、新しく作成したステートマシンを選択します。
- [実行の開始] を選択します。
- 入力フィールドをクリアします。
- [実行の開始] を選択します。
- [Send a custom Event] ステップを選択し、[実行出力] タブを選択します。ここでは、イベントが EventBridge に正常に配信されたか失敗したかが表示されます。
アクセス制御
EventBridge の統合では、AWS Identity and Access Management (IAM) による認証および認可がサポートされています。これには、IAM ロール、ポリシー、タグが含まれます。AWS IAM ロールとポリシー は、EventBridge リソースの作成またはアクセスのために適用できる、柔軟で堅牢なアクセス制御を提供します。タグベースのアクセス制御 を使用すると、すべての EventBridge リソースに対して、よりきめ細かなアクセス制御を設定できます。タグのキーと値のペアを指定して、EventBridge リソースを環境またはその他の基準で分類します。
EventBridge リソースポリシー は、特定のプリンシパル(通常は IAM ユーザーまたは AWS アカウント)がイベントを送信したり、イベントバス上でルールを作成できるかどうかを制御する JSON ポリシードキュメントです。リソースポリシーは、イベントバスにイベントを送信するためのアクセス許可を Step Functions に与えます。異なる AWS アカウントのワークフローや、特定のステートマシンに対してのみといった指定も可能です。詳細については、「Amazon EventBridge でのクロスリージョンイベントルーティングの概要」をご覧ください。
EventBridge 統合のアクセス制御を設定するには、Step Functions が以下のポリシーが付与されたロールを引き受ける必要があります。
{
"Statement": [
{
"Action": "events:PutEvents",
"Resource": "arn:aws:events:[REGION]:[ACCOUNT]:event-bus/[EVENT BUS NAME]",
"Effect": "Allow"
}
]
}
マイクロサービスのサンプル
KYC (Know Your Customer) ガイドラインは、顧客の本人確認とリスクプロファイルの作成を含む多くの金融機関における一般的なポリシーおよび基準です。この例では、Step Functions による KYC ワークフローのモデル化方法を説明し、これを使って2つのビジネスドメイン (口座とカスタマーサービス) を統合します。
このプロセスはイベント駆動型であり、疎結合、アイソレーション、自律性の概念を促進します。新しい EventBridge サービス統合による、ローコード統合アプローチを採用しています。
- イベントフローは口座システムから始まります。口座システムでは、新規口座開設の申し込みがされたというイベントを発行します。
- このイベントは、KYC サービス内のワークフローをトリガーします。
- KYC プロセスは、顧客の身元とリスクプロファイルを検証します。本人確認が完了すると、「本人確認完了」イベントが発行されます。
- KYC プロセスは、リスクプロファイル評価の結果に応じて、新規口座開設リクエストの承認または否認を通知する2つのイベントを発行します。
- これらのイベントは、口座およびカスタマーサービスドメインによって消費されます。各サービスは、KYC プロセスの結果を処理するための中央イベントバスにそれぞれルールを定義しています。
EventBridge の新しいサービス統合を使用すると、開発者はイベントをステートマシンに明示的にモデル化できます。これは、ステートマシンの実行のどの段階でも発生し、関心のあるコンシューマーに状態遷移を通知する便利な方法です。長時間実行されるプロセスでは、ステートマシンの実行 ID を知るためにコンシューマーが DescribeExecution
API を呼び出して実行履歴をクエリする必要性を置き換えられます。代わりに、コンシューマーはステートマシンから送出されるイベントをサブスクライブすることで、実装からの疎結合性を維持することができます。
ステートマシンの実行 ID が必要な場合は、サービス統合によって提供されます。例えば、先ほど定義したステートマシンの「新規口座開設の承認」ステートは、ステートマシンの ARN と実行 ID をリソース フィールドに含んだイベントを送信します。Step Functions は、ステートの実行時間、およびそれが呼び出されたアカウントとリージョンとともにこれらのフィールドを自動的に追加します。
{
"version": "0",
"id": "005fc46c-f5d7-a074-06a2-0032c07529d7",
"detail-type": "New account approved",
"source": "com.aws.kyc",
"account": "111122223333",
"time": "2021-05-06T03:08:23Z",
"region": "ca-central-1",
"resources": [
"arn:aws:states:ca-central-1:111122223333:stateMachine:KycStateMachine-jUkKkPuut800",
"arn:aws:states:ca-central-1:111122223333:execution:KycStateMachine-jUkKkPuut800:06bce19f-8b25-2982-a704-ad78cc1a29e5_afe130b6-0c15-e61f-90be-a27f38511a15"
],
"detail": {
"customerAddress": "123 Any Street, Any Town, USA",
"agencyChecked": true,
"indentityChecked": true,
"customerName": "Nikki Wolf",
"checksPassed": true
}
}
アプリケーションの実行
- GitHub リポジトリをクローンします。
git clone https://github.com/aws-samples/aws-stepfunctions-examples.git cd ./aws-stepfunctions-examples/sam/app-kyc-with-eventbridge
- AWS SAM CLI を使用してアプリケーションをビルドおよびデプロイします。パラメータはデフォルトのまま入力します。
sam build sam deploy -g
これにより、Step Functions の標準ワークフロー、EventBridge イベントバス、EventBridge ルールのターゲット用の Amazon CloudWatch ロググループなど、template.yaml ファイルで定義されている複数のリソースがデプロイされます。
アプリケーションのテスト
- KYC ワークフローを開始する新規口座開設の申し込みイベントをエミュレートして、イベントバスにいくつかのイベントを手動で送信します。
aws events put-events --entries file://put_events.json
put_events.json ファイルには、ステートマシンの実行を開始する中央イベントバスに送信されるイベントが含まれています。EventBusName フィールドの値が、AWS SAM デプロイによって作成されたイベントバスの名前と一致していることを確認します。
{
"Source": "com.aws.accounts",
"Detail": "{\"customerName\": \"Nikki Wolf\", \"customerAddress\": \"123 Any Street, Any Town, USA\" }",
"DetailType": "New account requested",
"EventBusName": "CentralEventBus"
}
レスポンスは、イベントが正常に送信されたことを示しています。
{
"FailedEntryCount": 0,
"Entries": [
{
"EventId": "9f6d6147-7f77-dfe8-f3b9-79b38833d258"
},
{
"EventId": "db695c48-da98-69a8-f82a-ad3cc04e07bd"
}
]
}
ステートマシンは、中央イベントバスに定義されているルールによって呼び出されます。このルールは、サーバーレス ステートマシンリソース の ステートマシンイベントソース として AWS SAM テンプレートで定義されます。
ワークフローは、別のファイル (/statemachine/kyc.asl.yaml) で定義されています。DefinitionSubstitutions フィールドは、テンプレートパラメータをワークフロー定義に渡すために使用されます。今回の場合、中央イベントバスの名前が CentralEventBusName 変数を代替するパラメータとして渡されます。この代替変数はステートマシン定義ファイルに渡され、ステートマシンで定義された EventBridge サービス統合ステートで、イベントを送信するイベントバスの名前を設定するために使用されます。
KycStateMachine:
Type: AWS::Serverless::StateMachine
Properties:
DefinitionUri: statemachine/kyc.asl.yaml
DefinitionSubstitutions:
CentralEventBusName: !Ref CentralEventBus
Policies:
- AWSXRayDaemonWriteAccess
- EventBridgePutEventsPolicy:
EventBusName: !Ref CentralEventBus
- Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- 'logs:CreateLogDelivery'
- 'logs:GetLogDelivery'
- 'logs:UpdateLogDelivery'
- 'logs:DeleteLogDelivery'
- 'logs:ListLogDeliveries'
- 'logs:PutResourcePolicy'
- 'logs:DescribeResourcePolicies'
- 'logs:DescribeLogGroups'
Resource: !GetAtt StateMachinesLogGroup.Arn
Logging:
Destinations:
- CloudWatchLogsLogGroup:
LogGroupArn: !GetAtt StateMachinesLogGroup.Arn
Tracing:
Enabled: True
Events:
EBRule:
Type: EventBridgeRule
Properties:
EventBusName: !Ref CentralEventBus
InputPath: $.detail
Pattern:
source:
- com.aws.accounts
detail-type:
- New account requested
account:
- !Ref AWS::AccountId
定義自体には、EventBridge サービス統合タイプを宣言する3つの新しい arn:aws:states:::events:putEvents
リソースが含まれています。
Parameters オブジェクトはサービス統合を設定するために必要なフィールドを保持しています。Entries には、イベントバスに送信される1つ以上のイベントを定義します。 EventBusName の値は、AWS SAM テンプレートの DefinitionsSubstitions フィールドによって提供されます。Detail の入力は、Amazon States Language を使用して動的に定義されます。Detail のフィールド名の末尾にある “.$” は、パラメーターがパスを使用して入力内の JSON ノードを参照することを指定しています。
Identity check completed:
Comment: >-
Publish event when identity check has been completed
Type: Task
Resource: 'arn:aws:states:::events:putEvents'
Parameters:
Entries:
- Detail.$: $
DetailType: Identity check completed
EventBusName: '${CentralEventBusName}'
Source: com.aws.kyc
Next: Verify risk profile
Retry:
- ErrorEquals:
- States.ALL
IntervalSeconds: 1
BackoffRate: 2
MaxAttempts: 2
クリーンアップ
チュートリアルを完了したら、忘れずに CloudFormation からスタックを削除してください。CloudFormation コンソールからアプリケーションを選択し、[削除] を選択します。
まとめ
Step Functions と EventBridge の統合により、Step Functions ワークフローから PutEvents を直接呼び出すことができるようになりました。
ワークフロー内で明示的にイベントをモデル化および送信する機能により、オーケストレーションロジックと他の分散コンポーネントまたはサービス間の結合度が軽減されます。また、EventBridge API を呼び出すために Lambda 関数を置く必要がなくなりました。
この機能は、Step Functions と EventBridge の両方が利用可能なすべてのリージョンでご利用いただけます。詳細については、AWS リージョン別のサービス表 をご覧ください。料金については、Step Functions の 料金 をご覧ください。通常の EventBridge サービスクォータ と Step Functions のサービスクォータ が適用されます。
サーバーレスについてさらに学習したい場合は、Serverless Land をご覧ください。
翻訳は Partner SA 櫻谷が担当しました。原文は こちら です。