高盛集团：零停机时间之旅

## 视频 <video src="https://dev-media.amazoncloud.cn/30-LibaiGenerate/31-LiBaiRebrandingVideo/FSI310-Goldman_Sachs__The_journey_to_zero_downtime-LBrebrandingWCaptionCN.mp4" class="bytemdVideo" controls="controls"></video> ## 导读 高盛集团的交易银行平台每天要处理价值数十亿美元的交易，同时满足客户对不间断正常运行时间的期望。本讲座将分享高盛集团如何通过一个复杂的、不断发展的平台，维持全天候可用的实时支付系统。查看平台的架构，该架构依赖于基于 Amazon Fargate、[Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) Synthetics、Amazon CodeDeploy、Amazon-MSK、Amazon Lambda 和 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 的 [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail)，以最大限度地减少停机时间。探索银行的自动化部署解决方案，该解决方案减轻了运营损害，并限制了不可预见事件的影响范围。 ## 演讲精华 <font color = "grey">以下是小编为您整理的本次演讲的精华，共1500字，阅读时间大约是8分钟。如果您想进一步了解演讲内容或者观看演讲全文，请观看演讲完整视频或者下面的演讲原文。</font> 实现任务关键型应用零停机时间的目标是一个复杂的过程，尤其是对于高度分布式的系统和事件驱动的架构。然而，在高盛公司在亚马逊云科技re:Invent2022上的一场名为“高盛:迈向零停机时间”的演讲中，演讲者们提供了宝贵的实际见解和策略来应对这一挑战。 在演讲开始时，演讲者们询问观众是否有实施零停机架构感到困难。大多数人都举起了手，这表明构建这样的弹性系统确实是各行各业企业面临的普遍障碍。演讲者们承诺在会议结束时，将为与会者提供可操作的技巧，利用各种亚马逊云科技服务和功能来应对他们的特定背景和组织。 第一位演讲者Manjula介绍自己是亚马逊云科技的高级解决方案架构师，专注于为金融服务客户提供战略建议，以利用多种亚马逊云科技云服务构建高可用系统。她强调，她与高盛的交易银行团队紧密合作了2.5年，共同经历了长达18个月的零停机时间之旅。 Manjula按照议程继续介绍，他们将首先确立问题陈述和动机。接下来，概述高盛交易银行业务及其可用性需求。然后，演讲者们将详细说明使用各种亚马逊云科技服务来缓解停机时间所部署的具体架构和策略。他们还将在追求零停机时间的过程中分享关键指标、取得的胜利、学到的教训和规划的未来改进。 Manjula从问题陈述开始，她将零停机时间定义为在维护、发布、升级或其他变更过程中，关键应用能够正常运行而不受干扰。她强调了四个主要因素推动了企业对零停机时间的日益增长的需求和追求：抵御不可避免的系统故障的能力，正如亚马逊云科技首席技术官沃纳·弗奥格斯的著名名言“一切都在不断失败。”因此，解决方案必须解决并从中恢复，如自然灾害甚至整个地区的服务中断。 其次，保持全天候可用性对于维护客户信任至关重要，因为任何停机时间都可能对企业和客户产生严重影响。高盛的系统必须始终保持弹性并在运行状态，以便不间断地为客户提供服务。 第三，企业有责任遵守严格的服务水平协议（SLA），因为他们要向客户做出承诺。因此，大多数公司都在构建多区域高度可用的架构和故障切换机制方面进行了大量投资。 最后，避免由于客户不满意或缺乏可用性而导致的企业信誉损失和收入损失是非常重要的。像高盛这样的企业无法承受停机时间，因为这会直接损害他们的业务。 接下来，Manjula邀请了Rob Carson，高盛交易银行团队的副总裁和技术研究员，详细介绍他们的具体业务和可用性需求。 Rob解释说，高盛的交易银行业务为企业客户提供基本的银行服务，如支付、存款、交易处理和分析。该业务于2018年开始运营，作为一个完全在亚马逊云科技上建设的绿色项目，除了一些必要的原有设施集成。 交易银行业务平台由高盛数百名工程师维护，包括数百个微服务。他们的恢复点目标为零，因为任何支付损失都是不可接受的。数据库失败的恢复时间目标小于2分钟。 最重要的是，他们每年在微服务中执行数千次部署，如果不妥善处理，可能会导致停机时间。Rob强调，除了基础设施问题外，停机的主要原因还有部署错误和失败。因此，平台团队有意识地将平滑的部署过程与可用性要求相结合，使用亚马逊云科技的CodeDeploy的蓝色/绿色部署功能。 提供指标，Rob指出他们在交易银行业务平台上每天处理数百亿的交易。他强调了实时支付或RTP铁路的需求，其正常运行时间需要达到99.5%，并根据行业法规有一个紧实的周日2-6 AM维护窗口。这进一步激发了他们在部署过程中追求高可用性的愿望，以满足合规要求并避免收入损失。 接下来，Rob从客户接口（如API、网站和文件传输）入手，详细介绍了该平台的各个组成部分。在交易进入关键支付流程的过程中，会进行多种验证，包括欺诈检查和余额充足性检查。最终，通过使用亚马逊云科技Lambda和[Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail)等适当的支付轨道来处理付款。 通过有意识地将系统分层，关键客户接口和支付流程与不太重要的后端组件（如分类帐和报告）相互隔离。这种分离使得每个组件的关键性得以根据高可用性策略进行调整。 接着，Rob详细阐述了他们的高可用性架构方法的核心原则： 首先，强烈建议采用不可变的ECS任务而非EC2实例。这样，每次可靠地启动时，容器都能保持一致性地避免在EC2主机之间出现配置偏差。这有助于实现一致性并提供弹性。 其次，用于部署ECS、Aurora数据库和其他组件的基础设施即代码模块是重复使用的。这实现了环境设置的标准化，并融入了可用性最佳实践。他们大量使用了Terraform模块。 第三，每个应用程序都被隔离到其自己的亚马逊云科技账户和没有互联网访问的虚拟私有云（VPC）中。通过私有VPC端点服务实现了跨账户的连通性。服务和端点的目录增强了安全和变更控制。 第四，团队成员独立部署，无需协调。服务通过自定义的零停机发布蓝绿库经理优雅地处理上游依赖项。 最后，自动化和文化使得运营开销最小化。使用亚马逊云科技Lambda、CloudWatch和SAM CLI来实现这一目标。 在微账户的设置过程中，Rob描述了平台团队如何首先配置核心功能，如CloudWatch、加密、与亚马逊云科技可观察性服务的集成以及通过VPC端点访问的Amazon MSK集群等消息传递集成。 随后，开发人员通过可重复使用的基础设施即代码模块部署ECS服务、Aurora PostgreSQL数据库和其他资源。正确配置入口和出口代理以提供受控的外部连接。 因此，开发人员获得了一个统一的、遵循最佳实践的环境，可以专注于应用逻辑和业务问题。与此同时，平台团队确保了可用性、安全性和变更控制的保证。 在探讨跨区域主动-主动扩展时，据Rob表示，由于全球使用场景的特殊性，无法强制执行统一的蓝图。应用程序需要在运行主动-主动或主动-被动（具备故障切换功能）模式之间自行选择。此外，还需考虑诸如亚马逊云科技区域间VPC对等连接等高阶选项。 总之，尽管提供了平台指南，但团队仍需根据应用架构和业务需求做出合适的选择，以实现全球数据复制和灾难恢复策略。 了解这些架构原则后，Rob将任务交给了韧性工程副总裁Akash Pau，请他详细介绍部署策略。 Akash首先将零停机部署视为避免“凌晨2点战争室”事故和非协调跨团队发布的关键。通过采用蓝色-绿色部署模式，可以预先验证并将流量逐步迁移至新版本，从而在技术复杂性及业务发布敏感性之间实现分离。 针对无状态服务如ECS，已使用CodeDeploy的原生蓝色-绿色处理功能。绿色环境用于烟雾测试和新版本的用户，并通过亚马逊云科技CloudWatch Synthetics进行监控。最终，SAM CLI会触发将负载均衡器流量从蓝色切换至绿色。 然而，数百个相互连接的微服务可能引发下游故障级联。为此，开发了自制的蓝色-绿色库管理员来抽象上游协调。库管理员可对ECS版本进行标记，并允许配置版本间的依赖关系。在部署过程中，可自动处理将REST请求和生产中的Kafka消息路由至正确的蓝色或绿色上游。还可借助亚马逊云科技Lambda集成自定义逻辑以满足独特业务需求。 在探讨最佳实践时，Akash倡导进行深度健康检查，而不仅仅是基本的ping和过程检查。这些检查可在部署前验证应用程序的功能，并兼作先锋服务。然而，为避免负载均衡器上频繁的健康检查过载，需进行缓存。对于缺乏负载均衡器的非Web工作负载，可使用伪NLB指向一个模拟服务，以实现在蓝色-绿色下的CodeDeploy。根据消耗时间进行配置，以实现渐进式优雅关闭，防止断开客户端连接。 阿卡斯强调了对技术部署和业务发布决策进行分离的重要性。在基础设施自动化部署绿色版本之前，所有应用程序更改都需要经过严格的审查、批准和标记。安全代码护栏可以防止在生产环境中对绿色的意外修改。在从蓝色切换到绿色之前，会进行多达48小时的测试和金丝雀运行。针对像数据库这样的有状态资源，还会实施蓝绿方案以实现零停机。Aurora PostgreSQL通过快速克隆功能创建临时绿色副本，以确保读取的不间断性。即使在进行蓝色数据库升级期间，写入后置缓存架构也能保持完全可用性。Kafka利用模式历史来确保跨版本的兼容性。尽管DynamoDB的无模式特性避免了类似问题，但仍需谨慎处理以避免删除其他应用程序正在使用的属性。双年游戏日模拟区域故障用于基准恢复过程并增强运行手册。此外，还通过亚马逊云科技故障注入模拟器进行混沌测试，以提高弹性。最终目标是实现完全自动化的零接触发布。简而言之，高盛慷慨地分享了他们在亚马逊云科技上实现交易银行零停机的实际经验。他们提供了有关架构策略和部署技巧的见解，以激发观众的智慧。演讲者成功地实现了他们的目标，即为与会者提供实用的知识，帮助他们开始自己的可用性之旅，并充分利用亚马逊云科技。 **下面是一些演讲现场的精彩瞬间：** ## 总结 该视频探讨了高盛公司在实现其关键交易银行业务应用零停机时间方面的经历。他们在亚马逊云科技上构建了系统，以利用其高可用性功能。重点在于采用具有诸如微服务和基础设施即代码等最佳实践的弹性架构。这实现了独立部署并阻止了级联故障。为了在路由流量之前验证发布，他们使用了亚马逊云科技的CodeDeploy的蓝色/绿色部署方式。这提供了一个用于测试更改的临时环境。同时进行了深度健康检查以确保应用程序运行正常。对于数据库，他们采用了快速克隆技术来创建绿色克隆物以避免停机。此外，他们还采用了一种创新的缓存后置写入方法，以便在数据库部署期间保持可用性。 在这个过程中，高盛公司减少了部署事件并提高了发布信心。获得的关键经验教训包括优雅关闭和测试真实条件的重要性。总之，他们的零停机时间努力已经显著提高了关键银行应用程序的弹性和可用性。这为在亚马逊云科技上构建高可用系统提供了一个很好的范例。 ## 演讲原文 ## 想了解更多精彩完整内容吗？立即访问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 余种核心云服务产品免费试用“")