Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DynamoDB Streams を Lambda のトリガーで使う話
Search
hmatsu47
PRO
March 29, 2023
Technology
0
1.3k
DynamoDB Streams を Lambda のトリガーで使う話
JAWS-UG 名古屋 推しの AWS サービスを語る LT 会 2023/03/29
hmatsu47
PRO
March 29, 2023
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
Aurora DSQL のトランザクション(スナップショット分離と OCC)
hmatsu47
PRO
0
3
いろんなところに居る Amazon Q(Developer)を使い分けてみた
hmatsu47
PRO
0
22
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
11
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
28
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
17
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
15
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
12
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
22
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
55
Other Decks in Technology
See All in Technology
役割は変わっても、変わらないもの 〜スクラムマスターからEMへの転身で学んだ信頼構築の本質〜 / How to build trust
shinop
0
120
Evolution on AI Agent and Beyond - AGI への道のりと、シンギュラリティの3つのシナリオ
masayamoriofficial
0
270
実践AIガバナンス
asei
3
210
実運用で考える PGO
kworkdev
PRO
0
120
広島銀行におけるAWS活用の取り組みについて
masakimori
0
160
Oracle Cloud Infrastructure:2025年8月度サービス・アップデート
oracle4engineer
PRO
0
120
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
30k
実践アプリケーション設計 ②トランザクションスクリプトへの対応
recruitengineers
PRO
4
1.1k
カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys
kaminashi
3
530
ここ一年のCCoEとしてのAWSコスト最適化を振り返る / CCoE AWS Cost Optimization devio2025
masahirokawahara
1
300
Vault meets Kubernetes
mochizuki875
0
140
「守る」から「進化させる」セキュリティへ ~AWS re:Inforce 2025参加報告~ / AWS re:Inforce 2025 Participation Report
yuj1osm
1
170
Featured
See All Featured
It's Worth the Effort
3n
187
28k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
4 Signs Your Business is Dying
shpigford
184
22k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Bash Introduction
62gerente
614
210k
Embracing the Ebb and Flow
colly
87
4.8k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
284
13k
Scaling GitHub
holman
463
140k
Optimizing for Happiness
mojombo
379
70k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
185
54k
Transcript
DynamoDB Streams を Lambda のトリガーで使う話 JAWS-UG 名古屋 推しの AWS サービスを語る
LT 会 2023/3/29 まつひさ(hmatsu47)
自己紹介…は時間省略のためスキップ 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 2
本日のネタは • RDS / Aurora 3
本日のネタは 4 • RDS / Aurora
本日のネタは • RDS / Aurora ではなく DynamoDB + Lambda •
データ登録用の DynamoDB テーブルでストリームを設定 • それをトリガーに Lambda を実行させる話 ◦ 元テーブルのデータを加工して別テーブルにコピーする ◦ Lambda で何らかの非同期 API を呼び出す ▪ 「中身が見えるキュー」としての使い方 5
どういうときに使う? • 違う設計の参照用テーブルを(複数)用意したいケース ◦ インデックスの数が多すぎる ▪ GSI は 20 個まで、LSI
は 5 個まで ◦ 後から LSI を追加したくなった ◦ 参照用テーブルに必要なパーティションキーまたはソートキーが 非正規形で、テーブルごとに値の組み合わせを変えたい ▪ 例)テーブル A では登録日+ユーザー ID、テーブル B では ユーザー ID + 商品 ID をパーティションキーにしたい 6
どういうときに使う? • 「中身が見えるキュー」として使いたいケース ◦ アプリケーションの実装者がキューの扱いに慣れていない ▪ キューの中身が見えないと不安 ◦ 中身を確認後「キューの一部だけ選んで Lambda
再発火」したい ▪ レコードを変更して保存すれば再びストリームに流れる ◦ ベストプラクティスは別にあるとしても、使う人に合わせた技術 (処理方法)選定があっても良いのでは? 7
使用例(1/2) • blastengine API でメール送信 ◦ 送信用テーブルに挿入・変更すると、 ◦ Streams をトリガーに
Lambda を起動 ▪ blastengine API にリクエストし、 ▪ 成功したら送信履歴テーブルに記録 • 送信用テーブルのレコードは削除 ▪ 失敗したら時間をあけてリトライ • レートリミット対策 ◦ バウンス処理部分の図示・説明は省略 8 ↑ ここ (ストリーム)
使用例(2/2) • Qiita 記事はこちら ◦ https://qiita.com/hmatsu47/items/e6e8fc9290eede7c8a55 ◦ API コールを失敗したレコードだけが送信用テーブルに残る ▪
必要があれば対象レコードの変更で Lambda 再発火 ◦ 送信履歴テーブルはバウンス(Webhook で取得)と突合する ▪ ここでは説明を省略 9
実行例(送信用テーブルに挿入) 10
実行例(送信用テーブル : API コール失敗レコードが残る) 11
実行例(送信履歴テーブル : API コール成功レコードのみ) 12
実行例(実際に届いたメール) 13
トリガーの設定例(1/3) 14 挿入・更新・削除レコードを 最大 100 件ずつまとめて Lambda に渡す 挿入・更新・削除レコードを まとめるために待機する秒数
トリガーの設定例(2/3) 15 Lambda 関数の実行がエラー になったときの再試行回数 (デフォルトは -1: 無制限) チェックするとエラー再試行時 にレコード行数を半分に分割
トリガーの設定例(3/3) 16 同一シャードから 同時に呼び出される Lambda は 1 つ 挿入・更新時のみ Lambdaを呼び出す
注意点(1/2) • 1 テーブルで複数ストリームが流れる ◦ シャード単位でストリームが分かれるので、挿入・更新・削除の 順序が完全に保証されるわけではない ▪ 1 シャード
複数パーティション・1 パーティション複数シャードの両方あり ◦ 一方で、ストリームごとの Lambda の処理時間が長すぎると処理 が詰まってしまう ▪ Step Functions を呼び出す形を検討 17
注意点(2/2) • デフォルトでは Lambda のトリガー再試行は無制限 ◦ 処理途中に捕捉し損ねたエラー・例外があると課金死の危険が ▪ エラー・例外の捕捉漏れが無いようにする ▪
再試行の回数を限定しておいたほうが良い 18
まとめ • DynamoDB の制約に引っ掛かる場合に使える ◦ インデックスが多すぎる or LSI を追加したいけどできない •
「中身が見えるキュー」として使える ◦ 中身を見た上で選択的に Lambda を再発火させることも • ストリームの順序と無限再試行に注意 ◦ 順序の保証が必要な場合は使わない ◦ 再試行の回数を限定して課金死を防ぐ 19