Lessons Netflix Learned from the AWS Outage
Bài tóm tắt Netflix 2011 3. Quy mô lớn Độ khó: Trung bình
Netflix · 2011 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bối cảnh
- 21/4/2011: sự cố lớn ở AWS US-East làm sập hoặc làm chậm nhiều website lớn.
- Với Netflix, đây là bài kiểm tra lớn đầu tiên xem kiến trúc cloud mới có tốt hơn so với sự cố năm 2008 không (Netflix 2016). Lúc này họ chạy ở 1 region, 3 AZ, phục vụ Mỹ và Canada.
Thay đổi chính (những gì đã làm đúng)
- Service stateless: instance nào cũng phục vụ được mọi request; hỏng một máy thì route sang máy khác và tự dựng máy mới.
- Dữ liệu có nhiều bản nóng ở nhiều zone: khi lỗi thì retry ở zone khác hoặc chuyển sang bản dự phòng nóng.
- Graceful degradation, ba nguyên tắc:
- fail fast: timeout gắt để thành phần lỗi không kéo cả hệ thống;
- fallback: không cá nhân hoá được thì trả kết quả cache (cũ) hoặc kết quả không cá nhân hoá;
- bỏ tính năng: tính năng không thiết yếu mà chậm thì gỡ khỏi trang.
- Dư N+1: cả 3 zone đều active (không có zone "chờ"), mua reserved instance ở mọi zone nhiều hơn mức dùng, để chịu được mất trọn một zone. Theo Netflix, đây là khoản tiền đáng chi.
- Tránh EBS làm kho dữ liệu chính; dựa vào S3, SimpleDB, Cassandra (không bị ảnh hưởng trong sự cố). Coi mọi tài nguyên khác là tạm thời.
Kết quả: dịch vụ chạy không cần can thiệp, chỉ có tỷ lệ lỗi và latency cao hơn bình thường trong buổi sáng (giờ thấp điểm); số cuộc gọi hỗ trợ khách hàng không tăng rõ.
Những gì chưa tốt
- Khi thấy AWS khó sửa xong trước giờ cao điểm buổi tối, họ quyết định rút khỏi zone lỗi bằng tay. Phải nhờ từng team đổi cấu hình; công cụ không làm được thay đổi hàng loạt.
- ELB cân bằng theo zone trước, theo instance sau. Mất nhiều máy ở một zone thì máy còn lại trong zone đó gánh hết, có thể dẫn tới sụp dây chuyền và 1/3 traffic rơi vào "hố đen". Load balancer tầng giữa tự viết của Netflix cân bằng theo instance, không phụ thuộc zone, nên không gặp vấn đề này.
Bài học (Netflix tự rút ra)
- Tạo thêm lỗi: Chaos Monkey (giết service ngẫu nhiên) đã có, nhưng chưa có gì mô phỏng mất cả một AZ. Ý tưởng "Chaos Gorilla" ra đời từ đây.
- Tự động hoá failover zone thành thao tác "một nút bấm".
- Hỗ trợ nhiều region, vừa để phục vụ toàn cầu vừa để có thể rời hẳn một region khi có sự cố lớn.
- Bỏ phụ thuộc EBS: chuyển instance có trạng thái sang AMI dựa trên S3; chuyển service MySQL lớn duy nhất chạy trên EBS sang Cassandra.
Bài học cho SWE
- Thiết kế cho lỗi từ đầu (stateless, nhiều zone, fallback) thì một sự cố lớn chỉ thành sự cố nhỏ.
- Quy trình bằng tay không scale được: thứ chịu tải tốt khi có 1 region sẽ không đủ khi có hàng chục AZ.
- Diễn tập chỉ chứng minh được thứ nó mô phỏng: Chaos Monkey không giúp gì khi mất cả zone.
- Lớp cân bằng tải có thể là điểm yếu ẩn khi tải giữa các zone không đều.
Liên quan
Độ tin cậy và multi-regionNền tảng nội bộ cho service (đường ray chung)Sự cố và postmortemLoad shedding, rate limit và backpressureTự động hoá vận hành và auto-remediationKiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định)
Được nhắc tới trong
Chủ đề (6)
Công ty (1)
Bài tóm tắt (5)