Active-Active for Multi-Regional Resiliency

Netflix · 2013 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài ngoài sheet, lấy để trả lời câu hỏi mở về active-active multi-region của Netflix. Phần trước: Netflix 2012.

Bối cảnh

• Theo Netflix, tỉ lệ hỏng phụ thuộc hai thứ: quy mô deploy và tốc độ thay đổi; chạy lớn mà vẫn đổi nhanh thì "lúc nào cũng có thứ hỏng". Mục tiêu nội bộ là 99,99%. Mất trọn một region rất hiếm, nhưng chính tốc độ thay đổi của họ đôi khi làm hỏng service quan trọng trong một region.
• Giữa 2013, dự án Isthmus đã chống được sự cố ELB toàn region (bài học từ đêm Giáng sinh 2012). Bước tiếp: active-active đầy đủ giữa us-east-1 và us-west-2, xong trong vài tháng.

Thay đổi chính

• Điều kiện: service trên đường gọi của user phải stateless (mọi sao chép trạng thái nằm ở tầng dữ liệu), chỉ dùng tài nguyên trong cùng region (ứng dụng ghi S3 phải ghi vào bucket của từng region), không có lời gọi xuyên region trên đường của user; sao chép dữ liệu bất đồng bộ.
• DNS (Denominator): UltraDNS định tuyến theo vùng địa lý (khoảng 50/50); một lớp Route53 phía sau để đổi traffic nhanh bằng cách chuyển CNAME. Không dùng định tuyến theo latency vì traffic sẽ dịch chuyển khó đoán.
• Zuul ở edge: phát hiện request đi nhầm region (giữ một phiên thiết bị trong một region), chế độ "failover" cho một region, và trần traffic tối đa: vượt trần thì trả lỗi ngay, để bảo vệ tầng dưới khi service đang scale lên hoặc cache region còn nguội (thundering herd khi chuyển traffic).
• Dữ liệu: mọi dữ liệu đọc/ghi phục vụ user nằm trong Cassandra nhân bản đa region. Thí nghiệm: ghi 1 triệu bản ghi ở một region, 500 ms sau đọc ở region kia dưới tải production, đọc được hết; theo Netflix, chưa phải test đầy đủ nhưng đủ tin cho use case của họ.
• Cache: không làm multi-master cho memcached mà thêm vào client EVCache khả năng invalidate từ xa: mỗi lần ghi ở một region, gửi message (qua SQS) sang region kia để xoá entry; lần đọc sau ở đó tự tính lại hoặc rơi xuống Cassandra.
• Deploy: môi trường tăng lên sáu (Test/Prod × ba region); công cụ workflow Mimir khai báo mục tiêu đa region, cộng canary analysis và rollback tự động, chờ nhiều giờ giữa các region để bắt lỗi trước khi phủ toàn cầu.
• Diễn tập: Chaos Gorilla (mất một AZ), Split-brain (cắt kết nối giữa region, chạy nhiều lần, tìm và sửa nhiều lỗi), Chaos Kong (dồn phần lớn traffic sang us-west-2, chuyển chậm hơn lúc khẩn cấp để service kịp scale và cache kịp ấm; giữ hơn 24 giờ rồi chuyển dần về 50/50).
• Trước khi Chaos Kong xong đã có một failover thật: một hệ middle tier ở một region suy giảm nặng, traffic được chuyển sang region khoẻ và chất lượng hồi lại trong thời gian ngắn.

Vì sao

• Cô lập và dự phòng ở mức region: hỏng bất kỳ kiểu nào ở một region không được ảnh hưởng region kia. Theo Netflix, phần phi kỹ thuật (làm song song với nhiều dự án khác) còn khó hơn, và họ dựa vào việc AWS cấp thêm capacity ở us-west-2 nhanh.

Còn lại (theo Netflix)

• Phase 2: tự động hoá các bước thủ công, rút ngắn thời gian ra quyết định failover và thời gian chuyển hết traffic.
• Bài toán khó hơn: dependency chậm hoặc lỗi chỉ một phần thời gian; họ dùng Latency Monkey để tiêm latency và lỗi theo phân phối.

Bài học cho SWE

• Active-active đòi kỷ luật ở tầng ứng dụng: stateless, tài nguyên cục bộ, không gọi xuyên region trên đường nóng; sao chép dồn về tầng dữ liệu.
• Chuyển traffic sang region kia là tự tạo thundering herd lên cache nguội và service chưa scale: cần trần traffic ở edge và chuyển từ từ.
• Cache đa region có thể giữ đơn giản bằng invalidation xuyên region thay vì sao chép dữ liệu cache.
• Chỉ tin được failover đã diễn tập ở production, kể cả kịch bản cắt mạng giữa region.

Liên quan

• Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định)
• Netflix 2011 → Netflix 2012 → bài này → Netflix 2016
• Netflix 2018 (EVCache về sau)
• Độ tin cậy và multi-region · Cache và invalidation · Load shedding, rate limit và backpressure