AWS Re:cap 05: 透過 Amazon Time Sync 改善分散式系統，Nasdaq 專題分享

影片： https://www.youtube.com/watch?v=PecK_inxe5Y

● 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 可用性模式。

效能韌性

● 效能可能隨應用程式需求波動，導致資源可能遭到浪費。

● 開放原始碼解決方案提供向上擴展（硬體升級）或向外擴展（將資料庫分割成多個部分），但兩者都難以處理一致性與吵雜鄰居問題。