Lambda での再試行動作について

関数を直接呼び出すときは、関数コードに関連するエラーを処理する方法を決定します。Lambda は、ユーザーに代わってこれらのタイプのエラーを自動的に再試行しません。再試行するには、関数を手動で再呼び出しするか、失敗したイベントをデバッグのためにキューに送信するか、エラーを無視します。関数コードが部分的にまたは完全に実行されている可能性もあれば、まったく実行されない可能性もあります。再試行する場合は、関数コードが重複したトランザクションや望ましくない副作用を引き起こすことなく同じイベントを複数回処理できるようにしてください。

関数を間接的に呼び出す際、呼び出し元やリクエストが遭遇するすべてのサービスの再試行動作について把握する必要があります。これには、以下のシナリオが含まれます。

• 非同期呼び出し － Lambda は、関数エラーを 2 回再試行します。関数にすべての受信リクエストを処理するのに十分な容量がない場合、イベントはキュー内で数時間待機して関数に送信される可能性があります。正常に処理できなかったイベントを把握するために、デッドレターキューを設定できます。詳細については、「Lambda が非同期呼び出しを処理する方法」を参照してください。

• イベントソースマッピング － ストリームから読み取るイベントソースマッピングは、項目のバッチ全てに対して再試行を実施します。繰り返されるエラーは、そのエラーが解決されるか、項目が期限切れになるまで、影響を受けるシャードの処理を妨げます。停止しているシャードを検出するには、Iterator Age メトリクスをモニタすることができます。

  キューから読み取るイベントソースマッピングについては、ソースキューの再試行ポリシーおよび可視性タイムアウトを設定することで、失敗したイベントの送信先と再試行の間の時間の長さを決定します。詳細については、Lambda がストリームおよびキューベースのイベントソースからのレコードを処理する方法 および 他の AWS サービスからのイベントを使用した Lambda の呼び出し のサービス固有のドキュメントを参照してください。

• AWS のサービス － AWS のサービスでは、同期的または非同期的に関数を呼び出す場合があります。同期呼び出しの場合、サービスは再試行するかどうかを決定します。例えば、Amazon S3 バッチオペレーションは、Lambda 関数が TemporaryFailure 応答コードを返す場合、オペレーションを再試行します。プロキシがアップストリームユーザーまたはクライアントからリクエストするサービスは、再試行戦略を持っているか、またはリクエスタにエラー応答をリレーする場合があります。例えば、API Gateway は常にエラー応答をリレーしてリクエスタに返します。

  非同期呼び出しの場合、再試行ロジックは呼び出しソースに関係なく同じです。デフォルトでは、Lambda は失敗した非同期呼び出しを最大 2 回再試行します。詳細については、「Lambda がエラーを処理し、非同期呼び出しで再試行する方法」を参照してください。

• 他のアカウントやクライアント － 他のアカウントへのアクセス権限を付与する場合、関数を呼び出すために設定できるサービスやリソースの制限にリソースベースのポリシーを使用することができます。関数を過負荷から守るためには、Amazon API Gateway を使用して、関数の前に API レイヤーを設定することを考慮してください。

Lambda アプリケーションのエラーに対応できるよう、Lambda では、Amazon CloudWatch や AWS X-Ray などのサービスを統合しています。ログやメトリクス、アラーム、関数コード内の問題を迅速に検出および特定するトレーシング、API またはアプリケーションをサポートするその他のリソースを組み合わせて使用することができます。詳細については、「Lambda 関数のモニタリングおよびトラブルシューティング」を参照してください。