[AWS Step Functions] 複数の先行ステートマシンの実行が完了した後に別AWSアカウントのステートマシンを実行してみた

ジョブ管理システムをAWS Step Functionsに置き換えたくてしょうがない

こんにちは、のんピ(@non____97)です。

皆さんはジョブ管理システムから抜け出したいと思ったことはありますか? 私は常に思っています。

前回の記事のおわりに以下のような記載をしました。

また、今回は先行ステートマシンと後続ステートマシンが同じAWSアカウントである前提で構成しました。先行ジョブネットと後続のジョブネットのアカウントが異なる場合でも、以下記事で紹介しているようにEventBridgeルールのターゲットで別アカウントまたはリージョンのイベントバスを選択することで対応可能だと考えます。

今回は実際に「複数の先行ステートマシンの実行が完了した後に別アカウントのステートマシンを実行」してみます。

検証の構成

今回の検証の構成は以下の通りです。

前回の以下記事と同様に、先行ステートマシンAと先行ステートマシンBの正常に実行完了した数のメトリクス(ExecutionsSucceeded)をCloudWatch Metric Mathで計算します。そして、計算結果が先行ステートマシンの数と同じ値になったらアラームを発報し、後続ステートマシンのAWSアカウントのEventBridgeイベントバスに処理を流します。後続ステートマシンのAWSアカウントでは、EventBridgeルールで先行ステートマシンのAWSアカウントからのアラームを検知したら後続ステートマシンを実行します。

検証は前回の記事の「CloudWatchアラームの設定」まで完了しており、EventBridgeルールの設定する前提で行います。

先行ステートマシンのAWSアカウントのEventBridgeルールの設定

先行ステートマシンのAWSアカウントのEventBridgeルールの設定をします。

CloudWatchアラームがアラーム状態になった場合に検知してほしいので、イベントパターンは以下のようになります。

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "resources": [
    "arn:aws:cloudwatch:us-east-1:<先行ステートマシンのAWSアカウントID>:alarm:prior-state-machine-alarm"
  ],
  "detail": {
    "state": {
      "value": ["ALARM"]
    }
  }
}

イベントを検知した場合は、後続ステートマシンのAWSアカウントのEventBridgeイベントバスに投げるようにターゲットを設定します。また、ステートマシン実行時のIAMロールは新規で作成しました。マネージメントコンソール上では以下のように設定を行います。

作成されたIAMロールのポリシーを確認すると、後続ステートマシンのAWSアカウントのデフォルトのEventBridgeイベントバスにイベントを流すポリシーとなっていました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "events:PutEvents"
            ],
            "Resource": [
                "arn:aws:events:us-east-1:<後続ステートマシンのAWSアカウントID>:event-bus/default"
            ]
        }
    ]
}

後続ステートマシンのAWSアカウントのEventBridgeイベントバスの設定

先行ステートマシンのAWSアカウントからアクセスできるように後続ステートマシンのAWSアカウントのEventBridgeイベントバスの設定をします。

デフォルトのEventBridgeイベントバスのアクセス許可を管理をクリックします。

先行ステートマシンのAWSアカウントから後続ステートマシンのAWSアカウントのデフォルトのEventBridgeイベントバスへのアクセスを許可するポリシーを入力して、更新をクリックします。

入力したポリシーは以下の通りです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "allow_account_to_put_events",
      "Effect": "Allow",
      "Principal": {
        "AWS": "<先行ステートマシンのAWSアカウントID>"
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:us-east-1:<後続ステートマシンのAWSアカウントID>:event-bus/default"
    }
  ]
}

後続ステートマシンのAWSアカウントのEventBridgeルールの設定

後続ステートマシンのAWSアカウントのEventBridgeルールの設定をします。

CloudWatchアラームがアラーム状態になった場合に検知してほしいので、イベントパターンは以下のようになります。

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "account": ["<先行ステートマシンのAWSアカウントID>"],
  "resources": [
    "arn:aws:cloudwatch:us-east-1:<先行ステートマシンのAWSアカウントID>:alarm:prior-state-machine-alarm"
  ],
  "detail": {
    "state": {
      "value": ["ALARM"]
    }
  }
}

イベントを検知した場合は、後続ステートマシンを実行するようにターゲットを設定します。また、ステートマシン実行時のIAMロールは新規で作成しました。マネージメントコンソール上では以下のように設定を行います。

作成されたIAMロールのポリシーを確認すると、後続ステートマシンを実行するポリシーとなっていました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "states:StartExecution"
            ],
            "Resource": [
                "arn:aws:states:us-east-1:<後続ステートマシンのAWSアカウントID>:stateMachine:StateMachineC"
            ]
        }
    ]
}

先行ステートマシンを実行してみた

それでは先行ステートマシンを実行してみて、そのタイミングで後続ステートマシンが実行されるのかを確認してみます。

マネージメントコンソールから先行ステートマシンAを実行しました。終了時間を確認すると、22:47 (JST)でした。

少し時間を置いて、先行ステートマシンBを実行しました。終了時間を確認すると、22:50 (JST)でした。

先行ステートマシンB実行後のCloudWatchアラームを確認すると、13:51 (UTC)にアラーム状態となっていました。

後続ステートマシンCの実行履歴を確認すると、確かに先行ステートマシンBの実行後である22:51 (JST)に実行開始をしていることを確認できました。

これで複数の先行ステートマシンの実行が完了した後に別アカウントのステートマシンを実行する動作確認ができました。

マルチアカウントでもステートマシンの連携はできる

AWS Step Functionsで複数の先行ステートマシンの実行が完了した後に別AWSアカウントのステートマシンを実行してみました。

大規模なジョブネットは複数のアカウントに処理がまたいでいる場合もあると思います。今回の検証でマルチアカウントでもステートマシン間の連携はできることを確認できたので、どんどんジョブネットを置き換えていきたいと思います。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!