回顾系列
- 回顾 01:Coinbase re:Invent 回顾 (IND3312)
- 回顾 02:利用 AI 和 AWS 构建未来交易平台
- 回顾 03:交易创新:Jefferies 基于 Amazon Bedrock 构建的 AI 助手 (IND3315)
- 回顾 04:FSI 如何通过 Agentic AI (GBL302) 彻底改变 HFT 分析
- 回顾 05:使用 Amazon Time Sync 改进分布式系统(采用 Nasdaq)
- 回顾 06:Amazon Aurora HA 和 DR 全球弹性设计模式 (DAT442)
- 回顾 07:构建智能体式 AI:Amazon Nova Act 与 Strands Agents 实践 (DEV327)
- 回顾 08:深入探讨 Amazon Aurora 及其创新 (DAT441)
- 回顾 09:深入探讨 Amazon S3(STG407)
- 回顾 10:Nasdaq:为全球金融服务构建弹性基础设施 (HMC327)
- 回顾 11:AWS Lambda 新功能 (CNS376)
- 回顾 12:使用 Kiro 进行规范驱动开发 (DEV314)
- 回顾 13:Amazon 的 FinOps:全球电商巨头的云成本管理经验 (AMZ308)
- 回顾 14:AWS 上交易平台的 Tick-to-Trade 延迟
场次笔记
NASDAQ 的云之旅与弹性系统架构
- 为金融服务构建弹性、高性能系统。
- 概述 NASDAQ 的云之旅、灾难恢复策略、混合基础设施解决方案、架构考量和未来展望。
- NASDAQ 背景:
- 电子交易所领域的先驱,在全球运营超过 30 家交易所。
- 为超过 130 个市场提供软件,包括交易、清算、风险管理和反金融犯罪解决方案。
- 以传统托管软件、托管服务和 SaaS 的形式提供解决方案。
- 云之旅:
- 始于 15 年前,逐步迁移撮合引擎和市场系统等关键系统。
- 从 T+1 备份发展到处理超低延迟事务的硬实时系统。
- 从关键性较低的系统转向对国家经济具有系统重要性的系统。
- 挑战:
- 超低延迟事务以微秒和纳秒计量。
- 由于邻近性和延迟方面的考量,对特定物理位置有要求。
灾难恢复策略与混合基础设施
弹性与监管要求
- 极高的弹性目标,客户期望达到 100% 正常运行时间。
- 在全球多个司法管辖区受到监管监督。
- 灾难恢复范围:
- 从备份和恢复到多站点、主动-主动、多区域系统。
- 必须就 RPO 和 RTO 目标达成一致,并了解系统如何应对灾难。
- 聚焦关键系统:
- 重点关注必须持续运行、不能停机的系统。
- 使用 Outposts 的混合计算、故障域、静态稳定性和断连运行。
- 使用 Outposts 的混合计算:
- 使用 Outposts 将工作负载放置在数据中心,同时通过 EC2 API 和 Amazon 基础设施进行管理。
- 使用 Direct Connect 线路连接区域与数据中心。
- 在数据中心机架中使用 EC2 服务器,并将其作为服务进行管理。
- 为市场系统添加超低延迟网卡。
- 实施裸机服务器和网络,实现物理上完全分离的数据平面。
- 裸机服务器
- 一种物理单租户服务器,使客户能够直接、独占地访问所有硬件资源;这不同于通过虚拟机监控程序共享硬件的虚拟服务器。这种设置可提供最高性能、稳定一致的 I/O 以及对软件栈的完全控制,因此非常适合高性能计算、游戏或 AI/ML 等高要求应用,以及需要物理隔离或特定硬件配置的工作负载。
故障域与静态稳定性
故障域
- 使用故障域概念来理解系统组件之间的共同命运。
- 运行软件的 EC2 服务器具有多个实例和热备(预置的 EC2 实例),以实现冗余。
- 每个软件组件都采用 AB 配对,确保备份组件不会共置于同一实例。
- 机架级故障域:
- 考虑潜在的机架级故障(例如断电)。
- 机架级故障:整个服务器机架因断电、冷却故障、网络交换机故障或物理损坏而离线,影响其中的所有服务器。
- 使用多个机架,并将软件组件的 AB 配对分散在不同机架上,以避免两个组件同时丢失。
- 站点级故障域:
- 数据中心采用多个物理站点以确保弹性。
- 美国市场的主站点位于新泽西州,辅助站点位于芝加哥。
- 静态稳定性:
- 使用热备(预置的 EC2 实例),确保备份资源立即可用。
- 将软件组件的 AB 配对分散在不同机架和站点,以便在发生故障时维持系统完整性。
- 热备:
- AWS 上的预置 EC2 实例主要通过 EC2 Auto Scaling warm pools 功能实现。此功能允许您维护一个实例池,在应用程序需要横向扩展时立即投入服务。
- 灾难恢复 (DR) 策略:warm pools 是“温备”或“指示灯”灾难恢复策略不可或缺的一部分
- 更快扩展:warm pool 中的实例已经预初始化,这意味着耗时的应用程序启动和配置流程已经运行完毕。
静态稳定性与断连运行
静态稳定性
- 使用静态稳定性概念确保系统在中断期间保持弹性。
- 使用热备(预置的 DC2 实例),避免故障期间依赖 EC2 控制平面。
- 目标是在中断期间无需变更即可维持系统功能,并依靠预配置的资源。
- 断连运行:
- 为与 AWS 服务的连接可能中断的场景(例如光缆损坏)做好准备。
- 确保市场系统在此类事件期间无需依赖外部服务也能继续运行。
- 使用热备和预配置资源,在断连场景中维持功能。
- 运维运行手册:
- 必须为各级故障域制定明确的运维运行手册。
- 应对服务器、机架和站点级故障的程序应经过编排,并为运维人员所熟悉。
- 目标是以可预测且经过充分演练的方式应对灾难,尽量减少实际事件中的意外。
断连运行与测试
断连运行
- 为失去 AWS 服务连接的场景(例如网络线路被切断)做好准备。
- 使用本地网关进行紧急访问,以便在不依赖外部服务的情况下本地管理系统。
- 了解可能需要外部连接的内部依赖项和操作,确保对其进行处理或规避。
- 测试故障模式:
- 通过长时间断开 Outposts 连接进行全面测试,以观察系统行为。
- 识别并处理停机期间可能失败的操作(例如 SSL 检查、IAM 交互)。
- 确保即使出现区域或服务链路问题,本地网关仍可访问。
- 策略总结:
- 在数据中心使用 Outposts 实现混合计算。
- 分析故障域,以了解组件的相互依赖关系和共同命运。
- 针对静态稳定性进行设计和测试,以便在中断期间无需变更即可维持系统功能。
- 专注于断连运行,确保系统在与 AWS 服务断开连接时仍可在本地继续运行。
- 强调通过周密规划、明确的运维运行手册和广泛测试来实现弹性,并避免灾难期间出现意外。
- 紧急访问
- 一种安全措施,允许获授权人员绕过正常访问控制,紧急访问关键系统、数据或功能。该术语源自打破玻璃以使用火灾报警器等应急设备的概念。它是一种故障安全协议,在因安全漏洞、系统故障或密码锁定等事件导致标准方法失效时使用。紧急访问账户已预先配置高权限,但在紧急情况发生前会受到安全保护并保持休眠;其使用应受到严格监控并记录。
- 紧急访问:发生危机且标准访问方法不可用时。
- 绕过控制:这些账户旨在绕过正常的身份和访问管理 (IAM)。
- 高级权限:这些账户已预先配置提升的权限。
- 严格管理:为防止滥用,紧急访问凭证受到极其谨慎的管理。
未来方向与增强
动态部署
- 规划使用基于规则的设置进行更动态的部署。
- 使用亲和性和反亲和性模式来平衡性能与弹性。
- 反亲和性模式是云/虚拟化环境(如 Kubernetes、VMware、OpenStack)中的规则,可防止特定工作负载(VM、Pod)共同运行在同一物理主机或同一故障域中。它通过分散工作负载来确保高可用性、容错能力和负载均衡;与此相对,亲和性会尝试将对象共置以提升性能。
- 目标是随着市场迁移到公有云,在不停机的情况下扩展系统。
- 高级硬件实验:
- 使用 Graviton 4 的体验良好,并与 Amazon 合作开发下一代 CPU。
- 测试适用于 Graviton 的超低延迟网卡及其他进展。
- 探索使用 FPGA 和 GPU 进行实时风险分析的加速计算。
- FPGA(现场可编程门阵列)是一种可重新配置的集成电路,制造后可通过编程执行广泛的数字逻辑功能。
- 扩展 Outposts 能力:
- 希望将更多高级组件(定制芯片、FPGA、GPU)引入 Outposts。
- 向第三方销售系统,旨在提供更多功能和服务。
- 谨慎集成服务:
- 谨慎地为 Outposts 添加更多服务,并与服务团队进行深入研究。
- 专注于了解故障模式,并确保高服务可用性和功能完备性。
- 结论:
- 持续努力增强系统弹性、性能和可用性。
- 强调通过细致规划、测试以及与 AWS 协作来实现未来目标。
- 感谢观众的参与,并鼓励填写表单以获取更多信息。
位于 Nasdaq 数据中心内的 AWS Outposts,用于支持超低延迟交易操作。其
主要组件及其功能如下
- AWS Cloud 和 Region:标准 AWS 环境,在多个相互隔离的 Availability Zone (AZ) 中提供服务。
- AWS Direct Connect:将 Nasdaq 数据中心连接到主要 AWS 区域的专用私有网络连接,用于控制平面和服务链路连接,以管理 Outposts。
- Nasdaq Data Center(本地):托管 AWS Outposts 的物理位置,使工作负载能够在本地运行,以满足低延迟和监管合规要求。
- AWS Outposts:部署在 Nasdaq 数据中心内,是完全托管的 AWS 计算和存储容量,将 AWS 基础设施、服务和 API 扩展到本地环境。
- 配备 Nitro 和 ULL NIC 的 Amazon EC2 Instances:运行交易应用程序的计算实例。它们利用 AWS Nitro System 提升性能和安全性,并使用超低延迟 (ULL) Network Interface Card (NIC) 来满足金融交易的严格延迟要求。
- Local Gateway:Outpost 的这一组件将本地网络连接到 Outpost VPC 子网内的实例,促进与现有 Nasdaq 基础设施的通信。
Nasdaq 网络
- ULL 交易网络:专为超低延迟设计的物理独立网络,直接与 EC2 实例上的 ULL NIC 连接,以便快速处理事务。
