不動の人気を誇る動画配信サービス「ニコニコ動画」（ニコ動）と「ニコニコ生放送」（ニコ生）において，動画プレーヤのHTML5化，そしてバックエンドシステムの刷新が図られました。このプロジェクトの背景や使われた技術，苦労したポイントなどについて，ドワンゴのエンジニアである七田弘志氏（写真1），後藤哲志氏（写真2），三須健太郎氏（写真3）にお話を伺いました。

フロントエンドのみならず，バックエンドシステムも刷新

──どのようなきっかけから，HTML5化プロジェクトが始まったのでしょうか。

七田：大きな要因となったのは，主要WebブラウザでFlashのサポートを打ち切るという方針が示されたことですね。今までもスマートフォンやテレビデバイスなどではHTML5プレーヤを実現できていたのですが，PC版のページは既存機能が大きく，プレーヤの作り変えが後手に回っていた部分が大きかったんです。それで我々も作りながら考えるという形でプロジェクトが始まりました。そのとき，少なくともフロントに関しては完全にプレーヤを乗せ替える必要があるのはわかっていましたが，バックエンドはそれ以前から改修を進めていたんですよね。

後藤：バックエンド側の改修プロジェクトは，2014年ごろにニコ生を強化したいといった話があり，そこから始まっています。そのプロジェクトでいったん成果を出しつつ，それを拡大・発展する形であらためて改善を進めました。特に重視したのはニコ生とニコ動のシステム的な融合で，この2つのサービスを同じリソースを使って提供することが大きなポイントになりました（図1）。

七田：バックエンドのプロジェクトは大変でしたね。従来のニコ動ではオリジナルファイルをそのまま再生していましたが，オリジナルファイルのままだとHTML5では再生に失敗することがあります。そもそもニコ動ではスマートフォンやTVなどの多様なデバイスがあるということもあって，動画の再生可能性を高めるために思い切ってトランスコードする方針に決めました。ただ，実際にトランスコードを行うには，アウトプットされる映像の画質を決める作業が必要になります。一般的な動画サービスでは，動画が投稿されるとそれをエンコードし，画質の異なるいくつかのファイルを生成します。こうした処理をニコ動でも行うのですが，その画質をどうするのか，どういったパラメータにするのかを決めるのはすごく苦労しました。

後藤：今までオリジナルファイルを再生してきたユーザーにも満足してもらえるものを見つけるのは，答えがないんですよね。それでさまざまなジャンルの動画を用意し，実際にトランスコードした何種類かの映像を見つつ，どれが良いかを5段階評価する取り組みを続けました。

写真1　七田弘志氏

七田：以前はオリジナルファイルのアップロードが完了すればOKでしたが，画質の異なる複数のトランスコードを行うと相応の時間がかかります。もし，それを最もクオリティが高いパラメータにすれば，当然画質は上がるのでユーザーにとってはうれしいのですが，一方でアップロードにすごく時間がかかることになります。こうしたバランスの調整は難しかった部分です。

──具体的な開発内容や従来からの変更点について教えてください。

七田：フロントの変更点としては，プレーヤがFlashからHTML／JavaScript／CSSで開発されるようになったことが大きいです。この変更によって，Flashでストリーミング再生するために使っていた疑似ストリーミングという動画配信方法が使えなくなってしまいました。そのため，現在公開されているHTML5プレーヤではレンジリクエストで動画を取得して再生するように実装されています。

三須：ニコニコ生放送のプレーヤもHTML5化していて，開発ではコンポーネント単位でUIを作成するアトミックデザインを採り入れました。作業はコンテナ側とコンポーネント側に分かれて行っていますが，私が担当したコンポーネント側ではReactとReact Storybook，TypeScript，CSS Modulesを使っています。アトミックデザインはまだ採り入れているところは少ないと思うのですが，かなり成功した部類に入ると感じています。

後藤：バックエンドシステムは今回さまざまな改善を行いました。特に大きかったのは，先にお話しした，動画と生放送の配信システムを内部的に統合した点です。また動画については，基本的にユーザーから投稿されたファイルを大きなファイルストレージに蓄積し，それを配信するという形ですが，今回からサポートしたレンジリクエストに対応できるように，ファイルの持ち方などを工夫しました。また，現状ではまだサービスに採り入れていませんが，将来を見据えて，新しいストリーミング規格であるMPEG-DASHへの対応も視野に入れています。

バックエンドシステムの開発で使われた「Erlang」

──バックエンドの開発ではErlangを使われたと伺いました。Erlangを本格的に開発に使っている事例は少ないと思いますが，なぜErlangだったのでしょうか。

後藤：まず1つ目の理由は，今回のプロジェクトの前段となったシステムがあり，それをErlangで作っていたことです。そのシステムを開発したとき，ErlangとScalaで性能を比較したのですが，実はScalaのほうが性能は良かったんです。ただ，Scalaはガベージコレクションによる性能低下が大きかったこと，また信頼性の点でErlangにアドバンテージがあると判断したことから，最終的にErlangで開発することになりました。

写真2　後藤哲志氏

そもそもErlangは分散システムに特化した機構を多数兼ね備えた言語なので，大量のサーバを使う今回のようなシステムには非常に合っていたと考えています。またオンプレミスで運用している多数のサーバを使っているので，何台かのサーバが落ちている前提でシステムを動かす必要があるという要件がありました。こういった要件にもErlangは非常にマッチしていました。

──実際にErlangで開発する中で，注意された点はありますか。

後藤：Erlangは動的型付け言語であり，複数のエンジニアで開発するときにはバグが生まれやすいという難点があります。そこで活用したのがDialyzerです。Erlangのコード解析に利用するツールがDialyzerで，型エラーを検知することもできます。これを利用することで，型エラーの問題をおおよそ回避できました。ただ，Dialyzerの処理はすごく重いんです。実行するとメモリを4GBぐらい奪っていきますし，処理にも10分ぐらいかかります。なので，自分のPCで開発している場合はサーバ側でDialyzerの検査を行うようにしていました。社内ではGitHub Enterpriseを使っていて，コミットするとJenkinsで自動的にDialyzerを起動して検証するといったプロセスにしています。