こんにちは。インターンで LINE LIVE のバックエンドの開発をしていました大森智仁です。京都大学工学部情報学科の4回生で、普段は競技プログラミングや最適化案件の実装をしていました。
今回は LINE LIVE の開発をしている LIVE サーバ開発チームにお世話になりました。
背景
LINE LIVE では、本番環境へのリリース前にリリース予定ブランチを確認する為のBeta環境があり、そこでエンジニアが動作確認したり、QAチームがテストします。
その動作確認の際、常に配信中となっている配信が複数あると嬉しいのですが、今までこの配信は手動で用意しており、LINE LIVE は最大 24 時間までしか配信できない仕様のため、配信を用意するために手間がかかっていました。
その手間をなくすため、私は動画ファイルをループ再生して自動的に配信し続けるサーバーを用意し LINE LIVE と繋いで配信するチャンネルを作成することになりました。また、動作確認で用いるため今後さまざまな機能や種別の配信をできるように構築する必要がありました。
手段
- 固定の動画ファイルを ffmpeg で rmtp 送信するコンテナ作成
- kubernetes クラスタ上に配置
- 自動配信システムでライブ配信してるものを LINE LIVE アプリから見れるようにする
といった手順で実装していきました。
設計
過程
固定の動画ファイルを ffmpeg で rtmp 送信するコンテナ作成
実際の LINE LIVE では配信者からの映像を rtmp で受け取り、hls に変換して配信していたので、同様に ffmpeg を用いて mp4 の動画データから rtmp 送信し、nginx で受け取って hls に変換するという方法を取りました。
送信するためには nginx に追加モジュールが必要だったため、ソースコードからインストールしてきました。
こちらの実装に関して、他の案はいくつかありました。その中から 2 つ紹介します。
Live Streaming Service (LSS) に rtmp を送って連携する
ライブ配信用に別チームが管理している LSS というサービスがあり、rtmp に送られた映像から CDN に展開する役割を担っています。その LSS に rtmp 方式で動画を送る方法もありました。しかし、LSS と連携するとなると、アプリと同じ動作をするように作り込む必要があります。すぐ導入できるようにするため、まずは LSS と連携せず、配信サーバーを立てる方法を選びました。
ffmpeg で hls を出力する
こちらは当初タスクをもらった時には思いついていなかったのですが、実装を進めていくうちにこの案もあるということに気づきました。しかし、現段階では配信サーバーを立てていますが、将来的には LSS と連携してあるべき姿を目指すと聞いています。そのため、rtmp 送出ができる状態にしておいた方が良いと判断しました。
kubernetes(k8s) クラスタ上に配置
VKS（社内プライベートクラウドVerdaのマネージドk8s）上に配置しました。これにより、配信の調子がおかしくなった際の再起動も容易でした。
Load Balancer(LB) は k8s のものではなく、社内の Load Balancer (Verda LB) を用いました。最初は k8s の LB を用いていたのですが、Verda LB を用いると SSL 証明書のダウンロードや更新などの必要がなくなるため https 化する際に切り替えました。
自動配信システムでライブ配信してるものを LINE LIVE アプリから見れるようにする
実際のサービスと同じ流れで配信を開始するには手続きが多く、仕様を把握して構築するまでにたくさんの時間がかかると予想したため、テスト用配信を手動で作成し、DB を少し書き換える方法を取りました。
hls url を入れる場所が DB にあったため、そこを書き換えて終了かと思っていたのですが、実は配信の hls url を取得するときその値は読み取られておらず、DB の他の値からコード上で組み立てられていました。ここで問題になってくるのが、ドメイン含む URL の大部分が変更できないということです。なぜなら、変更しようとすると、この為だけにビジネスロジックを書き換えなければならなく、あまり現実的ではないからです。
組み立てられていたドメインは CDN のもので、配信元は社内のストレージプラットフォーム、OBS でした。従って、OBS のどこかに m3u8, ts ファイルをアップロードすれば目的達成となるのですが、m3u8 ファイルがあるはずの場所に mp4 ファイルがあると言われ、アップロードする場所がわからず断念しました。
そのため、redis のキャッシュを書き換える方法を取ることにしました。実は当該 API はレスポンス内容を Redis にキャッシュしているので、そのキャッシュを更新すれば配信の hls url を変更することができます。仕様変更が入ることも踏まえ API を呼び出してキャッシュを作成した後に redis-cli で変更するスクリプトを作り、アプリから配信を見れるようになりました。
web 上だと https 化が必要だったため、ssl 証明書のある URL にし、nginx で CORS の設定をして解決しました。
失敗談
redis 書き換えの際、キャッシュがないときに作成しようとしたこと
キャッシュが存在しない状態があり得たため、私は当初、キャッシュが存在しなければ作成するコードを書こうとしていました。しかし、キャッシュとして持っていた値は hls url 以外に数十ほどの情報を含んだ JSON 文字列でした。hls url 以外の値をコピペしてきた場合、データ構造に変更があった場合に追随できず、デシリアライズに失敗するため、先に API を呼び出して正規ルートでキャッシュを作成した方が良いとメンターさんに教えてもらいました。
結果
app
web
今後の課題
無事、動画を LINE LIVE アプリから見ることができ、ハートやコメントも送れるようになりました。また、チャンネルをフォローしていれば Home 画面に配信が出てくるようにもなりました。今後の課題としては、今は個人配信のみですので、有料配信など特殊な配信などもできるように展開していければいいなと思っています。
感想
タスクに対しての感想は、私が苦手で避けて続けていたインフラ系のタスクでありましたが、メンターやチームの方々の協力のおかげでなんとか最低限のタスクはこなせたのかなと思っています。タスクをこなす中で、インフラ系の知識はもちろんのこと、LINE 内部で使われているサービスにたくさん触れ、理解を深めることができたと思います。また、質問の仕方や実装するときに考えるべきことなど基本的な部分であるものの私に足りていなかったことについても知ることができ、私にとっていい経験になりました。
会社に対しての感想は、仕事をするのにいい環境が揃っていると感じました。私が所属した LIVE サーバ開発チームでは、メンションをつけずに質問を投げても誰かが答えてくれましたし、毎日夕方にあるチームの会議でも質問がしやすくなっており、チームで 1 つのアプリを作っているのだという雰囲気を強く感じました。オフィスについても、食堂からデスク環境、フリードリンクなど業務をする上でいい環境が整っており、東京に住んでいたら毎日出社したいくらいでした。
6 週間と短い間でしたが、インターン生として受け入れていただきありがとうございました。