目次
はじめに
こんにちは、ライブコミュニティ事業本部Pococha事業部のエンジニアの加藤、佐々木、山田、米澤です。
2024年度新卒としてDeNAに入社し、8月からサーバーサイドエンジニアとしてPocochaにJoinして約2ヶ月が経過しました。配属早々、複雑なシステムに触れる機会が多く、この2ヶ月間で多くの学びを得ることができました。
今回は、新卒エンジニアの視点から見たPocochaのサーバーサイドについて、皆さんに少しでも共有できればと思います。以下に、具体的な内容としてPocochaとは何か、使用している技術・ツール、アーキテクチャについて解説し、クライアントとの通信方法やインフラ構成図を紹介します。さらに、主要機能のコードの流れとして「配信ボタンを押してライブ配信が始まるまで」と「アイテムを投げた際のリアルタイム通信」についても触れていきたいと思います。
この記事は、DeNAやPocochaのエンジニアに興味がある方にとくに読んでいただきたい内容です！
Pocochaとは
Pocochaは、DeNAが運営するライブコミュニケーションアプリです。
いつでも簡単にライブ配信と視聴をでき、ライバー（配信者）とリスナー（視聴者）による双方向コミュニケーションがライブ配信を盛り上げます。熱く応援してくれるファンに出会い、ファンとつながるコミュニティ・プラットフォームとして、ライバー・リスナーの両者にとって居心地のよい場を提供しています。
ライブコミュニケーションアプリ - Pococha
Pococha（ポコチャ）公式サイト - ライブコミュニケーションアプリ - Pococha
使用している技術・ツール
Pocochaで使用しているツールと特徴的なライブラリやツールを紹介します。
- サーバーサイド
- Ruby on Rails
- 使用している特徴的なライブラリなど
- Ridgepole
- データベースのスキーマを管理するために使用しています。
- Sidekiq
- バックグラウンド処理にはSidekiqを使用して処理をしています。
- Slim
- 運営の管理用ページなどはSlimを使用しています。
- Ridgepole
- 使用している特徴的なライブラリなど
- Ruby on Rails
- 可視化ツールなど
- Grafana
- Datadog
- CI/CD
- GitHub Actions
- チーム開発で使用しているツール
- Jira
- GitHub Enterprise
- GitHub Copilot
- ドキュメント
- Notion
アーキテクチャ
新卒で配属される際には、これまで個人開発などで経験を培ってきたが「配属されるプロジェクトほど大きなプロダクトを触ったことがないからわからない」はあるあるだと思います。
ここではざっくりと、デフォルトのRailsにはないPocochaで運用されているアーキテクチャを調査したので、それを紹介します。
app/decorators- アプリケーションからデータを受け取りプレゼンテーション用にフォーマットしています。
app/entities- エンティティオブジェクト。ドメイン駆動設計（DDD）におけるエンティティパターンを取り入れています。
app/forms- フォームオブジェクト。複雑なバリデーションやフォーム処理ロジックを専用のオブジェクトにカプセル化するために使われています。
app/masterdata- マスターデータ関連のファイルです。このサブディレクトリはデフォルトにはないが、ビジネスロジック上重要なマスターデータを管理するために追加されています。
app/queries- クエリオブジェクト。データベースへの複雑なクエリ操作をカプセル化しています。
app/services- ビジネスロジックを含むサービスオブジェクトが設けられています。ビジネスロジックを分離するために利用されています。
Railsアプリの標準的なアーキテクチャでは、MVC（Model-View-Controller）パターンにしたがってアーキテクチャが組まれています。しかしアプリケーションが複雑になるにつれ、デフォルトのディレクトリ構造だけでは対応しきれない場面が出てくることがあります。そのため、Pocochaでは上記のようなアーキテクチャを追加することでコードの可読性や保守性、再利用性を向上させています。
クライアント（モバイル・フロントエンド）との通信方法
背景
Pococha では Protocol Buffers （以降 protobuf）を用いたスキーマ駆動開発を行っています。
protobuf 導入以前は API レスポンスには型がなく、クライアント側のコードでレスポンスを model オブジェクトに変換する方針をとっていましたが、
- サーバーAPIの仕様が変わっていてもそれを検知できない
- model オブジェクトに変換する際、存在しないプロパティを参照する等ミスをする可能性がある
といった課題がありました。
これらの問題を解決するために、protobufを用いて以下のような運用を導入しています。
運用方針
サーバーの開発者が新たにAPIを作成する際には、以下のようなフローとなります。
-
/api_schema/protobuf/api配下に schema 定義ファイルhoge.protoを作成するsyntax = "proto3"; package protobuf.api.hoge; option java_outer_classname = "Hoge"; // GET '/v1/hoge' message GetV1Response { // response の型定義を書く string name = 1; } -
schema 定義ファイルから protobuf 設定ファイルを作成するスクリプトを実行する
/lib/protobuf/api/配下にprotobufの設定ファイルが作成される
-
/lib/protobuf/api/配下のファイルで定義されたクラスを用いてレスポンスを返す
クライアントの開発者は、上記によって作成されたサーバーリポジトリ内 protobuf ファイルを GitHub Packages に Publish して利用します。
インフラ構成図
Pocochaのインフラ構成図について簡単に紹介します。説明のために実際の構成図から抽象化しています。
インフラ構成図
- アプリケーションレイヤー
- EC2
- サーバー（管理画面含む）はNginx + Unicornで動いています。
- バッチ処理用のサーバーはSidekiqで動いています。
- ALB（Application Load Balancer）
- トラフィックを負荷分散し、スケーラブルなインフラを実現しています。
- Auto Scaling
- EC2のCPU使用率に応じて、インスタンスのオートスケーリングを行っています。
- EC2
- Aurora DB
- Aurora DB
- ユーザー情報や配信履歴などの永続的なデータを保存しています。
- Aurora DB
- ElastiCache
- Memcached
- Redisとは違いソートが出来ないですが高速であるため、ユーザーがどのデータベースに保存されているかの情報やユーザー詳細などソートが必要ない情報を保存しています。
- Redis
- ランキング情報、セッション情報、イベント情報といった短期的に頻繁にアクセスされるデータを保存しています。
- Memcached
- Lambda
- Lambda
- ライバーのプロフィール動画の検証処理をしています。
- S3
- ライバーのプロフィール動画を保存しています。
- Lambda
- マスターデータ
- CDN
- システム内で使用するアイテムの画像データなどをCDN経由で取得しています。
- S3
- システム内で使用するアイテムの画像データなどを保存しています。
- CDN
- 配信基盤
- IVS
- AWSのInteractive Video Service（IVS）を配信インフラとして用い、安全かつスムーズな配信をサポートしています。
- CDN
- ライブ配信のアーカイブデータをCDN経由で取得しています。
- S3
- ライブ配信のアーカイブデータを保存するためのオブジェクトストレージとして使用しています。
- IVS
- AI基盤
- AIシステム用社内API
- AIを用いて無言配信や運転しながらの配信など規約に違反している配信を検知する審査システムやおすすめの配信をタイムラインに表示するリコメンドシステムにより、ユーザーが安全に配信を楽しめる環境を提供しています。
- AIシステム用社内API
主要機能の処理の流れ
配信ボタンを押してライブ配信が始まるまで
ライブ配信時の処理について紹介します。
ライブを始める際には、以下の図のように主に2つの処理を行っています。
まず1つ目の処理は、ライブの設定です。ここでは配信の名前やライバーの情報、配信形式などを設定し、サーバー上での配信準備を行います。これによって、配信の一覧に表示されるようになります。
2つ目の処理は、設定した配信環境に使用している端末や通知を送るリスナー一覧の情報を追加することです。リスナーさんは通知やアプリの一覧から配信に参加できます。
これにより、配信を開始できます。
Amazon IVSを使用して映像や音声データを送受信しています。
配信ボタンを押してライブ配信が始まるまで
アイテムを投げた際のリアルタイム通信
Pocochaでは、ユーザーがアイテムを投げた際のリアルタイム通信を「bcsvr」というDeNA内製のミドルウェアで実現しています。「bcsvr」とは、インターネット上でpublish-subscribe型の通信を中継するためのサーバーです。使用背景としては、モバゲーなど他サービスでの使用実績があるためです。
アイテムを投げた際のリアルタイム通信には、以下の図のように主に2つの役割に分かれて処理を行っています。
1つ目の役割はサーバーによる処理です。ユーザーが「アイテムを投げる」という操作を行ったとき、その情報はサーバーに送信されます。サーバーは、この情報をもとにイベントデータを生成し、バックグラウンドで処理するためにジョブをキューに追加します。このキューに入れられたジョブは順序通りに処理され、「bcsvr」を介して特定のチャンネルに特定のアイテムを投げたというメッセージが配信されます。「bcsvr」は、TCPまたはWebSocketを使用してクライアントとの接続を管理し、メッセージが確実に伝達されるようにします。
2つ目の役割はクライアントによる処理です。ユーザーがライブに入室する際、クライアントは「bcsvr」に対してWebSocketでコネクションを確立します。この接続を通じて、サーバーから各ライブごとにパブリッシュされたメッセージをリアルタイムでサブスクライブし、受信します。
アイテムを投げた際のリアルタイム通信
おわりに
新卒メンバーがPocochaのサーバーサイドについて調査した内容を紹介しました。
Pocochaは8年近く開発が続く大きなプロダクトとなっており、過去のコードの積み重ねの歴史やライブストリーミングのサービス特有の設計を感じました。
また、Pocochaで使われている技術や構成や主要の処理から、技術の全体像を知ることができました。今後の業務に活かしていきたいです！
Pocochaでは、多くのエンジニアがさまざまな機能やユーザーにPocochaらしいより良い体験を届けるために改善を繰り返して開発をしています！
もし本ブログでPocochaについて興味を持っていただいたら幸いです。一緒にPocochaを盛り上げていきましょう！
最後まで読んでいただきありがとうございます。
最後まで読んでいただき、ありがとうございます！
この記事をシェアしていただける方はこちらからお願いします。