A Pods Architecture To Allow Shopify To Scale

Shopify · 2018 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

2015: không thể tiếp tục mua server DB to hơn, nên Shopify shard database. Scale được, nhưng mất khả năng chịu lỗi: code đầy những đoạn Sharding.with_each_shard do ... end, nên chỉ cần một shard hỏng là cả hành động đó hỏng trên toàn nền tảng. Shard càng nhiều, rủi ro càng lớn.
2016: tổ chức lại kiến trúc runtime.
Bài ngắn, mang tính tổng quan; hẹn kể chi tiết Pod Mover ở bài sau.

Thay đổi chính

Pod (không phải Kubernetes pod) = một tập shop nằm trên một bộ datastore cô lập hoàn toàn. App server, job worker, load balancer dùng chung, nhưng mỗi lúc chỉ được nói chuyện với một pod; cấm hành động xuyên pod.
Mỗi đơn vị công việc (web request, delayed job) gắn với một pod, nên phục vụ một request chỉ cần một pod còn sống.
Sorting Hat ở load balancer: dùng bộ luật để xác định request thuộc pod nào, gắn header, chuyển tới đúng nơi (Shopify có nhiều data center). App server đọc header để nối vào đúng datastore.
Disaster recovery theo pod: mỗi pod có một cặp data center (một active, một dự phòng). Pod Mover dời một pod sang data center dự phòng trong khoảng một phút, không rớt request hay job. Sơ tán cả data center chỉ là dời lần lượt từng pod. Shopify muốn dời pod hằng ngày.

Vì sao

Theo Shopify: shard thì scale được nhưng chưa đủ; phải cô lập từng shard để lỗi không lan thành sự cố toàn nền tảng. Thêm pod mới cũng không ảnh hưởng tới pod cũ.

Bài học cho SWE

Sharding mà vẫn có thao tác "lặp qua mọi shard" thì không cô lập lỗi được. Shard nào hỏng cũng kéo theo tất cả.
Cô lập theo tenant, tức mỗi request chỉ chạm một pod, giúp scale ngang và chịu lỗi cùng lúc. Đây là bulkhead ở mức kiến trúc dữ liệu.
Lấy đơn vị cô lập (pod) làm "nguyên tử" cho disaster recovery: thao tác nhỏ, lặp được, tự động hoá được.
Đối chiếu: Slack chọn hướng ngược lại, bỏ shard theo khách hàng vì khách lớn tạo hot spot (Slack 2020). Bài Shopify không nói cách xử lý shop rất lớn trong một pod.