Rolling the Heroku Redis Fleet

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

Bối cảnh

Heroku quản lý hàng triệu database. Một lỗ hổng Redis bị cấm công bố (CVE-2018-11218) buộc nâng cả fleet Redis mà không được báo nguyên nhân cho khách. Plan trả phí có HA: standby nhân bản bất đồng bộ, tự thay primary khi hỏng.

Immutable infrastructure: không SSH sửa máy; đổi gì thì build image mới và thay máy. Theo Heroku, ở quy mô của họ cấu hình riêng từng máy là không khả thi, và lợi ích cho một khách phải đến với mọi khách.
Quy trình fleet roll: build và test image mới → thay toàn bộ standby bằng standby mới → lên lịch maintenance trong cửa sổ của từng khách (báo trước ít nhất ba ngày làm việc, khách có thể chạy sớm) → kiểm standby đã đồng bộ → cắt replication để standby nhận ghi → đẩy release đổi config var của app sang primary mới → bỏ primary cũ, tạo standby mới. Plan hobby thay dần sau.
Chống mệt mỏi on-call: fleet roll sinh nhiều page hơn do gặp edge case chưa tự động hoá; code chỉ lên lịch thay máy trong giờ làm việc của người đang trực; control plane giới hạn mức song song.
Xong toàn fleet trong năm tuần kể từ khi nhận thông báo lỗ hổng, sớm một tuần so với công bố.

Hai mục tiêu ngược nhau: vá lỗ hổng nhanh và giảm gián đoạn; quy trình rõ + automation để một lỗi nhỏ không chạm hàng nghìn khách.

Có sẵn standby và image bất biến thì vá bảo mật cả fleet là một lần failover có kiểm soát.
Lịch chạy automation nên theo giờ làm việc của người trực, không chỉ theo tải hệ thống.