Netflix 如何在 7 分钟内完成故障转移译文

2018-09-21 16:03

　　在冬季2012年，Netflix公司遭受了长时间断电持续了七个小时，由于在美东地区的AWS弹性负载均衡服务的问题。(Netflix的运行在Amazon Web Services的[AWS] -我们没有自己的任何数据中心，所有与Netflix的互动是从AWS服务，除了视频的实际流。一旦你点击“播放”时，实际的视频文件是从我们自己的CDN服务。)在停电，没有流量进入美东是达到了我们的服务。

　　为了防止这种情况再次发生，我们决定建立地区性故障切换的系统，该系统是有弹性的，以我们的基础服务提供商的故障。故障转移是保护计算机系统从故障时主系统出现故障时，其中备用设备自动接管的方法。

　　区域故障转移降低了风险

　　我们扩展到三个AWS区域：两个在美国(美国东部和美国西部)，一个在欧盟(EU)。我们保留了足够的容量来执行故障转移，以便我们可以吸收单个区域的中断。

　　典型的故障转移如下所示：

　　1.意识到其中一个地区遇到了麻烦。

　　2.扩大两个救世主地区。

　　3.代理从陷入困境的区域到救世主的一些流量。

　　4.将DNS从问题区域更改为救世区域。

　　接下来让我们探索每一步

　　区域故障转移降低了风险

　　典型的故障转移如下所示：

　　1.意识到其中一个地区遇到了麻烦。

　　2.扩大两个救世主地区。

　　3.代理从陷入困境的区域到救世主的一些流量。

　　4.将DNS从问题区域更改为救世区域。

　　接下来让我们探索每一步。

　　1.找出问题

　　我们需要指标，最好是一个指标，它可以告诉我们系统的健康状况。在Netflix，我们使用称为每秒流启动的业务指标(简称SPS)。这是已成功开始播放节目的客户端数量。

　　我们按区域划分了这些数据，并且在任何给定时间我们都可以绘制每个区域的SPS数据，并将其与前一天和前一周的SPS值进行比较。当我们注意到SPS图表下降时，我们知道我们的客户无法启动流媒体节目，因此我们遇到了

　　此问题不一定是云基础设施的问题。这可能是组成 Netflix 生态系统的数百个微服务中的一个糟糕代码的部署，例如海底电缆的切割等。我们可能不知道其原因;我们只知道某处出了问题。

　　如果仅在一个区域中观察到 SPS 中的这种下降，则它是区域性故障转移的理想选择。如果在多个区域观察到下降，很不幸，因为我们只有足够的能力一次疏解一个区域。这正是我们将微服务一次部署到一个区域的原因。如果部署出现问题，我们可以立即撤销并稍后调试此问题。同样，我们希望避免故障转移出现在流量重定向之后(如在 DDoS 攻击中发生的那样)。

　　2.扩大救世主

　　一旦我们确定了病区，我们就应该准备其他区域(“救世主”)来接收来自病区的交通。在我们打开消防水带之前，我们需要适当地缩放救生区域中的堆叠。

　　在这种情况下，缩放的适当含义是什么?Netflix的流量模式全天都不是静态的。我们有高峰观看时间，通常是在下午6点到9点之间。但是在世界不同地区的不同时间都有6次拍摄。美国东部的交通高峰时段比美国西部高3小时，比欧盟地区落后8小时。

　　当我在美国东部进行故障转移时，我们会将来自美国东部的流量发送到欧盟，并将流量从南美洲发送到美国西部。这是为了降低延迟并为我们的客户提供最佳体验。

　　考虑到这一点，我们可以使用线性回归来预测将使用每个微服务的历史扩展行为路由到一天中的特定时间(以及每周的一天)的救急区域的流量。

　　一旦我们确定了每个微服务的适当大小，我们通过设置每个集群的所需大小来触发每个微服务的扩展，然后让 AWS 发挥其魔力。

　　3. 代理流量

　　既然微服务集群已经扩展，我们开始代理从故障区域到救急区域的流量。Netflix 已经构建了一个名为 Zuul 的高性能、跨区域边缘代理，并已经对其开源。

　　这些代理服务旨在验证请求、执行减载、重试已失败请求等。Zuul 代理也可以执行跨区域代理。我们使用此功能将一小撮流量路由到远离故障区域，然后逐渐增加已重新路由的流量，直到达到 100%。

　　这种渐进式代理允许我们的服务使用其扩展策略来执行任意用于处理接入流量所需的响应式扩展。这是为了补偿我们在进行扩展预测所耗费的时间与扩展每个集群所耗费时间之间的流量变化。

　　Zuul 在这一点上完成了繁重的工作，它将所有来自故障区域的流量路由到正常区域。但现在是完全废弃受影响区域的时候了。此处是 DNS 切换发挥作用的地方。

　　4. 切换 DNS