使用 Amazon Time Sync 改进分布式系统（采用 Nasdaq）

场次笔记

• 引用 Barbara Lipskovoff 的话：同步时钟可以通过减少通信来提高分布式系统的性能。
• 时钟的用途
• 时钟作为统一的度量尺度。
• 分布式系统中的传统用途：不可信，用于人类可观察性。
• 应用：
• 日志消息、指标、监控、UI 仪表板。
• 金融服务、医疗保健、广播媒体、在线游戏等行业的审计。
• 分布式系统有潜力通过可靠的时钟简化操作、减少锁定和领导者选举。

什么是时钟？

构建计算机时钟的基础知识

• 需要定期滴答的东西和对这些滴答进行计数的东西。
• 通常是结合了两种功能的单个硬件。
• 方程表示：
• 在时间 T，时钟 C 可以读取为经过的周期数除以频率和常数。
• 简单示例：
• 如果硬件以每秒 1 个周期的速度计数 1000 个周期，则经过 1000 秒。
• 结论：
• 在计算机上构建时钟的基本组件。

时钟硬件选项

硬件范围

• 从小型晶体振荡器到铯束、氢微波激射器和即将推出的光学时钟等大型设备。
• 外形尺寸从几毫米到机柜大小的设备不等。
• 价位：
• 小外形对于云计算来说更具成本效益。
• 大型设备可能花费数十万美元。
• 质量和准确性：
• 维持一微秒内的时间精度各不相同：
• 外形尺寸小：精确到几秒钟。
• 氢微波激射器和光学钟：可以精确数年，甚至可能数百年。

时钟漂移

所有振荡器都会漂移

• 即使是最精确的原子钟也会出现漂移。
• 在高精度时钟中，微秒级的漂移可能需要几个世纪才能观察到。
• 漂移原因：
• 制造过程、老化（物理学家关心的问题）。
• 对于云提供商：由于工作负载对 CPU 和服务器的影响，电源或温度变化存在微小差异。
• 漂移的影响：
• 周期频率随时间变化，导致时钟漂移。
• 示例：运行 5 天的 EC2 实例在未经校正的情况下出现了 75 毫秒的漂移。
• 解决时钟漂移问题
• 跟踪和纠正：
• 与人类调整手表类似，计算机需要跟踪并纠正漂移。
• Network Time Protocol（NTP）：
• 几十年来一直用于同步时钟。
• 涉及客户端时钟向服务器（参考时钟）发送消息以调整时间。

时钟同步的挑战

需要持续调整

• 时钟周期的频率不断变化。
• 需要反复询问正确的时间，而不仅仅是一次。
• 网络通信问题：
• 通过网络交换的消息有不同的延迟。
• 丢弃消息时存在消息失败的风险。

网络是问题的一部分

可行性和延迟

• 嘈杂的通信延迟使得很难辨别实际的时钟漂移。
• 网络不对称：
• 该网络不对称，导致即使使用完美的时钟，观察到的时间也会存在差异。
• 很难区分时钟误差和网络不对称。

AWS 解：Amazon Time Sync Service

• 为客户解决非确定性网络上时钟同步的复杂性。
• 执行：
• 于 2017 年推出。
• 利用 NTP (Network Time Protocol) 端点。
• 全球每个 EC2 实例均可在本地使用。
• 投资：
• 为了在全球范围内支持这项服务，需要进行大量的工程和硬件投资。

Amazon Time Sync Service

基本设置

• 带有 Nitro 系统和软件时间守护进程的 EC2 实例。
• NTP数据包从AWS系统分发到Nitro系统以校正服务器时钟。
• 准确性：
• NTP服务精度：1毫秒以下，一般为500-700微秒。
• 客户利益：
• 轻松、免打扰的服务；客户无需了解底层技术。

纳秒精度的挑战和解决方案

客户需求

• 客户寻求分布式系统的精度高于 1 毫秒。
• AWS 做法：
• 投资硬件以实现纳秒级精度。
• 使用 GPS 的专用电缆和冗余原子硬件时钟。
• 信号 (GPS) 绕过 AWS 网络直接发送到 EC2 实例。
• 专用Clock同步：
• 用于时钟同步的信号完全是专用的，不通过数据或控制平面。

基于Nitro的系统

• Nitro时钟：硬件参考时钟。
• NTP 数据包通信：直接发送到 Nitro 卡并返回，不经过网络。
• PTP 硬件时钟：
• 在Nitro系统中添加Precision Time Protocol（PTP）硬件时钟。
• 用户读取PTP硬件时钟（PHC）来本地校正系统时钟。
• 准确度等级：
• NTP：软件级别低于 100 微秒。
• PTP：软件级别大约 20 微秒。
• 广泛实施：
• 跨各种服务器类型（Graviton、Intel、AMD、GPU）添加的参考 PTP 硬件时钟。
• 基于Nitro系统硬件，支持全球基础设施投资。

硬件数据包时间戳

主要应用和优点

目的

• 为网络数据包添加时间戳实现纳秒级精度。
• 好处：
• 提高了分布式工作负载网络性能的可观察性。
• 允许以纳秒分辨率对服务器接收的消息进行排序。
• 驱动程序中的内置设施，可通过经典套接字 API 或 DPDK 工具包进行访问。

它是如何运作的

功能发布前

• 应用层时间戳：
• 消息到达，经过Nitro系统，到达实例。
• 应用程序从系统时钟读取时间并将时间戳附加到消息。
• 使用套接字 API 使用 4 行 C 代码。
• 功能发布后（硬件数据包时间戳）：
• Nitro系统和Nitro时钟：
• 消息到达，数据包在到达实例之前由 Nitro 系统和 Nitro 时钟加盖时间戳。
• 带时间戳的消息被传递到应用层。

实施和访问

访问方法

• 经典插座 API。
• DPDK (Data Plane Development Kit) 工具包，用于绕过内核基础设施直接进行数据包访问。
• 解决：
• 为网络数据包的接收时间戳提供纳秒分辨率。

示例比较

前

• 简单的过程涉及在消息接收后从系统时钟读取时间。
• 后：
• 在消息到达应用程序之前由硬件完成数据包时间戳的增强处理，提供更准确的时间戳。

硬件数据包时间戳的增强优势

提高准确性

• 提供更准确的网络性能视图。
• 示例：测量两个实例之间的往返时间。
• 用户空间应用程序测量：~400 微秒。
• 硬件数据包时间戳测量：~100-150 微秒。
• 可观察到的差异：
• 约 250 微秒的差异归因于操作系统和网络堆栈所花费的时间。
• 约占往返时间的2/3，凸显更精确的可观测性。
• 更清晰的网络性能：
• 允许识别和分解应用程序和网络之间的延迟。

NASDAQ用例介绍

客观的

• 展示NASDAQ使用AWS的精确时间技术在公共云环境中运行市场的进展。

NASDAQ 背景

金融市场的创新者

• 世界上第一个电子交易所，创建于 1971 年。
• 运营全球 30 多个市场，包括股票、债券、期权和衍生品。
• 以拥有市值最高的科技公司而闻名，其中包括亚马逊。
• 技术提供商：
• 为130多家市场运营商和2300家金融机构提供服务。
• 支持全球 NASDAQ 交易所上市的超过 44,400 家上市公司。
• 为 6000 家企业提供资本市场生命周期支持技术。

NASDAQ的云之旅

10多年前开始

• 开始使用 AWS Redshift 进行数据存储库和数据仓库（2012-2013 年）。
• 目前存储约 60 PB 的数据，支持后台功能。
• 向实时处理的演变：
• 使用流式实时市场信息进行市场监控。
• 通过公共云提供市场数据分发。
• AWS Outpost 上线期权交易所：
• 2022年，在AWS Outpost上推出NASDAQ MRX。
• 目前在 Outpost 上运行 6 个以上的市场系统。
• 公共云中的关键系统：
• 托管系统为市场参与者提供实时见解。
• 利用云可扩展性、性能和适当的规模来实现大消息量和峰值管理容量。

迁移到云的具体挑战

地理限制

• 股票和股票期权交易主要发生在新泽西州北部。
• 延迟依赖性需要将计算机部署在特定位置。
• 超低延迟事务：
• 交易的订单执行时间约为 20 微秒。
• 高消息量：
• 每天处理超过 1000 亿条消息。
• 特定的交换系统每秒处理多达 2-3 百万条消息。
• 高弹性和正常运行时间期望：
• 对于高效且运作良好的资本市场至关重要。
• 众多上市公司的主要上市地点。

NASDAQ交换系统架构

匹配引擎

• 处理预订订单、交易以及匹配买家和卖家的主要逻辑。
• 订购端口：
• 客户向交易所发送订单流的接口。
• 执行验证、交易前风险和其他功能。
• 公开市场数据源：
• 发布与市场匹配的引擎活动的视图（例如，NASDAQ I）。
• 客户：
• 通过入站交易向订单端口和撮合引擎提供订单流。

传统的本地模型

客观的

• 为参与者提供确定性且统计上公平的市场。
• 对身体特征的依赖：
• 数据中心光纤的长度。
• 系统组件和客户之间的交换机跳数。
• 网络延迟的来源：
• D1 和 D2：
• 物理设置导致的网络延迟的主要来源。
• D3：
• 包含网络和处理组件。
• 大约一半的往返延迟，大约 10 微秒。
• 有序处理：
• 匹配引擎的顺序处理确保客户提交的订单得到一致且可重复的处理，并返回给他们和公共市场数据源。

公共云的挑战

• 不可预测的网络状况。
• 没有固定的电缆长度或已知的交换机跳数。
• 其他网络流量或不可预测的节点放置造成的潜在延迟。

解决方案：硬件时间戳和重新排序缓冲区

关键时间段

• 重点关注 D1、D2 和 D3 以了解通过网络的交易时间。
• 硬件时间戳：
• 使用纳秒精度记录每个网络点的每笔交易的时间。
• 通过 Nitro 和 Amazon Time Sync Service 提供。
• 重新排序缓冲区：
• 位于匹配引擎前面。
• 专注于对入站交易进行排序（类似的技术适用于出站流）。
• 基于时间的边界：
• 使用硬件时间戳进行定义（例如，对于来自客户的订单，T1、T2、T3）。
• 确保交易按照其发起的顺序进行处理。
• 专利技术：
• 这是 NASDAQ 向低延迟系统公共云发展的基础。

原型和实验

使用的 AWS 实例

• M7I.2XL 实例。
• 邻近放置组：
• 确保计算节点在几个机架或同一机架内紧密放置。
• 用于重新排序的硬件时间戳：
• 用于根据时间戳对数据包重新排序。
• 时间限制测试：
• 5 微秒边界重新排序了约 25% 的数据包。
• 50 微秒边界重新排序了 84% 或更高的数据包。
• 迭代与演化：
• 继续致力于邻近放置功能和 Amazon Time Sync Service 以获得更大的粒度。

战略愿景

可扩展的交易系统

• 旨在开发可扩展的高性能系统，无论是部署在公共云还是本地。
• 公共云创新：
• 拥抱云创新，包括AI和数据迁移到公有云。
• 增强的安全性和可靠性：
• 对可用性、安全性和可靠性抱有很高的期望。
• 如果以负责任的方式构建并考虑到弹性，公共云将具有显着的优势。
• 利用市场专业知识：
• 作为在全球运营 30 个交易所并向 130 个市场提供技术的领导者，NASDAQ 对技术应用进行战略性思考。

在软件中利用高精度时钟

• 强调使用同步时钟减少分布式系统中的通信。
• AWS 时间同步服务：
• 在软件中提供具有微秒精度的纳秒范围时钟。
• 硬件数据包时间戳：
• 使应用程序能够受益于更准确的计时，从而增强性能和可观察性。

分布式系统的挑战

多个时钟

• 分布式系统有多个服务器，每个服务器都有自己的时钟。
• 时钟并非完全同步，导致事件排序变得复杂。
• 传统解决方案：
• 分布式锁、领导者选举和用于排序的共识算法。
• 随着系统的增长，这些算法限制了性能并增加了复杂性。

时钟不确定性和误差范围

人的视角

• 人类认为时间是精确的（例如下午 2 点），但时钟具有不确定性。
• 精度Clocks：
• 软件层中的AWS精密时钟具有不确定性（例如±20微秒）。
• 应用中的误差范围：
• 应用程序必须考虑到这个误差范围。
• 示例：银行账户交易需要正确排序以避免透支。

估算时钟不确定性

复杂的问题

• 客户需要了解其时钟的不确定性间隔。
• 例子：
• 检查 EC2 实例上的时间同步守护进程以估计错误。
• 时间同步来源：
• 互联网 NTP 服务器（例如 time.aws.com）：约 395 微秒的不确定性。
• 通过 Nitro 系统的本地 NTP 服务器：约 90 微秒的不确定性。
• PTP硬件时钟（通过Nitro系统增强Amazon Time Sync Service）：更准确。

AWS 简化

• AWS 旨在简化客户对时钟不确定性的理解和管理。
• 提供详细的解释来帮助客户，而不需要深厚的技术知识。

AWS Clockbound 软件

目的

• 简化客户对时钟不确定性的理解和管理。
• 可用性：
• 开源，自 2021 年起在 GitHub 上可用。
• 主要特点：
• 在一次操作中提供三条信息：
• 当前时间：例如，周一下午 2:00
• 不确定性窗口：例如，±20 微秒。
• 时钟状态：已初始化、自由运行或已同步。
• 支持与可扩展性：
• 支持 PTP 硬件和 NTP 源。
• 可扩展到要求苛刻的工作负载，每秒能够处理数百万次查询。
• 语言和兼容性：
• 为了性能和内存安全而用 Rust 编写。
• 可在 RSS 中作为云和 C 应用程序使用。

时钟误差界限

• 由于振荡器漂移和通信延迟而导致的最坏情况时钟误差的最严格限制。
• Clockbound的作用：
• 尽管存在累积误差，仍能提供准确的答案，在纳秒和微秒级精度场景中大放异彩。
• YugabyteDB Clockbound的用法
• 该开源数据库采用 AWS 的开源 Clockbound 软件。
• 混合逻辑时钟系统：
• 将传统逻辑排序与精密时钟相结合。
• 观察到的好处：
• 减少延迟：客户体验到的延迟减少了 3 倍。
• 吞吐量增加：交易吞吐量翻倍。
• 更少的重试：由于事务之间的冲突（例如读取和写入）减少，重试次数减少了 1000 倍。
• 改善客户体验：
• 增强数据库的一致性、隔离性和整体用户体验。

AWS 对精密时钟的使用

使用精密时钟的服务

• Aurora DSQL：多区域、全球规模的数据库。
• Dynamo DB Global Tables：多区域、全球规模的数据库。
• 使用原因：
• 跨区域的网络延迟（例如，US West 2 和 US East 1 之间为 70 毫秒）。
• 精密时钟的优势：
• 微秒至纳秒级时钟能够比通过网络发送数据包更快地完成事务排序。

AWS 在 Aurora DSQL 中使用精密时钟

多区域数据库一致性

• 对于维持多区域数据库的一致性和隔离性至关重要。
• Clockbound 的不确定性窗口：
• 用于管理跨不同区域的事件。
• 示例：与事件 2 或 3 相比，事件 1 保证是过去的事件。
• 事件 2 和 3 有重叠，需要仔细处理以避免重试。
• 可能的解决方案：
• 推迟事件（例如事件 3）的开始时间以避免重试。
• 数据库设计注意事项：
• 取决于系统设计、事件类型和客户要求。

新 EST 守护进程发布

目的

• 为客户简化高级计时功能的使用。
• 改进：
• 构建在与现有 Clockbound 软件相同的软件堆栈下。
• 显着改进，提高了准确性和可靠性。
• 客户信任：
• AWS 旨在随着时间的推移维持和改善客户信任和体验。
• 独立时间客户端：
• Clockbound 现在包括独立的时间客户端和守护程序。
• 同步和信息提供：
• 同步操作系统时钟。
• 向应用程序提供当前时间、不确定性窗口大小和时钟状态。
• 监管和可观察性原因：
• 对于法规遵从性和系统可观察性非常重要。
• 内置指标和可观察性：
• 可观测性是一等公民，并提供内置指标。
• 高性能与内存安全：
• 基于相同的 Rust 软件堆栈构建，以实现内存安全和高性能。
• 通过用于进程间通信的共享内存段实现高性能。

云优先设计范式转变

• 重新设计系统以云优先。
• 从传统的反馈循环系统转向前馈信息系统，更适合云应用程序。
• 测试模拟器
• 新的软件堆栈附带了一个模拟器。
• 允许用户测试软件、报告问题并提出改进建议。
• 云原生同步
• 可用性是所有虚拟化层的首要任务。
• 为Linux内核贡献了一个新功能，称为VM时钟（虚拟机时钟）。
• 与新发布的 Clockbound 结合：
• 允许将时间从 Nitro 时钟直接传输到实例中。
• 提高维护事件期间的性能，确保工作负载平稳运行。
• 新系统的性能
• 该系统设法在多个小时内跟踪和纠正漂移，使其误差在±1微秒之内。
• 不确定性之窗：
• 通过查询 Clockbound 守护程序绘制的不确定性窗口的大小。
• 锯齿行为：随着时钟更新而增大和缩小。
• 实现的不确定性窗口：应用程序内 20 到 26 微秒之间。

新泽西州北部的股票和期权意义重大，因为它作为主要金融数据中心（如锡考克斯的 Equinix）为 Wall Street 交易提供动力，邻近地区吸引了金融专业人士，并且当地经济强劲，NJR 等公司提供稳定的股息，所有 拥有强大的基础设施和通往 NYC 的通勤网络的支持，创造了多元化的投资

从高科技数据中心到成熟公司的景观。

为什么 Northern NJ 是股票和期权的中心

• 数据中心动力中心：Secaucus，NJ，托管对高频交易至关重要的关键数据中心（如 Equinix NY4），将活动从曼哈顿转移，并使 NJ 成为金融科技的中心位置。
• NYC 邻近性：良好的交通（火车、渡轮）将 NJ 与 NYC 连接起来，吸引了金融专业人士，使其成为曼哈顿金融区工作人员的主要居住区，从而促进了卑尔根县和哈德逊县等地的当地经济。
• 强大的本地公司：新泽西州拥有新泽西资源公司（NJR）等老牌公司，这些公司对注重股息的股权投资者具有吸引力，以一致的股息和价值指标而闻名。
• 投资生态系统：该地区受益于强劲的房地产升值（一种股权形式）、稳定的需求以及由 NJEDA（新泽西州经济发展局）支持的不断发展的“创新生态系统”，促进了传统和技术驱动的投资。
• 税收和监管环境：新泽西州有具体的法规，例如非居民股票期权收入的法规，表明其复杂的金融监管框架会影响投资者。
• 这对投资者意味着什么
• 数据和技术重点：技术相关领域和支持金融的数据基础设施存在机会。
• 价值和收入：寻找位于该州或附近的稳定、支付股息的公司以及房地产投资（房地产股权）。
• 通勤者吸引力：通往 NYC 的通勤交通便利的地区（例如卑尔根县的威霍肯）需求量很大，代表着房地产市场的强劲发展。

Equinix 位于新泽西州锡考克斯的园区（NY2、NY4、NY5、NY6）是 Wall Street 至关重要的低延迟枢纽

提供与主要金融交易所和交易生态系统的直接连接，

容纳众多金融公司，并为企业提供高安全性、可靠的主机托管

高频交易 (HFT) 和道琼斯新闻推送等基本数据服务，确保

速度和接近市场。这些设施充当数字骨干网，使公司能够

将他们的服务器放置在靠近交易所的位置以加快交易速度。

为什么它对 Wall Street 很重要

• 低延迟：物理上靠近交换机可最大限度地减少数据传输时间，这对于 HFT 至关重要。
• 市场准入：与交易场所、数据提供商（如道琼斯）和其他金融参与者的直接连接。
• 可靠性：采用强大的电源、冷却和安全性设计，可实现不间断的财务运营。

Amazon Aurora HA 和 DR 设计模式实现全球弹性

(DAT442)

弹性定义

• 工作负载从中断中恢复的能力
• 涉及资源的动态获取和中断缓解
• 高可用性 (HA)：
• 工作负载可用的时间比例
• 历史测量（例如，5 个 9 可用性）
• 灾难恢复 (DR)：
• 事故发生后恢复工作量的技术
• 恢复时间目标 (RTO)：恢复服务的最长时间
• 恢复点目标 (RPO)：可接受的最大数据丢失
• 重点关注 Aurora：
• Aurora PostgreSQL (APG) 和 Aurora MySQL (AMS)
• 类似的功能和弹性能力

高可用性（HA）

• 目标：保持系统持续运行，最大限度地减少中断，并避免单点故障。
• 方式：冗余、自动故障转移、负载平衡，通常在同一数据中心或区域内。
• 示例：具有多个实例的 Web 服务器、一个节点发生故障时自动切换的数据库集群。
• 重点：对常见的小问题（例如硬件故障、维护）进行容错。
• 灾难恢复（DR）
• 目标：在重大灾难（自然灾害、大规模数据损坏）后恢复业务运营。
• 方式：备份、复制、异地数据中心、定义的恢复过程 (RTO/RPO)。
• 示例：从云备份恢复数据，在区域中断后故障转移到辅助区域。
• 重点：抵御大规模灾难性事件的能力。
• 主要区别和关系
• 范围：HA处理小故障； DR 处理大的。
• 做法：HA 积极主动； DR 是反应性的。
• 整合：它们是互补的；强大的 HA 减少了对 DR 的需求，而 DR 在 HA 不够用时提供了终极安全网。

如果我的数据库节点出现故障怎么办？

自我管理数据库

• 具有组合数据库引擎和存储的单节点
• 备份期间潜在的性能问题
• RPO可能高达24小时
• 如果节点失败，RTO 可能会持续很多小时：
• Aurora 耐久性：
• 从一个可用区中的单个数据库集群开始
• 利用Aurora存储进行数据复制
• 节点分布在 3 个 AZs 的多租户存储队列
• 每次写入在 3 个 AZs 上复制 6 次
• 用户只需支付一份副本的费用
• RPO为0，无异步复制
• Aurora 仅写入日志记录，而不写入页面，从而增强了耐用性和性能
• Aurora 中的备份和恢复：
• 存储引擎持续将数据备份到S3，而不影响性能。
• 时间点恢复 (PITR) 可以从最早的可恢复时间（最多 35 天）到最晚（对于繁忙的数据库，大约 5 分钟前）。
• 恢复过程包括从 S3 提取数据、应用内部日志记录以及启动事务恢复引擎。
• 数据库实例可用性：
• 基本配置包括一个实例；故障需要10-15分钟更换。
• 添加备用实例提高可用性； Aurora 使其与主数据库保持同步。
• 故障转移到备用实例在几秒钟内就会发生，并保持相同的大小和负载容量。
• 导致 RPO 为 0，RTO 通常约为 30 秒，从而实现多 AZ 可用性模式。

性能弹性

• 性能可能会根据应用程序需求而波动，从而导致潜在的资源浪费。
• 开源解决方案提供纵向扩展（硬件升级）或横向扩展（将数据库分成多个部分），这对一致性和嘈杂的邻居都提出了挑战。