1.6K Views
February 29, 24
スライド概要
DeNA が提供するライブ配信アプリ『Pococha』は、50万以上の月間ユニークユーザーを抱える大規模アプリです。Pococha は配信者と視聴者の相互コミュニケーションを重要視しており、ピーク時にはコメント(ライブチャット)は毎時100万件以上にも上り、テーブルにかかる書き込み負荷が非常に高いです。しかしこのコメントテーブルは単一のメインデータベースに保存されていたので、アプリケーション全体へ悪影響を及ぼしていました。
本登壇では、技術基盤チームで業務を行っていた登壇者が最適な ID 形態を設計し、コメントテーブルをユーザごとのデータベースにシャーディングし、サービス全体の負荷を軽減させたことについてお話します。
DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。
大規模配信サービスのコメントテーブルをシャーディングした話 © DeNA Co., Ltd.
⾃⼰紹介 nagataaaas 永⽥ ⼤和 (Nagata Yamato) ‧2022年に⾼専卒業‧新卒⼊社、研修後Pococha技術基盤チー ムに配属 ‧2023年7⽉にアジャイル開発チームに異動 ‧好きな⾔語はPython(⽣まれたてのヒナが初めてみたモノを 親と思うアレ) © DeNA Co., Ltd. 2
やってきたこと ⾼専⼊学 フリーランスに インターンシップ @ DeNA 2018/08 2017/04 © DeNA Co., Ltd. 2022/10 2022/03 2019/08 インターンシップ @ LINE様 アジャイル開発 チームに異動 2022新卒エンジニア としてPocochaに配属 2023/07 2022/07 ⾼専卒業 社会の荒波に 揉まれ始める 本発表で話す コメントテーブル のシャーディング 施策を⾏う 3
⽬次 1. Pocochaについて 2. シャーディングの⽬的 3. 他テーブルからの参照‧リレーションの対応 4. シャーディングのためのID形態 5. ダウンタイムなしのマイグレーション⽅法 6. まとめ © DeNA Co., Ltd. 4
1. Pocochaについて 「自分らしさ」を発揮し、スマホ一つで誰かにとって 特別な存在になれるライブコミュニケーションアプリ © DeNA Co., Ltd. 5
1. Pocochaについて Pocochaは急⾓度のグロースを 経験している ● コロナでの巣篭もり需要から、ライブスト リーミングアプリ⾃体が全体的に伸びた ● リリースから数百%単位でのグロースが続 き、アプリの規模に対して追いついていない アーキテクチャになっている部分がある ● 特にチャット機能(コメント)を⽤いた 双⽅向コミュニケーションを主軸において おり、コメント周りの負荷が甚⼤ © DeNA Co., Ltd. 6
2. シャーディングの⽬的 そもそもシャーディングって? © DeNA Co., Ltd. ● ⽔平分割ともよばれる ● 単⼀のテーブル⾃体を複数のデータベースに分散させる ● 各シャードは同じテーブル構造だが、保存されているレコードが異なる 7
2. シャーディングの⽬的 �� © DeNA Co., Ltd. 8
2. シャーディングの⽬的 メインDB comments user_id © DeNA Co., Ltd. body 1 よ 2 はろー 1 こんちゃ 4 Python! 2 Dena? 9
2. サブDB 1 メインDB シャーディングの⽬的 サブDB 2 comments user_id © DeNA Co., Ltd. body 1 よ 2 はろー 1 こんちゃ 4 Python! 2 Dena? 10
2. サブDB 1 メインDB サブDB 2 comments comments comments user_id © DeNA Co., Ltd. シャーディングの⽬的 body user_id body 1 よ 2 はろー 1 こんちゃ 4 Python! 2 Dena? user_id body 11
2. サブDB 1 メインDB サブDB 2 comments comments comments user_id 4 © DeNA Co., Ltd. シャーディングの⽬的 body Python! user_id body user_id body 1 よ 2 はろー 1 こんちゃ 2 Dena? 12
2. シャーディングの⽬的 メインDB users lives shard_mapping … user2 user3 some_table some_table some_table some_table2 some_table2 some_table2 … … … © DeNA Co., Ltd. user1 … 13
2. シャーディングの⽬的 シャーディングすると何が嬉しいの? © DeNA Co., Ltd. ● スケールが簡単にできる ● DBが⼀つ落ちても他のシャードが⽣きていれば、サービス停⽌を回避 できる(場合がある) ● 擬似的に負荷を 1/(シャード数)に落とすことができる 14
2. シャーディングの⽬的 今回は... 書き込み負荷が⾼いコメントテーブルをシャーディング することでサービス全体のパフォーマンスを向上させる! のが⽬的 © DeNA Co., Ltd. 15
3. 他テーブルからの参照‧リレーションの対応 影響範囲の確認 1. 配信に対してコメントは紐づいている 2. ユーザの規約違反履歴の管理のために ポリモーフィックで関連付けされている © DeNA Co., Ltd. 16
3. 他テーブルからの参照‧リレーションの対応 規約違反履歴テーブルのポリモーフィズムは メインDBにしか対応していないので シャーディングに対応させる必要 © DeNA Co., Ltd. 17
3. 他テーブルからの参照‧リレーションの対応 カラム名 型 カラム名 型 id bigint id bigint review_target_id bigint (NotNull) review_target_id bigint (Null) review_target_type text (NotNull) review_target_type text (Null) user_shard_review_target_id char (Null) user_shard_review_target_type text (Null) ひと安⼼... © DeNA Co., Ltd. 18
3. 他テーブルからの参照‧リレーションの対応 ちょっとまって! © DeNA Co., Ltd. 19
3. 他テーブルからの参照‧リレーションの対応 どのシャードかわからなくない? © DeNA Co., Ltd. 20
3. 他テーブルからの参照‧リレーションの対応 ちょっとまって! © DeNA Co., Ltd. 21
3. 他テーブルからの参照‧リレーションの対応 既存のコードからめちゃくちゃ変わっちゃわない? © DeNA Co., Ltd. 22
3. 他テーブルからの参照‧リレーションの対応 IDにシャード番号も⼊れちゃう...? © DeNA Co., Ltd. 23
4. シャーディングのためのID形態 まず型を決めよう! © DeNA Co., Ltd. 24
4. シャーディングのためのID形態 既存のPKたちは... ● CHAR (26) ● BIGINT (auto increment) © DeNA Co., Ltd. 25
4. シャーディングのためのID形態 BIGINTを使うとしたら... AUTO INCREMENTをなくす + タイムスタンプ‧シャード情報を追加 + インクリメント処理⼿動実装 or ランダム実装 © DeNA Co., Ltd. 26
4. シャーディングのためのID形態 BIGINTを使うとしたら... ● インクリメント処理⼿動実装 → ● 書き込み時にテーブルを⼿動ロック&insert完了まで離さない ランダム実装 → タイムスタンプ部を42bit‧shard部を8bitとすると、たかだ か14bit 🙅 © DeNA Co., Ltd. 27
4. シャーディングのためのID形態 よし、ULIDベースだ! © DeNA Co., Ltd. 28
4. シャーディングのためのID形態 ULIDとは... 48bitのタイムスタンプと、80bitのランダム 画像: ulid spec (https://github.com/ulid/spec) © DeNA Co., Ltd. 29
4. シャーディングのためのID形態 最終的な形態 48bitのタイムスタンプ、10bitのシャード、80bitのランダム © DeNA Co., Ltd. 30
4. シャーディングのためのID形態 全エンジニアのために... make it a metaclass © DeNA Co., Ltd. 31
5. ダウンタイムなしのマイグレーション⽅法 よし、マイグレーションだ! © DeNA Co., Ltd. 32
5. ダウンタイムなしのマイグレーション⽅法 引⽤:新卒1年⽬が100億レコード超のDBマイグレーションをした話【DeNA TechCon 2023】 © DeNA Co., Ltd. 33
5. ● ● © DeNA Co., Ltd. ダウンタイムなしのマイグレーション⽅法 v2_commentsテーブルを作成し、commentsと同様のデータをinsert ○ 新しいテーブルにデータを貯める時間 Read処理はcommentsテーブルで⾏い、v2_commentsでは⾏わない 34
5. ● ● © DeNA Co., Ltd. ダウンタイムなしのマイグレーション⽅法 全てのReadの向き先をv2_commentsに変更 ○ commentsに処理が向いていないかを確かめる期間 念の為commentsテーブルにもデータは書き込む 35
5. ● © DeNA Co., Ltd. ダウンタイムなしのマイグレーション⽅法 commentsテーブルへのデータ書き込みを完全に止める ○ サービスに関するクエリは全てv2_commentsを⽤いる 36
まとめ ● 負荷が⾼くて困っている時はシャーディングもあり ○ ⼯夫次第で、最⼩限の労⼒で⼤きな効果を発揮できる ● ダウンタイムなしでマイグレーションするには ○ 新しいシステムに徐々に移⾏していくと⼿戻りが少ない ● サービスの将来性のために ○ 特別すぎることはしない。でも、守りすぎてもいけない ○ 改修の影響範囲は少なめに ○ シンプルにとどめる © DeNA Co., Ltd. 37