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

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

自己紹介  西中智樹 ( omoki ishinaka)    2018年12月より ay ay 
latform team 所属    好きなA サービス: E        

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

ay ayについて 

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

日本 o.1 決済サービス 

DynamoDB導入経緯 

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

• ay ay全て通知を管理する機能  ◦ ay ay残高付与 / キャンペーン /
受け取り/ わりかん   • タイムラインライクで、過去どこまでも確認できるも   • ユーザごとにパーソナライズされたも   通知サービス機能 

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

通知サービスに必要な要件 • 大量データを保存することができる  • 読み込み・書き込みパフォーマンスが良いこと  ◦ 数十億レコードでもパフォーマンス悪化しない  
• 高可用性なこと  • 柔軟にスケールができること  • スキーマ変更が容易なこと  • インフラ管理しやすいこと  • コストが安価であること  ◦ 従量課金など 

検討対象データストア • Aurora y   • Elasticache for edis 
• DocumentDB ( ongoDB)  • Cassandra(EC2構築)  • DynamoDB        2020年 3月検討内容（Amazon eyspaces GA前）  

導入検討大量データを保存することができる • 良い  ◦ DynamoDB  ◦ Cassandra  ▪
データ量に対する制約がない  • 普通  ◦ Aurora y   ◦ DocumentDB  ▪ 1クラスターで64 Bまでしか対応できない  • 悪い  ◦ Elasticache for edis  ▪ ノードを増やさなけれ、増えない   

導入検討読み込み・書き込みパフォーマンス • 良い  ◦ DynamoDB  ◦ Cassandra  ◦
Elasticache for edis  ◦ DocumentDB  ▪ 基本的にパフォーマンス良い  • 悪い  ◦ Aurora y   ▪ 数十億レコードでパフォーマンス悪化 

導入検討高可用性 • 良い  ◦ DynamoDB  ◦ DocumentDB  ◦ Aurora
y   ◦ Elasticache for edis  ▪ リージョン内 3A でバックアップ  • 普通  ◦ Cassandra  ▪ 自分たちでバックアップ管理が必要   

導入検討柔軟にスケールできること • 良い  ◦ DynamoDB  ▪ 自動的にオートスケール可能  • 普通 
◦ Elasticache for edis  ▪ オンラインでスケールアウト可能  • 悪い  ◦ Aurora y   ◦ DocumentDB  ◦ Cassandra  ▪ オンラインでスケールアップ困難   

導入検討容易にスキーマが変更できること • 良い  ◦ DynamoDB  ◦ DocumentDB  ▪ 容易に変更が可能 
• 悪い  ◦ Aurora y   ◦ Cassandra  ▪ A E AB Eなど処理が必要  • 対象外  ◦ Elasticache for edis  ▪ スキーマ概念がない   

導入検討インフラ管理しやすいこと • 良い  ◦ DynamoDB  ▪ インスタンス概念などが無い  • 普通 
◦ Elasticache for edis  ◦ DocumentDB  ◦ Aurora y   ▪ フェイルオーバーなど管理が必要  • 悪い  ◦ Cassandra  ▪ 自己管理ため   

導入検討コストが安価であること • 良い  ◦ DynamoDB  ▪ 従量課金体系  • 悪い 
◦ Cassandra  ◦ Elasticache for edis  ◦ DocumentDB  ◦ Aurora y   ▪ 最大トラフィック量を予想し、増強が必要     

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

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

アジェンダ（アプリ編）    1. 通知サービスビジネス要件  2. 通知サービスとDynamoDB 相性  3. データモデルとテーブルデザイン
4. ブロードキャスティング通知問題  5. ips 

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

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

お知らせページ（サービス目線）  • とりあえず大量通知を送りたい • ターゲティング • 特定ユーザー（シングルキャスティング） • すべて
ユーザー（ブロードキャスティング） • 特定セグメントユーザー（マルチキャスティング） • など計測したい

お知らせページ（パフォーマンス）  • 大量通知を処理できること • 日万～億レベル新しい通知 • 未読通知
数を取得 • をサポートすること • ページ単位で通知を取得 • をサポートすること • 通知送信 • なるや（全ユーザーに対して分以内完了）

通知サービスとDynamoDB 相性 

クエリーとデータ一貫性  • 一番複雑そうなクエリー  ◦ 特定ユーザー特定カテゴリー特定状態通知を取得し、時系列で並ぶ  • ほとんど最終一貫性で十分 
◦ どうしても強一貫性が必要な場合使えよい 

スケーラビリティ  • コンピューティングリソース  ◦ トラフィックユーザー単位で分散される  • ストレージリソース  ◦ 大量ボリューム
データ保存が必要  ◦ データアーカイビングが可能 

開発と運用簡単さ  • 基本運用不要  • 大量な実績  • 開発者にとって優しい  ◦ A
A D ・ドキュメント・サポート    • 結論：DynamoDBが向いてます 

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

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

テーブル設計  • 一般的なやり方：こデータモデルを一つテーブルに入れる  ◦ A ベストプラクティス  • 今回：マルチテーブル 
◦ 複雑なクエリーを対応するため  ◦ テーブル自体設計をシンプルにしたい  ◦ キャッシュため 

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

マルチテーブル：複雑なクエリーを対応するため  • category#status#created_at というアトリビュートを自分でメンテしないといけない  ◦ もし最初からこクエリー要件がなかったら、後でバッチで既存アイテムから作るしかない… 
◦ あらかじめ全パターンを作っておく、キャパシティー無駄になります  • 対応：カテゴリーでテーブルを分けてクエリーを簡単にする 

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

マルチテーブル：キャッシュため  • 通知内容(notification_content) 基本送信後変わらない  • 通知内容 1
C サイズ４ B を超えることがあり得る  • マルチキャスティング時、同じ内容を複数ユーザーに送る    • notification_contentを別テーブルにして、キャッシュするが良い 

マルチテーブル：キャッシュため  • notification_contentをnotification_templateテーブルに分離  ◦ content アトリビュートをG プロジェクションから切り離す  ◦ instance
アイテムサイズが４ B 以下にできる  ◦ template アイテムキャッシュが可能に  ◦ template 再利用が可能に（マルチキャスティングに） 

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

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

ブロードキャスティング（書き込み）  • 大量ユーザーがいるため、全ユーザー分通知アイテムを作るが非効率的  ◦ 通知内容全く同様な
で、broadcast templateテーブルにする  ◦ statusなど変わる部分がデフォルト値から変わったタイミングで個人通知アイテムを作成    ブロードキャスティング通知個人宛通知

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

ブロードキャスティング（ホットデータ）  • ユーザー常に最新通知から確認するため、全ユーザー常に最新アイテムをDBから引く  ◦ 毎回DynamoDBを引くと、全部同じパーティションになる
で、スケールしない  ◦ ユーザーによって最新通知定義がバラバラで、DA クエリーキャッシュも使いつらい 

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

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

ips 

Batch操作  • batch get itemで通知内容(template)を取得  ◦ G で特定通知を取得した後に、１リクエストで全templateを GE
  • batch write itemで通知送信処理  ◦ キューにたまる通知を高速に消化できる  • 両方ともDA 対応済み  • ちょっと残念なところ：batch updateがない 

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

n Demand ode  • キャパシティー自動的に調整してくれるモード  ◦ 高負荷状態に一定時間（30分以内）維持すれ、前ピーク二倍までに自動スケールできる 
◦ 急なスパイクでスロットリングするが、十分以内で24 C 以上に自動スケールさせた 

DynamoDB tream  • y Binlogと似た機能であり、DB変更をストリームにできるサービス  ◦ これを利用してほか A プラットフォームへ
パイプラインが作れる  • 通知C など分析ため、今検討中 

最後に 

e are hiring!  20カ国以上から集まった200名以上メンバー  • フロントエンドエンジニア • バックエンドエンジニア •
Androidエンジニア • iOS エンジニア • QA Engineer • Data Engineer • SRE / Platform • Product Security Engineer • QA マニュアルテストマネージャー • DBA • エンタープライズシステム開発PM/PMO • 不正対策エンジニア • セキュリティエンジニア • 業務推進エンジニア • プロダクトデザイナー

e are hiring!  For open positions contact: [email protected] https://about.paypay.ne.jp/career/  
採用ページこちらから

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

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

More Decks by PayPay

Other Decks in Technology

Featured

Transcript