过去的2018年俄罗斯FIFA世界杯不仅给该国的交通枢纽带来了沉重负担，而且给俄罗斯最大的广播公司的IT基础设施带来了沉重负担，后者以在线广播格式提供了比赛内容。 我们感兴趣的是，随着足球热，正在维修的服务器面临着新的挑战。
前言：高负荷？
有关高负载的讨论通常始于对主题的思考，哪些负载可以正确地视为“高”：每秒动态请求数千次？ 甚至是与可用资源有关的少量请求？ 每天有数百万的访客？ 集群中有数百个工作负载节点？
为了了解“灾难的规模”，我们正在谈论的是用户正在
同时观看广播的事实，该广播的数量已达到
200万 。 如果您“从内部”观看比赛的广播会发生什么，如何应对前所未有的流量？
三只鲸鱼
1.网站架构和翻译系统
最终用户与翻译系统之间交互的一般方案被简化为以下方案：
- 用户来到播放器启动观看视频的站点。 播放器本身是用JavaScript编写的，加载后会导致许多静态请求，以及与翻译相关的各种API。
- 除其他外，平衡器吸引了用于播放的播放列表。
- 播放列表是一组不断更新的短视频片段，这些片段存储在CDN服务器上。
- 在实时观看用户的视频时，会收集各种统计信息，尤其是CDN进行负载平衡时会综合考虑这些统计信息（以及实际可用带宽）。
甚至在我们开始合作之前，由客户工程师的内在力量设计和实施用于直接分发视频的架构。 后来，除了服务本身之外，我们还参与了基础架构的某些组件的设计和调试，以及站点本身，这在整个计划中起着重要作用。
该站点于几年前投入生产，专注于水平可扩展性-包括许多数据中心：
本文介绍的方案经过简化，旨在演示站点可伸缩性的性质，站点的组件分布在不同的数据中心中。
2. CDN
回到实际观看视频，很明显，主要负担落在CDN服务器上。 在上届世界杯的数据中，我们谈论的是恒定流量，以
每秒兆比特为单位 。 并且在许多方面，峰值负载的翻译工作的成功归因于CDN上所有可以传输给它们的内容的缓存，并最大限度地减少了其他操作的资源（网络，CPU，RAM等）成本。
另外，使用CDN的重要一点是与它们的API交互以获得有关总带宽和可用带宽的相关信息。 在广播系统中，此数据用于分发新观众并重新分发当前观众。
因此，如果CDN服务器可以为数百万的Internet观众提供足够的带宽，那么什么时候会发生问题？ 在锦标赛期间，我们观察了两种主要情况：
- 由于某些原因，广播中存在滞后。
例如，在一项锦标赛比赛中如此“发挥”的系统设置，以至于DDoS保护服务原本不希望突然加负载，而是开始将正在发生的事情视为一种攻击，一个接一个地阻止了CDN服务器的可用性...直到被告知情况是在某种意义上说是极端的，但仍然是全职的（做出了必要的结论-在下一次广播中，情况不再重复）。
在这样的时刻，所有被严重问题困扰的用户都开始使用播放器刷新页面。 - 通常，进球（尤其是第一个进球）会在有限的时间内激起观众大量涌入。
如果我们谈论更具体的数字，那么在1-1.5分钟之内涌入了成千上万的用户。
这两种情况都导致对动态网站内容的请求激增，而这些请求需要由可用资源来处理。 如何跟踪和解决此类问题？
3.实时监控和统计
在整个锦标赛期间，我们都有一个特别的职位，这很可能是一个很真实的笑话，其职责包括在工作场所专心看足球。 当然，足球本身并不是那么重要，而是对比赛或其他情况引起的任何事件的迅速反应...
什么是“其他情况”？ 在这样的公共事件中，甚至天气的影响也是明显的。 这是我们遇到的冠军赛的两个例子：
- 在一场比赛中一场雷雨开始时，卫星电视提供商遇到了设备问题（他们无法发送信号）。 这导致短时间内流量显着增加（约10％），因为寻找紧急的替代解决方案，观众开始大量上网并继续浏览。
- 在最后一场比赛中开始下雨时，断开连接和用户重新连接（大约5分钟后）时出现了很小的变化（大约3％）。 在这种情况下，广播本身没有发现问题，也就是说，跳转的原因没有技术依据。 假设是在街上观看足球比赛的观众（就像我本人一样）由于下雨而搬进了房间，在这短暂的时间内，他们与广播失去了联系。
回到监视自身的主题-在整个锦标赛期间，与开发人员进行
例行（每次高峰广播之后）的
惯例作为惯例，这些开发人员分析了所有关键情况（或接近这些情况）及其后果-为了最大程度地减少潜在的问题。下一次 限制了哪些服务器/服务？ 哪些查询特别苛刻？ 可以删除哪些请求（转移到CDN缓存几秒钟）？ 哪些请求可以被缓存更长的时间（每3分钟一次，而不是每分钟一次）？ 由于俄罗斯将参加比赛，因此预计观众人数的增加将如何？
说到俄罗斯。 您可能会猜到，参加俄罗斯国家队的人数平均是其他人的几倍。 而且，我们的团队在锦标赛中的排名越靠前，就越难将我们在此事上的喜悦与立即履行职责相结合-因为观众的不知疲倦使一切变得复杂。 尽管该系统旨在承受巨大的负载，但在正常的工作计划中，它们并不经常发生（每年少于10次）...对于世界杯来说，我们观察到一个月几乎每天都有高负载高峰。 但是，此模式的优点是检测实际瓶颈的可能性很大，而实际瓶颈仅在此类负载时刻才被发现。因此，如果通过监视系统中的标准图形将纯技术问题的一部分删除，那么在解决更复杂和/或面向业务逻辑的问题时，以内部实时名称“实时统计”为题的项目成就将发挥重要作用。
实时统计
Internet广播基础结构的这一重要组成部分是通过我们的努力设计和实现的，旨在为从用户观看视频的播放器中收集的技术数据提供商业智能工具。 它的核心是一个日志系统：
- 收集有关用户的各种可用数据（浏览器，IP等-为简单起见，我们可以说这些是我们过去在网站访问者的统计数据中查看的特征）；
- 通过广播（比特率等）和已发生的事件/问题（CDN切换，查看故障...）的技术数据对它们进行补充；
- 为平衡器提供数据，以实现CDN服务器上的最佳负载平衡（根据每个用户的特征）；
- 发送必要的警报给值班工程师，并创建有用的业务图表。
最后一点是最有趣的，因为：
- 该统计系统的警报是监视的关键组成部分，可让您在广播过程中“与时俱进”。 对他们进行分析（在自动化程度还不够的地方），服务员会做出适当的决定，以实时提高服务质量。 例如：
- 是否有许多用户从同一CDN服务器切换？ 必须暂时禁止它旋转（或与提供者联系以快速响应）。
- 用户观看视频是否开始遇到很多问题？ 是时候紧急分析原因了。
- 图表是实时业务统计信息，可让您回答关键问题，例如：
- 有多少用户观看了最后一分钟的广播？
- 在最后一分钟有多少用户遇到问题，他们的性质是什么？
由于相似的事件具有相同的图形配置文件，因此图形本身使您可以预测接下来几分钟内用户数量的增长，并在必要时采取主动措施 。
由于这些统计信息是实时工作的，并且对于整个服务的质量至关重要，因此即使是简单的本质上，数百万用户观看视频也不能归结为通过CDN向他们分发内容。 ClickHouse DBMS有助于从众多播放器中快速记录新数据（我们正在谈论每秒向记录在每个服务器上的成千上万的请求），而通常的Grafana用于图形。
比赛前，比赛中和比赛后在线视频观看者比例的图示顺便说一句 ：在高峰负载期间，一个有趣的解决方法是禁用HTTPS（支持HTTP）以用于来自统计系统的请求，这导致某些服务器上的CPU负载减少了两倍。总结
如此大型活动的在线广播成功
（甚至YouTube TV 也不总是能应付如此之大！）的关键因素有以下三个：
- 胜任的架构（用于广播系统和站点），即使不使用Kubernetes等现代系统，其架构最初也要针对高负载，可伸缩性和大量突发事件做好准备；
- 具有足够带宽的CDN服务器；
- 专门的监视，它允许：a）实时跟踪问题，b）提供必要的信息，以避免将来再出现这些问题。
尽管实际上还有更多的因素……但也许其中一个因素能够超越所有技术因素-人为因素。 最重要的角色是专家，他们不仅能够做到并在技术上捆绑一切必要的东西，而且还能不懈地取得成果，我尤其要特别指出客户管理层的优点。
关于上述Kubernetes的PS ...我们博客的许多读者可能希望看到的一个故事。 广播系统向其迁移的过程已经开始，但是在世界杯期间，这些进展尚未涉及。PPS
另请参阅我们的博客：