エラー制御の検索結果1 - 3 件 / 3件

• あとで読む

  KinesisデータストリームをLambdaで処理する時のエラー制御方法をまとめてみた | DevelopersIO

  • 4 users
  • dev.classmethod.jp
  • テクノロジー
  • 2023/05/08

  次に、リトライ数を2にして再度エラーを発生させます。 初回呼び出しでエラーが起きた後、2回再試行し、合計3回実行して処理を終えました。 バッチ処理時に一部のレコードが原因でバッチ全体をリトライされるのを防ぐ バッチ処理時に一部のレコードが原因でバッチ全体が再実行されるのを防ぎたい場合 二分探索法(bisect)でバッチを分割し、エラーを誘発するレコードを含むバッチを絞り込む バッチ内で失敗したレコード(のシーケンス)を特定し、失敗箇所からやり直す の2種類のアプローチがあります。 前者はアプリケーション側の作り込みなしに、Kinesisの基盤側でエラーを絞り込んでくれますが、同じレコードに対して何度も再実行される可能性があり、バッチサイズが大きい場合は無駄が多くなります。 後者はアプリケーション側で軽微な作り込みが伴うため、複雑さが増す一方で、リトライ時にはエラー箇所から再実行され、先行す

  
• あとで読む

  [Amazon Lex] AMAZON.FallbackIntentを利用すると自由自在なエラー制御が可能になる | DevelopersIO

  • 3 users
  • dev.classmethod.jp
  • テクノロジー
  • 2019/10/05

  1 はじめに CX事業本部の平内（SIN）です。 Amazon Lex(以下、Lex)では、一部（AMAZON.YesIntent、AMAZON.NoIntent）を除いて、Alexaの組み込みインテントが使用できます。今回は、無効な発話があった時に、それを受けとめることができるAMAZON.FallbackIntentの動作を確認してみました。 実は、昨日、AWS Machine Learning Blogで下記の記事を見つけ、試してみたくなったと言う感じです。 Managing conversation flow with a fallback intent on Amazon Lex 注：AMAZON.FallbackIntentは、2019/10現在、英語とドイツ語しか対応しておらず、日本語Alexaでは、利用できません。 動作確認のためのボットは、テンプレートで提供されているOr

  
• あとで読む

  ストリーム処理のエラー制御がより柔軟に！！Kinesis Data StreamsとDynamoDB Streamsから起動するLambdaでチェックポイントが利用可能になりました #reinvent | DevelopersIO

  • 3 users
  • dev.classmethod.jp
  • テクノロジー
  • 2020/12/17

  CX事業本部@大阪の岩田です。 Kinesis Data StreamsとDynamoDB Streamsから起動するLambdaで新たに「チェックポイント」が利用できるようになり、処理が「途中まで成功した」という情報をLambdaだけで管理できるようになりました。 さっそく試してみたいと思います。 何が嬉しいのか？ Kinesis Data Streams/DynamoDB Streamsから起動するLambdaのイベントデータには、「バッチ」という処理単位で複数レコードの情報が渡ってきます。これまでLambda単体ではバッチ全体での処理成功/失敗しか表現できず、レコード単位での処理成功/失敗を管理するには別途DynamoDBなどを利用する必要がありました。 バッチの途中で処理が異常終了するケースについて考えてみましょう。例えば10レコードがLambdaに渡ってきた場合に7レコードまで処

  • aws_kinesis