一种使用 AWS 云原生服务部署高可用 APACHE AIRFLOW 集群的方案

背景介绍

很多机器学习、数据湖、自动驾驶项目都会用到 Apache Airflow ， Apache Airflow是一个以编程方式创作、安排和监控工作流的平台， 它将工作流创作为任务的有向无环图 ( DAG )， 调度程序遵循指定依赖项来执行任务， 丰富的用户界面使生产中运行的管道可视化、进度监控和问题定位变得容易。当工作流被定义为代码时，它们变得更加可维护、可版本化、可测试和协作。任何具有 Python 知识的人都可以部署工作流。 Apache Airflow 不限制管道的范围， 您可以使用它来构建 ML 模型、传输数据、管理您的基础架构等等。

在 AWS 上，可以用托管服务 Amazon Managed Workflows for Apache Airflow (MWAA) 来很方便的创建一套 Apache Airflow 集群， 从而免去了重复繁重的集群搭建和维护等工作。但是目前并不是所有 AWS 区域都已经发布此托管服务，比如, 西云数据运营的 AWS （宁夏）区域和由光环新网运营的 AWS （北京）区域。在单机（例如， Amazon EC2  ）上面可以快速的搭建一套 Apache Airflow 系统， 但是此安装方式难以扩展， 可靠性不高， 安全保护缺失， 没有监控和告警， 运维和维护都很困难， 用于业务PoC 还行， 但是无法用于实际项目上。另外，在实际业务中， 还需要考虑如何实现用户登陆和鉴权， 这通常会花费开发人员很大一部分精力。

对于无法使用 AWS MWAA 托管服务，或者想使用特定 Apache Airflow 版本， 或者想定制 Apache Airflow 登陆、部署方式的用户，本博客介绍的方案可以很方便的创建一套高可用的 Apache Airflow 集群， 包括日志、监控、告警等， 方便运维和维护， 同时遵循AWS 安全的最佳实践， 避免使用数据库默认端口， 数据库数据加密存储等等。另外，此方案还提供了两种登陆方式， AWS Credentials 登陆和 OAuth 单点登陆， 可以有效减少相关的集成工作。

方案设计

Apache Airflow 集群基本架构

下面重点介绍一下如何通过 AWS 云原生服务来构建一套高可用的 Apache Airflow 集群，详细架构见下图。

( 1 )  Apache Airflow由4个部分组成，分别是Webserver、Scheduler、Worker、Flower，通过 Amazon Elastic Container Service（Amazon ECS） 进行部署、管理和自动伸缩容，底层计算资源采用AWS Fargate 无服务计算引擎，您无需预置和管理服务器。每个组件在 Amazon ECS 上面都有一个对应服务，每个服务可以设定最大、最小任务数量、每个任务所需要的 CPU 和 Memory 资源以及自动扩容的触发条件（例如，CPU使用率超过70%）等， Amazon ECS 会根据集群负载动态调整资源的分配与释放。每个任务对应一个容器实例， 由 Amazon ECS 统一负责启动、运行、编排与调度。

( 2 )  在每个任务所对应的容器实例上，会挂载一个同样的Amazon Elastic File System （Amazon EFS）， 用于 Apache Airflow  4个组件之间共享文件，特别是 Apache Airflow 正常工作运行所需要的DAG（有向无环图）工作流文件，Plugin文件，安装 python 依赖库所需要的requirements.txt 文件。

( 3 )  Apache Airflow 集群的元数据、工作流任务和用户账号资料等信息通过 Amazon Aurora PostgreSQL 数据来存储，为了确保系统的高可用性和信息安全，默认采用了  Amazon Aurora PostgreSQL  多可用区部署方式，数据库在每个可用区中运行，并已设计为具备高可靠性。 万一发生基础设施故障，  Amazon Aurora PostgreSQL  可自动故障转移至备用实例中，以便您能够在故障转移结束后立即恢复数据库操作。本解决方案也支持  Amazon Aurora Serverless  数据库集群的选项， Amazon Aurora Serverless  会根据应用程序的需求自动启动、关闭以及扩展或缩减容量，让您无需管理任何数据库实例，即可在云中运行数据库。

( 4 )  为了满足 Apache Airflow Worker 组件的横向扩展，Executor 采用CeleryExecutor 模式，用 Amazon Elasticache for Redis  来作为其后端，存放待执行或者已经执行命令的状态，并用作他们之间消息传递的broker。  Amazon Elasticache for Redis 采用主从多可用区部署模式，当主节点失败后自动切换到从节点，从而保证整个集群的高可用性。同时，采用 Auth 认证的方式执行 Redis 命令，提高了 Redis 集群的安全性。

( 5 )  Apache Airflow 四个组件的运行日志以及 DAG 工作流执行所产生的日志，容器、数据库等 Apache Airflow 集群所依赖的基础设施运行指标（CPU，内存，伸缩容，网络等）也都会上报到 Amazon CloudWatch，方便统一查看，结合 Amazon Simple Notification Service ， 业务可以定制自己的运维指标看板和告警。

( 6 )  在日常工作中，企业会根据业务需要开发新的 DAG （有向无环图）工作流或者对原先的工作流进行更改，此方案在 Apache Airflow 的基础上开发了一个Sync组件， 工作流开发人员只需将DAG文件上传到代码仓库， 后面会自动触发执行 CI/CD 部署流程， DAG 文件若有更新， 则会自动同步到 Apache Airflow 集群并生效。

( 7 )  安全是企业业务的基石， Apache Airflow 集群用到的 Webserver Secret Key ，数据库密码和Redis密码，  都通过AWS Secrets Manager进行存储和保护，程序动态进行获取， 避免了写死在代码里面、环境变量传递等不安全的使用方式。

AWS Credentials 登陆方式架构

上面章节介绍了Apache Airflow 集群的基本结构以及主要功能，下面介绍用户如何登陆和使用Apache Airflow，这就涉及到一个用户鉴权和认证的过程。我们先介绍一种比较简单的方式，不需要太多的前置依赖。

( 1 )  在Apache Airflow集群的前面增了一个 Amazon Application Load Balancer(Amazon ALB) ，部署在私有子网(Scheme为internal)， Apache Airflow的Webserver组件挂在 Amazon ALB 后面，外部系统是不可以直接访问 Apache Airflow 和 Amazon ALB 的， 从而保证了整个系统的安全。

( 2 )  Apache Airflow集群的用户在本地计算机安装 AWS Command Line Interface 和 AWS Session Manager Plugin， 配置好 AWS credentials， 借助 AWS Systems Manager Session Manager 的 Port Forwarding 和 Tunneling 技术, 将本地计算机的端口 Forward 到 Apache Airflow Webserver 的端口，从而可以通过本地浏览器正常登陆和使用 Apache Airflow 了。如何配置 AWS credentials ，请参照配置和凭证文件设置。

( 3 )  内部系统可以通过 Amazon ALB 进行Rest API 访问， Amazon ALB 作为Apache Airflow的负载均衡器。同时，通过 Amazon API Gateway 和 Customized Authentication Lambda 来对外提供Rest API 访问和认证授权服务，借助 Amazon API Gateway 的App Key和Usage Plan特性，可以对不同的 API 访问源进行请求和并发控制，架构如虚线部分所示。

OAuth 单点登陆方式架构

AWS Credentials 登陆方式比较简单，可以快速的搭建一套 Apache Airflow 集群，但是如果一个企业需要部署多套 Apache Airflow 集群，或者本身是一个 SaaS 系统，需要根据租户的数量创建多套 Apache Airflow 集群，这种方式显然是难以满足要求的。OAuth 单点登陆方式，可以有效的解决这种场景下的 Apache Airflow 登陆和鉴权。

( 1 )  在 Apache Airflow 集群前面增了一个 Amazon Application Load Balancer（Amazon ALB） ， 部署在公有子网( Scheme 为 Internet-facing )， 通过 Amazon Certificate Manager 管理和部署 Apache Airflow 自定义域名证书， 用于 Amazon ALB 的 Https 侦听器（TLS：443）中 SSL Certificate。Amazon Route 53 用于域名解析及 ACM 证书创建时验证。 Apache Airflow 的 Webserver 组件挂在 Amazon ALB 后面，外部系统可以通过 Amazon ALB 访问 Apache Airflow ， 用户认证鉴权逻辑放在 Apache Airflow 的 Webserver 组件中。

( 2 )  在通过 OAuth 单点登陆方式部署 Apache Airflow 集群前，需要有一个已经完成ICP备案的域名和提供 OAuth 认证集成的OAuth Provider（例如， Amazon Cognito， Keycloak， Openshift， Okta， Google， Azure 等等） 。

总结

对于需要在 AWS 上使用 Apache Airflow 但是 无法使用 AWS 托管服务 MWAA ， 或者想使用特定 Apache Airflow 版本， 或者想定制 Apache Airflow 登陆、部署方式的用户，可以通过此方案搭建高可靠的 Apache Airflow 集群，同时提供用户登陆和鉴权机制。此方案已在全球知名 Tier One 汽车供应商的高级辅助驾驶系统（Advanced driver-assistance system, ADAS）开发平台成功应用， 有兴趣的客户可以联系亚马逊云科技客户经理。

本篇作者