AWS Lambda
開発者ガイド

AWS Lambda 再試行動作

Lambda 関数は、次のいずれかが原因で失敗する場合があります。

  • 関数がエンドポイントに到達する前にタイムアウトになった。

     

  • 関数が入力データを正しく解析できなかった。

     

  • 関数にメモリ不足エラーまたは他タイムアウトなどのリソース制約が発生した。

このようなエラーが発生する場合、関数は例外をスローします。例外の処理方法は、Lambda 関数の呼び出し方法によります。

  • ストリームベースではないイベントソース – これらのイベントソースの一部は Lambda 関数を同期的に呼び出すようにセットアップされています。それ以外は非同期呼び出しです。したがって、例外は次のように処理されます。

     

    • 同期呼び出し – 呼び出し元アプリケーションが 429 エラーを受け取り、再試行が必要となります。サポートされているイベントソースおよびそれらが使用する呼び出しタイプのリストについては、「サポートされているイベントソース」を参照してください。これらのイベントソースは、追加の再試行数が統合に組み込まれている場合もあります。

      AWS SDK を使用して Lambda 関数を直接呼び出した場合、クライアントではエラーが表示され、再試行を選択できます。

       

    • 非同期呼び出し – 非同期イベントは Lambda 関数の呼び出しに使用される前にキューされます。AWS Lambda がイベントを完全に処理できない場合、呼び出しが 2 回自動的に再試行されます (再試行間には遅延があります)。関数にデッドレターキュー (DLQ) を指定した場合、障害イベントは指定された Amazon SQS キューまたは Amazon SNS トピックに送信されます。要求されず、またデフォルト設定でデッドレターキュー (DLQ) を指定しない場合、そのイベントは破棄されます。詳細については、「デッドレターキュー」を参照してください。

       

  • ストリームベースのポーリングベース (またはプルモデル) のイベントソース: Kinesis Data Streams または DynamoDB で構成されています。Lambda 関数呼び出しが失敗した場合、AWS Lambda はデータの有効期限が切れるまで、最大 7 日間、レコードのエラーが発生したバッチを試みます。

    例外はブロックとして扱われ、失敗したレコードのバッチの有効期限が切れるか処理が成功するまで、AWS Lambda ではシャードから新しいレコードの読み込みが行われません。こうすることで、確実に AWS Lambda で順番にストリームイベントが処理されます。

  • ストリームベースでない、ポーリングベースのイベントソース: Amazon Simple Queue Service で構成されます。Amazon SQS キューをイベントソースとして設定した場合、AWS Lambda はキュー内のレコードのバッチをポーリングし、Lambda 関数を呼び出します。呼び出しが失敗、またはタイムアウトした場合、バッチのメッセージはすべてキューに返り、可視性タイムアウト期間が過ぎると処理に使用できるようになります。(可視性タイムアウトは、Amazon Simple Queue Service によって他の消費者がそのメッセージを受信および処理できなくなる期間です)。

    呼び出しによってバッチが正常に処理されると、そのバッチのメッセージはそれぞれ、キューから削除されます。メッセージが正常に処理されなかった場合は破棄されます。または、Amazon SQS デッドレターキューを設定した場合は、分析に使用する障害情報が送信されます。

順序付けられたイベントの処理を必要としない場合に Amazon SQS キューを使用する利点は、前のメッセージの呼び出しに失敗しても、AWS Lambda が新しいメッセージの処理を継続することです。つまり、新しいメッセージの処理はブロックされません。

呼び出しモードの詳細については、「AWS Lambda イベントソースマッピング」を参照してください。