Scaling High-Availability Infrastructure in the Cloud

Twilio · 2011 · 2. Tăng trưởng · Độ khó: Cơ bản — bài gốc

Bài ngắn, tóm tắt một talk; chỉ có nguyên tắc, không có chi tiết hệ thống. Các bước sau của Twilio: Twilio 2014, Twilio 2017.

Ý chính (theo Twilio, 2011)

Five nines (99,999%) nghĩa là khoảng 5,26 phút downtime mỗi năm, 25,9 giây mỗi tháng. Ở mức đó, người không thể là một phần của vòng phát hiện và khắc phục: kể cả khi monitoring bắt được mọi lỗi và gọi đúng người, người trực không kịp mở máy, tìm lỗi, sửa trong năm phút. Hạ tầng HA phải tự phục hồi.
Thứ khó tự động hoá nhất là database và các thành phần có trạng thái, nhất là trên cloud, nơi không có phần cứng chuyên dụng tự failover. "Lưu trữ dữ liệu là bài toán kỹ thuật khó nhất của đa số SaaS cần scale."
Hai nguyên nhân downtime chính: lưu trữ dữ liệu và sai sót khi thay đổi (change control).
Vì sao lưu trữ khó: đổi schema phải ghi lại dữ liệu và index; phục hồi khó vì split-brain và thời gian khôi phục trạng thái; scale khó vì I/O trên cloud chậm hơn phần cứng; quản trị khó vì hệ quản lý dữ liệu rất phức tạp.
Khuyến nghị: tách rõ thành phần có trạng thái và không trạng thái; tránh lưu dữ liệu nếu được; dùng lưu trữ phi cấu trúc khi được; archive hoặc xoá mạnh tay dữ liệu không cần online; quy trình thay đổi có người duyệt rõ ràng; chọn công nghệ theo bài toán (SQL cho việc này, KV hay S3 cho việc khác).

Mục tiêu availability quyết định ai được ở trong vòng phục hồi: từ bốn số 9 trở lên thì phải tự động (Tự động hoá vận hành và auto-remediation).
Giảm lượng trạng thái là cách rẻ nhất để tăng availability; chọn kho dữ liệu theo từng loại dữ liệu (Chọn database theo workload).
Sáu năm sau Twilio mới tự động hoá failover cho queue Ratequeue (Twilio 2017): nguyên tắc có từ sớm, làm được cho từng hệ có trạng thái thì mất nhiều năm.