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

No content