SWE Wiki
Đăng nhập Nâng cấp
SWE Wiki › Bài tóm tắt › Spotify

Fleet Management at Spotify (Part 2): The Path to Declarative Infrastructure

Bài tóm tắt Spotify 2023 3. Quy mô lớn Độ khó: Trung bình

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

Phần 2: phần 1 Spotify 2023 · phần 3 Spotify 2023.

Bối cảnh

  • Spotify chuyển từ datacenter riêng lên GCP theo kiểu lift and shift: kiến trúc và quan hệ với hạ tầng gần như giữ nguyên, nên lựa chọn hạ tầng trên cloud rất khác nhau giữa team (tự chạy Cassandra, Kafka, Elasticsearch, Postgres như thời on-prem). Khuyến nghị thay đổi theo thời gian, nhưng không có cơ chế đưa hạ tầng cũ lên chuẩn mới. Lượng hạ tầng tăng theo cấp số nhân so với số kỹ sư; một team giữ hàng chục tới hàng trăm component, chuyển giao qua tái tổ chức.
  • Công cụ cấu hình theo máy (Puppet, Ansible) không hợp cloud: nên dùng dịch vụ managed; nhiều cấu hình không gắn với một máy (IAM, mạng, quan hệ subscription, backup, replication); không có máy sống lâu để hội tụ chậm.

Thay đổi chính

  • Ràng buộc chọn giải pháp: (1) GitOps: cấu hình nằm cùng source, được review, có lịch sử; (2) xem được lúc chạy: liệt kê mọi DB trong công ty, tìm cái vi phạm chính sách và chủ của nó, có break-glass cho SRE; (3) cấu hình là dữ liệu (YAML/JSON) chứ không phải code (HCL, Starlark, TypeScript), vì sửa dữ liệu bằng máy thì dễ, sửa code sao cho kết quả đánh giá ra đúng hạ tầng thì theo bài là khó như bài toán dừng; (4) nhập được hạ tầng sẵn có (hàng trăm nghìn resource) mà không đụng tới trạng thái hiện tại. Theo bài, Terraform không đáp ứng (2) và (3).
  • Chọn Kubernetes làm mặt điều khiển: mỗi loại resource là một CRD; chạy trên cụm Kubernetes riêng (operator nặng về API server, khác workload stateless nặng về node). Hơn 3.000 project GCP; một namespace cho mỗi project, một service account CI cho mỗi repo để giới hạn quyền.
  • Luồng: manifest trong repo được CI áp vào cụm (bước kpt kiểm và biến đổi nhẹ), chờ reconcile xong (ví dụ cache đã tạo) rồi báo kết quả vào log build và PR; build review chạy dry-run cho biết sẽ thêm/sửa/xoá gì. Tạo manifest qua plugin Backstage nhập resource sẵn có (Config Connector), plugin sinh manifest theo best practice, plugin IDE.
  • Quyền mặc định của user chỉ là đọc; sửa/xoá qua cơ chế break-glass.
  • Trừu tượng cao hơn: từ resource cloud thô dần sang resource tự định nghĩa do khoảng 20 operator nội bộ quản lý (DB managed, cache managed như Locus nhiều region, data job).

Vì sao

Bài học cho SWE

  • Muốn máy sửa cấu hình hàng loạt thì cấu hình phải là dữ liệu, không phải code.
  • Cần nhập được hạ tầng sẵn có vào mô hình mới mà không thay đổi nó; không thì không bao giờ phủ hết.
  • Đặt operator hạ tầng trên cụm riêng để không tranh API server với workload.

Liên quan

Quản lý fleet và migrate code hàng loạtTự động hoá vận hành và auto-remediationNền tảng nội bộ cho service (đường ray chung)
#Declarative infrastructure#Kubernetes CRD#Operator#Config Connector#GitOps#kpt#Backstage#RBAC break-glass#Lift and shift#Puppet

Được nhắc tới trong

Chủ đề (3)
Công ty (1)
Bài tóm tắt (2)