AWS Re:cap 10: Nasdaq：為全球金融服務打造具彈性的基礎設施（HMC327）

NASDAQ 的雲端歷程與彈性系統架構

● 為金融服務建置具彈性、高效能的系統。

● 概述 NASDAQ 的雲端歷程、災難復原策略、混合式基礎設施解決方案、架構考量及未來展望。

● NASDAQ 的背景：

● 電子交易所的先驅，在全球營運超過 30 個交易所。

● 為超過 130 個市場提供軟體，包括交易、結算、風險管理及反金融犯罪解決方案。

● 以傳統託管軟體、託管服務及 SaaS 形式提供解決方案。

● 雲端歷程：

● 始於 15 年前，逐步遷移撮合引擎與市場系統等關鍵系統。

● 從 T+1 備份進展至硬即時系統，處理超低延遲交易。

● 從較不關鍵的系統轉移至對國家經濟具有系統重要性的系統。

● 挑戰：

● 以微秒與奈秒衡量的超低延遲交易。

● 基於鄰近性與延遲考量，具有特定實體位置要求。

災難復原策略與混合式基礎設施

彈性與法規要求

● 高彈性目標，且客戶預期 100% 的正常運作時間。

● 在全球多個司法管轄區接受法規監督。

● 災難復原範圍：

● 從備份與還原，到多站點、主動－主動、多區域系統。

● 對 RPO 與 RTO 目標取得共識，並瞭解系統如何因應災難的重要性。

● 聚焦關鍵系統：

● 以必須持續運作且不能停機的系統為核心。

● 使用 Outposts 的混合式運算、故障域、靜態穩定性及中斷連線運作。

● 使用 Outposts 的混合式運算：

● 使用 Outposts 將工作負載放置於資料中心，同時透過 EC2 API 與 Amazon 基礎設施進行管理。

● 使用 Direct Connect 線路連接區域與資料中心。

● 在資料中心機架中使用 EC2 伺服器，並以服務形式進行管理。

● 為市場系統加入超低延遲網路介面卡。

● 實作裸機伺服器與網路，提供在實體上完全分離的資料平面。

● 裸機伺服器

● 實體單一租戶伺服器，讓用戶端能直接、專屬地存取所有硬體資源，不同於透過 Hypervisor 共用硬體的虛擬伺服器。此設定提供最高效能、一致的 I/O，以及對軟體堆疊的完整控制，非常適合高效能運算、遊戲或 AI/ML 等高需求應用程式，以及需要實體隔離或特定硬體組態的工作負載。

故障域與靜態穩定性

故障域

● 使用故障域概念來瞭解系統元件之間的共同命運。

● 執行軟體的 EC2 伺服器具有多個執行個體與熱備援（預先佈建的 EC2 執行個體），以提供備援。

● 每個軟體元件都有 AB 配對，確保備份元件不會共同位於相同執行個體。

● 機架層級故障域：

● 考量潛在的機架層級故障（例如電力中斷）。

● 機架層級故障：整個伺服器機架因電力中斷、冷卻故障、網路交換器故障或實體損壞而離線，影響其中所有伺服器。

● 使用多個機架，並將軟體元件的 AB 配對分散至不同機架，以避免兩個元件同時遺失。

● 站點層級故障域：

● 資料中心使用多個實體站點以確保彈性。

● 美國市場的主要站點位於 New Jersey，次要站點位於 Chicago。

● 靜態穩定性：

● 使用熱備援（預先佈建的 EC2 執行個體），確保備份資源立即可用。

● 將軟體元件的 AB 配對分散至不同機架與站點，以在發生故障時維持系統完整性。

● 熱備援：

● AWS 上預先佈建的 EC2 執行個體主要透過 EC2 Auto Scaling 暖集區功能實作。此功能可讓您維持一個執行個體集區，在應用程式需要向外擴展時立即投入服務。

● 災難復原（DR）策略：暖集區是「暖待命」或「指示燈」災難復原策略不可或缺的一部分

● 更快速擴展：暖集區中的執行個體已預先初始化，表示耗時的應用程式啟動與組態流程都已執行。

靜態穩定性與中斷連線運作

靜態穩定性

● 使用靜態穩定性概念，確保系統在中斷期間的彈性。

● 使用熱備援（預先佈建的 DC2 執行個體），避免故障期間依賴 EC2 控制平面。

● 目標是在中斷期間不進行變更也能維持系統功能，依賴預先設定的資源。

● 中斷連線運作：

● 為 AWS 服務連線可能中斷的情境做好準備（例如光纖損壞）。

● 確保市場系統在此類事件期間無需依賴外部服務也能繼續運作。

● 使用熱備援與預先設定的資源，在中斷連線情境中維持功能。

● 營運執行手冊：

● 為每個故障域層級制定明確營運執行手冊的重要性。

● 應妥善編排因應伺服器、機架及站點層級故障的程序，並讓營運人員熟悉這些程序。

● 目標是以可預測且經過充分演練的方式因應災難，將實際事件期間的意外降至最低。

中斷連線運作與測試

中斷連線運作

● 為 AWS 服務連線中斷的情境做好準備（例如網路線路遭切斷）。

● 使用 Local Gateway 進行緊急破窗存取，無需依賴外部服務即可在本機管理系統。

● 瞭解可能需要外部連線的內部相依性與操作，確保加以處理或避免。

● 測試故障模式：

● 長時間中斷 Outposts 連線以進行徹底測試，觀察系統行為。

● 識別並處理中斷期間可能失敗的操作（例如 SSL 檢查、IAM 互動）。

● 確保即使發生區域或服務連結問題，Local Gateway 仍可存取。

● 策略摘要：

● 在資料中心使用 Outposts 進行混合式運算。

● 分析故障域，以瞭解元件相依關係與共同命運。

● 針對靜態穩定性進行設計與測試，以便在中斷期間不進行變更也能維持系統功能。

● 著重於中斷連線運作，確保系統與 AWS 服務中斷連線時仍可在本機繼續執行。

● 強調審慎規劃、明確的營運執行手冊及廣泛測試，以實現彈性並避免災難期間出現意外。

● 緊急破窗

● 存取是一項安全措施，可讓授權人員略過一般存取控制，取得關鍵系統、資料或功能的緊急存取權。此術語源自打破玻璃以取用火災警報器等緊急設備的概念。這是在安全漏洞、系統故障或密碼鎖定等事件導致標準方法失效時使用的故障安全通訊協定。緊急破窗帳戶已預先設定高權限，但在緊急情況發生前會保持安全且停用，並應嚴格監控及記錄其使用情況。

● 緊急存取：危機發生且標準存取方法無法使用時。

● 略過控制：這些帳戶的設計用途是規避一般身分與存取管理（IAM）。

● 高階權限：帳戶已預先設定提升的權限。

● 嚴格管理：為防止濫用，緊急破窗憑證會受到極為謹慎的管理。

未來方向與增強功能

動態部署

● 規劃採用更多以規則為基礎設定的動態部署。

● 使用親和性與反親和性模式來平衡效能與彈性。

● 反親和性模式是雲端／虛擬化（例如 Kubernetes、VMware、OpenStack）中的規則，可防止特定工作負載（VM、Pod）一同在相同實體主機或相同故障域中執行，透過分散工作負載來確保高可用性、容錯能力及負載平衡；這與嘗試將項目共同配置以提升效能的親和性相反。

● 目標是在市場轉移至公有雲時，無需停機即可擴展系統。

● 先進硬體實驗：

● Graviton 4 的使用經驗良好，並與 Amazon 合作開發下一代 CPU。

● 測試適用於 Graviton 的超低延遲網路卡及其他進展。

● 探索使用 FPGA 與 GPU 的加速運算，以進行即時風險分析。

● FPGA（Field-Programmable Gate Array）是一種可重新設定的積體電路，可在製造後進行程式設計，以執行廣泛的數位邏輯功能。

● 擴展 Outpost 功能：

● 有意將更先進的元件（自訂晶片、FPGA、GPU）導入 Outposts。

● 將系統銷售給第三方，目標是提供更多功能與服務。

● 謹慎的服務整合：

● 以謹慎方式將更多服務新增至 Outposts，並與服務團隊進行深入探討。

● 著重於瞭解故障模式，並確保高服務可用性與功能。

● 結論：

● 持續努力增強系統彈性、效能及可用性。

● 強調透過細心規劃、測試及與 AWS 合作來達成未來目標。

● 感謝觀眾參與，並鼓勵填寫表單以取得更多資訊。

Nasdaq 資料中心內的 AWS Outposts，用以支援超低延遲交易操作。其

主要元件及其功能為

● AWS Cloud 與區域：標準 AWS 環境，在多個相互隔離的可用區域（AZ）中提供服務。

● AWS Direct Connect：將 Nasdaq 資料中心連接至主要 AWS 區域的專用私有網路連線，用於控制平面與服務連結連線，以管理 Outposts。

● Nasdaq 資料中心（內部部署）：託管 AWS Outposts 的實體位置，讓工作負載能在本機執行，以實現低延遲並符合法規要求。

● AWS Outposts：部署於 Nasdaq 資料中心內，是完全受管的 AWS 運算與儲存容量，可將 AWS 基礎設施、服務及 API 延伸至內部部署環境。

● 搭配 Nitro 與 ULL NIC 的 Amazon EC2 執行個體：執行交易應用程式的運算執行個體。它們運用 AWS Nitro System 來增強效能與安全性，並使用超低延遲（ULL）網路介面卡（NIC），以符合金融交易的嚴格延遲要求。

● Local Gateway：此 Outpost 元件會將內部部署網路連接至 Outpost VPC 子網路內的執行個體，以協助與現有 Nasdaq 基礎設施通訊。

Nasdaq 網路

● ULL 交易網路：專為超低延遲設計且在實體上分離的網路，直接與 EC2 執行個體上的 ULL NIC 連接，以快速處理交易。