翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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 ワークフローに変換できます。
-
ワークフローは 5 分以内に実行を完了する必要があります。
-
ワークフローはat-least-once実行モデルに準拠しています。つまり、ワークフローの各ステップは 1 回以上実行される可能性があるということです。
-
ワークフローは
.waitForTaskToken
または.sync
のサービス統合パターンを使用しません。
重要
Express ワークフローは Amazon CloudWatch Logs を使用して実行履歴を記録します。 CloudWatch Logs を使用すると、追加料金が発生します。
コンソールを使用して標準ワークフローを Express ワークフローに変換するには
-
Step Functions コンソール
を開きます。 -
[ステートマシン] ページで、標準タイプのステートマシンを選択して開きます。
ヒント
[すべてのタイプ] ドロップダウンリストから [標準] を選択すると、ステートマシンのリストがフィルタリングされ、標準ワークフローのみが表示されます。
-
[新規にコピー] を選択します。
デザインモード で Workflow Studio が開き、選択したステートマシンのワークフローが表示されます。
-
(オプション) ワークフローのデザインを更新します。
-
ステートマシンの名前を指定します。これを行うには、デフォルトのステートマシン名 の横にある編集アイコンを選択しますMyStateMachine。次に、[ステートマシンの設定] の [ステートマシン名] ボックスに名前を指定します。
-
(オプション) [ステートマシンの設定] で、ステートマシンのタイプや実行ロールなど、他のワークフロー設定を指定します。
[タイプ] では必ず [Express] を選択してください。[ステートマシンの設定] のその他のデフォルト設定をすべてそのまま使用します。
注記
で以前に定義した標準ワークフローを変換する場合 AWS CDK または AWS SAMでは、
Type
とResource
の名前の値を変更する必要があります。 -
[ロールの作成を確認] ダイアログボックスで、[確認] を選択して続行します。
[ロールの設定を表示] を選択して [ステートマシンの設定] に戻ることもできます。
注記
Step Functions が作成するIAMロールを削除した場合、Step Functions は後で再作成できません。同様に、ロールを変更した場合 (IAMポリシー内のプリンシパルから Step Functions を削除した場合など)、Step Functions は後で元の設定を復元できません。
ワークフローのコスト最適化を管理する際のベストプラクティスとガイドラインの詳細については、「費用対効果の向上」を参照してください。 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 リソースの目的を表すタグを追加できます。
リソース | キー | 値 |
---|---|---|
StateMachine1 |
Cost Center |
34567 |
Application |
Image processing |
|
StateMachine2 |
Cost Center |
34567 |
Application |
Rekognition processing |
セキュリティのためのタグ付け
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 ドキュメントの タスクワークフローの状態 を参照してください。
注記
Amazon States Language の定義の TimeoutSeconds
フィールドを使用してステートマシンのタイムアウトを設定できます。詳細については、「Step Functions ワークフローの 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
注記
この Lambda 関数を作成したら、そのIAMロールに Amazon S3 バケットから読み取るための適切なアクセス許可を付与してください。例えば、Lambda 関数のロールに AmazonS3ReadOnlyAccess アクセス許可をアタッチします。
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アクセスできます。次に示しているステートマシン実行の入力例では、データが
という名前の Amazon S3 バケット内の amzn-s3-demo-large-payload-json
data.json
に保存されています。
{
"key": "data.json",
"bucket": "arn:aws:s3:::amzn-s3-demo-large-payload-json
"
}
Step Functions の履歴クォータに達しないように新しい実行を開始する
AWS Step Functions の実行イベント履歴には、25,000 エントリのハードクォータがあります。実行イベントが 24,999 件に達すると、次のイベントが発生するまで待機します。
-
イベント番号 25,000 が
ExecutionSucceeded
の場合、実行は正常に終了します。 -
イベント番号 25,000 が
ExecutionSucceeded
以外の場合、ExecutionFailed
イベントはログに記録され、履歴の上限に達したためステートマシンの実行は失敗します。
長時間の実行でこのクォータに達しないようにするには、次のいずれかの方法を試行できます。
-
マップステートを分散モードで使用します。このモードでは、
Map
状態は各反復を子ワークフロー実行として実行します。これにより、最大 10,000 件という高い並列性を持つの並列子ワークフロー実行が可能になります。それぞれの子ワークフローの実行には、親ワークフローとは別の実行履歴があります。 -
進行中の実行の
Task
状態から、新しいステートマシンを直接実行します。このようなネストされたワークフロー実行を開始するには、必要なパラメータとともに親ステートマシンで Step Functions のStartExecution
APIアクションを使用します。ネストされたワークフローの使用の詳細については、Step Functions でタスク状態からワークフロー実行を開始する「」または「Step Functions APIアクションを使用して新しい実行チュートリアルを続行する」を参照してください。ヒント
ネストされたワークフローの例を にデプロイするには AWS アカウント、「モジュール 13 - ネストされた Express ワークフロー
」を参照してください。 -
を使用するパターンを実装する AWS Lambda ステートマシンの新しい実行を開始して、進行中の作業を複数のワークフロー実行に分割できる 関数。詳細については、Lambda 関数を使用して Step Functions で新しい実行を継続する のチュートリアルを参照してください。
一時的な Lambda サービスの例外を処理する
AWS Lambda は、一時的なサービスエラーが発生することがあります。この場合、Lambda を呼び出すと、ClientExecutionTimeoutException
、ServiceException
、AWSLambdaException
、または SdkClientException
などの 500 エラーが生じます。ベストプラクティスとしては、Lambda 関数を呼び出す Retry
、あるいはエラーを Catch
するために、ステートマシンでのこのような例外を事前に処理します。
Lambda エラーは、Lambda.
として報告されます。Lambda サービス例外エラーを再試行するには、次の ErrorName
Retry
コードを使用します。
"Retry": [ { "ErrorEquals": [ "Lambda.ClientExecutionTimeoutException", "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException"], "IntervalSeconds": 2, "MaxAttempts": 6, "BackoffRate": 2 } ]
注記
Lambda での未処理のエラーは、エラー出力で Lambda.Unknown
として報告されます。これには、 out-of-memory エラーと関数のタイムアウトが含まれます。Lambda.Unknown
、States.ALL
、または States.TaskFailed
を一致させて、こういったエラーに処理できます。Lambda が最大呼び出し数に達すると、エラーは Lambda.TooManyRequestsException
となります。Lambda Handled
とUnhandled
エラーの詳細については、FunctionError
「」の「」を参照してください。 AWS Lambda デベロッパーガイド 。
詳細については、次を参照してください。
アクティビティタスクのポーリング時のレイテンシーの回避
GetActivityTask
API は、 を 1 回taskToken
だけ提供するように設計されています。 アクティビティワーカーと通信している間に taskToken
がドロップされた場合、GetActivityTask
がタイムアウトするまで、レスポンスの待機のため複数の GetActivityTask
リクエストが 60 秒ブロックされます。
レスポンス待ちのポーリングが少数しかない場合、ブロックされたリクエストの後ろにすべてのリクエストが追加され、停止する可能性があります。ただし、各アクティビティの Amazon リソースネーム (ARN) に対して未処理のポーリングが多数あり、リクエストの一部が待機中に停止している場合、 を取得taskToken
して作業の処理を開始できるポーリングはさらに多くなります。
本番稼働システムでは、各時点でアクティビティ の ARNごとに少なくとも 100 のオープンポーリングをお勧めします。1 つのポーリングがブロックされ、それらのポーリングの一部がその後ろに並んでいる場合、GetActivityTask
のリクエストがブロックされている間に処理を実行するための taskToken
を受け取るさらに多くのリクエストがあります。
タスクのポーリング時に、これらのレイテンシーの問題を回避する方法。
-
アクティビティワーカーの実装の作業とは別のスレッドとしてポーラーを実装します。
-
ARN 各時点で、アクティビティごとに少なくとも 100 件のオープンポーリングがあります。
注記
あたり 100 件のオープンポーリングへのスケーリングにはコストがかかるARN場合があります。例えば、 あたり 100 個の Lambda 関数のポーリングARNは、100 個のポーリングスレッドを持つ単一の Lambda 関数よりも 100 倍高価です。レイテンシーを短縮しながらコストを最小限に抑えるには、非同期 I/O を使用する言語により、ワーカーごとに複数のポーリングスレッドを実装します。ポーラースレッドとワークスレッドが異なるアクティビティワーカーの例については、例: Ruby のアクティビティワーカー を参照してください
アクティビティおよびアクティビティワーカーの詳細については、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 のサービス。