Cloudflare cắt đôi độ trễ DNS và giảm 85% bộ nhớ nhờ lập kế hoạch build có mục tiêu

Cloudflare vừa công bố kết quả của đợt tái thiết kế lớn cho pipeline lan truyền DNS của mình. Bằng cách chuyển từ cơ chế "build lại toàn bộ zone" sang lập kế hoạch build có mục tiêu, công ty đã giảm độ trễ build trung bình từ khoảng 7,7 giây xuống 3,3 giây và cắt 85% mức sử dụng bộ nhớ đỉnh.

Thành tích này càng đáng chú ý khi lưu lượng sự kiện DNS đã tăng gần gấp ba so với năm 2022: từ khoảng 250 thay đổi bản ghi mỗi giây lên khoảng 700, chưa kể khoảng 100 loại sự kiện khác như thay đổi cấu hình zone.

Bài toán: zone ngày càng khổng lồ

Khi Cloudflare công bố bài viết trước về pipeline này vào năm 2022, Zone Builder tiếp nhận khoảng 250 thay đổi bản ghi DNS mỗi giây. Hiện nay con số đó là khoảng 700, cộng thêm khoảng 100 sự kiện khác.

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 yêu cầu, và cách công việc đó phình to theo kích thước zone. Một số zone hiện chứa hơn 20 triệu bản ghi, và Cloudflare dự kiến con số này sẽ tiến tới hàng trăm triệu.

Sơ đồ pipeline lan truyền DNS của Cloudflare

Mỗi sự kiện khởi động một đồ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 được. Cloudflare gọi công việc này là một build. Một build đọc trạng thái cơ sở dữ liệu hiện tại, chuyển thành định dạng dùng ở biên, rồi ghi các thay đổi vào Quicksilver — kho key-value phân tán của công ty.

Năm 2022, build theo từng bản ghi nhanh hơn 150 lần so với build toàn phần. Trên một zone thử nghiệm một triệu bản ghi, con số này là 4.250 lần. Bước tiếp theo hiển nhiên là áp dụng cách làm tương tự cho phần cấu hình zone.

Vì sao không chỉ build lại đúng phần cấu hình đã thay đổi?

Câu trả lời là nên như vậy, nhưng chứng minh được khi nào điều đó an toàn mới là phần tốn công nhất.

Một sự kiện bản ghi cho biết chính xác cái gì đã thay đổi. Ngược lại, một sự kiện zone có thể đến từ nhiều sản phẩm Cloudflare khác nhau, có thể không nói rõ vì sao zone thay đổi, và có thể thay đổi dữ liệu dùng chung cho nhiều zone cùng tên miền. Chọn quá nhiều việc thì lãng phí tài nguyên; chọn quá ít thì có thể để lại dữ liệu DNS cũ hoặc sai ở biên.

Cloudflare đã xây dựng một bộ lập kế hoạch build có mục tiêu chọn phương án nhỏ nhất có thể chứng minh là an toàn, cùng một bộ điều phối mới gộp công việc cho cùng một zone. Thay đổi cấu hình zone không còn kích hoạt build lại những zone có hàng chục triệu bản ghi.

Kết quả: bộ nhớ đỉnh giảm 85%, và phần dư thừa cho phép rút ngắn an toàn các khoảng chờ mà pipeline vốn cần để đảm bảo độ bền vững — từ đó cắt đôi thời gian từ lúc thay đổi DNS đến khi dữ liệu được ghi vào Quicksilver.

Năm vấn đề cần giải quyết

Để trả lời an toàn ba câu hỏi — tên DNS nào có thể thay đổi, metadata dùng chung hay danh sách zone được publish có đổi không, và trạng thái cũ nào cần xóa khỏi Quicksilver — nhóm kỹ thuật phải giải quyết năm bài toán.

Thứ nhất, sự kiện phải nói rõ cái gì đã thay đổi. Producer sự kiện được sửa để đính kèm các trường và cấu hình zone đã đổi, kèm giá trị cũ và mới khi có. Những sự kiện chỉ cập nhật dấu thời gian mà không rõ mục đích vẫn kích hoạt build toàn phần — nguyên tắc là không bao giờ biến sự mơ hồ thành ít việc hơn.

Thứ hai, mỗi thay đổi phải ánh xạ tới build nhỏ nhất còn đúng. Bộ lập kế hoạch chọn một trong năm loại build:

• Chỉ tài nguyên: build lại bản ghi ở các tên DNS cụ thể, không đổi metadata. Thường dùng cho thay đổi A, AAAA, TXT, CNAME.
• Tài nguyên và metadata: build lại tên cụ thể và metadata chia sẻ. Dùng khi đổi nameserver hoặc bản ghi wildcard.
• Apex và metadata: build lại đỉnh zone và metadata. Dùng cho cấu hình như Universal SSL.
• Purge: xóa một zone không còn cần publish.
• Toàn zone: build lại mọi bản ghi khi không chứng minh được phương án nhỏ hơn là an toàn.

Thứ ba, phải tính đến dữ liệu dùng chung giữa các zone cùng tên. Quicksilver lưu bản ghi riêng cho từng zone nhưng dùng chung một key metadata cho mọi zone Cloudflare có cùng tên miền. Key này hoạt động như một danh mục, cho máy chủ DNS biết được dùng những zone ID nội bộ nào. Trong quá trình onboarding, offboarding hay chuyển đổi vòng đời, có thể tồn tại tạm thời nhiều đối tượng zone cho cùng một tên miền.

Thứ tư, cơ sở dữ liệu có thể thay đổi giữa lúc phát sự kiện và lúc build. Vì vậy kế hoạch được lập hai lần: sự kiện tạo danh sách việc thận trọng, và ngay trước khi thực thi, Zone Builder đọc lại một ảnh chụp mới từ replica chỉ đọc. Kết quả có thể đổi theo bốn hướng: build có mục tiêu thành build toàn phần, thành purge, bị bỏ qua, hoặc metadata được dựng lại từ danh sách ứng viên hiện tại.

Thứ năm, gộp việc không được làm mất thông điệp Kafka. Cloudflare dùng cơ chế soft commit: một build có thể hoàn tất lệch thứ tự và được đánh dấu xong trong bộ nhớ, nhưng vị trí commit của Kafka chỉ tiến lên khi mọi thông điệp trước đó cũng đã xong. Đây là lựa chọn có chủ đích: chấp nhận làm lại việc còn hơn mất một thay đổi của khách hàng.

Sơ đồ hợp nhất công việc trong bộ điều phối

Kiểm chứng trước khi phát hành

Một build nhỏ chỉ có ích nếu tạo ra đúng dữ liệu DNS như build toàn phần. Cloudflare bổ sung các bài kiểm tra tương đương cho đường nameserver, wildcard và apex: chạy cả hai loại build từ cùng trạng thái cơ sở dữ liệu, cố định các giá trị phụ thuộc thời gian, rồi so sánh từng byte mọi key Quicksilver.

Ngoài ra còn có một Zone Builder gương: nó tiêu thụ luồng Kafka production và đọc cơ sở dữ liệu production, nhưng ghi vào một môi trường Quicksilver riêng không phục vụ lưu lượng khách hàng. Một bộ so sánh kiểm tra mẫu 20% số zone để tìm key thiếu, key thừa và giá trị khác biệt, hiển thị trên DNS Mirror Dashboard — chạy trên Cloudflare Developer Platform với Worker, Durable Objects và Cloudflare Access.

Sau khi kết quả gương ổn định, bộ điều phối mới được triển khai dần theo hash tên zone. Việc hash theo tên thay vì zone ID đảm bảo mọi zone cùng tên luôn nằm trên cùng một bộ điều phối, tránh hai bộ điều phối ghi cùng một key metadata.

Kết quả đo được trong 24 giờ

Trong 24 giờ đo đạc, phân bố các loại build như sau:

• 86,81% chỉ build tài nguyên
• 2,54% tài nguyên và metadata
• 2,30% apex và metadata
• 1,30% purge
• 7,04% vẫn là build toàn zone

Như vậy, 92,95% số build đã tránh được việc dựng lại toàn bộ zone. Hai loại build metadata trước đây vốn là build toàn phần, kể cả với zone lớn; cộng với 7,04% còn lại, tỷ lệ build toàn phần giảm khoảng 40%. Con số này còn chưa phản ánh hết công sức tiết kiệm được, vì các build toàn phần thường rơi vào những zone lớn nhất.

Biểu đồ p99 độ trễ hoàn tất build trước và sau thay đổi

Về độ trễ, đỉnh p99 lớn nhất giảm từ 14,6 phút xuống 1,21 phút, tức khoảng 12 lần. Bộ nhớ working-set của toàn bộ deployment giảm từ trung bình 49 GiB xuống 7 GiB (giảm 86%), mức đỉnh từ 79 GiB xuống 12 GiB (giảm 85%).

Quan trọng hơn, phần dư thừa tài nguyên cho phép Cloudflare rút ngắn khoảng cách rebuild giữa các lần build của cùng một zone, đồng thời giảm thời gian DNS Kafka Aggregator giữ mỗi sự kiện để chờ replica cơ sở dữ liệu bắt kịp. Kết hợp lại, độ trễ trung vị giảm từ khoảng 7,7 giây xuống 3,3 giây. Với histogram native mới, p90 ở mức khoảng 5,5 giây và p99 khoảng 12 giây.

Vì sao build toàn phần vẫn tồn tại

Năm 2022, Cloudflare từng tuyên bố sẽ loại bỏ hoàn toàn build toàn phần. Giờ đây họ thừa nhận điều đó "không thực tế cũng không hữu ích". Một zone được publish lần đầu cần ghi mọi bản ghi; một thay đổi có thể ảnh hưởng bản ghi ở bất kỳ đâu trong zone cần kiểm tra mọi bản ghi; và một sự kiện không nói rõ thay đổi gì vẫn phải build toàn phần.

Với zone nhỏ, build toàn phần cũng rẻ. Và nhờ những thay đổi đã triển khai, các build toàn phần còn lại hiện chủ yếu do những sự kiện như publish lần đầu — vốn chỉ tác động tới zone mới, ít bản ghi.

Với các kỹ sư vận hành hệ thống DNS quy mô lớn tại Việt Nam, bài học đáng chú ý nhất có lẽ không phải là con số 85% hay 12 lần, mà là nguyên tắc thiết kế: không bao giờ biến sự mơ hồ thành ít việc hơn, và luôn có một môi trường gương để so sánh từng byte trước khi tin tưởng vào tối ưu hóa.