The process: Implementing Yelp's failover strategy

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

Bối cảnh

• Yelp phục vụ từ hai region AWS ở hai bờ nước Mỹ. Request chỉ đọc (phần lớn traffic) đi tới region gần nhất, có logic cân tải giữa hai bên.
• Khi một region không khoẻ (cấu hình hạ tầng xấu, data store quan trọng suy giảm, hiếm khi là AWS), công cụ chính là failover: dời một phần (giảm áp lực để hệ hồi phục) hoặc toàn bộ traffic sang region còn lại. Thao tác chỉ là sửa một file YAML trong Git, nhưng ngay cả lúc khẩn cấp vẫn cần duyệt (on-call phụ, manager, hoặc kỹ sư trong sự cố). On-call diễn tập failover một phần và toàn phần đều đặn.
• Thời đầu, Yelp nhiều lần "làm chảy" region khoẻ vì dồn quá nhiều traffic quá nhanh. Scale lên mất vài phút khi mọi thứ ổn, mà vài phút đó không có; tệ hơn, một thay đổi cấu hình cấp thấp gần đây có thể làm chậm hoặc chặn việc cấp máy mới.

Thay đổi chính

• Giữ gấp đôi năng lực: gấp đôi số máy, nhưng không để máy ngồi không mà rải container trên mọi máy để mỗi máy chỉ dùng khoảng 50% tài nguyên lúc bình thường. Chi phí như nhau, mỗi host hỏng ảnh hưởng ít service hơn, hiệu năng ổn định hơn, và không phụ thuộc vào team compute lúc khẩn cấp.
• Năng lực dư nằm sẵn trong container: vẫn còn vài phút để lập lịch container mới, tải image, làm ấm worker, nên mỗi service tự chạy đủ container để chịu 2 lần traffic, mỗi container dùng đúng khoảng 50% tài nguyên được cấp. Failover chỉ còn tính bằng giây.
• Vấn đề: trong SOA, mỗi team tự cấu hình CPU, RAM, autoscaling của service mình; phần lớn team không có kiến thức để chỉnh chính xác tới 50%.
• Autotune: công cụ phân tích mức dùng và sinh giá trị tối ưu cho CPU, RAM, đĩa; giá trị đặt tay luôn thắng. Service bị kill vì hết RAM thì giá trị tối ưu được tự nâng trong vòng hai giờ, nhanh hơn thời gian trước đây mất để chẩn đoán. Chạy dạng gợi ý opt-in vài tuần, theo dõi chỉ số thành công, rồi chuyển thành mặc định ("autotuned defaults"). Kết quả phụ: giảm đáng kể chi phí compute nhờ thu nhỏ service cấp dư.
• Tổ chức: team production engineering nắm cấu hình mọi service (điều kiện để failover chắc chắn chạy), team compute tập trung vào nền tảng, developer không phải chỉnh tài nguyên.

Bài học cho SWE

• Failover chỉ an toàn nếu bên nhận đã có sẵn năng lực; scale lúc khẩn cấp là quá chậm và có thể hỏng (Độ tin cậy và multi-region).
• Headroom có thể "miễn phí" nếu rải đều thay vì để máy dự phòng ngồi không.
• Biến right-sizing thành mặc định tự động, đi từ gợi ý sang mặc định sau khi đo (Tự động hoá vận hành và auto-remediation, cùng hướng với Monzo 2020).
• Thao tác failover nên đơn giản (một file cấu hình) và được diễn tập đều.

Liên quan

• Độ tin cậy và multi-region
• Tự động hoá vận hành và auto-remediation
• Chi phí hạ tầng và build vs buy
• Cùng công ty: Yelp 2020, Yelp 2021