Nếu bạn từng đọc về cách chạy an toàn mã do AI tạo ra, hẳn bạn đã gặp chữ microVM, thường đi kèm Firecracker. Nó hoặc được giải thích là “một VM nhẹ” (đúng, nhưng chẳng giúp ích gì), hoặc bằng sơ đồ nội tạng của kernel. Đây là phiên bản ở giữa.
Hai lựa chọn cũ, và vì sao không cái nào phù hợp
Hãy bắt đầu từ hai thứ mà microVM nằm ở giữa.
Container là một nhóm tiến trình bình thường trên máy của bạn mà kernel đã đồng ý nói dối. Namespace cho chúng thấy hệ thống tệp, danh sách tiến trình và mạng riêng; cgroup giới hạn lượng CPU và bộ nhớ chúng được dùng. Nó khởi động trong mili giây vì không có gì mới được khởi động. Nhưng mọi container trên một máy chủ đều nói chuyện với cùng một kernel. Một lỗi kernel có thể chạm tới từ một container là lối thoát khỏi tất cả.
Máy ảo mang kernel riêng. CPU của máy chủ, nhờ ảo hóa phần cứng (KVM trên Linux), chạy máy khách như thể nó có máy tính riêng. Ranh giới là hypervisor, thứ để lộ ít hơn nhiều so với hàng trăm lệnh gọi hệ thống của một kernel. Cái giá là sự nặng nề. Một VM cổ điển mô phỏng cả một chiếc PC: firmware, bus PCI, bộ điều khiển USB, card đồ họa, đôi khi cả card âm thanh. Nó khởi động qua tất cả những thứ đó, mất từ vài giây đến vài phút, và mỗi phiên bản mang theo hàng chục hoặc hàng trăm megabyte overhead.
Một phép so sánh khá đứng vững: container là các căn hộ trong cùng một tòa nhà, dùng chung móng, đường ống và dây điện. VM là những ngôi nhà riêng. Nhà riêng là hàng xóm an toàn hơn, nhưng chẳng ai xây nhà cho một chuyến ghé thăm kéo dài 20 giây.
Firecracker bỏ đi những gì
Firecracker là một trình giám sát máy ảo (chương trình thiết lập và chạy VM trên KVM) viết bằng Rust và được mở mã nguồn năm 2018. Nó được làm ra cho một việc: chạy số lượng khổng lồ các khối lượng công việc ngắn hạn, không tin tưởng lẫn nhau, trên phần cứng dùng chung. Nó đạt được điều đó chủ yếu bằng cách lược bỏ:
- Không firmware, không dò phần cứng. Kernel được nạp thẳng vào bộ nhớ và khởi động. Không ai đi tìm những thiết bị không tồn tại.
- Mô hình thiết bị tí hon. Một card mạng, một thiết bị khối, một console nối tiếp và vài thứ nữa, tất cả đều là virtio (thiết bị được thiết kế cho máy ảo thay vì bắt chước thiết bị vật lý). Không USB, không đồ họa, không PCI.
- Mã nguồn nhỏ, an toàn bộ nhớ. Ít mã mô phỏng thiết bị hơn nghĩa là ít chỗ cho một lỗi giúp máy khách chạm tới máy chủ.
- Một chiếc lồng quanh chính VMM. Mỗi tiến trình Firecracker chạy trong một chroot, với bộ lọc seccomp cho lệnh gọi hệ thống của chính nó và cgroup cho tài nguyên. Nếu có gì thoát ra khỏi máy khách, nó sẽ rơi vào lồng, không phải lên máy chủ.
Các con số do chính dự án công bố: vào không gian người dùng chỉ trong 125 ms và overhead bộ nhớ dưới 5 MiB mỗi microVM. Đó là giá trị phòng thí nghiệm tốt nhất; một sandbox thực tế còn cần chuẩn bị ổ đĩa, mạng và chờ một agent bên trong sẵn sàng nhận lệnh, vì vậy sandbox của chúng tôi sẵn sàng trong khoảng một giây. Như vậy vẫn đủ gần tốc độ container để tạo mỗi tác vụ một cái rồi vứt đi sau đó.
Container và microVM trong thực tế
| Container | MicroVM Firecracker | |
|---|---|---|
| Kernel | dùng chung với máy chủ | riêng |
| Ranh giới với máy chủ | lệnh gọi hệ thống vào kernel dùng chung | hypervisor + VMM nhỏ |
| Thời gian khởi động | mili giây | ~0.1–1 giây |
| Overhead mỗi phiên bản | rất nhỏ | vài MiB |
| Thiết bị | những gì máy chủ để lộ | mạng, ổ đĩa, console |
| GPU | có thể | không |
| Phù hợp cho | mã của chính bạn, đóng gói ứng dụng | mã không đáng tin, khối lượng nhiều khách thuê |
Hàng quan trọng là hàng thứ hai. Với container, câu hỏi “mã này có thoát ra được không?” trở thành “có lỗi nào chạm tới được ở đâu đó trong kernel máy chủ không?”. Với microVM, nó trở thành “có lỗi nào trong hypervisor hay trong một nhúm thiết bị ảo không?”. Bề mặt thứ hai nhỏ hơn nhiều, và đó cũng chính là thứ các nền tảng đám mây vốn đã phải bảo vệ cho dịch vụ lưu trữ nhiều khách thuê của họ.
Những gì bạn đánh đổi
MicroVM không phải một bản nâng cấp miễn phí.
- Không GPU, không màn hình. Nó dùng để chạy mã, không phải desktop hay đồ họa.
- Ít thiết bị hơn, kém linh hoạt hơn. Bất cứ thứ gì cần phần cứng thật hoặc một danh sách dài mô-đun kernel sẽ không thấy thoải mái.
- Ranh giới vẫn cần chính sách. Một microVM mở lưu lượng đi ra vẫn có thể gửi lưu lượng bạn không muốn; một microVM chứa khóa API của bạn vẫn có thể làm lộ chúng. Cô lập bảo vệ máy chủ khỏi máy khách, chứ không bảo vệ bí mật của bạn khỏi đoạn mã mà bạn đã trao chúng cho.
Sandbox của chúng tôi dùng nó thế nào
Mỗi sandbox EQVPS là một microVM Firecracker với kernel riêng, từ 0.25 vCPU và 512 MB đến 8 vCPU và 16 GB. Nó có Python 3.12, Node.js 22, bash, git và curl, có internet đi ra và không có cổng vào. Sandbox tạm thời bị xóa khi bạn xong việc; sandbox persistent giữ ổ đĩa, và việc tạm dừng sẽ ghi một bản chụp của microVM xuống đĩa, nên nó không tốn gì cho đến khi chạy tiếp. Snapshot tạm dừng được giữ 14 ngày. Sau đó sandbox bị xóa và id của nó trả về 410 sandbox_deleted.
Chúng tôi chọn microVM thay vì container vì một lý do: mã chạy trong sandbox, theo định nghĩa, là mã chưa ai xem xét. Đầu ra của một AI agent, pull request của người lạ, một benchmark gồm một nghìn chương trình do mô hình viết. Với những thứ đó, một kernel riêng là ranh giới đáng để trả tiền. Chi tiết những gì chúng tôi xây quanh nó — các gói, hạn mức, giới hạn 55 giây cho lệnh đồng bộ — có trong tài liệu sandbox.
Nếu muốn so sánh ranh giới này với các lựa chọn khác kỹ hơn, các mức cô lập cho mã không đáng tin đặt tiến trình, container, microVM và VM đầy đủ cạnh nhau. Còn nếu điều thu hút bạn là giá theo giây, tính phí theo giây thực sự hoạt động ra sao trình bày phép tính.
Bình luận
Chưa có bình luận nào. Hãy là người đầu tiên.