Pocochaを支えるバックエンド 〜アーキテクチャとDBシャーディング〜【DeNA TechCon 2021】/techcon2021-3

新たな事業を成功させるためには、少人数で高速に機能をリリースしながら仮説検証を行ったり、増えていく利用者のための負荷対策を行ったり、可能であれば外部のソリューションを活用する必要があります。

DeNA のソーシャルライブサービスである Pococha では、小規模チームと限られた予算で高速に機能をリリースし、Amazon IVS などの外部ソリューションも活用しながら、仮説検証を繰り返すことでサービスを拡大させてきました。

また昨今では巣ごもり需要の影響も受け、Pococha は急激に成長しました。非常に多くの方々にご利用いただいた結果、スケールアップでは対応できない規模の負荷をさばく必要が出て来ました。

本セッションでは Pococha がどのような体制やシステム、工夫でこれらの課題を解決してきたのか、Pococha の裏側をご紹介します。

Transcript

1. 佐藤 琢斗 Pocochaを支えるバックエンド 〜アーキテクチャとDBシャーディング〜
2. この発表を聞くとわかること 1. ソーシャルライブサービスを支える 　 バックエンドの技術構成がわかる 2. リソースの限られた新規事業で 　 何を重視して開発してきたかわかる 3. DB書き込み負荷対策のために 　どのようにシャーディングを行ったかわかる
3. アジェンダ 1章. 自己紹介 2章. Pocochaとは？ 3章. Pocochaのバックエンド構成 4章. Pocochaのはじまり 〜限られたリソースとユーザー価値〜 5章. 急成長とDB負荷とシャーディング 6章. まとめとPocochaのこれから
4. アジェンダ 1章. 自己紹介 2章. Pocochaとは？ 3章. Pocochaのバックエンド構成 4章. Pocochaのはじまり 〜限られたリソースとユーザー価値〜 5章. 急成長とDB負荷とシャーディング 6章. まとめとPocochaのこれから
5. 自己紹介 佐藤 琢斗 / Takuto Sato (tockn) ・2020年DeNA新卒入社（1年目） ・Pocochaシステム部 ・Pocochaのイベント開発・運用を担当 Twitter: @tockn_s GitHub : tockn #Go #Vue.js #Firebase #GCP
6. 今年度新卒入社したエンジニアが キャッチアップしてきたPocochaの裏側をお話します
7. アジェンダ 1章. 自己紹介 2章. Pocochaとは？ 3章. Pocochaのバックエンド構成 4章. Pocochaのはじまり 〜限られたリソースとユーザー価値〜 5章. 急成長とDB負荷とシャーディング 6章. まとめとPocochaのこれから
8. Pocochaとは ・2017年に始まったソーシャルライブサービス ・誰でも気軽にライブ配信、視聴が可能 　・ライバー、リスナー ・チャットやアイテムによるコミュニケーション ・ランキング、イベントで上位を目指す仕組み
9. Pocochaとは ・絶賛急成長中 　・190万DL突破！ 　・ライバー、リスナーMAU 　　前年比３倍！ 2021年3月期第2四半期 決算説明会資料より抜粋
10. Pocochaの主要な機能（配信中） ・コメント 　・ライバーや他リスナーと会話 ・いいね 　・画面タップで送信。連投可能 ・アイテム 　・コインを消費してライバーを応援 ライバー、リスナー間 双方向コミュニケーション ⚠イメージです
11. Pocochaの主要な機能 ・イベント 　・開催期間中にライバー間でスコアを競う 　・入賞者には賞品贈呈 　・イベント終了直前の盛り上がり 　・毎月約100本のイベントを開催 リアルタイムスコア計算で 盛り上がりを演出 ⚠イメージです
12. ここまでを振り返る ・Pocochaというサービスの重要な要素 　・ライバー、リスナー間の双方向コミュニケーション 　　・コメント、アイテム等 　・リアルタイム性 　　・配信、イベントの盛り上がり →どのような構成でこれらを実現しているか？
13. アジェンダ 1章. 自己紹介 2章. Pocochaとは？ 3章. Pocochaのバックエンド構成 4章. Pocochaのはじまり 〜限られたリソースとユーザー価値〜 5章. 急成長とDB負荷とシャーディング 6章. まとめとPocochaのこれから
14. Pocochaのバックエンド構成全体像
15. アプリケーションレイヤ ・Ruby on Rails 　・モノリシック 　・クライアントと通信するほぼ全てのAPI 　・配信審査、運用を行う管理画面 　・EC2 with Auto Scaling ・ランキング周りはRedisで管理 　・Sorted set 　・リアルタイム性
16. ユーザー間リアルタイム通信とbcsvr ・ユーザー間のリアルタイム通信が必要 　・コメント 　・アイテム 　・いいね等 ・bcsvr 　・DeNA内製WebSocket Server 　・Pub/Sub 　・モバゲーでの利用実績
17. ユーザー間リアルタイム通信とbcsvr ・ユーザー間のリアルタイム通信が必要 　・コメント 　・アイテム 　・いいね等 ・bcsvr 　・DeNA内製WebSocket Server 　・Pub/Sub 　・モバゲーでの利用実績
18. ユーザー間リアルタイム通信とbcsvr ・ユーザー間のリアルタイム通信が必要 　・コメント 　・アイテム 　・いいね等 ・bcsvr 　・DeNA内製WebSocket Server 　・Pub/Sub 　・モバゲーでの利用実績
19. ユーザー間リアルタイム通信とbcsvr ・ユーザー間のリアルタイム通信が必要 　・コメント 　・アイテム 　・いいね等 ・bcsvr 　・DeNA内製WebSocket Server 　・Pub/Sub 　・モバゲーでの利用実績
20. 配信基盤 ・Amazon IVS (Interactive Video Service) 　・2020年に誕生 　・マネージドライブ配信ソリューション 　・オートスケールによるスケーラビリティ ・以前はwowzaを使用 　・メディアサーバソフトウェア 　・オンプレで管理 　・スケーラビリティ、品質管理コストが課題
21. ここまでを振り返る ・以上がPocochaの大まかなバックエンド構成 ・手堅い構成であり、モダンな構成ではない？ 　・マイクロサービス 　・Docker, Kubernetes等 ・なぜこのような構成を選択してきたのか？ → Pocochaのはじまりを覗いてみる
22. アジェンダ 1章. 自己紹介 2章. Pocochaとは？ 3章. Pocochaのバックエンド構成 4章. Pocochaのはじまり 〜限られたリソースとユーザー価値〜 5章. 急成長とDB負荷とシャーディング 6章. まとめとPocochaのこれから
23. インキュベーションプログラムとPococha ・Pocochaはインキュベーションプログラムの1つとして誕生 ・インキュベーションプログラムとは？ 　・DeNA社内で行われた職種、所属にかかわらず 　　新規事業の立ち上げができるプロジェクト (現在は終了) 　・4年間で40の新規事業を立ち上げ ・１つの事業に対して少額投資 　・新規事業の数を増やす 　・継続、クローズのフットワークを軽く 4年間で40の新規事業を生んだDeNA流 リーンインキュベーションの秘訣｜ 私の所信表明 千條 吉基 https://fullswing.dena.com/archives/2925
24. Pocochaの初期 ・リソースは限られていた 　・予算1000万 + α (人件費込み) 　・エンジニアは2人 　　・iOS, バックエンド1人ずつ 　・3ヶ月程でリリース、高速検証する必要があった →限られたリソースで如何にして価値を生むか？
25. ここでいう「価値」とは何か ・仮説検証段階では… 　・高速に機能をリリースし、分析して次の手を決めることが重要 　・「短期的なスピード」が価値 　・それがユーザー価値に直結 ・エンジニアの視点で… 　・機能のリリース、クローズを可能な限り早くすること 　・リリースした機能を即座に分析できる基盤を作ること
26. 限られたリソースで価値を生む ・初期Pocochaの場合、リソースは多いとは言えなかった 　（リソースが潤沢なスタートアップは少ないのでは？） ・技術の学習コストは事業の負担 　・例えば無理にモダンな技術を採用すると悪手になることも ・そこで堅実な技術選定が求められる 　・密結合であるRailsで開発スピードを出す 　・開発者本人が「既に持っている経験」を活用
27. ユーザー価値最大化に努めた結果 ・高速な機能開発、分析、意思決定に注力し、 　とにかくユーザー価値最大化に努めた ・結果、Pocochaは大きく成長 リスナーMAU 2021年3月期第2四半期 決算説明会資料より抜粋
28. ここまでを振り返る ・以上がPocochaが手堅い構成を取ってきた理由 ・その結果Pocochaは着実に成長 ・「短期的なスピード」が価値だった中の成長で 　浮き彫りになった課題もあった → どのような課題が浮き彫りになったのか？
29. アジェンダ 1章. 自己紹介 2章. Pocochaとは？ 3章. Pocochaのバックエンド構成 4章. Pocochaのはじまり 〜限られたリソースとユーザー価値〜 5章. 急成長とDB負荷とシャーディング 6章. まとめとPocochaのこれから
30. 急成長と浮かび上がる課題 ・巣ごもり需要もありPocochaは急成長 　・成長スピードが一段階加速 ・想定より早く課題解決を迫られることに 　・その1つが「DB（MySQL）負荷」 リスナーMAU 2021年3月期第2四半期 決算説明会資料より抜粋
31. DB負荷と向き合う（読み込み負荷） ・読み込み負荷に関して 　・元々DBはレプリケーション済み 　　・読み込みはリードレプリカから行う ・読み込みと書き込みの分割 ・複数レプリカによる負荷分散 ・読み込み負荷は大きな問題にはならず
32. DB負荷と向き合う（書きこみ負荷） ・書き込み負荷に関して 　・シャーディングされていなかった 　・今まではスケールアップで解決していた 　　・限界があるが、まだ先のはずだった… 　・成長スピードが上がったことで、限界が早く来た 　　・db.r5.12xlargeまでスケールアップ、残り2段階…
33. シャーディング対応 ・書き込み起因の負荷を減らすためにシャーディング 　・特に負荷の大きいテーブル ・そもそもシャーディングとは 　・水平分割 　・独立した複数DBに 　　　同一テーブルのレコードを分散配置 　
34. シャーディング対応で考えること ・レコード分散方法 　・どのレコードをどのシャードに置くか？ ・id採番方法 　・どのように複数DBで一意なidを持つか？ ・アプリケーション側実装方法 　・どのようにApp側から複数DBを操作するか？
35. シャーディング対応で考えること ・レコード分散方法 　・どのレコードをどのシャードに置くか？ ・id採番方法 　・どのように複数DBで一意なidを持つか？ ・アプリケーション側実装方法 　・どのようにApp側から複数DBを操作するか？
36. レコード分散方法 ・どのレコードをどのシャードに割り当てるか ・idを元に一意に決定する方法 　・id範囲 　　・例: idが1~100はシャード1へ、101~200はシャード2へ等 　・idとシャード数との剰余 　　・例: シャード数が2の時、id: 100はシャード1へ、id: 101はシャード2へ等 ・シンプルで高速だが、シャード増設への対応が困難
37. レコード分散方法 ・そこでPocochaでは… ・割り当て先を重み付きランダムで決定する方法 　・INSERT時に割り当て 　　・割り当て先管理テーブルにINSERT ・シャード増設に対応可能 ・重みを変更し割り当て先の工夫が可能 割当先管理テーブル
38. レコード分散方法 ・そこでPocochaでは… ・割り当て先を重み付きランダムで決定する方法 　・INSERT時に割り当て 　　・割り当て先管理テーブルにINSERT ・シャード増設に対応可能 ・重みを変更し割り当て先の工夫が可能 割当先管理テーブル
39. シャーディング対応で考えること ・レコード分散方法 　・どのレコードをどのシャードに置くか？ ・id採番方法 　・どのように複数DBで一意なidを持つか？ ・アプリケーション側実装方法 　・どのようにApp側から複数DBを操作するか？
40. id採番方法 ・シャーディングすると1テーブルが複数DBに跨る ・複数DB間で一意なidを担保する必要 ・Pocochaでは2つの方式を採用 　・既存のテーブル 　　・採番テーブル方式 　・新規作成するテーブル 　　・ULID方式
41. ・Pocochaの場合、既存のテーブルのidはAUTO_INCREMENT 　・このままでは複数DB間で一意なidにならない ・そこで採番テーブルを作成 　・idのみを保持するテーブル ・実際のテーブルには 　採番テーブルで採番したidをINSERT ・既存のテーブルをシャーディング可能に id採番方法 - 採番テーブル方式 採番テーブル
42. ・Pocochaの場合、既存のテーブルのidはAUTO_INCREMENT 　・このままでは複数DB間で一意なidにならない ・そこで採番テーブルを作成 　・idのみを保持するテーブル ・実際のテーブルには 　採番テーブルで採番したidをINSERT ・既存のテーブルをシャーディング可能に id採番方法 - 採番テーブル方式 採番テーブル
43. ・Pocochaの場合、既存のテーブルのidはAUTO_INCREMENT 　・このままでは複数DB間で一意なidにならない ・そこで採番テーブルを作成 　・idのみを保持するテーブル ・実際のテーブルには 　採番テーブルで採番したidをINSERT ・既存のテーブルをシャーディング可能に id採番方法 - 採番テーブル方式 採番テーブル
44. ・Pocochaの場合、既存のテーブルのidはAUTO_INCREMENT 　・このままでは複数DB間で一意なidにならない ・そこで採番テーブルを作成 　・idのみを保持するテーブル ・実際のテーブルには 　採番テーブルで採番したidをINSERT ・既存のテーブルをシャーディング可能に id採番方法 - 採番テーブル方式 採番テーブル
45. id採番方法 - ULID方式 ・ULIDとは 　・一意に識別できるソート可能な識別子 　・生成順に辞書順でソート可能 　・ソート可能なUUIDのようなもの ・新規テーブルのidはULIDを使用 　・複数DBのテーブル間で一意 & 順序も担保 01EVXNGW7BASK7B1G92DQ8BW1K 01EVXNGW7BWZK8TF16EWF2PSW7 01EVXNGW7BQPHMETNBMMZ6GD0C ︙ ULIDの生成例
46. シャーディング対応で考えること ・レコード分散方法 　・どのレコードをどのシャードに置くか？ ・id採番方法 　・どのように複数DBで一意なidを持つか？ ・アプリケーション側実装方法 　・どのようにApp側から複数DBを操作するか？
47. アプリケーション側実装方法 ・Pocochaでは現在Rails5を使用 ・Rails 5.x単体ではシャーディング非対応 　（Rails 6.1では対応しているが、当時未リリース） ・そこでOctopusを使用 　・Rails (Active Record) でシャーディングするためのgem 　・メジャーであること、社内の利用実績が選定理由
48. ここまでを振り返る ・急成長で特に大きかった課題は「DB書き込み負荷」 　・シャーディング対応 ・「短期的なスピード」が価値のフェーズから 　「長期的な品質」も価値となるフェーズになった → 今後Pocochaはどうなっていくのか？
49. アジェンダ 1章. 自己紹介 2章. Pocochaとは？ 3章. Pocochaのバックエンド構成 4章. Pocochaのはじまり 〜限られたリソースとユーザー価値〜 5章. 急成長とDB負荷とシャーディング 6章. まとめとPocochaのこれから
50. Pocochaのこれから ・グローバル版の開発 　・多言語対応 etc... ・新機能開発 　・コラボ配信 　・新規イベント etc... 「守りつつ攻める体制」でグロースさせる！ ・さらなる品質向上の追求 　・パフォーマンス 　　・遅延時間短縮 　　・通信プロトコル最適化 　・組織拡大に対応する 　　　アーキテクチャ模索
51. 発表まとめ ・システム構成 　・「双方向通信」と「リアルタイム性」がキーワード 　・Ruby on Rails, MySQL, Redis, bcsvr, Amazon IVS ・Pocochaはミニマムに始まった事業 　・高速仮説検証を重視し、技術選定は堅実に！ ・シャーディングで急成長によるDB負荷対策 　・ランダム分散, 採番テーブル, ULID, Octopus
52. We are hiring! Pocochaではエンジニアを絶賛募集中！ 　話を聞いて興味を持った方！ 　グロースフェーズの事業でサービスの成長にコミットしたい方！