Slack 最近完成了一項大規模的資料平台現代化工程，將其在 Amazon EMR（Amazon Elastic MapReduce，一種用於處理大數據的託管叢集服務）管線中的任務執行方式，從傳統的 SSH 連線全面遷移至基於 REST API 的調度架構。這次遷移涉及超過 700 個 Airflow 任務操作符，涵蓋了全球 8 個資料區域。
為什麼要放棄 SSH 執行模式
在早期的設計中，Slack 使用 Airflow 作為工作流調度工具，透過 SSH（Secure Shell，一種加密的遠端登入協定）直接連線到 EMR 的主節點來執行指令。對初創或小型專案來說，這種方式非常簡單直接，但當系統規模擴大到數百個生產環境工作流（如搜尋索引、分析管線）時，這種做法會帶來嚴重的工程債。
首先是安全性風險。直接允許 SSH 存取生產叢集會大幅增加攻擊面。管理大量的 SSH 金鑰分發與定期輪換（Rotation）會產生巨大的維運壓力。其次是可觀測性不足，若要稽核某個任務的執行狀況，工程師必須在多個系統之間比對日誌，缺乏統一的追蹤手段。最後是可靠性問題，由於任務依賴於持久的連線，一旦網路波動導致連線中斷，任務可能會在後台持續運行而無法控制，或者在基礎設施不穩定時靜默失敗。
引入 Quarry：以 REST API 實現解耦
為了克服上述問題，Slack 開發了一套內部調度層，命名為 Quarry。其核心邏輯是將執行模式從 持久連線 轉變為 請求與回應。
現在，Airflow 不再直接登入伺服器，而是透過 HTTP API 向 Quarry 提交任務。每個任務在伺服器端擁有完整的生命週期管理，包括提交、透過 Job ID 追蹤進度以及受控的取消機制。這種設計將 任務提交者（Airflow）與 任務執行環境（EMR）完全解耦，即使客戶端連線中斷，伺服器端的任務依然能穩定運行並記錄狀態。
處理異質工作負載的技術方案
在遷移過程中，Slack 面臨的最大挑戰是如何處理不同類型的運算任務。對於 Spark 或 Hive 等大數據框架，可以直接利用 Livy 或 HiveServer2 等現有的 REST 介面。然而，許多舊有的工作流包含大量的任意 Shell 指令（Shell Commands），這些指令無法直接透過 API 呼叫。
為了解決這個問題，Slack 採用了 Apache Hadoop YARN 的 Distributed Shell 功能。YARN 是 Hadoop 的資源管理系統，而 Distributed Shell 允許在受管理的容器中執行 Shell 指令。這不僅解決了指令執行問題，還提供了資源隔離（Resource Isolation）與容錯能力，確保單一任務不會耗盡整個叢集的資源。
遷移過程中的陷阱與實務經驗
這次遷移跨越三個季度，在 8 個不同的資料區域逐步推進。在實作過程中，Slack 發現了兩個關鍵問題：
第一是資源限制的差異。在 SSH 模式下，某些虛擬記憶體（Virtual Memory）的強制執行行為被掩蓋了，但切換到 YARN 容器執行後，這些限制變得明顯，導致部分任務觸發記憶體不足而失敗。
第二是網路拓撲的隱藏依賴。在跨帳號的網路連線過程中，遷移揭露了許多先前未被察覺的服務間依賴關係，這要求團隊必須在正式切換前重新梳理網路拓撲。
總結與工程影響
透過這次重構，Slack 不僅消除了生產環境的 SSH 存取權限，大幅提升安全性，還透過結構化日誌與集中化指標強化了可觀測性。
對於工程師而言，這次遷移提供了一個重要的教訓：許多在初期為了快速開發而採用的 簡單方案（如 SSH 遠端執行），在規模化後往往會變成維運噩夢。將 基礎設施操作 API 化 是實現自動化可靠性與安全稽核的必經之路。此外，這次的 REST 化改造也為未來將 Spark 遷移至 Kubernetes (K8s) 奠定了標準化的基礎。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。