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
910
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
大人の社会科見学 ~ NTT 技術史料館に行ってみよう!
hmatsu47
PRO
0
270
pgvector 0.6.0 以降の進化についてざっくり取り上げてみる
hmatsu47
PRO
0
21
Cloudflare Workes からMySQL 系 DB への接続事情(2024/4 現在)
hmatsu47
PRO
0
45
BuriKaigi2024 にボランティアスタッフとして参加した話
hmatsu47
PRO
0
62
Aurora MySQL と Redshift の zero-ETL 統合のフィルター機能を試してみた
hmatsu47
PRO
0
82
Aurora MySQL 3.06 の ML 機能で Bedrock アクセスを試してみた
hmatsu47
PRO
0
68
RDS Data API と Aurora zero-ETL 統合と BuriKaigi2024 の話
hmatsu47
PRO
0
32
RDS Data API のその後と Aurora zero-ETL 統合のデータ転送処理の話
hmatsu47
PRO
0
81
RDS_Aurora 関連アップデート 2023 版
hmatsu47
PRO
0
82
Other Decks in Technology
See All in Technology
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
480
LINE WORKSへ簡単通知!Incoming Webhookアプリの紹介
mmclsntr
0
110
楽しくGoを学び合う、LayerXの勉強会文化 / LayerX's study culture of having fun and learning Go together
ar_tama
2
350
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1k
AWSでRAGを作る法方
sonoda_mj
1
140
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
エンジニア向け会社紹介資料
caddi_eng
14
230k
スレットハンティングについて知っておきたいこと
hacket
0
130
Github Actions 로 Android 팀의 효율성 극대화
hadonghyun
0
160
E2Eテスト自動化プラットフォームにおけるAIの活用
shift_evolve
0
190
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 / AI Test Lab vol.1
shift_evolve
0
190
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
44
4.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Unsuck your backbone
ammeep
666
57k
Fantastic passwords and where to find them - at NoRuKo
philnash
42
2.7k
Facilitating Awesome Meetings
lara
46
5.8k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
17
8.7k
The Invisible Customer
myddelton
117
13k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.5k
Debugging Ruby Performance
tmm1
71
11k
The Illustrated Children's Guide to Kubernetes
chrisshort
39
47k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
The Power of CSS Pseudo Elements
geoffreycrofte
64
5.2k
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