Tweet
Tweet

Slide 1

Slide 1 text


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


Slide 2

Slide 2 text

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


Slide 3

Slide 3 text

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


Slide 4

Slide 4 text

ay ayについて


Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

日本 o.1 決済サービス


Slide 7

Slide 7 text

DynamoDB導入 経緯


Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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


Slide 10

Slide 10 text

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


Slide 11

Slide 11 text

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


Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

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


Slide 14

Slide 14 text

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


Slide 15

Slide 15 text

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


Slide 16

Slide 16 text

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


Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

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


Slide 19

Slide 19 text

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


Slide 20

Slide 20 text

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


Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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


Slide 23

Slide 23 text

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


Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

通知サービスとDynamoDB 相性


Slide 28

Slide 28 text

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


Slide 29

Slide 29 text

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


Slide 30

Slide 30 text

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


Slide 31

Slide 31 text

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


Slide 32

Slide 32 text

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


Slide 33

Slide 33 text

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


Slide 34

Slide 34 text

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


Slide 35

Slide 35 text

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


Slide 36

Slide 36 text

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


Slide 37

Slide 37 text

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


Slide 38

Slide 38 text

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


Slide 39

Slide 39 text

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


Slide 40

Slide 40 text

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


Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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


Slide 44

Slide 44 text

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


Slide 45

Slide 45 text

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


Slide 46

Slide 46 text

ips


Slide 47

Slide 47 text

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


Slide 48

Slide 48 text

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


Slide 49

Slide 49 text

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


Slide 50

Slide 50 text

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


Slide 51

Slide 51 text

最後に


Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

e are hiring!
 For open positions contact: momoko.hayakawa@paypay-corp.co.jp https://about.paypay.ne.jp/career/ 
 採用ページ こちらから

Slide 54

Slide 54 text

No content