在2016年，我们谈到了MegaFon.TV如何与所有想收看《权力的游戏》新季的人相处。 该服务的发展并没有止步于此，到2017年中期，我们不得不处理数倍的负载。 在这篇文章中，我们将说明如此迅速的增长如何激发我们从根本上改变组织CDN的方法，以及世界杯如何测试了这种新方法。
简要介绍MegaFon.TV
MegaFon.TV是一项OTT服务，用于观看各种视频内容-电影，电视节目，电视频道和录制的节目。 通过MegaFon.TV，几乎可以在任何设备上访问内容：在装有iOS和Android的手机和平板电脑上，在不同发行年份的智能电视LG，三星，飞利浦，松下以及整个OS动物园（Apple TV，Android TV）中， Windows，MacOS，Linux上的桌面浏览器，iOS和Android上的移动浏览器，甚至在机顶盒和儿童Android投影仪等奇特的设备上。 实际上，对设备没有任何限制-只有700 Kbps带宽的Internet可用性很重要。 关于我们如何组织对这么多设备的支持，将来会另作文章。
该服务的大多数用户是MegaFon订户，这可以通过订户的资费套餐中包含的有利可图（甚至通常是免费的）报价来解释。 尽管我们也注意到其他运营商的用户显着增加。 根据此分布，MegaFon.TV流量中80％的MegaFon.TV流量被消耗。
从体系结构上讲，自服务启动以来，内容已通过CDN分发。 我们有单独的
帖子专门介绍此CDN的工作。 在其中，我们讨论了它如何使我们能够处理2016年底（《权力的游戏》新季发行期间）进入该服务的高峰流量。 在这篇文章中，我们将讨论MegaFon.TV的进一步发展以及随着2018年世界杯而出现的新冒险。
服务增长。 和问题
与上一篇文章相比，到2017年底，Megafon.TV的用户数量增长了数倍，电影和电视剧的数量也增加了一个数量级。 启动了新功能，出现了新软件包，可通过“订阅”获得。 自从我们每天看到“权力的游戏”以来，流量高峰，电影和电视节目在总流中的比例稳步增长。
随之而来的问题开始于流量的重新分配。 我们的监控程序配置为以不同格式下载用于不同类型流量的数据块，越来越多地产生了按超时下载视频数据块的错误。 在MegaFon.TV服务中，块的长度为8秒。 如果块在8秒内没有时间加载，则可能会发生错误。
预计错误高峰将在最繁忙的时间发生。 这应该如何影响用户？ 至少，他们可以观察到视频质量的下降。 由于足够多的多比特率配置文件，因此肉眼并不总是可以注意到它。 在最坏的情况下，视频冻结。
开始寻找问题。 几乎立即，很明显在CDN的EDGE服务器上发生了回扣错误。 在这里，我们需要做一点说明，并说明服务器如何处理实时和VOD流量。 该方案有些不同。 来到EDGE服务器获取内容（播放列表或块）的用户，如果缓存中有内容，则从那里获取内容。 否则，EDGE服务器将在Origin上查找内容，并加载主频道。 连同播放列表或块一起，提供了
Cache-Control：max-age标头，它告诉EDGE服务器要缓存多少特定单位的内容。 LIVE和VOD之间的区别在于缓存块所需的时间。 对于实时块，设置了较短的缓存时间，通常从30秒到几分钟-这是由于实时内容的相关时间较短。 此高速缓存存储在RAM中，因为您需要不断分配块并重写高速缓存。 对于VOD块，需要设置更长的时间，从几个小时到几周甚至几个月不等，具体取决于内容库的大小以及用户之间视图的分布。 至于播放列表，它们通常在不超过两秒钟的时间内被缓存，或者根本不被缓存。 值得澄清的是，我们仅在讨论我们的服务器在其中工作的所谓CDN的PULL模式。 在我们的情况下，使用PUSH模式并不完全合理。
但是回到发现问题。 正如我们已经注意到的，所有服务器同时工作于两种类型的内容的返回。 同时，服务器本身具有不同的配置。 结果，某些计算机使用IOPS过载。 由于性能，磁盘数量，磁盘容量小，内容库大，块没有时间进行写入/读取。 另一方面，接收更多流量的功能更强大的计算机的CPU使用率开始出现故障。 CPU资源用于服务SSL流量和通过https传递的数据块，而磁盘上的IOPS几乎达到35％。
所需要的是一种方案，该方案将以最小的成本使以最佳方式使用可用容量成为可能。 此外，六个月后世界杯即将开始，根据初步计算，现场交通高峰应该增加了六倍...
CDN的新方法
分析问题后，我们决定根据由具有不同配置的服务器组成的不同PAD来分离VOD和实时流量。 并且还创建了流量分布及其在不同服务器组之间的平衡的功能。 总共有三个这样的组：
- 具有大量高性能磁盘的服务器，这些磁盘最适合缓存VOD内容。 实际上，最大容量的SSD RI磁盘是最合适的，但是没有一个，购买适当数量的SSD RI磁盘会花费太多预算。 最后，决定使用现有的最好的。 每个服务器在RAID5中包含八个1TB 10k SAS磁盘。 从这些服务器上编译了VOD_PAD。
- 具有大量RAM的服务器，用于缓存所有可能的格式以交付实时数据块，并具有能够处理ssl流量和“厚”网络接口的处理器。 我们使用以下配置：2个8核处理器/ 192GB RAM / 4个10GB接口。 从这些服务器上编译了EDGE_PAD。
- 剩余的服务器组无法处理VOD流量，但适用于少量的实时内容。 它们可以用作储备。 从服务器RESERVE_PAD被编译。
分布如下：
一个特殊的逻辑模块负责选择用户应该从中接收内容的PAD。 这是他的任务：
- 分析URL，对每个流请求应用以上方案，并发布所需的PAD
- 要每5分钟从EDGE_PAD接口中消除负载（ 这是我们的错误 ），并且在达到限制时，将多余的流量切换到RESERVE_PAD。 为了减轻负载，编写了一个小的perl脚本，该脚本返回了以下数据：
- 时间戳记 -更新负载数据的日期和时间（采用RFC 3339格式）；
-total_bandwidth-当前接口负载（总计），Kbps；
-rx_bandwidth-当前接口负载（传入流量），Kbps；
-tx_badwidth-当前接口负载（传出流量），Kbps。
- 在无法预料的情况下，以手动方式将流量直接传输到任何PAD或Origin服务器，或者在必要时在一个PAD上工作。 该配置以yaml格式存储在服务器上，并允许将所有流量发送到所需的PAD，或者根据以下参数之一将流量发送：
-内容类型
-流量加密
-付费流量
-设备类型
-播放列表类型
-地区
原始服务器的人员不足SSD。 不幸的是，当将流量切换到Origin时，VOD块上的HIT_RATE尚不理想（大约30％），但是它们执行了任务，因此我们没有发现CNN中的打包程序有任何问题。
由于用于EDGE_PAD配置的服务器很少，因此决定在流量份额最大的区域（莫斯科和伏尔加河地区）分配服务器。 在GeoDNS的帮助下，流量已从伏尔加河和乌拉尔联邦区的区域发送到了伏尔加河地区。 莫斯科枢纽负责其余的工作。 我们真的不喜欢从莫斯科向西伯利亚和远东地区提供流量的想法，但是这些地区总计占所有流量的约1/20，而MegaFon的渠道竟然足以容纳此类流量。
计划制定后，进行了以下工作：
- 在两周的时间里，开发了切换CDN的功能
- 安装和配置EDGE_PAD服务器以及为其扩展渠道花费了一个月的时间
- 将当前服务器组分为两部分花了两周时间，再花了两周时间将设置应用于网络上的所有服务器和服务器设备
- 最后，我们花费了一周的时间进行测试（不幸的是，由于没有负载，后来才受到影响）
事实证明，这需要并行进行一些工作，最终整个过程花了六个星期。
初步结果和未来计划
调整后，整体系统性能为250 Gb / s。 通过将VOD流量传输到单独的服务器的解决方案，在投入生产后立即显示出其有效性。 自世界杯开始以来，VOD流量一直没有问题。 出于种种原因，有几次我不得不将VOD流量切换到Origin，但从原则上讲，它们也可以应对。 由于我们很少使用高速缓存，因此该方案可能不是很有效，因为我们迫使SSD不断覆盖内容。 但是电路有效。
至于实时路况，随着世界杯的开始，相应的测试我们的决定量出现了。 问题始于当我们在俄罗斯-埃及比赛中达到极限时第二次面对流量转换。 当流量交换正常工作时，它们全部倒在备用PAD上。 在这五分钟内，请求的数量（增长曲线）是如此之大，以至于备份CDN完全阻塞并开始注入错误。 同时，在此期间释放了主PAD，并开始变得有点空闲：
由此得出3个结论：
- 五分钟仍然太多了。 决定将卸载时间减少到30秒。 结果，备用PAD上的流量停止了间歇性增长：
- 每次触发开关时，至少有必要在PAD之间转移用户。 这应该提供额外的切换平滑度。 我们决定为每个用户（或更确切地说是设备）分配一个cookie，根据该cookie，负责分发的模块可以了解是将用户留在当前PAD上还是应该执行切换。 在这里，该技术可以由实施该技术的人自行决定。 因此，我们不会在主PAD上丢弃流量。
- 切换的阈值设置得太低，结果，备用PAD上的流量像雪崩般增长。 在我们的案例中，这是再保险-我们不能完全确定我们是否进行了正确的服务器调整（顺便说一下，这个想法来自Habr）。 该阈值已提高到网络接口的物理性能。
改进过程花了三天的时间，在俄罗斯和克罗地亚的比赛中，我们检查了优化是否有效。 总的来说，结果令我们满意。 在高峰时，系统处理了215 Gbit / s的混合流量。 这不是对系统性能的理论限制-我们仍然有很大的余地。 如果有必要，现在我们可以连接任何外部CDN，并在其中“丢弃”多余的流量。 当您不想每月为使用别人的CDN支付固定费用时，这种模型非常有用。
我们的计划包括CDN的进一步发展。 首先，我想将EDGE_PAD方案扩展到所有联邦地区-这将导致较少使用渠道。 VOD_PAD冗余电路测试也在进行中，其中一些结果现在看起来非常令人印象深刻。
总的来说，过去一年中所做的一切使我认为分发视频内容的服务的CDN是必不可少的。 并不是因为CDN可以节省很多钱，而是因为CDN成为服务本身的一部分，直接影响质量和功能。 在这种情况下，将其交到不正确的人手中至少是不合理的。