REL11-BP02 失效转移到运行状况良好的资源 - 可靠性支柱
实施指导 资源

REL11-BP02 失效转移到运行状况良好的资源

如果资源发生故障，运行状况良好的资源应继续为请求提供服务。对于位置受损（如可用区或 AWS 区域），确保您拥有适当的系统，以失效转移到未受损位置内运行状况良好的资源。

设计服务时，应在资源、可用区或区域之间分配负载。因此，可以通过将流量转移到运行状况良好的剩余资源，缓解单个资源的故障或损坏。考虑在出现故障时如何发现服务并将流量路由到相应服务。

在设计服务时要考虑故障恢复。在 AWS，我们设计服务时会尽量缩短从故障恢复的时间并降低对数据的影响。我们的服务主要使用的数据存储，只有在数据持久存储在一个区域中的多个副本之后，才会确认请求。它们被构建为使用基于单元格的隔离，并使用可用区提供的故障隔离功能。我们在自己的运营过程中广泛使用自动化。我们还将替换和重新启动功能优化为可从中断快速恢复。

允许失效转移的模式和设计因各项 AWS 平台服务而异。许多 AWS 原生托管服务本质上跨多个可用区（如 Lambda 或 API Gateway）。其他 AWS 服务（如 EC2 和 EKS）需要特定的最佳实践设计，来支持跨可用区的资源或数据存储的失效转移。

应设置监控功能，以检查失效转移资源是否正常，跟踪资源失效转移的进度，并监控业务流程的恢复情况。

期望的结果： 系统能够自动使用新资源从降级中恢复，或手动恢复。

常见反模式：

  • 规划和设计阶段未考虑如何应对失败。

  • 未确立 RTO 和 RPO。

  • 监控不足，无法检测出故障的资源。

  • 适当隔离故障域。

  • 不考虑多区域失效转移。

  • 在决定是否进行失效转移时，故障检测过于敏感或过于激进。

  • 未测试或验证失效转移设计。

  • 执行自动修复，但不通知需要进行该修复。

  • 缺少缓冲期，无法避免太快进行失效自动恢复。

建立此最佳实践的好处： 您可以构建更具韧性的系统，在遇到故障时，通过正常降级和快速恢复，保持可靠性。

未建立这种最佳实践的情况下暴露的风险等级： 高

实施指导

AWS 服务（例如 Elastic Load Balancing 和 Amazon EC2 Auto Scaling）有助于跨资源和可用区分配负载。因此，可以通过将流量转移到运行状况良好的剩余资源，缓解单个资源（例如 EC2 实例）的故障或可用区的损坏。

对于多区域工作负载，设计就比较复杂。例如，跨区域只读副本允许您将数据部署到多个 AWS 区域。但是，仍需要进行失效转移才能将只读副本提升为主副本，然后将流量指向新的终端节点。Amazon Route 53、Route 53、Route 53 ARC、CloudFront 和 AWS Global Accelerator 可以协助跨 AWS 区域路由流量。

Amazon S3、Lambda、API Gateway、Amazon SQS、Amazon SNS、Amazon SES、Amazon Pinpoint、Amazon ECR、AWS Certificate Manager、EventBridge 或 Amazon DynamoDB 等 AWS 服务将通过 AWS 自动部署到多个可用区。如果出现故障，这些 AWS 服务会自动将流量路由到状态正常的位置。数据在多个可用区中进行冗余存储，并保持可用。

对于 Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon EKS 或 Amazon ECS，多可用区是一个配置选项。如果启动了失效转移，AWS 可以将流量引导到运行正常的实例。此失效转移操作可由 AWS 执行，或根据客户要求执行

对于 Amazon EC2 实例、Amazon Redshift、Amazon ECS 任务或 Amazon EKS Pod，您要选择部署到哪些可用区。对于某些设计，Elastic Load Balancing 会提供解决方案以检测运行不正常的可用区内的实例，并将流量路由至运行正常的可用区。Elastic Load Balancing 还可以将流量路由至本地数据中心内的组件。

对于多区域流量失效转移，重新路由可以利用 Amazon Route 53、Route 53 ARC、AWS Global Accelerator、Route 53 Private DNS for VPCs 或 CloudFront 来提供一种方法，以定义互联网域并分配路由策略（包括运行状况检查），从而将流量路由到运行正常的区域。AWS Global Accelerator 提供静态 IP 地址，这些地址充当应用程序的固定入口点，然后使用 AWS 全球网络而不是互联网来路由到您选择的 AWS 区域中的端点，以获得更高的性能和可靠性。

实施步骤

  • 为所有相应的应用程序和服务创建失效转移设计。隔离每个架构组件，为每个组件创建符合 RTO 和 RPO 的失效转移设计。

  • 使用失效转移计划所需的所有服务配置底层环境（例如开发或测试）。使用基础设施即代码（IaC）部署解决方案，以确保可重复性。

  • 配置恢复站点（例如第二个区域）以实施和测试失效转移设计。如有必要，可以临时配置测试资源以限制额外成本。

  • 确定哪些失效转移计划由 AWS 自动执行，哪些可以通过 DevOps 流程自动执行，哪些可能需要手动执行。记录并测量每项服务的 RTO 和 RPO。

  • 创建失效转移行动手册，包括对每个资源、应用程序和服务进行失效转移的所有步骤。

  • 创建失效自动恢复行动手册，包括对每个资源、应用程序和服务进行失效自动恢复的所有步骤（包含时机）

  • 制定计划以启动和演练行动手册。使用模拟和混沌测试来测试行动手册步骤和自动化功能。

  • 对于位置受损（如可用区或 AWS 区域），确保您拥有适当的系统，以失效转移到未受损位置内运行状况良好的资源。在测试失效转移之前，请检查配额、自动扩展级别和正在运行的资源。

资源

相关的 Well-Architected 最佳实践：

相关文档：

相关示例：