FSI Meetup 2025 Q4 - Graviton 遷移成功案例

場次筆記

運用 AWS 與 EC2 Graviton 推動系統轉型

Numora 概覽

• 成立已有 100 年，總部位於東京
• 五大部門：財富管理、投資管理、銷售、全球市場、投資銀行
• 口號：「連結東西方市場」
• 秉持紀律、創業精神、創意解決方案與思想領導的傳統
• 支援企業風險職能
• 為全球業務執行市場風險與交易對手風險模型
• 運算與資料密集型作業，非常適合使用雲端
• 幾乎無須擔心延遲

部署規模

• 每天使用 EC2 Spot 部署超過 65,000 個核心，以執行定價批次作業
• 每天產生約 2 TB 的資料
• 資料保留期限最長達七年
• 目前 S3 使用量約為 2 TB，採用 S3 Integring 以符合成本效益的方式儲存歷史資料

資料彙總與摘要

• Numora 選擇採用記憶體內彙總
• 使用超過 100 個超大型 EC2 執行個體，針對信用風險與市場風險模型進行次秒級彙總

議程

• 公有雲對金融機構內部運算風險的影響
• Numora 風險系統的高階架構
• Graviton 在定價與彙總使用案例中的案例研究
• 遷移流程中的其他考量與經驗心得

Numora 系統的高階架構

資料湖倉儲存所有輸入與輸出

• 輸入包含交易、歷史市場資料與參考資料（帳戶、幣別、國家）
• 混合式資料湖倉：主要在內部部署環境處理資料，並匯出至 S3 供雲端部署使用

定價引擎

• 由 C++ 定價計算器組成
• 載入輸入資料、執行模型，並輸出交易層級的結果

彙總引擎

• 載入資料及參考資料，以便在次秒內依帳簿、國家、幣別或交易對手進行資料切割與分析

內部自製 BI 工具

• 事件式平台
• 提供預設檢視，並允許使用者建立自己的檢視
• 建立虛擬資料表，供應用程式與試算表透過 SQL 存取及製作樞紐分析

定價使用案例與 Graviton 導入

• 約 5 年前在 AWS 上正式啟用定價作業，最初在維吉尼亞北部使用 Intel，一年後再加入俄亥俄區域
• 約 3 年前將所有定價引擎遷移至 Graviton
• 由於數值準確性至關重要，因此必須完整重新編譯 C++ 定價引擎並進行數值迴歸測試
• 在維吉尼亞北部與俄亥俄區域使用完全由 Spot 組成的 Auto Scaling 群組執行定價引擎
• 運用多種執行個體類型與不同標準規格
• 使用所有 Graviton 執行個體家族（Graviton 2、3 與 4）及執行個體

定價層遷移至 Graviton 的成果

• 在 4x large 上執行一個引擎，在 24x large 上執行四個引擎
• 成本降低 50%
• 效能未受損，且觀察到些微提升
• 經驗心得：謹慎選擇部署區域、採用多區域架構，並最佳化批次作業尾端以節省成本

彙總使用案例與 Graviton 導入

• 彙總層由大型 JVM 組成
• Java 供應商提供 ARM 相容的 JVM 後，便將彙總層切換至 Graviton
• 由於系統以 Java 為基礎，因此無須重新編譯，但仍執行了完整的迴歸測試
• 使用 On-Demand 執行個體進行有狀態資料載入及資料切割與分析功能（切割與分析法的運作方式，是將資料拆分成較小且易於管理的區塊（切割），再重新排列這些元素以觀察模式與趨勢（分析）。其功能包括：將資料拆解以進行詳細分析，以及促進資料的多維度分析）
• 導入 Compute Savings Plans，以涵蓋 80% 的用量並降低成本
• 改用能提供額外最佳化的供應商
• 為彙總引擎導入自訂 Spot 執行個體，暫停或回收未使用的執行個體，進一步降低成本
• 目前使用 X2GD 執行個體（具備磁碟儲存空間的 Graviton），但也能運用其他執行個體類型
• 規劃在不久的將來遷移至 Graviton 4

彙總平台遷移至 Graviton 的成果

• 預估在相同成本下，彙總平台可擴充至 3 倍規模
• 在維持成本不變的情況下，得以部署新的業務功能，例如 FRTB IMA 模型

Numora 雲端遷移歷程的主要心得與建議

及早投資部署管線，並強制執行資源標記

• 使用與引擎整合的集中式部署管線，以控管執行個體與作業系統
• 有助於維持成本效益並減少錯誤

在團隊中灌輸創業精神與當責意識

• 使用 AWS 所節省的成本可再投資於其他使用案例，或直接增加盈餘
• 導入一流的可觀測性與防護機制

專注於韌性

• 先從區域內的多可用區部署開始
• 導入多區域部署以提高韌性
• 緊跟 AWS 的創新腳步，並在其基礎上打造自己的創新
• AWS 為系統建置與問題解決提供強大的環境