Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ニコニコ生放送の配信基盤改善

52,416 views

Published on

ニコニコ生放送では配信系のシステムにErlangの採用が増えてきています。あまり聞きなれない(と思う)Erlangという言語、この言語のどこにニコニコ生放送で採用されるだけの良さがあるのか、また、Erlangにすることで何が変わるのか、そして、どうやってErlangという言語を採用し、既存のサービスを置き換えているのか、ドワンゴの文化的な背景も交えてお話しさせていただきます。

2015年2月19日 Developers Summit 2015 発表資料です
http://event.shoeisha.jp/devsumi/20150219/session/639/

  • Be the first to comment

ニコニコ生放送の配信基盤改善

  1. 1. ニコニコ生放送の 配信基盤改善 Developers Summit セッションID:19-A-6 ハッシュタグ:#devsumiA 2015年2月19日 谷内 崇浩 株式会社ドワンゴ
  2. 2. 初めまして 谷内 崇浩 (やち たかひろ) ドワンゴで配信システムを開発 C++を使った配信サーバの 開発が得意 最近はErlangの普及に熱心 twitter: @gnyo
  3. 3. 今日は Erlangの話をします!
  4. 4. あとすこし 生放送の配信基盤のおはなしも
  5. 5. まずは ニコニコについて 弊社のサービス のブランド名
  6. 6. イベント http://info.dwango.co.jp/ pi/ns/2015/0201/index.html ニコニコ闘会議 (1/31~2/1) ニコニコ超会議 (4/25~26)
  7. 7. ニコニコ動画 sm21757153
  8. 8. ニコニコ生放送
  9. 9. 昨年は・・・ 弊社の吉村がデブサミで ニコニコ生放送の書き直しについて 発表しましたが
  10. 10. 生放送の構造 配信基盤 生放送サービス Scala Play2 ライブストリーミング メッセージ コメント 視聴 リクエスト コメント 今日は ここの話 をします ここは そのまま
  11. 11. 今日の流れ 1. 配信基盤について 2. Erlang採用の道のり 3. 配信基盤の改善
  12. 12. 今日の流れ 1.配信基盤について 2. Erlang採用の道のり 3. 配信基盤の改善
  13. 13. 生放送の配信基盤 生放送配信基盤 Origin Server Edge Server HLS Server archive CDN オンプレ 配信 大規模 配信は CDNか ら Edge Server 放送 中継中継中継 配信 配信 配信 録画 The Internet
  14. 14. 番組数は6,000超 2015年2月10日 22:40 6061番組
  15. 15. 視聴者のべ220万人 http://info.dwango.co.jp/pi/ns/2014/1215/index.html ※ 複数の番組における 視聴者の、のべ人数 ※
  16. 16. 最長527時間 http://info.dwango.co.jp/pi/ns/2014/0411/index.html
  17. 17. 配信基盤、 今はどうなってる? サーバ製品で頑張って運用 大規模な配信はCDNまかせ 長時間配信中はメンテ不能 インフラの職人芸 この運用、健全?
  18. 18. で、どうしたい? 自動的にスケール 高い耐障害性 無停止で動く 柔軟に機能を追加できる 高度なプロトコル
  19. 19. これを・・・ Erlangを使って実現したい! やれ!
  20. 20. 今日の流れ 1. 配信基盤について 2.Erlang採用の道のり 3. 配信基盤の改善
  21. 21. Erlangの特徴 1986年登場 関数型言語 動的型付け 軽量プロセス アクターモデル ホットコードスワップ
  22. 22. 軽量プロセス プロセスは超軽量 OSのプロセスとは異なる 気楽にプロセスを作る まるでOOPの インスタンスのように
  23. 23. アクターモデル プロセス間のメッセージ通信 専用の演算子が定義済み ホスト間でも利用可 なので、 機能ごとにプロセス化 あとはメッセージ通信で PCクラスタも作れる
  24. 24. Let it Crash ! Erlangの思想 エラー処理は書かず 何か起こったら殺す case fun() of a -> ok; b -> error end. なむ fun()が’c’を 返すと死ぬ
  25. 25. 何がいいのか? プロセスが死んだときは 監視プロセスが復帰処理 自分で頑張らなくていい 実装が簡潔 影響範囲が限定できる
  26. 26. ホットコードスワップ 実行中にコード更新可能 システムは止めなくていい
  27. 27. いい言語ですね でも、 開発者が不足 ノウハウがない 動的型付けかよ! 性能出るのか?
  28. 28. Scalaとの性能比較 Scala(+Redis)とErlangで比較 特定のAPIの実装に対して、 秒間リクエスト数 応答時間 を測定
  29. 29. 接続数と応答時間 Erlangが 1,500 で頭打ち Scalaが 2,200 で頭打ち
  30. 30. 最短応答時間 最短応答時間 (msec) Erlang Scala TCP Connect 0.347 0.339 Body 4.55 2.50 Session Total TCPの接続は同等、内部処理が重い
  31. 31. Scalaと比べ Erlangの応答時間は144% Erlangの同時接続数は68% 全体的に悪いが 差は2倍未満 HiPEを使うと高速化
  32. 32. 軽量プロセス性能 軽量プロセスの性能測定 起動時間 メモリ使用量
  33. 33. 測定条件 指定したプロセス数が起動した時点の 経過時間 メモリ利用量の増分 機材 Intel Core2 Duo 2.8GHz メモリ: 3GB supervisor管理下の gen_serverプロセスで測定
  34. 34. 起動時間は プロセスあたり25μ秒
  35. 35. メモリー使用量は プロセスあたり3kB
  36. 36. Erlangのプロセスは プロセスあたり 25μ秒で起動 3kBのメモリを占有 3GBの搭載メモリで 1,000,000プロセス起動
  37. 37. ホットコードスワップ 言語レベルでサポート 更新前のコード呼び出し 最新のコード呼び出し get_info(X). user_session:get_info(X). モジュール 内の呼出 モジュール 名つき呼出
  38. 38. 性能はわかった Scalaより若干遅い プロセス起動は高速軽量 ホットコードスワップ可能 で、開発者の確保は? あと、型安全は?
  39. 39. 型安全は・・・ dializerで担保 コードにspecを記載 ビルド時に実行 型の静的チェックが可能 でも、 spec書き忘れるとダメ 時々おかしなこと言う
  40. 40. だから・・・ 開発者はどうするの! いねー だろ!
  41. 41. Born in the net, Connected by the net. http://info.dwango.co.jp/recruit/ 【急募】 エンジニア
  42. 42. それはともかく ドワンゴ社員は 新しい物好き 言語オタクも多い 基本優秀(のはず)
  43. 43. 実際のトレーニング Step1. 書籍読破と講習 Step2. moyotize 内部ライブラリの開発 moyo(https://github.com/dwango/moyo) Step3. 課題 サーバを書いてもらう 1週間程度を複数実施 後はpull requestでレビュー
  44. 44. とにかく 性能評価と開発・運用の検討を経て、 Erlang採用 評価ポイント ホットコードスワップ アクターモデル クラスタ構築のしやすさ 安定性と実績 プロトコル実装が容易 話は配信基盤に戻ります
  45. 45. 今日の流れ 1. 配信基盤について 2. Erlang採用の道のり 3.配信基盤の改善
  46. 46. ニコ生の特徴 視聴者が少ない番組がある 視聴者が膨大な番組がある 番組数が多い ベストエフォートはダメ デバイスごとに異なる プロトコル
  47. 47. マルチデバイス 向けのシステム スマホ向けのHLSサーバ 2013年からErlang採用 システムはかなり安定 運用も簡単 KVSもDBも不要
  48. 48. アクターモデルと Let it Crash モジュールごとにサーバプロセス化 個々のユーザセッションが、 個別のサーバプロセス 問題があったら殺す 影響範囲は狭い 全体は安定
  49. 49. KVSとDB不要 アクターモデルで全体で情報共有 ノード決定はコンシステントハッシュ ユーザ情報、番組情報は APIから渡す セッションの状態は 個別のプロセスが保持
  50. 50. Erlangの採用事例が できた 成果が認められて、 開発リーダは社長賞を受賞!
  51. 51. Erlang成果出たね では、PC向けでも頑張ろう! そこには、大きな壁が・・・
  52. 52. 極端な ロングテールモデル 番組数(人気順) 視聴者数(番組ごと) 極端に番組特 性が異なる 生放送の視聴特性(イメージ)
  53. 53. 極端な ロングテールモデル 人気番組 一つの番組で、 サーバいっぱい使う 通常番組 一つのサーバで、 番組をいっぱい詰め込む 考え方が違う・・・
  54. 54. 番組数と視聴者の 規模 6,000番組超 のべ、220万人のユーザ そして、 番組公開直後の「突入」
  55. 55. あきれた長時間放送 527時間メンテできない この間、アーカイブ必須
  56. 56. 対策:クラウド的な 視聴者の多い番組 Origin Edge Edge Edge Origin Edge Edge Edge 視聴者の少ない番組 Origin Origin 視聴者が 増えたら 追加 多くの番 組を詰め 込む コンシステントハッ シュでノード決定 Origin クラスタ Edge クラスタ
  57. 57. ハッシュで資源の 場所を決定 ノードの追加削除に 強い →Erlangに向いてる コンシステントハッシュ 0 0xFFFF 16bitのハッシュ空間なら... 0xFFFFの直後に0が来 るような空間を考える 番組の ハッシュ値 ノードを空 間上にマッ ピング ノード 決定
  58. 58. 「突入」耐性 一気にユーザが流れ込む 複数のサーバで受付を分散 コンシステントハッシュで リソース位置を判断 負荷集中ポイントを 作らない
  59. 59. 大規模配信 ノードの追加ロジックを開発 ベストエフォートにならないよう 必要な台数を順次投入 中継開始が高速になる プロトコルを新規開発 ユーザを待たせない!
  60. 60. ptpt耐性 リアルタイム特性を維持 ノードの処理量を限定 ErlangのGCは性能を予測可能 ネットワーク帯域 スイッチの場所を考慮 帯域の管理 クライアントの状態監視 軽量プロセス最高!
  61. 61. ホットデプロイ 生放送を中継しながら システムを更新可能 デプロイツールの自動化 fabric利用 システムのrpm化
  62. 62. なんとか 道筋は見えています Erlangによる配信系の更新 にはもう少しかかりますが より良いサービスを目指し、 できるだけ早い導入を進めます
  63. 63. 最後に ドワンゴではErlangエンジニアを 募集しています Erlangにご興味のある方 配信システムに強い方 是非、ご応募ください! http://info.dwango.co.jp/recruit/
  64. 64. おわり ご清聴ありがとうございました。 感謝

×