PayPayでのDynamoDB活用事例について

PayPay

August 25, 2020

Tweet Share

Transcript

1. 
 ay ay通知サービスにおける
 DynamoDB 活用
 
 西中 智樹 


2. 自己紹介
 西中 智樹 ( omoki ishinaka)
 
 2018年12月より ay ay


   latform team 所属
 
 好きなA サービス: E 
 
 
 


3. アジェンダ（インフラ編）
 1. ay ayについて
 2. DynamoDB導入 経緯
 3. データストアサービス 比較検討


4. ay ayについて


5. 日本 o.1 決済サービス
 支払い
 • オフライン決済
 • オンライン決済/ミニアプリ 
 •

   2 と請求書 支払い 
 　　　ボーナス運用　 
 近く お店
 • ay ayが利用できるお店が地図一覧 で分かる
 
 お知らせ
 ay ayピックアップ
 • 事前注文テイクアウトサービス 
 ay ayフリマ
 タクシーを予約する
 • DiDi ミニアプリ
 
 そ 他多数
 ber Eatsミニアプリ 
 ※2020年1月16日　ICT総研調べ「 QRコード決済 利用可能店舗数に関する調査」より

6. 日本 o.1 決済サービス


7. DynamoDB導入 経緯


8. 日本 o.1 決済サービス
 支払い
 • オフライン決済
 • オンライン決済/ミニアプリ 
 •

   2 と請求書 支払い 
 　　　ボーナス運用　 
 近く お店
 • ay ayが利用できるお店が地図一覧 で分かる
 
 お知らせ
 ay ayピックアップ
 • 事前注文テイクアウトサービス 
 ay ayモール / フリマ 
 タクシーを予約する
 • DiDi ミニアプリ
 
 そ 他多数
 serEatsミニアプリ
 ※2020年1月16日　ICT総研調べ「 QRコード決済 利用可能店舗数に関する調査」より

9. • ay ay全て 通知を管理する機能
 ◦ ay ay残高付与 / キャンペーン /

   受け取り/ わりかん 
 • タイムラインライクで、過去どこまでも確認できるも 
 • ユーザごとにパーソナライズされたも 
 通知サービス 機能


10. データストアサービス 検討


11. 通知サービスに必要な要件 • 大量 データを保存することができる
 • 読み込み・書き込み パフォーマンスが良いこと
 ◦ 数十億レコードでもパフォーマンス悪化しない 


    • 高可用性なこと
 • 柔軟にスケールができること
 • スキーマ 変更が容易なこと
 • インフラ管理しやすいこと
 • コストが安価であること
 ◦ 従量課金など


12. 検討対象 データストア • Aurora y 
 • Elasticache for edis


    • DocumentDB ( ongoDB)
 • Cassandra(EC2構築)
 • DynamoDB
 
 
 
 2020年 3月 検討内容（Amazon eyspaces GA前 ） 


13. 導入検討 大量 データを保存することができる • 良い
 ◦ DynamoDB
 ◦ Cassandra
 ▪

    データ量に対する制約がない
 • 普通
 ◦ Aurora y 
 ◦ DocumentDB
 ▪ 1クラスターで64 Bまでしか対応できない
 • 悪い
 ◦ Elasticache for edis
 ▪ ノードを増やさなけれ 、増えない
 


14. 導入検討 読み込み・書き込み パフォーマンス • 良い
 ◦ DynamoDB
 ◦ Cassandra
 ◦

    Elasticache for edis
 ◦ DocumentDB
 ▪ 基本的にパフォーマンス 良い
 • 悪い
 ◦ Aurora y 
 ▪ 数十億レコードで パフォーマンス 悪化


15. 導入検討 高可用性 • 良い
 ◦ DynamoDB
 ◦ DocumentDB
 ◦ Aurora

    y 
 ◦ Elasticache for edis
 ▪ リージョン内 3A でバックアップ
 • 普通
 ◦ Cassandra
 ▪ 自分たちでバックアップ 管理が必要
 


16. 導入検討 柔軟にスケールできること • 良い
 ◦ DynamoDB
 ▪ 自動的にオートスケール可能
 • 普通


    ◦ Elasticache for edis
 ▪ オンラインでスケールアウト可能
 • 悪い
 ◦ Aurora y 
 ◦ DocumentDB
 ◦ Cassandra
 ▪ オンラインで スケールアップ困難
 


17. 導入検討 容易にスキーマが変更できること • 良い
 ◦ DynamoDB
 ◦ DocumentDB
 ▪ 容易に変更が可能


    • 悪い
 ◦ Aurora y 
 ◦ Cassandra
 ▪ A E AB Eなど 処理が必要
 • 対象外
 ◦ Elasticache for edis
 ▪ スキーマ概念がない
 


18. 導入検討 インフラ管理しやすいこと • 良い
 ◦ DynamoDB
 ▪ インスタンス概念などが無い
 • 普通


    ◦ Elasticache for edis
 ◦ DocumentDB
 ◦ Aurora y 
 ▪ フェイルオーバーなど 管理が必要
 • 悪い
 ◦ Cassandra
 ▪ 自己管理 ため
 


19. 導入検討 コストが安価であること • 良い
 ◦ DynamoDB
 ▪ 従量課金体系
 • 悪い


    ◦ Cassandra
 ◦ Elasticache for edis
 ◦ DocumentDB
 ◦ Aurora y 
 ▪ 最大トラフィック量を予想し、増強が必要
 
 


20. DynamoDBを利用した通知サービス


21. 自己紹介
 u houxun 
 
 
 認証・認可基盤 ユーザー基盤 通知サービス 言語

22. アジェンダ（アプリ編）
 
 1. 通知サービス ビジネス要件
 2. 通知サービスとDynamoDB 相性
 3. データモデルとテーブルデザイン

    4. ブロードキャスティング通知 問題
 5. ips


23. 通知サービス ビジネス要件


24. お知らせページ（ユーザー目線）
 • タイムライン的な ですべて 通知を一元表示 • 通知ごと既読・アーカイブなど 管理 • 無限スクロール

    既読通知 未読通知

25. お知らせページ（サービス目線）
 • とりあえず大量 通知を送りたい • ターゲティング • 特定ユーザー（シングルキャスティング） • すべて

    ユーザー（ブロードキャスティング） • 特定セグメント ユーザー（マルチキャスティング） • など計測したい

26. お知らせページ（パフォーマンス）
 • 大量 通知を処理できること • 日 万～億レベル 新しい通知 • 未読通知

    数を取得 • をサポートすること • ページ単位で通知を取得 • をサポートすること • 通知送信 • なる や（全ユーザーに対して 分以内完了）

27. 通知サービスとDynamoDB 相性


28. クエリーとデータ一貫性
 • 一番複雑そうなクエリー
 ◦ 特定ユーザー 特定カテゴリー 特定状態 通知を取得し、時系列で並ぶ
 • ほとんど最終一貫性で十分


    ◦ どうしても強一貫性が必要な場合 使え よい


29. スケーラビリティ
 • コンピューティングリソース
 ◦ トラフィック ユーザー単位で分散される
 • ストレージリソース
 ◦ 大量ボリューム

    データ 保存が必要
 ◦ データ アーカイビングが可能


30. 開発と運用 簡単さ
 • 基本運用不要
 • 大量な実績
 • 開発者にとって優しい
 ◦ A

    A D ・ドキュメント・サポート
 
 • 結論：DynamoDBが向いてます


31. データモデルとテーブルデザイン


32. データモデル
 • user: 通知 対象ユーザー
 • notification_content: 通知 内容
 •

    category: 通知 種類
 ◦ long_term：お知らせページに残り続ける通知 ◦ short_term：アーカイブされたら二度と表示しない通知（主にユーザーに何 かをしてほしいとき） • status: 通知 状態（既読・アーカイブなど）
 • created_at: timestamp


33. テーブル設計
 • 一般的なやり方：こ データモデルを一つ テーブルに入れる
 ◦ A ベストプラクティス
 • 今回：マルチテーブル


    ◦ 複雑なクエリーを対応するため
 ◦ テーブル自体 設計をシンプルにしたい
 ◦ キャッシュ ため


34. マルチテーブル：複雑なクエリーを対応するため
 • 特定ユーザー 特定カテゴリー 特定状態 通知を取得し、時系列で並 ぶ
 ◦ G 後でも追加できて良いですが…複合インデックス

    大変


35. マルチテーブル：複雑なクエリーを対応するため
 • category#status#created_at というアトリビュートを自分でメンテしな いといけない
 ◦ もし最初からこ クエリー 要件がなかったら、後でバッチで既 存アイテムから作るしかない…


    ◦ あらかじめ全パターンを作っておく 、キャパシティー 無駄 になります
 • 対応：カテゴリーでテーブルを分けてクエリーを簡単にする


36. マルチテーブル：複雑なクエリーを対応するため
 • long termとshort term テーブルを別で作る
 ◦ テーブルとG が簡単になります
 ◦

    テーブルでカテゴリーをクエリーします


37. マルチテーブル：キャッシュ ため
 • 通知 内容(notification_content) 基本送信後変わらない
 • 通知 内容 1

    C サイズ４ B を超えることがあり得る
 • マルチキャスティング時、同じ内容を複数ユーザーに送る
 
 • notification_contentを別テーブルにして、キャッシュする が良い


38. マルチテーブル：キャッシュ ため
 • notification_contentをnotification_templateテーブルに分離
 ◦ content アトリビュートをG プロジェクションから切り離す
 ◦ instance

    アイテムサイズが４ B 以下にできる
 ◦ template アイテムキャッシュが可能に
 ◦ template 再利用が可能に（マルチキャスティングに）


39. マルチテーブル：サマリー


40. ブロードキャスティング通知 問題


41. ブロードキャスティング（書き込み）
 • 大量 ユーザーがいるため、全ユーザー分 通知アイテムを作る が非効率的
 ◦ 通知 内容 全く同様な

    で、broadcast templateテーブルに する
 ◦ statusなど変わる部分がデフォルト値から変わったタイミングで 個人通知アイテムを作成
 
 ブロードキャスティン グ通知 個人宛通知

42. ブロードキャスティング（読み込み）
 • 特定時間帯 broadcast notificationを取得し、notification_instance クエリー結果とマージ
 ◦ query(table=broadcast_notification, created_at between(ts1,

    ts2))
 ブロードキャスティン グ通知 個人宛通知

43. ブロードキャスティング（ホットデータ）
 • ユーザー 常に最新 通知から確認するため、全ユーザー 常 に最新 アイテムをDBから引く
 ◦ 毎回DynamoDBを引くと、全部同じパーティションになる

    で、スケールしない
 ◦ ユーザーによって最新通知 定義がバラバラ で、DA ク エリーキャッシュも使いつらい


44. ブロードキャスティング（ホットデータ）
 • どうしてもDynamoDBを使いたいなら
 ◦ むりやりデータを複数バケットにduplicateした上、 にします
 ◦ リクエストするたびにランダムでバケットを選ぶ
 ◦ バケット

    数でスケールする
 
 • もしく …


45. ブロードキャスティング（キャッシュ）
 • DynamoDBをフォーバックストレージだけに使う
 ◦ edis setでデータをキャッシュし、DynamoDBをフォーバッ クデータストアとして使う
 ◦ edisがミス ときだけDynamoDB引く


46. ips


47. Batch操作
 • batch get itemで通知 内容(template)を取得
 ◦ G で特定通知を取得した後に、１リクエストで全templateを GE

    
 • batch write itemで通知送信処理
 ◦ キューにたまる通知を高速に消化できる
 • 両方ともDA 対応済み
 • ちょっと残念なところ：batch updateがない


48. DA 
 • template アイテムキャッシュとして使用
 ◦ DynamoDB A をそ まま使える

    で、アプリケーション修正 ほぼ不要
 ◦ batch get 一部ミスを対応してくれて素晴らしい
 ◦ レイテンシーを半分以下にし、コスト大幅に削減
 • ちょっと残念なところ
 ◦ など 設定 テーブルごとにできない
 ◦ 実装上特定テーブル・クエリーをDA 抜きにする 工夫が必 要


49. n Demand ode
 • キャパシティー自動的に調整してくれるモード
 ◦ 高負荷状態に一定時間（30分以内）維持すれ 、前 ピーク 二倍までに自動スケールできる


    ◦ 急なスパイクでスロットリングするが、十分以内で24 C 以上 に自動スケールさせた


50. DynamoDB tream
 • y Binlogと似た機能であり、DB変更をストリームにできるサー ビス
 ◦ これを利用してほか A プラットフォームへ

    パイプライン が作れる
 • 通知C など 分析 ため、今検討中


51. 最後に


52. e are hiring!
 20カ国以上から集まった200名以上 メンバー
 • フロントエンドエンジニア • バックエンドエンジニア •

    Androidエンジニア • iOS エンジニア • QA Engineer • Data Engineer • SRE / Platform • Product Security Engineer • QA マニュアルテスト マネージャー • DBA • エンタープライズシステム開発PM/PMO • 不正対策エンジニア • セキュリティエンジニア • 業務推進エンジニア • プロダクトデザイナー

53. e are hiring!
 For open positions contact:[email protected] https://about.paypay.ne.jp/career/ 


    採用ページ こちらから
54. None