StepFunctionのTimeoutSecondsについて

-

StepFunctionsの state machineのテンプレートにはTimeoutSecondsという設定を設定できます。

https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/sfn-stuck-execution.html

ここでは、StatesのTaskでTimeoutSecondsを指定していますが、States外でもTimeoutSecondsを指定できることがわかりました。ただ、自分が想定した動作とちょっと違ったです。

 

最初に想定していた動作

  • Statesの外でTimeoutSecondsを指定している場合は、各TaskのDefaultのTimeoutSeconds設定で動作する

    • なので、TaskにTimeoutSecondsが書かれてなくでも指定された時間にタイムアウトが起きる

  • 両方書かれている場合は、Task内の時間が優先される

     

実際の動作

動作確認コート

以下のようなStepFuncionsのState machine定義があるとします。

{
  "Comment": "A Hello World example of the Amazon States Language using Pass states",
  "StartAt": "Invoke_Lambda1",
  "TimeoutSeconds": 100,
  "States": {
    "Invoke_Lambda1": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "arn:aws:lambda:us-east-1:XXXXXXXXXXXX:function:myTestFunction:$LATEST",
        "Payload": {
          "Input.$": "$"
        }
      },
      "Next": "Invoke_Lambda2",
      "TimeoutSeconds": 60
    },
    "Invoke_Lambda2": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters": {
        "FunctionName": "arn:aws:lambda:us-east-1:XXXXXXXXXXXX:function:myTestFunction:$LATEST",
        "Payload": {
          "Input.$": "$",
          "TaskToken.$": "$$.Task.Token"
        }
      },
      "End": true
    }
  }
}

  • Statesの外のTimeoutSecondsは100秒に設定

  • ２つのLambda関数Task(同じ関数だけど)が実行される

    • Invoke_Lambda1はTimeoutSecondsが60秒

    • Invoke_Lambda2はTimeoutSecondsは未設定で、waitForTaskTokenで実行したままTokenが返ってくるまで待つので、ずっと実行されている状態になる

      • 最終的にこのState machineの実行がTimeoutになる

       

結果

例えば、Invoke_Lambda1の実行に50秒かかりました。Invoke_Lambda2でTimeoutされるのは何秒になるんでしょうか。想定なら50秒+100秒(未設定のTaskにデフォルトで適用)で150秒なると思っていました。

しかし、実際に実行してみると上記のState machineを実行すると100秒でTimeoutになります。Stateの外に書くTimeoutSecondsはState machineの全体の実行時間を指していることがわかりました。まあ、よく考えるとデフォルト値よりは全体の実行時間と思うのが自然な気がしますね…。

 

まとめ

  • StepFuncionsのTimeoutSecondsはStatesの外とStatesのTaskの中に書ける

    • Statesの外に書くTimeoutSecondsはState machineの全体の実行時間を指す
    • Taskの中に書くTimeoutSecondsはTaskの実行時間を定義する

  • Taskに何も書かないとずっと実行中でタスクの終了を待つことになる

 

蛇足

Popular Posts

CloudWatch EventsはAmazon EventBridgeになるらしい

-
イメージ
まえおき 　最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。 グーグル翻訳先生に翻訳をお願いすると CloudWatch Events is now Amazon EventBridge Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications. CloudWatch EventsがAmazon EventBridgeになりました Amazon EventBridge（以前のCloudWatch Events）は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。 らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。( Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合 )   Cloudwatch EventsとAmazon EventBridgeの違い 　全く同じサービスであるというと若...
続きを読む

PythonのDict型をDynamoDB形式のJsonに変換する

-
pythonでDynamoDB関連操作をするとき、難しい点の一つは一つは以下のようなDynamoDBの独特なJSON形式だと思います。 { "id": { "N": 12345 }, "name": { "S": "TanakaTaro" } } Python用のAWS SDKであるBoto3にはDynamoDB形式のJsonをPythonのDictに変換できる TypeSerializer と TypeDeserializer があります。 https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html TypeSerializer PythonのDictをDynamoDB形式のJsonに変換します。個人的には変換結果で最初の{"M": ...}はなくしてほしいですが… TypeDeserializer DynamoDB形式のJsonをPythonのDictに変換します。こちらも一気に変換はできず、各Keyごとに変換が必要です。 まとめ＆蛇足 TypeSerializerとTypeDeserializerはDynamoDBのデータをpythonで処理したいときや処理後にまたDynamoDBにアップロードしたいときに有効に利用できそうです。 ただ、そのまま利用するよりは、利用しやすくカスタム関数やクラスを作成したほうがよさそうです。 JavaScriptのSDKにもConverterというものがあるようです https://aws.amazon.com/jp/blogs/developer/announcing-the-amazon-dynamodb-document-client-in-the-aws-sdk-for-javascript/
続きを読む

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった

-
イメージ
まえおき 今週あったチーム先輩(Aさん)との会話 私　：CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。 　　　これが私がCDKを押す理由の一つなんですよ。 Aさん：LambdaみたいにS３バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私　：あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん：うん?これでできないんだけ？(CloudFormationのドキュメントURLを共有) 私　：できるじゃん!? 　送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備 　State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)   　jsonファイルで保存し、S3のバケットに保存する。 　これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備 　 CloudFormationの StepFunctions::StateMachi...
続きを読む