web-dev-qa-db-ja.com

AWSLambdaメッセージをバッチで処理する

私は何か疑問に思っています、そして私は本当にそれについての情報を見つけることができません。多分それは行く方法ではありませんが、私は知りたいだけです。

ラムダがバッチで作業することについてです。バッチメッセージを消費するようにLambdaを設定できることは知っています。私のLambda関数では、各メッセージを繰り返し、1つが失敗すると、Lambdaは終了します。そして、サイクルが再び始まります。

少し異なるアプローチについて疑問に思っています。3つのメッセージがあるとしましょう：[〜＃〜] a [〜＃〜]、[〜＃〜] b [〜＃〜] =および[〜＃〜] c [〜＃〜]。私もそれらをバッチで取ります。ここで、メッセージBが失敗した場合（API呼び出しが失敗した場合など）、メッセージBをSQSに返し、メッセージCの処理を続行します。

出来ますか？もしそうなら、それは良いアプローチですか？ Lambdaでさらに複雑なものを実装する必要があることがわかったので、そうではありません。

ありがとう

amazon-web-servicesaws-lambdaamazon-sqs
6
Vedran Maricevic.

2019年11月の時点で、 AWSが導入 最大再試行回数とともにBisect On FunctionErrorの概念。関数がべき等である場合、これを使用できます。

このアプローチでは、バッチ内の1つのアイテムが失敗した場合でも、関数からエラーをスローする必要があります。バッチを2つに分割して再試行するAWS。これで、バッチの半分が正常に通過するはずです。残りの半分については、不良レコードが特定されるまでプロセスが続行されます。

1
joseph

メッセージのバッチから失敗したメッセージのみを再試行する場合は、完全に実行可能ですが、少し複雑になります。

これを実現するための可能なアプローチは、イベントのリスト（[eventA、eventB、eventC]など）を反復処理し、実行ごとに、イベントが失敗した場合は失敗したイベントのリストに追加することです。次に、失敗したイベントのリストに何かが含まれているかどうかを確認するエンドケースを用意し、含まれている場合は、手動でにメッセージを送り返します。 SQS（ SQS sendMessageBatch を使用）。

ただし、手動でイベントを挿入し直すため、これによりイベントがキューの最後に配置されることに注意してください。

複雑さをあまり感じずに問題を解決できれば、何でも「良いアプローチ」になります。この場合、成功したイベントを再実行する必要があるという問題は、この方法で解決できる問題です。

1
Deiv

すべてのアーキテクチャの決定と同様に、それはあなたの目標とあなたがより複雑にするために何を喜んで交換するかに依存します。 SQSを使用すると、メッセージを順不同で処理できるため、再試行によって他のメッセージがブロックされることはありません。それが複雑さの価値があるかどうかは、メッセージがブロックされることを心配している理由によって異なります。

ラムダ再試行動作 およびDead LetterQueuesについて読むことをお勧めします。

1
bwest

Node.jsについては、 https://www.npmjs.com/package/@middy/sqs-partial-batch-failure を確認してください。

const middy = require('@middy/core')
const sqsBatch = require('@middy/sqs-partial-batch-failure')

const originalHandler = (event, context, cb) => {
  const recordPromises = event.Records.map(async (record, index) => { /* Custom message processing logic */ })
  return Promise.allSettled(recordPromises)
}

const handler = middy(originalHandler)
  .use(sqsBatch())

詳細については、 https://medium.com/@brettandrews/handling-sqs-partial-batch-failures-in-aws-lambda-d9d6940a17aa を確認してください。

0
Brett