基于 AWS 的量化交易业务架构总览

阅读数:21 2019 年 11 月 22 日 08:00

基于 AWS 的量化交易业务架构总览
## 背景介绍
复制代码
在数字金融体系中,许多客户都充分利用 AWS 快速、稳定的全球基础设施构建他们的业务,优化访问、分析和决策的效率,提高业务扩展的弹性,完善业务运行的稳定性。同时在高频交易场景中,无论是行情数据同步、预测分析还是决策下单,速度都是至关重要的因素。本文总结了一些量化交易场景下可以借鉴的最佳实践,帮助您更好的使用 AWS 服务。
## 选择延迟最低的部署位置
AWS 的基础设施遍布全球,为客户的业务部署提供了丰富的选择空间。到目前为止,AWS 在全球 22 个地理区域(Region)内运营着 69 个可用区(Availability Zone),每个可用区内包含多个数据中心,这些数据中心、可用区和 AWS 区域之间都通过高可用、低延迟的私有网络基础设施进行互连,使得所有 AWS 资源之间的访问快速、稳定。借助 AWS 全球资源和网络,量化交易架构可以快速部署、稳定运行,获得最低的访问延迟,并实现灵活的迁移和扩展。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws1.jpg)
对于高频交易来说,访问延迟决定着交易的结果是否能达到预期。如果您要访问部署在 AWS 上的金融服务,使用 AWS 意味着请求会通过 AWS 骨干网络到达您要访问的客户端,与请求在 Internet 中传输相比延迟更低、稳定性更高;如果服务部署在与客户端所在区域相同的区域,那么延迟会更低,同一区域内资源互访的延迟只有几毫秒;为了提高可用性,每个区域的不同可用区相隔一定距离(100 公里以内),互相之间完全隔离,如果您将 AWS 资源与请求对端的资源部署在同一可用区,请求发生在同一可用区内,延迟将降到最低。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws2.jpg)
图示:使用 AWS 之外的资源访问 AWS 上部署的服务时,需要经过复杂的网络环境,可能产生较多延迟。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws3.jpg)
图示:使用 AWS 资源访问 AWS 上部署的服务时,通过 AWS 全球骨干网高速通信,网络环境好、延迟低。
我做了一个延迟测试,用于直观展现不同的部署位置对访问延迟的影响,当然最终还是以您的实际业务访问情况为准,这个测试结果作为参考。以金融服务部署在 AWS 东京区域为例,当服务部署在东京以外的其他地理位置时,例如美国东部,访问的平均延迟是 148.199ms(测试使用 AWS N.Virginia 区域,使用 ping 测试,链路经过优化,实际如果不在 AWS 做部署,网络质量会更不稳定,延迟也可能更高);如果您的服务部署在金融服务所在的区域(东京区域)但不同可用区,访问的平均延迟分别是 2.801ms 和 2.059ms,可以看到延迟大幅度降低;如果您的服务进一步部署在金融服务所在的可用区,访问的平均延迟是 0.587ms,有进一步的提升;如果再结合 private link 通过内网直接访问,在安全性提高的同时,延迟还可以表现的更好。
## 使用 PrivateLink 进一步提升安全性并降低成本
对于访问安全性要求高的团队,在与 API 服务提供商(如交易所)协商后,可以使用 AWS PrivateLink 提高访问的安全性。AWS PrivateLink 可以在 VPC、AWS 服务和本地应用程序之间通过 Amazon 网络安全地提供私有连接。您的客户端服务提供商可以将他们的应用程序配置为 AWS PrivateLink 支持的服务,之后您可以使用 VPC endpoint,在他们的服务和您的 VPC 之间创建连接,这样您的请求就会通过私有网络更安全、更迅速地到达目标服务。AWS PrivateLink 的工作方式如下图。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws4.jpg)
那么如何使用 PrivateLink 呢?接下来向您介绍 PrivateLink 的使用步骤。
### 1. API 服务提供方:创建终端节点服务
首先对于 API 服务的提供方(如交易所),需要基于网络负载均衡器创建终端节点服务。由于 PrivateLink 提供的是私有链接,网络负载均衡器也建议使用面向内部的模式。打开 AWS 控制台,选择 VPC 服务,在左边栏中选择终端节点服务(Endpoint Services),点击【创建终端节点服务】按钮,进入终端节点服务的创建页面。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws5.jpg)
选择之前创建好的网络负载均衡器,点击【创建服务】按钮,很快终端节点服务就创建好了。
### 2. API 服务提供方:授予连接权限
创建好的终端节点服务默认情况下只有本账户可以申请建立连接,在 API 服务提供方给服务使用方的账户赋予权限之后,相应使用方才能申请建立连接。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws6.jpg)
在控制台中选择上一步创建的终端节点服务,点击【白名单委托人】标签,然后点击【将委托人添加到白名单中】按钮,在新页面的 ARN 框中填写 API 服务使用方提供的 IAM 用户 ARN,格式为 arn:aws:iam::AWS_ACCOUNT_ID:IAM_USER,其中的 AWS_ACCOUNT_ID 为服务使用方的 aws 账户 ID,IAM_USER 为服务使用方用于配置的 IAM 用户名称。填写完成后,点击【添加到白名单委托人中】按钮,完成添加,之后 API 使用方就可以搜索到这个终端节点服务。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws7.jpg)
之后将【服务名称】发送给 API 服务使用方,服务使用方(交易团队)就可以使用服务名称申请私有连接。
### 3. API 服务使用方:创建终端节点
然后对于服务使用方,打开 AWS 控制台,选择 VPC 服务,在左边栏中选择终端节点(Endpoint),点击【创建终端节点】按钮,进入终端节点的创建页面。在服务类别中选择【按名称查找服务】,输入从服务提供方获取到的服务名称 com.amazonaws.vpce.REGION.xxxxxx,点击验证,会弹出 VPC 和安全组的选项。选择相应服务器所在的 VPC 及子网,选择一个开放相应端口的安全组,点击【创建终端节点】按钮完成创建。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws8.jpg)
刚刚创建完成时,终端节点的状态显示为【待接受】,是因为大部分终端节点服务会设置需要服务提供方允许才能连接。此时联系服务提供方,让他们在终端节点服务中找到相应的申请,接受连接请求。在终端节点的详细信息中,会有多个 DNS 名称,分别是统一 DNS 名称和每个子网对应的特定 DNS 名称,复制第一个 DNS 名称,用于之后的连接。
### 4. API 服务提供方:接受连接申请
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws9.jpg)
此时,API 服务提供方在终端节点服务页面的【终端节点连接】选项卡下,可以看到使用方提出的终端节点连接请求。点击【操作】按钮,再点击【接受终端节点连接请求】,即可开始自动创建连接。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws10.jpg)
### 5. API 服务使用方:连接创建完成
从 API 服务提供方处确认接受请求后,终端节点的状态会变为【待处理】,此时会自动在 VPC 中创建相应的网络接口(ENI),几分钟后网络接口创建完成,终端节点的状态会变为【可用】,此时私有连接就创建完成了。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws11.jpg)
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws12.jpg)
现在可以测试一下创建好的私有连接了,登录服务使用方(交易服务器生产环境)的 VPC 中的一台 EC2 设备,访问之前复制的终端节点 DNS 名称,能看到相应的结果,代表终端节点服务已经正常使用。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws13.jpg)
基于上述考虑,降低 AWS 云上访问延迟的最佳实践是通过网络测试,找出访问延迟最低的区域与可用区,然后在这个可用区中部署您的业务系统。为了将访问延迟降到最低,您可以将行情同步、决策、自动下单在内的整个系统部署在该可用区内,保证全部业务间访问在最近可用区内完成。同时,您可以通过 Private Link 获取更安全、迅速的内网访问。
## 降低决策过程的延迟
在对外访问延迟尽可能降低之后,进一步优化的空间就在于自动化决策的延迟。决策延迟的降低在架构层面体现在三个细节:公有子网部署、集中同一可用区部署、使用置放群组。
AWS 的网络基础服务 VPC(Virtual Private Cloud)提供云上的虚拟私有网络,EC2、RDS、ElastiCache 等服务都部署在 VPC 中,它们可以通过 VPC 的组件——互联网网关(Internet Gateway)来与互联网通信。每一个 VPC 属于一个区域,其中可以划分子网,每个子网属于一个可用区,您可以在子网中启动 AWS 资源。_(每个子网都可以绑定路由表并设置路由规则,如果路由规则中 0.0.0.0/0 指向 Internet 网关,那么这个子网就是公有子网,子网内的 EC2 在有公有 IP 的情况下可以和互联网资源直接互访;如果没有直接指向 Internet 网关的路由,那么这个子网就是私有子网,但同样可以通过 NAT Gateway 这个功能向外访问,从而提高网络层面的安全性。_) 同一 VPC 内的各个子网之间是可以互相访问的,您可以根据业务模块的不同,将需要更高安全性的 EC2(如决策服务器)放在私有子网中,与其他实例内部通信,通过 NAT Gateway 发起向外的请求;而将需要更低延迟的 EC2(如行情同步、下单服务器)放在公有子网中,直接通过 Internet 网关向外发起请求,使访问更便捷。
为了提高可用性,很多场景的最佳实践是跨可用区部署(如负载均衡器 Elastic Load Balancer,自动扩展 AutoScaling,托管关系型数据库 RDS,托管内存数据库 ElastiCache 等),防止单可用区故障对服务产生影响;但在高频交易的场景下,跨可用区部署可能会增加访问延迟,那么使用单可用区部署来提高访问速度是一种适当的策略。例如 ElastiCache 的 Redis 集群模式部署,选择多个可用区会提高可用性,但同时也可能增加访问延迟;使用单可用区做集群部署,并且将访问 Redis 集群的 EC2 也部署在相同的可用区内,这样损失了一部分可用性,但优化了决策速度。
当然,很多时候为了尽可能降低延迟,会使用单节点部署的方式,进一步减少各个服务模块(行情同步、决策、下单)之间的延迟,速度和可用性之间是一种您需要进行的权衡。那么在单可用区部署甚至单节点部署之后,如何尽可能保证服务的可用性呢?
有以下几个方面:
1. 对于 EC2 实例,定期做 AMI 镜像,并将镜像复制到备用 Region 中,从而在单节点故障时能在同可用区、其他可用区甚至其他区域快速启动相同的 EC2 实例,恢复服务。
2. 对于 RDS 数据库,在自动快照的基础上做手动快照(在重要节点,如代码版本更新等),并将快照复制到备用 Region 中,从而在故障时快速恢复服务。
3. 对于 ElastiCache,定期做备份,并将备份复制到备用 Region 中,从而在缓存集群故障时能快速恢复服务。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws14.jpg)
在业务系统有多台服务器的情况下,选择 EC2 置放群组可以进一步降低服务器之间的访问延迟。在集群类置放群组模式下,服务器会部署在同一可用区中尽可能近的位置,集群内任意一台服务器都可以以最小时延 / 最高带宽与该置放群组内的所有其他节点进行通信。要使用集群置放群组,可以在创建 EC2 的第三步【配置实例详细信息】的时候进行设置,选择添加到新的置放群组并命名,选择模式为 cluster;之后的实例就可以放在创建好的置放群组中,从而降低这些实例之间的通信延迟。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws15.jpg)
## 节约模型训练与预测时间
如果您的量化交易逻辑涉及到机器学习的分析和预测,那么节约模型预测的时间也会是整个量化交易过程中的重要一环。除了尽可能优化预测逻辑之外,节点部署上同样建议使用单可用区部署,并使用置放群组使得 EC2 之间的通信延迟尽可能低。在使用机器学习算法,如常用的 RNN、LSTM、GRU、Reinforcement Learning 等训练模型的过程中,Amazon Deep Learning AMI 与 AWS 的机器学习平台 Amazon SageMaker 可以帮助您进一步缩短模型训练与预测的时间。
Deep Learning AMI 配备了 TensorFlow、PyTorch、Apache MXNet、Caffe、Caffe2、Microsoft Cognitive Toolkit (CNTK)、Chainer、Theano、Keras、Gluon 和 Torch 等常见的机器学习框架,并预装了 CUDA、cuDNN GPU 加速框架。Deep Learning AMI 在 EC2 C5 实例上使用 Intel Advanced Vector Extensions(AVX 指令集)构建计算优化型 TensorFlow,以提高向量和浮点运算的性能,并可利用 Intel Math Kernel Library for Deep Neural Networks (MKL-DNN) 性能增强库。在 c5.18xlarge 实例上,使用 TensorFlow 1.12 通过合成 ImageNet 数据集训练 ResNet-50 基准的速度比在普通 TensorFlow 1.12 二进制文件上训练的速度要快 13 倍。同时,AWS P3 实例在云级别数百个 GPU 的操作中可以实现近线性扩展效率。
Amazon Sagemaker 是全托管的机器学习平台,实现数据收集、处理、建模、训练、部署全流程解决方案;Amazon SageMaker 支持多种算法与深度学习框架,包括完全托管的 Reinforcement Learning 算法,并支持 Bayesian optimization 等多种超参优化算法。在模型训练完成后,SageMaker 可以轻松在生产环境中一键式部署您的模型,以便您可以开始针对实时或批量数据的预测。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws16.jpg)
如上图所示,您的原始数据可以汇聚到 S3 构建的数据湖中,在使用 SageMaker 时,快速启动一台轻量级的笔记本实例(如 T2.medium,以很低的成本完成整个流程的管理和控制),打开 Jupitar Lab,在其中选择您喜欢的框架(常用框架已经预置在笔记本实例中),然后轻松开始数据的预处理和模型训练等工作,节约安装框架、调试的时间。
![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/overview-of-quantitative-transaction-business-architecture-on-aws17.jpg)
在完成数据的预处理之后,您只需通过几行代码,调用 API 使用 SageMaker 内置的算法,赋予相应的超参数即可开始模型训练。在调用 API 时会指定训练任务使用的实例类型(如 P3 这样的 GPU 实例,或 C5 这样的 CPU 优化型实例等),之后 SageMaker 会自动完成启动实例、执行训练任务、获取模型、关闭实例的整个过程,这些计算资源只在使用过程中付费,从而既提高了任务部署的效率,也降低了计算资源的浪费,节约了成本。如果内置的算法(线性学习、XG-Boost、因式分解机、图像分类、Sequence2Sequence、K-Means 等 17 种)不能满足您的需求,您还可以通过 MarketPlace 查找和使用其他公司贡献的算法;或者将自己的算法或模型打包上传到 Docker 容器中,从而直接在 SageMaker 中使用。
训练好的模型会存储在 SageMaker 管理的 S3 中,您可以使用控制台或 Python 命令(只需点击或者几行代码,设置实例类型等信息)的方式轻松完成模型的部署,部署之后的模型会以 HTTPS 的方式等待调用。如果在模型验证的过程中需要统计信息,SageMaker 节点支持蓝绿部署,方便您快速的重新部署和验证。
从框架预置、数据处理到模型训练、部署、验证,SageMaker 提供的流程中都帮助您完成了很多自动化的工作,从而使整个机器学习的过程更加敏捷和轻松;同时即起即用的方式不但缩减了整个过程的时间,也减少浪费、降低了成本。很多客户通过使用 SageMaker 大幅节约了模型训练与预测的时间,如 Coinbase 和 NFL,从而高效地将原先需要几个月完成的工作在几天内完成。
除了使用 SagaMaker 管理整个机器学习流程,提高整体环节效率之外,在 GPU 上还有可以提升的空间。通过 Amazon G4 实例,搭载 NVIDIA 最新的 T4 GPU,并针对需要使用基础 GPU 软件库的机器学习应用进行了优化,可以在提高机器学习效率的同时降低成本。而借助 Amazon Elastic Inference,您可以将低成本 GPU 驱动的加速附加到 Amazon EC2 和 Amazon SageMaker 实例,更进一步降低深度学习的推理成本。
## 小结
综上所述,使用 AWS 部署量化交易架构的最佳实践包括选择延迟最低的区域与可用区、单可用区部署并使用置放群组降低通信时延、使用 Deep Learning AMI 或 SagaMaker 节约模型训练与预测时间等。在此基础之上,您可以优化代码,使得判断与处理的用时更少,尽可能减少从交易信号出现到完成交易指令整个流程的时间,在瞬息万变的市场中赢得先机。
## 参考资料
2. AWS VPC 与 Subnet:https://docs.aws.amazon.com/zh_cn/vpc/latest/userguide/VPC_Subnets.html
3. AWS 终端节点服务使用文档:https://docs.aws.amazon.com/zh_cn/vpc/latest/userguide/endpoint-service.html
4. AWS 终端节点使用文档:https://docs.aws.amazon.com/zh_cn/vpc/latest/userguide/vpc-endpoints.html
5. EC2 置放群组:https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/placement-groups.html
6. Deep Learning AMI:https://docs.amazonaws.cn/en_us/dlami/latest/devguide/what-is-dlami.html
## 本篇作者
<footer>
!
AWS 解决方案架构师,负责基于 AWS 的云计算方案的咨询与架构设计,同时致力于 AWS 云服务知识体系的传播与普及。在网络、软件开发等领域有实践经验,加入 AWS 之前曾任软件开发工程师、Scrum master、项目经理等角色,PMI 认证 PMP。目前关注游戏、高性能计算等领域。
</footer>
<footer>
!
AWS 解决方案架构师,负责基于 AWS 云平台的解决方案咨询和设计,尤其在大数据分析与建模领域有着丰富的实践经验。
</footer>
<footer>
!
### 原野
AWS 资深客户经理,负责区块链行业。
</footer>

本文转载自 AWS 技术博客。

原文链接:
https://amazonaws-china.com/cn/blogs/china/overview-of-quantitative-transaction-business-architecture-on-aws/

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布