AWS Step Functionsを利用したことはありますか？

私はサービスが出てから使い所がよくわかっておらず利用を避けてきましたが、非同期処理のサービス呼び出しした後に待ち受けする処理をAWS Lambdaで実装しようとした際に苦慮したケースがありました。

そこで、AWS Certified Solutions Architect - Professionalにも出てくるAWS Step Functionsを利用すれば実現できるのではないかと思って実装してみると意外に簡単に実現できることがわかったのでその経験をまとめてみました。

AWS Step Functionsとは

AWS Step Functionsの紹介ページより

デベロッパーが AWS のサービスを利用して分散型アプリケーションを構築し、プロセスを自動化し、マイクロサービスのオーケストレーション、データと機械学習のパイプラインを構築できるようにするビジュアルワークフローサービスです。

実装してみた

今回実装したステートマシン図は以下の通りです。
EFSをマウントしている複数台のEC2で構成しているWebサーバに対して、転送元のS3のバケットよりデータを転送する仕組みをDataSyncを使って実現しており、データの転送を完了するとCloudFrontのキャッシュを削除するとともに完了通知をSNSを使って通知するというものです。
なお、このステートマシンは、EventBridgeルールにてS3のバケットにトリガーファイルを配置することにより起動されるようになっています。

実行結果は以下の通りで、状態遷移数は50でした。1ヵ月あたり4,000回の状態遷移まで無料なので、80回実行しても無料の計算になります。

(AWS Lambdaではなく)AWS Step Functionsで実装するメリット

今回の実装を通してAWS Step Functionsで実装するメリットを洗い出ししてみました。AWS Lambdaを使って他のAWSサービスを呼び出すことが多いと思いますが、（バッチ実行的な処理の場合には特に）まずはAWS Step Functionsで呼び出しできないかを先に検討した方が良いと考えます。

また、実行結果を見ると、私が過去オンプレミス環境で利用していた System WalkerやHinemosなど運用管理ソフトウエア(JP1も有名ですね)を彷彿とさせ、Amazon EventBridgeと連携させることで、運用管理の観点でも利用しやすい仕組みだと感じています。

• （サービスの呼び出しだけを行っているような実装であれば）AWS Lambdaにあるランタイムサポートに合わせてリファクタリングせずに済むようになる
• スロットリングの影響を軽減できる
• Lambdaにある15分の実行時間の制約を受けなくなる（個別に呼び出しが必要な箇所だけAWS Step Functionsで呼び出すことにより、呼び出し元の時間制限を受けずに済む）
• 実行状況がわかりやすい
• 並列処理などがやりやすくなる
• テスト状態という機能を使って各ステップごとの単体テストが容易