Get best of the week

HighLoad ++，Mikhail Raichenko（ManyChat）：几乎没有魔术，或者分发太比特视频流有多么容易

下一次HighLoad ++会议将于2020年4月6日至7日在圣彼得堡举行。详细信息和门票在这里。HighLoad ++ Moscow2018。大厅“德里+加尔各答”。11月8日，下午2点 摘要和介绍。



我在VKontakte团队工作，正在开发视频广播系统。
在报告中，我将分享后端开发的功能，我们的系统如何发展以及我们所采用的技术解决方案：


  • 我们如何进行视频广播后端，以及它的演变过程；
  • 业务和运营需求对体系结构的影响；
  • “等待”和“重试”将失败；
  • 用户数量如何使最简单的任务复杂化；
  • 如何在没有UDP的情况下减少延迟；
  • 我们每天进行两次压力测试，或Clover帮助我们进行的测试。

Mikhail Raichenko（以下简称MR）： -短途旅行。我将向您介绍直播我们的人，直播（直播），我们接收视频流的平台以及我们分发的平台。最后，我将讨论live的当前体系结构，其局限性和功能，以及当前体系结构如何在“三叶草”之类的作用下幸存下来。



关于直播。报告大纲


  • 首先，我将谈谈直播和直播本身，将向我们展示给其他观众的视频内容发送给我们。
  • . ? , , , , - - , - , . , : , – .
  • . , . . , , .
  • , , . , . , , , , , 2014-2015 . , .
  • . , .
  • , . , . , .
  • , . .
  • , , «», .




所有广播服务看起来都是这样的：



我们有一些流媒体，它向我们发送RTMP流，然后向观众展示-没什么奇怪的，没有什么超自然的。



视频流来自哪里？对我们来说，重要的流量来源是我们的移动应用程序VKlife。他有什么好处？在其中，我们可以完全控制我们如何编码视频。我们可以在客户端进行许多优化，以便以后以最小的延迟将其显示给我们的观众。

缺点：移动应用程序在网络之上运行。它可以是3G ...在任何情况下，几乎都是移动网络，这会带来一些滞后-您需要在应用程序端另外缓冲数据，以便流尽可能平稳地运行。

第二个来源是带有OBS，Wirecast或其他桌面应用程序流的流媒体。这是一个相当大的受众。有时这些是研讨会，有时是游戏流（特别是其中很多来自此类应用程序）。从积极的角度来看：此类应用很少，我们可以为拖缆提供良好的调整建议。但是同时有很多设置，并且发送的并不是我们想要的流。

第三类是来自媒体服务器的RTMP流。这些可以是非常小的媒体服务器，即家庭格式：一个人可以看到街道或其他东西。还是来自合作伙伴的相当严肃的广播：可以有任何东西，此类流并不多，但从根本上说，它们对我们非常重要。

谁在看


同样，这是一个移动应用程序-此处的所有内容都很清楚。最大的问题是网络延迟。从专业人士出发：我们可以自定义播放器-很好，对我们来说很方便，但并非100％都能实现。

vk.com上的网络播放器。在这里，一切也很简单-它是您可以打开观看的常规网络播放器。 vk.com上的观众足够多，广播中有很多观众。一些广播会挂在我们的“视频”部分-可能有数以万计（有时没有任何PR），尤其是如果这是有趣的内容。

因此，对于坐在网络播放器上的观看者来说，频道足够大。因此，流量很大，包括一次广播。

第三个是某些第三方网站上的VKontakte Web播放器。您可以开始流式传输所需的所有内容，然后在网站上挂起VKontakte网络播放器。如果您有有趣的内容，可以成为我们的合作伙伴：可以将其挂起，也可以随我们一起挂起-随心所欲。您可以通过这种方式来组织广播，一切都会正常进行。

与视频通话的比较


在视频通话中，将避免某些图像失真。视频通话更加简单：我们可以大幅降低图像质量，但同时必须保持非常好的延迟。长期以来，该服务将绝对无法使用。

在这种意义上的广播中，反之亦然：我们必须保持高质量的图像，但同时由于许多因素，我们可能会增加延迟。例如，播放器以一种或另一种方式缓冲其流（例如，可能要经过一秒或两次才能缓冲网络的性能下降），因此在大多数情况下，没有第二毫秒的延迟。您可以为此而努力，但是食物不是先决条件。



对于普通视频，情况恰好相反。我们需要非常好的质量。同时，希望将视频尺寸，比特率与质量之比最小化，从而以最小的流量提供最佳解决方案。优点：我们不受时间限制：在下载视频时，我们有足够的时间来优化视频，了解如何以最佳方式压缩视频，做点什么，然后将其拖动到缓存中（如有必要）-一般来说，一切都足够了好。



在现场直播中，情况恰恰相反：我们只有很少的时间进行转码。同时，机会很少，但对广播没有期望。如果我们有支持或质量不是很好，观众会原谅我们。

第一个版本


完全可以预期：



实际上，这有点不同：



“ Streamer-媒体服务器-缓存级别-查看器”。原则上，此版本可让您进行相当大的扩展。我想说它应该已经可以承受成千上万的观众了。它还有其他缺点...

例如，如果您查看此电路（上一张幻灯片），您会发现它不是容错的。我们必须与媒体服务器进行猜测，才能很好地平衡受众。我们不能在每个服务器上挂很多缓存-这简直太贵了。因此，我们看上去很简单明了，可以进行扩展，但是显然缺少某些东西……于是我们开始制定要求。

基础设施要求


重要的是什么？

  • . , , . ( ). (, ).
  • . : -, (, ) ; -, – , , .
  • 交付地区。也是重要的一点！将所有视频内容从彼得斯堡或莫斯科拖到某种新西伯利亚，叶卡捷琳堡，甚至从圣彼得堡到莫斯科都是愚蠢的。这不是很好，因为网络延迟会很长-会有延迟，一切都会延迟，这不是很好。因此，我们的基础架构必须考虑到我们向区域交付内容。
  • 方便的操作和监控。重要属性。由于系统很大，因此查看器很多，因此在出现任何问题（包括监视产品和技术指标）时，应及时向管理员发送警报，这一点很重要。



广播基础架构现在看起来像什么？


结果，我们建立了一个相当简单但有效的基础架构...

  • – , ( , ). RTMP-, . , .
  • , , , , . . , , , – : , -, (. . ); -, .
  • . – , . , , . , ( , ).
  • , (edge-). , . !
  • – edge-, , . : , – .



有趣的是？平衡！在这种方案中，我们选择平衡，尝试将观看相同流的观众发送到每个边缘服务器。缓存的位置在这里非常重要，因为可以有许多边缘服务器。如果从流的角度来看，缓存的临时性和局部性都没有观察到，那么我们将使内部层超载。我们也不希望那样。

因此，我们通过以下方式进行平衡：我们为要向其发送查看器的区域选择特定的边缘服务器，并进行发送，直到我们开始理解已经发生了某些填充并将其发送到另一台服务器为止。电路简单，工作非常可靠。自然地，对于不同的流，您选择了不同的边缘服务器序列（我们发送观众的序列）。因此，平衡非常简单。

我们还为客户端提供了到可用边缘服务器的链接。这样做是为了在边缘服务器发生故障的情况下，我们可以将查看器重定向到另一个。即，当观看者观看广播时，他每隔几秒钟接收一次到所需服务器的链接。如果他知道链接必须不同，那么他将切换（播放器切换）并继续观看来自另一台服务器的广播。

边缘服务器的另一个重要作用是内容保护。所有内容保护基本上都在此进行。为此，我们有自己的nginx模块。它有点类似于安全链接。

缩放和平衡


  • . , : , . edge-, . . . … , – , -- – , – , , , – ! – .
  • . , , , , : . ( ) , – , . , , , edge-.
  • , , , .



?


我们拥有的主要协议之一是RTMP（不仅用于输入，而且用于内容分发）。主要优势是低延迟。可能是半秒，一秒，两秒。实际上，好处就此结束了。...



这种流协议很难监控-尽管存在规范，但从某种意义上讲它是封闭的。 Flash播放器不再起作用（实际上，它“已包含一切”）。需要CDN级别的支持-您需要特殊的nginx模块或您自己的软件才能正常传输流。移动客户端也有一些困难。开箱即用的移动客户端支持非常差-需要特殊改进，而这一切都非常困难。
我们使用的第二个协议是HLS。它看起来很简单：它是一个文本文件，即所谓的索引文件。它包含指向具有不同权限的索引文件的链接，并且文件本身包含指向媒体段的链接。



他好不好 尽管有点老，但它非常简单。它允许您使用CDN，即，您只需要nginx即可分发HLS协议。就监视而言，这是可以理解的。

这是它的优点：

  • 操作简便-nginx作为代理服务器；
  • 监视和获取指标很容易（足以监视您在网站上监视的内容）；
  • 现在，此协议是内容交付的主要协议。

显着负号：

  • 高延迟。



HLS延迟实际上嵌套在协议本身中。由于需要很长的缓冲时间，因此播放器被迫至少在加载一个块时等待，但是以一种很好的方式，他必须等待直到加载两个块（两个媒体段），否则，如果出现延迟，客户端将向播放器加载，这不会对播放器造成很大的影响用户体验。

延迟HLS的第二点是缓存。播放列表缓存在内部层和边缘服务器上。相对而言，即使我们缓存一秒或半秒，也大约要加上2-3秒的延迟。总的来说，结果是12到18秒-这不是很愉快，显然更好。

改善HLS


基于这些想法，我们开始改进HLS。我们以一种非常简单的方式对其进行了改进：让我们将播放列表的最后一个尚未录制的媒体片段提前一点。也就是说，一旦我们开始编写最后一个媒体片段，我们就会立即在播放列表中宣布它。这时发生了什么？..

减少了播放器中的缓冲时间。玩家认为自己已经下载了所有内容，并冷静地开始下载所需的片段。这样，我们就可以“欺骗”玩家一点，但是如果我们很好地监视“钢铁”（玩家身上的负载），这并不会吓到我们-我们可以提前停止细分，一切都会恢复正常。

第二点：我们共赢了大约5-8秒。他们来自哪里？该段时间是每个段2到4秒，加上缓存播放列表的时间（这是另外2-3秒）。而且，我们的延迟正在大大减少。延迟从12-15秒减少到5-7。

这种方法还有什么好处？它实际上是免费的！我们只需要检查播放器是否与此方法兼容。那些不兼容的，我们发送到旧的URL，然后将兼容的播放器发送到新的URL。我们不需要升级支持此功能的旧客户端，这也很重要。我们实际上不需要修改，发布移动客户端中的播放器。我们不需要开发网络播放器。看起来还不错！



缺点-需要控制传入的视频流。对于移动客户端，我们可以很轻松地做到这一点（当流来自移动客户端时），也可以毫无问题地进行转码，因为播放器必须知道一个媒体段所花费的时间。并且由于我们在实际录制之前就宣布了它，因此我们需要知道录制它需要多少时间。

质量指标


因此，我们改进了HLS。现在，我想告诉我们我们如何监控以及我们拍摄的质量指标：



主要质量指标之一是开始时间。理想情况下，这是当您在广播之前滚动浏览移动客户端时，按一下按钮，然后立即开始。如果它在您按下按钮之前启动，则是理想的选择，但是不幸的是，只有在您按下按钮时才启动。
第二点是信号延迟。我们认为几秒钟很好，可以忍受10秒，20-30秒非常不好。它为什么如此重要？例如，对于音乐会和某些公共活动而言，这是绝对不重要的指标，没有反馈。我们只是显示视频流-最好不要拖延，否则会稍有延迟。对于正在召开某种会议或某人说出某些内容并向他提问的人，这开始变得很重要，因为他们在评论中提出了很多问题，我希望听众尽快获得反馈。

另一个重要指标是缓冲和滞后。实际上，该指标不仅从客户端和质量的角度来看很重要，而且从我们可以“拉伸” HLS交付量，我们可以从服务器中榨取数据量的角度来看很重要。因此，我们同时监视播放器和“钢”中的平均缓冲时间。

球员素质的选择是可以理解的：意想不到的变化总是令人讨厌。

因此，这也是重要的指标。

监控方式


我们有许多监视指标，但是在这里，我选择了那些在出现问题时始终有效的指标：



  • -, . - , . , – , ( , – ).
  • / . , , , , , . .
  • edge-. , , edge- .


«», ?


现在，我将告诉您当我们使用基础架构来广播带有问题和答案的视频流时，我们如何处理诸如“ Player”之类的应用程序。

三叶草是一个在线测验。主持人说了些什么，问：问题解决了-您回答。比赛结束10分钟后，有12个问题-某种奖品。有什么好复杂的？这就是增长！

该图在右边：



[在图上] 的峰值是开始“三叶草”时基于API的服务器上的负载。其余时间是通常的广播流。这不能等于观看者的数量。也许这是请求的数量和负载。

很难：在5分钟内，一百万名观众到达了顶峰。他们开始观看广播，注册，执行某种动作，请求视频...这似乎是一个非常简单的游戏，但是这种情况发生在很短的时间内（包括最后一场比赛在内的所有动作）-这带来了相当大的负担。

我们面临哪些问题和挑战？




  • 快速增长。有时是每周+ 50％。例如，如果您在星期三有20万人，那么在星期六或星期日可能已经有300人。这真是很多！问题开始浮现，以前是看不见的。
  • 2 . . , . , , , , , .
    12 . , , , , , - , , …
  • , . , , 200-300 , 400-500.
  • - , , , 3-5 . ? «», , , , .

    ( 3 , ), , 3-5 . ? – , – exponential backoff, .

    exponential on backoff: – , 2 , 4, 8. backend-.

«»?



  • -, . , – .
  • « ». , , , , «». , , -, , -, .
  • , – , «» . «». , , , … – . 10% «» – , 10% «» 100 – .
  • «» , , «» . – - . 100 – , 1 15 – .
  • . «» , , , . , , .
  • . , . , latency, .
  • . – , .
  • «» 1 . , , . . , , . .

?


建筑完全适合我们，我可以放心推荐它。 HLS将与我们保持至少网站的主要协议以及其他所有协议的备用协议。也许我们将切换到MPEG-DASH。

废弃的RTMP。尽管它提供了较低的延迟，但我们还是决定调整HLS。也许考虑其他运输工具，包括DASH作为替代方案。



我们将改善收支平衡。我们还希望对入站平衡进行无缝故障转移，以便在客户端的一台介质服务器上出现问题的情况下，切换将完全不可见。

也许我们将开发从边缘服务器到客户端的交付系统。最有可能的是某种UDP。哪一个-我们正在考虑中，并且处于研究阶段。

实际上，仅此而已。谢谢大家！

问题


观众提问（以下简称-A）：-非常感谢您的举报！只有来自Odnoklassniki的发言人发言，他告诉我他们必须重写拖缆，编码器，编码器……您使用这样的解决方案还是使用市场上现有的解决方案（例如Harmonic等）？



MR： -现在我们有了第三方解决方案。在我们使用的开源解决方案中，我们拥有nginx，即RTMP模块（很长时间）。一方面，他很高兴我们，因为他很简单。我们战斗了很长时间，以便他能稳定地工作。现在，他正在从Nginx-RTMP转向自己的解决方案。我们现在正在考虑使用转码器。接收器（即接收部分）也已从Nginx-RTMP重写为其解决方案。

和：-我想问一个关于在HLS上切片RTMP的问题，但据我了解，您已经回答了……告诉我，您的解决方案是开源的吗？

MR： -我们正在考虑以开源形式发布它。我们宁愿发布它，但问题是在开源中发布的时间。只是将源放在Internet上-这还不够。您需要考虑一些部署示例。你问什么目的？要使用吗？

答： -因为我也遇到过Nginx-RTMP！坦率地说，很长一段时间都不支持它。作家甚至都没有回答特别的问题……

MR： -如果需要，您可以写信。自用？我们可以同意。我们真的计划开放它。

和：-您还说过可以从HLS迁移到DASH。 HLS不适合？

MR： -这是关于我们能做什么或可能不会做什么的问题。在研究替代传输方法（即UDP）方面，这在很大程度上取决于我们所要考虑的内容。如果我们发现“完全”良好的东西，那么我们可能不会碰HLS。如果看起来MPEG-DASH更舒适-也许我们会移动它。这似乎并不困难，但是我们不确定是否有必要。在那里，流之间，质量与其他事物之间的同步显然更好。有加号。

答：关于警报。您谈到了以下事实：如果流停止流式传输，则立即发出警报。而且您没有发现任何与您无关的东西：提供商崩溃了，Megafon崩溃了，人们停止了流媒体播放。..

MR：-假设与我们无关的事情基本上是各种假期等等。是的，他们确实。好吧，他们做到了，是的。管理员看着-今天是假期，其余的特征都没问题-他们平静了下来。

答： -关于缩放。它在什么级别扩展？例如，我要求从电话发送信息流-我会立即收到与正确的ash服务器的特定链接吗？

MR： -链接将立即出现，并且在必要时将切换您（如果特定服务器上有问题）。



答： -谁会切换？

MR： -移动播放器或网络播放器。

答： -他将重新启动流或什么？

MR： -一个新的链接将会出现在他应该直播的地方。他将去那里重新询问信息流。

和：-您在什么级别拥有缓存？以及播放列表和片段，还是仅此而已？..

MR： -和播放列表，片段！无论是在时间上还是在时间返回方面，它的缓存都略有不同，但是我们都缓存了两者。

答： -关于建立灰服务器？您是否遇到过这样的情况，即您一次广播观看了200万观众，却没有时间花些时间来快速购买一些灰服务器？还是您提前筹集了一切保证金？

先生：-也许不是。首先，库存总是小是大-没关系。其次，广播不会突然变得超人气。我们可以很好地预测观众人数。基本上，为了有很多人，我们必须付出努力。因此，我们可以根据所做的努力来调整广播的观看者数量。

答： -您说过，您要测量演奏者的乐器延迟。怎么样？

MR： -非常简单。在媒体片段的块中（以媒体片段的形式），我们有一个时间戳，以媒体片段的名称命名-在播放器中，我们只是将其返回。如果根本不明确，他将返回。

答： -我记得尝试在WebRTC上运行对等。为什么拒绝？

先生：“我无法为您回答这个问题-它是在没有我的情况下发生的。”我不能说为什么尝试，也不能说为什么拒绝。

答： -关于接收器和媒体服务器。据我了解，您曾经拥有Nginx-RTMP，现在无论那里还是那里，都有自己的解决方案。实际上，这是一台代理其他媒体服务器的媒体服务器，并且它们已经在缓存中和边缘。

MR： -所以，不是真的。这是一个自制的解决方案，但是在媒体服务器和接收器方面都不同。 Nginx-RTMP-这是某种收割机，可以同时做到。我们的接收器和媒体服务器的内部在代码和整个方面都非常不同。唯一将它们组合在一起的就是RTMP处理。

答： -关于边缘之间的平衡。这是怎么发生的？

MR： -我们测量流量，并将其发送到所需的服务器。我不太理解这个问题...

答： -我将解释：用户通过播放器请求播放列表-他将相对路径返回到清单和块或绝对路径，例如通过IP或域？..

MR： -这些路径是相对的。

答： -也就是说，一个用户观看视频流时没有平衡吗？

MR： -发生了。够花俏的。当服务器超载时，我们可以使用301st重定向。如果我们发现那里的一切都非常糟糕，对于某些段，我们可以将其发送到另一台服务器。

答： -但是应该连接到播放器的逻辑中吗？

先生：-不，不应缝这部分。 301st重定向！简单地说，玩家应该能够退出301st链接。过载时，我们可以将其从服务器端发送到另一台服务器。

答： -是的，他问服务器，服务器把它交给了他？

MR： -是的。这不是很好，因此，播放器的逻辑用于转发到其中一台服务器发生故障的链接的重推链接-这已经在播放器的逻辑中。

答： -您不是尝试按照亲戚关系而不是按照绝对路径工作：当您要求玩家做一些魔术时，找出哪里有资源，哪里没有，并已经给出了指示特定服务器的播放列表？

先生：-实际上，它看起来像是可行的解决方案。如果您来的话，我们会两全其美！但是当前的解决方案也可以使用，所以我真的不想从一个过渡到另一个，尽管也许这也看起来像一个可行的解决方案。

答： -告诉我，这对多播是否友好？据我了解，HLS绝对没有任何...

MR： -在当前的实现中，系统中实时组播可能没有任何内容。这里不包括多播的概念。也许在管理魔力的最深处某个地方，网络内部有些东西，但是它对所有人都隐藏了，没人知道...




一点广告：）


感谢您与我们在一起。你喜欢我们的文章吗？想看更多有趣的资料吗？通过下订单或向您的朋友推荐给开发人员的基于云的VPS，最低价格为4.99美元，这是我们为您发明的入门级服务器 的独特类似物：关于VPS（KVM）E5-2697 v3（6核）的全部真相10GB DDR4 480GB SSD 1Gbps从$ 19还是如何划分服务器？（RAID1和RAID10提供选件，最多24个内核和最大40GB DDR4）。

阿姆斯特丹的Equinix Tier IV数据中心的戴尔R730xd便宜2倍吗？仅在荷兰有2台Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100电视！戴尔R420-2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB-$ 99起！阅读有关如何构建基础设施大厦的信息。使用Dell R730xd E5-2650 v4服务器花费一欧元9000欧元的c类？

More articles:


All Articles