#linedevday LINE LIVE を支えるアーキテクチャ の参加レポ＠LINE DEVELOPER DAY 2016
LINE DEVELOPER DAY 2016に今年も今年も参加してきたのでそのメモです。
LINE LIVE を支えるアーキテクチャ
サービス開発3室 大澤和宏様
LINE LIVEとは
歴史
- LIVEキャストを実験的にやってみたら好評だったためリリースしてみました
- 2015/12にリリース
- 2016/08に課金などを盛り込んだLINE LIVE version2をリリースしました
環境
- Java Nginx, MySQL, Redis, Elasticsearch, Fluentd, CDN,etc
- Serverはmedia260+、chatは110+、APIとその他は100+以上ある
LINEとの連携
- LINEの中でもLINE LIVEを配信できる
- LINEのタイムライン上から配信も先月リリースされました
データ解析
- 視聴者数を収集してるが、厳密にやるためにData Labsに依頼している（New stream processing platformwith Apache Flinkのセッションで説明します）
Video Stream Delivery
HTTP Live Streaming（HLS）について
- Appleによって開発されているもので、複数の動画ファイルをまとめることで長時間のビデオを再生できるようにしている
- tsファイルをまとめるm3u8ファイルで構成されている
- CDN経由での配信もやりやすい
- tsは2秒にしている
- cacheをパージしないとライヴ配信ができない
- 複数のビットレートごとにm3u8を用意して、それらを束ねたm3u8ファイルを用意することでビットレート選択して配信ができる
Architecture
- クライアントからRTMPを使ってMediaServersに配信され、OBSにHLSとしてアップロードされる
- アップロード後APIサーバに通知して、ユーザに配信スタートを通知する
- 視聴者からはCDNを通してOBSサーバと通信して視聴する
LINE LIVEでのHLS
- アニメ配信などで多く利用されている方法を使用している
- 情報を暗号化されたURLを生成して、CDN経由で配信する
- m3u8ファイルのアクセス時刻と再生されるべき差分を計算することで、すべての視聴者に同じ動画を再生するようにしている
- アーカイブに保存されている動画を自動的に再生されるものに関しては、暗号化されたURLを生成する
- その後、対応したtsファイルを再生する
回線の不安定によって起こる問題の対処について
- 回線状況が不安定なことでRTMPの切断が多く発生する
- HLSファイルが生成されなくなるためOBSからのファイルを取得できなくなる
- CDNにキャッシュがあればそれを再生するがなければOBSからコンテンツをとるが、OBSには適切なファイルがないため404のレスポンスを受け取ってしまう。その為クライアントの再生はストップしてしまう
- 切断を考慮してクライアントではリトライしてまた再生するようにしている
- しかし404が発生すると大量のリトライなどがOBSに来てしまう問題があった
- Burst API Serverを別途立てて、そこに対してクライアントはポーリングするように別途API Serverを提供した。
- 404を返した場合はサスペンドをクライアントにおくり、クライアントはBurst API Serverに対してポーリングしてサスペンドかどうかを確認するようにして、OBSにアクセスがいかないようにしている
- このAPIはバースト用に考えて構築している。また、通常の再生時のサーバとはわけているのでサービスダウンはない。
- 404を返した場合はサスペンドをクライアントにおくり、クライアントはBurst API Serverに対してポーリングしてサスペンドかどうかを確認するようにして、OBSにアクセスがいかないようにしている
パフォーマンスの改良
- 同時配信数が増えるとサーバの負荷が増えてしまう
- 運用費をさげるために、CPUではなくGPUを使うことで処理効率を上げ、サーバ台数を減らそうとしている
- 720pだと、5並列配信から11は並列にできるようになったりした
Loveとチャット
チャットの仕組み
- 人気のあるチャットでは大量に滝みたいにチャットが流れる
- 100万人くらいが同時に発言した場合に耐えうる用に設計して開発した
- チャットとクライアントはwebsocketを通して開発している
- 視聴者側と配信側では差異はあるが、基本的には同じ仕組みで行われている
- 課金もしたいため、決済用のJSON APIを使ってその後、チャットのサーバへ通信を行うようにしている
- チャットサーバは110台以上のインスタンスを使っているが、基本的には複数のサーバでチャットルームが作成されるように作っている
- Redisのpubsubを使って実装しています
- チャットログもRedisに保存しています
- 数千人単位でチャットルームが分割されるようにしています
チャットのアーカイブ処理について
- アーカイブされた動画を再生するときも当時のチャットが流れるようになっている
- ライブが終了するとMySQLに全て保存されるが、アーカイブされている動画がバズるとMySQLの負荷が高まってしまうので、チャットログをjsonファイルとしておくことで、MySQLにはインデックスだけでjsonファイルにアクセスできるようにした
障害
- jvmのサーバ利用領域を使い切った障害があった
- ももくろのあーりんの配信でチャットに書き込んで1分に1万以上の書き込みが殺到した
LOVE
- エフェクトを連打できるようにしている
- 連射が可能というポリシーで作った
- ボタンがタップするためにHTTP通信が発生するとバーストしてしまうので、定期的に連打数をまとめて通信を行ってカウントしている
- 送信されたラブ数は後ほど集計用にRedis+MySQLやHadoopなどに送っている
- Live中はredisを使っているのでZREVRANGEを使ってランキングで表示できるようにしている
EXAMPLE
- SKE48での企画配信では、2時間で1100万ラブおされ、問題なく配信できました
- 桜坂46の配信では、30分間で230万以上のラブを獲得した
- ハートの獲得数に応じた番組配信を行うことが多いので、必要なものと感じている
- 詳細については安定した love を提供するために、LINE LIVE チャット機能を支えるアーキテクチャなどのブログ参照
- ラブランキングの機能も近々実装予定です
FAQ
- redis clusterは何代構成？
- 3台構成です
- バックアップが1台
- 運用中にFailOverなどはあったか？
- 1回あった。
- クライアントの仕組みがしくっていて、一瞬障害が起こったことがあった
- redisチームのほうにパッチを当ててもう治ってます
- 配信側のRTMPをHLSに変換するところは負荷が高いと思うが、MediaServerの工夫とかはあるか？
- 配信専門チームに作ってもらっているので、エンジニアブログに書くようにプッシュしておきます
