S3、Kinesis/DynamoDB StreamsでのLambdaリトライ処理 - Qiita
こちらの記事の内容と現在のリトライ動作は異なっています。 詳細は下記の公式ドキュメントを参照してください。 エラー時のリトライ - AWS Lambda公式ドキュメント AWS Lambda のイベントソースごとの呼び出しタイプ - Qiita 概要 Lambda ファンクション内で context.done() の第1引数に null 以外の値を渡すと処理失敗となりリトライが発生する。 各イベントソースによるリトライ処理を調べてみた。 処理失敗時には 3 分後に再度ファンクションが呼び出される。 context.invokeid は前回と同じ値になる。 リトライを含めて最大 3 回実行される。 ETagの比較 US Standard は全ての操作で結果整合性、それ以外のリージョンでは新規作成以外の操作で結果整合性をもって動作する。 Lambda に限らず S3 のオブジェクトを取得する場
KinesisかS3か
Kinesisを触ってはみたものの、特別「これは使いやすい！」という印象ではなかった。 Kinesisの用途は要するに AWSにガンガンデータを送る AWS側では、送られてきたデータを片っ端から処理する AWS側に着いたデータは処理しようがしまいが一定期間(現在は24時間)で消える というもの。 しかし、AWSへの送信は単純にHTTPSのPOSTリクエストであり、さらにBase64エンコードされているということで特に効率的な方法ではない。むしろ効率をまったく考慮しておらず、シンプルさ、扱いやすさに徹している。 HTTPSのPOSTリクエストであるにも関わらずサイズ上限(現在は50KB)がきついので、小さなデータを送る用途に限定される。 個人的に数十～百台程度のサーバからAWSへのログの集約(Log Aggregation)を計画しているのだが、Kinesisの用途にぴったりか？と考えた一方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
