Cloudflare giảm một nửa độ trễ xây dựng DNS nhờ lập kế hoạch có mục tiêu

Cloudflare đã tối ưu hóa đáng kể quy trình lan truyền DNS, giảm một nửa thời gian cần thiết để đẩy các thay đổi lên mạng lưới toàn cầu của mình. Đội ngũ kỹ thuật đạt được điều này bằng cách thay thế các quá trình tái tạo toàn bộ zone vốn tốn kém tài nguyên bằng một công cụ lập kế hoạch build có mục tiêu mới, giúp xác định đơn vị công việc nhỏ nhất an toàn cho mỗi thay đổi. Sự chuyển dịch kiến trúc này cũng giúp giảm mức tiêu thụ bộ nhớ đỉnh điểm xuống 85%, cho phép hệ thống xử lý hiệu quả hơn các zone chứa hàng chục triệu bản ghi.

Chuyện gì đã xảy ra

Thách thức cốt lõi bắt nguồn từ quy mô ngày càng tăng của các zone DNS trên mạng lưới Cloudflare. Trong khi khối lượng sự kiện tăng từ 250 lên khoảng 700 sự kiện/giây kể từ năm 2022, nút thắt cổ chai chính không phải là thông lượng mà là chi phí tính toán để xử lý các zone lớn. Một số zone hiện chứa hơn 20 triệu bản ghi, con số dự kiến sẽ tăng lên hàng trăm triệu. Trước đây, bất kỳ thay đổi nào đối với cài đặt zone hoặc bản ghi thường kích hoạt một quá trình build toàn bộ, trong đó hệ thống đọc mọi bản ghi trong cơ sở dữ liệu, chuyển đổi sang định dạng edge và so sánh với trạng thái hiện tại. Đối với các zone khổng lồ, quy trình này quá đắt đỏ và thường không thể vừa vào bộ nhớ.

Để giải quyết vấn đề này, các kỹ sư Cloudflare đã phát triển một công cụ lập kế hoạch build có mục tiêu và một bộ lập lịch thống nhất. Công cụ lập kế hoạch phân tích các sự kiện đầu vào để xác định chính xác những phần nào của zone đã thay đổi, chẳng hạn như tên DNS cụ thể hoặc siêu dữ liệu chia sẻ, thay vì tái tạo toàn bộ zone. Bộ lập lịch sau đó kết hợp nhiều sự kiện đang chờ xử lý cho cùng một zone vào một cửa sổ thực thi duy nhất. Cách tiếp cận này đảm bảo rằng các thay đổi cài đặt zone không còn kích hoạt quá trình tái tạo toàn bộ cho các zone chứa hàng chục triệu bản ghi. Kết quả là giảm 50% thời gian từ khi thay đổi DNS đến khi dữ liệu được ghi vào Quicksilver, kho lưu trữ khóa-giá trị phân tán của Cloudflare, và giảm 85% mức sử dụng bộ nhớ đỉnh điểm.

Cơ chế hoạt động

Việc tối ưu hóa dựa trên khả năng phân biệt giữa các loại thay đổi DNS khác nhau và ánh xạ chúng sang các phạm vi build cụ thể. Hệ thống phân loại các bản build thành năm nhóm: chỉ tài nguyên (cho các thay đổi bản ghi tiêu chuẩn như A hoặc CNAME), tài nguyên và siêu dữ liệu (cho các thay đổi nameserver hoặc wildcard), apex và siêu dữ liệu (cho các cài đặt như Universal SSL), purge (dọn sạch, cho các zone chưa xuất bản) và toàn bộ zone (khi không thể chứng minh tính an toàn). Công cụ lập kế hoạch đảm bảo rằng bất kỳ bản build có mục tiêu nào đều tạo ra đầu ra giống hệt từng byte so với bản build toàn bộ. Nếu hệ thống không thể chứng minh rằng một bản build nhỏ hơn là an toàn, nó sẽ mặc định quay lại bản build toàn bộ, tuy nhiên đối với các zone cực lớn, hệ thống tránh hoàn toàn các bản build toàn bộ để ngăn chặn tình trạng cạn kiệt bộ nhớ.

Một thành phần quan trọng của hệ thống này là cách xử lý siêu dữ liệu chia sẻ. Trong kiến trúc của Cloudflare, nhiều đối tượng zone nội bộ có thể tồn tại cho cùng một tên miền công khai trong các sự kiện vòng đời như quá trình onboarding. Một khóa siêu dữ liệu chia sẻ trong Quicksilver đóng vai trò như một thư mục, cho biết các máy chủ thẩm quyền (authoritative servers) biết ID zone nội bộ nào đang hoạt động. Khi một thay đổi ảnh hưởng đến siêu dữ liệu này, chẳng hạn như cập nhật nameserver, trình build phải làm mới toàn bộ khóa chia sẻ. Để đảm bảo tính nhất quán, hệ thống thực hiện một lần đọc mới từ các replica cơ sở dữ liệu ngay trước khi thực thi. Cách tiếp cận "lập kế hoạch hai lần" này tính đến bất kỳ thay đổi nào trong cơ sở dữ liệu xảy ra giữa sự kiện ban đầu và quá trình build thực tế, ngăn chặn dữ liệu cũ hoặc sai lệch lan truyền đến edge.

Chi tiết chính

• Mức sử dụng bộ nhớ đỉnh điểm giảm 85% nhờ loại bỏ các thao tác đọc toàn bộ zone không cần thiết cho các tập dữ liệu lớn.
• Độ trễ lan truyền DNS giảm một nửa, rút ngắn thời gian từ khi thay đổi đến khi ghi vào Quicksilver đi 50%.
• Hệ thống xử lý các zone chứa hơn 20 triệu bản ghi, với kỳ vọng tăng trưởng lên tới hàng trăm triệu bản ghi.
• Sử dụng năm loại build: chỉ tài nguyên, tài nguyên và siêu dữ liệu, apex và siêu dữ liệu, purge và toàn bộ zone.
• Bộ lập lịch thống nhất kết hợp nhiều sự kiện cho cùng một zone vào một bản build duy nhất để nâng cao hiệu quả.
• Các lần đọc cơ sở dữ liệu mới diễn ra ngay trước khi thực thi để đảm bảo bản build phản ánh trạng thái hiện tại.

Tại sao điều này quan trọng

Đối với các kỹ sư hạ tầng và đội ngũ nền tảng, nghiên cứu tình huống này nhấn mạnh tầm quan trọng của xử lý gia tăng (incremental processing) trong các hệ thống quy mô lớn. Khi tập dữ liệu phình to, các thao tác tuyến tính như tái tạo toàn bộ trở nên không bền vững. Việc chuyển từ mô hình "tái tạo mọi thứ" sang mô hình "chỉ tái tạo những gì đã thay đổi" minh họa cách theo dõi phụ thuộc chính xác có thể mở khóa những cải thiện hiệu suất đáng kể. Điều này đặc biệt liên quan đến các đội ngũ quản lý kho cấu hình quy mô lớn hoặc dịch vụ có trạng thái (stateful services), nơi cả tính nhất quán và tốc độ đều rất quan trọng. Khả năng chứng minh tính an toàn trong khi tối thiểu hóa khối lượng công việc cho phép các hệ thống mở rộng quy mô mà không cần tăng tương ứng tài nguyên tính toán.

Cách tiếp cận này cũng mang lại bài học về xử lý tính nhất quán cuối cùng (eventual consistency) và các điều kiện tranh chấp (race conditions). Bằng cách đọc trạng thái mới từ các replica ngay trước khi thực thi, Cloudflare giảm thiểu rủi ro hành động dựa trên thông tin lỗi thời mà không làm tắc nghẽn đường ống nạp dữ liệu (ingestion pipeline). Mô hình lập kế hoạch thận trọng sau đó xác minh vào phút chót là một chiến lược mạnh mẽ cho các hệ thống phân tán, nơi thứ tự sự kiện và độ trễ nhân bản cơ sở dữ liệu là những thách thức cố hữu. Nó cho thấy khả năng phục hồi không luôn đòi hỏi thêm thời gian chờ; đôi khi, nó yêu cầu xác minh thông minh hơn tại thời điểm hành động.

Bạn có thể làm gì

• Kiểm tra các đường ống dữ liệu của bạn để xác định các quy trình thực hiện tái tạo toàn bộ khi chỉ cần cập nhật một phần.
• Triển khai một hệ thống phân loại thay đổi để xác định phạm vi công việc tối thiểu cần thiết cho từng loại sự kiện.
• Sử dụng bộ lập lịch thống nhất để gộp các sự kiện liên quan, giảm bớt chi phí phát sinh do chuyển đổi ngữ cảnh và thiết lập lặp lại.
• Xác minh trạng thái cuối cùng với một nguồn sự thật (source of truth) mới ngay trước khi thực thi để xử lý an toàn độ trễ nhân bản.
• Đặt giới hạn cứng cho các thao tác nặng về bộ nhớ và xác định các chiến lược dự phòng, chẳng hạn như tái tạo một phần, cho các trường hợp cực đoan.
• Đảm bảo rằng bất kỳ bản cập nhật có mục tiêu nào cũng tạo ra đầu ra giống hệt với bản tái tạo toàn bộ để duy trì các cam kết về tính toàn vẹn dữ liệu.