亚马逊AWS官方博客
在单一可用区内快速从应用程序故障中恢复
Original URL: https://aws.amazon.com/cn/blogs/networking-and-content-delivery/rapidly-recover-from-application-failures-in-a-single-az/
通过此次更新，适用于 Amazon Route 53 应用程序恢复控制器的可用区转移功能现在也可在以下 AWS 区域使用。
要了解更多信息，请参阅更新后的“最新资讯”文章或可用区转移文档。
今天，我们将推出可用区转移功能，这是 Amazon Route 53 应用程序恢复控制器（Route 53 ARC）的一项新功能，内置于弹性负载均衡（ELB）中。通过执行可用区转移，您能够在单一可用区（AZ）内快速从应用程序故障中恢复。
在这篇文章中，我们将解释可用区转移的工作原理，以及它们如何适应使用负载均衡器运行状况检查等功能的高弹性多可用区应用程序的整体可靠性策略。此外，您还可以观看这堂关于使用 AWS 服务设计和监控多可用区应用程序的补充讲座，其中还讨论了可用区转移功能，该讲座在 AWS re:Invent 2022：运行高可用性多可用区应用程序上发布。
您可以立即在以下 AWS 区域开始使用预览版可用区转移：美国东部（俄亥俄州）、美国东部（弗吉尼亚州北部）、美国西部（俄勒冈州）、亚太地区（雅加达）、亚太地区（悉尼）、亚太地区（东京）、欧洲地区（法兰克福）、欧洲地区（爱尔兰）和欧洲地区（斯德哥尔摩）。您可以在关闭跨可用区负载均衡的应用程序负载均衡器（ALB）和网络负载均衡器（NLB）中使用可用区转移。使用可用区转移无需支付额外费用。
使用 AZ 构建容错服务
AWS 服务以及在 AWS 上运行高弹性应用程序的客户采用一个关键策略来设计可靠的系统，即使用多个独立的副本，并且一次针对任何一个副本的故障进行规划。在此策略中，您将整个系统构建为多个应用程序副本（通常为三个），并且一次针对一个副本的故障进行规划。这样，如果一个副本暂时处于离线状态，则必须在每个副本中配置足够的容量来处理负载。
接下来，您需要确保所有常见的故障模式（即部署不正确、响应延迟过高、错误率升高）都包含在一个副本或一个故障容器中。这样，如果一个副本出现故障，您可以暂时将其从系统中移除，以恢复客户的正常服务。恢复正常服务后，您可以调查和修复出现故障的副本。故障可能来自多种来源，包括软件部署、操作员错误、硬件故障、电源故障、网络设备故障、证书到期，甚至是数据中心故障。通过努力确保故障很少发生，控制在一个副本中并可快速恢复，您可以运行更可靠的系统。
该策略以恢复为导向，这意味着它优先考虑恢复，而不是调查和修复。首先，通过移除出现故障的副本，将应用程序恢复到正常运行状态。然后，您可以调查根本原因并修复出现故障的副本，然后将副本恢复服务。确保您可以在确定根本原因之前先进行恢复，这样可以缩短平均恢复时间（MTTR），并缩短对客户产生的影响的持续时间。
该策略的一个关键部分是最大限度地减少任意两个副本同时发生故障或以协调方式发生故障的可能性。为此，必须确保副本尽可能独立地运行。这通常涉及一系列措施，例如一次只将软件部署到一个副本，一次只对一个副本进行更改，以及跨副本分散限制（或“抖动”）。这些是操作项，例如文件系统大小、堆内存限制、证书到期时间、计划作业运行时间等。这样，多个副本就不会同时出现问题。例如，您可以对副本设置不同的限制，以帮助控制一个副本首次出现的与限制相关的问题，您可以暂时移除该副本。
当您使副本与独立的物理故障容器保持一致时，系统将从这种副本策略中受益更多。在 AWS 上构建时，可以将可用区用作物理故障容器。可用区允许您将副本放置在相隔一定距离（通常为数英里）的不同物理数据中心，以确保它们具有不同的电源、连接、网络设备和洪泛平原。同样，这旨在最大限度地减少任意两个副本同时发生的事件数量，并有助于防止相关故障。
从硬故障中恢复
将应用程序构建为多个独立副本、与可用区保持一致并配置足够的容量来处理一个副本丢失的故障后，下一步是设置机制以快速检测和移除可用区或可用区副本中运行状况不佳的副本。如果您使用 ALB 或 NLB，则针对可用区故障的第一道防线是运行状况检查。通过运行状况检查，负载均衡器会定期探测每个目标，以检查响应是否正常，即 HTTP 状态 200。如果响应指示运行状况不佳或者响应超时，则表示检测到故障，系统会在一分钟内将请求从发生故障的目标路由出去。此外，Amazon Route 53 会对每个负载均衡器节点进行运行状况检查，如果某个可用区的目标运行状况均不佳，则会将该可用区从负载均衡器的 DNS 中移除。
目标运行状况检查可以快速有效地检测明显可检测的故障或硬故障，如目标实例故障。其他硬故障示例包括不再侦听应用程序连接，或者运行状况检查响应返回 HTTP 状态 500 的应用程序。要确保最有效的运行状况检查，设计深度健康检查处理程序通常很有帮助，这样可以更彻底地测试应用程序。但是，需要仔细考虑是否实施深度运行状况检查，以避免出现误报，例如可能由于过载导致的情况。有关更多信息，请参阅 Amazon Builder’s Library 中关于实施运行状况检查的精彩文章。
可用于检测硬故障的另一项功能是正常运行目标最小值。ALB 和 NLB 最近新增了此功能，允许您在目标组或 AZ 中指定最低数量的正常运行目标。现在，如果一个可用区副本出现故障并低于您配置的最低容量阈值，则该副本将无法通过运行状况检查，流量将路由到其他副本。这样可以避免受损的副本不堪重负。
从灰色故障中恢复
即使实施了深度健康检查，也可能出现更模棱两可或间歇性的灰色故障模式，这些模式难以检测。例如，进行可用区部署后，副本对探测的响应可能指示其运行状况良好，但却存在会影响客户的功能性错误。或者，也许新代码的执行效率较低或者会间歇性崩溃，但其在检查时仍能快速响应，所以看似正常运行。细微的基础设施问题，例如数据包丢失或间歇性依赖关系故障，也可能导致响应速度变慢，但仍能通过运行状况检查。
对于这些灰色故障情况，采用更高级别的机制（无论是人工的还是自动的）来检查可用区副本的客户体验会很有帮助。这样，当可用区副本出现灰色故障时，人工或自动系统可以从该 AZ 转移。AWS 多年来一直采用这种双管齐下的策略，现在我们使客户在 AWS 上运行应用程序时能更轻松地采用类似的策略。ELB 现在为关闭跨可用区负载均衡的 ALB 和 NLB 提供了启动可用区转移的选项。这种内置的恢复控制功能允许您在应用程序运行状况不佳时暂时从可用区转移。
首先，请确保关闭跨可用区负载均衡。如下图所示，这会将负载均衡器节点设置为仅将请求路由到本地 AZ 中的目标。这样做可以使每个可用区故障容器与负载均衡器及其目标保持一致，并且可以更轻松地检测单个可用区副本中的故障。您可以关闭 ALB 和 NLB 的跨可用区负载均衡。
图 1. 如何在开启和关闭跨可用区负载均衡的情况下路由请求
现在，您可以在 ELB 中启动可用区转移。由于可用区转移控制是内置的，因此无需进行任何设置，但应确保您的 Amazon Identity and Access Management（IAM）用户或角色有权调用可用区转移 API。可用区转移允许您使用简单的 StartZonalShift API 调用暂时将客户流量从运行状况不佳的可用区副本中移出。如果其他副本运行状况良好，并且有能力为客户提供服务，则可以在几分钟内恢复客户体验。然后，当您的客户愉快地继续使用您的应用程序时，您就可以着手调试和修复运行状况不佳的可用区副本。当您准备好将应用程序工作负载恢复到已修复的可用区时，可以取消可用区转移，或者干脆等它到期。
可用区转移的工作原理
当您请求通过调用可用区转移 API 将流量移出可用区时，它是如何运作的？ 考虑在已关闭跨可用区负载均衡的 NLB 后面跨三个可用区运行的 Web 服务，如下图所示。您可以对 NLB 的每个可用区端点进行综合监控，因此您可以查看每个 AZ 请求的成功率和延迟。您的 Amazon CloudWatch 控制面板显示，有 1% 的客户请求（P99）出现了一秒钟的延迟。根据每个可用区的指标，您可以在 AZ3 中看到类似的延迟增加，而 AZ1 和 AZ2 的延迟则保持标称值（约 60 毫秒）不变。您还不知道是什么原因导致了延迟增加，但有明显的迹象表明，问题出现在 AZ3 的副本中。尽管请求仍然成功，运行状况检查也将通过，但是像这样的延迟增加可能会给客户带来问题。
图 2. 采用 CloudWatch Synthetics 的 3-AZ 负载均衡器架构检测到一个可用区延迟增加
图 3. 一个可操作的 CloudWatch 控制面板，包含客户和每个可用区的视图。延迟指标显示客户体验和单一可用区的延迟有所增加
如果您的 Web 服务有足够的备用计算容量来处理移除一个 AZ 的情况，则可以将流量从 AZ3 转移出来，先进行故障恢复，然后再调查问题。这是如何运作的？ 当您启动可用区转移时，会请求将客户流量从 AZ3 路由出去。可用区转移会迫使 AZ3 负载均衡器运行状况检查失败，并使其 IP 地址从 DNS 中撤出。这会导致新连接仅被路由到其他可用区。根据客户端行为和连接重用情况，现有连接可能需要一些时间才能耗尽，尽管通常只需要几分钟。
您可以使用 StartZonalShift API 调用将流量从可用区转移出去，该调用会返回一个可用区转移 ID。可用区转移会将流量暂时从可用区移出，因此需要设置一个到期时间。这不是对负载均衡器的永久配置更改。以下带有 StartZonalShift API 的 CLI 命令示例将启动将在 12 小时后到期可用区转移：
图 4. 相同的 3-AZ 负载均衡器架构，采用可用区转移以将流量从受损的可用区移出
现在，可用区转移已经生效，CloudWatch 控制面板显示客户端点的 ResponseTime 指标已恢复正常。监控显示延迟问题在 AZ3 中仍然存在，但该 AZ 不再接收客户流量。您还可以看到，ProcessedBytes 在 AZ1 和 AZ2 中有所上升，在 AZ3 中有所下降。
图 5. 可操作的 CloudWatch 控制面板显示，可用区转移已经通过将请求从受损的可用区移出恢复了客户体验
由于您的客户已经重新体验到了正常服务，现在可以 AZ3 中调查问题了。也许最近对 AZ 进行了部署？ 也许另一个团队成员正在执行的工作影响到了该可用区的副本？ 或者，AZ3 中可能有某个持续存在且在 Amazon Health Dashboard 上可见的问题？ 无论导致受损的原因是什么，您现在都有时间进行调查并努力解决这个问题。可以根据需要执行可用区转移。
如果您需要延长可用区转移的时间以留出更多时间进行故障排除，则可以通过简单的 UpdateZonalShift API 调用来实现。以下示例 CLI 命令将可用区转移设置为四小时后到期：
当 AZ3 中的可用区副本恢复后，您可以取消可用区转移，也可以等待其自动到期。要取消它，请将 CancelZonalShift API 调用与 可用区转移 ID 结合使用。例如，使用以下 CLI 命令：
如果您使用 Amazon Virtual Private Cloud（Amazon VPC）端点服务，值得注意的是，当您对与 Amazon VPC 端点服务关联的区域 NLB 启动可用区转移时，可用区转移也会自动应用于所有相应的 Amazon VPC 端点。这样可以确保通过 AWS PrivateLink 到达您的 NLB 的流量也遵循可用区转移。
为应对单一可用区应用程序故障做准备
我们已经讨论了如何启动可用区转移以进行恢复，现在让我们来看看如何为该策略做好准备并有效应用该策略。
检测故障
当您的应用程序有一个运行状况不佳的可用区副本时，您应该能够检测到。要可靠地做到这一点，您需要每个可用区的应用程序运行状况信号。可以通过几种相互补充的方法做到这一点。
被动监控：大多数应用程序都会创建指标来跟踪致命错误、异常、响应时间或 HTTP 状态码，例如 HTTP 状态 200 和 HTTP 状态 500。如果您在指标维度中包含主机的可用区，则可以创建显示单个可用区副本中的问题的聚合指标。此外，ALB 和 NLB 都提供每个可用区的指标，例如 UnhealthyHostCount 和 ProcessedBytes。ALB 还提供每个可用区的 HTTP 状态 500 错误计数。所有这些指标都有助于为您的决策提供依据。
主动和综合监控：除了被动监控之外，针对您的应用程序创建综合请求也很有用，这样可以更全面地了解客户体验。Amazon CloudWatch Synthetics 提供托管金丝雀服务，该服务可以定期针对端点运行您选择的代码并创建指标。除了标准的区域 DNS 名称外，ALB 和 NLB 还都提供可用区 DNS 名称。这使您可以创建金丝雀来分别监控每个可用区应用程序副本的响应能力和可靠性，如下所示：
由于 CloudWatch Synthetics 是一项托管服务，因此您可以在附近的 AWS 区域部署金丝雀，以确保即使是应用程序运行所在区域内的问题，您的监控也能灵活应对。
其他输入：除了直接监控应用程序的运行状况信号外，评估其他输入（例如来自 AWS Health Dashboard 的通知）也很有用。请注意，当 Health Dashboard 显示某个 AZ 中的问题时，并不一定表示您自己的应用程序受到了影响。出于这个原因，通常最好同时直接评估应用程序可用区副本的运行状况。
控制面板和聚合：将流量移出可用区的常见起点是，在尝试自动执行此类流量移动之前，先让操作员执行手动操作（即由人员做出决策）。对于操作人员来说，如前文示例所示的简单 CloudWatch 控制面板可提供可用区的单一整体视图，有助于快速做出决策。请注意，CloudWatch 控制面板是全球性的。因此，创建该控制面板后，您可以从任何 AWS 区域访问它，以提高复原能力。
可用区转移的最佳实践
由于可用区转移会减少实时应用程序的容量，因此在生产环境中使用可用区转移时必须小心。让我们讨论一些准备工作和安全检查，以帮助确保安全使用可用区转移。
预先扩展容量余量。当您遵循以恢复为导向的策略时，我们建议您预先扩展计算容量，留出足够的余量，以便在一个可用区副本离线的情况下满足峰值流量的要求。可用区转移使这一点变得更加重要。启动可用区转移会暂时从负载均衡器后面移除一个可用区的容量。这意味着，在使用可用区转移之前，必须确保所有可用区都有足够的容量。对于关闭跨可用区负载均衡的 3-AZ ALB 或 NLB，当您从一个可用区时转移负载时，预计另外两个可用区中的每个可用区会增加大约 50% 的负载。对于 2-AZ 负载均衡器，您应该预计另一个可用区的负载会增加一倍。
如果您决定使用扩展策略而不是预先扩展容量，请仔细考虑所使用的策略和指标。例如，平均 CPU 利用率可能不会因可用区转移而增加。这是因为当自动扩缩组某一部分的 CPU 利用率降低时，另一部分的 CPU 利用率会随之增加。
确保所有可用区副本均正常运行，并且正在接收流量。可用区转移的工作原理是将一个可用区中的应用程序副本标记为运行状况不佳。因此，在发生影响其中一个副本的事件之前，您必须确保您的目标在其他可用区副本中正常运行，并且正在接收流量。为确保您保持这种意识，请创建一个控制面板，其中包含运行状况不佳的目标的 ELB 指标和每个可用区的 bytesProcessed 指标，如此处的示例控制面板所示。
提前测试。与任何恢复机制一样，您必须定期练习，以确保它在需要时能发挥作用。我们建议在实际事件发生之前使用可用区转移，最好是同时在测试和生产环境中使用。测试将使您在发生操作性事件时胸有成熟、游刃有余。
练习使用 API 或 CLI。为了快速成功地处理故障，您通常需要使用最快、最可靠且依赖性最少的工具。为便于使用，我们在 AWS 管理控制台上提供了可用区转移。但是，当快速恢复至关重要时，我们建议您的恢复运行手册告诉操作员使用亚马逊云科技命令行界面（Amazon CLI）或可用区转移 API 调用，如果可能，结合使用预先存储的 AWS 凭证。
仅使用可用区转移暂时移动流量。应用程序中运行状况不佳的可用区副本一旦修复，就应恢复使用。这可以确保整个应用程序尽快恢复到完全冗余和弹性状态。
小心地执行自动化。下一步自然是努力实现可用区转移的自动化。这很合理，但要仔细考虑边缘情况。例如，如果您的应用程序因为流量突然增加而变得过载，那么您通常不需要移除可用区，因为这会使问题变得更糟。另外，请确保添加的任何自动化操作都会在在可用区转移开始时仔细检查其他副本是否正常运行。
从另一个区域进行监控。考虑从相邻的 AWS 区域进行主动监控。附近的区域可能更能代表您的应用程序的客户体验，而从另一个区域进行监控可以减少应用程序与其监控之间风险共担的问题。
试用可用区转移
为了帮助您开始在 Route 53 ARC 中进行可用区转移，我们提供了一个 AWS CloudFormation 示例模板，您可以下载和部署该模板，以便在示例 NLB 应用程序中试用此功能。您可以使用 Amazon Fault Injection Simulator（Amazon FIS）来模拟灰色故障事件，然后启动可用区转移以进行恢复。该模板创建的架构与这篇博客文章中描述的架构类似。下载内容包括以下内容：
- 3-AZ NLB，已关闭跨可用区负载均衡
- 自动扩缩组，主机运行 Apache Web 服务器来满足 1MB 文件的要求
- Regional CloudWatch Synthetics 金丝雀，它通过 NLB（客户视图）轮询 1MB 文件
- 针对每个可用区提供的三个 CloudWatch Synthetics 金丝雀，它们还会根据其特定的可用区 NLB 端点（每个可用区视图）轮询 1MB 文件
- 基于异常检测的 CloudWatch 警报
- CloudWatch 控制面板，在一个视图中显示所有数据
- AWS FIS 实验模板，它向一个可用区注入灰色故障（丢包率 2%），持续 30 分钟
使用该 CloudFormation 模板自行试用可用区转移。您可以按照以下步骤了解以恢复为导向的策略的工作原理：
- 下载 CloudFormation 模板并在任何可进行可用区转移的 AWS 区域部署。
- 在 AWS 管理控制台中，打开 CloudWatch 控制面板，等待数据模式建立。
- 打开 FIS 控制面板，开始实验 PacketLossOnInstancesIn-AZ-B，它将在一个可用区副本中注入数据包丢失。
- 返回 CloudWatch 控制面板，等待 3-5 分钟，然后查看客户体验 ResponseTime 指标的变化。两个 AZ 的响应时间应该正常，一个 AZ 的响应时间应该有所增加，这表明一个可用区副本出现了问题。
- 记下或复制响应时间较长的可用区副本的 AZ ID。
- 打开 Route 53 ARC 控制台，然后选择可用区转移。
- 选择启动可用区转移，然后在选择可用区下拉菜单中，选择您从 CloudWatch 控制面板中记录或复制的 AZ ID。
- 在资源表中，从 CloudFormation 堆栈中选择 NLB 的 ARN。
- 在设置可用区转移到期时间下，选择 6 小时。
- 选中确认复选框，然后选择开始。
现在返回 CloudWatch 控制面板。您应该会看到客户体验列显示恢复情况，而问题可用区副本的金丝雀继续显示问题。您还应该会在 BytesProcessed 图表上看到，流量正在从一个副本转移到其他副本。
现在，您可以取消 FIS 实验或等它到期，受影响的可用区副本中的问题将得到解决。您也可以取消可用区转移，方法是：在 Route 53 ARC 控制台中，选择您启动的可用区转移，然后选择取消可用区转移。
最后，通过删除 CloudFormation 堆栈来清理可用区转移实验中的资源。
要使用可用区转移，您需要拥有对可用区转移 API 的权限。使用弹性负载均衡托管策略、ElasticLoadBalancingFullAccess 或 AdministratorAccess 的 IAM 用户和角色自动授予访问权限您还可以在自己的 IAM policy 中明确授予对 arc-zonal-shift API 操作的访问权限。
现已推出
现已在简介中列出的 AWS 区域推出适用于已关闭跨区域负载均衡的 ALB 和 NLB 的 Route 53 ARC 可用区转移功能。将来将支持更多 AWS 区域和负载均衡器配置。欢迎试用可用区转移，并向我们提供您的反馈！