利用亚马逊云科技创建多区域架构的最佳实践

## 视频 <video src="https://dev-media.amazoncloud.cn/30-LibaiGenerate/31-LiBaiRebrandingVideo/ARC308-Best_practices_for_creating_multi_Region_architectures_on_AWS-LBrebrandingWCaptionCN.mp4" class="bytemdVideo" controls="controls"></video> ## 导读 构建和构建多区域体系结构可能会带来一系列新的挑战。这些挑战包括如何管理依赖性、基础架构部署、数据复制、一致性、可观察性、测试和操作。无论需要扩展到多个地区提高弹性，遵守政府数据法规，或改善最终用户延迟，本论坛将重点介绍最佳实践、设计原则和示例架构，从而帮您满足需求。 ## 演讲精华 <font color = "grey">以下是小编为您整理的本次演讲的精华，共2600字，阅读时间大约是13分钟。如果您想进一步了解演讲内容或者观看演讲全文，请观看演讲完整视频或者下面的演讲原文。</font> 乔·查普曼（Joe Chapman）和尼尔杰·库马尔（Neeraj Kumar）热烈欢迎参加此次re:Invent的与会者。这次会议专注于分享在亚马逊云科技上创建多区域架构的最佳实践。他们解释说，这次会议的推动力是为了解决组织在考虑跨越多个亚马逊云科技地区构建或扩展其工作负载时所面临的各种复杂决策。这些决策的驱动因素可能包括为全球分布的用户群提高性能，为关键工作负载增加可用性，或者遵守数据居住法规。无论动机如何，发言人都承认，设计和运营多区域架构都会带来大量的复杂性。无论是刚刚开始这段旅程还是已经深入规划，有许多重要的设计权衡需要评估。 乔和尼尔杰强调，通过查看现实世界的例子并提取关键经验教训，与会者将离开此会议更有能力规划自己的多区域路线。在简要概述了议程和预期结果之后，乔在进一步深入研究多区域架构之前先退一步，确保建立了适当的基础。他提醒观众，亚马逊云科技地区本身就是为了弹性而设计的，具有跨离散数据中心自动冗余的功能。具体来说，乔概述了每个亚马逊云科技地区至少包含三个独立的可用区。可用区由一个或多个位于可能影响其邻居的潜在灾难影响区域之外的数据中心组成。这种隔离可以通过在不同的洪泛平原上定位或将独立的基础设施供电来实现。在可用区内，通过高带宽、低延迟的网络连接链接各个数据中心。这使得能够在不跨越长距离的情况下部署高度可用且高性能的应用程序。乔想让观众记住的基本观点是，亚马逊云科技地区是通过设计来支持弹性的。 对于已在亚马逊云科技上运营一段时间的组织而言，区域的弹性特性可能已经得到了很好的理解。然而，在开始处理多区域复杂性之前，乔建议通过亚马逊云科技架构良好框架的角度进行设计审查。这个练习的目的是确认工作负载是否真正能够利用单区域的弹性，然后再尝试将其扩展到更广泛的范围。乔警告说，匆忙地将不理想的区域架构跨多个区域展开可能会加剧问题，而不是解决它们。 当然，乔承认许多与会者可能会有必要的技术或业务需求，需要多区域架构。对于这些使用场景，他建议清楚地定义当前架构和推动变革的未来需求这两个方面。例如，如果提高性能是目标，应该收集有关延迟、吞吐量和错误率的基准指标。然后，需要建立量化寻求的性能提升目标的指标。这种数据驱动的方法可以消除假设，并将技术实现的重点放在可测量的结果上。 同样，如果增加可用性是主要需求，应了解当前的可用性水平及其量化方法。在确定现状基准的基础上，必须确定未来的可用性目标及其测量方式。 最后，如果遵守数据居住地法规要求多区域架构，则需明确适用于组织的具体条款。这可能包括对数据存储位置、数据传输机制和人员数据访问的限制。 在充分理解当前状态和未来需求的基础上，乔建议仔细反向思考以确定候选解决方案。应该从完全满足需求的角度评估这些解决方案，以找到最佳前进道路。 让他表示，让业务和技术利益相关方参与这个过程对于就固有成本、复杂性和权衡达成一致非常关键。乔强调，这种前期一致将为组织的多区域之旅奠定坚实的基础。 在探讨了单地区与多地区架构的问题后，乔将任务交给了他的同事尼尔杰，以便后者能介绍两个现实生活中的客户案例。这些案例将展示常见的多地区迁移过程并提炼出关键经验教训。 尼尔杰首先介绍了第一个场景，这是一个迅速发展的金融科技零售银行。过去，这家银行一直在一个亚马逊云科技地区内运营。然而，随着客户群的不断增长，潜在的中断时间对业务的影响也越来越大。因此，灾难恢复和业务连续性问题已经上升到了董事会层面。 为了实现灾难恢复目标，即达到15分钟的恢复点目标和1小时的恢复时间目标，银行需要评估不同的架构选项以满足其需求。这些选项包括了从简单的备份和恢复到试点、暖备用和活动就绪设计等各种复杂性和功能。在经过仔细考虑后，银行选择了暖备用架构，因为这是根据其使用情况做出的适当权衡。 在暖备用模式下，工作负载会被复制到二级被动地区。当一级地区发生故障时，二级地区可以承担全部生产负载。该架构的关键组件包括一种数据复制机制，用于保持备用地区的数据库更新，以及足够的计算能力，以便在故障切换时运行完整的工作负载。 为了满足他们的数据复制需求，银行使用了[Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail)的本地全局数据库功能。这使他们能够以主动-被动方式跨地区部署Aurora集群，从而有效地将数据更新从主要地区传输到次要地区。 此外，跨地区同步应用程序代码和配置也非常重要。银行采用了分阶段部署代码的最佳实践。这意味着首先在主要地区发布，然后在后续部署到次要地区之前留出确认稳定性的时间。 银行还制定了一份详细的运行手册，详细阐述了在需要切换到辅助区域时需要执行的程序。遵循最佳的弹性实践，这些过程被设计成可以在辅助区域中执行，从而避免了主要区域内可能出现的故障依赖项或网络问题对故障切换产生影响。 Neeraj总结了一些银行温暖备用方法所展示的关键最佳实践： - 根据RPO/RTO需求，让业务影响分析指导灾难恢复和持续策略。 - 在地区范围内错开代码更改部署，以允许测试和每个发布的确认。 - 选择满足工作负载恢复点目标的数据复制技术。 - 确保恢复过程可以从辅助区域调用，以避免受损的依赖关系。 基于温暖备用原则，银行开始实施对其故障切换过程的定期测试。这将建立组织对故障切换在实际断电期间按预期运行的信任。他们开始进行频繁的“比赛日”演练，以锻炼故障切换和其他灾难情景。这些全公司范围的模拟验证了在危机期间人员、流程和技术可以正确协调。银行还开始利用亚马逊云科技的故障注入服务来注入受控故障，并进一步测试检测和恢复能力。 Neeraj指出，这些做法继续展示了良好的多区域原则： - 在模拟场景中定期测试检测和控制恢复，以防止真实事件的发生。 在银行的多区域旅程中，他们将关注点转向确保负责检测区域故障的系统的弹性。他们意识到，对可观察性能力的任何损害都可能阻碍快速的故障切换决策。为了减轻这种风险，实施了内部和外部监控，以测量地区的健康状况。这提供了相关数据点，以自信地区分实际区域断电和监控系统故障。 由于备用的外部监控，故障切换过程可以依赖权威数据来触发跨区域的路由更改、容量增加和其他灾害响应。Neeraj强调的最佳实践是： 从内部和外部角度来看待区域卫生问题，以便获得可靠的故障切换信号。 Neeraj总结说，银行正有计划地经历多区域成熟过程，从而影响了其目前的架构状况。通过复制、测试、监控和严格的管理，恢复了系统的恢复能力。然而，由于工作负载和技术不断变化，持续的改进被认为是非常必要的。 尽管已经取得了显著的进步，但一切都不是免费的。为了实现其强大的多区域功能，银行增加了额外的复杂性和成本。与所有的架构决策一样，这些权衡都是通过限制停机时间和保持竞争力来证明其合理性的。 在第一个场景结束后，Joe继续介绍了第二个客户旅程——将单一区域的应用程序迁移到多区域的主动-主动模式。这家公司为全球用户提供多种客户的认证即服务。 他们转型的动力来自于两个方面。首先，随着他们签订更大的企业合同，客户需要合同保证的可用性超过99.99%。他们的当前区域架构很难持续达到这些高可用性目标。其次，尽管全球用户分布广泛，但性能根据地理位置而显著不同。数据显示，某些地区的用户认证延迟比其他地区高得多。这导致他们很大一部分客户群的体验不佳。 该公司为其多区域计划设定了两个具体目标： 1. 将其关键认证API的可用性提高到99.99%。 2. 全球范围内将认证延迟减少30%。 Joe概述了现有的架构，包括一个API网关，前端连接Lambda、ECS和EC2计算资源。数据存储在DynamoDB和S3中。 随着将这种架构扩展到多个区域的工程开始，团队很快遇到了第一个挑战。在检查更广泛的环境后，他们意识到只有大约20%的生产基础设施是用代码定义的。随着时间的推移，大量的配置漂移和手动更改累积在了假设的理想状态和实际区域部署之间。这对一致的跨区域推广构成了主要障碍。 基础设施即代码对于实现一致的跨区域部署至关重要。通过利用堆叠参数和条件，每次只在一个区域进行更改部署。接下来，需要解决一个智能且可靠的全球跨区域路由问题。公司希望确保用户，无论地理位置如何，都能获得最佳的延迟性能。为了解决这个问题，他们实施了基于延迟的Route 53路由服务。该服务使用DNS自动将用户路由到最接近的、根据延迟计算的区域端点。为了在应用程序出现问题时转移流量，还部署了Route 53应用程序恢复控制器。通过与状态检查的集成，恢复控制器可以程序化地将用户从不健康的区域移走。这两个服务共同帮助公司在多区域架构中实现了高性能的交通管理解决方案。此外，Joe还强调了其他一些最佳实践：Route 53基于延迟的路由和应用程序恢复控制器支持全球的性能和区域的疏散能力。尽管大多数用户活动都与读取密集的认证API互动，但公司仍需谨慎考虑数据复制策略。在同步和异步复制模型之间进行权衡后，团队认为跨区域的同步复制可以提供原子一致性，但性能和可用性的权衡使他们最终选择了异步复制。 要理解工作负载的一致性需求和数据复制选项。 - 在多写者架构中，确保一致性通过实现如idempotence（即操作可以被重复执行而不影响结果）和变化检测等技术来实现。 可观察性是另一个关键关注领域，因为它有助于提高可用性和性能。公司从多个角度进行检查，以构建一个全面的运行状况图像。服务器日志提供后端可见性，而来自其他区域的合成检查测量前端用户流量。真实用户监控则捕获生产使用数据。这些不同的可观察性手段结合在一起，可以快速检测到影响终端用户的异常。 - 通过实施不同内外部检查方法以获得强大的可观察性。 随着多区域推广的继续，公司优先考虑采用架构最佳实践以提高工作负载的区域独立性。这增强了工作负载之间的隔离，减少了问题发生时的影响范围。所有流量都转移到地区2，以揭示任何潜在的跨区域耦合。这项锻炼揭示了某些后续需要去耦的遗留集成点。这些改进确保了其中一个区域的工作负载可以完全独立运行。 - 为限制故障在区域间的传播，要设计用于完全区域独立性的架构。 然而，团队也意识到，尽管基础设施成本已被考虑在内，但运营费用可能被低估了。增加的人员、培训以及程序更新将是运行多区域架构所必需的。例如，运行书籍需要根据区域进行故障排除步骤进行更新。新的运行书籍还需要为诸如计划区域疏散等场景创建。服务配额也需要在每个区域而不是仅仅在账户级别谨慎跟踪和管理。 - 预测并预算额外的运营开销，如针对特定区域的运行书籍和服务配额管理。 正在进行的区域间配置调整是一个潜在挑战。为了持续监控不一致性，实施了对恢复控制器运行状况和就绪检查的调整。这使得能够主动修复基础设施和应用部署过程中的问题。随着时间的推移，检测漂移对于维护区域间的一致性变得至关重要。 - 拥有检测和纠正区域间配置和部署差异的工具。 乔在该公司继续优化其架构的过程中，审查了所涉及的最佳实践。他指出仍有一些未完成的任务，但示例展示了一个由业务需求驱动的深思熟虑的过程。 尼尔杰根据两个详细的客户情况提供了结论性意见。他总结说，关键是要让业务需求主导技术决策。考虑到亚马逊云科技区域的固有弹性，大多数工作负载不需要在多个地域进行复杂的扩展。 当他有说服力的商业理由时，他建议逐步进行并有计划地进行。这些案例研究了数据复制、一致性、部署速度、恢复测试和可观察性等方面的挑战。建筑设计应该有意在复杂性和功能之间取得平衡。 没有适用于所有用例的单一多区域架构，因此建议与亚马逊云科技解决方案专家合作。尼尔杰推荐了亚马逊云科技制作的《多区域基础知识》和《韧性生命周期》白皮书以供进一步学习。 总的来说，演讲者在re:Invent上通过实际公司的案例研究将其单区域应用转变为多区域架构。他们的目标是通过对战场上的具体经验教训，帮助观众在类似的旅程中保持清晰的视野。 这些案例强调了让业务需求设定方向，同时积极应对技术复杂性的问题。乔和尼尔杰重申，没有针对多区域弹性的标准答案或捷径。然而，通过有计划地处理可用性、性能、一致性、冗余和操作方面的问题，企业可以量身定制解决方案，同时尽量减少风险。 **下面是一些演讲现场的精彩瞬间：** 在多个亚马逊云科技区域中运行工作负载可以提升性能、提高可用性和增强合规性。  ARC将持续进行就绪检查，以确保辅助区域的应用程序得到正确配置以实现故障切换。  可观察性作为检测和控制故障以实现快速恢复的基本功能，对于跨地区扩展可观察层以获取外部视角并做出更明智的故障决策至关重要。  当前的韧性架构是一个不断发展的观点，并且是一个持续的改进过程，涉及到逐步升级、权衡和额外的运营开销。  演讲者强调了在开始多区域架构之旅时，仔细考虑数据依赖性和访问模式的重要性。  领导者分享了亚马逊云科技的灾难恢复服务以及构建韧性解决方案的经验。  ## 总结 这段视频探讨了在亚马逊云科技（Amazon Web Services）上构建多区域架构的最佳实践。演讲者通过两个实际案例展示了关键经验教训。 第一个案例涉及到一家寻求改进其灾难恢复策略的金融科技零售银行。由于公司的快速增长，该行已将其恢复时间目标（RTO）和恢复点目标（RPO）指标化，并采用了跨区域的热备用策略。他们还实施了亚马逊Aurora全局数据库（[Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) Global Database）的数据复制，并逐步部署代码。此外，他们还会定期进行应急演练和故障注入服务（Fault Injection Service）测试，以便更好地理解故障切换流程。为了优化观察性，该行还实现了跨区域扩展，从而更有效地检测和处理故障。同时，他们使用亚马逊Route 53应用程序恢复控制器来实现智能流量路由。 第二个案例涉及到一个希望提高全球正常运行时间服务级别协议（SLA）并降低延迟的认证提供商。该提供商使用了亚马逊云形成（CloudFormation）实现基础架构即代码，以确保一致的跨区域部署。他们还利用了商用Route 53基于延迟的路由和恢复控制器来进行智能流量分发。为了提高可用性和性能，他们还使用了亚马逊DynamoDB全局表的异步复制功能。此外，他们还实施了差异化观察，以获取应用程序的整体健康状况。 一些关键最佳实践包括： - 以业务需求为主导，推动多区域需求的产生 - 在一个区域内先实施弹性基本原则，例如观察性 - 了解工作负载的一致性需求，并选择合适的数据复制策略 - 使用基础架构即代码并进行分阶段部署，以实现一致的区域推广 - 结合基于延迟的智能路由和流量分配能力 - 定期测试故障切换流程，并运行区域健康状况检查 - 设计具有区域独立性的架构，以隔离区域性问题 - 考虑因增加运营开销而产生的额外成本，例如运行手册和服务配额 ## 演讲原文 ## 想了解更多精彩完整内容吗？立即访问re:Invent 官网中文网站！ [2023亚马逊云科技re:Invent全球大会 - 官方网站](https://webinar.amazoncloud.cn/reInvent2023/?s=8739&smid=19458 "2023亚马逊云科技re:Invent全球大会 - 官方网站") [点击此处](https://aws.amazon.com/cn/new/?trk=6dd7cc20-6afa-4abf-9359-2d6976ff9600&trk=cndc-detail "点击此处")，一键获取亚马逊云科技全球最新产品/服务资讯！ [点击此处](https://www.amazonaws.cn/new/?trk=2ab098aa-0793-48b1-85e6-a9d261bd8cd4&trk=cndc-detail "点击此处")，一键获取亚马逊云科技中国区最新产品/服务资讯！ ## 即刻注册亚马逊云科技账户，开启云端之旅！ [【免费】亚马逊云科技“100 余种核心云服务产品免费试用”](https://aws.amazon.com/cn/campaigns/freecenter/?trk=f079813d-3a13-4a50-b67b-e31d930f36a4&sc_channel=el&trk=cndc-detail "【免费】亚马逊云科技“100 余种核心云服务产品免费试用“") [【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用”](https://www.amazonaws.cn/campaign/CloudService/?trk=2cdb6245-f491-42bc-b931-c1693fe92be1&sc_channel=el&trk=cndc-detail "【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用“")