新卒1年目が100億レコード超のDBマイグレーションをした話【DeNA TechCon 2023】

youtube：https://youtu.be/SuMRj6K620o

概要：
ライブコミュニケーションアプリ Pococha は、今年1月にサービス開始から6周年を迎えました。
サービスの成長に伴い、データベースの規模も昔とは比較にならないくらい大きくなり、今回マイグレーションを行った Pococha 最大のテーブルは100億レコード以上の規模となっていました。
パフォーマンス観点での課題が顕在化し、データベースの再設計が必要な局面を迎えています。

特に課題のひとつに、テーブルが大規模になるにつれて、インデックス設計やパーティション化が適切に行えていないと、テーブルに対する検索速度が大幅に劣化することがあります。
また、テーブルをマイグレーションするにあたって、ユーザー体験を損なうことがないよう可能な限りダウンタイムを発生させずに行うことが理想的です。

そこで、本セッションでは Pococha 最大規模の100億レコード超テーブルのマイグレーションプロジェクトに手を挙げた私が「なぜマイグレーションしたのか」「ダウンタイムなしでマイグレーションした方法」「障害を起こさないための工夫」について体験から得た学びをお伝えします。

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

Transcript

1. 新卒1年目が100億レコード超の DBマイグレーションをした話 成田 篤基（Atsuki Narita）/ @7riatsu ライブストリーミング事業本部Pococha事業部システム部
2. Table of Contents 1. なぜマイグレーションしたのか 2. ダウンタイムなしでマイグレーションした方法 3. 障害を起こさないための工夫 4. まとめ 2
3. 3 • Pococha はスマホひとつでいつでも・どこでも ライブ配信を通じて誰かの特別な存在になれるアプリ • 配信をするライバーとコメントやアイテムで応援するリスナーの 双方向コミュニケーションサービス
4. 1. なぜマイグレーションしたのか • Pococha は開発開始から6年以上が経過 ◦ サービスの成長に伴い、DB も昔とは比較にならないほど大規模に ◦ パフォーマンス観点で課題が顕在化し、DB の再設計が必要 4
5. • ライバーやリスナー同士の コミュニケーション手段 • Pococha リリース当初から実装 • データは Pococha 最大規模の comments テーブルに保存 コメント機能 5 1. なぜマイグレーションしたのか
6. • comments テーブルが抱えていた課題 Read heavy • Read 処理に多くの時間を要 する • レコードが増えるにつれて slow-query の発生源に 多すぎるレコード数 • 移行完了時のレコード数は 100 億以上！ • 今後もサービス拡大に応じ てレコード数は増え続ける 1. なぜマイグレーションしたのか 6
7. • comments テーブル マイグレーションの目的 Read 処理時間の削減 レコード数の削減 1. なぜマイグレーションしたのか 7
8. RANGE パーティショニング の追加 • 一定期間後、古いデータを まとめて DROP することで レコード数を効率よく削減 • パーティションテーブルの絞り 込みやレコード数の削減によっ て、Read 処理の効率アップ • 目的達成へのアプローチと期待できる効果 1. なぜマイグレーションしたのか • ユースケースにあった インデックス設計にすることで Read 処理の効率アップ • パーティショニングによって レコード数が減り ALTER で インデックス変更が容易に 8 インデックスの再設計
9. • 非 パーティショニング ◦ 全期間分のデータが一つのテーブルに存在 ◦ (例) 2022年4月15日 のコメントデータを探したい ▪ 全期間のデータの中からシークするので非効率的 🙅 9 全期間 1. なぜマイグレーションしたのか
10. • RANGE パーティショニング ◦ 1ヶ月単位でデータを分割して保持 ◦ 古いデータは DROP PARTITION で効率よくパージ（削除）可能 ◦ SELECT 対象のパーティションテーブルを指定したり データ自体を減らすことで Read 処理の効率アップ ◦ デメリット: パーティションをまたぐクエリは非効率かも ◦ (例) 2022年4月15日 のコメントデータを探したい ▪ 「2022/04」範囲だけシークするので効率的 🙆 10 2022/01 2022/02 2022/03 2022/04 2022/05 1. なぜマイグレーションしたのか
11. 1. なぜマイグレーションしたのか 11 • 古いパーティションテーブルをパージする際の注意点 ◦ 集計クエリや過去のデータが使えない場合がある (例) 一度でもコメントしたことのあるユーザーか判定 • 古いデータをパージすると結果が不正確になる可能性 • 集計テーブルを作成しコメントしたことのあるユーザーを保存 • 別のテーブルにロジックを持たせて解決！ ?
12. • 目的とアプローチの再確認 ◦ 目的 ◦ アプローチと期待できる効果 1. なぜマイグレーションしたのか 12 Read 処理時間の削減 レコード数の削減 • レコード数の削減 • Read 処理時間の削減 インデックスの再設計 RANGE パーティショニング の追加 • Read 処理時間の削減
13. 2. ダウンタイムなしでマイグレーションした方法 • フェーズ分けしてリリース（ストラングラーフィグパターン） 13 Strangler Fig Phase 1. Tree Phase 2. Strangler Branch Phase 3. Strangled Tree Phase 4. Strangler Fig
14. • ストラングラーフィグパターンによるシステム移行 レガシー モダン モダン レガシ ー 2. ダウンタイムなしでマイグレーションした方法 14 レガシー モダン 移行前 移行フェーズ1 移行完了 移行フェーズ2 • 徐々に移行することによって、システムが常に稼働した状態を保てる • ダウンタイムを発生させない移行方法
15. 15 2. ダウンタイムなしでマイグレーションした方法 v2_comments テーブル comments テーブル Server Write v2_comments テーブル comments テーブル Server Read / Write Write v2_comments テーブル Server Read / Write フェーズ1 フェーズ2 フェーズ3 Read / Write • v2_comments テーブルを新規作成 • 徐々に comments テーブルの参照から v2_comments テーブルの参照に切り替え • v2_comments テーブルへの過去のデータの移植は必須ではないので行わなかった
16. 16 2. ダウンタイムなしでマイグレーションした方法 v2_comments テーブル comments テーブル Server Write v2_comments テーブル comments テーブル Server Read / Write Write v2_comments テーブル Server Read / Write フェーズ1 フェーズ2 フェーズ3 Read / Write • v2_comments テーブルを作成し、comments テーブルと同様のデータを INSERT ◦ 新しいテーブルにデータを溜める期間 • Read 処理は comments が行い、v2_comments では行わない
17. 17 2. ダウンタイムなしでマイグレーションした方法 v2_comments テーブル comments テーブル Server Write v2_comments テーブル comments テーブル Server Read / Write Write v2_comments テーブル Server Read / Write フェーズ1 フェーズ2 フェーズ3 Read / Write • 全ての Read 処理の向き先を comments から v2_comments テーブルに変更 ◦ comments テーブルに SELECT 句が飛んでいないか監視する期間 • 念の為 comments テーブルにも INSERT する
18. 18 2. ダウンタイムなしでマイグレーションした方法 v2_comments テーブル comments テーブル Server Write v2_comments テーブル comments テーブル Server Read / Write Write v2_comments テーブル Server Read / Write フェーズ1 フェーズ2 フェーズ3 Read / Write • comments テーブルへの INSERT を止めて v2_comments テーブルに完全移行 • Read / Write 処理共に向き先は v2_comments テーブル • 一定期間経過したデータは自動的に DROP PARTITION で効率よくパージ
19. 3. 障害を起こさないための工夫 19 1. テストのない既存機能は先にテストを書く 3. メトリクス監視 2. 影響箇所の洗い出しは丁寧に行う
20. 1. テストのない既存機能は先にテストを書く ◦ テストが書かれていない場合、変更前にテストを追加 ▪ デグレを検知できる体制を作る 3. 障害を起こさないための工夫 20
21. 3. 障害を起こさないための工夫 21 2. 影響箇所の洗い出しは丁寧に行う ◦ コメント機能は Pococha の中でも他機能による参照が多い機能 ◦ 地道に一つずつ時間をかけて調査した（調査だけで1, 2ヶ月） ◦ 今回のプロジェクトでこの調査が一番苦労した
22. Performance Insights クエリが DB 負荷の 原因になっていないか 3. メトリクス監視 リリース後 障害や想定外のエラー が起きていないか 想定外のクエリ発行 / slow-query の監視 例:フェーズ2リリース後 comments テーブルへの SELECT 3. 障害を起こさないための工夫 22 Grafana Amazon RDS
23. • Pococha 最大規模の comments テーブルのマイグレーションを行った ◦ 「レコード数の削減」「Read 処理時間の削減」のために 「インデックスの再設計」「パーティショニングの追加」を実施 • ダウンタイムなしでマイグレーションするためには 徐々に新しいシステムに移行するストラングラーフィグパターンが有効 • 障害を起こさないための工夫 ◦ 1. テストのない既存機能は先にテストを書く ◦ 2. 影響箇所の洗い出しは丁寧に行う ◦ 3. メトリクス監視 4. まとめ 23