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

背景介绍

在数字金融体系中，许多客户都充分利用AWS快速、稳定的全球基础设施构建他们的业务，优化访问、分析和决策的效率，提高业务扩展的弹性，完善业务运行的稳定性。同时在高频交易场景中，无论是行情数据同步、预测分析还是决策下单，速度都是至关重要的因素。本文总结了一些量化交易场景下可以借鉴的最佳实践，帮助您更好的使用AWS服务。

选择延迟最低的部署位置

AWS的基础设施遍布全球，为客户的业务部署提供了丰富的选择空间。到目前为止，AWS在全球 22 个地理区域（Region）内运营着 69 个可用区（Availability Zone），每个可用区内包含多个数据中心，这些数据中心、可用区和 AWS 区域之间都通过高可用、低延迟的私有网络基础设施进行互连，使得所有AWS资源之间的访问快速、稳定。借助AWS全球资源和网络，量化交易架构可以快速部署、稳定运行，获得最低的访问延迟，并实现灵活的迁移和扩展。

对于高频交易来说，访问延迟决定着交易的结果是否能达到预期。如果您要访问部署在AWS上的金融服务，使用AWS意味着请求会通过AWS骨干网络到达您要访问的客户端，与请求在Internet中传输相比延迟更低、稳定性更高；如果服务部署在与客户端所在区域相同的区域，那么延迟会更低，同一区域内资源互访的延迟只有几毫秒；为了提高可用性，每个区域的不同可用区相隔一定距离（100公里以内），互相之间完全隔离，如果您将AWS资源与请求对端的资源部署在同一可用区，请求发生在同一可用区内，延迟将降到最低。

图示：使用AWS之外的资源访问AWS上部署的服务时，需要经过复杂的网络环境，可能产生较多延迟。

图示：使用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的工作方式如下图。

那么如何使用PrivateLink呢？接下来向您介绍PrivateLink的使用步骤。

1. API服务提供方：创建终端节点服务

首先对于API服务的提供方（如交易所），需要基于网络负载均衡器创建终端节点服务。由于PrivateLink提供的是私有链接，网络负载均衡器也建议使用面向内部的模式。打开AWS控制台，选择VPC服务，在左边栏中选择终端节点服务（Endpoint Services），点击【创建终端节点服务】按钮，进入终端节点服务的创建页面。

选择之前创建好的网络负载均衡器，点击【创建服务】按钮，很快终端节点服务就创建好了。

2. API服务提供方：授予连接权限

创建好的终端节点服务默认情况下只有本账户可以申请建立连接，在API服务提供方给服务使用方的账户赋予权限之后，相应使用方才能申请建立连接。

在控制台中选择上一步创建的终端节点服务，点击【白名单委托人】标签，然后点击【将委托人添加到白名单中】按钮，在新页面的ARN框中填写API服务使用方提供的IAM用户ARN，格式为arn:aws:iam::AWS_ACCOUNT_ID:IAM_USER，其中的AWS_ACCOUNT_ID为服务使用方的aws账户ID，IAM_USER为服务使用方用于配置的IAM用户名称。填写完成后，点击【添加到白名单委托人中】按钮，完成添加，之后API使用方就可以搜索到这个终端节点服务。

之后将【服务名称】发送给API服务使用方，服务使用方（交易团队）就可以使用服务名称申请私有连接。

3. API服务使用方：创建终端节点

然后对于服务使用方，打开AWS控制台，选择VPC服务，在左边栏中选择终端节点（Endpoint），点击【创建终端节点】按钮，进入终端节点的创建页面。在服务类别中选择【按名称查找服务】，输入从服务提供方获取到的服务名称com.amazonaws.vpce.REGION.xxxxxx，点击验证，会弹出VPC和安全组的选项。选择相应服务器所在的VPC及子网，选择一个开放相应端口的安全组，点击【创建终端节点】按钮完成创建。

刚刚创建完成时，终端节点的状态显示为【待接受】，是因为大部分终端节点服务会设置需要服务提供方允许才能连接。此时联系服务提供方，让他们在终端节点服务中找到相应的申请，接受连接请求。在终端节点的详细信息中，会有多个DNS名称，分别是统一DNS名称和每个子网对应的特定DNS名称，复制第一个DNS名称，用于之后的连接。

4. API服务提供方：接受连接申请

此时，API服务提供方在终端节点服务页面的【终端节点连接】选项卡下，可以看到使用方提出的终端节点连接请求。点击【操作】按钮，再点击【接受终端节点连接请求】，即可开始自动创建连接。

5. API服务使用方：连接创建完成

从API服务提供方处确认接受请求后，终端节点的状态会变为【待处理】，此时会自动在VPC中创建相应的网络接口（ENI），几分钟后网络接口创建完成，终端节点的状态会变为【可用】，此时私有连接就创建完成了。

现在可以测试一下创建好的私有连接了，登录服务使用方（交易服务器生产环境）的VPC中的一台EC2设备，访问之前复制的终端节点DNS名称，能看到相应的结果，代表终端节点服务已经正常使用。

基于上述考虑，降低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中，从而在缓存集群故障时能快速恢复服务。

在业务系统有多台服务器的情况下，选择EC2置放群组可以进一步降低服务器之间的访问延迟。在集群类置放群组模式下，服务器会部署在同一可用区中尽可能近的位置，集群内任意一台服务器都可以以最小时延/最高带宽与该置放群组内的所有其他节点进行通信。要使用集群置放群组，可以在创建EC2的第三步【配置实例详细信息】的时候进行设置，选择添加到新的置放群组并命名，选择模式为cluster；之后的实例就可以放在创建好的置放群组中，从而降低这些实例之间的通信延迟。

节约模型训练与预测时间

如果您的量化交易逻辑涉及到机器学习的分析和预测，那么节约模型预测的时间也会是整个量化交易过程中的重要一环。除了尽可能优化预测逻辑之外，节点部署上同样建议使用单可用区部署，并使用置放群组使得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 可以轻松在生产环境中一键式部署您的模型，以便您可以开始针对实时或批量数据的预测。

如上图所示，您的原始数据可以汇聚到S3构建的数据湖中，在使用SageMaker时，快速启动一台轻量级的笔记本实例（如T2.medium，以很低的成本完成整个流程的管理和控制），打开Jupitar Lab，在其中选择您喜欢的框架（常用框架已经预置在笔记本实例中），然后轻松开始数据的预处理和模型训练等工作，节约安装框架、调试的时间。

在完成数据的预处理之后，您只需通过几行代码，调用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节约模型训练与预测时间等。在此基础之上，您可以优化代码，使得判断与处理的用时更少，尽可能减少从交易信号出现到完成交易指令整个流程的时间，在瞬息万变的市场中赢得先机。

参考资料

1. AWS全球基础设施：https://thinkwithwp.com/cn/about-aws/global-infrastructure
2. AWS VPC 与 Subnet：https://docs.thinkwithwp.com/zh_cn/vpc/latest/userguide/VPC_Subnets.html
3. AWS 终端节点服务使用文档：https://docs.thinkwithwp.com/zh_cn/vpc/latest/userguide/endpoint-service.html
4. AWS 终端节点使用文档：https://docs.thinkwithwp.com/zh_cn/vpc/latest/userguide/vpc-endpoints.html
5. EC2置放群组：https://docs.thinkwithwp.com/AWSEC2/latest/WindowsGuide/placement-groups.html
6. Deep Learning AMI：https://docs.amazonaws.cn/en_us/dlami/latest/devguide/what-is-dlami.html
7. Amazon Sagemaker：https://thinkwithwp.com/cn/sagemaker/
8. Amazon G4实例介绍：https://thinkwithwp.com/cn/ec2/instance-types/g4/
9. Amazon Elastic Inference介绍：https://thinkwithwp.com/cn/machine-learning/elastic-inference/

本篇作者