FSI Meetup 2025 Q4 - Brex 資料庫災難復原

場次筆記

Brex 簡介

• 用於管理費用、差旅與信用額度的財務作業系統平台。
• 工程經理與團隊成員討論如何運用 Amazon Aurora 強化韌性並拓展國際市場

Brex 服務

• 公司卡、費用管理、差旅、帳單付款及銀行業務
• 目標是協助客戶明智且精打細算地支出

為災難情境預先準備基礎設施的重要性

• 著重於資料層，主要使用 PostgreSQL 搭配 PG bouncer 與複本，以供應用程式和分析用途使用
• 將較小的資料庫合併至單一資料庫執行個體
• 過去的災難復原流程需手動執行且相當耗時

災難復原解決方案的目標

• 採用溫備援災難復原解決方案，以縮短復原時間目標（RTO）與復原點目標（RPO）
• RTO：災難發生後，恢復正常運作所允許的最長時間
• RPO：可容許遺失的最大資料量

決定 RPO 與 RTO

• 分析指標、評估目前能力，並進行廣泛測試
• 瞭解應用程式將如何因應額外延遲與資料遺失

選擇 Amazon Aurora Global Database

• 無須大幅變更目前設定，即可提供所需功能
• 可在需要時使用次要區域

目前實作的注意事項

• 為讀取應用程式建立自訂 DNS 端點，同時供應用程式與分析用途使用

遷移挑戰與方法

• 由於可能造成應用程式停機，從 PostgreSQL 遷移至 Aurora 並不容易
• 著重於自動化，以盡量減少人工處理
• 建置 Temporal 工作流程來執行自動化工作，以驗證遷移步驟並準備環境
• 在確認自動化流程已驗證資料庫狀態後，執行切換至 Aurora Global 的作業

遷移期間的停機管理

• AWS 為遷移提供一小段停機時間（2 至 3 分鐘）
• 利用這段時間調整端點及使用該資料庫的應用程式
• 善用短暫的停機時間，順利完成轉換

使用 Temporal 工作流程進行自動化

遷移前的目前狀態

• 應用程式連線至 PG bouncer，再由 PG bouncer 連線至 PostgreSQL 執行個體與複本執行個體

遷移流程

• 透過 AWS 建立 Aurora 讀取複本，全程無須停機
• 工作流程提升 Aurora 讀取複本，並建立 Aurora 全域叢集
• 應用程式連線至 PG bouncer，再由 PG bouncer 使用全域寫入器端點連線至 Aurora 全域叢集
• 可建立另一個叢集以設定多區域架構

Flux：

• 透過 git 儲存庫讓 Kubernetes 叢集保持同步的工具
• 工作流程預先產生 Flux git pull request
• 在人工驗證後，工作流程自動合併 pull request
• 將確認訊號傳送至工作流程，以繼續執行停機作業並提升 Aurora 全域叢集

使用 AI 自動檢閱 Flux

• 識別 pull request 中的錯誤或問題，並提供註解供檢閱

dry run 遷移旗標

• 允許測試遷移，而不會造成破壞性動作或停機
• 預先建立 Flux git pull request 以供檢閱，但不合併 pull request 或提升叢集

遷移中使用的其他工具與流程

• Terraform：建立範本，以新的全域叢集形式管理資料庫
• 在遷移工作流程完成後，為每個資料庫加入 Terraform
• 透過 Terraform 管理全域叢集中的讀取器執行個體

內部命令列工具：

• 加入命令，讓團隊能透過自助方式為其 Aurora 全域叢集執行切換或容錯移轉
• 容錯移轉：用於從非計畫性中斷復原；若某個區域停擺，便切換至其他區域
• 切換：用於營運維護或計畫性程序等受控情境，不會遺失資料

以反覆迭代方式改善工作流程效能的歷程

• 初始工作流程完成端對端自動化約需 15 分鐘
• 提升 Aurora 全域叢集和建立 Flux git pull request 所需的停機時間
• 流程依序執行，未進行平行處理

加入平行處理後，工作流程時間縮短至 10 分鐘

• 更新工作流程以平行執行步驟，包括取得憑證及預先建立 Flux pull request
• 導入 dry run 旗標，以進行非破壞性的遷移測試

最終重新調整工作流程結構後，執行時間縮短至 3 分鐘

• 預先建立 Flux pull request，讓工作流程暫停至停機時段
• 減少 git add 作業以降低成本
• 加入訊號命令，以受控方式啟動停機作業

過程中學到的經驗

• 在正式遷移前，全面測試與審慎部署至關重要
• 從預備環境開始，解決問題後再繼續部署至正式環境
• 自動化可減少人為錯誤，並能輕鬆將流程套用至多個資料庫
• 使用 dry run 選項來模擬遷移，在不造成停機的情況下測試工作流程（dry run 或 practice run 是一種試驗或排演，屬於軟體測試流程，用來確保系統正常運作且不會導致嚴重故障。）
• 每週遷移少量資料庫，以反覆迭代的方式改善