GitHub, Autoscaling và Ngụy biện Thay thế Thành phần

Trong bài viết gần đây về sự cố GitHub, có một chi tiết quan trọng thường bị bỏ qua: đó là chính sách autoscaling trên dịch vụ gặp sự cố với Istio sidecar bị bão hòa. Bài viết này sẽ phân tích sâu về vấn đề này và chỉ ra một bài học lớn hơn về cách chúng ta tiếp cận độ tin cậy của hệ thống.

Autoscaling là gì và vì sao nó lại quan trọng?

Autoscaling là chiến lược tự động điều chỉnh tài nguyên (compute, memory) dựa trên tải hiện tại của dịch vụ. Thay vì phải cấp phát tài nguyên cho mức tải cao nhất (peak load), autoscaling giúp hệ thống linh hoạt hơn, tiết kiệm chi phí và phản ứng kịp thời với sự thay đổi của lưu lượng truy cập.

Để sử dụng autoscaling hiệu quả, bạn cần xác định:

• Metric đại diện cho tải (thường là CPU utilization hoặc số lượng request)
• Quy tắc thêm/bớt tài nguyên dựa trên sự thay đổi của metric đó

Sai lầm trong chính sách autoscaling của GitHub

Theo báo cáo sự cố, chính sách autoscaling của dịch vụ bị ảnh hưởng chỉ theo dõi tải trên chính dịch vụ đó mà không tính đến giới hạn của Istio sidecar. Điều này dẫn đến việc sidecar bị bão hòa về concurrency nhưng hệ thống không kịp mở rộng thêm pod.

Đây là một ví dụ điển hình về việc CPU utilization không phải lúc nào cũng là metric tốt nhất. Tác giả dẫn chứng trường hợp của Slack năm 2021, khi dịch vụ bị bão hòa do các thread bị block chờ I/O nhưng CPU vẫn ở mức thấp. Trong trường hợp đó, Slack đã phải thêm quy tắc scale dựa trên số lượng thread để xử lý kịp thời.

Mỗi chính sách autoscaling là một "hệ thống điều khiển" riêng biệt

Mỗi dịch vụ có hành vi khác nhau dưới tải, nghĩa là mọi chính sách autoscaling đều được "thiết kế riêng" - Lorin Hochstein

Điều này tạo ra một thách thức lớn: đội ngũ sở hữu dịch vụ không chỉ phải lo về business logic mà còn phải chịu trách nhiệm vận hành một hệ thống điều khiển với các tham số tùy chỉnh, chỉ có thể kiểm tra qua load testing. Và hầu hết họ không phải là chuyên gia autoscaling. Vì vậy, việc xảy ra lỗi cấu hình là điều không quá bất ngờ.

Ngụy biện thay thế thành phần - Bài học lớn hơn

Tác giả nhấn mạnh rằng chúng ta dễ rơi vào ngụy biện thay thế thành phần (component substitution fallacy) - quan niệm rằng muốn cải thiện độ tin cậy thì chỉ cần tập trung tìm và sửa các thành phần lỗi.

Tuy nhiên, có hai sự thật quan trọng:

1. Hệ thống của bạn đang chứa đầy các lỗi tiềm ẩn ở các thành phần mà bạn chưa phát hiện ra
2. Dù có những lỗi này, hệ thống vẫn không liên tục sụp đổ

Nếu chỉ riêng lỗi thành phần là đủ để làm sập hệ thống, thì hệ thống của bạn đã sập ngay bây giờ rồi. Thay vào đó, hãy xem sự tương tác giữa các thành phần là yếu tố hạng nhất. Trong sự cố GitHub, chúng ta thấy sự tương tác giữa:

• Thay đổi mô hình lưu lượng (bao gồm cả scraper)
• Chính sách autoscaling
• Sự bão hòa của Istio sidecar
• Logic retry
• Sự bão hòa của HAProxy node
• Lưu lượng xác thực

Những câu hỏi quan trọng không có trong báo cáo công khai

Báo cáo sự cố công khai thường không đầy đủ. Một số câu hỏi quan trọng chỉ có thể trả lời qua báo cáo nội bộ:

• Chính sách autoscaling này có tồn tại trước khi sử dụng Istio sidecar không?
• Lưu lượng bất thường là loại request nào? Tăng đột ngột hay từ từ?
• Tại sao lưu lượng lại tăng?

Bài học cho các tổ chức: Đừng chỉ dừng lại ở việc đọc báo cáo sự cố công khai. Hãy tự đặt câu hỏi cho các sự cố nội bộ của chính mình. Chính những câu hỏi đó sẽ giúp bạn hiểu sâu hơn về hệ thống và cải thiện độ tin cậy một cách bền vững.

---

Lưu ý cho độc giả Việt Nam: Autoscaling là một khái niệm quan trọng trong vận hành hệ thống cloud-native. Nếu bạn đang sử dụng Kubernetes hoặc các nền tảng cloud như AWS, Google Cloud, Azure, hãy dành thời gian kiểm tra lại chính sách autoscaling của mình - đặc biệt là với các thành phần sidecar như Istio hay Envoy.