Slack 近期完成了一项大规模数据平台改造：将其 Amazon EMR 数据处理流程中的 SSH 作业执行模式全面替换为基于 REST API 的统一调度架构。此次改造彻底移除了对生产集群的直接 SSH 访问，并将 700 多个 Airflow Operator 迁移到集中式作业提交系统中。Slack 希望借此提升平台在安全性、可靠性以及可观测性方面的表现，并统一管理分布在八个数据区域的数据处理任务。

在过去很长一段时间里，Slack 的数据平台依赖 Airflow 通过 SSH 直接连接 Amazon EMR 主节点来执行任务。这种方式在系统规模较小时简单直接，但随着越来越多生产工作流接入平台，问题开始逐渐显现。搜索索引构建、数据分析流水线等关键业务都依赖这种执行模式。到了 2024 年，基于 SSH 的任务执行已经遍布生产环境中的大量 EMR 集群，相关的运维和安全问题也随之放大。

由于 Airflow 需要直接访问生产集群，整个系统的攻击面被显著扩大。SSH 密钥的分发、管理和轮换也带来了持续的运维负担。与此同时，审计工作变得越来越困难。一次任务执行过程中产生的日志往往散落在多个系统中，排查问题时需要跨平台关联分析，成本较高。可靠性方面同样存在隐患。例如 SSH 连接中断后，任务有时仍在后台继续运行；而在基础设施不稳定的情况下，某些任务甚至可能悄无声息地失败，却无法被及时发现。

为了解决这些问题，Slack 构建了一套基于 REST API 的任务提交体系，其核心是内部编排平台 Quarry。在新的架构中，Airflow 不再通过 SSH 登录集群，而是通过 HTTP 接口提交任务。任务提交之后，系统会为每个任务分配唯一 ID，用于后续状态跟踪、查询和取消操作。这种方式将任务执行过程与客户端连接彻底解耦。同时，所有任务状态都集中管理，也让监控、审计和运维变得更加容易。

改造前后的架构对比（来源：Slack 博文）

从 SSH 迁移到 REST 还需额外的工程用于支持不同的工作负载类型。对于 Spark 和 Hive 任务，Slack 可以直接利用现有的 REST 化组件，例如 Livy 和 HiveServer2 来完成迁移。真正复杂的是那些执行任意 Shell 脚本的任务。为了解决这一问题，Slack 利用了 Apache Hadoop YARN 的 Distributed Shell 功能。该机制允许 Shell 命令运行在 YARN 管理的容器中，从而获得资源隔离、故障恢复以及统一调度能力，而无需依赖 SSH 登录节点执行。

整个迁移过程并非一次性完成，而是逐步推进的。Slack 先后在开发环境、预发布环境和生产环境中完成验证，并最终覆盖八个数据区域。由于每个区域的网络隔离策略和合规要求并不相同，迁移过程中也暴露出不少此前隐藏的问题。例如，团队发现 YARN 对虚拟内存的限制策略与 SSH 执行模式下的表现存在明显差异，而这一问题过去一直被掩盖着。他们还发现了一些跨账号网络连接问题，以及多个服务之间未被充分记录的隐式依赖关系。

沃尔玛高级软件工程师 Sudip Ghosh 对此评价道：

这不仅仅是一次安全层面的改进，更是在偿还一笔长期积累的技术债务。SSH 用来起步非常方便，但随着组织规模扩大，想要安全地扩展并实现一致的审计几乎是不可能的。

Slack 用三个季度完成了整个迁移项目，并且没有影响任何关键业务工作流的正常运行。迁移完成后，生产环境中的 EMR 集群已经完全取消 SSH 访问。借助 Quarry 的服务端任务管理机制，任务执行的可靠性得到提升；通过结构化日志和统一指标体系，可观测性也得到了增强。与此同时，这种基于 REST 的方式也大幅度降低了 Airflow 与 EMR 之间的耦合度，团队间的作业提交流程也得到了统一。Slack 表示，这一改造还为后续的 Spark on Kubernetes 计划铺平了道路。

为了降低风险，整个上线过程采用了渐进式策略。团队首先逐步废弃旧版 Operator，然后分阶段在不同环境中验证新方案。他们还专门构建了 Airflow 元数据仪表盘，用于追踪仍然依赖 SSH 的工作流，并通过跨团队协作持续推动迁移工作。

Slack 总结了几个重要经验：尽早梳理和验证网络拓扑结构、提前验证不同执行模式下的资源限制行为，以及在限制旧组件使用或推动大规模迁移时，充分且持续的沟通往往和技术方案本身同样重要。

查看英文原文：Slack Eliminates SSH in EMR Pipelines, Migrates 700+ Jobs to Rest-Based Architecture - InfoQ