Tweet
Tweet

Slide 1

Slide 1 text

パーソナライズされた コンテンツ配信のための 低遅延分散KVSの構築 あるいはクライアント中心一貫性とはなにか 第９回 分散システム集会 on VRChat @bootjp / ぶーと

Slide 2

Slide 2 text

本発表は 2020年に@bootjpが本名で書いた 「パーソナライズされた コンテンツ配信のための 低遅延分散KVSの構築」 という論文を解説するものです。

Slide 3

Slide 3 text

本発表は 2020年に@bootjpが本名で書いた 「パーソナライズされた コンテンツ配信のための 低遅延分散KVSの構築」 という論文を解説するものです。

Slide 4

Slide 4 text

アジェンダ ● 本構築手法の背景と課題 ● コンテンツ配信とは ● パーソナライズされたコンテンツ配信とは ● 一般的な分散KVSを用いた際の構成例と問題 ● 既存研究／技術はなにが解決できなかったのか ○ Master/Slave方式の分散KVSを用いた際の構成 ○ キーシャーディングの分散KVSを用いた際の構成 ● 提案手法の紹介 ● 評価 ● おわりに／質疑応答

Slide 5

Slide 5 text

本構築手法の背景と課題 ● 従来のアプリケーションではデータストアにRDBを用いることが多かった ● 一方RDBでは応答速度が要求されるケースでは性能に限界があった ● そこで，応答速度が要求される用途ではKey-Value Store (KVS) が用いられた ● 一般にコンテンツ配信では，複数のアプリケーションノードを用いるため，複数ノー ドのKVSからなる分散KVSを用いる

Slide 6

Slide 6 text

コンテンツ配信とは ● 大量のユーザに対して安定して高速にコンテンツを配信する ● 大量のユーザーに配信するために ○ 複数のアプリケーションノードを用いる ○ 複数のアプリケーションノードへ接続をロードバランサで分散をする ○ 分散KVSを用いてアプリケーションノードのデータ同期を行う ● 代表的なサービス例 ○ Pixiv ○ imgur ○ YouTube ○ ニコニコ動画

Slide 7

Slide 7 text

パーソナライズされたコンテンツ配信とは ● 利便性向上や効果的なマーケティングのために，リッチなコンテンツ配信が求めら れるようになった ● ユーザーごとに異なるデータをユーザからの問い合わせ後に生成してコンテンツを 配信するようになった ● 代表的なシステム例 ○ 広告配信 ○ レコメンデーション ○ 検索エンジン ○ 通知管理システム

Slide 8

Slide 8 text

パーソナライズされたコンテンツ配信とは ● 前述のシステムでは以下の3点を同時に満たす必要がある ○ 高速な応答速度で ○ ユーザー毎に異なるデータを ○ 安定して配信する ● ユーザーごとに異なるデータをユーザからの問い合わせ後に生成し応答 するコンテンツ配信のこと

Slide 9

Slide 9 text

パーソナライズされたコンテンツ配信とは ● 広告配信のRTB(Real Time Bidding)では応答速度に要件があり，多くはネット ワーク遅延を含め100ミリ秒である ● 一般に広告配信アプリケーションの処理は，50ミリ秒以内に収める必要があると言 われている ● したがってコンテンツ配信に用いる分散KVSは以下を満たす必要がある ○ 10ミリ秒以下高速な応答性能 ○ 単一のユーザに一貫性のあるデータの提供 ○ 2つの要素を安定して提供する

Slide 10

Slide 10 text

一般的な分散KVSを用いた際の構成例と問題

Slide 11

Slide 11 text

一般的な分散KVSを用いた際の構成例と問題

Slide 12

Slide 12 text

一般的な分散KVSを用いた際の構成例と問題 ● ネットワーク越しの問い合わ せになるため応答速度が遅 い ● 問い合わせ数が増えると応 答速度が低下する

Slide 13

Slide 13 text

一般的な分散KVSを用いた際の構成例と問題

Slide 14

Slide 14 text

一般的な分散KVSを用いた際の構成例と問題 ● 分散KVSノードのデータ同期 に遅延が発生する

Slide 15

Slide 15 text

一般的な分散KVSを用いた際の構成例と問題 ● 分散KVSはネットワーク越しの問い合わせになるため応答速度が遅い ● 問い合わせ数が増加すると応答速度が低下する ● 更新クエリが増えると分散KVSのレプリケーション通信がボトルネックとな りデータの同期で遅延が発生する

Slide 16

Slide 16 text

既存研究／技術はなにが解決できなかったのか ● 同期遅延 ○ Master/Slave方式の分散KVSのSlaveをアプリケーションノードの置くことで解決 ○ ⇢レプリケーションラグが発生する ● 応答速度の遅延 ○ キーシャーディング方式の分散KVSを用いることで分割統治により同期を省くことができ る ○ ⇢アプリケーションノードと同一ノードにデータをもつ分散 KVSは配置できない

Slide 17

Slide 17 text

既存研究／技術はなにが解決できなかったのか ● 同期遅延 ○ Master/Slave方式の分散KVSのSlaveをアプリケーションノードの置くことで解決 ○ ⇢レプリケーションラグが発生する

Slide 18

Slide 18 text

Master/Slave方式の分散KVSを用いた際の構成例

Slide 19

Slide 19 text

Master/Slave方式の分散KVSを用いた際の構成例 ● レプリケーションラグが発生し ，必ずしも最新のデータがか えらない

Slide 20

Slide 20 text

既存研究／技術はなにが解決できなかったのか ● 応答速度の遅延 ○ キーシャーディング方式の分散KVSを用いることで分割統治により同期を省くことができ る ○ ⇢アプリケーションノードと同一ノードにデータをもつ分散 KVSは配置できない

Slide 21

Slide 21 text

キーシャーディングの分散KVSを用いた際の構成

Slide 22

Slide 22 text

キーシャーディングの分散KVSを用いた際の構成 ● シャーディングの場合必ずし も同一ノードのKVSにデータ があるとは限らないため遅延 が発生する ● 別ノードへ取得に行く場合は 大きく遅延するため, 安定した性能とはいえない

Slide 23

Slide 23 text

既存研究／技術はなにが解決できなかったのか ● 同期遅延 ○ Master/Slave方式の分散KVSのSlaveをアプリケーションノードの置くことで解決 ○ ⇢レプリケーションラグが発生する ● 応答速度の遅延 ○ キーシャーディング方式の分散KVSを用いることで分割統治により同期を省くことができ る ○ ⇢アプリケーションノードと同一ノードにデータをもつ分散 KVSは配置できない

Slide 24

Slide 24 text

提案手法 - アプローチ ● 応答性能の確保 ○ 分散KVS をコンテンツ配信アプリケーションと同一のノードに配置する ○ プロセス間通信でデータを交換することでネットワーク遅延を廃する ● 単一ユーザの一貫性の確保 ○ ロードバランサでユーザのコンテンツ配信アプリケーションへの接続を常に同一ノードに 固定する ○ 以降ユーザには同一ノードで一貫性のあるデータ提供する ○ この状態を一貫性モデルの1つ，クライアント中心一貫性を確保しているに等しい状態で ある

Slide 25

Slide 25 text

提案手法 - 構成図

Slide 26

Slide 26 text

評価 - 概要 ● 評価を行うためプロトタイプの実装を行った ○ memcached互換のプロトコルで通信できる分散 KVSをGo言語で実装した ○ ロードバランサの機能を用いてユーザの接続先ノードの固定した ○ 実装は以下のリポジトリで公開している ■ https://github.com/bootjp/turbo-ubiquitous-store ● 評価は2つの観点から行う ○ 既存技術との応答速度の比較 ○ 単一ユーザにおいて一貫性が保証できているか

Slide 27

Slide 27 text

評価 - 応答速度 ● 提案手法の応答時間を評価する ● 既存技術であるRedisの応答時間を評価し提案手法と比較する ● 評価には memtier_benchmark を用いた ● 実際の環境を模倣し以下の環境で評価をした． ○ 既存手法は単一ノードに別ノードよりネットワーク経由 ○ 提案手法は単一ノードないにおいての Unix Domain SocketでのIPCでの評価 ● memtier_benchmark の引数は以下の通り ○ --threads=16 --requests=10000 ○ 並列パイプライン数（--pipeline） は1 ~ 10で変化させた

Slide 28

Slide 28 text

評価 - 応答速度

Slide 29

Slide 29 text

評価 - 応答速度 既存技術と比較し，平均 し10ms以上の高速化 要件の10ms以下の応 答速度の達成

Slide 30

Slide 30 text

評価 - 応答速度 まとめ ● 提案手法と既存技術のRedisの平均応答時間は ○ 提案手法が 4.32ミリ秒 ○ Redisが16.79ミリ秒 ● 提案手法による10ミリ秒以上の応答の高速化を確認した． ● 既存技術では応答時間の要件を満たせない一方，提案手法では要件を容 易に充足できることも確認した

Slide 31

Slide 31 text

評価 - 一貫性 ● 提案手法でユーザ単位のデータの一貫性を確認する ● 評価に用いる以下の仕様の実験用アプリケーションを作成した ○ ユーザーの識別子ごとに何回のアクセスがあったかを分散 KVSに記録し，最新の値を分 散KVSから取得しレスポンスする ○ これを複数ノード配置し前段にロードバランサによりロードバランスを

Slide 32

Slide 32 text

評価 - 一貫性 ● 評価方法 ○ クライアント側が計測しているリクエスト回数と分散 KVSで計測された数を比較し一貫性 の評価を行った ○ 100並列の各100回のリクエストを行った

Slide 33

Slide 33 text

評価 - 一貫性 まとめ ● 実験の結果，クライアントがリクエストした回数とレスポンスの結果は常に 一致しており，クライアント自身が書き込んだ値を読み出すことができる一 貫性が正しく機能していることを確認した

Slide 34

Slide 34 text

おわりに ● 実験では応答速度の要件を満たし，既存技術と比較し平均応答速度が10 ミリ秒以上高速化された． ● 一貫性においてはクライアント中心一貫性が正しく確保できていることを確 認した ● 提案手法では今後の課題として，ノードダウン時や入替時の一貫性の担 保がある

Slide 35

Slide 35 text

質疑応答