Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

PayPay
August 25, 2020

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

Presented by: Tomoki Nishinaka, Yu Zhouxun

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

PayPay

August 25, 2020
Tweet

More Decks by PayPay

Other Decks in Technology

Transcript

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


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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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

    ユーザー(ブロードキャスティング) • 特定セグメント ユーザー(マルチキャスティング) • など計測したい
  15. お知らせページ(パフォーマンス)
 • 大量 通知を処理できること • 日 万~億レベル 新しい通知 • 未読通知

    数を取得 • をサポートすること • ページ単位で通知を取得 • をサポートすること • 通知送信 • なる や(全ユーザーに対して 分以内完了)
  16. 開発と運用 簡単さ
 • 基本運用不要
 • 大量な実績
 • 開発者にとって優しい
 ◦ A

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

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

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

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


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

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

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

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

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

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

    で、broadcast templateテーブルに する
 ◦ statusなど変わる部分がデフォルト値から変わったタイミングで 個人通知アイテムを作成
 
 ブロードキャスティン グ通知 個人宛通知
  22. Batch操作
 • batch get itemで通知 内容(template)を取得
 ◦ G で特定通知を取得した後に、1リクエストで全templateを GE

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

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

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

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

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