MixChannel
MixChannel は、（ 株） Donuts おもに若者世代から人気を集めているライブ配信＆動画投稿コミュニティアプリです。利用者は累計1,000万ユーザーを超え、月間での利用ユーザー数は80万人ほどと規模の大きなサービスとなっています。
このように大規模なサービスでは日々多くのユーザーがサーバにアクセスするため、サーバは各リクエストに対するレスポンスを高速に返す必要があります。
またMixChannelでは、ライブ配信システムだけでなく、ライブ配信サービスを支えるさまざまなシステムが動いており、ユーザーの行動から次のサービスを考えるための計測も行われています。今回は、多くのユーザーからアクセスされているライブ配信サービスのサーバ技術と、ライブ配信の裏側で運用されている機能や技術について紹介します。
ユーザーのライブ配信を支えるシステムの構成
ライブ配信サービスでは、各ユーザーのライブ配信状況などの情報を正しく管理してクライアントに伝える必要があります。また、ライブ配信自体を実現するためには、チャットデータとライブ配信の動画データの2種類のデータを扱う必要があります。加えて日々多くのユーザーがアクセスするため、それらのアクセスに耐えうるサーバ構成にしなければなりません。
MixChannelでは、ライブ配信の情報管理と実施のためのシステムを、おもに次の4種類のサーバによって実現しています。
APIサーバ
チャットサーバ
ライブサーバ
ストレージサーバ
また、ライブ配信を支えるサーバ全体の構成は図1 のようになっています。4種類のサーバそれぞれの役割や用いられている技術について説明します。
図1 サーバ全体の構成APIサーバ
APIサーバはシステムの中心となるサーバです。MixChannelで現在行われているライブ配信の情報や配信者が配信を開始するときの設定など、ライブ配信回りの処理をおもに担います。各クライアントとはHTTPで通信します。ライブ配信に関連する処理のうち、APIサーバが行う処理としては次の例があります。
現在行われているライブ配信の情報を返す
配信を開始・終了する
配信されているライブに入室する
ライブ配信でアイテムを投げる
APIサーバのプログラムはおもにGo言語で実装されています。また、多くのユーザーからのアクセスに対応するため、API サーバを複数立て、AWSのELB（Elastic Load Balancer ）によってアクセスを分散させています。
データ自体はAmazon RDS（Relational Database Service ）上に保存しており、アクセスごとにデータを取得します。そのうち、ライブ一覧やアイテム一覧など同じデータを何回も返すものについては、レスポンスを高速化するためにキャッシュを利用しています。しかし、サーバごとのメモリキャッシュでは、サーバによってデータの新しさに違いが出る可能性があるため、Redisによって複数サーバにおけるキャッシュの同期を実現しています。
チャットサーバ
MixChannelのライブ配信中は、コメントや投げられたアイテムデータの送受信、視聴者数やライブ配信の状態の取得などをサーバとクライアントの間でリアルタイムに処理できるようにしています。この役割を担うのがチャットサーバです。チャットサーバは通信にWebSocketを用います。ライブを配信・視聴している各クライアントとサーバの間をWebSocketで接続し、ライブ配信に関連する情報をJSON形式のデータとして送受信しています。
チャットサーバは、さまざまな種類のデータを扱います。今回は具体例として、視聴ユーザーが送信するチャットデータと、配信ユーザーを応援するために視聴ユーザーが送信できるアイテムデータを紹介します。
チャットデータのやりとりは図2 に示すように、サーバが受け取って流すだけの単純なしくみになっています。たとえば、ある視聴クライアントがチャットを投稿した場合、そのチャットデータをWebSocketを通じてチャットサーバが受信します。次いで、ライブを配信・視聴しているすべてのクライアントに受信したデータを配送すると処理が完了します。
図2 チャットサーバにおけるチャットデータのやりとりの流れ一方、視聴ユーザーが送信できるアイテムデータでは、投げた先の配信ユーザーが正常にライブ配信を行っていることを確認するため、少し複雑な方法で処理を行います。アイテムデータには、送信状態と消費状態という2つの状態が存在し、初めは送信状態になっています。これを配信ユーザーが消費状態に遷移させたうえで各ユーザーにデータを配送します。
アイテムデータの処理の流れは図3 のとおりです。まず視聴クライアントがAPIサーバにアイテム送信のリクエストを送り（図3の①） 、チャットサーバを経由してライブを配信するクライアントだけに送信状態のアイテムデータが配送されます（図3の②） 。その後、ライブを配信するクライアントがAPIサーバにアイテム消費のリクエストを送信すると（図3の③） 、ライブを配信・視聴しているすべてクライアントにチャットサーバを経由して消費状態のアイテムデータが配送され、処理が完了します（図3の④） 。
図3 チャットサーバにおけるチャットデータのやりとりの流れチャットサーバのプログラムもGo言語で実装されています。Go言語の機能であるgoroutineを用いてライブ配信ごとの非同期処理を実現したうえで、WebSocketを介して各クライアントとリアルタイムに接続しながら処理を行います。また、アイテムデータをAPIサーバからチャットサーバに受け渡す処理は、RedisのPub/Subを用いて実現しています。
ライブサーバ
ライブ配信において配信者と視聴者がリアルタイムにやりとりできるようにするには、動画データも遅延なく配送する必要があります。この動画データのやりとりを行っているのがライブサーバです。ライブ配信における動画データは、ストリーミングでデータをやりとりできるRTMP（Real Time Messaging Protocol ）というプロトコルで送受信します。
動画データのやりとりの前に、ライブを配信・視聴する各クライアントとRTMPで接続します。そのうえでライブを配信しているクライアントからHLS（HTTP Live Streaming ）形式の動画データを受け取り、視聴しているクライアントに配送することで、ライブの視聴を実現します。
またMixChannelでは、特定のライブ配信の録画データを視聴できるようにしています。この機能は、RTMPで受け取った動画データをストレージサーバとして利用しているAmazon S3に転送して保存しておき、クライアントが録画データを視聴する際に保存しておいたデータを参照することで実現しています（図1） 。
ストレージサーバ
ライブ配信の際に使用するアイテムの画像などのリソースファイルやライブ配信の録画データは、Amazon S3上に配置されており、必要に応じてクライアントがダウンロードして利用します。
アイテムの画像などのリソースファイルをストレージサーバに配置する利点は、機能のリリースを行う際にクライアント側のアプリを更新しなくても、サーバ側の更新だけで対応できるという点です。これにより、リリース作業が容易になります。
またこれらのリソースデータは、Amazon CloudFrontをコンテンツ配信ネットワーク（CDN）として利用することで、データがキャッシュされるようにしており、クライアントはデータを高速に取得できます。
いかがでしたでしょうか。後編（1月15日掲載予定）ではライブ配信の裏側について解説します。ご期待ください。
特集1 イミュータブルデータモデルで始める 業務の複雑さをシンプルに表現！ 特集2 いまはじめるFlutter iOS/Android両対応アプリを開発してみよう 特集3 作って学ぶWeb3 ブロックチェーン、スマートコントラクト、NFT
