Netlify chuyển Edge Functions sang Firecracker MicroVM: nhanh gấp 5 lần

Netlify vừa công bố quá trình xây dựng lại toàn bộ hạ tầng đằng sau Edge Functions, chuyển từ dịch vụ thực thi bên ngoài sang Firecracker MicroVM chạy ngay trong mạng lưới edge của chính họ. Kết quả đo được là tốc độ nhanh hơn khoảng 5 lần ở mức trung vị, độ khả dụng lên tới 99,998%. Điều đáng chú ý là thay đổi này không ảnh hưởng gì đến cách lập trình viên viết và sử dụng Edge Functions.

Bài toán đặt ra

Mỗi ngày có khoảng một tỷ Edge Functions chạy trên Netlify — từ việc cá nhân hóa trang cho Sunweb, định tuyến lưu lượng dựa trên cookie cho Loto-Québec, cho đến hàng trăm nghìn trang web khác làm đủ thứ từ cá nhân hóa, định tuyến đến xác thực. Tất cả đều chạy trên một runtime JavaScript đầy đủ, mở rộng theo lưu lượng của khách hàng.

Thách thức kỹ thuật nằm ở chỗ: để chạy hàng chục, thậm chí hàng trăm nghìn edge function mỗi giây, hệ thống phải xử lý từng request, định tuyến chính xác, cấp phát tài nguyên tính toán và khởi động cả code của nền tảng lẫn code của khách hàng — tất cả trong vòng vài mili giây. Trước đây, mọi request đều phải rời khỏi mạng lưới Netlify, đi ra internet để thực thi rồi quay về, khiến độ trễ đội lên đáng kể.

Những con số biết nói

Một lần gọi hàm ở trạng thái "nóng" (warm) — bao gồm định tuyến tới node tính toán, vào MicroVM, chạy hàm và tạo header phản hồi — nay chỉ tốn:

• ~5–6ms ở mức trung vị (p50), giảm mạnh so với 25–40ms trước đây
• Nhanh hơn 47,4% ở p99
• Độ khả dụng 99,998%
• Giao log nhanh gấp 5 lần

Sơ đồ độ trễ trung vị của Edge Functions

Còn với lần gọi "lạnh" (cold invocation) — khi request đến một vùng mà chưa node tính toán nào từng thấy — hệ thống cần tải các image liên quan trước khi chạy được. Tình huống này xảy ra với khoảng 1,2% số lần gọi và tốn trung bình khoảng 9ms.

Hành trình của một request

Đường đi của request qua edge node và compute node

Để hiểu rõ hơn, hãy đi theo đường đi của một request đơn lẻ, theo đúng thứ tự.

Request đến edge node. Mọi request đều đáp xuống edge node gần khách hàng nhất. Node này kết thúc kết nối TLS và kiểm tra đường dẫn request với các tuyến Edge Functions của bản triển khai đó. Nếu không khớp gì, request đi tiếp vào cache rồi ra origin như bình thường. Nếu khớp, đây chính là điểm mà trước kia request rời khỏi mạng lưới Netlify — nhưng nay nó được chuyển thẳng đến một compute node nội bộ.

Edge node ghi bản đặc tả. Trước khi request đi bất cứ đâu, edge node ghi ra một bản đặc tả cho cỗ máy sẽ chạy hàm. Bản đặc tả này nêu tên ba image: runtime, image nền tảng của Netlify và image của edge function. Nó cũng đặt giới hạn CPU, bộ nhớ và số kết nối. Bản đặc tả đi kèm request trong mọi lần gọi. Hash của nó cùng thông tin riêng theo site tạo thành một service ID — nhờ đó hai bản triển khai có code hoặc biến môi trường khác nhau sẽ là hai service khác nhau và không bao giờ dùng chung MicroVM.

Sự cô lập này quan trọng nhất với những thất bại mà Netlify không muốn có thể xảy ra. Một bản triển khai có nguy cơ bị xâm nhập sẽ chạy trong MicroVM riêng, và kể cả nếu nó thoát khỏi runtime, nó cũng không thể làm hỏng khách hàng khác hay chính tầng tính toán.

Chọn compute node. Mỗi vùng có một nhóm compute node. Edge node chọn node cho service bằng rendezvous hashing: cùng một service luôn đáp xuống cùng một node, nhờ đó MicroVM luôn ấm và code đã nằm sẵn trên đĩa lẫn trong cache. Tuy nhiên, gửi mọi request về cùng một node cũng tạo ra điểm nóng. Netlify xử lý bằng cách nới lỏng tính dính khi vượt một ngưỡng nhất định, trải service ra một lát cắt các node để hấp thụ đột biến lưu lượng mà không ảnh hưởng đến các service khác.

Khởi động MicroVM. Mỗi hàm chạy trong MicroVM Firecracker riêng, được tạo trong chưa đầy một mili giây và khởi động trong khoảng 2ms ở p99. Lý do là VM khởi động một môi trường Linux tinh gọn thay vì cả hệ điều hành đầy đủ. Các file của edge function được gắn dưới dạng image EROFS không nén rồi memory-map, nên VM chỉ đọc những phần thực sự dùng đến. Khi MicroVM khởi động xong và server JavaScript bắt đầu lắng nghe trên một cổng, hệ thống chụp lại snapshot. Khi hàm không được gọi, các MicroVM co về 0 thay vì ngồi không; lần gọi sau sẽ khởi động MicroVM mới từ snapshot đó.

Compute node và cơ chế memory-map snapshot

Vòng đời VM — khởi động, chụp snapshot, phục hồi và co về 0 — là sản phẩm của Unikraft. Netlify phối hợp chặt với đội Unikraft trong suốt quá trình di trú để đảm bảo hệ thống trụ vững trước lưu lượng và các kiểu mẫu truy cập của họ.

Những bài học sau nhiều năm vận hành

Vận hành dự án này suốt vài năm, Netlify đã rút ra nhiều bài học để tối ưu hiệu năng và khả năng gỡ lỗi. Ở quy mô lớn, họ từng gặp đủ loại sự cố — từ cạn cổng trên switch ảo đến DNS (một điều khiến chính họ bất ngờ, nhưng không phải lúc nào cũng là DNS).

Các circuit breaker bảo vệ hệ thống tính toán

Trong lần thiết kế lại này, các compute node chạy DNS resolver cục bộ. Họ cũng mở rộng bộ chỉ số thu thập, ghi lại những thứ như thời gian khởi động, thời gian mở cổng đầu tiên và thời gian bắt đầu code người dùng. Đặc biệt, hệ thống có nhiều circuit breaker để đảm bảo việc định tuyến lại và ngừng sử dụng compute node diễn ra kịp thời.

Thiết kế hạ tầng vừa nhanh vừa chịu lỗi

Khi xây một hệ thống như trên, người ta phải tối ưu đồng thời hai thứ: trải nghiệm người dùng cuối và độ bền vững của quá trình triển khai. Cần đẩy thay đổi ra nhanh nhưng cũng phải có khả năng hoàn tác nhanh không kém.

Các compute node được dựng từ một image nền do Unikraft phát hành rồi cài thêm một bộ gói. Chúng được xây tách biệt khỏi edge node vì ba lý do: giữ edge node nhẹ và nhanh, cho phép dùng loại instance khác cho compute node, và cho phép mở rộng các node này độc lập. Một control plane theo dõi node nào tồn tại và node nào khỏe mạnh; edge node định kỳ hỏi nó để lấy danh sách. Control plane cũng là thứ điều khiển việc triển khai — một đội hình mới được dựng lên song song, mở rộng cho khớp rồi chỉ tiếp nhận lưu lượng khi đã khỏe mạnh.

Điều này mở ra cơ hội gì?

Việc tự vận hành tầng tính toán đồng nghĩa giới hạn của Edge Functions giờ do chính Netlify quyết định. Ba thứ từng bất khả thi nay đã nằm trong tầm tay:

• Hỗ trợ gói npm thoát khỏi giai đoạn beta. Gói npm hiện chạy trong edge function ở dạng beta với các rào cản về native binary và import file lúc runtime. Một VM thật với hệ thống file thật sẽ xóa bỏ phần lớn lý do tồn tại của những rào cản đó.
• Có dư địa xem lại giới hạn vận hành. Các giới hạn được ghi trong tài liệu như 50ms CPU mỗi request, 512MB bộ nhớ và 20MB code nén đều bắt nguồn từ mô hình thực thi dựa trên isolate.
• Tính toán ngay trong mạng lưới riêng. Bất cứ thứ gì phụ thuộc vào việc kiểm soát đường đi mạng, thay vì phải vươn ra bên thứ ba qua internet, giờ đều có thể xây dựng được.

Toàn bộ công trình đã chạy thật, phục vụ lưu lượng sản xuất ngay hôm nay, với mức giá giữ nguyên, không cần bước di trú và không cần thay đổi gì trong bất kỳ dự án nào. Đây không chỉ là một cú tăng tốc — đó là nền tảng tốc độ cao hơn mà Netlify có thể tiếp tục xây dựng lên, đồng thời nắm quyền kiểm soát nhiều hơn với toàn bộ vòng đời request.