How we optimized Magic Pocket for cold storage

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

Bối cảnh

• Magic Pocket (Dropbox 2016) lưu block bất biến tối đa 4 MB trên đĩa quay (SMR từ 2018, Dropbox 2023); trong một region thì mới upload là replication n-way, sau đó erasure coding nền.
• Mỗi block được lưu độc lập ở ít nhất hai region cách nhau hàng nghìn dặm; mỗi region có cả bản replication nội bộ, nên tổng dữ liệu gần gấp đôi.
• Truy cập lệch mạnh theo tuổi file (2019): hơn 40% lượt đọc là file upload trong ngày, hơn 70% trong tháng, hơn 90% trong năm (OCR, trích token tìm kiếm, preview, chia sẻ đều diễn ra ngay sau upload).

Thay đổi chính

• Hai tier: tier mới "cold", hệ cũ đổi tên "warm"; dữ liệu nguội được chuyển nền, bất đồng bộ. Yêu cầu: không hi sinh độ bền (chịu mất cả một region cộng nhiều rack ở region còn lại), không hi sinh availability đọc, không cần availability ghi (ghi của user vào warm, nên có thể dừng ghi vào cold bất cứ lúc nào), chấp nhận thêm ít latency.
• Hai thiết kế bị bỏ:
  • Một erasure code trải qua mọi region trong một phần mềm duy nhất: prototype chạy được trên stage, nhưng một bug phần mềm có thể xoá mọi thứ vì không còn ranh giới logic giữa các region; độ phức tạp làm chậm các dự án storage khác. Huỷ sau hơn 9 tháng làm.
  • Kiểu f4 của Facebook (ghép cặp block ở hai region, XOR lưu ở region thứ ba): phải duy trì một cấu trúc ghép cặp toàn cục, và kiểu xoá khó đoán của Dropbox làm việc thu hồi chỗ phức tạp.
• Thiết kế chọn: bỏ giả định "một block phải đọc xong trong một region khi mọi region đều sống". Mỗi block chia thành fragment: ví dụ 3 region thì 2 fragment dữ liệu ở region 1, 2 và XOR của chúng ở region 3 (tổng quát hoá bằng Reed-Solomon). Không đổi gì bên trong mỗi region.
  • Put: chuyển nền nên nếu một region chết thì dừng migration đến khi cả ba sống lại.
  • Get: gửi cả ba region, lấy 2 phản hồi nhanh nhất, huỷ cái còn lại.
  • Delete: mỗi region xoá độc lập, chạy phiên bản phần mềm xoá khác nhau vào thời điểm khác nhau để một bug không xoá mọi fragment.
• Latency: p5 cao hơn rõ (luôn có ít nhất một round-trip liên vùng), p25–p95 hơn warm đúng khoảng một round-trip nhờ kết nối TCP ấm, cửa sổ lớn qua Courier/HTTP/2 (Dropbox 2019). p99 của cold lại thấp hơn warm, vì warm đọc region gần trước rồi mới thử region khác khi lỗi/timeout. Dropbox sửa warm: gửi thêm request sang region thứ hai nếu request đầu chưa về sau một ngân sách thời gian (hedged request theo Jeff Dean).
• Luôn chạy kịch bản xấu nhất: đọc cold lúc nào cũng phải ghép fragment từ nhiều region, nên mất một region không làm dịch chuyển traffic hay tăng I/O đột ngột ở region còn lại.
• Tiết kiệm: warm là 1+1 (tổng 2 × hệ số replication nội bộ), cold 3 region là 2+1 (1,5 ×), giảm 25% đĩa; 4 region 3+1 giảm 33%. Dữ liệu chưa bị xoá khỏi warm cho tới khi qua nhiều vòng kiểm tra.

Vì sao

• Cross-region đầy đủ là chi phí lớn nhất; cold data hiếm khi đọc nên đổi chi phí mạng lấy chi phí đĩa là đáng.

Bài học cho SWE

• Theo nhóm tác giả: thêm ràng buộc (giữ failure domain độc lập bằng mọi giá) loại thiết kế sớm; bỏ một ràng buộc ngầm (đọc trong một region) mở ra lời giải mới.
• "Số nines" trên giấy không tính rủi ro bug phần mềm chung; hai region chạy phần mềm độc lập là tuyến phòng thủ cuối trước unknown unknowns.
• Dám huỷ dự án đã làm 9 tháng khi nó không giữ được lời hứa về độ bền.
• Thiết kế mà đường bình thường cũng là đường dự phòng thì không có bất ngờ capacity khi failover.

Liên quan

• Chi phí hạ tầng và build vs buy · Độ tin cậy và multi-region
• Các mốc khác của Magic Pocket: Dropbox 2016 · Dropbox 2022 · Dropbox 2023