部署ML/DL 模型到一个consolidated AI演示

关键字：IRIS，IntegratedML，Flask，FastAPI，TensorFlow Serving，HAProxy，Docker，Covid-19

目的：

过去几个月里，我们提到了一些深度学习和机器学习的快速演示，包括一个简单的 Covid-19 X 射线图像分类器和一个用于可能的 ICU 入院的 Covid-19 实验室结果分类器。  我们还介绍了 ICU 分类器的 IntegratedML 演示实现。  虽然“数据科学”远足仍在继续，但从“数据工程”的角度来看，或许也是尝试一些 AI 服务部署的好时机 - 我们能否将目前所接触到的一切都封装成一套服务 API？  我们可以利用哪些常用的工具、组件和基础架构，以最简单的方式实现这样的服务堆栈？

范围

范围内：

作为快速入门，我们可以使用 docker-compose 将以下 docker 化组件部署到 AWS Ubuntu 服务器中

• HAProxy  - 负载均衡器
• Gunicorn vs. Univorn  - Web 网关****服务器
• Flask vs. FastAPI - Web 应用 UI 的应用服务器、服务 API 定义和热图生成等
• TensorFlow Model Serving vs. TensorFlow-GPU Model Serving - 图像等分类的应用后端服务器
• IRIS IntegratedML - 带有 SQL 界面的统一 App+DB AutoML
• Jupyter Notebook 中模拟客户端进行基准测试的 Python3
•  Docker 和 docker-compose
• 配备 Tesla T4 GPU 的 AWS Ubuntu 16.04 

注：配备 GPU 的 TensorFlow Serving 仅用于演示目的 - 您只需关闭 GPU 相关镜像(在 dockerfile 中)和配置(在 docker-compose.yml 中)。

范围外或者在下一个愿望清单上：

• Nginx 或 Apache 等 Web 服务器在演示中暂时省略。
• RabbitMQ 和 Redis - 用于可靠消息传递的队列代理，可由 IRIS 或 Ensemble 替代。   
• IAM (Intersystems API Manger) 或 Kong 在愿望清单上IAM (Kong 在愿望清单上
• SAM (Intersystems System Alert & Monitoring) SAM (Intersystems
• ICM (Intersystems Cloud Manager) 与 Kubernetes Operator - 诞生以来一直是我的最爱ICM (Kubernetes Operator - 诞生以来一直是我的最爱
• FHIR(基于 Intesystems IRIS 的 FHIR R4 服务器和 FHIR Sandbox，用于 FHIR 应用上的 SMART)
• CI/CD devop 工具或 Github Actions

“机器学习工程师”必然会动手遍历这些组件，在服务生命周期内提供一些生产环境。 随着时间的推移，我们可以扩大范围。

GitHub 仓库

完整源代码位于 https://github.com/zhongli1990/covid-ai-demo-deployment

integratedML-demo-template 仓库也与新仓库一同重用。  

部署模式

以下为此“Docker 中的 AI 演示”测试框架的逻辑部署模式。

出于演示目的，我特意创建了 2 个独立的堆栈，用于深度学习分类以及 Web 渲染，然后使用 HAProxy 作为软负载均衡器，以无状态方式在这 2 个堆栈之间分配传入的 API 请求。

• Guniorn + Flask + TensorFlow Serving
• Univcorn + FaskAPI + TensorFlow Serving GPU

IRIS 与 IntegratedML 用于机器学习演示示例，即 ICU 预测的前一篇文章中。

在目前的演示中，我省略了一些生产服务需要或考虑的常用组件：

• Web 服务器：Nginx 或 Apache 等 HAProxy 和 Gunicorn/Uvicorn 之间需要它们，以进行正确的 HTTP 会话处理，即避免 DoS 攻击等。
• 队列管理器和数据库：RabbitMQ 和/或 Redis 等，在 Flask/FastAPI 和后端服务之间，用于可靠的异步服务和数据/配置持久性等。  
• API 网关：IAM 或 Kong 集群，在 HAProxy 负载均衡器和 Web 服务器之间进行 API 管理，不创建单点故障。
• 监视和警报：SAM 很不错。
• 为 CI/CD DevOps 进行配置：云中立的部署和管理以及带有其他常见 devops 工具的 CI/CD 将需要带 K8s 的 ICM。

其实，IRIS 本身当然可以作为企业级队列管理器以及用于可靠消息传递的高性能数据库。 在模式分析中，很明显 IRIS 可以代替 RabbitMQ/Redis/MongoDB 等队列代理和数据库，得到更好的整合，大幅减少延迟，并提高整体性能。  还有，IRIS Web Gateway(先前为 CSP Gateway)当然可以代替 Gunicorn 或 Unicorn 等，对吧？  

环境拓扑

在全 Docker 组件中实现上述逻辑模式有几种常见选项。 首先：  

• docker-compose
• docker swarm 等
• Kubernetes 等 
• 带 K8s 操作的 ICM

这个演示从功能性 PoC 和一些基准测试的“docker-compose”开始。 当然，我们很想使用 K8s，也有可能随着时间的推移使用 ICM。 

如 docker-compose.yml 文件中所述，它的环境拓扑在 AWS Ubuntu 服务器上的物理实现最终将是：  

上图显示了如何将所有 Docker 实例的服务端口映射并直接暴露于 Ubuntu 服务器以进行演示。 在生产中应该全部经过安全加固。 纯粹出于演示目的，所有容器都连接到同一个 Docker 网络中；而在生产中，它将被分为外部可路由和内部不可路由。

Docker 化组件 

下面显示了主机中的那些存储卷如何按照这个 docker-compose.yml 文件的指示挂载到各个容器实例： 存储卷如何按照这个

ubuntu@ip-172-31-35-104:/zhong/flask-xray$ tree ./ -L 2

./
├── covid19                             (Flask+Gunicorn container and Tensorflow Serving container will mount here)
│   ├── app.py                                (Flask main app:  Both web application and API service interfaces are defi