お客様事例をベースとした金融アーキテクチャ解説を公開(金融リファレンスアーキテクチャ日本版 2025)
AWS 的“日本版金融参考架构”自2022年首次发布以来,一直在持续扩充内容。其中,针对“关键业务(核心银行系统)”、“客户渠道”等金融行业特有的工作负载,已发布了结合 AWS CDK 示例代码的参考架构。例如,“关键业务(核心银行系统)”不仅适用于核心系统,也可用于一般的 OLTP 系统。
然而,一直以来都存在这样的需求:在了解具体系统特性的基础上,希望获知更详细的考虑点和架构决策依据。为此,本次我们分析并整理了包括全球在内的先进案例,将其作为阐述架构要点的文档予以发布。
本次公开的是以下三个用例:
- 证券公司的 OMS(订单管理系统)
- 信用卡的发卡系统
- 保险行业的数据分析系统
针对每个用例,文档都包含关于架构目的和特点的讲解,并附带了预期的常见问题解答(FAQ)。本文将介绍各用例的概要。
证券公司的 OMS(订单管理系统)
我们公开了在云环境中构建证券公司订单管理系统(OMS)的参考架构。该架构基于在国内外运行的多个案例经验,为那些寻求将传统在本地或大型机上运行的证券公司核心系统,以低延迟、高可扩展性、高可用性相平衡的方式构建成云原生系统,提供了指导方针。
作为实现要点,文档解释了以下内容:
- 利用 Amazon ElastiCache for Redis 实现内存消息传递,以实现组件间的低延迟通信。
- 通过微服务化实现各组件独立扩展,以应对开盘时等可预测的峰值负载。
- 利用 AWS Outposts 实现靠近交易所的部署,以最小化与 EMS(执行管理系统)的通信延迟。
详情请参阅正文:金融工作负载架构讲解 资本市场 OMS。
信用卡的发卡系统
我们公开了将信用卡发卡系统从本地环境分阶段迁移、构建和运行到 AWS 时的参考架构。该架构基于客户先行案例,展示了如何实现信用卡行业所需的各种要素:应对因促销等活动引起的支付需求导致的高流量处理及实时授权要求、引入支付技术及行业标准/应对金融监管要求变更、以及保障支持业务连续性的高可用性等。
文档展示了一种架构模式:在 AWS 上构建授权(Authorization)以及对账(Reconciliation,核对清算文件与已授权数据)功能,而在本地构建结算(Settlement)功能。
此外,作为实现要点,还解释了以下内容:
- 采用多区域主动-主动配置,根据卡号、客户ID等数据内容判断从本地分发到哪个区域,从而分离各区域的处理对象,实现一致性与可用性的平衡。
- 采用微服务架构,实现各功能的独立横向扩展。
- 通过引入请求聚合来保障 DynamoDB 的性能。
保险行业的数据分析系统
我们公开了在 AWS 上构建和运行实现保险业务所需数据处理的数据平台时的参考架构。该架构基于客户先行案例,展示了如何实现保险行业所需的各种要素:应对数据量激增导致的处理能力不足与成本增加、遗留系统功能限制导致难以应对多样化需求、以及安全边界模糊导致的合规性应对难题等。
该平台以集成数据湖为中心,在云上系统化实现保险业务中从投保人信息、健康信息、财务数据的摄取到分析功能。通过采用多账户策略,在数据摄取、数据湖、数据转换、数据仓库、数据分析等每个处理环节都在分离的账户中执行,从而实现了 PII/PHI 数据的完全分离和安全边界的明确化。
作为实现要点,文档解释了以下内容:
- 利用 Amazon Aurora 作为元数据存储库,通过 AWS Glue 框架实现元数据驱动的作业自动生成,从而统一摄取不同来源的数据。
- 通过 Amazon Redshift Data Sharing 实现计算分离架构,将预配置集群上的 ETL/ELT 处理与无服务器集群上的分析处理完全分离,避免性能冲突。
- 通过 AWS Organizations 的多账户策略和 IAM 跨账户角色,实现 PII/PHI 数据的完全分离和最小权限访问控制。
详情请参阅正文:保险工作负载:数据分析基础。
总结
本博客文章由 AWS 的解决方案架构师 樋口 健人、武方 総、髙木 香里、吉澤 稔、松本 耕一朗 撰写。