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. ay ay通知サービスにおける

    DynamoDB 活用


    西中 智樹

    View full-size slide

  2. 自己紹介

    西中 智樹 ( omoki ishinaka)


    2018年12月より ay ay

    latform team 所属


    好きなA サービス: E 




    View full-size slide

  3. アジェンダ(インフラ編)

    1. ay ayについて

    2. DynamoDB導入 経緯

    3. データストアサービス 比較検討


    View full-size slide

  4. ay ayについて


    View full-size slide

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

    支払い

    ● オフライン決済

    ● オンライン決済/ミニアプリ

    ● 2 と請求書 支払い

       ボーナス運用  

    近く お店

    ● ay ayが利用できるお店が地図一覧
    で分かる


    お知らせ

    ay ayピックアップ

    ● 事前注文テイクアウトサービス

    ay ayフリマ

    タクシーを予約する

    ● DiDi ミニアプリ


    そ 他多数

    ber Eatsミニアプリ 

    ※2020年1月16日 ICT総研調べ「 QRコード決済 利用可能店舗数に関する調査」より

    View full-size slide

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


    View full-size slide

  7. DynamoDB導入 経緯


    View full-size slide

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

    支払い

    ● オフライン決済

    ● オンライン決済/ミニアプリ

    ● 2 と請求書 支払い

       ボーナス運用  

    近く お店

    ● ay ayが利用できるお店が地図一覧
    で分かる


    お知らせ

    ay ayピックアップ

    ● 事前注文テイクアウトサービス

    ay ayモール / フリマ 

    タクシーを予約する

    ● DiDi ミニアプリ


    そ 他多数

    serEatsミニアプリ

    ※2020年1月16日 ICT総研調べ「 QRコード決済 利用可能店舗数に関する調査」より

    View full-size slide

  9. ● ay ay全て 通知を管理する機能

    ○ ay ay残高付与 / キャンペーン / 受け取り/ わりかん 

    ● タイムラインライクで、過去どこまでも確認できるも 

    ● ユーザごとにパーソナライズされたも 

    通知サービス 機能


    View full-size slide

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


    View full-size slide

  11. 通知サービスに必要な要件
    ● 大量 データを保存することができる

    ● 読み込み・書き込み パフォーマンスが良いこと

    ○ 数十億レコードでもパフォーマンス悪化しない

    ● 高可用性なこと

    ● 柔軟にスケールができること

    ● スキーマ 変更が容易なこと

    ● インフラ管理しやすいこと

    ● コストが安価であること

    ○ 従量課金など


    View full-size slide

  12. 検討対象 データストア
    ● Aurora y 

    ● Elasticache for edis

    ● DocumentDB ( ongoDB)

    ● Cassandra(EC2構築)

    ● DynamoDB




    2020年 3月 検討内容(Amazon eyspaces GA前 )

    View full-size slide

  13. 導入検討 大量 データを保存することができる
    ● 良い

    ○ DynamoDB

    ○ Cassandra

    ■ データ量に対する制約がない

    ● 普通

    ○ Aurora y 

    ○ DocumentDB

    ■ 1クラスターで64 Bまでしか対応できない

    ● 悪い

    ○ Elasticache for edis

    ■ ノードを増やさなけれ 、増えない


    View full-size slide

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

    ○ DynamoDB

    ○ Cassandra

    ○ Elasticache for edis

    ○ DocumentDB

    ■ 基本的にパフォーマンス 良い

    ● 悪い

    ○ Aurora y 

    ■ 数十億レコードで パフォーマンス 悪化


    View full-size slide

  15. 導入検討 高可用性
    ● 良い

    ○ DynamoDB

    ○ DocumentDB

    ○ Aurora y 

    ○ Elasticache for edis

    ■ リージョン内 3A でバックアップ

    ● 普通

    ○ Cassandra

    ■ 自分たちでバックアップ 管理が必要


    View full-size slide

  16. 導入検討 柔軟にスケールできること
    ● 良い

    ○ DynamoDB

    ■ 自動的にオートスケール可能

    ● 普通

    ○ Elasticache for edis

    ■ オンラインでスケールアウト可能

    ● 悪い

    ○ Aurora y 

    ○ DocumentDB

    ○ Cassandra

    ■ オンラインで スケールアップ困難


    View full-size slide

  17. 導入検討 容易にスキーマが変更できること
    ● 良い

    ○ DynamoDB

    ○ DocumentDB

    ■ 容易に変更が可能

    ● 悪い

    ○ Aurora y 

    ○ Cassandra

    ■ A E AB Eなど 処理が必要

    ● 対象外

    ○ Elasticache for edis

    ■ スキーマ概念がない


    View full-size slide

  18. 導入検討 インフラ管理しやすいこと
    ● 良い

    ○ DynamoDB

    ■ インスタンス概念などが無い

    ● 普通

    ○ Elasticache for edis

    ○ DocumentDB

    ○ Aurora y 

    ■ フェイルオーバーなど 管理が必要

    ● 悪い

    ○ Cassandra

    ■ 自己管理 ため


    View full-size slide

  19. 導入検討 コストが安価であること
    ● 良い

    ○ DynamoDB

    ■ 従量課金体系

    ● 悪い

    ○ Cassandra

    ○ Elasticache for edis

    ○ DocumentDB

    ○ Aurora y 

    ■ 最大トラフィック量を予想し、増強が必要



    View full-size slide

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


    View full-size slide

  21. 自己紹介

    u houxun 



    認証・認可基盤
    ユーザー基盤
    通知サービス
    言語

    View full-size slide

  22. アジェンダ(アプリ編)


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

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

    3. データモデルとテーブルデザイン
    4. ブロードキャスティング通知 問題

    5. ips


    View full-size slide

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


    View full-size slide

  24. お知らせページ(ユーザー目線)

    • タイムライン的な ですべて 通知を一元表示
    • 通知ごと既読・アーカイブなど 管理
    • 無限スクロール
    既読通知
    未読通知

    View full-size slide

  25. お知らせページ(サービス目線)

    • とりあえず大量 通知を送りたい
    • ターゲティング
    • 特定ユーザー(シングルキャスティング)
    • すべて ユーザー(ブロードキャスティング)
    • 特定セグメント ユーザー(マルチキャスティング)
    • など計測したい

    View full-size slide

  26. お知らせページ(パフォーマンス)

    • 大量 通知を処理できること
    • 日 万~億レベル 新しい通知
    • 未読通知 数を取得
    • をサポートすること
    • ページ単位で通知を取得
    • をサポートすること
    • 通知送信
    • なる や(全ユーザーに対して 分以内完了)

    View full-size slide

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


    View full-size slide

  28. クエリーとデータ一貫性

    ● 一番複雑そうなクエリー

    ○ 特定ユーザー 特定カテゴリー 特定状態 通知を取得し、時系列で並ぶ

    ● ほとんど最終一貫性で十分

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


    View full-size slide

  29. スケーラビリティ

    ● コンピューティングリソース

    ○ トラフィック ユーザー単位で分散される

    ● ストレージリソース

    ○ 大量ボリューム データ 保存が必要

    ○ データ アーカイビングが可能


    View full-size slide

  30. 開発と運用 簡単さ

    ● 基本運用不要

    ● 大量な実績

    ● 開発者にとって優しい

    ○ A A D ・ドキュメント・サポート


    ● 結論:DynamoDBが向いてます


    View full-size slide

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


    View full-size slide

  32. データモデル

    ● user: 通知 対象ユーザー

    ● notification_content: 通知 内容

    ● category: 通知 種類

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

    ● created_at: timestamp


    View full-size slide

  33. テーブル設計

    ● 一般的なやり方:こ データモデルを一つ テーブルに入れる

    ○ A ベストプラクティス

    ● 今回:マルチテーブル

    ○ 複雑なクエリーを対応するため

    ○ テーブル自体 設計をシンプルにしたい

    ○ キャッシュ ため


    View full-size slide

  34. マルチテーブル:複雑なクエリーを対応するため

    ● 特定ユーザー 特定カテゴリー 特定状態 通知を取得し、時系列で並
    ぶ

    ○ G 後でも追加できて良いですが…複合インデックス 大変


    View full-size slide

  35. マルチテーブル:複雑なクエリーを対応するため

    ● category#status#created_at というアトリビュートを自分でメンテしな
    いといけない

    ○ もし最初からこ クエリー 要件がなかったら、後でバッチで既
    存アイテムから作るしかない…

    ○ あらかじめ全パターンを作っておく 、キャパシティー 無駄
    になります

    ● 対応:カテゴリーでテーブルを分けてクエリーを簡単にする


    View full-size slide

  36. マルチテーブル:複雑なクエリーを対応するため

    ● long termとshort term テーブルを別で作る

    ○ テーブルとG が簡単になります

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


    View full-size slide

  37. マルチテーブル:キャッシュ ため

    ● 通知 内容(notification_content) 基本送信後変わらない

    ● 通知 内容 1 C サイズ4 B を超えることがあり得る

    ● マルチキャスティング時、同じ内容を複数ユーザーに送る


    ● notification_contentを別テーブルにして、キャッシュする が良い


    View full-size slide

  38. マルチテーブル:キャッシュ ため

    ● notification_contentをnotification_templateテーブルに分離

    ○ content アトリビュートをG プロジェクションから切り離す

    ○ instance アイテムサイズが4 B 以下にできる

    ○ template アイテムキャッシュが可能に

    ○ template 再利用が可能に(マルチキャスティングに)


    View full-size slide

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


    View full-size slide

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


    View full-size slide

  41. ブロードキャスティング(書き込み)

    ● 大量 ユーザーがいるため、全ユーザー分 通知アイテムを作る
    が非効率的

    ○ 通知 内容 全く同様な で、broadcast templateテーブルに
    する

    ○ statusなど変わる部分がデフォルト値から変わったタイミングで
    個人通知アイテムを作成


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

    View full-size slide

  42. ブロードキャスティング(読み込み)

    ● 特定時間帯 broadcast notificationを取得し、notification_instance
    クエリー結果とマージ

    ○ query(table=broadcast_notification, created_at between(ts1,
    ts2))

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

    View full-size slide

  43. ブロードキャスティング(ホットデータ)

    ● ユーザー 常に最新 通知から確認するため、全ユーザー 常
    に最新 アイテムをDBから引く

    ○ 毎回DynamoDBを引くと、全部同じパーティションになる
    で、スケールしない

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


    View full-size slide

  44. ブロードキャスティング(ホットデータ)

    ● どうしてもDynamoDBを使いたいなら

    ○ むりやりデータを複数バケットにduplicateした上、 にします

    ○ リクエストするたびにランダムでバケットを選ぶ

    ○ バケット 数でスケールする


    ● もしく …


    View full-size slide

  45. ブロードキャスティング(キャッシュ)

    ● DynamoDBをフォーバックストレージだけに使う

    ○ edis setでデータをキャッシュし、DynamoDBをフォーバッ
    クデータストアとして使う

    ○ edisがミス ときだけDynamoDB引く


    View full-size slide

  46. Batch操作

    ● batch get itemで通知 内容(template)を取得

    ○ G で特定通知を取得した後に、1リクエストで全templateを
    GE 

    ● batch write itemで通知送信処理

    ○ キューにたまる通知を高速に消化できる

    ● 両方ともDA 対応済み

    ● ちょっと残念なところ:batch updateがない


    View full-size slide

  47. DA 

    ● template アイテムキャッシュとして使用

    ○ DynamoDB A をそ まま使える で、アプリケーション修正
    ほぼ不要

    ○ batch get 一部ミスを対応してくれて素晴らしい

    ○ レイテンシーを半分以下にし、コスト大幅に削減

    ● ちょっと残念なところ

    ○ など 設定 テーブルごとにできない

    ○ 実装上特定テーブル・クエリーをDA 抜きにする 工夫が必
    要


    View full-size slide

  48. n Demand ode

    ● キャパシティー自動的に調整してくれるモード

    ○ 高負荷状態に一定時間(30分以内)維持すれ 、前 ピーク
    二倍までに自動スケールできる

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


    View full-size slide

  49. DynamoDB tream

    ● y Binlogと似た機能であり、DB変更をストリームにできるサー
    ビス

    ○ これを利用してほか A プラットフォームへ パイプライン
    が作れる

    ● 通知C など 分析 ため、今検討中


    View full-size slide

  50. 最後に


    View full-size slide

  51. e are hiring!

    20カ国以上から集まった200名以上 メンバー

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

    View full-size slide

  52. e are hiring!

    For open positions contact: [email protected]
    https://about.paypay.ne.jp/career/

    採用ページ こちらから

    View full-size slide