From SSH to REST: A Security-Driven Modernization of Slack’s EMR Data Pipelines

Bài tóm tắt Slack 2026 4. Điều chỉnh Độ khó: Trung bình

Slack · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bối cảnh

  • Data platform của Slack dựng khoảng 2017 theo cách đơn giản: Airflow cần chạy job trên cụm EMR thì SSH vào master node và chạy lệnh. Cách này lan ra khắp nơi; tới 2024 có hơn 700 job dùng operator dựa trên SSH, gồm cả job dựng index search Solr hằng ngày từ hàng TB dữ liệu.
  • Vấn đề:
    • Bảo mật: truy cập SSH thẳng vào cụm, phải phân phối và xoay vòng key, audit phải ghép log nhiều nơi, phân quyền phức tạp.
    • Vận hành: job chạy ngay trên master node nên tranh tài nguyên; pod Kubernetes của Airflow restart là đứt kết nối SSH, job hỏng; job chạy dài thành zombie sau khi kết nối mất; không biết chắc job thành hay bại khi mất kết nối.
    • Bị chặn: không thể bắt đầu Spark on Kubernetes hay EMR on EKS; không xong được dự án Whitecastle (dời hạ tầng AWS sang tài khoản con để cách ly).

Thay đổi chính

  • Nộp job qua REST: POST nhận job ID, GET xem trạng thái, DELETE để huỷ. Vòng đời job nằm ở phía server, client crash vẫn hỏi lại được.
  • Spark có Livy, Hive có HiveServer2. Khó nhất là MapReduce và hơn 300 job chạy lệnh shell tuỳ ý (aws s3 sync, hadoop distcp, script Python). Đã cân nhắc tự viết service chạy lệnh từ xa, dùng Ansible/Salt, hoặc tự tạo loại job mới trong YARN; đều bị loại vì phức tạp hoặc phải tự làm lớp bảo mật.
  • YARN Distributed Shell (tính năng ít người biết, có sẵn trong YARN): đưa script lên S3, nộp qua REST API của YARN, YARN cấp container, tải script và chạy, có giới hạn tài nguyên, cách ly, retry, huỷ sạch và log.
  • Quarry, gateway nộp job sẵn có của Slack (cho EMR/YARN, Trino, Snowflake), đứng giữa: xác thực bằng token giữa service thay SSH key, theo dõi trạng thái phía server, huỷ, log/metric/trace có cấu trúc.
    • Trước: Airflow → SSH → EMR master → chạy lệnh. Sau: Airflow → Quarry REST → YARN ResourceManager → container EMR.
  • Cách làm: PoC với job thí điểm → review bảo mật → đưa thành Key Result có lãnh đạo theo dõi (đạt 80% trong pha này) → migrate hàng loạt nhiều team song song → dọn DAG sót, khai tử operator SSH. Migrate theo loại operator, từng operator một; dev → GovDev/CommDev → prod; dashboard tiến độ bằng cách query DB của Airflow tìm task còn dùng SSH.
  • Con số: hơn 700 job, 7 loại operator, 8 data region độc lập (yêu cầu chủ quyền dữ liệu), 5 team, không downtime, xong trong 3 quý.

Sự cố gặp trên đường

  • Lỗi kiểm tra virtual memory: chạy qua SSH thì bỏ qua giới hạn tài nguyên của YARN; nộp đúng cách thì YARN chặn container vượt vmem. Tắt kiểm tra vmem theo khuyến nghị của AWS. Bài học theo Slack: SSH che nhiều vấn đề.
  • Phân tách mạng: job dời sang cụm ở vùng mạng chặt hơn bị timeout khi gọi dịch vụ quản lý khoá; lộ ra một phụ thuộc vào topo mạng không ghi ở đâu.
  • 8 region = 8 cuộc migrate song song, mỗi region có cấu hình, quy tắc dữ liệu, phiên bản cụm khác nhau; làm thí điểm ở một region rồi lan dần. Theo Slack: khó hơn N lần và mỗi region có kiểu lỗi riêng.

Kết quả

  • Bỏ hoàn toàn SSH vào cụm EMR production; xong Whitecastle; hết tranh tài nguyên trên master; job sống qua restart của pod Airflow, hết zombie; mở đường cho Spark on Kubernetes; Airflow tách khỏi chi tiết hạ tầng EMR.
  • Điều sẽ làm khác: vẽ topo mạng sớm hơn, test giới hạn tài nguyên ngay ở pha thí điểm, báo trước rộng hơn khi chặn dùng operator cũ.

Bài học cho SWE

  • Một lối tắt ban đầu (SSH vào master) lan theo đường dễ nhất cho tới khi nó chặn mọi hiện đại hoá phía sau (Pipeline dữ liệu và analytics).
  • Kết nối có trạng thái giữa bộ điều phối và job là điểm yếu: client restart thì không biết job ra sao. Nộp job kiểu "lấy ID rồi hỏi trạng thái" chịu được restart.
  • Migrate theo loại operator, có dashboard "còn bao nhiêu", chặn dùng cách cũ ở cuối là cách migrate nền tảng có nhiều người dùng (Migration không downtime).
  • Chuyển từ đường "bỏ qua kiểm soát" sang đường "đúng chuẩn" sẽ lộ ra giới hạn và phụ thuộc trước đây vô hình; test chúng sớm.

Liên quan