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.

DeNAの大規模ライブ配信基盤を支える技術

30,584 views

Published on

DeNA TechCon 2018の登壇資料です。

Published in: Technology
  • Be the first to comment

DeNAの大規模ライブ配信基盤を支える技術

  1. 1. DeNAの大規模ライブ配信基盤を支え る技術 IT基盤部 第1グループ 漢 祐介
  2. 2. アジェンダ • DeNAのライブ配信基盤の紹介 • 大規模配信におけるCDN利用について • 配信基盤のマルチリージョン対応について • 低遅延配信への対応について • H.265/HEVC 次世代コーデックの対応について • まとめ 1
  3. 3. DeNAインフラで動くライブ配信サービス 2
  4. 4. • インターネット上でアイドル、タレントとコミュニ ケーションを楽しむことができる、仮想ライブ 空間 • 仮想ライブ空間では、アバターの格好になり 応援したいパフォーマーの部屋を訪問しコ ミュニケーションできる • パソコン・スマートフォンなどから配信すること ができる • VRライブ配信を行うこともできる (SHOWROOM VR) DeNAインフラで動くライブ配信サービス SHOWROOM (ショールーム) 3
  5. 5. • スマートフォンに特化した生配信・実況配信 が出来るコミュニケーションサービス • スマートフォンの画面をミラーリングしながら ライブ配信ができる • 日本国内以外にも韓国などの海外でも配信 が賑わっている • ゲーム実況やゲーム大会の配信などが人気 DeNAインフラで動くライブ配信サービス Mirrativ (ミラティブ) 4
  6. 6. • 手軽に気軽にライブ配信ができるサービス • ヒマなとき、楽しいとき、グチりたいとき、か まって欲しいとき、どんなときでもライブ配信 できる • 配信時に美肌フィルターが使える • 配信も視聴も手軽にできるようになっている DeNAインフラで動くライブ配信サービス Pococha Live (ポコチャ) 5
  7. 7. • ライブハンドメイドアプリ • ライブ配信をしながらモノを作ったりしながら 販売ができるサービス • 完成品だけでなく制作過程やクリエーターの 作品への思いも込めて表現できる • 過去に配信された映像は見返す事もできる • 2018年3月30日サービス提供終了予定 DeNAインフラで動くライブ配信サービス Laffy (ラッフィー) 6
  8. 8. 前書き 一部 TechCon 2017 で 発表した資料と被る部分があります 詳細な構成について記述してあるので、よろしけれ ば後日確認していただければと思います 7
  9. 9. DeNAのライブ配信基盤について どういった インフラ構成になっているのか 8
  10. 10. DeNAのライブ配信基盤について このスライドに登場する主な登場人物 - 配信者 - 視聴者 - Origin(オリジン)サーバ - Edge(エッヂ)サーバ - 配信プロトコル 9
  11. 11. DeNAのライブ配信基盤について 配信者 映像を撮影し配信ソフトやアプリを通じてインターネットに配信する人のこと 配信スタイルはさまざまでスマホのアプリから直接配信をしていたりする 10
  12. 12. DeNAのライブ配信基盤について 視聴者 インターネットで配信されている映像をみる人 視聴方法はパソコンならサイトを通じて、スマホならアプリなどを通じて視聴する 11
  13. 13. DeNAのライブ配信基盤について Origin(オリジン)サーバ 配信者から映像を受け付けるサーバ 配信される映像データはこのサーバで受け取り、 Edgeサーバを通して視聴者に届けられる 12
  14. 14. DeNAのライブ配信基盤について Edge(エッヂ)サーバ 視聴者が映像を視聴する際に繋ぎに来るサーバ Originに配信されている映像データを視聴者に配信するサーバ 13
  15. 15. DeNAのライブ配信基盤について 配信プロトコル 映像を届けるためのプロトコル プロトコルといっても HLSやDASHはHTTP上での ルールのようなもの、プロトコルの種類によっていく つか違いはあるが主に今回登場するのは下記の 3 つ - RTMP - 古くからあるリアルタイムメッセージングプロト コル - HLS - HTTP上でライブストリーミングを実現するため の規格 - DASH - HLS同様HTTP上でストリーミングを実現する ための規格 細かなプロトコルの中身は割愛 14
  16. 16. DeNAのライブ配信基盤について 15
  17. 17. DeNAのライブ配信基盤について DeNAではさまざまなライブ配信サービスがあり、サー ビスによってライブの特色はバラバラ。 16
  18. 18. DeNAのライブ配信基盤について ライブ配信サービスのインフラを構築する上で 何を気にしてインフラ構成をとるのか - 安定した配信ができること - 大規模な配信にも対応できること - 低遅延であること 17
  19. 19. DeNAのライブ配信基盤について - 安定した配信ができること - 大規模な配信にも対応できること - 低遅延であること 18
  20. 20. DeNAのライブ配信基盤について 安定した配信をするため - 適切なキャパシティプランニング - 可用性を上げるための工夫 - 影響の極小化 これらをどう見積もりながら、どんな仕組みで構築して いくかが重要 19
  21. 21. DeNAのライブ配信基盤について Originサーバのキャパシティは何で決まるか 20
  22. 22. DeNAのライブ配信基盤について キャパシティは複数の項目から決定 21 CPUを使い切る前に、トラフィックでサ チってしまったり、大量のEdgeがぶら下 がるとメモリが枯渇してしまったりする。 項目 ・配信数 ・トラフィック ・CPU使用率 ・メモリ使用率 Originサーバは配信をずっと受け続ける ため、キャパシティに余裕をもたせたい → これらの項目の数値を元にキャパシ ティを決定
  23. 23. DeNAのライブ配信基盤について Edgeサーバのキャパシティは何で決まるか 22
  24. 24. DeNAのライブ配信基盤について キャパシティは掛け算で決まる 23 接続数が多いとCPUを食うし、トラフィッ クも出る、高画質(高解像度)な配信の場 合接続数が少なくてもトラフィックがサ チってしまう 項目 ・接続数 ・トラフィック ・CPU使用率 ・メモリ使用率 後述するオートスケールの仕組みは、こ の項目を元に計算式を作ってスケール アウト・スケールインが自動で行われて いる
  25. 25. DeNAのライブ配信基盤について Origin <-> Edge 間は接続が束ねられる(offload) 24
  26. 26. DeNAのライブ配信基盤について Origin <-> Edge 間の接続はオフロー ディングされるため、Originは視聴数に 比例することはないが、Edgeは視聴数 に比例して増やす必要があるので、何 台までぶら下げれるかも重要 25
  27. 27. DeNAのライブ配信基盤について Originサーバの可用性を高めるため Active/Standby 方式のLBで振り分けている 26
  28. 28. DeNAのライブ配信基盤について EdgeサーバはOriginのActive側とStandby側どちらにも接続している 27
  29. 29. DeNAのライブ配信基盤について キャパシティが決まれば、スケールできるように設計をする 分割できる単位を決めshardingしている(Orign + Edgeがセットで1 shard) 28
  30. 30. DeNAのライブ配信基盤について Origin/EdgeのセットでShard単位にして Origin/Edgeの組み合わせはスケール出来 るが、EdgeそのものもShard内でスケール できるように構築しておく 29
  31. 31. DeNAのライブ配信基盤について - 安定した配信ができること - 大規模な配信にも対応できること - 低遅延であること 30
  32. 32. DeNAのライブ配信基盤について 大規模な配信にも対応できるようにするため - 柔軟なトラフィックコントロールシステム - edge だけではなく origin もコントロール - オートスケーリングシステム - 構築の自動化(= 高速なスケールアウト) - サービスイン・アウトの自動化 - 複数のクラウドでも動く - 緻密なモニタリング - 何かあった時に気付けるように 31
  33. 33. トラフィックコントロール(Edge) 32
  34. 34. トラフィックコントロール(Origin) 33
  35. 35. トラフィックコントロール Edgeだけトラフィックをコントロールできても、 いざOriginに配信をしようと思った時に問題が起こらないよう、 Originのトラフィックをコントロールできるように実装してある。 この仕組があることで安全にサービスイン・アウトも出来るた め、メンテナンス性も向上している 34
  36. 36. トラフィックコントロール トラフィックをコントロールするためのシステムはアプリケーショ ンの実装と密に関わっているため、開発陣とのコミュニケーショ ンが大切。 また逆に開発陣も仕組みを理解してくれるため、柔軟にトラ フィックのコントロールするための仕組みを実現。 突発的なトラフィックが起きた場合もこのシステムを組み合わせ ることでコントロール可能になっている。 35
  37. 37. オートスケーリング 36 キャパシティを決める際に、負荷試 験を実施。 そこから得られた数値を元にオート スケールを実装している。 また、自動化してある為、高速に サービスインまで持っていくことがで きる
  38. 38. オートスケーリング(マルチクラウド) 37 何らかの理由でクラウドサービ スが利用できなくなったとしても (リミットに達した等) 複数のクラウドサービスでそれ ぞれオートスケーリングできる ように設計している 複数のクラウドサービスが混在 してもダウンタイム無く、サービ スを継続させれるように実装さ れている
  39. 39. DeNAのライブ配信基盤について - 安定した配信ができること - 大規模な配信にも対応できること - 低遅延であること 38
  40. 40. DeNAのライブ配信基盤について 遅延をなるべく最小限にするために、Origin<->Edgeの間はシンプルな構成を取って いる 39
  41. 41. DeNAのライブ配信基盤について 遅延の少ないプロトコルを選択できるように、またモバイル回線になった場合もシー ムレスに切り替えができるように複数のプロトコルで通信ができる HLSなどのHTTPを利用するものはチャンク最適化をしている 40
  42. 42. 大規模配信におけるCDNの利用について いかに遅延を減らし 高品質な映像を届けているのかについて 41
  43. 43. 大規模配信におけるCDNの利用について 従来からCDNの利用はなるべく避けてきていた - 遅延が少ないプロトコルが利用できない - CDNを経由させることによる遅延がでていた しかしながら利用することによるメリットはある - CDNならではの高品質ネットワーク - 配信のオフロード 2017年から一部サービスからCDNでの配信を開始 (もの自体は2016年後半からは存在していた) 42
  44. 44. 大規模配信におけるCDNの利用について もともとCDNの利用はVR配信のオフローディング用途として構 想していた - 2K解像度に匹敵する解像度が必要であること - それに伴う高ビットレート映像 これらサイズを既存のEdgeからトラフィックを流した場合に、 キャパシティが足りなくなる事が想定されたため、オフローディ ングできるよう構想 43
  45. 45. 大規模配信におけるCDNの利用について 44 VR専用の配信系統なども準備していた またDASH(MPEG-DASH)も利用できるようになった
  46. 46. 大規模配信におけるCDNの利用について ただ、CDNを設置する事による映像の遅延問題は解消していなかった。 というのも、当初CDNはEdgeの後段に置く予定だった 45
  47. 47. 大規模配信におけるCDNの利用について Edgeの後段に置く理由は、 Edge自体にOriginの冗長化構成を考慮した設計が入っているため、その後段にいる ことでその恩恵を受けれるようになっていたり、 オートスケールがShard単位で行われるため、Edge群を向けておけばオフローディ ング先を分散できるため が、遅延が大きく、利用には向いていなかった 46
  48. 48. 大規模配信におけるCDNの利用について 遅延はどこで発生しているのかを調査したところ 各ポイントでのバッファリングとチャンクデータを CDNから参照する際に最適化されておらず 再取得が増えていたことが原因としてありそうだった 47
  49. 49. 大規模配信におけるCDNの利用について そこで、Originから直接映像を取り出して CDNから読み出せるように再構成 さらに、CDNから取得したチャンクデータを再取得が少ない形式に変換することとで、キャッシュヒット率を高 めると共に遅延を少なくさせている 48
  50. 50. 大規模配信におけるCDNの利用について これらを経て、30秒近く遅延していた映像が数秒の遅延に抑えつつCDNの利用が出 来るようになっている また、当初の想定とは別にオフローディング用途としての利用があり、現在では配信 を見る前のプレビュー画面などで利用されている 49
  51. 51. 配信基盤のマルチリージョン対応について ライブ配信基盤の海外展開について 50
  52. 52. 配信基盤のマルチリージョン対応について 国外のユーザは日本のEdgeに繋ぎに来るよりも、現地のネット ワークで繋いだほうが遅延が少ない また、CDNの遅延もある程度の抑える事ができたが、従来の低 遅延も利用したい 既存のインフラ構成はそのままに、海外のリージョンに対応して いる 2017年から一部サービスから利用を開始している 51
  53. 53. 配信基盤のマルチリージョン対応について 海外のどこにインフラを構築するべきか - 国外の利用者が多いところ - 日本よりも利用者にとって近いところ - そもそもインフラ構築ができるところ => シンガポールに既存のインフラ構成のまま構築 52
  54. 54. 配信基盤のマルチリージョン対応について 53
  55. 55. 配信基盤のマルチリージョン対応について インフラは構築できた 視聴者が使うEdge先はどうやって変更するか => IP Geolocationベースに向き先を決定している また、既存の設計そのままに横展開した設計し、フェイルバック が出来るように設計(現在は日本がフェイルバック先) 54
  56. 56. 配信基盤のマルチリージョン対応について 55
  57. 57. 配信基盤のマルチリージョン対応について オートスケールの設計自体がマルチクラウドも視野に設計して いるので、大きく手を加えること無く 複数リージョンでもオートスケーリングされるように構築してい る。 また、今後の多拠点展開も視野に構築自体も自動化 ・社内ツール連携の廃止 ・最新のOSやVMへの対応強化 56
  58. 58. 配信基盤のマルチリージョン対応について 57
  59. 59. 配信基盤のマルチリージョン対応について 58
  60. 60. 配信基盤のマルチリージョン対応について 59
  61. 61. 配信基盤のマルチリージョン対応について 60 従来どおり マルチクラウドも 利用できるように なっている
  62. 62. 低遅延配信への対応について Low-latency HLS (LHLSと呼んでいる) 61
  63. 63. 低遅延配信への対応について LHLSってなに? - 自分が勝手にそう呼称しているだけ - 最小限の遅延でHLSを配信したかった - ブラウザでRTMPが利用できなくなりつつある - HLS(HTTP経由)である利点があるから - CDNでの利用ができるから 62
  64. 64. 低遅延配信への対応について なんでHLSが遅延するのか => 僕らの使っているOriginに原因がありそうだ 63
  65. 65. 低遅延配信への対応について Originが配信を受けるまで(イメージ) 64
  66. 66. 低遅延配信への対応について OriginからEdgeに届くまでやっていること 65
  67. 67. 低遅延配信への対応について Originは色々やっている(イメージ) 66
  68. 68. 低遅延配信への対応について Originは色々やっている(イメージ) 67
  69. 69. 低遅延配信への対応について Edgeから視聴者に届くまでも色々多い 68
  70. 70. 低遅延配信への対応について 映像を低遅延化させるためには、OriginやEdgeで行っている バッファを如何に短くするかが鍵となってくる (CDN対応のところでやっている) また、チャンクの秒数を短くすることでEdgeに届くパケットを早く 送出することができる 69
  71. 71. チャンク最小化 2秒の映像データを3個保持している場合、これは6秒の映像ということ 7-8秒目の映像が配信されるまで2秒の遅延が発生 70
  72. 72. チャンク最小化 そこで2秒だった映像を1秒区切りに再変換させることで遅延時間を減らせるのでは ないか?また保持するチャンクを減らすなどで配信されるのを減らせないか 71
  73. 73. 低遅延配信への対応について Originからリアルタムに映像を 取り出すようにし、この中で mpegtsに詰め直しをリアルタ イムに行う(1秒単位に切り詰 め) 詰め直したmpegtsをHLSとし て配信できるようにした HTTP(LHLS Origin)を用意 72
  74. 74. チャンク最小化 73
  75. 75. チャンク最小化 - 結果 雑な実装ながら原理的にはこういったことの積み重ねで低遅延 は作れそう - ただしプロダクションには使えないほどバグが多い (TechConに間に合わなかった) - RTMPは遅延が少なくすごいというのを再確認できた 今後も調査していく 74
  76. 76. H.265/HEVC 次世代コーデックの対応について 次世代コーデックへの対応について 現在の行っている取り組み 75
  77. 77. H.265/HEVC 次世代コーデックの対応について 配信規模が増えるに従い、配信トラフィックが増加の 一途 - 低画質向けのトランスコードはしているがターゲット はパケ死対策でメインの利用ではない - そもそも高画質の配信をしているからトランスコード はできない 76
  78. 78. H.265/HEVC 次世代コーデックの対応について H.265/HEVCとは - H.264/AVCの後継コーデック - H.264と比べブロックノイズが少なく、同じビットレートなら H.265の方が綺麗 - H.264よりも圧縮率が高く40%ほどサイズが小さい - 比較的最新のスマホで利用できるようになってきた - 8Kに対応(H.264は4Kまで) ※以降紛らわしいのでH.265は HEVC と表記しています いくつかコーデックと画質の比較してみました 77
  79. 79. 画質比較 - 元画像 78 比較対象 ProRes422 1920x1080p30 130Mbps
  80. 80. 画質比較 - 400Kbps 79 H.264 baseline 4.0 1920x1080p30 400Kbps 一番画質が悪い。 木の質感ものっぺり と潰れていてブロッ クノイズも出ている。
  81. 81. 画質比較 - 400Kbps 80 H.264 main 4.0 1920x1080p30 400Kbps ぼやけた感じが大分 減っているが、木の 木目などは潰れてい る状態。
  82. 82. 画質比較 - 400Kbps 81 HEVC 1920x1080p30 400Kbps 比較対象のProRes とまではいかないが パット見るだけでは 分からないレベル
  83. 83. 同じ箇所を横に並べてみました 元画像 82 H.264 main 400KbpsH.264 baseline 400Kbps HEVC 400Kbps
  84. 84. 同じ箇所を横に並べてみました 元画像 83 H.264 main 400KbpsH.264 baseline 400Kbps HEVC 400Kbps ブロックノイズが 見える 木の質感が失わ れている
  85. 85. H.264を倍のビットレートにしても同画質にはならず 84 H.264 main 4.0 800Kbps HEVC 400Kbps 400Kbpsから 800Kbpsに上 げたものの まだ質感が足 りない...。
  86. 86. H.265/HEVC 次世代コーデックの対応について H.264 800Kbps と HEVC 400Kbps の画質がほぼ同等と思えるくらい H.265/HEVC は綺麗 また、データサイズが 89,710 バイト(90 KB) あったものが 41,618 バイト(45 KB) まで減るため、 トラフィックの削減にも効果がありそう 85
  87. 87. H.265/HEVC 次世代コーデックの対応について H.265/HEVCはとても有用そう、ただし圧縮時のCPU負荷が高騰する。 ものによるが概ね120%-180%ほどCPU使用率が上がることが分かっている 現在はOrigin内でトランスコードしているが、安定した品質で届けられる仕組みを検 討 86
  88. 88. H.265/HEVC 次世代コーデックの対応について 課題事項が沢山あるので一つ一つ検証を進めている。 fMP4 対応も視野にしつつ構成を検討中。 87
  89. 89. まとめ 2017年を振り返る 88
  90. 90. まとめ - 大規模配信の対策いろいろ - 遅延少なくCDNの利用が出来るようになった - マルチリージョン対応しているようになった - 新しい低遅延化への取組み中 - H.265/HEVC も検証中 89
  91. 91. ご清聴ありがとうございました

×