ニコニコ生放送では配信系のシステムにErlangの採用が増えてきています。あまり聞きなれない（と思う）Erlangという言語、この言語のどこにニコニコ生放送で採用されるだけの良さがあるのか、また、Erlangにすることで何が変わるのか、そして、どうやってErlangという言語を採用し、既存のサービスを置き換えているのか、ドワンゴの文化的な背景も交えてお話しさせていただきます。 2015年2月19日 Developers Summit 2015 発表資料です http://event.shoeisha.jp/devsumi/20150219/session/639/

1. ニコニコ生放送の
配信基盤改善
Developers Summit
セッションID：19-A-6
ハッシュタグ：#devsumiA
2015年2月19日
谷内 崇浩
株式会社ドワンゴ

2. 初めまして
谷内 崇浩 （やち たかひろ）
ドワンゴで配信システムを開発
C++を使った配信サーバの
開発が得意
最近はErlangの普及に熱心
twitter: @gnyo

3. 今日は
Erlangの話をします！

4. あとすこし
生放送の配信基盤のおはなしも

5. まずは
ニコニコについて
弊社のサービス
のブランド名

6. イベント
http://info.dwango.co.jp/
pi/ns/2015/0201/index.html
ニコニコ闘会議
（1/31～2/1）
ニコニコ超会議
（4/25~26）

7. ニコニコ動画
sm21757153

8. ニコニコ生放送

9. 昨年は・・・
弊社の吉村がデブサミで
ニコニコ生放送の書き直しについて
発表しましたが

10. 生放送の構造
配信基盤
生放送サービス
Scala
Play2
ライブストリーミング
メッセージ
コメント
視聴
リクエスト
コメント
今日は
ここの話
をします
ここは
そのまま

11. 今日の流れ
1. 配信基盤について
2. Erlang採用の道のり
3. 配信基盤の改善

12. 今日の流れ
1.配信基盤について
2. Erlang採用の道のり
3. 配信基盤の改善

13. 生放送の配信基盤
生放送配信基盤
Origin
Server
Edge
Server
HLS
Server archive
CDN オンプレ
配信
大規模
配信は
CDNか
ら
Edge
Server
放送
中継中継中継
配信
配信
配信
録画
The Internet

14. 番組数は6,000超
2015年2月10日 22:40
6061番組

15. 視聴者のべ220万人
http://info.dwango.co.jp/pi/ns/2014/1215/index.html
※ 複数の番組における
視聴者の、のべ人数
※

16. 最長527時間
http://info.dwango.co.jp/pi/ns/2014/0411/index.html

17. 配信基盤、
今はどうなってる？
サーバ製品で頑張って運用
大規模な配信はCDNまかせ
長時間配信中はメンテ不能
インフラの職人芸
この運用、健全？

18. で、どうしたい？
自動的にスケール
高い耐障害性
無停止で動く
柔軟に機能を追加できる
高度なプロトコル

19. これを・・・
Erlangを使って実現したい！
やれ!

20. 今日の流れ
1. 配信基盤について
2.Erlang採用の道のり
3. 配信基盤の改善

21. Erlangの特徴
1986年登場
関数型言語
動的型付け
軽量プロセス
アクターモデル
ホットコードスワップ

22. 軽量プロセス
プロセスは超軽量
OSのプロセスとは異なる
気楽にプロセスを作る
まるでOOPの
インスタンスのように

23. アクターモデル
プロセス間のメッセージ通信
専用の演算子が定義済み
ホスト間でも利用可
なので、
機能ごとにプロセス化
あとはメッセージ通信で
PCクラスタも作れる

24. Let it Crash !
Erlangの思想
エラー処理は書かず
何か起こったら殺す
case fun() of
a -> ok;
b -> error
end.
なむ
fun()が’c’を
返すと死ぬ

25. 何がいいのか？
プロセスが死んだときは
監視プロセスが復帰処理
自分で頑張らなくていい
実装が簡潔
影響範囲が限定できる

26. ホットコードスワップ
実行中にコード更新可能
システムは止めなくていい

27. いい言語ですね
でも、
開発者が不足
ノウハウがない
動的型付けかよ！
性能出るのか？

28. Scalaとの性能比較
Scala(+Redis)とErlangで比較
特定のAPIの実装に対して、
秒間リクエスト数
応答時間
を測定

29. 接続数と応答時間
Erlangが
1,500
で頭打ち
Scalaが
2,200
で頭打ち

30. 最短応答時間
最短応答時間
(msec)
Erlang Scala
TCP Connect 0.347 0.339
Body 4.55 2.50
Session Total
TCPの接続は同等、内部処理が重い

31. Scalaと比べ
Erlangの応答時間は144%
Erlangの同時接続数は68%
全体的に悪いが
差は2倍未満
HiPEを使うと高速化

32. 軽量プロセス性能
軽量プロセスの性能測定
起動時間
メモリ使用量

33. 測定条件
指定したプロセス数が起動した時点の
経過時間
メモリ利用量の増分
機材
Intel Core2 Duo 2.8GHz
メモリ: 3GB
supervisor管理下の
gen_serverプロセスで測定

34. 起動時間は
プロセスあたり25μ秒

35. メモリー使用量は
プロセスあたり3kB

36. Erlangのプロセスは
プロセスあたり
25μ秒で起動
3kBのメモリを占有
3GBの搭載メモリで
1,000,000プロセス起動

37. ホットコードスワップ
言語レベルでサポート
更新前のコード呼び出し
最新のコード呼び出し
get_info(X).
user_session:get_info(X).
モジュール
内の呼出
モジュール
名つき呼出

38. 性能はわかった
Scalaより若干遅い
プロセス起動は高速軽量
ホットコードスワップ可能
で、開発者の確保は？
あと、型安全は？

39. 型安全は・・・
dializerで担保
コードにspecを記載
ビルド時に実行
型の静的チェックが可能
でも、
spec書き忘れるとダメ
時々おかしなこと言う

40. だから・・・
開発者はどうするの！
いねー
だろ！

41. Born in the net, Connected by the net.
http://info.dwango.co.jp/recruit/
【急募】
エンジニア

42. それはともかく
ドワンゴ社員は
新しい物好き
言語オタクも多い
基本優秀（のはず）

43. 実際のトレーニング
Step1. 書籍読破と講習
Step2. moyotize
内部ライブラリの開発
moyo（https://github.com/dwango/moyo）
Step3. 課題
サーバを書いてもらう
1週間程度を複数実施
後はpull requestでレビュー

44. とにかく
性能評価と開発・運用の検討を経て、
Erlang採用
評価ポイント
ホットコードスワップ
アクターモデル
クラスタ構築のしやすさ
安定性と実績
プロトコル実装が容易
話は配信基盤に戻ります

45. 今日の流れ
1. 配信基盤について
2. Erlang採用の道のり
3.配信基盤の改善

46. ニコ生の特徴
視聴者が少ない番組がある
視聴者が膨大な番組がある
番組数が多い
ベストエフォートはダメ
デバイスごとに異なる
プロトコル

47. マルチデバイス
向けのシステム
スマホ向けのHLSサーバ
2013年からErlang採用
システムはかなり安定
運用も簡単
KVSもDBも不要

48. アクターモデルと
Let it Crash
モジュールごとにサーバプロセス化
個々のユーザセッションが、
個別のサーバプロセス
問題があったら殺す
影響範囲は狭い
全体は安定

49. KVSとDB不要
アクターモデルで全体で情報共有
ノード決定はコンシステントハッシュ
ユーザ情報、番組情報は
APIから渡す
セッションの状態は
個別のプロセスが保持

50. Erlangの採用事例が
できた
成果が認められて、
開発リーダは社長賞を受賞！

51. Erlang成果出たね
では、PC向けでも頑張ろう！
そこには、大きな壁が・・・

52. 極端な
ロングテールモデル
番組数（人気順）
視聴者数（番組ごと）
極端に番組特
性が異なる
生放送の視聴特性（イメージ）

53. 極端な
ロングテールモデル
人気番組
一つの番組で、
サーバいっぱい使う
通常番組
一つのサーバで、
番組をいっぱい詰め込む
考え方が違う・・・

54. 番組数と視聴者の
規模
6,000番組超
のべ、220万人のユーザ
そして、
番組公開直後の「突入」

55. あきれた長時間放送
527時間メンテできない
この間、アーカイブ必須

56. 対策：クラウド的な
視聴者の多い番組
Origin
Edge
Edge
Edge
Origin
Edge
Edge
Edge
視聴者の少ない番組
Origin
Origin
視聴者が
増えたら
追加
多くの番
組を詰め
込む
コンシステントハッ
シュでノード決定
Origin
クラスタ
Edge
クラスタ

57. ハッシュで資源の
場所を決定
ノードの追加削除に
強い
→Erlangに向いてる
コンシステントハッシュ
0 0xFFFF
16bitのハッシュ空間なら...
0xFFFFの直後に0が来
るような空間を考える
番組の
ハッシュ値
ノードを空
間上にマッ
ピング
ノード
決定

58. 「突入」耐性
一気にユーザが流れ込む
複数のサーバで受付を分散
コンシステントハッシュで
リソース位置を判断
負荷集中ポイントを
作らない

59. 大規模配信
ノードの追加ロジックを開発
ベストエフォートにならないよう
必要な台数を順次投入
中継開始が高速になる
プロトコルを新規開発
ユーザを待たせない！

60. ｐｔｐｔ耐性
リアルタイム特性を維持
ノードの処理量を限定
ErlangのGCは性能を予測可能
ネットワーク帯域
スイッチの場所を考慮
帯域の管理
クライアントの状態監視
軽量プロセス最高！

61. ホットデプロイ
生放送を中継しながら
システムを更新可能
デプロイツールの自動化
fabric利用
システムのrpm化

62. なんとか
道筋は見えています
Erlangによる配信系の更新
にはもう少しかかりますが
より良いサービスを目指し、
できるだけ早い導入を進めます

63. 最後に
ドワンゴではErlangエンジニアを
募集しています
Erlangにご興味のある方
配信システムに強い方
是非、ご応募ください！
http://info.dwango.co.jp/recruit/

64. おわり
ご清聴ありがとうございました。
感謝