Rời AWS Route 53 sang Bunny DNS để tiết kiệm chi phí

Chi phí dịch vụ đám mây luôn là bài toán đau đầu với những người tự vận hành hạ tầng. Vincent Bernat, tác giả blog kỹ thuật vincent.bernat.ch, vừa chia sẻ hành trình chuyển hệ thống DNS định tuyến theo vị trí địa lý (GeoDNS) từ Amazon Route 53 sang Bunny DNS — và hóa đơn hàng tháng của anh giảm từ 5 USD xuống còn 1 USD, tức chỉ còn một phần năm.

Bản đồ phân bố máy chủ DNS

Vì sao Route 53 trở nên quá đắt?

Trước đây, Bernat dùng Amazon CloudFront để phân phối tài nguyên tĩnh và Route 53 để đưa người đọc tới máy chủ gần nhất. Nhưng chi phí của Route 53 cộng dồn khá nhanh: 0,50 USD mỗi zone mỗi tháng, 0,70 USD mỗi triệu truy vấn địa lý, 0,75 USD mỗi healthcheck mỗi tháng, chưa kể 1 USD mỗi tháng cho khóa KMS cần thiết để ký các zone bằng DNSSEC (cơ chế xác thực tên miền chống giả mạo).

Khi biết Bunny DNS gần như miễn phí với tối đa 500 tên miền và hỗ trợ trả lời bằng script, anh quyết định chuyển đổi. Một điểm cộng nữa: Bunny.net là công ty châu Âu có trụ sở tại Slovenia.

Bunny CDN và Bunny DNS có gì đặc biệt?

Bunny.net khởi đầu với dịch vụ BunnyCDN năm 2015 và bổ sung IPv6 năm 2017. Việc chuyển sang nền tảng mới diễn ra suôn sẻ. Vì phụ thuộc vào kỹ thuật thương lượng nội dung (content negotiation) để trả về ảnh AVIF và WebP, anh cấu hình CDN lưu đệm riêng cho từng định dạng ảnh. Anh cũng tắt tính năng ghi log để tránh thu thập thông tin cá nhân.

Điểm trừ duy nhất của Bunny CDN là chưa hỗ trợ HTTP/3. Khi hỏi bộ phận hỗ trợ, chỉ hai phút sau họ trả lời rằng đang phát triển nhưng chưa có thời điểm ra mắt cụ thể.

Bunny DNS ra mắt năm 2022 và mới đây đã hạ giá xuống gần như bằng không. Dịch vụ hỗ trợ định tuyến địa lý, nhưng điểm hấp dẫn nhất là DNS lập trình được (scriptable DNS): hệ thống chạy một đoạn JavaScript do người dùng cung cấp trên mỗi truy vấn để tự tính toán câu trả lời.

Bài toán chọn máy chủ gần nhất

Bernat vận hành bảy máy ảo NixOS nhỏ rải khắp thế giới: Paris, Nuremberg, Ashburn, Singapore, San Jose, São Paulo và Sydney. Nhờ DNS lập trình được của Bunny, anh có thể trả về địa chỉ IP của hai máy chủ gần người dùng nhất, và trình duyệt sẽ tự chuyển sang máy chủ thứ hai nếu máy đầu tiên gặp sự cố.

Đoạn script dựa vào hàm hỗ trợ RoutingEngine.getClosestServer() để xác định máy chủ còn hoạt động gần nhất. Dùng công cụ Doggo, anh kiểm tra được rằng truy vấn từ Amsterdam nhận về IP ở Paris, còn từ Texas nhận về máy chủ ở Ashburn.

Tuy nhiên, cách làm này có nhược điểm: người dùng ở Buenos Aires nhận về cả São Paulo (cách 1.000 dặm, độ trễ 30 ms) lẫn Ashburn (cách 5.200 dặm, độ trễ 140 ms). Vì phần lớn trình phân giải DNS xáo trộn thứ tự, người dùng có thể phải tải trang từ máy chủ xa hơn.

Thử với bản ghi HTTPS rồi quay lại điểm xuất phát

Bernat đã cân nhắc bản ghi HTTPS của DNS (định nghĩa trong RFC 9460), vốn cho phép chỉ định máy chủ ưu tiên và máy chủ dự phòng kèm giao thức HTTP/3. Về lý thuyết, đây là giải pháp hoàn hảo cho cả độ trễ lẫn tính sẵn sàng. Nhưng thực tế Chrome bỏ qua mọi bản ghi có đích không phải dấu chấm, và Bunny DNS không trả kèm địa chỉ IP trong phần bổ sung như với CNAME. Kết quả là trình phân giải phải gửi hai truy vấn thay vì một. Bản ghi HTTPS vẫn còn quá mới cho trường hợp sử dụng này.

Giải pháp lai

Cuối cùng, anh chọn cách dung hòa: script trả về hai máy chủ gần nhất nếu khoảng cách giữa chúng tương đương; nếu máy chủ thứ hai xa gấp đôi và cách hơn 1.000 dặm, chỉ trả về máy chủ gần nhất với TTL thấp hơn, chỉ 2 phút.

Kết quả kiểm tra: từ Chicago chỉ nhận về máy chủ Ashburn với TTL 120 giây, còn từ Mexico nhận về cả Ashburn lẫn San Jose với TTL 3.600 giây. Mã nguồn đầy đủ có phần phức tạp hơn một chút, xử lý trường hợp hàm hỗ trợ chỉ hỗ trợ IPv4 và trường hợp không đủ máy chủ hoạt động để dựng câu trả lời. Anh dùng CDK Terrain để dựng trạng thái đích bằng TypeScript và OpenTofu để triển khai, tận dụng nhà cung cấp Terraform đầy đủ của Bunny.net.

Chứng chỉ ACME bằng Hickory DNS

Route 53 còn đảm nhận một việc khác: phục vụ zone acme.luffy.cx để giải bài thử thách DNS-01 của ACME (giao thức cấp chứng chỉ tự động). Vì Bunny DNS không cho phép giới hạn quyền truy cập ở mức từng zone, anh thay bằng Hickory, một DNS server viết bằng Rust với bộ nhớ an toàn, hỗ trợ tự động ký DNSSEC và cập nhật động qua SQLite. Cấu hình chỉ gồm vài dòng khai báo zone, khóa ký ECDSA P-256 và khóa TSIG.

Một hạn chế khác: Bunny DNS không thể công bố bản ghi DS trong một zone, mà đây là yêu cầu bắt buộc để bảo vệ zone acme.luffy.cx. Vì vậy anh vẫn phải đặt zone luffy.cx tại deSEC, dịch vụ lưu trữ DNS miễn phí của một tổ chức phi lợi nhuận tại Berlin.

Góc nhìn

Câu chuyện này đáng chú ý với các kỹ sư và đội vận hành tại Việt Nam đang tự dựng hạ tầng. DNS lập trình được biến một dịch vụ tưởng như đơn giản thành công cụ định tuyến linh hoạt, cho phép mỗi đội tự mã hóa logic chọn máy chủ thay vì phụ thuộc hoàn toàn vào tính năng có sẵn của nhà cung cấp lớn. Khi phải phục vụ người dùng trải khắp các vùng miền, cách tiếp cận này giúp giảm chi phí đáng kể mà vẫn giữ được độ trễ thấp.

Tuy nhiên, bài viết cũng cho thấy những điểm cần lưu ý trước khi chuyển đổi: khả năng công bố bản ghi DS, mức độ hỗ trợ HTTP/3 và giới hạn quyền truy cập theo zone đều là những ràng buộc thực tế có thể phát sinh. Việc chia tách hệ thống — dùng nhà cung cấp này cho lưu lượng chính, nhà cung cấp khác cho các zone phụ — là chiến lược hợp lý để vừa tối ưu chi phí vừa giữ được tính sẵn sàng.