作者majorinche·2021-10-12 14:38

容器云架构师·大型金融单位

某金融企业基于容器云平台采用联邦学习技术提高风控效率实践

字数 6710阅读 9544评论 10赞 17

# 摘要
容器云平台的弹性能力以及对微服务的支持，对于提升企业内部的资源使用效率和主流应用的快速发布有着重大意义。本文针对金融企业中，容器云平台的现实需求做出相关技术分析，给出相关模块的参考设计和实现方案，并结合企业生产实践，提出一些实践经验。

# 一、简介
传统的虚拟化技术，在资源使用率、灵活性和弹性方面提升度并不高。而容器云技术恰好可以比较好的解决这些问题，并且在微服务、DevOps、分布式等方面的天生具备优势，因此成为 云计算的基础架构的选择。借助于容器云的高效和可扩展等特点，以容器为代表的云原生技术能更大程度地发挥云计算的优势。

制约当前容器应用进一步深化发展的痛点与难点是：企业内部缺少跨越岗位壁垒、敏捷协作的新型IT团队，以及相应的更加开放的企业组织管理方式。同时，也是制约企业数字化转型进一步发展的一个核心关键因素。

目前，基于容器和k8s的基础架构已成为新一代应用开发的基础，也是实现数字化转型的关键。

目前我们实际业务场景中，小微商户的风险评估问题已成为制约银行业发展的一个主要障碍，同时由于数据隐私安全保护的要求，跨企业的数据合作受到限制。运用联邦学习技术，可以探索多方数据融合效果以及联邦学习算法的可行性，并对小微企业进行多维度评价，优化企业风险授信模型。

为此我们在容器云平台实现了针对隐私计算产品的部署和验证工作。我们目前关注的重点，主要包括了联邦学习相关产品的验证，以及基于英特尔® 软件防护扩展（英特尔® SGX）技术的TEE方案。

# 二、需求分析
## 1 弹性伸缩
传统方式下应用和基础环境资源（计算、网络、存储、监控等）是紧耦合的关系，都存在于同一台物理机中。而应用的扩缩容意味着物理机环境环境资源的扩容和缩容。基础环境的扩缩容耗时会非常长，因为涉及到非常多需要人工介入的环境，而且都是串行的，比如采购物理机、分配存储、网络调试、操作系统安装、网络策略开通、应用部署、监控审计部署、接入负载均衡等等。整个流程通常需要数周的时间。

通过IaaS、虚拟化、自动化工具大幅度缩减了基础环境资源扩容的时间，整个流程仍然需要数天时间，这对于真正需要弹性的应用来说还是不够块。

在容器云环境下，应用和基础环境是解耦的，应用的扩缩容不需要涉及基础环境的扩缩容，仅仅需要修改应用部署模板文件中的副本数，然后在容器云平台执行即可。容器云平台会根据副本数来自动创建或者删除副本，使得最终的副本数符合预期。整个扩缩容流程完成时间是秒级的。

这样当应用面临突发业务量增长，需要紧急扩容的时候，就可以非常快的完成，实现了真正意义上的弹性扩容。

## 2 微服务化
微服务的特点，就是迭代效率高、资源使用率高、单一微服务可自行扩容、单一微服务故障 对全局影响有限，所以应用微服务化是当前应用改造的一个重点方向。但是传统方式下的应用微服务化开发运营是缺乏体系支撑的，成本高昂、便捷性差。

容器云平台提供了一套成熟的支撑体系，可以很好的支撑应用的微服务化改造，成本低廉、便捷性好。在多个微服务中，仅仅对外部提供服务的微服务需要申请负载均衡，内部微服务之间的调用通过service机制即可实现。如果很多微服务都需要对外提供服务，也可以通过ingress将所有服务收敛到一个入口上，这样对负载均衡的需求数量就大幅度下降。容器化的微服务都是运行在一个计算机群内，可以共享计算节点，扩容、缩容都不需要申请虚拟机，资源的使用效率可以最高。

## 3 故障探测和恢复
传统方式下的应用故障判断、隔离和恢复完全依赖人工介入，耗时很长。比如一旦出现某个应用节点的故障，需要运维人员人工判断是哪一个节点出了问题，然后人工将该节点摘除。随后人工恢复故障节点，再恢复回去。这就导致很长的故障窗口期，对业务连续性并不友好。

容器云平台下，应用的故障判别、隔离和恢复完全自动化实现，无需人工干预。容器云平台提供一套应用服务的自主探测和处理机制，例如liveness和readiness探针工作方式，同时。当发现某个应用副本异常，会立即将其从svc摘除，之后自动调整故障副本，并在可用的节点上新建新的副本。当探测到新建副本已经可以提供服务后，会自动将新建副本挂载到svc下面。这种完全自动化的故障处理恢复机制为应用提供了故障自愈能力，将故障窗口期减小到最小。

## 4 资源使用率提升
使用物理机部署应用时，一个物理机部署一个应用，应用空闲时，会造成大量的CPU和内存资源闲置。

使用虚拟机后，一个物理机上可以虚拟出多个主机，可以部署多个应用，资源使用效率得到了很大的提升。虚拟机之间可以共享CPU，但是无法共享内存和存储，比如一个虚拟机申请了16GB内存和50GB存储，这些资源只能被这个虚拟机独占，无法和其它虚拟机共享。

容器的本质是进程，进程间是可以共享宿主机的CPU、内存、存储和网络，资源使用效率得到最充分的利用。当然做到这一点的前提是容器能够确保进程运行的基本资源不被抢占，资源层面实现良好的隔离性。同时允许设置资源使用配额上限，避免影响其它应用进程。

## 5 机密计算
隐私计算中，基于半同态加密的方法，我们可以针对训练过程中交互的中间结果进行加密后计算，保证梯度等敏感信息不外泄。但是随着特征维度和样本的增加，整体加密的规模和迭代次数将严重影响联邦训练的效率。从计算性能和资源消耗角度来看，半同态加密也难以满足复杂运算的需求。

机密计算可以通过在本地安全可信执行环境下对两方或多方数据进行非加密状态的模型训练，提高联邦学习的运算效率。

我们需要验证机密计算，尤其是在容器云环境下，在联邦学习场景下的实际落地可行性以及对联邦建模效率的提升，同时又不降低数据的安全性。

# 三、容器云平台建设架构设计
## 1 总体架构设计
**总体架构图如下：**
![](/home/attachment/202110/12/1252545_163402029369300.png)

整体应用层我们主要针对隐私计算产品，站点管理强调多个主从站点间的添加和删除，任务管理具体管理联邦学习任务，具体通信之间的请求路径我们通过路由表管理实现。在模型训练完成后，我们使用模型管理实现；针对机器学习中，文件较大的常见，我们使用文件管理针对大文件的上传和使用

镜像库的的设计主要考虑到各种镜像环境，包括常见的操作系统的依赖包，JAVA的依赖包，还有devops过程中产生的各种工件，这些我们设计了对象存储作为镜像库的后端存储

平台层，我们提供了多个不同用途的集群，包括生产容器云平台，开发容器云平台和测试容器云平台，其中开发和测试容器云平台位于同一个网络环境中，而与生产容器云平台我们使用网络专线实现可控的通信。

左边是管理工具体系，其中统一身份认证连接到公司内部AD域中，提供租户帐号的统一登陆和鉴权服务；DevOps工具链可以从AD域获取用户和权限，然后通过K8S API和镜像库API实现应用的自动化流水线发布。EFK日志系统用于存储容器应用的日志。指标监控主要获取容器的CPU，内存等常见资源使用情况，展示告警主要接收来自Prometheus的监控数据，提供统一视图、告警推送的能力。

右边是存储管理平台，我们设计了丰富的接口供容器云平台使用，包括常见的rbd，cephfs和对象存储。Nfs和iscsi虽然性能弱一些，主要为了兼容部分旧有的服务和应用的场景

## 2 机密计算节点支持
隐私计算的一个实现方向是硬件安全技术，即机密计算TEE

TEE是基于硬件方案实现，是计算设备主处理器上的一个安全区域，它可以保证加载到TEE内部的代码和数据的安全性、机密性以及完整性，正是这些机制使得可信计算成为可能。TEE提供的隔离执行环境支持：隔离执行、安全存储、远程认证等功能。TEE也解决了远程认证可信计算的问题，包括如何证明是可信计算，证明是合法的可信硬件，证明运行进程与程序一致等，其基本原理是先通过远程认证证明是可信计算环境，然后再传数据，最后各方可以保证进程堆栈和数据都保密的情况下完成计算，拿到计算结果。

Intel SGX方案满足了TEE需要的功能，包括远程认证、抗软件攻击、抗物理攻击、低权限等几个方面。相比较而言，SGX的优势是基于SGX的硬件隔离，保证代码运行在Enclave中并支持多线程并发，可被中断。并且可信计算基(TCB)只有CPU完全透明的内存加密，18条新指令。最后 Enclave本身没有特权，只能运行在用户态，并内置了内存保护机制。

## 3 后端存储实现
Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，根据使用场景可以划分为对象存储、块存储和文件系统服务。使用Ceph分布式存储作为容器云平台的后端存储，为应用提供持久化的数据存储能力。在生产和开发测试环境各部署一个Ceph集群，为所属数据中心的K8S集群提供持久化存储后端服务。在K8S集群中，我们创建相应的storage-provider控制器，包括rbd-provisioner和cephfs-provisioner，保证我们不必去手动创建pv或者pvc的信息，即可实现动态申请PVC。

## 4 指标监控和告警
每一个计算节点上会部署一个监控exporter。应用如需监控，需要在应用开发时，暴露一定的指标值，供后端监控节点使用。应用容器启动后，监控exporter会获得容器监控指标，prometheus会通过主动拉取的方式获取各个应用容器的指标值，并通过grafana呈现大屏的效果，并且设置对应的alertmanager去针对各个异常触发告警。
![](/home/attachment/202110/12/1252545_163402032028944.png)
**图片来源于prometheus官网**

## 5 日志处理
每个计算节点部署一个日志收集代理，该代理面向计算节点上所有的容器。如果应用容器需要抓取日志，我们使用filebeat收集容器日志或者宿主机的日志，然后发送给elasticsearch，并且在Kibana上也会呈现最终的效果。
![](/home/attachment/202110/12/1252545_163402035115458.png)

## 6 虚拟化的支持
从需求层面说，我们的容器云平台应该承接部分应用只能运行在虚拟机环境中，例如我们的隐私计算应用产品需要同时支持两种容器化部署方式，k8s和docker-compose，所以需要一定数量的虚拟机验证docker-compose的效果，我们不再选择传统的iaas平台作为虚拟化的承载，例如openstack，而是选择kubevirt作为虚拟化的平台

kubevirt主要由redhat发起并联合社区开发的开源项目，旨在云原生操作系统Kubernetes中运行和管理虚拟机，其技术基础主要基于KVM实现，以通用的qcow2镜像为基础，创建一个Centos的容器并推送到镜像仓库，宿主机拉取并启动容器

**有几个特点，也是我们选择的的考量点：**
一是访问方便，通过nodeport方式暴露虚拟机的访问方式，变化的只是端口，而宿主机IP地址可以采用一个，由于nodeport是绑定svc的，所以虚拟机多次重装，也不需要变更访问方式

二是创建速度很快，在各个计算节点镜像ready的前提下，一条kubectl apply命令就可以同时创建出POD，pvc,svc和ingress等资源对象

# 四、容器云平台实践经验
## 1 虚拟化方面
例如路由问题，由于kubevirt的虚拟机的网络栈是复用K8S的，所以路由更改，就不能简单通过route或者ip命令实现，需要在k8s层面去做，所以应用不能有太多复杂网络访问需求。

例如关闭问题，虚拟机的生命周期受到pod生命周期印象，如果pod关闭了，那么其代管的虚拟机vmi对象，状态变成completed了，所有数据也全部丢失

例如句柄问题，虚拟机本身需要较多的文件打开数，所以fs.max-files和ulimit等参数都需要提交设置后，否则虚拟机会因为宿主机的too many open files问题而自行关闭

## 2 配置管理方面
配置管理在我们实际工作，占据很大一部分，一旦集群或者应用发生异常，造成我们的配置丢失，配置成本上也是一个，所以我们一直努力探索如何把配置，不仅仅是持久化，更重要的是版本控制化，这样不仅仅是备份配置，更重要的记录变更的过程。

## 3 DevOps方面
一是域名访问的问题，我们开始默认使用域名的方式访问gitlab，这个在虚拟机环境下没有问题，Windows本地hosts文件建个映射，正常访问就好了。

但是当gitlab-runner建立新的stage时，有个初始化代码的过程，需要从gitlab拉取源码，这里会访问域名来进行初始化，但是域名有时候是无法解析的，不稳定，虽然可以通过更改coredns的configmap加入临时映射，但是效果欠佳

二是500报错的问题，这个问题很常见，我们的开始解决方式，是无脑重启，反正每次重启都能解决问题，后续为此我们做了较大的更新：一是启用域名访问的方式，使用nodeport方式访问；二是增加共享缓存的size；三是增加足够多的内存，Gitlab的特点是所有的进程都打包在一个容器中，也算是一个重应用，所以我们给了充足的内存

## 4 负载均衡
容器云平台正常提供了ingress的方式，部分应用，例如与合作站点的，基于grpc的通信不再支持ingress的通信，二是直接使用nodeport的方式进行通信

## 5 机密计算
我们通过开源的sgx-device-plugin插件，针对机密计算场景进行了测试验证。并给计算节点打标签的方式，然后在应用部署模板里指定nodeSelector或者亲和性的方式，实现在K8S集群应用sgx提供的隐私计算的能力，无需开启容器特权模式即可使用SGX，并支持自动获取EPC内存大小以及支持容器声明式EPC内存分配。

## 6 联邦学习
联邦学习本质上，也是一种分布式建模过程，其核心原理是，多方合作建模过程中，不交换原始数据，仅仅交换加密后的参数，以保护用户隐私。

而联邦学习的分布式特性使它的部署和使用具备一定的复杂性和难度。借助于k8s的弹性和可扩展的能力，和基于helm的便利性，我们实现了在k8s平台部署联邦学习产品，并使用云原生技术管理联邦学习集群并处理工作负荷。

使用k8s具备很多优势，包括：使用简单，免除了安装很多依赖库的烦恼；配置灵活，按需部署集群；适用于任意的云环境。

# 五、效果总结
在隐私计算产品开发过程中，引入DevOps的理念后，将源码构建，容器打包和应用发布以流水线形式管理，开发测试的效率大幅提升
![](/home/attachment/202110/12/1252545_163402038411125.png)
在联邦学习产品部署过程中，得益于helm与operator强大支持能力，我们通过yaml文件的配置，实现了按需申请以及释放资源的能力。
![](/home/attachment/202110/12/1252545_163402041071872.png)

后期还有几个方面需要我们持续研究，包括隐私计算的性能和管理问题：

例如对GPU等专用设备的纳管，隐私计算中，金融行业通用的同态加密方式，需要2048位密钥的大整数，而大整数的四则运算对计算能力有极大需求，所以GPU或者FPGA将会是考虑的重点。

例如横向扩展能力，横向扩展本身需要基础平台的支持，特别是有状态应用，配合k8s的hpa或者statefulset，可以设置某些阈值实现自动扩展计算节点的能力。

例如对于隐私计算产品在开发环境中流程的自动化，目前的部署虽然已经实现了helm自动化安装，但是还是不够快，在容器云环境中，我们还需要做的更快，才能突出容器云平台的敏捷性，例如一条命令或者一个控制器可以实现从集群部署，连通性验证，数据上传，性能验证，结果展示，集群销毁的全流程和全生命周期的实现。

例如容器云平台对于Intel SGX的支持，通过sgx-device-plugin的技术，将机密计算正式引入到我们的容器云平台中，丰富隐私计算的适应场景。

SGX 机密学习联邦学习云原生智能风控容器云平台 GPU 容器云 Kubernetes 负载均衡

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论10 条评论

15305419779zxy

主任山东大正公司
2021-11-09 21:21

现在实际问题是：小微商户的风险评估问题已成为制约银行业发展的一个主要障碍，同时由于数据隐私安全保护的要求，跨企业的数据合作受到限制。运用联邦学习技术，可以探索多方数据融合效果以及联邦学习算法的可行性，并对小微企业进行多维度评价，优化企业风险授信模型。本文通过几方面的介绍，对架构设计和提高数据的安全性有独特的见解，值得关注

shshiheng系统运维工程师北京
2021-10-28 13:52

非常有参考意义的实践经验，谢谢分享。

MapleLeafLJ研发工程师兴业银行
2021-10-26 17:27

感谢作者的分享，本文的内容对我们的容器云平台建设很有帮助。文中作者提到通过机器学习建立针对小微企业的风险授信模型，请问作者如何平稳地从传统模型过渡至机器学习训练的模型，如何做好与业务部门的沟通工作，以及训练模型效果如何呢？

笑笑

存储架构师华大基因
2021-10-26 09:25

作者的需求分析总结的很到位，目前各家金融企业的需求基本是: 1.弹性伸缩 2.微服务化 3.故障探测和恢复 4.提升资源使用率(物理机) 从架构图来看，作者所在公司直接使用ceph作为后端存储，而没有采用商业存储和ceph共存，这个体现了贵公司的实力和转型的决心。在虚拟化层面，作者公司采用kubevirt作为虚拟化平台，为大家去vmware提供了另外一个思路实践经验方面，作者直接说了结论，如果能采取"现象"+"错误图"+“排错思路”+“解决方法” ，应该会对大家更有帮助。感谢作者无私的分享。

ltzxlwj700m

系统工程师中*银行
2021-10-25 16:47

感谢作者的分享。本文讲了几个我个人比较感兴趣的点：EFK、联邦学习、容器云。关于联邦学习以及intel EGX技术的应用，希望作者再多发文章分享经验。现在云安全越来越重要，intel EGX技术在云安全中是否有一席之地？作者通过开源的sgx-device-plugin插件，针对机密计算场景进行了测试验证，能否告知验证结果如何，是否有效率提升，提升程度如何。

menglunyang

系统工程师中国银行
2021-10-23 15:24

感谢作者详细的分享。作者使用的容器云平台用到了很多成熟的容器技术，包括采用Ceph集群作为后端存储，prometheus监控告警以及ELK作为日志查询核心。对于我们建设容器平台有很大的指导意义。文章让我印象最为深刻的地方是机密计算这一部分，作者采用了开源的sgx-device-plugin插件，针对机密计算场景进行了测试验证，这是我之前从未考虑到的地方，对intel EGX技术也没有接触过，通过作者的分享，让我初步对intel EGX技术有了印象，期待作者后续的文章详细介绍intel EGX技术，以及采用intel EGX技术其他应用场景。最后请问作者在进行机密计算时使用到的资源大约是多少，加密解密对性能有大的影响。