使用 Amazon Aurora 与 QuickSight 构建云 ERP 实时分析系统

概述

将企业核心 ERP 系统迁移至云端时，如何保障甚至提升原有的实时操作报表能力，是许多组织面临的重大挑战。本文档基于 Oldcastle APG 公司的实际案例，阐述了一种构建实时分析系统的 SRE 友好型架构。该系统利用 AWS 托管服务（如 Amazon Aurora、Amazon QuickSight）与 Infor 的 Data Fabric Stream Pipelines 相结合，实现了从 ERP 数据摄取到嵌入式可视化分析的端到端低延迟流水线。此架构模式对于需要在云环境中维持高可用性、可扩展性和实时业务洞察的 SRE 和平台工程师具有重要参考价值。

核心概念

理解本架构涉及以下关键技术组件与设计模式：

  • 实时数据流 (Real-time Data Streaming)：通过 Infor Data Fabric Stream Pipelines 捕获 ERP 数据库表的增删改操作，并以变更事件的形式实时推送。这与传统的批量 ETL 流程形成对比，显著降低了数据新鲜度延迟。
  • 托管关系型数据库 (Managed Relational Database)：使用 Amazon Aurora PostgreSQL 兼容版作为核心数据存储。其 Multi-AZ 部署提供了高可用性和自动故障转移，读副本支持按需扩展，满足读密集型分析负载。
  • 嵌入式分析 (Embedded Analytics)：通过 Amazon API Gateway 和 AWS Lambda 将 Amazon QuickSight 的交互式仪表盘和像素级完美报表安全地嵌入到原有 ERP（Infor OS）用户界面中，提供无缝的用户体验。
  • 连接池与故障转移：Amazon RDS Proxy 在应用（分析层）与数据库之间管理连接池，支持自动故障转移，这对于处理高频流数据、避免数据库连接耗尽至关重要。
  • 安全的网络集成：使用 Network Load Balancer (NLB) 提供稳定的公网入口（Elastic IP），配合 Amazon EC2 实例作为 RDS 路由器和 iptables NAT 规则，安全地将流量转发至私有子网中的 Aurora 集群，实现了公有云服务与私有网络资源的可控互联。

实践

Oldcastle 构建的实时分析系统，其端到端工作流如下，展示了如何将各组件集成为一个可靠的 SRE 可运维系统。

1. 数据摄取与传输

  • 在 Infor Cloud ERP 环境中启用 Data Fabric Stream Pipelines 附加功能。
  • 配置特定 ERP 表（如销售订单、库存、财务交易）以实时发布变更事件，捕获插入、更新和删除操作及元数据。
  • 事件数据被推送至面向互联网的入口点。

2. 安全流量接入与分发

  • 在公网子网部署带有静态弹性 IP 地址的 Network Load Balancer (NLB)，为 Infor 的出站连接提供可预置白名单的稳定 IP。
  • 在私有子网中部署 Amazon EC2 实例作为 RDS 路由器，作为 NLB 的后端目标。
  • RDS 路由器通过 iptables NAT 规则将流量转发至私有子网中的 Amazon Aurora 数据库，确保即使 Aurora IP 因故障转移改变，公网入口 IP 保持不变。
  • 安全组配置：NLB 仅接受来自 Infor IP 范围的 HTTPS (443) 流量；RDS 路由器仅接受来自 NLB 的流量。

3. 数据库连接管理与高可用存储

  • 在 RDS 路由器与 Aurora 集群之间部署 Amazon RDS Proxy。它管理连接池、复用连接，并在主实例故障时自动将流量重定向到提升的副本。
  • RDS Proxy 使用 IAM 认证 来安全地获取数据库凭据。
  • 使用 Amazon Aurora PostgreSQL 集群存储数据，配置为跨多个可用区部署（Multi-AZ），包含一个写入器实例和多个读取器实例。
  • 数据库 Schema 设计考虑使用 JSONB 列 处理灵活的流数据，并为常用查询字段创建索引以维持性能。启用自动备份和点-in-time恢复。

4. 分析与可视化

  • 创建 Amazon QuickSight 账户，通过 VPC 连接器和存储在 AWS Secrets Manager 中的凭证连接到 Aurora 数据库。
  • 识别适合 SPICE 缓存的数据集（通常是聚合或频繁访问的数据），并配置增量刷新计划。
  • 使用 QuickSight 可视化界面构建仪表盘，利用计算字段实现业务逻辑、参数增强交互性，并实施行级安全 (RLS) 规则以确保数据访问合规。
  • 使用 像素级完美报表 功能生成适用于打印或合规性要求的格式化文档。

5. 嵌入式集成

  • 在 AWS 账户中启用 QuickSight 嵌入功能，并注册 Infor 域名。
  • 创建 Amazon API Gateway REST API，后端由 AWS Lambda 函数支持。该函数负责：
    • 对用户进行身份验证，验证 Infor 会话令牌。
    • 调用 QuickSight 的 GenerateEmbedUrlForRegisteredUser API 生成限时的、签名的 URL，并应用行级安全策略。
    • 将 Infor 用户角色映射到 QuickSight 权限，并根据用户组织上下文应用仪表盘筛选器。
  • 在 API Gateway 中配置 CORS 设置，允许来自 Infor 域的请求，并实施速率限制。
  • 在 Infor 端，通过 iframe 元素调用 API Gateway 端点，将生成的仪表盘 URL 嵌入 ERP 界面，实现无缝访问。

SRE 要点

本案例的架构设计深刻体现了 SRE 在保障系统可靠性、可观测性和高效事件响应方面的最佳实践。

  • 与可靠性的关联：该架构通过多层设计确保了高可用性。Amazon Aurora 的 Multi-AZ 部署 提供了数据库层面的故障转移能力；Amazon RDS Proxy 管理连接池并在数据库故障时透明地重定向流量，避免了应用层的连接错误；NLB 配合静态 IP 保证了数据入口点的稳定性。这些共同构成了一个能够优雅处理组件故障的系统，最大限度地减少了因基础设施问题导致的分析服务中断。
  • 最佳实践与常见反模式：
    • 最佳实践：使用托管服务（Aurora， RDS Proxy， QuickSight）减少运维负担；通过 VPC 私有子网、IAM 认证、安全组和 API Gateway 认证实施纵深防御安全策略；将分析功能嵌入业务工作流（ERP界面）以提升采用率和效率。
    • 应避免的反模式：避免直接让云 ERP 服务连接私有数据库实例，本方案通过 NLB 和 EC2 路由器提供了安全可控的桥接；避免应用直接管理数据库连接，使用 RDS Proxy 是更可靠的选择；避免构建复杂的自管批处理管道，采用原生流处理（Data Fabric Stream Pipelines）降低延迟和复杂性。
  • 相关指标 (SLI/SLO/SLA)：
    • SLI：可以包括从 ERP 事务发生到数据在 QuickSight 仪表盘上可见的端到端延迟；仪表盘页面的加载时间；系统支持的并发用户数；每日处理的事务数据量。
    • SLO：可以设定为“95% 的仪表盘查询在 5 秒内返回”；“系统在 99.9% 的时间对授权用户可用”。
    • SLA：对内部用户（客服、财务等）的承诺可以基于 SLO 制定，例如承诺关键运营报表在正常工作时间内的可用性和响应时间。该架构的弹性伸缩能力（Aurora 读副本自动扩展）有助于保障 SLO 在负载增长时仍能达成。
  • 可观测性：虽然案例未详述监控细节，但一个健壮的 SRE 实践需要在此架构中部署完整的可观测性堆栈。这包括使用 Amazon CloudWatch 监控 NLB、EC2 路由器、RDS Proxy 和 Aurora 的指标与日志；设置关键路径（如数据流延迟、API Gateway 延迟与错误率）的报警；并利用追踪工具确保端到端数据流的可追溯性。良好的可观测性是快速诊断性能瓶颈和故障、进行容量规划的基础。
  • 容量规划与弹性：系统设计明确考虑了扩展性：支持超过100个并发用户、处理每日数百万事务。Amazon Aurora 的读副本可以按需添加以应对查询负载，QuickSight SPICE 缓存加速了重复查询。这种弹性设计符合 SRE 的容量规划原则，能够随业务增长平滑扩展，避免因资源不足导致的性能下降或服务降级。