7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 19

KDDI エンジニア＆デザイナー Advent Calendar 2025

@m-iwasaki(Masahiro Iwasaki)inKDDI株式会社

AWS Lambda Durable Functions の「最大１年間実行可能」を正しく理解する

7
Last updated at Posted at 2025-12-18

はじめに

re:Invent 2025 にて、AWS Lambda Durable Functions がリリースされました。機能説明の中で「最大 1 年間実行可能」という表現があり、注目された方も多いのではないでしょうか。

AWS の公式ドキュメントでは、Durable Functions について次のように説明されています。

Lambda durable functions enable you to build resilient multi-step applications and AI workflows that can execute for up to one year while maintaining reliable progress despite interruptions. When a durable function runs, this complete lifecycle is called a durable execution, which uses checkpoints to track progress and automatically recover from failures through replay, re-executing from the beginning while skipping completed work.

「最大 1 年間実行可能」という言葉だけを見ると、Lambda の 実行時間 15 分制限が拡張されたようにも見えますが、実際には少し意味が異なります。

本記事では、Durable Functions の timeout / checkpoint / replay の考え方を整理します。

Lambda Durable Functions とは

Lambda Durable Functions は、通常の Lambda と同じイベントハンドラの形を保ちつつ、checkpoint / replay によって「途中まで進んだ状態」を安全に保持し、失敗や待機から復帰できるようにする仕組みです。

ポイント

  • Steps
    context.step() で囲った処理は、成功すると チェックポイント化 され、
    再開時（replay）には 再実行されず、保存済みの結果が再利用 されます。

  • Wait
    context.wait() を使うことで安全に中断でき、
    待機中は Lambda が実行されないため、Lambda の実行時間課金は発生しません。

つまり、Durable Functions は
「長時間 CPU を回し続けるための機能」ではなく、
「長期間にわたる業務フロー（待ちが多い処理）を安全に進めるための機能」
と言えます。

Durable Functions の 2 種類の Timeout

Durable Functions を理解するうえで重要なのが、Timeout が 2 種類ある点です。

Lambda Function Timeout

  • 単一の Lambda 実行に対する制限
  • 最大 15 分
  • Durable execution を有効化しても この制限は変わりません

Durable Execution Timeout

  • Durable ワークフロー全体（開始〜終了）に対する制限
  • 最大 366 日（約 1 年）
  • wait による待機時間も含まれます

Durable execution を ON にしても Lambda 自体の 15 分制限はそのまま です。
“最大 1 年” というのは、ワークフロー全体のライフサイクル上限を指しています。

Durable Functions の checkpoint / replay

Durable Functions では、待機やリトライなどから再開する際に replay が行われます。

replay の特徴

  • コードは 先頭から再実行されるように見える
  • ただし、完了済みの step（チェックポイント済み） はスキップされ、保存済みの結果が返される

この仕組みにより、開発者は「上から順にコードを書いているだけ」でも、内部的には耐障害性の高いワークフローを実現できます。

サンプルコード（Python）

ここから、Durable Functions の 最も基本的な使い方として、

  • context.step() によるチェックポイント化
  • context.wait() による安全な待機・再開

を公式の Python SDK サンプルに沿った形で見ていきます。

from aws_durable_execution_sdk_python import (
    DurableContext,
    durable_execution,
    durable_step,
)
from aws_durable_execution_sdk_python.config import Duration

@durable_step
def validate_order(step_context, order_id):
    step_context.logger.info(f"Validating order {order_id}")
    return {"orderId": order_id, "status": "validated"}

@durable_step
def process_payment(step_context, order_id):
    step_context.logger.info(f"Processing payment for order {order_id}")
    return {"orderId": order_id, "status": "paid", "amount": 99.99}

@durable_step
def confirm_order(step_context, order_id):
    step_context.logger.info(f"Confirming order {order_id}")
    return {"orderId": order_id, "status": "confirmed"}

@durable_execution
def lambda_handler(event, context: DurableContext):
    order_id = event["orderId"]

    # Step 1: Validate order
    validation_result = context.step(validate_order(order_id))

    # Step 2: Process payment
    payment_result = context.step(process_payment(order_id))

    # Wait for 10 seconds to simulate external confirmation
    context.wait(Duration.from_seconds(10))

    # Step 3: Confirm order
    confirmation_result = context.step(confirm_order(order_id))

    return {
        "orderId": order_id,
        "status": "completed",
        "steps": [validation_result, payment_result, confirmation_result],
    }

Durable Execution を有効化すると、Lambda ハンドラは @durable_execution でラップされ、context として DurableContext が渡されます。各処理は @durable_step で定義しておくと、context.step(...) で実行した際に チェックポイント化され、replay（再開）時に結果が再利用される前提の書き方ができます。

コードのポイント

  • @durable_step + context.step()
    step は完了すると結果が保持され、replay 時に再利用されます。そのため、順番に書いているだけでも checkpoint/replay に適した構造になります。

  • context.wait()
    単なる sleep ではなく、安全に中断・再開できる待機です。これにより、長期間にわたる業務フローが成立します。

冪等性と副作用に注意する

Durable Functions の replay は強力ですが、裏返すと 意図しない再実行 が起こり得ます。

たとえば以下のような処理を step の外で行うと、

  • DynamoDB への書き込み
  • 外部 API リクエスト
  • S3 への put

replay 時に 再度実行される可能性があります。

そのため原則として、

  • 副作用のある処理は context.step() に閉じ込める
  • 外部システム連携は冪等性を前提に設計する

ことが重要です。

具体的には、

  • idempotency key を使う
  • 「処理済みかどうか」を DB で管理する
  • 外部 API が冪等 API を提供している場合は利用する

といった、従来の分散システム設計が有効になります。

replay はログ上でどう見えるか

Durable Functions を初めて触ると、CloudWatch Logs を見たときの挙動に少し戸惑うことがあります。なぜなら、Durable Functions では replay（再実行）時にもコードが先頭から走るため、ログ上では「同じ処理が何度も実行されている」ように見えるからです。

ログの見え方

先ほどのサンプルコードを例に、以下のようなログが出力されるとします。

INFO Validating order order-123
INFO Processing payment for order order-123

ここで context.wait() によって一度処理が中断され、10 秒後に再開されると、replay によりコードは先頭から再実行されます。その結果、CloudWatch Logs には次のように見える場合があります。

INFO Validating order order-123
INFO Processing payment for order order-123
INFO Confirming order order-123

一見すると、validate / payment がもう一度実行されているように見えますが、実際には再実行されていません。

なぜこのようなログになるのか

Durable Functions の replay では、

  • コードは 先頭から評価される
  • ただし 完了済みの step はスキップされ、保存済みの結果が返る

という挙動を取ります。

つまり、validate_order、process_paymentの中身は 再実行されていないものの、context.step(...) の呼び出し自体は評価されるため、step 内で出力したログが再度表示されることがあります。これはバグや二重実行ではなく、Durable Functions の設計通りの挙動です。

replay を前提にしたログ設計のポイント

この特性を理解していないと、

  • 「同じ処理が二重に実行されているのでは？」
  • 「決済が2回走っていないか？」

と不安になります。

そのため、以下のような工夫をしておくと安心です。

1. 副作用のあるログは step 内に閉じ込める

外部 API 呼び出しや DB 更新と同様に、重要なログも step 内で出力することで、

  • replay 時は「結果が再利用されている」ことが前提になる
  • step 外のログと混ざりにくくなる

というメリットがあります。

2. replay 中かどうかを意識する

Durable SDK では、step_context や context から「今が replay 中かどうか」を判別できる情報が提供されています。これを使うと、

if not step_context.is_replaying:
    step_context.logger.info("Processing payment...")

のように、replay 時のログ出力を抑制することも可能です。

replay を理解すると見えてくる Durable の設計思想

このログ挙動を理解すると、Durable Functions が

  • 「Lambda を長時間動かす仕組み」ではなく
  • 「何度再開しても同じ結果に収束するワークフロー」

を目指して設計されていることが分かります。

その代わりに、

  • ログは replay を前提に読む
  • 副作用は step に閉じ込める
  • Exactly once を期待しない

といった 分散システム的な思考が求められます。

Step Functions との使い分け

Durable Functions は「コードで書けるワークフロー」であるため、Step Functions と比較されることが多いですが、両者は競合というより補完関係です。

Durable Functions が向いているケース

  • 複雑な条件分岐を コードで自然に 書きたい
  • 人待ち・外部イベント待ちが多い（wait が活きる）
  • AI ワークフローなど、途中で止まりやすい処理

Step Functions が向いているケース

  • 状態遷移を可視化して運用したい
  • サービス連携を明示的に管理したい
  • ワークフローを定義として管理したい（変更管理・監査）

個人的には、

  • 開発者が書き切りたい複雑ロジック → Durable Functions
  • 運用者が見る必要があるフロー → Step Functions

という線引きがしっくり来ています。

まとめ

Lambda Durable Functions は、

  • 「Lambda を 1 年実行できる」機能ではなく
  • 「最大 1 年、状態を保持しながらワークフローを進められる」機能

です。

  • Durable execution を有効化しても Lambda の 15 分制限はそのまま
  • “最大 1 年” は Durable ワークフロー全体のライフサイクルの話
  • context.step() と context.wait() を正しく使うことで、checkpoint / replay による堅牢な長期フローが書ける
  • 冪等性と副作用の扱いが設計上の重要ポイント
7
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?