极点宏观｜Financial Cloud Cloud · AWS Re:cap
AWS Re:cap 04: FSI Meetup 2025 年第四季度 - 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，后者连接到 PostgreSQL 实例和副本实例
迁移流程
● 通过 AWS 创建 Aurora 只读副本，且无需停机
● 工作流提升 Aurora 只读副本，并创建 Aurora 全局集群
● 应用连接到 PG bouncer，后者再使用全局写入器端点连接到 Aurora 全局集群
● 可以再创建一个集群，以构建多区域环境
Flux：
● 通过 git 存储库保持 Kubernetes 集群同步的工具
● 工作流预先生成 Flux git 拉取请求
● 人工验证后，工作流自动合并拉取请求
● 向工作流发送确认信号，使其继续执行停机操作并提升 Aurora 全局集群
使用 AI 自动审查 Flux
● 识别拉取请求中的错误或问题，并提供审查意见
试运行迁移标志
● 可在不触发破坏性操作或停机的情况下测试迁移
● 预先创建 Flux git 拉取请求以供审查，但不合并请求或提升集群
迁移中使用的其他工具和流程
● Terraform：创建用于将数据库作为新全局集群进行管理的模板
● 迁移工作流完成后，为每个数据库添加 Terraform 配置
● 通过 Terraform 管理全局集群中的读取器实例
内部命令行工具：
● 添加命令，使团队能够以自助方式为其 Aurora 全局集群执行切换或故障转移
● 故障转移：用于从非计划中断中恢复；当一个区域停机时，切换到其他区域
● 切换：用于运营维护或计划内操作等受控场景，不会丢失数据
通过迭代提升工作流性能的历程
● 最初的工作流完成端到端自动化大约需要 15 分钟
● 提升 Aurora 全局集群并创建 Flux git 拉取请求时会出现停机
● 流程按顺序执行，未进行并行化
引入并行化后，工作流耗时缩短至 10 分钟
● 更新工作流以并行执行步骤，包括获取凭证和预先创建 Flux 拉取请求
● 引入试运行标志，用于对迁移进行非破坏性测试
最终重构工作流后，执行时间缩短至 3 分钟
● 预先创建 Flux 拉取请求，使工作流可以暂停并等待停机窗口
● 减少 git add 操作以降低成本
● 添加信号命令，以受控方式启动停机
实施过程中获得的经验
● 在正式迁移前进行全面测试和审慎部署至关重要
● 从预发布环境开始，解决问题后再进入生产环境
● 自动化可减少人为错误，并能轻松复制到多个数据库
● 使用试运行选项模拟迁移，以便在不造成停机的情况下测试工作流（试运行或演练是一种软件测试过程，用于确保系统能够正常工作且不会导致严重故障。）
● 每周迁移少量数据库，通过迭代持续改进