re:Invent 2023 技术上新｜Amazon Route 53 应用程序恢复控制器新功能：可用区自动转移...

作者：Sébastien Stormacq

可用区自动转移是 Amazon Route 53 应用程序恢复控制器的一项新功能。您可以启用该功能，当亚马逊云科技发现影响可用区的潜在故障时，自动将工作负载的流量安全地从可用区转移，并在故障解决后转移回来。

部署弹性应用程序时，通常会在一个区域的多个可用区部署资源。可用区是指相隔一定距离（通常达数英里）的不同物理数据中心组，以确保其拥有不同的电源、连接、网络设备和洪泛区。

为了帮助您防止应用程序错误，比如部署失败、配置错误或操作员错误，亚马逊云科技去年推出了以手动或编程方式触发可用区转移的功能。这样，当您发现某个可用区的指标下降时，就可以将流量从该可用区转移。为此，对负载均衡器进行配置，将所有新连接只定向到运行正常的可用区中的基础设施。这让您可以在调查故障根本原因的同时，保持应用程序对客户的可用性。修复后，您可以停止可用区转移，确保流量再次分布到所有区域。

仅当关闭跨区域负载均衡（NLB 的默认设置）时，可用区转移才会在应用程序负载均衡器（ALB）或网络负载均衡器（NLB）级别工作。简而言之，负载均衡器提供两个级别的负载均衡。第一级在 DNS 中配置。负载均衡器为每个可用区公开一个或多个 IP 地址，在区域之间实现客户端负载均衡。流量到达可用区后，负载均衡器会将流量发送到注册的运行正常的目标，这通常是 Amazon Elastic Compute Cloud (Amazon EC2) 实例。默认情况下，ALB 将流量发送到所有可用区中的目标。要使可用区转移正常工作，必须配置负载均衡器以禁用跨区域负载均衡。

当可用区转移开始时，DNS 会将所有流量从一个可用区发送出去，如下图所示。

手动可用区转移有助于保护您的工作负载，免受来自您的错误的影响。但是，当可用区中存在潜在故障时，您有时很难识别或检测到故障。使用应用程序指标很难检测可用区中的问题，因为在大多数情况下，您不会跟踪每个可用区的指标。此外，您的服务经常跨可用区边界调用依赖项，从而导致所有可用区中出现错误。在现代微服务架构中，这些检测和恢复步骤通常必须在数十或数百个离散的微服务中执行，导致恢复时间长达数小时。

客户向我们咨询，想要了解我们能否在检测可用区中的潜在故障方面减轻他们的负担。毕竟，通过内部监控工具，我们可能会比您更早发现潜在问题。

通过此次发布，您现在可以配置可用区自动移动，保护您的工作负载免受可用区中潜在故障的影响。我们使用自己的亚马逊云科技内部监控工具和指标来决定何时触发网络流量转移。转移自动开始；不需要调用 API。当我们检测到某个区域存在潜在故障时，例如电源或网络中断，将自动触发基础设施中 NLB 或 ALB 流量的自动转移，并在故障得到解决后将流量转移回来。

显然，从可用区转移流量是一项精细的操作，必须仔细准备。我们建立了一系列保护措施，确保不会意外降低应用程序的可用性。

首先，我们有内部控制，确保我们一次只从一个可用区转移流量。其次，我们每周在您的基础设施上试运行 30 分钟的转移。您可以定义不想试运行的时间段，例如，周一至周五 08:00-18:00。第三，您可以定义两个 Amazon CloudWatch 警报，充当试运行期间的断路器：一个警报用于阻止试运行启动，一个用于在试运行期间监控应用程序的运行状况。当试运行期间触发任一警报时，我们会停止警报，并恢复所有可用区的流量。在试运行结束时，应用程序运行状况警报状态会显示结果：成功或失败。

根据责任分担原则，您也有两个责任。

首先，您必须确保在所有可用区部署足够的容量，以便在流量转移后维持剩余可用区中流量的增长。我们强烈建议在剩余可用区中始终保持足够的容量，不要依赖扩展机制，因为其可能会延迟应用程序恢复或影响可用性。当可用区自动转移触发时，Amazon Auto Scaling 可能需要比平时更长的时间来扩展资源。预扩展资源可确保为要求最苛刻的应用程序提供可预测的恢复时间。

假设为了吸收常规用户流量，您的应用程序需要跨三个可用区的 6 个 EC2 实例（2×3 实例）。在配置可用区自动转移之前，应确保剩余可用区有足够的容量，以便在一个可用区不可用时吸收流量。在本例中，这意味着每个可用区有三个实例（3×3=9个实例和三个可用区，以便在流量转移到两个可用区时保持2×3=6个实例来处理负载）。

在实践中，当试运行需要高可靠性的服务时，通常会在线运行一些冗余容量，以应对突发事件，比如客户驱动的负载峰值、偶尔的主机故障等。以这种方式补充现有冗余，既可以确保出现可用区问题时快速恢复，又可以为其他事件提供更强的可靠性。

其次，必须为您选择的资源显式启用可用区自动转移。亚马逊云科技仅对您选择的资源应用可用区自动转移。应用可用区自动转移会影响分配给应用程序的总容量。正如刚才提到，您的应用程序必须为此做好准备，在剩余的可用区中部署足够的容量。

当然，在所有可用区部署这种额外容量是有成本的。在考虑弹性问题时，我们需要在应用程序可用性和成本之间做出业务权衡。这是我们仅对您选择的资源应用可用区自动转移的另一个原因。

让我们看看如何配置可用区自动转移

为了向大家展示如何配置可用区自动转移，我使用 CDK 脚本部署了现在很有名的 TicTacToe Web 应用程序。我打开亚马逊云科技管理控制台中的 Route 53 应用程序恢复控制器页面。在左侧窗格中，选择可用区自动转移。然后，在欢迎页面上，选择为资源配置可用区自动转移。

我选择了演示应用程序的负载均衡器。记住，目前只有关闭了跨区域负载均衡的负载均衡器，才符合使用可用区自动转移的要求。正如控制台上的警告提醒的那样，我还要确保应用程序有足够的容量，以便在失去一个可用区的情况下继续运行。

我向下滚动页面，配置我不希望亚马逊云科技试运行 30分钟的时间和天数。首先，在我对自动转移感到满意之前，我会阻止周一至周五 08:00-18:00 的试运行。请注意，时间以 UTC 表示，不会随夏令时而变化。您可以使用 UTC 时间转换器应用程序寻求帮助。虽然在一开始时，将工作时间排除在外更加安全，但我们建议您在工作时间也配置此试运行，以确保在应用程序流量低或没有流量时捕获可能不可见的问题。您最需要的，可能就是让可用区自动转移在高峰时段不受影响您的工作，但如果您从未进行过测试，又有多大把握确信它会影响您的工作呢？理想情况下，您希望避免占用任何时间，但我们知道，这未必总能行得通。

在同一页面的下方，我输入了两个断路器警报。第一个用来阻止试运行启动。通过此警报，我们知道现在不是开始试运行的好时机。例如，当应用程序出现问题时，或者将应用程序的新版本部署到生产环境时。第二个 CloudWatch 警报提供了试运行的结果。这使得可用区自动转移可以判断您的应用程序对试运行的响应。如果警报始终显示正常，我们就知道一切顺利。

如果在试运行期间触发这两个警报中的任何一个，可用区自动转移将停止试运行，并恢复到所有可用区的流量。

最后，我承认每周进行30分钟的试运行可能会降低应用程序的可用性。

然后，我选择创建。

就是这样。

几天后，我在控制台的资源可用区转移历史记录选项卡上看到了运行的历史记录。我会监控两个断路器警报器的历史记录，确保一切都得到正确监控和配置。

无法测试自动转移本身。当我们在可用区中检测到潜在问题时，它会自动触发。我询问服务团队，是否可以关闭可用区来测试我在这篇文章中分享的说明；他们礼貌地拒绝了我的请求 :-)。

要测试您的配置，您可以触发手动转移，其行为与自动转移相同。

还有几点要注意

现在，除中国和 GovCloud 外，所有亚马逊云科技区域均可免费使用可用区自动转移。

我们建议使用“crawl、walk、run”方法。首先，从手动可用区转移开始，以获得对应用程序的信心。然后，打开可用区自动转移，在工作时间之外配置试运行。最后，修改时间表，将工作时间内的可用区转移包括在内。您要测试应用程序对在您最不希望发生时发生的事件的响应。

我们还建议您从整体上考虑，当我们将流量从一个可用区移出然后移回时，应用程序的所有部分将如何恢复。我想到的列表如下，虽然并不完整。

首先，正如我前面说过的，计划额外的容量。其次，考虑每个可用区中可能出现的单点故障，例如，在单个 EC2 实例上运行的自管理数据库，或留在单个可用区中的微服务等。对于需要可用区转移的应用程序，我强烈建议使用托管数据库，例如 Amazon DynamoDB 或 Amazon Aurora。它们具有内置的复制和故障转移机制。第三，计划在可用区再次可用时切换回来。扩展资源需要多长时间？是否需要补充缓存？

通过我的同事 Adrian 撰写的这一系列精彩文章，您可以了解有关弹性架构和方法的更多信息：

https://adhorn.medium.com/

最后请记住，目前只有关闭了跨区域负载均衡的负载均衡器才有资格使用可用区自动转移。要使用 CDK 脚本关闭跨区域负载均衡，您需要删除 stickinessCookieDuration ，并在目标组上添加 load_balancing.cross_zone.enabled=false 。下面是 CDK 和 Typescript 的示例：

TypeScript

// 添加自动扩缩组
    // 作为侦听器的负载均衡。
    const targetGroup = listener.addTargets('MyApplicationFleet', {
      port: 8080,
      // 对于可用区转移，必须禁用黏性和跨可用区负载均衡
      // stickinessCookieDuration: Duration.hours(1),
      targets: [asg]
    });    
    // 禁用跨可用区负载均衡
    targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false");

现在，您可以选择要受益于可用区负载均衡的应用程序了。首先查看每个可用区的基础设施容量，然后定义断路器警报。一旦确信您的监控配置正确，就可以启用可用区自动转移。

了解所有 re:Invent 2023 热门发布产品，

请扫描下方二维码：

听说，点完下面4个按钮

就不会碰到bug了！