了解亚马逊网站如何以及为何扩展到更多亚马逊云科技区域,并构建服务以便于在不同区域部署和迁移。在本次讨论中,探索使用多个亚马逊云科技区域的好处,以及亚马逊网站在构建和管理区域灵活服务方面的经验和最佳实践。学习如何将服务与特定区域解耦、管理应用程序延迟和依赖关系,以及如何设计架构以利用区域多样性、客户邻近性和成本优化等区域灵活部署带来的优势。
以下是小编为您整理的本次演讲的精华。
亚马逊多区域扩展战略的复杂性进一步加剧了由于其服务背后错综复杂的依赖关系和相互连接而带来的挑战。Lisa Gutamrithand透露,几年前他们的服务图快照仅显示了他们服务的一小部分,数据流明显缺失。缺乏全面的服务图成为一个重大遗憾,因为团队不得不重新回顾部落知识来解开服务和数据源之间复杂的关系。
一个特别引人注目的例子凸显了这一挑战的深度。Lisa分享说,对于亚马逊网站上的单个详情页面,图表中的每一个箭头都代表一个不同的服务或API调用,而快照只捕获了实际依赖关系的一小部分。协调如此复杂架构在不同区域之间的迁移成为了一项艰巨的任务,迫使亚马逊设计出将这一过程分解为更小、更易管理的部分的策略。
为了应对这种复杂性,亚马逊探索了针对不同用例量身定制的技术。对于面向人类客户的系统,其延迟要求与服务计算机客户端的要求不同,亚马逊对迁移方法进行了区分。此外,亚马逊认识到其市场之间的技术债务水平不同,因此优先选择历史包袱较少的区域进行推广。
也许最有趣的策略是区分“可见区域”和“不可见区域”体验。借鉴网页渲染的类比,亚马逊认识到客户对初始页面加载和后续需要滚动的交互的延迟期望是不同的。通过利用这一区别,亚马逊可以优先迁移影响初始客户体验的关键组件,而将不太敏感的方面推迟到后期阶段。
作为这些策略的补充,亚马逊着手开发“体验级别目标”的概念,这一概念超越了个别团队历来关注的传统服务级别目标(SLO)。Lisa坦率地承认,这是亚马逊尚未解决的一个领域,但一位高级工程师已被指派解决这一挑战,目标是在下一年的re:Invent大会上提出解决方案。
配置管理成为亚马逊多区域之旅中的一个重大障碍。Lisa透露,典型的亚马逊配置密钥遵循一种假定特定区域(如“us-east-2”)的模式。这种硬编码的假设渗透到无数配置文件中,给亚马逊寻求扩展到新区域带来了巨大挑战。
为了说明这个问题的严重性,Lisa分享了一个用于加拿大出版商的配置密钥示例。该密钥假定加拿大总是在us-east-2区域运行,与多区域策略不兼容。同样,技术配置通常依赖于与us-east-2区域相关的特定亚马逊资源名称(ARN),进一步加剧了这一问题。
认识到需要范式转变,亚马逊着手过渡到“自然参数”——与区域无关且可以无缝适应任何区域的配置密钥。这涉及到一种多管齐下的方法,从为团队提供区域迁移指导开始,逐步发展到可以在拉取请求中检测有问题的配置的linter,最终目标是到2025年将区域感知配置辅助直接集成到集成开发环境(IDE)中。
对于大量现有代码,亚马逊转向了Amazon CodeGuru,利用其人工智能驱动的功能通过自动拉取请求来识别和修复配置问题。Lisa强调亚马逊致力于引导团队朝着与区域无关的配置迈进,认识到成功导航这一复杂过渡所需的专业知识。
基础设施作为代码成为亚马逊多区域战略的一个关键推动力。Lisa强调了基于点击操作的扩展所带来的挑战,引用了许多最初采用这种方法但后来却感到后悔的团队。缺乏全面的资源清单往往会导致疏忽,例如忘记在新区域配置关键资源,如DynamoDB表或S3存储桶。
为了解决这些问题,亚马逊采用了亚马逊云科技 Cloud Development Kit (CDK),它提供了一个强大的框架用于资源发现,并降低了手动错误的风险。Lisa分享了一个理想目标:简化添加新区域的过程,只需更新一个列表,这体现了基础设施作为代码的强大和灵活性。
数据一致性成为亚马逊多区域之旅中的一个巨大挑战。Lisa承认,人们对跨区域同步延迟测量在数十毫秒的强一致性数据感到忧虑。无法接受停机的实时迁移前景进一步加剧了这一艰巨任务的复杂性。
然而,亚马逊在Prime Video采用的最终一致性模型中找到了慰藉。通过利用DynamoDB中的全局表,Prime Video能够无缝地跨区域同步数据,大大简化了在流量转移期间团队之间的协调工作。这种方法被证明是多区域之旅中最积极的惊喜之一,因为Prime Video的大部分系统都可以使用DynamoDB全局表提供的最终一致性模型进行迁移。
对于无法容忍最终一致性的强一致性用例,亚马逊探索了替代策略。亚马逊的广告团队采用了“互斥键空间”方法,实际上是一次将一个客户迁移到另一个区域。虽然这引入了流量和数据迁移之间的协调挑战,但它允许团队将每个客户视为驻留在单个区域中,从而简化了数据同步过程。
Lisa强调了持续现代化在亚马逊多区域战略中的重要性。技术债务,如硬编码的配置和假设,以及像Amazon SimpleDB这样遗留服务的存在,都必须主动解决。鼓励团队拥抱现代化努力,认识到解决长期存在的问题的动机终于以多区域的必要性形式出现。
当Frank Stone登场时,他深入探讨了指导亚马逊选择目标扩展区域的考虑因素。区域之间的延迟成为一个关键因素,亚马逊云科技区域之间的物理距离引入的延迟远远超过了单个区域内通常经历的亚毫秒延迟。Frank警告说,应用程序通常会多次跨越这些区域间距离,从而加剧了性能影响,因此需要仔细评估依赖关系。
另一个考虑因素是不同区域可用实例类型的差异。虽然新区域通常提供最新的实例类型,但旧区域可能缺乏应用程序针对的遗留实例类型的支持。这一现实需要重新表征应用程序性能配置文件,这对于迁移到新区域的团队来说是一项不小的任务。
亚马逊云科技区域之间可用服务的差异也需要引起注意。随着新服务的发布和推出,它们最初只在一部分区域可用。Frank建议客户与亚马逊云科技服务团队协调,确保服务可用性与其业务需求保持一致,并探索在所需区域推出服务的潜在解决方案或时间表。
Frank强调了网络星期一等突发流量事件的容量规划的重要性。他强调与亚马逊云科技服务团队接洽,了解扩展限制并提前配置资源,确保在高需求期间为客户提供无缝体验。
为了加快数据迁移工作,亚马逊利用了S3跨区域复制(CRR)和亚马逊云科技数据库迁移服务的强大功能。S3 CRR支持跨区域同步对象数据,而亚马逊云科技数据库迁移服务则通过利用读取副本等机制,实现了最小停机时间的数据库复制。
Frank分享了S3 CRR流程的见解,强调了在目标区域创建新存储桶并配置跨区域复制的能力。这将确保在源区域创建的任何新对象都会自动复制到目标区域。但是,为了解决源存储桶中现有的对象,亚马逊采用了S3批量复制,这是一个一次性的过程,将所有对象从源迁移到目标区域。
虽然S3 CRR提供了每秒1千兆的默认复制速率,但Frank承认,对于某些用例,可能需要更高的吞吐量。在这种情况下,客户可以与亚马逊云科技支持部门接洽,要求提高复制速率,以满足其特定需求。
在数据库领域,亚马逊利用了亚马逊云科技服务(如DynamoDB、Aurora、DocumentDB、Neptune、Elasticsearch和RDS)提供的内置复制机制。推荐的方法是在目标区域创建一个读取副本,允许数据同步并最终将写入操作故障转移到读取副本。
虽然这种方法在故障转移过程中引入了最终一致性,Frank指出,对于某些具有强一致性要求的用例(如支付应用程序),可能需要额外的应用程序逻辑来确保跨区域的数据完整性。
对于Aurora Global Tables,亚马逊与亚马逊云科技合作优化了复制过程,实现了仅需几秒钟的故障转移时间,并实现了跨区域的近乎实时事务复制。然而,对于其他RDS数据库,复制和故障转移过程可能会稍慢一些,但仍遵循相同的一般原则。
Frank还强调了跨区域备份和快照的能力,作为一种可行的数据迁移策略。这种方法涉及在源区域备份数据存储或数据库,将备份或快照复制到目标区域,并在那里恢复它们,从而在最小化停机时间的同时迁移数据。
随着他们的演讲接近尾声,Frank和Lisa总结了亚马逊多区域之旅的关键要点,强调了多区域策略可以带来的切实好处。降低延迟、增强故障转移能力、负载均衡机会以及符合数据驻留要求等都是促使亚马逊努力的令人信服的优势。
然而,他们强调了主动规划和持续现代化作为关键成功因素的重要性。拥抱基础设施即代码、解决技术债务以及持续评估架构决策被确定为为未来区域扩展做好准备的重要步骤。
仔细评估目标区域,考虑延迟、实例类型可用性、服务推出和容量规划等因素,被认为是扩展过程的一个关键方面。Frank和Lisa鼓励客户利用亚马逊云科技提供的丰富的多区域服务和迁移工具,这些工具专门设计用于简化和加速区域扩展之旅。
在整个叙述过程中,Frank和Lisa将亚马逊的多区域战略的错综复杂的线索编织在一起,分享见解、经验教训和实践指导。他们的演讲为着手进行类似旅程的组织提供了一个全面的路线图,阐明了通过战略利用亚马逊云科技区域来提供卓越客户体验的道路。
我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出,企业要从 " 成本优化 " 转向 " 创新驱动 " ,通过完善的数据战略和 AI 云服务,把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域,通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验,助力企业在 AI 时代突破。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70038688/viewspace-3090319/ ,如需转载,请注明出处,否则将追究法律责任。