AWS Step FunctionsとAWS Lambdaの使い分け

summary

AWS Step Functionsはワークフロー処理を実装してくれるサービスです。個人的にもAWS Step Functionsは大好きなサービスです。例えばSAGAパターンを利用して決済処理や予約システムのトランザクションを実装したり、ビッグデータのETLなんかにも使用することが出来ます。一方でシンプルなワークフローに対してはAWS Lambdaのみで実装してしまった方がコストや実装スピードの面でメリットが有る場合もあるでしょう。本記事ではそれらの使い分けやメリット、デメリットについて解説しています。

AWS Step Functionsで実装するためには、Amazon State Languageなどの新たな学習コスト、AWSサービス自体のコストへの考慮、StandardモードかExpressモードのどちらを使うかの判断、更には様々なStep Functions サービスクォータへの対処など実装における複雑性は増すといっていいでしょう。しかし、それでもAWS Step Functionsでワークフローを実装するビジネス上のメリットはたくさんあります。まずはAWS Lambdaのみでワークフローを実装していく場合のメリット見てみます。

AWS Lambdaのみで実装した場合のメリット

例えば以下のようなワークフローの処理をAWS Lambdaで書いたとします。AWSにそこまで詳しくないデベロッパーにとってはAWS Step Functionsの固有の仕様や実装方法を覚える必要がないため、シンプルに実装を進めることができるのではないでしょうか。また、コスト面に置いてもLambda Function単体にかかるコストのみを考慮すればよいため、AWS Step Functionsを使った場合に比べると安く済みます。サービスクオータも基本的にはAWS Lambdaの同時実行数やLambdaファンクションの15分の実行時間制限あたりのみを考慮すれば問題が無いでしょう。

そこまで大掛かりにならないような小規模なワークフローであれば、AWS Lambdaのみで実装してしまう方がコストや効率の面でメリットがあります。

exports.hello = async (event) => {
  try {
    // 初期化処理
    await doInitialization()

    // 分岐処理
    if (event.flag !== true) {
      return await stopProcess()
    } 
 
    // Map処理
    await Promise.all(
      event.records.map(async (record) => {
        await putDynamoDbTable(record)
      })
    )

    // 通知
    await sendSns()
     
  } catch (error) {
    // エラーハンドリング
  }
};

AWS Step Functionsのメリット

では、どういったケースでAWS Step Functionsを選択していけばよいのでしょうか。ビジネスにとって重要かつ複雑なワークフローをチームで実装するのであれば、AWS Step Functionsを使う価値は十分にあるでしょう。AWS Lambda単体に比べるとコストは掛かります。しかし、以下で説明するメリットを考えると、結果的にAWS Step Functionsの方がトータルで効率的になるケースが多いです。以下、そのメリットを見ていきましょう

認知負荷が軽減される

上記、AWS Lambdaで実装した処理と同様の処理をAWS Step Functionsで実装すると以下のようなワークフローになります。私自身がAWS Step Functionsを好きな理由の一つはこのようにビジュアルでワークフローが可視化され、ワークフローを理解するための認知負荷が非常に低いことです。すべての実行履歴（いつ状態が開始されたか、入力と出力、エラーメッセージやスタックトレースなど）は追跡可能なため、開発時や運用時のデバッグも非常に容易です。システムエラーが発生した際にもプログラムを専門としないプロダクトオーナーやプロジェクトオーナーの観点でも何が発生しているのかを理解しやすく、顧客への原因の説明などもやりやすいものになるでしょう。

ほぼすべてのAWSサービスと接続できる

現時点でほぼすべてのAWSサービスをAWS Step Functionsのステート(状態)に設定することが可能です。毎回AWS Lambdaを挟む必要がなくなる分、シンプルになりますし、コールドスタートの考慮をする必要がなくなります。また、コスト面でもAWS Step Functionsは100万回の状態遷移で25ドルかかります。この表現だけだとなかなか分りづらいかもしれませんが、サーバレスなAWSサービスの中でもコストが高めのサービスと言えるでしょう。AWS Lambdaと組み合わせて使う場合にはAWS LambdaのコストとAWS Step Functionsのコストを合計で考える必要がありましたが、できる限りLambdaファンクションレスでAWS Step Functionsを実装することでコストを最小限に抑えることが出来ます。

長時間の実行が可能

AWS Step Functionsのスタンダードモードで最長1年間のワークフローの実行が可能です。AWS Lambdaで実装する際には15分の実行時間を考慮する必要がありましたが、基本的にそれらは不要になります。課金自体も状態遷移数に対する課金になり、ワークフローの実行時間に対しては課金されないため、待機処理をするにはとても都合が良いでしょう。例えば、コールバックパターンを使用することで人間の入力を待ってワークフローの続きを実行させることが出来ます。

例えば、会員登録などでユーザにメールが送信されて、メール中のリンクをクリックすることで登録が完了するといった仕組みがよくありますが、これもコールバックパターンを利用することで実装可能です。

エラーハンドリングが強力

AWS Step Functionsを使うとエラー時に遷移させたいステートやその入力データを指定したり、リトライの回数や待ち時間などの条件を細かく指定することが可能になります。これらをAWS Lambdaのtry-catchだけで実装するとなるとかなり複雑でメンテナンスの難しいロジックになるでしょう。例えば、購買・予約システムや決済システムを実装する際にはデータや決済に不整合が発生しないようにエラーハンドリングを実装する必要があります。決済処理は成功したが購買処理は失敗してしまったなどの実装になっているとビジネスにとっては致命的です。このような場合にもAWS Step Functionsのエラーハンドリングの機能をうまく使って実装を行なうことで不整合を発生させないワークフローの構築が可能となります。

AWS Step Functionsのデメリット

やはり、コストが高いのが一番のデメリットでしょう。また、ステートにAWS Lambdaを使用した場合にはLambda ファンクション内のビジネスロジックとAWS Stap FunctionsのASLによる設定が分離されるため、その可読性は複雑なものになってしまいます。また、AWS Lambdaと使用する場合には両方のサービスクォータ及びコストについての考慮が必要になります。

まとめ

結論として、AWS Step Functionsは豊富な機能と強力なワークフローのビジュアルを提供しますが、独自の複雑さとコストも伴います。ひとつの判断基準としては、ビジネスにおけるそのワークフローの重要度や複雑度がポイントになってくるのではないかと思います。多人数でのメンテを必要としないようなシンプルなワークフローはサクッとLambda関数で実装してしまえばよいでしょう。

一方で、ビジネスにとって重要なワークフローにはAWS Step Functionsを強く推奨します。視覚化、監査記録、強力なエラーハンドリングの利点は、リスクの高いワークフローに合致しています。たとえば、既に紹介したような予約や在庫、支払い処理が絡むようなワークフローは、その重要性からStep Functionsへの投資への費用対効果はあると考えてよいでしょう。

その他にもワークフローに人間の意思決定が必要な場合は、独自で実装を行なうよりもAWS Step Functionsのコールバックパターンを活用すべきです。また、同様に、失敗したステートから再開することが重要なワークフローの場合も、AWS Step Functionsが適しているでしょう。