Pocochaの技術的課題と展望

はじめに

こんにちは。Pococha事業部エンジニアの北澤です。本記事では、 Pocochaを取り巻く技術的な課題と、それを解決するためにどのような試みを行っているのかをご紹介します。中にはまだ道半ばであったり実現が叶っていないものもありますが、私達がPocochaの技術課題にどのように立ち向かおうとしているかを少しでもお伝えできればと思います。

配信を支えるシステム構成

取り組みについてご紹介する前に、まずはPocochaの配信機能を支えるシステム構成を簡単にご紹介したいと思います。配信機能は大まかに、以下の3つのコンポーネントで構成されています。

Amazon Interactive Video Service

マネージド型の動画ストリーミングサービスです。動画配信については、基本的にこのサービスに乗っかる形になります。
Ruby on Rails + MySQL からなる Web API サーバ

アイテムやコメントといった、動画データ以外のデータ管理とドメインロジックを全て担っています。おそらく読者の皆さんが想像する一般的な Webアプリケーションと基本的には同じだと思いますが、高トラフィックを安定的に捌くための負荷対策は行っています。
DeNA内製のPubSub サーバ

上記のWeb API サーバでドメインロジックを表現しつつ、リアルタイム性をこのPubSubサーバで実現しています。同じ配信枠に参加しているクライアントに対して、Web API サーバからメッセージをブロードキャストすることができるので、アイテムやコメントをリアルタイム性高く同期できます。

PubSub サーバの構成

これらのコンポーネントにより、シンプルな動画配信・コメント機能・アイテム機能などであれば、十分実現することができます。ですが、Pocochaが提供したい “特別な居場所” を実現するためには、より適したアーキテクチャや手法があるのでは？と日々、思案を重ねています。

【取り組み1】Web API 通信の改善

クライアント(モバイル端末) と Web API サーバ間のプロトコルは、RESTful API であり、データフォーマットには JSON を利用しています。これは非常に一般的な手法であり、デファクトスタンダードとも言えると思います。しかし、JSON のようなテキストデータでは、通信容量も大きくなりがちであり、クライアントでのデシリアライズコストも馬鹿になりません。

クライアントの処理では、動画再生やアイテム演出などにより大きくリソースを割きたいので、それ以外の処理コストを可能な限り削減したいと考えています。そこで、API通信のデータフォーマットをバイナリデータにする試みを行いました。具体的には、Protocol Buffersを利用しています。現在は一部のAPIで利用しているだけですが、今後は徐々に移行していく予定です。

さらに副作用として、 Protobuf スキーマを記述することによりデータのスキーマを定義しているため、サーバクライアント間でのスキーマの共有のしやすさやシリアライズ・デシリアライズ実装の標準化・効率化にも繋がりました。

今後の展望としては、 PubSubサーバでやりとりするデータ(現状はJSON)もバイナリデータに移行していきたいと考えています。

【取り組み2】マスターデータの改善

Pocochaはロングテールなサービスを作ることを最も大切にしています。
*Pocochaの設計思想の詳細はこちらも参考にしてください

ある一部のコンテンツやユーザーにトラフィックを集中させるのではなく、サービスを使うユーザー一人ひとりにとってかけがえのない居場所を提供し、誰でも自己肯定感を高く生きていける世界を創りたいと考えています。

自由にコミュニケーションを取ることができるシステム機能を用意しました、で完結する様な単純なものでは全くなく、各ユーザセグメントに最適化した様々なコンテンツを高頻度に提供し続けるものになります。例えば、「イベント」と呼ばれる期間限定で開かれる特別な催し物は現在月200本以上開催されており、今後もその数は増えていく予定です。他にも配信中のコミュニケーションにとって重要な要素であるアイテムについても、定期的に新作が登場し、現在440を超える数になっています。これらのコンテンツは、システム内部ではデザインアセットやマスターデータといった形で表現されることになるわけですが、上述の価値観を実現するためには大量かつ複雑なデータを扱わなければなりません。

このようなマスターデータと呼ばれるデータは、RDB(リレーショナルデータベース)上で管理されるのが一般的です。ですが、数万を超えるデータ量と複雑なデータ構造であることにより、しばしばパフォーマンス低下を引き起こし、また開発効率・運用効率の低下にも悩まされています。このようなデータは、Redisなどのインメモリデータストアやアプリケーションプロセスのメモリ領域にキャッシュすることでパフォーマンス低下の問題は軽減されることも多いですが、現在の Pococha のデータ量と複雑性ではそれらの対策でも不十分だと考えています。

また、Google Sheetsを用いてデータ制作・反映のワークフローを整え、極力エンジニアの手をかけずにアジリティ高く運営を進める仕組みを構築してはいるものの、ここからさらにデータ制作フローをスケールさせていく必要があります。そこでもまた、前述のようにデータの量と複雑性に立ち向かわなければなりません。

現状は、RDB, CSVデータ, Google Sheetsといった要素でデータのフローが構築されていますが、私たちの価値提供の方法に最適なやり方をゼロベースで検討しています。まだ形にはなっていないものの、おそらくRDBや表形式データから脱却した先に答えがあるのではないかと模索しています。

【取り組み3】リアルタイムコミュニケーションを支えるシステム

Pocochaはライバーからリスナーに向けた一方通行のライブ配信サービスではなく、リスナーからライバー、そしてリスナー同士のコミュニケーションによって成り立つコミュニケーションプラットフォームです。よって、動画配信だけではなくコメントやアイテムを使ったコミュニケーションも不可欠です。

これらのコミュニケーションは、前述の通り Web API サーバと PubSubサーバの組み合わせで実現しています。コメントやアイテムなどのデータを同じ配信枠内に参加している全員にリアルタイムに届けるだけであれば、これで十分機能するでしょう。しかし、 Pococha が提供したい “特別な居場所” とは、「リアルタイムチャットシステムを提供したので後は自由にコミュニケーションしてください」という単純なものでは決してありません。

配信枠内での応援行動に対して適切なフィードバックを返すために、システムの裏側では様々な処理を行っています。現在の仕様が最適で完成されたものというわけではありません。むしろまだまだ改善、改良が必要です。

私たちは日々仮説を検証し、課題を特定し、パラメータやドメインロジックを頻度高く更新しています。期間限定イベントに特有の処理も実装する必要があります。

これらの実装は往々にして、配信枠の参加者全員のアクションが配信枠全体の状態を随時更新していくようなロジックになります。 Pocochaではこのような処理は主にデータベースの排他制御を用いて実現しています。

これだけ書くと簡単そうに見えますが、実際のところ、アクションの順序も含んだ整合性を担保しつつ超高頻度に状態を更新し続ける必要があるため、一筋縄ではいきません。

Web API サーバは配信枠とは無関係に分散されているためどうしてもデータベースの排他制御頼みになってしまいますし、ピーク時間帯にはかなりの速度で参加者のアクションが積み重なるため、常に負荷を意識した繊細な実装が求められます。

また、参加者のアクションだけでなく、配信中の時間経過にも連動して状態は変化していきます。これをAPIリクエストドリブンなアーキテクチャで実現する難しさにも直面しています。

状態変化をほぼリアルタイムに参加者全員に共有することについては、現在のPubSubサーバを用いた構成により実現できています。ですが、上記のような実装の困難さと、アジリティ高く機能開発・改修を繰り返してゆくことの両立は非常に難しく、立ち向かわなければならない課題だと考えています。これについては、従来の Web API サーバと PubSubサーバを用いた仕組みの延長線上では解決は難しいのではと考えており、ゼロベースで解決策を模索しています。

配信枠の空間・時間をそのまま表現するようなシステム構成にするのが適しているのではと現時点では検討しています。

具体的には、

配信枠毎に固定の常駐プロセスを対応させ、配信枠の状態をオンメモリ上で保持し続けて随時更新していく
その配信枠の参加者全員が対応する常駐プロセスとネットワーク接続し、リアルタイムで状態を共有する
データベースへの永続化は、参加者のアクション毎ではなくもう少し広い間隔で一定周期で行う

といったアプローチが実現できないかを検証しています。

おわりに

ご紹介したそれぞれの取り組みについて、まだやりきったものではないため、詳細なアプローチは異なるものになるかもしれません。しかし、それぞれの課題はどれもPocochaが打ち破らなければならないものであり、どのようなアプローチを以てしても解決していきます。実際に課題を解決することができたら、改めてどこかでご紹介させていただきたいと思っています。