Presented by: Tomoki Nishinaka, Yu Zhouxun
PayPayの機能の一つとして2020年4月に新たにリリースされた通知サービスでは、スケーラビリティとパフォーマンスを重視し、数々のデータストアソリューションの中からDynamoDBを採用しました。通知センターの設計からリリースまでにおける検討プロセスや、DynamoDBを使った開発/運用手法、及びテーブル設計のtipsについてご紹介します。
ay ay通知サービスにおける DynamoDB 活用 西中 智樹
View Slide
自己紹介 西中 智樹 ( 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
matyuda
you
rponte
nagauta
jfg956
tenforward
naoto_pq
goyoki
takagimeow
hikarut
shogo452
sat
erikaheidi
tmm1
caitiem20
holman
maggiecrowley
notwaldorf
brianwarren
samanthasiow
samlambert
jensimmons
mza
trishagee