Aws lambda関数を使用して、バケット内のアップロードされたwavファイルをmp3形式に変換し、後でファイルを別のバケットに移動します。正常に動作しています。しかし、トリガーには問題があります。小さなwavファイルをアップロードすると、lambda関数が1回呼び出されます。しかし、大きなサイズのwavファイルをアップロードすると、この機能が複数回トリガーされます。
この問題をグーグルで調べたところ、ステートレスであることがわかったため、複数回呼び出されます(このトリガーが複数のアップロードまたは同じアップロードのためのものかどうかは不明です)。
https://aws.Amazon.com/lambda/faqs/
1回のアップロードでこの関数を1回呼び出すメソッドはありますか?
ショートバージョン:ラムダ関数構成のタイムアウト設定を増やしてみてください。
ロングバージョン:
ここでタイムアウトしているラムダ関数を実行していると思います。
S3イベントは本質的に非同期であり、S3イベントをリッスンするラムダ関数は、そのイベントが拒否される前に少なくとも3回再試行されます。ラムダ関数は、変換と再アップロードを行う小さいサイズのアップロード中に1回だけ(エラーなしで)実行されると述べました。コードからの変換と再アップロードに必要な時間が、ラムダ関数のタイムアウト設定よりも長くなる可能性があります。
したがって、ラムダ関数構成のタイムアウト設定を増やしてみてください。
ところで、ラムダ関数が複数回呼び出されることを確認する1つの方法は、イベントID(67fe6073-e19c-11e5-1111-6bqw43hkbea3)発生-
START RequestId: 67jh48x4-abcd-11e5-1111-6bqw43hkbea3 Version: $LATEST
このイベントIDは、ラムダが呼び出された特定のイベントを表し、同じS3イベントを処理するすべてのラムダ実行で同じである必要があります。
また、1つのラムダ実行の終了を示す次のログ行で実行時間(期間)を検索できます-
REPORT RequestId: 67jh48x4-abcd-11e5-1111-6bqw43hkbea3 Duration: 244.10 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 20 MB
解決策ではない場合、少なくとも正しい方向でデバッグする余地があります。それがどうなるか教えてください。
Lambdaを数回実行するイベントは、 AWSドキュメント で指定されているLambdaの再試行動作によるものです。
コードで例外が発生したり、タイムアウトしたり、メモリが不足したりする場合があります。コードを実行するランタイムでエラーが発生して停止する場合があります。並行性が不足し、抑制される可能性があります。
Lambdaにエラーが発生し、クライアントまたはサービスがLambda関数を呼び出して再試行する可能性があります。
CloudWatchログを使用してエラーを見つけ、解決することで問題を解決できます。
私も同じ問題に直面しました。私の場合、それはアプリケーションエラーのためであり、それを解決することは私を助けました。
context
オブジェクトには、現在処理しているリクエストIDに関する情報が含まれています。同じイベントが複数回発生しても、このIDは変わりません。イベントがトリガーされるたびにこのIDを保存し、最後に処理したIDが現在のIDと同じでないことを確認できます。
この問題を修正するための最終的なコードを次に示します(MongooseJSデータベースハンドラーを備えたNodeJS)。
exports.handler = function(event, context, lambdaCallback) {
Events.findOneAndUpdate(
{ name: 'some-event-name' },
{ lastRequestId: context.awsRequestId }).then(function(event) {
// Without specifying the option "new: true" the old document is returned
// after the update, so we check the ID against the old value
if(event.lastRequestId == context.awsRequestId) {
return;
}
/* Run the actual job */
...
});
}
お役に立てれば!