[レポート] Deep Dive on AWS Lambda durable functions #CNS380 #AWSreInvent

セッションの概要

AWS Lambda durable functions enhances Lambda's programming model to simplify building fault-tolerant applications using familiar programming language patterns in JavaScript, TypeScript, or Python. We'll explore new capabilities that simplify failure handling through built-in retry mechanisms, efficient handling of human-in-the-loop interactions, and state management to track progress. Through an interactive demo, you'll see how to get started with Lambda durable functions in your IDE, and use primitives like “steps” and “waits” for state management, failure handling, and seamless execution of long-running business logic. Leave equipped to leverage durable functions for your next project, simplifying architectures and deliver fault-tolerant applications faster.

[機械翻訳]
AWS Lambda durable functions は、JavaScript、TypeScript、または Python の使い慣れたプログラミング言語パターンを使用して、フォールトトレラントなアプリケーションの構築を簡素化するために、Lambda のプログラミングモデルを強化します。組み込みのリトライメカニズムによる障害処理の簡素化、人間参加型 (human-in-the-loop) インタラクションの効率的な処理、進捗を追跡する状態管理といった新機能を探求します。インタラクティブなデモを通じて、IDE 内で Lambda durable functions を開始する方法、そして状態管理、障害処理、長時間実行されるビジネスロジックのシームレスな実行のために「ステップ」や「待機」といったプリミティブを使用する方法を実際にご覧いただけます。次のプロジェクトで durable functions を活用し、アーキテクチャを簡素化し、フォールトトレラントなアプリケーションをより迅速に提供するための知識を持ち帰ってください。

• Type: Breakout session
• Level: 300 – Advanced
• Features: Lecture-style
• Topic: Serverless & Containers
• Area of Interest: Event-Driven Architecture, Lambda-Based Applications, Serverless
• Role: Developer / Engineer, DevOps Engineer, Solution / Systems Architect
• Services: AWS Lambda

モノリスとマイクロサービス

モノリスとマイクロサービスを比較し、どちらが優れているのかと考えたことがある開発者は少なくないはずです。実際にはどちらにもメリットとデメリットが存在します。

セッションでは、「開発者はモノリスのように開発して、マイクロサービスとしてデプロイしたいという思いがある」と説明されました。
昔ながらの単一のアプリケーション開発を求めていますが、同時に認知的負荷なしで疎結合なアーキテクチャを使いたい、という意味です。

そこで Durable Functions が登場してくるわけですが、マイクロサービスのメリットを維持しつつ、モノリスのような単一アプリケーション開発体験を取り戻すためのミッシングリンクである、というコンセプトで紹介されました。

AWS Lambda durable functions

Durable Functions を構成する主な仕組みとして 3 つのポイントが紹介されました。

• Checkpoint: イベントハンドラが実行される際、進行状況を永続化
• Replay: 一時停止や障害からの復帰時に、すでに完了した作業をスキップするためのメカニズム
• SDK: Checkpoint や Replay などの低レベルな処理を開発者が意識せずに済むよう抽象化

以下、スライドが若干見えにくいですが、実際のコードを例に説明されました。

context.step

このブロックで囲まれた処理が完了すると、進行状況が保存されます。DynamoDB への書き込み処理などが実装例としてあげられています。

context.parallel

名前の通りですが、複数の独立したタスクを効率的に実行するための機能です。スライドは、別々の API リクエストを、直列ではなく並列に実行して時間を短縮しようとする実装例になります。

context.waitForCallback

この関数が呼ばれると Lambda は完全に停止し、課金も停止します。再開に必要なコールバック ID が生成されるので、外部システムなどはこの ID を使って API を呼び出し、処理を再開させることになります。

実装時の注意事項

UUID 生成、ランダム値、現在時刻取得などは、必ず step の中で行う必要があるとのことでした。replay 時に値が変わってしまい、整合性が取れなくなるためです。step の中で実行することで、replay の際に同じ値が再利用されます。

セッションでは、replay の整合性を保つため、$LATEST の使用は避け、バージョン発行やエイリアスの使用が推奨されていました。これにより、再実行時に同じコードロジックが適用されることが保証されます。

Step Functions との使い分け

似たようなサービスとして Step Functions を思い浮かべた方もいらっしゃると思います。では、どちらを選択すれば良いのでしょうか。

登壇者の方は「開発者の好み」が選択の重要な要素だと述べられていました。
セッションでは、コードベースのアプローチを好む開発者には Durable Functions が、ビジュアルなワークフロー定義を好む開発者には Step Functions が向いているのではないかと説明されていました。

とは言え、サービスが主眼にしているポイントはそれぞれ異なるので、丁寧に比較して適切に技術選定することが重要です。

おわりに

個人的に気になっていたアップデートに早速 Deep Dive することができました。
開発の幅は確実に広がったと思いますので、どのようなユースケースが適しているのかを今から考えておきたいところです。