透過 Amazon Time Sync 改善分散式系統，Nasdaq 專題分享

場次筆記

• Barbara Lipskovoff 引言：同步時鐘可藉由減少通訊來改善分散式系統效能。
• 時鐘的用途
• 時鐘作為共同的測量尺度。
• 在分散式系統中的傳統用途：不受信任，用於供人員觀察。
• 應用：
• 日誌訊息、指標、監控、UI 儀表板。
• 金融服務、醫療保健、廣播媒體、線上遊戲等產業中的稽核。
• 在分散式系統中，可靠的時鐘有潛力簡化作業、減少鎖定，以及簡化領導者選舉。

什麼是時鐘？

建置電腦時鐘的基礎知識

• 需要會週期性振盪的元件，以及計算這些振盪次數的元件。
• 通常由單一硬體同時結合這兩項功能。
• 方程式表示法：
• 在時間 T，讀取時鐘 C 所得到的值，可以表示為經過的週期數除以頻率，再加上一個常數。
• 簡單範例：
• 以每秒振盪 1 個週期的硬體計算 1000 個週期，代表經過了 1000 秒。
• 結論：
• 這是在電腦上建置時鐘的基本元件。

時鐘的硬體選項

硬體範圍

• 從小型石英振盪器，到銫原子束、氫微波激射器及即將推出的光學時鐘等大型設備。
• 外型尺寸從幾毫米到機櫃大小的設備不等。
• 價位：
• 小型規格對雲端運算而言更具成本效益。
• 大型設備可能要價數十萬美元。
• 品質與準確度：
• 將時間維持在一微秒內的準確度各不相同：
• 小型規格：可準確維持數秒。
• 氫微波激射器與光學時鐘：可準確維持數年，甚至可能數百年。

時鐘漂移

所有振盪器都會漂移

• 即使最準確的原子鐘也會發生漂移。
• 在高度準確的時鐘中，微秒等級的漂移可能要數百年才能觀察到。
• 漂移原因：
• 製造流程、老化（物理學家關注的問題）。
• 對雲端供應商而言：電源供應的微小差異，或工作負載對 CPU 與伺服器造成影響所引發的溫度變化。
• 漂移的影響：
• 週期頻率會隨時間變化，進而導致時鐘漂移。
• 範例：一個執行 5 天的 EC2 執行個體，在未校正的情況下出現 75 毫秒的漂移。
• 處理時鐘漂移
• 追蹤與校正：
• 就像人類調整腕錶一樣，電腦也需要追蹤並校正漂移。
• 網路時間協定 (NTP)：
• 數十年來一直用於同步時鐘。
• 作法是由用戶端時鐘傳送訊息至伺服器（參考時鐘），以調整時間。

時鐘同步的挑戰

需要持續調整

• 時鐘週期的頻率會持續變化。
• 需要反覆詢問正確時間，而非只詢問一次。
• 網路通訊問題：
• 透過網路交換的訊息會有不同的延遲。
• 訊息遭丟棄時，存在傳送失敗的風險。

網路也是問題的一部分

可行性與延遲

• 雜訊繁多的通訊延遲，使人難以判斷實際的時鐘漂移。
• 網路不對稱：
• 網路並非對稱，因此即使時鐘完美，觀察到的時間仍會有差異。
• 很難區分時鐘誤差與網路不對稱。

AWS 解決方案：Amazon Time Sync Service

• 為客戶解決透過非確定性網路進行時鐘同步的複雜問題。
• 實作：
• 於 2017 年推出。
• 使用 NTP (Network Time Protocol) 端點。
• 全球每個 EC2 執行個體皆可在本機使用。
• 投資：
• 投入大量工程與硬體資源，在全球支援這項服務。

Amazon Time Sync Service

基本設定

• 具備 Nitro system 與軟體時間常駐程式的 EC2 執行個體。
• NTP 封包從 AWS 分發系統經由 Nitro system 傳送，以校正伺服器時鐘。
• 準確度：
• NTP 服務準確度：低於 1 毫秒，通常為 500-700 微秒。
• 客戶效益：
• 簡單且無須介入的服務；客戶不需要瞭解底層技術。

奈秒準確度的挑戰與解決方案

客戶需求

• 客戶希望分散式系統能達到優於 1 毫秒的準確度。
• AWS 方法：
• 投資硬體以實現奈秒等級的準確度。
• 使用 GPS 專用纜線與備援原子硬體時鐘。
• 訊號 (GPS) 直接傳送至 EC2 執行個體，繞過 AWS 網路。
• 專用時鐘同步：
• 時鐘同步訊號完全專用，不經過資料平面或控制平面。

Nitro 型系統

• Nitro 時鐘：硬體參考時鐘。
• NTP 封包通訊：直接送至 Nitro 卡再返回，不涉及網路。
• PTP 硬體時鐘：
• 在 Nitro system 中加入 Precision Time Protocol (PTP) 硬體時鐘。
• 使用者讀取 PTP 硬體時鐘 (PHC)，在本機校正系統時鐘。
• 準確度等級：
• NTP：軟體層級低於 100 微秒。
• PTP：軟體層級約 20 微秒。
• 廣泛實作：
• 在各種伺服器類型（Graviton、Intel、AMD、GPU）中加入參考 PTP 硬體時鐘。
• 以 Nitro system 硬體為基礎，支援全球基礎設施投資。

硬體封包時間戳記

主要應用與效益

用途

• 為網路封包加上時間戳記時，可達到奈秒等級的準確度。
• 效益：
• 改善分散式工作負載的網路效能可觀察性。
• 能以奈秒解析度排列伺服器所接收訊息的順序。
• 驅動程式中的內建功能，可透過傳統 socket API 或 DPDK 工具組存取。

運作方式

功能發布前

• 應用程式層時間戳記：
• 訊息抵達、通過 Nitro system，然後到達執行個體。
• 應用程式從系統時鐘讀取時間，並將時間戳記附加至訊息。
• 使用 socket API，以 4 行 C 程式碼完成。
• 功能發布後（硬體封包時間戳記）：
• Nitro system 與 Nitro 時鐘：
• 訊息抵達後，在到達執行個體之前，由 Nitro system 與 Nitro 時鐘為封包加上時間戳記。
• 已加上時間戳記的訊息會傳遞至應用程式層。

實作與存取

存取方式

• 傳統 socket API。
• DPDK (Data Plane Development Kit) 工具組，用於繞過核心基礎設施直接存取封包。
• 解析度：
• 為所接收網路封包的時間戳記提供奈秒解析度。

比較範例

之前

• 簡單的流程，在收到訊息後從系統時鐘讀取時間。
• 之後：
• 強化的流程，在訊息抵達應用程式之前由硬體完成封包時間戳記，提供更準確的時間戳記。

硬體封包時間戳記的增強效益

提高準確度

• 提供更準確的網路效能視圖。
• 範例：測量兩個執行個體之間的往返時間。
• 使用者空間應用程式測量值：~400 微秒。
• 硬體封包時間戳記測量值：~100-150 微秒。
• 可觀察到的差異：
• ~250 微秒的差異，歸因於作業系統與網路堆疊所花費的時間。
• 約占往返時間的 2/3，突顯更精確的可觀察性。
• 更清晰的網路效能：
• 能夠識別並拆解應用程式與網路之間的延遲。

NASDAQ 使用案例簡介

目標

• 展示 NASDAQ 使用 AWS 精準時間技術，在公有雲環境中營運市場的進展。

NASDAQ 背景

金融市場創新者

• 全球第一家電子交易所，創立於 1971 年。
• 在全球營運超過 30 個市場，包括股票、債券、選擇權及衍生性金融商品。
• 以匯集包括 Amazon 在內、市值領先的頂尖科技公司而聞名。
• 技術供應商：
• 服務超過 130 家市場營運商及 2300 家金融機構。
• 支援在全球 NASDAQ 交易所掛牌的 44,400 多家上市公司。
• 為 6000 家企業提供技術，支援資本市場生命週期。

NASDAQ 的雲端旅程

始於 10 多年前

• 從使用 AWS Redshift 的資料儲存庫與資料倉儲開始（2012-2013 年）。
• 目前儲存約 60 PB 的資料，支援後台功能。
• 演進至即時處理：
• 使用串流即時市場資訊進行市場監控。
• 可透過公有雲分發市場資料。
• 在 AWS Outpost 上推出選擇權交易所：
• 2022 年，在 AWS Outpost 上推出 NASDAQ MRX。
• 目前在 Outpost 上執行 6 個以上的市場系統。
• 公有雲中的關鍵系統：
• 託管為市場參與者提供即時洞察的系統。
• 利用雲端的可擴展性、效能與適當規模調整能力，處理大量訊息與受管的尖峰容量。

移轉至雲端的特定挑戰

地理限制

• 股票與股票選擇權交易主要在紐澤西州北部進行。
• 延遲相依性要求將電腦部署於特定地點。
• 超低延遲交易：
• 交易的下單至執行時間約以 ~20 微秒計。
• 大量訊息：
• 每天處理的訊息量超過 100 個十億，也就是千億則。
• 特定交易所系統每秒可處理多達 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 Time Sync Service：
• 提供奈秒範圍、在軟體中具有微秒準確度的時鐘。
• 硬體封包時間戳記：
• 讓應用程式能受益於更準確的計時，提升效能與可觀察性。

分散式系統的挑戰

多個時鐘

• 分散式系統有多部伺服器，各自擁有自己的時鐘。
• 時鐘並未完美同步，導致事件排序更為複雜。
• 傳統解決方案：
• 使用分散式鎖定、領導者選舉與共識演算法進行排序。
• 隨著系統成長，這些演算法會限制效能並增加複雜度。

時鐘不確定性與誤差範圍

人類觀點

• 人類認為時間是精確的（例如下午 2 點），但時鐘存在不確定性。
• 精準時鐘：
• AWS 精準時鐘在軟體層存在不確定性（例如 ±20 微秒）。
• 應用程式中的誤差範圍：
• 應用程式必須將此誤差範圍納入考量。
• 範例：銀行帳戶交易需要正確排序，以避免透支。

估算時鐘不確定性

複雜問題

• 客戶需要瞭解其時鐘的不確定性區間。
• 範例：
• 檢查 EC2 執行個體上的時間同步常駐程式以估算誤差。
• 時間同步來源：
• 網際網路 NTP 伺服器（例如 time.aws.com）：~395 微秒的不確定性。
• 透過 Nitro system 的本機 NTP 伺服器：~90 微秒的不確定性。
• PTP 硬體時鐘（透過 Nitro system 強化的 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 clock（虛擬機器時鐘）的新功能。
• 與新版 Clockbound 結合：
• 能夠將時間直接從 Nitro 時鐘傳入執行個體。
• 在維護事件期間改善效能，確保工作負載順暢運作。
• 新系統的效能
• 系統可在數小時內持續追蹤並校正漂移，使其維持在 ±1 微秒內。
• 不確定性範圍：
• 透過查詢 Clockbound 常駐程式繪製的不確定性範圍大小。
• 鋸齒狀行為：隨著時鐘更新而擴大及縮小。
• 達成的不確定性範圍：應用程式內介於 20 至 26 微秒。

紐澤西州北部的股票與選擇權意義重大，因為當地是支撐華爾街交易的主要金融資料樞紐（例如位於 Secaucus 的 Equinix），鄰近優勢吸引金融專業人士，加上由 NJR 等提供穩定股息的公司所構成的強健地方經濟，這一切 都由完善的基礎設施與通往 NYC 的通勤網路所支援，形成多元的投資

環境，涵蓋高科技資料中心到歷史悠久的公司。

為何紐澤西州北部是股票與選擇權樞紐

• 資料中心重鎮：紐澤西州 Secaucus 設有關鍵資料中心（例如 Equinix NY4），對高頻交易至關重要；這些設施將交易活動從 Manhattan 轉移，使 NJ 成為金融科技的核心地點。
• 鄰近 NYC：便捷的交通（火車、渡輪）連接 NJ 與 NYC，吸引金融專業人士，也使當地成為 Manhattan 金融區從業人員的首選居住地，帶動 Bergen 與 Hudson Counties 等地的地方經濟。
• 強健的本地公司：New Jersey 擁有歷史悠久的公司，例如 New Jersey Resources (NJR)，其持續穩定的股息與價值指標，對著重股息的股票投資人深具吸引力。
• 投資生態系統：該地區受益於房地產強勁增值（股權的一種形式）、穩定需求，以及由 NJEDA (New Jersey Economic Development Authority) 支援且持續成長的「創新生態系統」，同時促進傳統及科技驅動的投資。
• 稅務與監管環境：New Jersey 設有特定法規，例如非居民股票選擇權收入相關規定，顯示其具備會影響投資人的成熟金融監管架構。
• 這對投資人的意義
• 資料與科技焦點：金融科技相關領域及支援金融業的資料基礎設施中存在機會。
• 價值與收益：除了不動產投資（房地產權益）外，也可留意總部位於該州或鄰近地區、穩定配息的公司。
• 通勤吸引力：通往 NYC 的交通便利地區（例如 Weehawken、Bergen County）需求旺盛，是穩健的房地產權益投資標的。

Equinix 位於紐澤西州 Secaucus 的園區（NY2、NY4、NY5、NY6）是華爾

街至關重要的低延遲樞紐，提供通往主要金融交易所與交易生態系統的直接連線，

進駐許多金融公司，並為

高頻交易 (HFT) 與 Dow Jones 新聞饋送等重要資料服務提供高度安全、可靠的主機代管，確保

速度及鄰近市場的優勢。這些設施如同數位骨幹，讓公司能夠

將伺服器設置在交易所附近，以加快交易速度。

為何這對華爾街很重要

• 低延遲：實體位置鄰近交易所，可將資料傳輸時間降至最低，這對 HFT 至關重要。
• 市場存取：直接連線至交易場所、資料供應商（例如 Dow Jones）及其他金融參與者。
• 可靠性：採用穩健的電力、冷卻與安全設計，確保金融作業不中斷。

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 的需求，而當 HA 不足時，DR 則提供最終安全網。

如果我的資料庫節點故障會怎樣？

自行管理的資料庫

• 將資料庫引擎與儲存空間結合於單一節點
• 備份期間可能發生效能問題
• RPO 可能高達 24 小時
• 節點故障時，RTO 可能長達數小時
• Aurora 耐久性：
• 從單一可用區中的一個資料庫叢集開始
• 使用 Aurora 儲存空間進行資料複寫
• 多租戶儲存機群的節點分散於 3 個 AZ
• 每次寫入都會跨 3 個 AZ 複寫 6 次
• 使用者只需為一份副本付費
• 不使用非同步複寫，RPO 為 0
• Aurora 僅寫入日誌記錄而非頁面，以提升耐久性與效能
• Aurora 中的備份與還原：
• 儲存引擎會持續將資料備份至 S3，而不影響效能。
• 可從最早可還原時間（最多 35 天前）到最新時間（繁忙資料庫約 5 分鐘前）執行時間點還原 (PITR)。
• 還原程序包括從 S3 提取資料、套用內部日誌記錄，以及啟動引擎以進行交易復原。
• 資料庫執行個體可用性：
• 基本組態包含一個執行個體；故障時需要 10-15 分鐘進行替換。
• 新增待命執行個體可提高可用性；Aurora 會使其與主要執行個體保持同步。
• 在數秒內容錯移轉至待命執行個體，並維持相同大小與負載容量。
• 結果是 RPO 為 0，RTO 通常約為 30 秒，形成多 AZ 可用性模式。

效能韌性

• 效能可能隨應用程式需求波動，導致資源可能遭到浪費。
• 開放原始碼解決方案提供向上擴展（硬體升級）或向外擴展（將資料庫分割成多個部分），但兩者都難以處理一致性與吵雜鄰居問題。