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

343e1356053327aa64bcb4aa39bb6cc2?s=47 PayPay
August 25, 2020

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

Presented by: Tomoki Nishinaka, Yu Zhouxun

PayPayの機能の一つとして2020年4月に新たにリリースされた通知サービスでは、スケーラビリティとパフォーマンスを重視し、数々のデータストアソリューションの中からDynamoDBを採用しました。通知センターの設計からリリースまでにおける検討プロセスや、DynamoDBを使った開発/運用手法、及びテーブル設計のtipsについてご紹介します。

343e1356053327aa64bcb4aa39bb6cc2?s=128

PayPay

August 25, 2020
Tweet

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

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

    アイテムサイズが4 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 で特定通知を取得した後に、1リクエストで全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: momoko.hayakawa@paypay-corp.co.jp https://about.paypay.ne.jp/career/ 


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