新卒1年目が100億レコード超の DBマイグレーションをした話 成田 篤基（Atsuki Narita）/ @7riatsu ライブストリーミング事業本部Pococha事業部システム部

Table of Contents 1. なぜマイグレーションしたのか 2. ダウンタイムなしでマイグレーションした方法 3. 障害を起こさないための工夫 4. まとめ 2

3 ● Pococha はスマホひとつでいつでも・どこでも ライブ配信を通じて誰かの特別な存在になれるアプリ ● 配信をするライバーとコメントやアイテムで応援するリスナーの 双方向コミュニケーションサービス

1. なぜマイグレーションしたのか ● Pococha は開発開始から6年以上が経過 ○ サービスの成長に伴い、DB も昔とは比較にならないほど大規模に ○ パフォーマンス観点で課題が顕在化し、DB の再設計が必要 4

● ライバーやリスナー同士の コミュニケーション手段 ● Pococha リリース当初から実装 ● データは Pococha 最大規模の comments テーブルに保存 コメント機能 5 1. なぜマイグレーションしたのか

● comments テーブルが抱えていた課題 Read heavy ● Read 処理に多くの時間を要 する ● レコードが増えるにつれて slow-query の発生源に 多すぎるレコード数 ● 移行完了時のレコード数は 100 億以上！ ● 今後もサービス拡大に応じ てレコード数は増え続ける 1. なぜマイグレーションしたのか 6

● comments テーブル マイグレーションの目的 Read 処理時間の削減 レコード数の削減 1. なぜマイグレーションしたのか 7

RANGE パーティショニング の追加 ● 一定期間後、古いデータを まとめて DROP することで レコード数を効率よく削減 ● パーティションテーブルの絞り 込みやレコード数の削減によっ て、Read 処理の効率アップ ● 目的達成へのアプローチと期待できる効果 1. なぜマイグレーションしたのか ● ユースケースにあった インデックス設計にすることで Read 処理の効率アップ ● パーティショニングによって レコード数が減り ALTER で インデックス変更が容易に 8 インデックスの再設計

● 非 パーティショニング ○ 全期間分のデータが一つのテーブルに存在 ○ (例) 2022年4月15日 のコメントデータを探したい ■ 全期間のデータの中からシークするので非効率的 🙅 9 全期間 1. なぜマイグレーションしたのか

● RANGE パーティショニング ○ 1ヶ月単位でデータを分割して保持 ○ 古いデータは DROP PARTITION で効率よくパージ（削除）可能 ○ SELECT 対象のパーティションテーブルを指定したり データ自体を減らすことで Read 処理の効率アップ ○ デメリット: パーティションをまたぐクエリは非効率かも ○ (例) 2022年4月15日 のコメントデータを探したい ■ 「2022/04」範囲だけシークするので効率的 🙆 10 2022/01 2022/02 2022/03 2022/04 2022/05 1. なぜマイグレーションしたのか

1. なぜマイグレーションしたのか 11 ● 古いパーティションテーブルをパージする際の注意点 ○ 集計クエリや過去のデータが使えない場合がある (例) 一度でもコメントしたことのあるユーザーか判定 ● 古いデータをパージすると結果が不正確になる可能性 ● 集計テーブルを作成しコメントしたことのあるユーザーを保存 ● 別のテーブルにロジックを持たせて解決！ ?

● 目的とアプローチの再確認 ○ 目的 ○ アプローチと期待できる効果 1. なぜマイグレーションしたのか 12 Read 処理時間の削減 レコード数の削減 ● レコード数の削減 ● Read 処理時間の削減 インデックスの再設計 RANGE パーティショニング の追加 ● Read 処理時間の削減

2. ダウンタイムなしでマイグレーションした方法 ● フェーズ分けしてリリース（ストラングラーフィグパターン） 13 Strangler Fig Phase 1. Tree Phase 2. Strangler Branch Phase 3. Strangled Tree Phase 4. Strangler Fig

● ストラングラーフィグパターンによるシステム移行 レガシー モダン モダン レガシ ー 2. ダウンタイムなしでマイグレーションした方法 14 レガシー モダン 移行前 移行フェーズ1 移行完了 移行フェーズ2 ● 徐々に移行することによって、システムが常に稼働した状態を保てる ● ダウンタイムを発生させない移行方法

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 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 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 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 で効率よくパージ

3. 障害を起こさないための工夫 19 1. テストのない既存機能は先にテストを書く 3. メトリクス監視 2. 影響箇所の洗い出しは丁寧に行う

1. テストのない既存機能は先にテストを書く ○ テストが書かれていない場合、変更前にテストを追加 ■ デグレを検知できる体制を作る 3. 障害を起こさないための工夫 20

3. 障害を起こさないための工夫 21 2. 影響箇所の洗い出しは丁寧に行う ○ コメント機能は Pococha の中でも他機能による参照が多い機能 ○ 地道に一つずつ時間をかけて調査した（調査だけで1, 2ヶ月） ○ 今回のプロジェクトでこの調査が一番苦労した

Performance Insights クエリが DB 負荷の 原因になっていないか 3. メトリクス監視 リリース後 障害や想定外のエラー が起きていないか 想定外のクエリ発行 / slow-query の監視 例:フェーズ2リリース後 comments テーブルへの SELECT 3. 障害を起こさないための工夫 22 Grafana Amazon RDS

● Pococha 最大規模の comments テーブルのマイグレーションを行った ○ 「レコード数の削減」「Read 処理時間の削減」のために 「インデックスの再設計」「パーティショニングの追加」を実施 ● ダウンタイムなしでマイグレーションするためには 徐々に新しいシステムに移行するストラングラーフィグパターンが有効 ● 障害を起こさないための工夫 ○ 1. テストのない既存機能は先にテストを書く ○ 2. 影響箇所の洗い出しは丁寧に行う ○ 3. メトリクス監視 4. まとめ 23