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 ワークフローの両方で使用可能です。これにより、お客様は次の２つの統合パターンのいずれかを使用して、ワークフローから指定したイベントバスに直接イベントを発行できます。

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 キューの３つのターゲットにイベントを送信するルールがデプロイされます。

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 ワークフローのモデル化方法を説明し、これを使って２つのビジネスドメイン (口座とカスタマーサービス) を統合します。

このプロセスはイベント駆動型であり、疎結合、アイソレーション、自律性の概念を促進します。新しい EventBridge サービス統合による、ローコード統合アプローチを採用しています。

KYC (Know Your Customer) ワークフロー

イベントフローは口座システムから始まります。口座システムでは、新規口座開設の申し込みがされたというイベントを発行します。
このイベントは、KYC サービス内のワークフローをトリガーします。
KYC プロセスは、顧客の身元とリスクプロファイルを検証します。本人確認が完了すると、「本人確認完了」イベントが発行されます。
KYC プロセスは、リスクプロファイル評価の結果に応じて、新規口座開設リクエストの承認または否認を通知する２つのイベントを発行します。
これらのイベントは、口座およびカスタマーサービスドメインによって消費されます。各サービスは、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
```
Bash
SAM デプロイの出力

これにより、Step Functions の標準ワークフロー、EventBridge イベントバス、EventBridge ルールのターゲット用の Amazon CloudWatch ロググループなど、template.yaml ファイルで定義されている複数のリソースがデプロイされます。

アプリケーションのテスト

KYC ワークフローを開始する新規口座開設の申し込みイベントをエミュレートして、イベントバスにいくつかのイベントを手動で送信します。
```
aws events put-events --entries file://put_events.json
```
Bash

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 サービス統合タイプを宣言する３つの新しい arn:aws:states:::events:putEvents リソースが含まれています。

Parameters オブジェクトはサービス統合を設定するために必要なフィールドを保持しています。Entries には、イベントバスに送信される１つ以上のイベントを定義します。 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 櫻谷が担当しました。原文はこちらです。

Cookie の設定を選択する

Amazon Web Services ブログ