ドワンゴ 技術コミュニケーション室のsaka1です。

この記事では、社内で用いられているLightningTalk(LT)用のライブストリーミングシステムについて紹介したいと思います。 LTは普段こんな感じで行われています。

実は、社内ではLTの開催形式について見直しが行われつつあります。 記事の執筆時点ではまだこのシステムは使われていますが、ライフサイクルとして末期かもしれません。 せっかくなのでシステムがどういったものだったかについての記録を残したいと思い、記事を書くことにしました。

記事ではまず、なぜシステム開発が必要だったかについて簡単に説明し、次にシステムの技術的詳細について紹介していきます。

LT運営にどういった課題があったか

エンジニア有志が参加するLT会はそれまでも定期開催されていたのですが、エンジニアの人数が増えるにつれて、 一つの会議室に全員が物理的に集合してLTを開催するのは難しくなっていました。 同じWebエンジニアであっても働くフロアやビルが違うという状況がある中、 せめて発表はライブストリーミングの形で手軽に見たいよね、という要望がずっと出ていました。

そこでLT運営チームは、ニコニコ生放送（ニコ生）のdev版を使った配信を 試してみたのですが……LTが社内ライブ配信されるのは便利だと分かったものの、課題が見つかりました。

• あくまで開発環境なので安定している保証がない
  • 例えば次のリリースに向けたデプロイがされると、LT配信が壊れてしまう可能性がある
  • かといってLTのために開発を止めるのは本末転倒になってしまう

つまり、開発環境に開発以外のことを相乗りさせようとしているのが筋悪だということです。 じゃあもう1つニコ生があればいいのか？ というとそれも難しそうでした。 ニコ生は非常に多機能なシステムなので、LTのためだけにもう一つのdev環境を準備するのはとても現実的ではありません。

困った上司はsaka1に「社内LT配信のシステム作ってよ！！」 「映像が流れて、あとコメントも出せるといいな！！」と言ってきたのが開発の始まりです。

求められていたシステムはどんなものか？

改めて要件を整理すると、次のようなLT配信システムが求められていることが分かりました。

• LT現場のカメラ映像をPCブラウザから視聴できるページを作ること
• コメント（いわゆるニコニコ風の、画面オーバーレイ型の流れるコメントです）を流せること
• 低コストで作ること
  • インフラにかかる費用を最小化したい（LTしてない時はリソース利用を止めたい）
  • このシステム自体の開発にもあまり工数を割きたくない

早い安いうまいを実現してくれという感じで困った要求ですが、これをなんとか具現化していくことになりました。

何を作らないことにしたか

システムの構成について紹介する前に、何を しなかったか について述べさせてください。 LT配信システムは通常のWebシステム開発ではしないような割り切りを入れています。一般論としてアンチパターンに近いものもあるかもしれません。

• 中・大規模配信への対応をしない
  • 社内向けなので同時配信数はどんなに多くても100〜200ぐらいという想定でした
  • したがって複数ノードによる配信やCDNの利用は考慮外としました
• 高可用性は考えない
  • 冗長化などはしませんでした。たとえLTが見れなくなっても業務に支障は出ないためです
• データの永続化をしない
  • 詳細は後述しますが、コメントはインメモリで保持します。例えばサーバを再起動すると揮発してしまいますが許容することにしました
  • 配信された映像の保存は配信機器側で行うことにしました
• UIはごく単純に
  • 流すコメントは別で取ってくることにして、視聴画面には映像があるだけという作りにしました

別の言い方をすると、今回の開発ではスコープをできる限り絞り込んだことによって、ごく単純な構成を手に入れているという側面があります。

具体的なシステム構成について

とにかく手早く作ることを求められたので、既製品を最大限に流用することにしました。

システムはアプリケーションサーバと映像配信サーバから構成されます。 アプリケーションサーバ……と言いつつ静的アセットの配信も行うサーバデーモンですが、Sinatraで書かれています。 クライアントにはJavaScriptで書かれた視聴アプリを配信し、 クライアントは映像配信サーバをHLS受信します（ライブラリとしてはhls.jsを用いた普通のHLS配信です）。

アプリケーションサーバはオンプレミスの仮想化環境に、映像配信サーバはAWSにあります。 映像配信サーバは、LTが行われていない時にはインスタンス停止することで無駄な費用が発生するのを避けています。 （意図したわけではないのですが）ハイブリッドクラウドでいいとこ取りをしようというような構成になってしまいました。

以降、機能別にポイントを挙げていきます。

ライブストリーミング

映像配信サーバにはWowza on AWSを使うことにしました。 ドワンゴはVOD/LIVEの映像ストリーミングを業務で扱っている会社ですので、 内製の配信サーバやライブラリもあるのですが、今回はあえて市販品を使うことにしました。

• 内製の配信サーバは明らかにオーバースペックで、利用するメリットがあまりない
  • 社内LTで1000番組を同時配信！！ とかやらないので……
• WowzaはAMIの有償サブスクリプションで利用できるので、インスタンスを構成するコストが低い

などの理由によります。Wowzaは基本的に扱いやすくいい子です。今回の用途には十分適合してくれました。

コメント

コメントについての問題は2つあり、コメントをクライアントでどう描画するかと、コメントをどこから取得してクライアントに流すかです。

ニコニコ風の画面にオーバーレイする形で流れるコメントですが、実はコメントを正しく描画するのは簡単ではないことが知られています。 筆者もあまりよく知らないのですが、いくつものルールを守らないと「らしく」ならないそうです。

幸いなことに、社内には生放送向けコメント描画エンジンのJavaScriptライブラリが整備されていました。 ライブラリはReactコンポーネントの形になっていたので、ニコ生の開発チームから使い方を聞いて組み込むと、 あっさり本物の描画ができるようになりました。

コメントの取得については、次のような仕組みをざっと作りました。

• SlackのLTチャンネルへの投稿をリアルタイムで吸い、アプリケーションサーバにPOSTするSlack Appを書く
  • Rubyのgemを使いReal Time Messaging APIから投稿を吸い上げるようにしました
• APIサーバは最新のコメント何件かをメモリに保持する
• クライアントはアプリケーションサーバをポーリングし、新着コメントが受信できたら表示する
  • 新着分を認識するために、サーバ側でコメントにシーケンシャルなIDを採番して付けています

非常に原始的な仕組みではあるものの、単純な実装で期待した挙動になってくれているようです。

その他、細かな工夫

映像配信の設定チューニング

映像配信のトランスコード設定などは、ちょっとだけ調整しました。といっても、ほとんどがWowzaのデフォルトです。

LTは動きが少なく文字などが多い傾向にあるため、ビットレートに対して解像度を大きくした方が画質が良く見えるようです。 また、リアルタイム性を改善するため、HLSのセグメント長を多少縮めた気がします（配信の遅延が大きすぎると、現地組と映像視聴組でSlackの話題がずれるという問題がありました）。 あとはABRを有効化しておきました（WowzaのUIをポチポチするだけです）

AWS側の構成管理

AWS側の構成管理はTerraformを使っています。 実際のところインスタンスが一つ立っているだけなのですが、AWSからの配信を社内限定にするために、 アクセス元IPのホワイトリストの管理が必要だったりと、この規模でさえ適当に手構築するよりTerraformを使った方が便利だったように思います

管理機能

アプリケーションサーバにはいわゆる管理機能がついています。具体的には映像配信サーバのインスタンス起動・終了をUIからできるようにしてあります

LT配信システムを導入してみてどうだったか

それなりに便利だと好評を得られました。……さらに、思いがけない副次的な利用が発生することもありました。 このシステムは本来エンジニアのLTのために作られたわけですが、他にも例えばディレクターの発表会など、社内に向けて映像を発信したいという需要はそれなりにあったらしく、LTではない場面で活用されるケースも出てきています。

まとめ

社内で用いられているLTライブストリーミングシステムについて紹介しました。 Wowzaを立ててブラウザに映像配信という程度であればとても簡単にできるので、おすすめです。