Slack 淘汰 SSH：700+ EMR 作业迁移至基于 REST 的调度架构

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