翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Step Functions のベストプラクティス

以下のトピックは、Step Functions ワークフローの管理と最適化に役立つベストプラクティスです。

Express ワークフローを使用したコストの最適化

Step Functions は、ステートマシンの構築に使用するワークフロータイプに基づいて、標準ワークフローと Express ワークフローの価格を決定します。サーバーレスワークフローのコストを最適化するには、以下の推奨事項のどちらかまたは両方に従ってください。

Standard ワークフロータイプまたは Express ワークフロータイプの選択が請求に与える影響については、「」を参照してください。 AWS Step Functions 料金

Standard ワークフロー内の Nest Express ワークフロー

Step Functions は一定の期間とステップ数のあるワークフローを実行します。ワークフローによっては、短時間待機した後に実行を完了する場合があります。実行時間が長いワークフローと high-event-rate ワークフローの両方を組み合わせる必要がある場合もあります。Step Functions を使用すると、小さくて単純な複数のワークフローから大規模で複雑なワークフローを構築できます。

例えば、注文処理ワークフローを構築する場合、同一ではないすべてのアクションを標準ワークフローに含めることができます。これには、人が操作する注文の承認や支払いの処理などのアクションが含まれる場合があります。その後、支払い通知の送信や商品在庫の更新など、一連の独立したアクションを Express ワークフローにまとめることができます。この Express ワークフローは標準ワークフロー内にネストできます。この例で、標準ワークフローは親ステートマシンと呼ばれます。ネストされた Express ワークフローは子ステートマシンと呼ばれます。

標準ワークフローを Express ワークフローに変換する

既存の標準ワークフローが以下の要件を満たしていれば、Express ワークフローに変換できます。

ワークフローのコスト最適化を管理する際のベストプラクティスとガイドラインの詳細については、「費用対効果の向上」を参照してください。 AWS Step Functions ワークフロー 。

Step Functions でのステートマシンとアクティビティのタグ付け

AWS Step Functions は、ステートマシン (標準と Express の両方) とアクティビティのタグ付けをサポートしています。タグは、 リソースを追跡および管理し、 のセキュリティを向上させるのに役立ちます。 AWS Identity and Access Management （IAM) ポリシー。Step Functions リソースにタグを付けた後、 を使用してリソースを管理できます。 AWS Resource Groups。 この方法については、「」を参照してください。 AWS Resource Groups ユーザーガイド 。

次の例のように、タグベースの認証の場合、ステートマシンの実行リソースはステートマシンに関連付けられたタグを継承します。

arn:<partition>:states:<Region>:<account-id>:execution:<StateMachineName>:<ExecutionId>

実行リソース を指定する DescribeExecutionまたは他の を呼び出すAPIsとARN、Step Functions はステートマシンに関連付けられたタグを使用して、タグベースの認証の実行中にリクエストを承諾または拒否します。これにより、ステートマシンレベルの実行へのアクセスを許可または拒否できます。

リソースのタグ付けに関連する制限を確認するには、タグ付けに関連する制限 を参照してください。

コスト割り当てのタグ付け

コスト配分タグを使用してステートマシンの目的を特定し、その組織を に反映できます。 AWS 請求 サインアップして を入手する AWS タグのキーと値を含める アカウント請求書。「」の「毎月のコスト配分レポートの設定」を参照してください。 AWS Billing レポートの設定の詳細については、 ユーザーガイドを参照してください。

例えば、次のように、コストセンターと Step Functions リソースの目的を表すタグを追加できます。

セキュリティのためのタグ付け

IAM は、タグに基づくリソースへのアクセスの制御をサポートしています。タグに基づいてアクセスを制御するには、 IAMポリシーの条件要素でリソースタグに関する情報を指定します。

例えば、キー environment および値 production のタグを含むすべての Step Functions リソースへのアクセスを制限できます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "states:TagResource",
                "states:DeleteActivity",
                "states:DeleteStateMachine",
                "states:StopExecution"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {"aws:ResourceTag/environment": "production"}
            }
        }
    ]
}

詳細については、「 IAMユーザーガイド」の「タグを使用したアクセスの制御」を参照してください。

Step Functions コンソールでのタグの管理

Step Functions コンソールでステートマシンのタグを表示および管理できます。ステートマシンの [Details] (詳細) ページから、[Tags] (タグ) を選択します。

Step Functions API アクションによるタグの管理

Step Functions を使用してタグを管理するにはAPI、次のAPIアクションを使用します。

タイムアウトを使用して Step Functions ワークフロー実行が停止しないようにする

デフォルトでは、Amazon States Language はステートマシンの定義にタイムアウトを指定しません。明示的なタイムアウトが設定されていないと、Step Functions は多くの場合、アクティビティのワーカーからのレスポンスでしか、タスクが完了したことを知ることができません。エラーが発生した場合、TimeoutSeconds フィールドに Activity 状態または Task 状態が指定されていないと、実行は、返されることのないレスポンスを待ち続けるため、スタックします。

この状況を回避するには、ステートマシンで Task を作成するときに、適切なタイムアウトを指定します。例:

"ActivityState": {
  "Type": "Task",
  "Resource": "arn:aws:states:us-east-1:123456789012:activity:HelloWorld",
  "TimeoutSeconds": 300,
  "Next": "NextState"
}

タスクトークン (.waitForTaskToken) でコールバックを使用する場合は、ハートビートを使用し、Task状態定義に HeartbeatSecondsフィールドを追加することをお勧めします。HeartbeatSeconds をタスクのタイムアウトよりも短く設定できるので、ワークフローがハートビートエラーで失敗した場合、タスクが完了するまでに時間がかかったのではなく、タスクの失敗が原因であることがわかります。

{
  "StartAt": "Push to SQS",
  "States": {
    "Push to SQS": {
      "Type": "Task",
      "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
      "HeartbeatSeconds": 600,
      "Parameters": {
        "MessageBody": { "myTaskToken.$": "$$.Task.Token" },
        "QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/push-based-queue"
      },
      "ResultPath": "$.SQS",
      "End": true
    }
  }
}

詳細については、Amazon States Language ドキュメントの タスクワークフローの状態 を参照してください。

Step Functions で大きなペイロードを渡すARNs代わりに Amazon S3 を使用する

状態間でデータの大きいペイロードを渡す実行を終了できます。状態間を通過するデータが 256 KB を超える可能性がある場合は、Amazon Simple Storage Service (Amazon S3) を使用してデータを保存し、 Payloadパラメータでバケットの Amazon リソースネーム (ARN) を解析してバケット名とキー値を取得します。または、実行時に小さいペイロードを渡すように実装を調整します。

次の例では、ステートマシンは入力を に渡します。 AWS Lambda 関数。Amazon S3 バケット内のJSONファイルを処理します。このステートマシンを実行すると、Lambda 関数はJSONファイルの内容を読み取り、ファイルの内容を出力として返します。

Lambda 関数を作成する

次の という名前の Lambda 関数は、特定の Amazon S3 バケットに保存されているJSONファイルの内容pass-large-payloadを読み込みます。

import json
import boto3
import io
import os

s3 = boto3.client('s3')

def lambda_handler(event, context):
    event = event['Input']
    final_json = str()
    
    s3 = boto3.resource('s3')
    bucket = event['bucket'].split(':')[-1]
    filename = event['key']
    directory = "/tmp/{}".format(filename)
    
    s3.Bucket(bucket).download_file(filename, directory)
    
    with open(directory, "r") as jsonfile:
    
        final_json = json.load(jsonfile)
    
    os.popen("rm -rf /tmp")
    
    return final_json

ステートマシンを作成する

次のステートマシンは、以前に作成した Lambda 関数を呼び出します。

{  
   "StartAt":"Invoke Lambda function",
   "States":{  
      "Invoke Lambda function":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke",
         "Parameters":{  
            "FunctionName":"arn:aws:lambda:us-east-2:123456789012:function:pass-large-payload",
            "Payload":{  
               "Input.$":"$"
            }
         },
         "OutputPath": "$.Payload",
         "End":true
      }
   }
}

入力に大量のデータを渡すのではなく、そのデータを Amazon S3 バケットに保存し、 Payloadパラメータでバケットの Amazon リソースネーム (ARN) を渡して、バケット名とキー値を取得できます。その後、Lambda 関数はこれを使用してデータに直接ARNアクセスできます。次に示しているステートマシン実行の入力例では、データが amzn-s3-demo-large-payload-json という名前の Amazon S3 バケット内の data.json に保存されています。

{
  "key": "data.json",
  "bucket": "arn:aws:s3:::amzn-s3-demo-large-payload-json"
}

Step Functions の履歴クォータに達しないように新しい実行を開始する

AWS Step Functions の実行イベント履歴には、25,000 エントリのハードクォータがあります。実行イベントが 24,999 件に達すると、次のイベントが発生するまで待機します。

長時間の実行でこのクォータに達しないようにするには、次のいずれかの方法を試行できます。

一時的な Lambda サービスの例外を処理する

AWS Lambda は、一時的なサービスエラーが発生することがあります。この場合、Lambda を呼び出すと、ClientExecutionTimeoutException、ServiceException、AWSLambdaException、または SdkClientException などの 500 エラーが生じます。ベストプラクティスとしては、Lambda 関数を呼び出す Retry、あるいはエラーを Catch するために、ステートマシンでのこのような例外を事前に処理します。

Lambda エラーは、Lambda.ErrorName として報告されます。Lambda サービス例外エラーを再試行するには、次の Retry コードを使用します。

"Retry": [ {
   "ErrorEquals": [ "Lambda.ClientExecutionTimeoutException", "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException"],
   "IntervalSeconds": 2,
   "MaxAttempts": 6,
   "BackoffRate": 2
} ]

詳細については、次を参照してください。

アクティビティタスクのポーリング時のレイテンシーの回避

GetActivityTask API は、 を 1 回taskTokenだけ提供するように設計されています。 アクティビティワーカーと通信している間に taskToken がドロップされた場合、GetActivityTask がタイムアウトするまで、レスポンスの待機のため複数の GetActivityTask リクエストが 60 秒ブロックされます。

レスポンス待ちのポーリングが少数しかない場合、ブロックされたリクエストの後ろにすべてのリクエストが追加され、停止する可能性があります。ただし、各アクティビティの Amazon リソースネーム (ARN) に対して未処理のポーリングが多数あり、リクエストの一部が待機中に停止している場合、 を取得taskTokenして作業の処理を開始できるポーリングはさらに多くなります。

本番稼働システムでは、各時点でアクティビティ の ARNごとに少なくとも 100 のオープンポーリングをお勧めします。1 つのポーリングがブロックされ、それらのポーリングの一部がその後ろに並んでいる場合、GetActivityTask のリクエストがブロックされている間に処理を実行するための taskToken を受け取るさらに多くのリクエストがあります。

タスクのポーリング時に、これらのレイテンシーの問題を回避する方法。

アクティビティおよびアクティビティワーカーの詳細については、Step Functions のアクティビティについて説明します。 を参照してください

CloudWatch ログリソースポリシーのサイズ制限

ログ記録を使用してステートマシンを作成する場合、または既存のステートマシンを更新してログ記録を有効にする場合、Step Functions は指定したロググループで CloudWatch Logs リソースポリシーを更新する必要があります。 CloudWatch Logs リソースポリシーは 5,120 文字に制限されています。

CloudWatch Logs は、ポリシーがサイズ制限に近づいていることを検出すると、 で始まるロググループのログ記録 CloudWatch を自動的に有効にします/aws/vendedlogs/。

CloudWatch Logs リソースポリシーのサイズ制限を回避/aws/vendedlogs/するために、Logs CloudWatch ロググループ名の前に を付けることができます。Step Functions コンソールでロググループを作成する場合、推奨されるロググループ名には、既に というプレフィックスが付けられます/aws/vendedlogs/states。

CloudWatch ログには、アカウントごとにリージョンごとに 10 個のリソースポリシーのクォータもあります。アカウントのリージョンに 10 CloudWatch Logs リソースポリシーがすでにあるステートマシンでログ記録を有効にしようとすると、ステートマシンは作成または更新されません。引用符のログ記録の詳細については、CloudWatch 「ログクォータ」を参照してください。

ログを CloudWatch ログに送信できない場合は、「」を参照してくださいTroubleshooting state machine logging to CloudWatch Logs。ログ記録全般の詳細については、「 からのログ記録を有効にする」を参照してください。 AWS のサービス。