DynamoDB RCU Tunning

Transcript

1. DynamoDBのテーブル RCUを 1/100に減らした話 Hoang Minh Quang AI事業本部 LT会 #AWS Hanoi DevCenter 2024/07/18
2. HOANG MINH QUANG (クアン） •Joined CyberAgent / Hanoi DevCenter in 2023/08 •アプ運用カンパニー / 大福山チーム Backend Engineer •Ramen / RDBMS / Go / Design •パフォーマンスチューニング About me @minhquang4334 @Quang4334 #times-hanoi-devcenter ref ref
3. #times-hanoi-devcenter 技術興味深いなチームで、気になる方 はぜひ遊びに来てください
4. DynamoDBのRCUとは • DynamoDBのテーブルの読み取りのスループットで、RCU(Read Capacity Unit)という単位で 割り当てる • 「1RCUで4KBの項目を1秒当たり結果整合性なら 2個を読み込める」 この計算方式は分かりにくいですね　:cry: Refs: https://aws.amazon.com/dynamodb/pricing/provisioned/
5. DynamoDBのRCUとは • 「1RCUで4KBの項目を1秒当たり結果整合性なら 2個を読み込める」 一個は1 Item（レコード）である → 1RCUはMAX 2 Items 読み込める 読み込めるデータはQueryのレスポンスのデータじゃなくて、スキャンされたデータになる もしfull スキャンになってしまうと、全量データのサイズ・数で計算されてしまう
6. RCUを減らせば ・パフォーマンスが向上できる ・お金が節約できる Refs: https://aws.amazon.com/dynamodb/pricing/provisioned/
7. RCUを減らす、基本的な考え方 1RCUで4KBの項目を1秒当たり結果整合性なら 2個のアイテムを読み込める RCU = f(num_read_requests, total_scan_item_size_per_request) Minimize num_read_requests Minimize total_scan_item_size_per_request num_read_requests: DynamoDBのテーブルに読み取りリクエストの数 total_scan_item_size_per_request: 一回の読み取りリクエストでスキャンされるデータ容量
8. 背景
9. 私たちのチームのプロダクトは 大手リテール会社と協業して、リテールモバイルアプリを開発しています。 アプリでユーザーがポイント詰め・買い物・キャンペーンクーポン利用などができます。 現アプリは一ヶ月稼働ユーザーは数百万います。
10. 課題 あるユーザーに公開中ターゲッティングされているキャンペーン (aka Campaign) 一覧を取得したい ・ユーザー：サービス利用者 ・キャンペーン ：セールス・広告のキャンペーン。定める期間で行う ・ターゲッティングキャンペーン ：一部の個別ユーザーに対してターゲッ ティングする 逆に全ユーザー向けのキャンペーンもある
11. 今の設計の構成 Aurora MySQL DynamoDB Primary Key id is_public is_targeting begin_at end_at CampaignMasterTable Partition Key user_id Sort Key campaign_id created_at updated_at TargetingUserCampaignTable データは異なるデータストアに保 存されている
12. なぜデータストア分けているか • DynamoDBのWrite Throughput が Auroraより良い TargetingUserCampaignTableのWrite Operationが多い、1分で 1000万以上レコードが書き込む可能 性がある 現時点では対象のDynamoDBテーブルのレコード数は 7億ぐらい
13. 現状の実装
14. 現状の実装 公開中のキャンペーン一 覧を取得する Aurora MySQL DynamoDB ユーザーにターゲティン グされているユーザーを 絞る ※ 公開中かどうかの情報はAuroraにあり どのユーザーにターゲティングされているか DynamoDBにあるので両方見る必要 課題：あるユーザーに公開中ターゲッティングされているキャンペーン一 (aka Campaign) 覧を取得したい
15. 現状の実装 公開中のキャンペーン一 覧を取得する SELECT id as public_campaign_ids FROM CampaignMasterTable WHERE …… Aurora MySQL DynamoDB ユーザーにターゲティン グされているユーザーを 絞る
16. 現状の実装 DynamoDBで絞って、 結果返す SELECT campaign_id FROM TargetingUserCampaignTable WHERE CampaignID IN (${public_campaign_ids}) AND userId = ? 公開中のキャンペーン一 覧を取得する SELECT id as public_campaign_ids FROM CampaignMasterTable WHERE …… Aurora MySQL DynamoDB ユーザーにターゲティン グされているユーザーを 絞る
17. 現状の実装 どうやってこのクエリをDynamoDBに叩けるか SELECT campaign_id FROM TargetingUserCampaignTable WHERE CampaignID IN (${public_campaign_ids}) AND userId = ? 公開中のキャンペーン一 覧を取得する SELECT id as public_campaign_ids FROM CampaignMasterTable WHERE …… Aurora MySQL DynamoDB ユーザーにターゲティン グされているユーザーを 絞る
18. PartiQLを使用している • a SQL-compatible query language for Amazon DynamoDB なので、複雑なクエリでもDynamoDBでいい感じに叩ける WHERE … IN, OR, BETWEEN, ><=><= などで • DB上でページネーション可能 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html
19. PartiQLを並列化する PartiQLはWHERE INにあるplaceholdersの数の上限は 100であり、場合によっては50個で、 同時に公開中のキャンペーンが非常に多いため、分割して並列した。 SELECT campaign_id FROM TargetingUserCampaignTable WHERE CampaignID IN (${public_campaign_ids_1}) AND userId = ? DynamoDB ユーザーにターゲティン グされているユーザーを 絞る SELECT campaign_id FROM TargetingUserCampaignTable WHERE CampaignID IN (${public_campaign_ids_2}) AND userId = ? SELECT campaign_id FROM TargetingUserCampaignTable WHERE CampaignID IN (${public_campaign_ids_n}) AND userId = ? …… public_campaign_ids = (public_campaign_ids_1, public_campaign_ids_2, .. ,public_campaign_ids_n)
20. 現状実装のイメージ
21. 問題 • PartiQLの仕様がわかりにくい Partition KeyとSort Keyをwhereの条件で指定してもページネーション発生されて、余計なデータもスキャンされてしまう チームで一緒に仕様を調べても完全理解までできない RCUの見積もりが難しいすぎる • 並列化の制御が大変 並列しすぎると、DynamoDBに負荷が高くなって、throttlingエラーも出るから、適切に調整する必要 どのくらい並列化したら良いか見積もりにくい Datadogのトーレスが複雑
22. どんどんシステム品質が悪化された • 対象のテーブルの RCU = 5000/s 以上で高い • たまに throttling error 発生、サービス不安定 • DynamoDBのコストが高い • APIやシステム全体に P90 Latency が遅い (〜150ms)
23. 改善策
24. 改善策 DynamoDBで結果絞るのではなく、 OnMemoryやる方針にしました DynamoDBで結果絞る SELECT campaign_id FROM TargetingUserCampaignTable WHERE CampaignID IN (${public_campaign_ids}) AND userId = ? 公開中のキャンペーン一 覧を取得する SELECT id as public_campaign_ids FROM CampaignMasterTable WHERE …… Aurora MySQL DynamoDB ユーザーにターゲティン グされているユーザーを 絞る 改善前
25. 改善策 DynamoDBで結果絞るのではなく、 OnMemoryやる方針にしました 公開中のキャンペーン一 覧を取得する Aurora MySQL DynamoDB ユーザーの全ターゲティ ングキャンペーン取得す る 公開中かどうか関わらず それぞれ実行して、On MemoryでOverlap された データ(共通部分）を結果 にする 改善策 SELECT id as public_campaign_ids FROM CampaignMasterTable WHERE …… DynamoDB.GetItem by userID partition key つまり userIDのpartitionの全データをとる
26. なぜそう改善したか • 実際のデータやビジネスの要件の特殊から考える 同時に公開中のキャンペーン（数百件）が多いけど、一人のユーザーに対してターゲティングされるキャンペーンは 少ない それで一つのpartition (user_id)にデータは少ない（数十件程度）
27. なぜそう改善したか • DynamoDBのpartition key をフル活用する Partition keyだけを使うので、超早い 1個のItemが125 Bytesでしたら、1 Queryは 8000個のItemまで取得できる。 それで、一回のQueryで大丈夫だし、並列も不要になる
28. なぜそう改善したか • RCUを見積もりやすい Partitionの全量データを取得するため、Queryレスポンスのデータと読み込めるデータは同じなので、RCU見積もりも しやすい
29. RCU最適 1RCUで4KBの項目を1秒当たり結果整合性なら 2個を読み込める RCU = f(num_read_requests, total_scan_item_size_per_request) Minimize num_read_requests Minimize total_scan_item_size_per_request 並列化をやめて、一回の Queryだけで行う Queryで必要なデータだけ読 み込める
30. 結果
31. RCU 対象のテーブルのRCUは 1/100になった
32. トレーススパン
33. AWSコスト 1000$/月ぐらいまでDynamoDBのコスト削減できた
34. ちなみにレイテンシーも 対象のAPIのP90レイテンシは 10x 早い サービス全体のP90 レイテンシは 2x 早い
35. その他に考えられそうな改善余地 • hot partitionがないかモニタリングする 一つのpartitionの全量データを取得するので、hot partition考える必要 改善の実装であれば、hot partitionが生まれたら、そのpartitionのuser_idにレイテンシーが高い 今のビジネスの要件でそのケースはないけど • DynamoDBのBatchGetItemを試してみる DBで絞る方針はそのままにして、PartiQLからBatchGetに移行検証してみる
36. EOF