This post is also available in the following languages. Korean, English

大規模サービスLINE LIVEのためのエンコーダレイヤ構造と悩んだこと

Kim Suhyuk2017-12-15

Bridge Engineering

はじめに

こんにちは。LINE ITSC所属のエンジニア、Kim Suhyukです。これはLINE Advent Calendar 2017の16日目の記事です。

先日12月10日に、LINE LIVEサービスがリリースされてからちょうど2年が経ちました。リリース以来障害なく運営できて、とてもよかったと思っています。私はライブメディアサービスの構築や運営の経験がなかったため、今回の記事では、設計や構築を始めるときに悩んだ点についてまとめてみました。

背景および課題

LINE LIVEは、いつでも誰でもライブ配信できるサービスとして、予測を超える数のユーザーが利用したとしても円滑にライブを配信・視聴できる必要があります。そのため、以下の条件を満たす構造が必要と考えました。

1.リソースが足りなくなったときに速やかに拡張できる。

ライブを配信・視聴するユーザーの数を予測できない一方で、全てのリクエストを同時に処理する必要があります。

2.ライブ配信・視聴に対して、同時接続した全てのユーザーに安定的な品質を保証する。

LINE LIVEでは、LINE公式アカウントからもライブを配信できます。公式アカウントでライブ配信が開始されると、そのアカウントの友だちとして登録されている全てのユーザーに、ライブ配信が始まったことを知らせるメッセージが送信されます。そのため、トラフィックのスパイクが発生すると見込まれました。

3.初期構築の後も、変更に対して柔軟な対応ができる。

サービスの成長と共にインフラの変更が要求されると予測されたため、コンポーネント間の結合が弱く柔軟に変更できる構造が必要でした。特に、Media Serverはライブ配信するユーザーが増えればスケールアウトが必要になるため、いっそう結合を弱くする必要がありました。

これらの条件は、最近よく使われるMSA（Microservices Architecture）で満たすことができます。結論として、LINE LIVEのMedia Serverも、トランスコードとレコードを除いた全ての機能をできるだけ分けて、アプリケーション間の結合を弱くした構成で設計することになりました。

LINE LIVEのエンコーダレイヤの構造

以下の図は、サービス全体の流れを示しています。ここから、コンポーネントごとに説明していきます。

Media Server

一般的に、Media Serverは以下の機能を提供します。

ライブを配信するRTMP信号を、他のユーザーが視聴できるデータに変換する処理
RTMP信号の認証
ライブの録画

LINE LIVEのMedia Serverについて、さらに説明します。

1.どの環境でも安定的な視聴を提供するためのトランスコード

LINE LIVEはユーザーがどのネットワークからでも安定的に視聴できるように、さまざまな解像度とビットレートを提供していますが、そのために必要な処理をトランスコードといいます。動画のトランスコードはサーバーリソースを多く消費する処理なので、数多くのサーバーが必要です。

2.ライブを配信するユーザー数の増加への対応

ライブを配信するユーザーの増加に合わせて、Media Serverも増やすことになります。Media Serverの台数が変わっても、他のシステムへの影響は最低限にする必要があります。

LINE LIVEはいくつかの理由でWowza Media Serverを使っています。Wowza Media Serverで提供される基本認証はローカルファイルベースなので、ユーザー管理が難しいです。

そこで、別の認証システムを構築して、Media Serverと連携する方法を検討しました。WowzaのSDKを使えば外部認証システムと連携できますが、いくつか問題があったので、SDKは結局使いませんでした。

その問題点を簡単に説明します。まず、カスタムモジュールを開発するリソースも、安定性をテストする時間も足りない状況でした。また、Wowzaがアップデートされるたびにカスタムモジュールの動作確認や修正が必要なことを考えると、維持コストが高いと判断しました。

検討した結果、Media Serverから認証を分離することになりました。

Proxy Server

Media Serverの持つ認証機能ではなく、他の認証システムに切り替える方法を探しました。この認証システムには以下の機能が必要です。

RTMP信号を受けて、認証システムに確認してから許可・拒否する。
認証に成功した場合、Media ServerにRTMP信号をリレーする。

この条件を満たすため、RTMPをプロキシ処理できるアプリケーションが必要でした。

調べてみたところ、一般的にはMedia Serverの負荷分散のためにHAProxyを使うことがわかりました。HAProxyを使えばリレーはできますが、Media Serverを追加したり削除したりするたびに、全てのプロキシサーバーにある設定情報を変更することになります。これは運用上大きな負担になるうえ、認証の問題は解決できませんでした。認証の問題を解決するため、HAProxyとLua Scriptingを使って対応できるか検討しているうちに、nginxのrtmp-moduleの検討も始めました（詳しくは、以下の資料を参照してください）。

参考資料
https://leandromoreira.com.br/2015/04/26/fifa-2014-world-cup-live-stream-architecture/

最終的に、nginxとrtmp-moduleを使って認証とリレーについてPoC環境で確認したところ、問題なく構築できました。その後は負荷テストとロングランテストなど行いました。サービスとして十分に使えると判断し、LINE LIVEのプロキシソリューションとして導入しました。

Proxy Serverを導入したため、Media Serverは内部ネットワーク内に限定して設置することができ、外部からアクセスできるエンドポイントも単一化できました。

Manager Server

Manager Serverは、Media Serverとバックエンドシステムの間でさまざまな処理を担当します。サービスを安定的に運用するため、以下のような主要機能が搭載されています。

ライブ配信に使うストリームキー認証
Media Serverのモニタリング
Media Serverの負荷分散
同一ストリームキーでの重複ライブ配信の防止
ライブ配信の終了後のVOD生成などの作業
アイドル状態の接続の管理

CDNとOrigin Server

ライブ視聴に関連して、LINE LIVEでは以下の問題を解決する必要がありました。

CDN（Content Delivery Network）リクエストの内部ルーティング
トラフィックのスパイクに対する安定的な処理

LINEの公式アカウントは数十万人から数千万人の友だちを持っています。このような公式アカウントでライブを配信する場合、全ての友だちにメッセージを送信できます。メッセージを受信した全てのユーザーは、公式アカウントから送られたメッセージに含まれるリンクをクリックするとすぐにライブを視聴できます。多くのユーザーがライブを視聴しようとするこの短時間の間に、問題があってはなりません。

ユーザーがライブを視聴するとき、ライブはCDNから提供されています。ただ、あまり短い期間内に多数のユーザーがCDNに同じリクエストを送ると、CDNでキャッシュが消失してOrigin Serverを参照しなければならないことがあります。正常なリクエストであっても、Origin ServerでDDoSとして判断されるほど大量のリクエストが発生する可能性もあります。また、特定のライブがどのMedia Serverに割当られているかは、CDNでは分からないという問題があります。

この問題を解決するために、CDNリクエストを処理するOrigin Serverが必要です。Origin Serverは大きく2つの方法で構築できます。

視聴に必要な情報を共有ストレージに書き込み、ストレージをOrigin Serverとして設定する。
CDNリクエストをMedia Serverと繋ぐProxy ServerをOrigin Serverとして構築する。

最も重視視したのは、予想できない障害が発生した場合に影響範囲を少なく抑えることです。結論として、LINE LIVEのOrigin Serverは2番目の方法で構築しました。

1番目の方法には以下の問題がありました。共有ストレージでは、ストレージに障害が発生したらサービス全体に障害が拡大する可能性が高く、状況によっては障害時間が長くなる可能性もありました。また、ライブ配信数が増えればディスクI/Oも増えるため、ストレージの拡張が必要です。そしてトラフィックのスパイクが発生した場合、安定的に処理するためのキャッシュのような仕組みも必要です。

2番目の方法を選んだのは次の理由のためです。Proxy Serverで構築する場合、リクエストに対して正しいMedia Serverへルーティングするロジックを追加する必要がありますが、そのロジックのコードが正しく作成できてさえいれば、全てメモリで処理できます。この方法ではディスクI/Oも発生しません。

また、エンジニアが書いたコードによって障害ポイントが限定されるため、単一マシン単位で対応できて、予想できなかった障害にも速やかに対応できます。共有ストレージに比べてこの点はメリットです。

最後に、Proxy Serverにキャッシュ機能を追加しました。主な機能として、短い時間内に同じリクエストがある場合、リクエストをキューに積んで最初のリクエストでだけMedia Serverからのレスポンスをキャッシュし、それ以降はキューにあるリクエストをキャッシュから検索するようになっています。

今後について

PCクライアントからライブ配信できる機能がリリースされたため、ゲームライブのような高画質ライブ配信がどんどん増えています。そのための対応を検討しています。またサービスの成長に合わせて、もっと多様なニーズに応えるため、最適な環境を提供しようと頑張っています。

記事を執筆して

久しぶりに記事を書くのが難しかったですが、少なくともLINE LIVEの一部機能を紹介できてとても嬉しく思います。以下にLINE LIVEの発表資料とLIVEシステム構築の参考記事のリンクを挙げましたので、ご興味があればぜひご覧ください（LINE LIVEがリリースされた時期と前後して公開されたFacebookのLiveに関する記事から、Facebookにも私と同じ課題があったと知ることができました）。同じような課題をお持ちの方々に、この記事が少しでもお役に立てれば幸いです。

明日の記事はocadarumaさんによる「Akka HTTPの仕組みを理解する」です。お楽しみに！