The Chubby lock service for loosely-coupled distributed systems

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

Nguồn thứ cấp: Adrian Colyer tóm tắt paper Chubby (Burrows, OSDI 2006), có trích nguyên văn nhiều đoạn. Mọi nhận định là theo Google qua lời kể của Colyer. Chubby là nguồn cảm hứng cho ZooKeeper.

Bối cảnh

• Trước Chubby, phần lớn hệ ở Google bầu primary bằng cơ chế tự chế hoặc cần người can thiệp sau mỗi lần hỏng. Chubby được thiết kế làm dịch vụ khoá thô (coarse-grained), ví dụ để bầu primary, không phải khoá ngắn hạn theo giao dịch.
• Chọn làm dịch vụ thay vì thư viện đồng thuận nhúng vào ứng dụng: dễ gắn vào ứng dụng có sẵn, vì theo paper developer "không phải lúc nào cũng lên kế hoạch HA như mong muốn"; ứng dụng không cần tự giữ quorum (một cell thường 5 replica, client vẫn chạy được khi số replica của chính nó ít).
• Giao diện khoá quen thuộc với lập trình viên, nhưng paper cảnh báo đó là con dao hai lưỡi: nhiều người tưởng hiểu khoá, ít ai nghĩ tới máy hỏng độc lập trong hệ bất đồng bộ.

Thay đổi chính

• Thiết kế: một cell khoảng 5 replica dùng Paxos bầu master; DNS để tìm replica. Giao diện giống file system (file và thư mục, node vĩnh viễn hoặc tạm gắn với session); mỗi file/thư mục là một khoá đọc/ghi advisory (không chặn truy cập file, dễ debug và quản trị hơn khoá bắt buộc). Bỏ các ngữ nghĩa khó phân tán (đổi tên giữa thư mục, quyền theo đường dẫn, thời gian truy cập) để mỗi thư mục có thể do master khác phục vụ và metadata cache được.
• Cache phía client có invalidation tường minh: master gửi lệnh huỷ khi dữ liệu đổi, client không bao giờ nhận cập nhật đẩy, vì cập nhật đẩy có thể làm client nhận vô hạn thay đổi cho file nó đã thôi dùng. Lease giữ cache hợp lệ chỉ bằng keep-alive.
• Failover có grace period: master mới bầu xong thì client tiếp tục session nếu kịp trước khi lease cục bộ hết; bầu lâu thì client xoá cache và chờ thêm grace period. Theo paper, code failover chạy ít hơn mọi phần khác nên là "nguồn bug thú vị".
• Cách dùng thực tế khác dự định: Chubby thành name service chính của Google, nơi hẹn gặp của MapReduce, nơi GFS và Bigtable bầu primary, kho file cần HA (ACL). Lý do thay DNS: job hàng nghìn process gọi lẫn nhau tạo số lần tra DNS bậc hai; với TTL 60 giây, một job 3.000 client cần khoảng 150.000 lượt tra/giây để giữ cache. Cache của Chubby được giữ bằng keep-alive nên không tốn theo số entry. Sau đó thêm server chuyển giao thức chuyên cho tra tên và một DNS server đọc từ Chubby để chuyển dần ứng dụng cũ; theo paper, biết trước thì đã làm proxy sớm hơn.
• Scale: proxy cho read và keep-alive; chia cây thư mục qua nhiều server (năm 2006 chưa cần).

Bài học từ vận hành (theo paper)

• Cell dùng chung nên phải cô lập client với nhau: không có tấn công, nhưng nhầm lẫn và kỳ vọng khác nhau của developer gây hiệu ứng như tấn công. Review trước khi cho client lên production lúc đầu không đủ kỹ.
• Developer hay viết vòng retry vô hạn khi file chưa có, hoặc mở-đóng file liên tục để poll. Thử phạt bằng độ trễ tăng dần với Open() lặp lại; cuối cùng làm cho Open() lặp lại rẻ còn dễ hơn giáo dục.
• Developer coi Chubby như luôn sẵn sàng: một hệ hàng trăm máy chạy quy trình phục hồi hàng chục phút mỗi khi Chubby bầu master mới, khuếch đại một sự cố gấp trăm lần cả về thời gian lẫn số máy. Họ cũng không phân biệt "dịch vụ đang chạy" với "dịch vụ sẵn sàng cho ứng dụng của mình".

Bài học cho SWE

• Đưa bầu leader và cấu hình HA vào một dịch vụ dùng chung, thay vì mỗi hệ tự chế, là một bước tiến hoá rõ của hạ tầng; cùng hướng với etcd/ZooKeeper về sau (Nền tảng nội bộ cho service (đường ray chung), Failover, replica và dự phòng dữ liệu).
• Cache có lease + invalidation (không đẩy cập nhật) giữ ngữ nghĩa đơn giản và tải server thấp (Cache và invalidation).
• Dịch vụ dùng chung phải tự bảo vệ trước client hành xử sai; khi không sửa được hành vi client, làm cho đường đi sai rẻ đi (Hot partition và thundering herd).
• Client của dịch vụ nền phải chịu được nó bầu lại leader mà không tự khuếch đại sự cố.
• Hệ được thiết kế cho A thường bị dùng chủ yếu cho B (khoá → name service); theo dõi cách dùng thật để thêm đường chuyên biệt.

Liên quan

• Cùng công ty: Google 2020 · Google 2021
• Vitess (PlanetScale/CNCF) 2022 (bầu primary tự động cho MySQL, dùng topology server)
• Failover, replica và dự phòng dữ liệu · Nền tảng nội bộ cho service (đường ray chung) · Cache và invalidation · Hot partition và thundering herd