大量のユーザーを抱える「ニコニコ動画（ニコ動⁠）⁠」⁠「⁠ニコニコ生放送（ニコ生⁠）⁠」をさらに進化させるべく，ドワンゴでは土台となる基盤を見直し，大幅なアップデートを実施した。ドワンゴのエンジニアである原耕司氏（写真1⁠）⁠，太田健氏（写真2⁠）⁠，川平航介氏（写真3）の3名にお話を伺い，プロトコルや分散ファイルシステムまで独自に開発したという，このプロジェクトの真相に迫った。

将来のサービス拡充に向けて土台を整備

――今回，サービスの基盤部分を大幅に刷新された理由は何でしょうか。

原：ニコ動は，サービスの提供開始から時間が経ったことで裏側のコードが複雑になっており，これから新たな機能をバンバン追加するのが厳しい状況になっていました。そこで，将来的なサービス拡充に対応できる新たな土台をスクラッチから作ろうという話になりました。

太田：典型的な部分では，動画と生放送がそれぞれ別のしくみで配信されていることが挙げられます。さらに，同じ生放送でもPC向けとモバイル向けで別のシステムが使われていて，なおかつサービスの拡充に伴って肥大化していたことも問題でした。この先に進むためにはさまざまなサービスをまとめて扱える基盤を作る必要があるということで，このプロジェクトがスタートしたんです。

――今回の基盤部分の刷新において，最も大きなポイントになった要件は何だったのでしょうか。

写真1　原耕司氏

原：ニコニコで扱っている各々のコンテンツをできるだけ統一された形で取り扱えるようにすることが大きな要件でした。生放送や動画のコンテンツ，あるいは生放送を録画してあとで動画として視聴するなど，さまざまなユースケースが考えられます。その一つ一つのコンテンツを別々なものとしてとらえるのではなく，状況に応じて適切に配信する基盤を整えたいと考えました。

――アーキテクチャの設計はスムーズに進んだのでしょうか。

原：設計はすんなり進められましたが，実装を進める中で隠れていた要件が発覚することもあり，多少の手戻りはありました。たとえば，動画視聴時の手順の1つに，その動画を再生するための権利を取得する処理があります。我々はそれをサーバ側から呼ぶことを前提にしていましたが，プロジェクトの途中で，権利取得の処理をクライアントが直接呼び出すケースもあることがわかったんです。手戻りが発生することにはなりますが，必要な処理だったので対応しました。

川平：サービスとしての歴史が長い分，要件も複雑になっていました。当然ヒアリングにも時間を割きましたが，それでも見逃してしまう部分があり，その対応も苦労しました。

独自のアルゴリズムで多数のノードの協調制御を実現

――簡単に，今回のシステムの概要を教えてください。

原：データフローで表現するとすごくシンプルです（図1⁠）⁠。アプリサーバでユーザー認証などの処理が行われたあと，ユーザーのスマートフォンやPCから生放送の映像や動画がアップロードされます。今回開発した「Dwango Media Cluster」は，こうした生放送の映像や動画をスマートフォン用やPC用などいくつかのターゲットに分けてトランスコードを行いつつ，動画であればストレージにも保存し，最終的にエッジサーバから配信します。

――以前の基盤と比べて，最も大きく変わったのはどういった部分でしょうか。

原：以前はバラバラだったシステムを完全に統合したことです。従来のしくみはそれぞれのサービスで別々のサーバが使われていたため，サービスをまたいでリソースを融通させられませんでした。しかし今回の基盤では，各々のノードが動画と生放送のどちらにでも対応でき，必要に応じてリソースを適切に配分できます。

太田：年末の深夜の生放送や，人気のあるユーザーの生放送で急激にトラフィックが増えたとき，以前は対応するのが大変だったんです。しかし今回の基盤では，そのような急激なトラフィックの変化にも対応しやすくなりました。

――今回のシステムで特に工夫した点を教えてもらえますか。

原：まず1つは，それぞれのノードに対する処理の振り分けですね。単純なサービスであれば，ロードバランサでそれぞれのノードに処理を振り分ければ十分です。ただ，今回の基盤は動画のトランスコードが含まれるので，すごく処理が重いんですね。さらに生放送では，1つの番組でも5～6ノードが連携して動作します。こうした処理を単純なロジックで振り分けると，ハードウェアリソースを有効に活用できないだけではなく，そもそもサービスとして成り立たないことが予想されました。そこで，利用しているリソースを各ノードで常に管理し，それを一元的に把握することで，適切なノードに処理を割り当てています。

川平：実際にはマスタノードのようなものはなく，各ノードのCPUやディスクの使用率をクラスタ全体で共有し，どのノードに処理させるのがベストかを判断するアルゴリズムを作りました。

写真2　太田健氏

太田：マスタがコントロールする形では，どうしてもそこがボトルネックになりやすいので，マスタとなる情報をすべてのノードが持ち，どのノードでも判断できるようにしました。ただこの方式も，クラスタのサイズが巨大になるにつれて，各ノードの情報を通知・収集するためのコストが無視できなくなってきます。そのため，リソース管理を階層化したり，各ノードが必要な情報のみを共有する，といったしくみを入れることも検討しています。

原：配信処理は複数のノードを使って実現しているので，それぞれの処理を有向グラフとして抽象化し，たくさんあるクラスタ内のノードのどれに割り当てるかというアルゴリズムを開発しています（図2⁠）⁠。配信処理におけるタスクグラフを定義して，そのときどきでどのノード群に処理を割り当てるかを判断しています。

太田：ノード数が多いので，通信コストも重要です。生放送ストリームをノード間で中継したり，動画ファイルを移動・複製したりする場合に，位置関係を意識して目的ノードや転送経路を決定しないと，経路上のネットワークのキャパシティをオーバーしてしまうことにもなるため，そのあたりも考慮したアルゴリズムにしています。