Advancing Our Chef Infrastructure

Slack · 2024 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 1 của chuỗi ba bài về hạ tầng EC2 của Slack: phần 2 Slack 2025 · phần 3 Slack 2026.

Bối cảnh

• Slack quản lý hàng chục nghìn instance EC2 (Vitess, worker Kubernetes, nhiều thành phần ứng dụng), đa số Ubuntu, một phần Amazon Linux, cấu hình bằng Chef.
• Thời đầu: một stack Chef (EC2 + ALB + RDS + OpenSearch), scale lên và ra theo nhu cầu; ba môi trường Sandbox, Dev, Prod trên cùng stack. Cookbook nội bộ upload đè cùng phiên bản, nên mọi môi trường nhận thay đổi cùng lúc mỗi giờ: một thay đổi hỏng có thể làm hỏng mọi lần chạy Chef và mọi lần dựng máy mới; stack Chef là điểm hỏng chung.

Thay đổi chính

• Nhiều stack Chef (shard): instance mới hỏi một bản ghi CNAME có trọng số của Route53 để được gán vào một stack; tách hẳn stack dev và prod. Stack nào hỏng thì dồn máy mới sang stack còn lại.
• Hệ quả của việc shard:
  • Tìm hàng xóm: cookbook dùng Chef search (ví dụ node có role X ở region Y), nay chỉ thấy node trong một stack. Chuyển sang đăng ký service vào Consul; nhưng gọi Consul phải qua mạng overlay Nebula, mà Nebula lại do Chef cấu hình (vòng phụ thuộc), nên logic tra cứu phải chạy trong ruby_block ở pha converge (kèm lazy), không ở pha compile.
  • Chef làm inventory: nhiều công cụ dùng Chef làm kho thông tin node; viết Shearch (chạy query trên mọi shard rồi gộp) và Gnife (thay knife), sửa nhiều công cụ nội bộ.
  • Upload cookbook: chạy nhiều bản DishPig (mỗi stack một), fan-out qua SNS → nhiều SQS; message tới lệch giờ làm các stack có phiên bản cookbook khác nhau.
• Chef Librarian: mỗi lần merge, GitHub Actions đóng tarball cả repo, đặt phiên bản YYYYMMDD.TIMESTAMP.0, đẩy S3; Librarian upload phiên bản mới lên mọi stack nhưng chưa môi trường nào dùng. API cập nhật một môi trường lên một phiên bản, hoặc theo môi trường khác; trạng thái lưu DynamoDB; giao diện xem commit nào ở đâu; app Slack báo người viết khi thay đổi của họ được promote.
• Promote theo lịch có chặn: một CronJob Kubernetes promote sandbox → dev → prod, nhưng trước đó kiểm một key trong S3; khi thấy lỗi ở sandbox/dev, người trực đặt key để chặn (hiện làm tay, mục tiêu là tự động theo metric). Role không có phiên bản nên rút gần hết logic khỏi role.

Vì sao

• Một stack và một phiên bản cho mọi môi trường nghĩa là mọi thay đổi có vùng ảnh hưởng toàn hạ tầng; phiên bản hoá artifact là điều kiện để promote từng bước (Deploy và release an toàn).

Bài học cho SWE

• Hệ quản lý cấu hình cũng là hệ production cần shard và cần đường promote, không chỉ ứng dụng.
• Shard một hệ thường làm vỡ các công dụng phụ của nó (ở đây là inventory và service discovery); kiểm kê ai đang dựa vào nó.
• Upload phiên bản bất biến lên mọi nơi trước, rồi chỉ đổi con trỏ môi trường; có công tắc chặn promote (Tự động hoá vận hành và auto-remediation).

Liên quan

• Slack 2025 · Slack 2026 · Slack 2023 · Slack 2020
• Deploy và release an toàn · Tự động hoá vận hành và auto-remediation