Cloudflare giảm một nửa độ trễ xây dựng DNS, cắt 85% bộ nhớ

Pipeline DNS của Cloudflare giờ nhận khoảng 700 thay đổi bản ghi DNS mỗi giây, gần gấp ba con số 250 của năm 2022, cộng thêm khoảng 100 sự kiện khác như thay đổi thiết lập zone. Vấn đề không nằm ở số lượng sự kiện, mà ở loại công việc mà một số sự kiện đòi hỏi và cách công việc đó tăng theo kích thước zone. Có zone hiện chứa hơn 20 triệu bản ghi và dự kiến còn tăng tới hàng trăm triệu.

Mỗi sự kiện khởi động đồng hồ đo thời gian biến thay đổi thành dữ liệu mà các máy chủ DNS có thẩm quyền sử dụng, gọi là một build. Build đọc trạng thái cơ sở dữ liệu hiện tại, chuyển sang định dạng dùng ở biên và ghi thay đổi vào Quicksilver. Năm 2022, build theo từng bản ghi nhanh hơn build toàn phần 150 lần tính trung bình, và nhanh hơn 4.250 lần trên zone thử nghiệm một triệu bản ghi. Bước tiếp theo được đặt ra khi đó là làm điều tương tự cho thiết lập zone.

Vì sao build toàn phần hết khả năng mở rộng

Zone Builder ban đầu không cần biết vì sao zone thay đổi: nó đọc zone và toàn bộ bản ghi, chuyển thành khóa Quicksilver, so sánh với khóa đã lưu, xóa khóa cũ và ghi khóa thay đổi. Lần ghi cuối chỉ chứa khóa thay đổi, nhưng build toàn phần vẫn phải đọc, mã hóa và so sánh mọi bản ghi, đồng thời giữ cả zone trong bộ nhớ. Với các zone lớn nhất, zone không vừa bộ nhớ.

Thiết lập zone khiến việc nhắm mục tiêu khó hơn. Ví dụ Universal SSL khi bật hoặc tắt sẽ cập nhật metadata và có thể thay đổi bản ghi CAA ở đỉnh zone. Build có mục tiêu phải trả lời ba câu hỏi: tên DNS nào có thể thay đổi, metadata dùng chung hoặc danh sách zone được công bố có thể thay đổi không, và trạng thái cũ nào phải xóa khỏi Quicksilver.

Năm bài toán phải giải

Cloudflare sửa bộ sinh sự kiện để gửi kèm các trường và thiết lập zone đã thay đổi, kèm giá trị cũ và mới khi có. Mỗi thiết lập được truy vết qua mã sinh đầu ra DNS để phân loại ảnh hưởng. Những sự kiện chỉ cập nhật dấu thời gian, hoặc thiếu chi tiết, sự kiện lạ hay thay đổi có thể ảnh hưởng bản ghi ở bất kỳ đâu trong zone vẫn kích hoạt build toàn phần. Nguyên tắc là không bao giờ biến sự không chắc chắn thành ít việc hơn.

Bộ lập kế hoạch chọn một trong năm loại build:

• Resources only: dựng lại bản ghi ở các tên DNS cụ thể, thường dùng cho thay đổi A, AAAA, TXT, CNAME.
• Resources and metadata: dựng lại tên cụ thể và metadata dùng chung, dùng cho thay đổi nameserver và wildcard.
• Apex and metadata: dựng lại đỉnh zone và metadata, dùng cho thiết lập như Universal SSL.
• Purge: gỡ zone không còn được công bố.
• Full zone: dựng lại mọi bản ghi khi không chứng minh được việc nhỏ hơn là an toàn.

Quy tắc là mọi khóa mà build có mục tiêu ghi phải giống từng byte với kết quả của build toàn phần; nếu không chứng minh được thì làm build toàn phần. Với zone vượt ngưỡng số bản ghi cố định, Zone Builder không bao giờ chuyển sang build toàn phần mà dựng lại đỉnh zone, metadata và mọi tên do sự kiện trong hàng đợi xác định.

Tên miền trùng và kiểm tra trước khi ghi

Quicksilver lưu khóa bản ghi của từng zone riêng, nhưng chỉ có một khóa metadata dùng chung cho mọi zone Cloudflare cùng tên miền, đóng vai trò danh mục cho biết các ID zone nội bộ được phép dùng. Trong quá trình tiếp nhận, rời bỏ và thay đổi vòng đời, nhiều đối tượng zone có thể cùng tồn tại cho một tên miền; một chính sách ưu tiên chọn một tập nhỏ, có giới hạn để công bố. Khi ghi khóa metadata, Zone Builder dựng lại toàn bộ khóa từ góc nhìn mới và ghi bản ghi của zone kích hoạt trước metadata tham chiếu tới chúng.

Việc lập kế hoạch diễn ra hai lần: sự kiện tạo danh sách việc thận trọng, rồi ngay trước khi thực thi, Zone Builder đọc ảnh chụp công bố mới gồm thiết lập zone hiện tại, việc zone có nên được công bố lên mạng này không và các ID zone cùng tên thuộc khóa metadata. Trạng thái mới có thể khiến build có mục tiêu thành build toàn phần, thành purge, bị bỏ qua hoặc dựng lại khóa metadata. Dữ liệu đọc từ bản sao chỉ đọc để không tranh chấp với ghi của khách hàng; DNS Kafka Aggregator trì hoãn sự kiện đủ lâu để bù độ trễ thông thường, và bước kiểm tra cơ sở dữ liệu cuối cùng sẽ từ chối nếu bản sao vẫn chậm hơn.

Hợp nhất công việc trong một bộ lập lịch

Công việc bản ghi và công việc toàn zone trước đây dùng hai bộ lập lịch riêng, không gộp được việc của nhau. Cloudflare thay bằng một bộ lập lịch thống nhất: bộ lập kế hoạch quyết định phải build gì, bộ lập lịch quyết định khi nào chạy. Khi nhiều sự kiện của một zone đến trước lúc build, công việc được gộp; gộp chỉ thêm việc, và nếu bất kỳ sự kiện nào cần cả zone thì build gộp thành build toàn phần, còn purge ghi đè mọi lần dựng lại. Bộ lập lịch theo dõi riêng công việc DNS phải làm và các thông điệp Kafka chờ xác nhận; khi thử lại, cả hai được giữ nguyên.

Kết quả: thay đổi thiết lập zone không còn dựng lại các zone hàng chục triệu bản ghi. Hai cải tiến cùng giảm 85% bộ nhớ đỉnh, và phần dư cho phép rút ngắn thời gian chờ vốn có để đảm bảo khả năng phục hồi, giảm một nửa thời gian từ khi thay đổi DNS đến khi dữ liệu được ghi vào Quicksilver.

Nguồn: Cloudflare Blog