Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
KARTE リアルタイムユーザー解析基盤のDB (450TB)をゼロダウンタイムで 新DBに移...
Search
Jun
February 18, 2022
Technology
3
4.1k
KARTE リアルタイムユーザー解析基盤のDB (450TB)をゼロダウンタイムで 新DBに移行したノウハウ
2022 Developer Summit登壇資料
https://event.shoeisha.jp/devsumi/20220217/session/3655/
Jun
February 18, 2022
Tweet
Share
More Decks by Jun
See All by Jun
20230713_PLAID_マルチプロダクトでのデータ分析基盤(集中と分散)
kusahana
0
120
PLAID マルチプロダクト環境下で SLO運用を浸透させるために 20230705
kusahana
0
980
Cloud Bigtable を使いこなす秘訣 2022
kusahana
0
1.6k
Other Decks in Technology
See All in Technology
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.2k
いざ、BSC討伐の旅
nikinusu
2
780
Amazon Personalizeのレコメンドシステム構築、実際何するの?〜大体10分で具体的なイメージをつかむ〜
kniino
1
100
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
Terraform Stacks入門 #HashiTalks
msato
0
350
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
170
The Role of Developer Relations in AI Product Success.
giftojabu1
0
120
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
120
Why App Signing Matters for Your Android Apps - Android Bangkok Conference 2024
akexorcist
0
120
強いチームと開発生産性
onk
PRO
34
11k
DMARC 対応の話 - MIXI CTO オフィスアワー #04
bbqallstars
1
160
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
Featured
See All Featured
Statistics for Hackers
jakevdp
796
220k
KATA
mclloyd
29
14k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
120
Writing Fast Ruby
sferik
627
61k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
How GitHub (no longer) Works
holman
310
140k
How STYLIGHT went responsive
nonsquared
95
5.2k
Thoughts on Productivity
jonyablonski
67
4.3k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Transcript
1 KARTE リアルタイムユーザー解析基盤のDB (450TB)をゼロダウンタイムで 新DBに移⾏したノウハウ 株式会社プレイド ⽇⿐ 旬 ɹɹʛɹɹ© PLAID
Inc. 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ
ɹɹʛɹɹ© 2019 PLAID Inc. 2 ⾃⼰紹介 yyyy.mm.ddɹɹʛɹɹEvent name hereɹɹʛɹ ɹɹʛɹɹ©
PLAID Inc. ⽇⿐ 旬 Kusahana Jun • 株式会社プレイド所属 • Engineer • 2012 ~ 2019: IBMのSE(Web Application/API開発、⾃動テストetc) • 2019/3 ~: プレイド⼊社 • リアルタイム解析基盤チーム(分散システムを初めて触る) • 主にバックエンド系が好き
本⽇のテーマ 3 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. この発表について リアルタイム解析基盤
DB移⾏のきっかけ 移⾏⽅法 発⽣した問題 ・ 教訓 話すこと 👉 リアルタイムユーザー解析基盤 DB移⾏時のノウハウ
⾒出しテキスト 4 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. 今⽇の発表について 今⽇の発表でチャレンジしたいこと
• あんまり世に出ない具体的なDB移⾏⽅法を多くのエンジニアと共有したい • 特に実運⽤した際に発⽣した問題・しくじりから得た教訓を共有したい • ⼤規模なDB移⾏だけじゃなくて、他のDB移⾏にも応⽤できるはず • Disclaimer • NoSQL(Big TableやBig Queryなど)の知識が⼀定程度ある前提
本⽇のテーマ 5 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. この発表について リアルタイム解析基盤
DB移⾏のきっかけ 移⾏⽅法 発⽣した問題 ・ 教訓 話すこと 👉 リアルタイムユーザー解析基盤 DB移⾏時のノウハウ
リアルタイム解析基盤 6 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. ֬ೝ͢Δ جຊαʔϏε͝ར༻ํ๏Λ͝հ͠·͢ɻ
͓ಘͳಛయཱͭใ͕ຬࡌͰ͢ɻ ॳΊͯͷํ ְתּׅ然钠ׅ 6*رؠ؎ش٦ֽוזַזַ♳麦׃זְծ➙ ״إٔؗ،حف׃ְהְֲ倯䗳铣דׅկ UIرؠ؎ش٦ָ濼גֶֻץֹ 7אךرؠ؎ٕٝ٦ٕ DESIGN RULES » CHECK ׆ה⢪ִ،؎ذيֽ䲧ִת׃կ ֿך堣⠓ֶ鋅鷕׃זֻկ 窫㼎ծ 妜׃ְ ౙͷओɺ Ξλʔ COLLECTION OUTER 嗚稊勴⟝㼰׃㢌刿ֽׅדծ֮זך椚 䟝ך暟⟝ח⳿⠓ִ〳腉䚍ָ넝ֻזתׅկ 勴⟝㢌ִג嗚稊׃גגְֻׁկ ׀䋞劄ך暟⟝כ 鋅אַתׇד׃ַ ꟗׄ ⼀⼈⼀⼈に合わせた 顧客体験を提供 Webサイトの訪問者の⾏動を 顧客ごとにリアルタイムに解析 $9 ސ٬ମݧ ϓϥοτϑΥʔϜ
⾒出しテキスト 7 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. リアルタイム解析基盤 リアルタイム解析基盤の概要
本⽇のテーマ 8 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. この発表について リアルタイム解析基盤
DB移⾏のきっかけ 移⾏⽅法 発⽣した問題 ・ 教訓 話すこと 👉 リアルタイムユーザー解析基盤 DB移⾏時のノウハウ
⾒出しテキスト 9 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏のきっかけ より多くユーザーのデータをより早く解析するために
• ゼロベースでリアルタイム解析基盤のアーキテクチャ、ユーザーデータ構造を再設計 • ユーザーデータの構造もあるべき姿に変更され効率化される。。はず(確証はなし)
⾒出しテキスト 10 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏のきっかけ 解析基盤アーキテクチャとユーザーデータDBの移⾏順序
⾒出しテキスト 11 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏のきっかけ ユーザーデータDBだけ先に移⾏する
• リスクは⼤きく勇気はいるが、先に移⾏するメリットしかない • 本当に新データ構造が効率的か早めに確かめることができる • 本当に効率的なら、早く移⾏することでメリットを早く享受できる • 変更要因が⼀つの⽅が問題発⽣時の切り分けが楽になる
本⽇のテーマ 12 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. この発表について リアルタイム解析基盤
DB移⾏のきっかけ 具体的な移⾏⽅法 発⽣した問題 ・ 教訓 話すこと 👉 リアルタイムユーザー解析基盤 DB移⾏時のノウハウ
13 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 ユーザーデータDB移⾏のハードル •
リアルタイム解析サービスの停⽌は基本許容できないため、ゼロダウンタイム前提 • 移⾏不備等によりユーザーデータが壊れると、クリティカルな影響が出る • 本来配信すべきでないエンドユーザーにアクションが誤配信される、全く配信されない • データ量が多く(450TB)、現実的な時間内に移⾏できるのか懸念
14 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 ハードルを乗り越えるためにとったアプローチ •
クライアントごとにユーザーデータを移⾏できるようにする • まずは⼩さく始めてみる • 問題発⽣時の影響範囲を限定的にする • 現・新の検証ステップを設ける • できる限り⾒えている問題は潰す
15 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 ダウンタイムゼロのDB移⾏ 4ステップ
ポイント • クライアント単位で各ステップを経て移⾏する • Read切り替え前に検証ステップを挟むこと
16 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 1. レプリケーション
設計 • 前提 • 頻繁に読み書きされる(定常時でRead: 20K RPS, Write: 8K RPS) • 過去来訪したユーザーデータも漏らさず移⾏する必要がある • Big Tableではクライアントごとの移⾏対象ユーザーの絞り込みはできない • 設計ポイント • リアルタイムでの2重書き込みとバッチ書き込みを組み合わせる • Big Table以外のDBから移⾏対象を絞り込む
17 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 1. レプリケーション
実装 • リアルタイムでの2重書き込み • 移⾏ステップによって処理振り分け • バッチでの書き込み • 移⾏対象ユーザーをBigQueryで事前抽出 • Data fl owで書き込みスループットを調整 • 実⾏順序 • 2重書き込み開始 -> バッチ書き込み
18 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 2. 検証
• 現ユーザーデータを使いつつ、裏側で検証 • 現・新の⼀致確認 • 新データ形式のReadパフォーマンス • 検証結果はモニタリングする
19 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 3. Read切り替え
• 新ユーザーデータから読み込む • 仮に問題があったら、ステップ2に戻れる
20 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 4. Write停⽌
• 現ユーザーデータへの書き込みを停⽌ • もうステップ3には引き返せない
21 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 ダウンタイムゼロのDB移⾏ 4ステップ
ポイント • クライアント単位で各ステップを経て移⾏する • Read切り替え前に検証ステップを挟むこと
22 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. DB移⾏⽅法 移⾏フェーズ 1.
トライアル • 社内⽤サイト、中規模のクライアント数社、⼤規模クライアント⼀社 • まずは⼩さくスタートしつつ、リスクを早く潰すため⼤規模なクライアントに挑戦 2. 横展開 • ⼤規模クライアントを除いた残り全て 3. 最後の仕上げ • ⼤規模クライアント数⼗社
本⽇のテーマ 23 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. この発表について リアルタイム解析基盤
DB移⾏のきっかけ 移⾏⽅法 発⽣した問題 ・ 教訓 話すこと 👉 リアルタイムユーザー解析基盤 DB移⾏時のノウハウ
24 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. トライアルフェーズ バグ潰し、パフォーマンスチューニング繰り返し •
レプリケーション(特にバッチでの書き込み) -> 検証を繰り返す⽇々 • バグが予想以上に出た • 新形式のRead/Writeの不備、現 <-> 新の変換ロジック不備 • パフォーマンスチューニングは最低限にとどめた • 新DBでのBigTableのフィルター条件が複雑すぎて逆に負荷が増⼤ • フィルター条件をシンプルにしてアプリケーション側でフィルタリング • 初期段階ではDB内のデータ分散が⼗分でないため、パフォーマンスが出にくい
25 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. トライアルフェーズ 最初のRead切り替えはリスクテイクして進める •
問題 • 現・新⽐較の⼀致率は100%にはならない・パフォーマンスも若⼲悪い • 対応 • 緩めの最低限の⽬標値達成+検証結果に⾃信もてたらリスクテイクして進めるしかない • クライアントごとの移⾏のため仮に問題があったとしても影響は限定的 • 問題が出てすぐ直せなくとも、検証ステップに引き返せばいい
26 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. 横展開フェーズ 横展開フェーズで起きた問題 1.
デプロイ時の解析処理速度が劇的に悪化 • 移⾏対象増加によるCon fi g肥⼤化が原因 2. 未移⾏クライアントのデータが⼀部⽋損 • アプリケーション側の振り分け処理のバグが原因
27 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. 横展開フェーズ 1. デプロイ時の解析処理速度が劇的に悪化
• 事象 • Con fi gのDB(Big Table)が過負荷状態となりreadパフォーマンスが劇的に悪化 • ⼀定サイズ(不明)を超えるとBig Table内部でキャッシュされなくなった模様 • 対応 • 地道に移⾏対象全てJSファイルにハードコーディングし、デプロイを繰り返した • 得られた教訓・知⾒ • そもそも10%等など刻んで段階的に移⾏すればよかった • 複数の⾏にCon fi gを書き込み、read側を分散させ過負荷を防⽌する⽅法もとり得た
28 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. 横展開フェーズ 2. 未移⾏クライアントのデータが⼀部⽋損
• 事象 • 未移⾏のユーザーデータ更新が意図せずスキップされることがある • 対応 • 振り分け過程でのバグを修正し、影響があったクライアントには連絡済み • 得られた教訓・知⾒ • ユーザーデータがおかしい?という内部調査依頼をタイミング問題と⽚付けてしまった • ⾒えていない問題こそ予兆や違和感に敏感に反応すべきだったが、検証結果を過信した
29 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. 仕上げフェーズ 最後の仕上げフェーズは意外とスムーズ •
当初の懸念 • 本当に全ユーザーデータ移⾏が現実的な時間内で終わるか? • 実際は2週間以内に全て移⾏完了 • 移⾏対象抽出⽤のBigQueryのリソース(Slot)を⼀時的に増やした(Flex Slot) • 書き込みバッチのジョブ並列数を5倍にしてバッチの書き込みスループットを増やした • 考察 • 移⾏が進むにつれ、データが増えて負荷が分散され、⼤量の書き込みに耐えうる状況だった • 当初450TBのDB移⾏は解決困難な問題に⾒えたが、やってみるとさほど問題ではなかった
30 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. 仕上げフェーズ 予想以上にパフォーマンス向上・コスト削減に成功!! •
データ量 • 450TB -> 225TB(不要なデータは移⾏対象から除外 & 圧縮効果) • パフォーマンス • ユーザー取得速度(95 percentile)が100ms程度早くなった • コスト • Big Tableの消費リソース数を30%程度削減した(1⽇辺り20万円程度の削減効果)
31 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. まとめ DB移⾏に際して得た学び •
ハイリスク・ハイリターンな変更(例えばDB移⾏)こそ、勇気を持って個別に早く実施すべき • ⼤きな問題に⾒えても⼩さくスタートし、段階的に進めればなんとかなる • クリティカルな影響がでうる場合は、検証ステップが有効 • どんなに検証したとしても、必ず⾒えていない⾓度から障害は起きうる • 影響範囲を限定的にする設計と、ふとした予兆・違和感を⼤事にすることが重要
32 2022.02.17ɹɹʛɹɹDeveloper Summit 2022ɹɹʛɹ ɹɹʛɹɹ© PLAID Inc. 終わりに 解析基盤全体の移⾏が次のゴール •
DB移⾏で得た学びを活⽤しながら、移⾏設計・検証を進めてる • DB移⾏よりも多くの領域が変更対象となり、よりチャレンジング • 移⾏後に基盤全体の移⾏ノウハウを発表する予定 👉
データによって ⼈の価値を最⼤化する ⼈の発想⼒や柔軟性に敵うアルゴリズムはまだ存在しません。だからこそ、 ⼈の創造性を引き出すテクノロジーで世界を変えていきたいと考えています。 ⼈の柔軟なアイディアや感性をミックスしながら、 「データと⼈の相互作⽤を起こし、 双⽅の価値を最⼤化すること」を⽬指します。 新規プロダクト連続リリースにつき、全職種全⼒採⽤中💪 recruit.plaid.co.jp プレイド採⽤情報
QRίʔυ QRίʔυ 2021/9 公式リリース KARTE Blocks QRίʔυ 2021/9 サービスサイト公開 Qualt Data
None