AWS Lessons Learned for Data Processing Pipelines

Expedia · 2016 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Site chặn crawler; wiki đọc toàn văn qua trình duyệt, ghi chú bằng lời của wiki. Bài ngắn, dạng danh sách bài học sau một năm chạy trên AWS.

Bối cảnh

• Khoảng 2015, team Media Services của Expedia chuyển pipeline xử lý ảnh (nhận ảnh từ khách sạn và nhà cung cấp, tối ưu, phân phối cho các site) từ một hệ batch cũ sang pipeline dựa trên queue trên AWS.
• Được: scale khi tải nặng, deploy nhanh hơn, hết lo mua thêm đĩa cho lượng ảnh tăng.

Thay đổi chính (các bài học)

• SQS visibility timeout: quen RabbitMQ (message trả lại queue khi consumer mất kết nối), team mất thời gian mới hiểu vì sao có message bị xử lý hai lần: SQS trả message lại theo timeout, không theo kết nối. Mặc định 30 giây, xử lý thường dưới 10 giây nhưng đôi khi lâu hơn; tăng lên 1 phút vẫn trùng, nên đặt 1 giờ cho an toàn. Đổi lại, message của consumer chết phải chờ rất lâu mới được nhận lại; họ ghi chú sẽ xem lại, và gợi ý gia hạn theo từng message (ChangeMessageVisibility).
• S3 không có thư mục thật: "đổi tên thư mục" là đổi key của từng object. Đã chuyển hơn một triệu file từ SAN lên S3 bằng Snowball, gõ sai đường dẫn gốc, phải viết script chạy song song trên nhiều máy để đổi key từng file, kéo dài migration.
• S3 cross-region replication không bắc cầu: chuỗi bucket 1 → 2 → 3 không chạy ở chặng thứ hai, vì bản sao tạo bởi replication không được replicate tiếp (đúng như tài liệu).
• DynamoDB với tải đột biến: ảnh mới về theo đợt, có lúc vượt capacity dự kiến cao nhất, gây lỗi; chỉ nhờ retry phía ứng dụng mới không mất dữ liệu. Tăng capacity theo spike thì được, nhưng thời điểm đó chỉ giảm được bốn lần mỗi 24 giờ và thay đổi cần thời gian mới có hiệu lực; autoscaling cần ít nhất 10 phút vượt ngưỡng nên phản ứng quá muộn. Vì đỉnh không đoán được độ lớn, team chuyển từ DynamoDB sang Aurora.

Vì sao

• Mỗi dịch vụ managed có ngữ nghĩa riêng khác với hệ tự vận hành quen thuộc; giả định mang từ hệ cũ sang là nguồn lỗi chính.

Bài học cho SWE

• Với queue kiểu lease/visibility timeout, at-least-once là mặc định: consumer phải idempotent, timeout đặt theo thời gian xử lý tệ nhất, hoặc gia hạn theo message (Event-driven, message queue và Kafka).
• Database tính tiền theo capacity đặt trước hợp tải đều; tải đột biến không đoán được độ lớn thì chọn hệ khác hoặc mô hình tính tiền khác (Chọn database theo workload). Hai năm sau, Expedia lại có câu chuyện ngược chiều: chuyển một workload từ Cassandra sang DynamoDB (Expedia 2018).
• Kiểm tra kỹ đường dẫn và tên key trước khi chuyển dữ liệu khối lớn; sửa sau tốn bằng cả lần chuyển.
• Đọc giới hạn của tính năng replication trước khi thiết kế failover dựa trên nó.

Liên quan

• Cùng công ty: Expedia 2018 · Expedia 2020
• Event-driven, message queue và Kafka · Chọn database theo workload