Netflix 是互联网电视市场的领导者——该公司创建并正在积极开发这一细分市场。 Netflix 不仅因其丰富的电影和电视剧目录而闻名，这些电影和电视剧几乎可以在地球的每个角落以及任何带显示屏的设备上观看，而且还因其可靠的基础设施和独特的工程文化而闻名。
DevOops 2019 上展示了 Netflix 开发和支持复杂系统方法的一个明显示例 - Netflix 开发总监。 毕业于下诺夫哥罗德国立大学计算数学和数学系。 Sergey Lobachevsky 是 Netflix Open Connect - CDN 团队的首批工程师之一。 他构建了用于监控和分析视频数据的系统，推出了一项流行的评估互联网连接速度的服务 FAST.com，并且在过去几年中一直致力于优化互联网请求，以便 Netflix 应用程序能够尽快为用户服务。
该报告得到了与会者的好评，我们为您准备了文本版本。
谢尔盖在报告中详细谈到
- 关于什么因素影响客户端和服务器之间的 Internet 请求的延迟；
- 如何减少这种延迟；
- 如何设计、维护和监控容错系统；
- 如何在短时间内取得成果，并将业务风险降至最低；
- 如何分析结果并从错误中吸取教训。
这些问题的答案不仅是那些在大公司工作的人需要的。
每个开发和支持互联网产品的人都应该了解并实践所提出的原则和技术。
接下来是从演讲者的角度进行叙述。
网速的重要性
互联网请求的速度与业务直接相关。 以购物行业为例：2009 年的亚马逊 100 毫秒的延迟会导致 1% 的销售额损失。
移动设备越来越多，随之而来的是移动网站和应用程序。 如果您的页面加载时间超过 3 秒，您就会失去大约一半的用户。 和 Google 会考虑搜索结果中页面的加载速度：页面速度越快，在 Google 中的排名就越高。
对于延迟至关重要的金融机构来说，连接速度也很重要。 2015年，Hibernia Networks 纽约和伦敦之间耗资 400 亿美元的电缆，可将城市之间的延迟减少 6 毫秒。 想象一下，减少 66 毫秒的延迟需要花费 1 万美元！
根据 ，超过 5 Mbit/s 的连接速度不再直接影响典型网站的加载速度。 然而，连接延迟和页面加载速度之间存在线性关系：
然而，Netflix并不是一个典型的产品。 延迟和速度对用户的影响是分析和开发的一个活跃领域。 应用程序加载和内容选择取决于延迟，但加载静态元素和流媒体也取决于连接速度。 分析和优化影响用户体验的关键因素是 Netflix 多个团队积极开发的领域。 目标之一是减少 Netflix 设备和云基础设施之间的请求延迟。
在报告中，我们将特别关注使用 Netflix 基础设施示例来减少延迟。 让我们从实际的角度考虑如何处理复杂分布式系统的设计、开发和运营过程，并将时间花在创新和结果上，而不是诊断运营问题和故障。
Netflix 内部
数千种不同的设备支持 Netflix 应用。 它们由四个不同的团队开发，分别为 Android、iOS、电视和网络浏览器制作不同版本的客户端。 我们花费了大量的精力来改善和个性化用户体验。 为此，我们并行运行数百个 A/B 测试。
AWS 云中的数百个微服务支持个性化，提供个性化用户数据、查询调度、遥测、大数据和编码。 流量可视化如下所示：
左边是入口点，然后流量分布在不同后端团队支持的数百个微服务中。
我们基础设施的另一个重要组成部分是 Open Connect CDN，它向最终用户提供静态内容 - 视频、图像、客户端代码等。 CDN 位于自定义服务器（OCA - Open Connect Appliance）上。 里面有运行优化的 FreeBSD 的 SSD 和 HDD 驱动器阵列，以及 NGINX 和一组服务。 我们设计和优化硬件和软件组件，以便这样的CDN服务器可以向用户发送尽可能多的数据。
这些服务器在互联网流量交换点（Internet eXchange - IX）的“墙”如下所示：
Internet Exchange为互联网服务提供商和内容提供商提供了相互“连接”的能力，以便更直接地在互联网上交换数据。 全球大约有70-80个互联网交换点安装了我们的服务器，并且我们独立安装和维护它们：
此外，我们还直接向互联网提供商提供服务器，让他们安装在自己的网络中，从而改善 Netflix 流量的本地化和用户的流媒体质量：
一组 AWS 服务负责将客户端的视频请求分派到 CDN 服务器，并配置服务器本身 - 更新内容、程序代码、设置等。 对于后者，我们还构建了一个骨干网络，将互联网交换点的服务器与 AWS 连接起来。 骨干网络是一个由光纤电缆和路由器组成的全球网络，我们可以根据需要进行设计和配置。
上 ，我们的 CDN 基础设施在高峰时段提供了大约 150/XNUMX 的全球互联网流量，以及 Netflix 运营时间最长的北美地区 XNUMX/XNUMX 的流量。 令人印象深刻的数字，但对我来说最惊人的成就之一是整个CDN系统是由不到XNUMX人的团队开发和维护的。
最初，CDN 基础设施旨在传输视频数据。 然而，随着时间的推移，我们意识到我们还可以使用它来优化来自 AWS 云中客户端的动态请求。
关于互联网加速
如今，Netflix 有 3 个 AWS 区域，对云的请求的延迟将取决于客户距最近区域的距离。 同时，我们有很多CDN服务器用于传送静态内容。 有没有办法利用这个框架来加速动态查询呢？ 然而，不幸的是，不可能缓存这些请求——API 是个性化的，并且每个结果都是唯一的。
让我们在 CDN 服务器上创建一个代理并开始通过它发送流量。 会更快吗？
物料
让我们记住网络协议是如何工作的。 如今，互联网上的大多数流量都使用 HTTP，这取决于底层协议 TCP 和 TLS。 为了让客户端连接到服务器，它会进行一次握手，并且要建立安全连接，客户端需要与服务器交换消息 100 次，并至少再传输一次数据。 如果每次往返延迟 (RTT) 为 400 毫秒，则我们需要 XNUMX 毫秒才能接收第一位数据：
如果我们将证书放在CDN服务器上，那么如果CDN距离较近，客户端和服务器之间的握手时间可以显着减少。 假设 CDN 服务器的延迟为 30 毫秒。 那么接收第一位需要 220 ms：
但优点还不止于此。 一旦建立连接，TCP 就会增加拥塞窗口（它可以通过该连接并行传输的信息量）。 如果数据包丢失，则 TCP 协议的经典实现（如 TCP New Reno）会将打开的“窗口”减少一半。 拥塞窗口的增长及其再次从丢失中恢复的速度取决于到服务器的延迟（RTT）。 如果此连接仅到达 CDN 服务器，则恢复速度会更快。 同时，丢包是一种标准现象，尤其是对于无线网络而言。
由于用户的流量，互联网带宽可能会减少，尤其是在高峰时段，从而导致交通拥堵。 然而，互联网上无法优先处理某些请求。 例如，优先考虑小型且对延迟敏感的请求，而不是加载网络的“繁重”数据流。 然而，在我们的例子中，拥有自己的骨干网络允许我们在 CDN 和云之间的请求路径的一部分上执行此操作，并且我们可以完全配置它。 您可以确保小数据包和对延迟敏感的数据包优先处理，大数据流稍后处理。 CDN离客户端越近，效率就越高。
应用层协议（OSI Level 7）也会对延迟产生影响。 HTTP/2 等新协议可以优化并行请求的性能。 但是，我们确实有 Netflix 客户端使用不支持新协议的旧设备。 并非所有客户端都可以更新或优化配置。 同时，CDN 代理和云之间具有完全的控制权，并且能够使用新的、最佳的协议和设置。 旧协议无效的部分仅在客户端和 CDN 服务器之间运行。 此外，我们可以在CDN和云之间已经建立的连接上发出多路请求，从而提高TCP级别的连接利用率：
我们测量
尽管该理论有望改进，但我们并不急于立即在生产中启动该系统。 相反，我们必须首先证明这个想法在实践中可行。 为此，您需要回答几个问题：
- 速度: 代理会更快吗？
- 可靠性: 会不会经常坏？
- 复杂性: 如何与应用程序集成？
- 成本：部署额外的基础设施需要多少钱？
让我们详细考虑评估第一点的方法。 其余的也以类似的方式处理。
为了分析请求的速度，我们希望获取所有用户的数据，而无需花费大量时间进行开发，也不会中断生产。 为此有几种方法：
- RUM，或被动请求测量。 我们测量用户当前请求的执行时间并确保完全的用户覆盖。 缺点是由于多种因素，例如请求大小、服务器和客户端的处理时间不同，信号不太稳定。 此外，您无法在不影响生产的情况下测试新配置。
- 实验室测试。 模拟客户端的特殊服务器和基础设施。 在他们的帮助下，我们进行了必要的测试。 这样我们就可以完全控制测量结果和清晰的信号。 但设备和用户位置并未完全覆盖（尤其是在全球范围内提供服务并支持数千种设备型号）。
如何结合这两种方法的优点？
我们的团队已经找到了解决方案。 我们编写了一小段代码 - 一个示例 - 我们将其内置到我们的应用程序中。 探针使我们能够从我们的设备进行完全受控的网络测试。 它的工作原理如下：
- 加载应用程序并完成初始活动后不久，我们就运行探针。
- 客户端向服务器发出请求并接收测试的“配方”。 配方是需要向其发出 HTTP(s) 请求的 URL 列表。 此外，配方还配置请求参数：请求之间的延迟、请求的数据量、HTTP(s) 标头等。 同时，我们可以并行测试几个不同的配方——在请求配置时，我们随机确定要发布哪个配方。
- 选择探针启动时间，以免与客户端上网络资源的主动使用发生冲突。 本质上，时间是在客户端不活动时选择的。
- 收到配方后，客户端并行向每个 URL 发出请求。 对每个地址的请求都可以重复——即所谓的。 “脉冲”。 在第一个脉冲上，我们测量建立连接和下载数据所需的时间。 在第二个脉冲上，我们测量通过已建立的连接加载数据所需的时间。 在第三个之前，我们可以设置一个延迟，测量建立重连的速度等。
在测试过程中，我们测量了设备可以获得的所有参数：
- DNS请求时间；
- TCP连接建立时间；
- TLS 连接建立时间；
- 接收第一个数据字节的时间；
- 总加载时间；
- 状态结果代码。
- 所有脉冲完成后，样本将加载所有测量结果以进行分析。
关键点是对客户端逻辑、服务器数据处理以及并行请求测量的最小依赖。 因此，我们能够隔离和测试影响查询性能的各种因素的影响，在单个配方中改变它们，并从真实客户那里获得结果。
事实证明，该基础设施不仅仅适用于查询性能分析。 目前我们有 14 个活跃配方，每秒超过 6000 个样本，接收来自地球各个角落的数据，设备全覆盖。 如果Netflix从第三方购买类似的服务，每年将花费数百万美元，而且覆盖范围也会更差。
实践中的测试理论：原型
通过这样的系统，我们能够评估 CDN 代理对请求延迟的有效性。 现在你需要：
- 创建代理原型；
- 将原型放在 CDN 上；
- 确定如何将客户端定向到特定 CDN 服务器上的代理；
- 将性能与没有代理的 AWS 中的请求进行比较。
任务是尽快评估所提出的解决方案的有效性。 由于良好的网络库的可用性，我们选择 Go 来实现原型。 在每个 CDN 服务器上，我们将原型代理安装为静态二进制文件，以最大程度地减少依赖性并简化集成。 在最初的实现中，我们尽可能使用标准组件，并对 HTTP/2 连接池和请求复用进行少量修改。
为了在 AWS 区域之间进行平衡，我们使用了地理 DNS 数据库，该数据库与用于平衡客户端的数据库相同。 为了为客户端选择 CDN 服务器，我们对 Internet Exchange (IX) 中的服务器使用 TCP Anycast。 在此选项中，我们对所有 CDN 服务器使用一个 IP 地址，客户端将被定向到 IP 跳数最少的 CDN 服务器。 在互联网提供商（ISP）安装的CDN服务器中，我们无法控制路由器来配置TCP Anycast，因此我们使用 ，它将客户引导至互联网提供商以获取视频流。
因此，我们有三种类型的请求路径：通过开放互联网到云、通过 IX 中的 CDN 服务器或通过位于互联网提供商处的 CDN 服务器。 我们的目标是了解哪种方式更好，以及与将请求发送到生产的方式相比，代理有什么好处。 为此，我们使用如下采样系统：
每条路径都成为一个单独的目标，我们看看我们得到的时间。 为了进行分析，我们将代理结果合并为一组（选择 IX 和 ISP 代理之间的最佳时间），并将其与没有代理时向云请求的时间进行比较：
正如您所看到的，结果好坏参半 - 在大多数情况下，代理提供了很好的加速，但也有足够数量的客户端，情况会显着恶化。
结果，我们做了几件重要的事情：
- 我们评估了客户端通过 CDN 代理向云发出请求的预期性能。
- 我们从所有类型的设备的真实客户那里收到数据。
- 我们意识到该理论并未 100% 得到证实，并且使用 CDN 代理的初始报价对我们不起作用。
- 我们没有冒险——我们没有为客户改变生产配置。
- 没有任何东西被破坏。
原型2.0
因此，回到绘图板并再次重复该过程。
我们的想法是，我们将确定每个客户端的最快路径，而不是使用 100% 代理，然后向那里发送请求 - 也就是说，我们将执行所谓的客户端引导。
如何实施？ 我们不能在服务器端使用逻辑，因为...... 目标是连接到该服务器。 需要有某种方法在客户端上执行此操作。 理想情况下，用最少的复杂逻辑来完成此操作，以免解决与大量客户端平台集成的问题。
答案是使用DNS。 在我们的例子中，我们有自己的 DNS 基础设施，我们可以设置一个域区域，我们的服务器将是专制的。 它的工作原理如下：
- 客户端使用主机向 DNS 服务器发出请求，例如 api.netflix.xom。
- 请求到达我们的 DNS 服务器
- DNS 服务器知道该客户端的最快路径并发出相应的 IP 地址。
该解决方案具有额外的复杂性：独裁 DNS 提供商看不到客户端的 IP 地址，只能读取客户端使用的递归解析器的 IP 地址。
因此，我们的独裁解析器必须不是为单个客户端做出决定，而是为基于递归解析器的一组客户端做出决定。
为了解决这个问题，我们使用相同的样本，聚合每个递归解析器的客户端测量结果，并决定将这组数据发送到哪里 - 使用 TCP Anycast 通过 IX 的代理、通过 ISP 代理或直接发送到云。
我们得到以下系统：
生成的 DNS 引导模型允许您根据客户端到云连接速度的历史观察结果来引导客户端。
同样，问题是这种方法的效果如何？ 为了回答这个问题，我们再次使用我们的探针系统。 因此，我们配置演示者配置，其中一个目标遵循 DNS 控制的方向，另一个目标直接进入云（当前生产）。
因此，我们比较结果并评估有效性：
结果，我们学到了几件重要的事情：
- 我们使用 DNS 引导评估了从客户端到云的请求的预期性能。
- 我们从所有类型的设备的真实客户那里收到数据。
- 所提出想法的有效性已被证明。
- 我们没有冒险——我们没有为客户改变生产配置。
- 没有任何东西被破坏。
现在谈谈困难的部分 - 我们将其投入生产
简单的部分现在已经结束了——有了一个工作原型。 现在最困难的部分是为 Netflix 的所有流量推出一个解决方案，部署到 150 亿用户、数千台设备、数百个微服务以及不断变化的产品和基础设施。 Netflix 服务器每秒接收数百万个请求，不小心操作很容易破坏服务。 与此同时，我们希望通过互联网上数千个 CDN 服务器动态路由流量，这些服务器中的某些内容会在最不合时宜的时刻不断发生变化和中断。
而这一切，团队有3名工程师负责系统的开发、部署和全面支持。
因此，我们将继续谈论安宁健康的睡眠。
如何继续开发而不把所有时间都花在支持上？ 我们的方法基于三个原则：
- 我们减少了潜在的故障规模（爆炸半径）。
- 我们正在为意外做好准备——尽管经过了测试和个人经验，我们预计有些东西会被破坏。
- 优雅的降级——如果某些东西不能正常工作，它应该自动修复，即使不是以最有效的方式。
事实证明，在我们的案例中，通过这种解决问题的方法，我们可以找到一个简单有效的解决方案，并显着简化系统支持。 我们意识到我们可以向客户端添加一小段代码并监视由连接问题引起的网络请求错误。 如果出现网络错误，我们会直接回退到云端。 该解决方案不需要客户团队投入大量精力，但大大降低了我们意外故障和意外的风险。
当然，尽管有后退，我们在开发过程中仍然遵循明确的规则：
- 样品测试。
- A/B 测试或金丝雀测试。
- 逐步推出。
通过示例，已经描述了该方法 - 首先使用定制的配方来测试更改。
对于金丝雀测试，我们需要获得可比较的服务器对，在这些服务器上我们可以比较系统在更改之前和之后的工作情况。 为此，我们从许多 CDN 站点中选择接收可比流量的服务器对：
然后我们在 Canary 服务器上安装更改后的版本。 为了评估结果，我们运行一个系统，将大约 100-150 个指标与控制服务器样本进行比较：
如果金丝雀测试成功，我们就会分批逐步发布。 我们不会同时更新每个站点上的服务器 - 由于问题而丢失整个站点对用户服务的影响比在不同位置丢失相同数量的服务器的影响更大。
一般来说，这种方法的有效性和安全性取决于收集的指标的数量和质量。 对于我们的查询加速系统，我们从所有可能的组件收集指标：
- 来自客户 - 会话和请求的数量、回退率；
- proxy——请求次数和时间的统计；
- DNS——请求的数量和结果；
- 云边缘 - 在云中处理请求的数量和时间。
所有这些都被收集到一个管道中，并且根据需要，我们决定将哪些指标发送到实时分析，将哪些指标发送到 Elasticsearch 或大数据以进行更详细的诊断。
我们监控
在我们的例子中，我们正在对客户端和服务器之间请求的关键路径进行更改。 同时，客户端、服务器上以及通过 Internet 传输的不同组件的数量是巨大的。 在数十个团队的工作和生态系统的自然变化过程中，客户端和服务器上的变化不断发生。 我们处于中间——在诊断问题时，我们很有可能参与其中。 因此，我们需要清楚地了解如何定义、收集和分析指标，以快速隔离问题。
理想情况下，实时完全访问所有类型的指标和过滤器。 但指标很多，所以就出现了成本的问题。 在我们的例子中，我们将指标和开发工具分开如下：
为了检测和分类问题，我们使用我们自己的开源实时系统 и - 用于可视化。 它将聚合指标存储在内存中，可靠并与警报系统集成。 为了进行本地化和诊断，我们可以访问 Elasticsearch 和 Kibana 的日志。 对于统计分析和建模，我们使用 Tableau 中的大数据和可视化。
看来这种方法很难实施。 然而，通过分层组织指标和工具，我们可以快速分析问题，确定问题类型，然后深入了解详细的指标。 一般来说，我们大约需要花1-2分钟的时间来确定故障的根源。 此后，我们与特定团队合作进行诊断 - 从几十分钟到几个小时。
即使诊断很快完成，我们也不希望这种情况经常发生。 理想情况下，只有当服务受到重大影响时，我们才会收到严重警报。 对于我们的查询加速系统，我们只有 2 个警报会通知：
- 客户回退百分比 - 评估客户行为；
- 探针错误百分比 - 网络组件的稳定性数据。
这些关键警报监视系统是否为大多数用户工作。 我们会查看有多少客户端在无法获得请求加速时使用了回退。 尽管系统中发生了大量变化，但我们平均每周发出的严重警报少于 1 个。 为什么这对我们来说就足够了？
- 如果我们的代理不起作用，则会有客户端回退。
- 有一个自动转向系统可以响应问题。
有关后者的更多详细信息。 我们的试用系统，以及自动确定客户端到云端的请求最佳路径的系统，可以让我们自动应对一些问题。
让我们回到示例配置和 3 个路径类别。 除了加载时间之外，我们还可以看看交付本身的事实。 如果无法加载数据，那么通过查看不同路径的结果，我们可以确定损坏的位置和内容，以及是否可以通过更改请求路径来自动修复它。
Примеры：
这个过程可以自动化。 将其包含在转向系统中。 并教会它响应性能和可靠性问题。 如果某些东西开始损坏，如果有更好的选择，请做出反应。 与此同时，由于客户的后备，立即反应并不重要。
因此，系统支持的原则可以表述为：
- 减少故障规模；
- 收集指标；
- 如果可以的话，我们会自动修复故障；
- 如果不能，我们会通知您；
- 我们正在开发仪表板和分类工具集以实现快速响应。
得到教训
编写原型并不需要太多时间。 就我们而言，4 个月后就准备好了。 有了它，我们收到了新的指标，并且在开发开始 10 个月后，我们收到了第一个生产流量。 然后繁琐且非常困难的工作开始了：逐步产品化和规模化系统，迁移主要流量并从错误中吸取教训。 然而，这个有效的过程不会是线性的——尽管尽一切努力，一切都无法预测。 快速迭代和响应新数据要有效得多。
根据我们的经验，我们可以推荐以下内容：
- 不要相信你的直觉。
尽管我们的团队成员经验丰富，但我们的直觉总是让我们失望。 例如，我们错误地预测了使用 CDN 代理的预期加速或 TCP 任播的行为。
- 从生产中获取数据。
尽快访问至少少量的生产数据非常重要。 在实验室条件下获得独特案例、配置和设置的数量几乎是不可能的。 快速访问结果将使您能够快速了解潜在问题并将其纳入系统架构中。
- 不要听从其他人的建议和结果 - 收集您自己的数据。
遵循收集和分析数据的原则，但不要盲目接受别人的结果和陈述。 只有您才能确切知道什么对您的用户有效。 您的系统和客户可能与其他公司有很大不同。 幸运的是，现在有了分析工具并且易于使用。 您得到的结果可能与 Netflix、Facebook、Akamai 和其他公司声称的不同。 在我们的案例中，TLS、HTTP2 或 DNS 请求统计的性能与 Facebook、Uber、Akamai 的结果不同 - 因为我们有不同的设备、客户端和数据流。
- 不必要地追随时尚潮流并评估效果。
从简单开始。 在短时间内制作一个简单的工作系统比花费大量时间开发不需要的组件要好。 根据您的测量和结果解决重要的任务和问题。
- 为新的应用程序做好准备。
正如很难预测所有问题一样，也很难提前预测其好处和应用。 向初创公司学习——他们适应客户条件的能力。 就您而言，您可能会发现新问题及其解决方案。 在我们的项目中，我们设定了减少请求延迟的目标。 然而，在分析和讨论过程中，我们意识到我们还可以使用代理服务器：
- 平衡 AWS 区域之间的流量并降低成本；
- 对 CDN 稳定性进行建模；
- 配置 DNS；
- 配置 TLS/TCP。
结论
在报告中，我描述了Netflix如何解决加速客户端和云之间的互联网请求的问题。 我们如何使用客户的采样系统收集数据，并使用收集的历史数据通过互联网上最快的路径路由客户的生产请求。 我们如何利用网络协议的原理、我们的 CDN 基础设施、骨干网络和 DNS 服务器来实现这一任务。
然而，我们的解决方案只是 Netflix 如何实施此类系统的一个示例。 什么对我们有用。 我向大家报告的应用部分是我们遵循的发展原则和支持原则并取得了良好的效果。
我们的问题解决方案可能不适合您。 然而，即使您没有自己的 CDN 基础设施，或者它与我们的基础设施有很大不同，理论和设计原则仍然存在。
业务请求速度的重要性也仍然很重要。 即使对于简单的服务，您也需要做出选择：在云提供商、服务器位置、CDN 和 DNS 提供商之间。 您的选择将影响您的客户的互联网查询的有效性。 衡量和理解这种影响对你来说很重要。
从简单的解决方案开始，关心你如何改变产品。 边走边学习，并根据来自客户、基础设施和业务的数据改进系统。 考虑设计过程中出现意外故障的可能性。 然后您就可以加快开发流程、提高解决方案效率、避免不必要的支持负担并安然入睡。
今年 以在线格式。 您可以向 DevOps 之父之一约翰·威利斯 (John Willis) 本人提问！
来源： habr.com