ドワンゴのエンジニア魂

第2回 大量トラフィックを支えるインフラ~独自プロトコル,ファイルシステムの実装もいとわない!~

この記事を読むのに必要な時間:およそ 3 分

クラスタ内通信で使うプロトコルを独自に開発

川平:通信という意味では,システム内で使う映像や音声を低遅延で転送するために,DMTPという独自のプロトコルを開発しました。似た特性のプロトコルに,アドビシステムズが開発したRTMP(Real-Time Messaging Protocol)がありますが,今回の基盤刷新ではノード間の映像の転送などをすべて独自開発のDMTPで実現しました。

――RTMPを使わずに独自開発のプロトコルを開発した理由は何でしょうか。

川平:RTMPは自由度が低い部分があるほか,クラスタ内での利用には不要な仕様が多かったりするため,シンプルなプロトコルで通信したいと考えました。特に,将来的に複数の映像の同期や合成などの加工も考えているのですが,RTMPではタイムスタンプを表すために32ビットのミリ秒単位の値を使っているため,正確な時刻が必要な加工では精度が不足することがあります。たとえば44.1kHzの音声の1サンプルをミリ秒で指定できませんし,30fpsのフレームの間隔も正しく表現できません。ニコ生には1週間以上のすごく長い番組もあるので,32ビット幅だとすこし心許ないと思い,そういった面からも独自に開発しようということになりました。

太田:DMTPの一番の目的は映像と音声の配信で,それに特化することでコンパクトな仕様になっているほか,用途などに応じて調整できる自由度も持たせています。

動画配信に特化した分散ファイルシステム

――それ以外で,今回の新たな基盤構築のために新規で開発したものはありますか。

太田:実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。

写真3 川平航介氏

写真3 川平航介氏

川平:当初利用しようとしていた分散ファイルシステムが,思ったよりも性能が出ないことがわかったときは結構焦りました。まずは設定や構成の変更で性能の向上を試みたり,実装を読んだうえでデータへのアクセスのしかたを工夫したりして処理効率を高めました。それでも目標とする性能を出すことは難しいとわかったのですが,ネットワークやサーバの性能をちゃんと使えればもっと多くの配信をさばけるはずと考え,独自に開発しようという流れになったんです。

太田:動画配信サービスの特徴として,1つのファイルのデータサイズが数百MBから数十GBと非常に大きいことが挙げられます。それを保存する際に,冗長性を担保するために複数のノードに複製を置くわけですが,ディスク容量をできるだけ抑えて,かつ耐障害性を高めなければなりません。

この際,単に複数のノードに同じ内容を分散して保存するだけだとディスク容量的に厳しい。そこで,消失訂正符号(イレイジャーコード)と呼ばれるしくみを採り入れたのですが,ここでも1つ問題がありました。1つのファイルを小さなブロックに分割して複数のノードに分散するのですが,ブロックサイズが小さいため動画再生時に5~6台程度のノードから細かいブロックを同時に集めてくる必要があり,これはハードディスクに優しくないんです。ブロックサイズを大きくすればスループットは出しやすくなりますが,ストリーム配信で重要となる「安定したペースで最初から最後まで配信し続ける」といった要件を達成するのが困難になるという問題がありました。

基本的にハードディスクは一気に読み込んだほうが性能を引き出せますが,イレイジャーコードを使うと複数のノードで細かなデータアクセスが発生してしまいます。当初は1ノードあたり1,000ユーザー程度をさばければよいと考えていましたが,実際はそれを大きく下回るアクセスにしか対応できませんでした。それが最も大きな課題で,その解決に向けて調査を行い,独自の分散ファイルシステムの開発を進めることになりました。現状は初期バージョンの開発完了にかなり近づいています。

――オープンソースとして公開されている分散ファイルシステムはいくつかありますが,汎用的なプロダクトで対応するのは難しかったのですね。

太田:そうですね。やはり動画配信で求められるスペックは,一般的な分散ファイルシステムの仕様から考えると特殊な部分があり,一般に公開されているプロダクトで対応するのは難しいかもしれません。

――ちなみに,分散ファイルシステムの開発に使った言語は何だったのでしょうか。

太田:Rustという言語で,ガベージコレクションがなく,C++にメモリ安全性の機能を付加したようなものです。ニコニコの動画・生放送の配信基盤開発ではErlangを使うことが多いのですが,レイテンシを細かく制御したい分散ファイルシステムの分野では,どうしてもガベージコレクションが気になってきます。たしかにErlangのガベージコレクションはすごく優秀ですが,自分で制御したほうが安定して予測した性能を出しやすく,またデータ構造を工夫することで消費メモリサイズも大幅に削減できるので,ガベージコレクションのないRustを選択しました。Rustは低レイヤのリソースを直接操作するような領域にも強いので,将来的に検討している,ブロックデバイスを直接制御するような場面でも有効だと考えています。

“すごいサービス”に向けての土台作り

――現状のプロジェクトの進捗状況を教えてください。

原:会長の川上(量生氏)やリーダー陣,僕たちアーキテクトの中で話し合っている「こんなものが作りたいね」というのが100だとすると,現状はまだ3とか5くらいです(笑)⁠現状は,とにかく複雑化した従来のしくみをキレイにして作り直し,一部を載せ替えたという段階で,載せ替えを完了するのが次のステップです。この基盤を使ってすごいサービスを作っていくのが3番目のステップで,そこに向けて開発を続けています。

太田:ニコ動とニコ生の基盤を1つにまとめるという目標の第一段階は達成できましたが,それは1つのステップにすぎません。やりたいことはもっと先にあるんです。

原:単純な基盤の作り直しであれば,こんなオーバースペックなプロジェクトをやる必要はなかったのですが,先ほどお話しした100を目指すための投資ということです。

――その100を目指すうえで,エンジニアの役割は非常に大きいと思います。ドワンゴでは,どういったエンジニアが求められているのでしょうか。

原:コンピュータサイエンスの深い知識を持っていて,言語は比較的何でもかまわない,そんな人がいいですね。要件やサービス特性に基づいた最高のアルゴリズムとデータ構造はどのようなものか,その時間╱空間計算量はどうなのか,ハードウェアリソースを使い切れるか……このようなことについて,ホワイトボードを使いながら議論できる,そういった人に来てほしいと思っています。

――本日はありがとうございました。

ドワンゴでは,各種エンジニアを募集しています。

詳しくは,http://dwango.co.jp/recruit/をご覧ください。

WEB+DB PRESS

本誌最新号をチェック!
WEB+DB PRESS Vol.106

2018年8月24日発売
B5判/144ページ
定価(本体1,480円+税)
ISBN978-4-7741-9943-6

  • 特集1
    [コードで超わかる!]
    実践Android/iOSアプリ設計

    開発を加速させる実装パターン
  • 特集2
    [速習]Spring Boot
    簡潔にコードを書けるJavaフレームワーク
  • 特集3
    仮想DOM革命
    ReactでGUI設計が変わる!

バックナンバー

ドワンゴのエンジニア魂

コメント

コメントの記入