ステートマシンの設計 - Step Functions によるワークフローオーケストレーション

分散システムにおけるワークフロー管理の課題

マイクロサービスやサーバーレスアーキテクチャでは、複数のサービスを連携させた複雑なビジネスプロセスの管理が課題となります。個々の Lambda 関数やサービスは単一の責務を持ちますが、それらを組み合わせたワークフロー全体の制御、エラーハンドリング、リトライ、状態管理を自前で実装すると、コードの複雑さが急激に増大します。AWS Step Functions は、ステートマシンの概念に基づいてワークフローを定義・実行するフルマネージドサービスで、この課題を解決します。Amazon States Language (ASL) という JSON ベースの言語でワークフローを宣言的に定義し、ビジュアルエディタで処理フローを視覚的に確認・編集できます。

Standard ワークフローと Express ワークフロー

Step Functions は Standard と Express の 2 種類のワークフロータイプを提供し、ユースケースに応じた最適な選択が可能です。Standard ワークフローは最大 1 年間の実行をサポートし、実行履歴の完全な記録と exactly-once のセマンティクスを保証します。長時間のバッチ処理、人間の承認を含むワークフロー、複雑なエラーハンドリングが必要なビジネスプロセスに適しています。料金はステート遷移 1,000 回あたり 0.025 USD (2026 年 8 月時点・米国東部 (バージニア北部)) で、実行履歴は 90 日間保持されます。Express ワークフローは最大 5 分間の実行で、秒間 100,000 件以上の高スループット処理に対応します。IoT データの処理、リアルタイムのストリーミングデータ変換、高頻度の API リクエスト処理など、短時間で大量の実行が必要なワークロードに最適です。Express ワークフローの課金は実行回数 (100 万回あたり 1.00 USD) と実行時間 (GB-秒) の組み合わせで、ステート遷移数で課金される Standard とは料金モデルそのものが異なります。そのため、ステート遷移の多い処理を短時間・高頻度に回すワークロードでは Express の方が費用を抑えやすく、実行回数が少なく長時間動くワークフローや完全な実行履歴が要件になるケースでは Standard が適します。どちらが安くなるかは遷移数・実行時間・メモリ使用量の組み合わせで逆転するため、実際のワークロードの数値を両方の料金モデルに当てはめて比較します。

ステートタイプとエラーハンドリング

Step Functions は 8 種類のステートタイプを提供し、多様なワークフローパターンを表現できます。Task ステートは Lambda 関数や AWS サービスの呼び出し、Choice ステートは条件分岐、Parallel ステートは並列実行、Map ステートは配列データの反復処理を担います。Wait ステートは指定時間の待機、Pass ステートはデータの変換・受け渡し、Succeed と Fail ステートはワークフローの終了を制御します。Map ステートの分散モードでは、最大 10,000 件の並列実行が可能で、大規模なデータ処理パイプラインを効率的に構築できます。エラーハンドリングは Retry と Catch の 2 つのメカニズムで実現します。以下は ASL でのエラーハンドリング定義例です。

{
  "ProcessOrder": {
    "Type": "Task",
    "Resource": "arn:aws:lambda:ap-northeast-1:123456789:function:process",
    "Retry": [
      {
        "ErrorEquals": ["States.TaskFailed"],
        "IntervalSeconds": 3,
        "MaxAttempts": 3,
        "BackoffRate": 2.0,
        "JitterStrategy": "FULL"
      }
    ],
    "Catch": [
      {
        "ErrorEquals": ["States.ALL"],
        "Next": "HandleError"
      }
    ]
  }
}

Retry は IntervalSeconds (初回の待機時間)・MaxAttempts (再試行回数)・BackoffRate (待機時間の増加率) による指数バックオフを提供し、一時的な障害からの回復を自動化します。待機時間にランダムなばらつきを与えるジッターは既定では適用されず、上の例のように JitterStrategy を FULL と明示指定した場合にのみ有効になります。多数の実行が同じタイミングで失敗したとき、ジッターなしでは再試行の時刻が揃って下流のサービスを再び圧迫するため、並列度の高いワークフローでは明示指定を検討します。Catch はリトライ後も失敗した場合のフォールバック処理を定義し、エラー通知やクリーンアップ処理への分岐を実現します。

AWS サービスとの直接統合

Step Functions の AWS SDK 統合により、Lambda 関数を介さずに 200 を超える AWS サービスの 9,000 を超える API アクションを直接呼び出せます (2026 年 8 月時点)。 DynamoDB へのデータ書き込み、 SQS へのメッセージ送信、 SNS による通知、 ECS タスクの起動、 Glue ジョブの実行などを、ステートマシンの定義内で直接記述できます。この直接統合により、単純な API 呼び出しのためだけに Lambda 関数を作成する必要がなくなり、アーキテクチャの簡素化とコスト削減が実現します。 Optimized 統合では、 DynamoDB 、 SQS 、 SNS 、 EventBridge などの主要サービスとの連携がさらに効率化され、レスポンスのフィルタリングやエラーハンドリングが組み込まれています。 Callback パターンを使用すれば、外部システムからの応答を待機する非同期ワークフローも構築でき、人間の承認プロセスや外部 API の完了待ちを含むワークフローに対応します。 Step Functions の SDK 統合は IAM ロールベースの認証で AWS サービスにシームレスにアクセスでき、追加の認証設定が不要です。

IaC によるステートマシンの管理と運用

Step Functions のステートマシンは SAM (Serverless Application Model) や CDK (Cloud Development Kit) で宣言的に管理できます。SAM テンプレートでは、ステートマシンの定義ファイル (ASL JSON) を外部参照し、関連する Lambda 関数や IAM ポリシーとともに 1 つのスタックでデプロイできます。

Resources:
  OrderStateMachine:
    Type: AWS::Serverless::StateMachine
    Properties:
      DefinitionUri: statemachine/order.asl.json
      DefinitionSubstitutions:
        ProcessFunctionArn: !GetAtt ProcessFunction.Arn
        OrderTableName: !Ref OrderTable
      Policies:
        - LambdaInvokePolicy:
            FunctionName: !Ref ProcessFunction
        - DynamoDBCrudPolicy:
            TableName: !Ref OrderTable

CloudWatch メトリクスとの統合により、実行回数、成功率、失敗率、実行時間の統計をリアルタイムに監視できます。ExecutionsFailed メトリクスにアラームを設定すれば、ワークフローの失敗を即座に検知し、SNS 経由で通知できます。X-Ray との統合により、ステートマシン内の各ステップのレイテンシを詳細にトレースし、パフォーマンスボトルネックを特定できます。CloudWatch Logs への実行ログ出力を有効にすれば、ステート遷移の詳細な履歴を長期保存し、監査やトラブルシューティングに活用できます。

Step Functions の料金

(2026 年 8 月時点・米国東部 (バージニア北部) の料金) 標準ワークフローは状態遷移 1 回あたり 0.000025 ドルの従量課金です。月 100 万回の状態遷移を実行した場合、無料枠の 4,000 回を差し引いた 996,000 回分が課金対象となり、約 24.9 ドルになります。無料枠は月間 4,000 回の状態遷移で、AWS アカウント作成から 12 か月で失効しない継続的な枠として提供されています。Express ワークフローは実行回数 (100 万回あたり 1.00 ドル) と実行時間の組み合わせで課金され、実行時間は使用量に応じた段階制です (最初の 1,000 GB-時間が 0.06 ドル、次の 4,000 GB-時間が 0.03 ドル、それ以降が 0.01642 ドル)。GB-秒に換算すると最初の段階が約 0.00001667 ドルにあたります。メモリは 64 MB 単位、実行時間は 100 ミリ秒単位で切り上げて計測されるため、極端に短い処理を大量に回す場合は実行回数側の課金が支配的になります。Express ワークフローの実行回数・実行時間に無料枠はありません。高スループットの短時間実行では Express の料金モデルが有利になりやすく、長時間の実行や完全な実行履歴の保持が要件になるワークフローでは標準が適しています。単価はリージョンによって異なるため、実際の見積もりは利用リージョンの公式料金表で確認してください。

まとめ - ステートマシン設計の選択

AWS Step Functions は、ステートマシンの概念に基づいたワークフローオーケストレーションサービスとして、分散システムの複雑な処理フローを宣言的に定義・管理します。Standard (最大 1 年実行・ステート遷移 1,000 回あたり 0.025 USD) と Express (秒間 100,000 件規模のスループット・実行回数と実行時間による課金) の 2 種類のワークフロータイプにより、長時間のバッチ処理から高スループットのリアルタイム処理まで幅広いユースケースに対応します。200 を超える AWS サービスとの SDK 直接統合により、Lambda 関数を介さないシンプルなアーキテクチャを実現し、SAM/CDK による IaC 管理で開発効率とコスト効率を向上させます。