基本概念 - AWS Lambda

基本概念

Lambda は、JavaScript、TypeScript、Python に耐久性のある実行 SDK を提供します。これらの SDK は耐久性のある関数を構築するための基盤であり、進行状況のチェックポイント、再試行の処理、実行フローの管理に必要なプリミティブが提供されます。SDK の完全なドキュメントや例については、GitHub の「JavaScript/TypeScript SDK」および「Python SDK」を参照してください。

耐久性のある実行

耐久性のある実行は Lambda の耐久性のある関数における完全なライフサイクルを表し、チェックポイントおよび再生メカニズムを使用してビジネスロジックの進行状況を追跡し、実行を停止し、障害から復旧します。関数が停止または中断の後に再開すると、以前に完了したチェックポイントが再生されて、関数は実行を続行します。

ライフサイクルには、実行を完了するために Lambda 関数の複数の呼び出しが含まれる場合があります (特に停止または障害復旧の後)。このアプローチにより、中断しても信頼性の高い進行状況を維持しながら、関数を長期間 (最大 1 年) 実行できるようになります。

再生の仕組み

関数の実行時に、Lambda はすべての耐久性のあるオペレーション (ステップ、待機、その他のオペレーション) の実行ログを保持します。関数を一時停止する必要がある場合、または中断が発生した場合、Lambda によってこのチェックポイントログが保存されて実行が停止されます。再開すると、Lambda は最初から関数を再度呼び出し、チェックポイントログを再生し、保存された値を完了したオペレーションに置き換えます。つまり、コードが再度実行されますが、以前に完了したステップは再実行されません。代わりに保存された結果が使用されます。

この再生メカニズムは、耐久性のある関数を理解するために不可欠です。コードは再生中に決定的である必要があります。つまり、同じ入力で同じ結果が生成されます。副作用 (ランダムな数値の生成や現在の時刻の取得など) を伴う操作は、再生中に異なる値を生成し、非決定的な動作を引き起こす可能性があるため、ステップ外では避けてください。

DurableContext

DurableContext は、耐久性のある関数が受け取るコンテキストオブジェクトです。チェックポイントを作成して実行フローを管理するステップや待機など、耐久性のあるオペレーションの方法を提供します。

耐久性のある関数は、デフォルトの Lambda コンテキストではなく、DurableContext を受け取ります。

TypeScript
import { DurableContext, withDurableExecution, } from "@aws/durable-execution-sdk-js"; export const handler = withDurableExecution( async (event: any, context: DurableContext) => { const result = await context.step(async () => { return "step completed"; }); return result; }, );
Python
from aws_durable_execution_sdk_python import ( DurableContext, durable_execution, durable_step, ) @durable_step def my_step(step_context, data): # Your business logic return result @durable_execution def handler(event, context: DurableContext): result = context.step(my_step(event["data"])) return result

耐久性のある関数用 Python SDK によって同期メソッドが使用され、await はサポートされません。TypeScript SDK では async/await が使用されます。

Steps

ステップは、組み込みの再試行および自動チェックポイントでビジネスロジックを実行します。各ステップは結果を保存し、中断後に完了したステップから関数を再開できるようにします。

TypeScript
// Each step is automatically checkpointed const order = await context.step(async () => processOrder(event)); const payment = await context.step(async () => processPayment(order)); const result = await context.step(async () => completeOrder(payment));
Python
# Each step is automatically checkpointed order = context.step(lambda: process_order(event)) payment = context.step(lambda: process_payment(order)) result = context.step(lambda: complete_order(payment))

待機状態

待機状態は、継続する時間になるまで関数の実行が停止する (さらに課金を停止する) 計画された一時停止です。使用して期間、外部コールバック、特定の条件を待機します。

TypeScript
// Wait for 1 hour without consuming resources await context.wait({ seconds:3600 }); // Wait for external callback const approval = await context.waitForCallback( async (callbackId) => sendApprovalRequest(callbackId) );
Python
# Wait for 1 hour without consuming resources context.wait(3600) # Wait for external callback approval = context.wait_for_callback( lambda callback_id: send_approval_request(callback_id) )

関数で待機が発生した場合、または一時停止する必要がある場合、Lambda はチェックポイントログを保存して実行を停止します。再開する際、Lambda は関数を再度呼び出してチェックポイントログを再生し、保存された値を完了したオペレーションに置き換えます。

もっと複雑なワークフローの場合、耐久性のある Lambda 関数には高度なオペレーションも用意されています。これには、同時実行に parallel()、配列の処理に map()、ネストされたオペレーションに runInChildContext()、ポーリングに waitForCondition() などがあります。各オペレーションを使用するタイミングに関する詳細な例およびガイダンスについては、「」を参照してください。

他の関数の呼び出し

呼び出しにより、耐久性のある関数は他の Lambda 関数を呼び出して結果を待機できます。呼び出し元の関数は呼び出される関数の実行中に停止し、結果を保持するチェックポイントが作成されます。特殊な関数が特定のタスクを処理するモジュラーワークフローを構築できるようになります。

context.invoke() を使用して耐久性のある関数内から他の関数を呼び出します。呼び出しはチェックポイントされるため、呼び出される関数が完了した後に関数が中断された場合、関数を再呼び出しせずに、保存された結果で再開されます。

TypeScript
// Invoke another function and wait for result const customerData = await context.invoke( 'validate-customer', 'arn:aws:lambda:us-east-1:123456789012:function:customer-service:1', { customerId: event.customerId } ); // Use the result in subsequent steps const order = await context.step(async () => { return processOrder(customerData); });
Python
# Invoke another function and wait for result customer_data = context.invoke( 'arn:aws:lambda:us-east-1:123456789012:function:customer-service:1', {'customerId': event['customerId']}, name='validate-customer' ) # Use the result in subsequent steps order = context.step( lambda: process_order(customer_data), name='process-order' )

呼び出される関数は、耐久性のある Lambda 関数または標準の Lambda 関数のいずれかの場合があります。耐久性のある関数を呼び出した場合、呼び出し元の関数は完全な耐久性のある実行が完了するまで待機します。このパターンは各関数が特定のドメインを処理するマイクロサービスアーキテクチャで一般的であり、特殊で再利用可能な関数で複雑なワークフローを作成できます。

注記

クロスアカウントの呼び出しはサポートされていません。呼び出される関数は、呼び出し元の関数と同じ AWS アカウントに存在する必要があります。

耐久性のある関数の設定

耐久性のある関数には、実行動作およびデータ保持を制御する特定の構成設定があります。これらの設定は標準の Lambda 関数設定とは別で、耐久性のある実行ライフサイクルの全体に適用されます。

DurableConfig オブジェクトは、耐久性のある関数の設定を定義します。

{ "ExecutionTimeout": Integer, "RetentionPeriodInDays": Integer }

[Execution timeout] (実行タイムアウト)

実行タイムアウトは、耐久性のある実行を開始から完了まで実行できる期間を制御します。単一の関数の呼び出しが実行可能な時間を制御する Lambda 関数のタイムアウトとは異なります。

耐久性のある実行はチェックポイント、待機、再生を進行しながら、複数の Lambda 関数の呼び出しをまたくことがあります。実行タイムアウトは、個々の関数の呼び出しではなく、耐久性のある実行の合計経過時間に適用されます。

違いを理解する

Lambda 関数のタイムアウト (最大 15 分) は、関数の個々の呼び出しを制限します。耐久性のある実行タイムアウト (最大 1 年) は、実行の開始から完了、障害発生、タイムアウトまでの合計時間を制限します。この期間中、関数がステップを処理し、待機し、障害から復旧するとき、複数回呼び出されることがあります。

例えば、耐久性のある実行タイムアウトを 24 時間に設定して、Lambda 関数タイムアウトを 5 分に設定した場合、次の条件が該当します。

  • 各関数の呼び出しは 5 分以内に完了する必要があります

  • 耐久性のある実行全体は最大 24 時間実行できます

  • この 24 時間の期間中に関数を何度も呼び出すことができます

  • 待機オペレーションは Lambda 関数のタイムアウトにはカウントされませんが、実行タイムアウトにはカウントされます。

Lambda コンソール、AWS CLI、AWS SAM を使用して、耐久性のある関数を作成するときに実行タイムアウトを設定できます。Lambda コンソールで関数を選択したら [設定] を選択し、耐久性のある実行を選択します。実行タイムアウト値を秒単位で設定します (デフォルトで 86400 秒/24 時間、最小 60 秒、最大 31536000 秒/1 年)。

注記

実行タイムアウトおよび Lambda 関数タイムアウトは設定が異なります。Lambda 関数のタイムアウトは、個々の呼び出しを実行できる時間を制御します (最大 15 分)。実行タイムアウトは、耐久性のある実行全体の合計経過時間を制御します (最大 1 年)。

保持期間

保持期間は、耐久性のある実行が完了した後に Lambda が実行履歴およびチェックポイントデータを保持する期間を制御します。このデータにはステップ結果、実行状態、完全なチェックポイントログが含まれます。

保持期間が終了したら、Lambda は実行履歴およびチェックポイントデータを削除します。実行の詳細を取得したり、実行を再生したりすることはできなくなりました。保持期間は、実行が終了状態 (SUCCEEDED、FAILED、STOPPED、TIMED_OUT) に達したときに開始されます。

Lambda コンソール、AWS CLI、AWS SAM を使用して、耐久性のある関数を作成するときに保持期間を設定できます。Lambda コンソールで関数を選択したら [設定] を選択し、耐久性のある実行を選択します。保持期間の値を日数単位で設定します (デフォルトで 14 日、最小 1 日、最大 90 日)。

コンプライアンス要件、デバッグのニーズ、コストに関する考慮事項に基づいて、保持期間を選択してください。保持期間を長くすると、デバッグや監査の増加する時間に対応できますが、ストレージコストが増加します。