ถ้าคุณเคยอ่านอะไรเกี่ยวกับการรันโค้ดที่ AI สร้างขึ้นอย่างปลอดภัย คุณคงเคยเห็นคำว่า microVM มักอยู่ข้าง ๆ คำว่า Firecracker คำอธิบายมักเป็นแค่ “VM น้ำหนักเบา” (จริง แต่ไม่ช่วยอะไร) หรือไม่ก็แผนภาพภายในเคอร์เนล นี่คือเวอร์ชันที่อยู่ตรงกลาง
สองตัวเลือกที่เก่ากว่า และทำไมไม่มีอันไหนเหมาะ
เริ่มจากสองสิ่งที่ microVM อยู่ตรงกลาง
คอนเทนเนอร์ คือกลุ่มของโปรเซสธรรมดาบนเครื่องของคุณ ที่เคอร์เนลยอม “หลอก” พวกมัน namespaces ทำให้พวกมันเห็นระบบไฟล์ รายการโปรเซส และเครือข่ายของตัวเอง ส่วน cgroups จำกัดว่าใช้ CPU และหน่วยความจำได้เท่าไร มันเริ่มทำงานในระดับมิลลิวินาทีเพราะไม่มีอะไรใหม่ต้องบูต แต่คอนเทนเนอร์ทุกตัวบนโฮสต์คุยกับเคอร์เนลเดียวกัน บั๊กในเคอร์เนลที่เข้าถึงได้จากในคอนเทนเนอร์หนึ่ง คือทางออกจากทุกคอนเทนเนอร์
เครื่องเสมือน มีเคอร์เนลของตัวเอง CPU ของโฮสต์ใช้การจำลองเสมือนระดับฮาร์ดแวร์ (KVM บน Linux) รันเกสต์ราวกับว่ามันมีคอมพิวเตอร์ของตัวเอง ขอบเขตคือไฮเปอร์ไวเซอร์ ซึ่งเปิดเผยน้อยกว่า system call หลายร้อยตัวของเคอร์เนลมาก ราคาที่ต้องจ่ายคือความหนัก VM แบบคลาสสิกจำลองพีซีทั้งเครื่อง: เฟิร์มแวร์ บัส PCI ตัวควบคุม USB การ์ดจอ บางครั้งก็การ์ดเสียงด้วย มันบูตผ่านทั้งหมดนั้น ใช้เวลาตั้งแต่วินาทีถึงนาที และแต่ละอินสแตนซ์แบกโอเวอร์เฮดหลายสิบหรือหลายร้อยเมกะไบต์
อุปมาที่ใช้ได้ดีพอสมควร: คอนเทนเนอร์คือห้องชุดในอาคารเดียวกัน ใช้ฐานราก ท่อ และสายไฟร่วมกัน VM คือบ้านแยกหลัง บ้านเป็นเพื่อนบ้านที่ปลอดภัยกว่า แต่ไม่มีใครสร้างบ้านเพื่อการมาเยือน 20 วินาที
Firecracker ตัดอะไรออกไป
Firecracker เป็น virtual machine monitor (โปรแกรมที่ตั้งค่าและรัน VM บน KVM) เขียนด้วย Rust และเปิดซอร์สตั้งแต่ปี 2018 มันถูกสร้างมาเพื่องานเดียว: รันเวิร์กโหลดอายุสั้นที่ไม่ไว้ใจกันจำนวนมหาศาลบนฮาร์ดแวร์ที่ใช้ร่วมกัน มันไปถึงจุดนั้นด้วยการตัดสิ่งต่าง ๆ ออกเป็นหลัก:
- ไม่มีเฟิร์มแวร์ ไม่มีการค้นหาฮาร์ดแวร์ เคอร์เนลถูกโหลดเข้าหน่วยความจำโดยตรงแล้วเริ่มทำงาน ไม่มีอะไรไปค้นหาอุปกรณ์ที่ไม่มีอยู่
- โมเดลอุปกรณ์ขนาดจิ๋ว การ์ดเครือข่าย อุปกรณ์บล็อก คอนโซลอนุกรม และอีกเล็กน้อย ทั้งหมดเป็น virtio (อุปกรณ์ที่ออกแบบมาสำหรับเครื่องเสมือน ไม่ใช่การเลียนแบบอุปกรณ์จริง) ไม่มี USB ไม่มีกราฟิก ไม่มี PCI
- โค้ดเบสเล็กและปลอดภัยด้านหน่วยความจำ โค้ดที่จำลองอุปกรณ์น้อยลง หมายถึงที่ซ่อนของบั๊กที่ทำให้เกสต์เข้าถึงโฮสต์ได้น้อยลง
- กรงรอบตัว VMM เอง โปรเซส Firecracker แต่ละตัวรันอยู่ใน chroot มีตัวกรอง seccomp จำกัด system call ของมันเอง และ cgroups จำกัดทรัพยากรของมัน ถ้ามีอะไรหลุดออกจากเกสต์ได้จริง มันจะไปตกอยู่ในกรง ไม่ใช่บนโฮสต์
ตัวเลขที่โปรเจกต์เผยแพร่เอง: เข้าสู่ user space ได้ในเวลาเพียง 125 ms และโอเวอร์เฮดหน่วยความจำไม่ถึง 5 MiB ต่อ microVM นี่คือตัวเลขที่ดีที่สุดในห้องแล็บ แซนด์บ็อกซ์จริงยังต้องเตรียมดิสก์และเครือข่าย และมีเอเจนต์ข้างในที่พร้อมรับคำสั่ง ของเราจึงพร้อมใช้ในราวหนึ่งวินาที ซึ่งยังใกล้ความเร็วของคอนเทนเนอร์พอที่คุณจะสร้างหนึ่งตัวต่องานแล้วทิ้งได้
คอนเทนเนอร์กับ microVM ในทางปฏิบัติ
| คอนเทนเนอร์ | Firecracker microVM | |
|---|---|---|
| เคอร์เนล | ใช้ร่วมกับโฮสต์ | ของตัวเอง |
| ขอบเขตกับโฮสต์ | system call เข้าสู่เคอร์เนลที่ใช้ร่วมกัน | ไฮเปอร์ไวเซอร์ + VMM ขนาดเล็ก |
| เวลาเริ่มทำงาน | มิลลิวินาที | ~0.1–1 วิ |
| โอเวอร์เฮดต่ออินสแตนซ์ | น้อยมาก | ไม่กี่ MiB |
| อุปกรณ์ | อะไรก็ตามที่โฮสต์เปิดให้ | เครือข่าย ดิสก์ คอนโซล |
| GPU | ทำได้ | ไม่ได้ |
| เหมาะกับ | โค้ดที่ไว้ใจได้ การแพ็กแอป | โค้ดที่ไม่น่าไว้ใจ เวิร์กโหลดหลายผู้เช่า |
แถวที่สำคัญคือแถวที่สอง สำหรับคอนเทนเนอร์ คำถาม “โค้ดนี้หนีออกมาได้ไหม?” จะกลายเป็น “มีบั๊กที่เข้าถึงได้ที่ไหนสักแห่งในเคอร์เนลของโฮสต์ไหม?” สำหรับ microVM จะกลายเป็น “มีบั๊กในไฮเปอร์ไวเซอร์หรืออุปกรณ์เสมือนไม่กี่ชิ้นไหม?” พื้นผิวแบบหลังเล็กกว่ามาก และเป็นพื้นผิวเดียวกับที่แพลตฟอร์มคลาวด์ปกป้องอยู่แล้วสำหรับโฮสติ้งหลายผู้เช่าของตัวเอง
สิ่งที่คุณต้องแลก
microVM ไม่ใช่การอัปเกรดฟรี
- ไม่มี GPU และไม่มีจอแสดงผล มันมีไว้รันโค้ด ไม่ใช่สำหรับเดสก์ท็อปหรือเวิร์กโหลดกราฟิก
- อุปกรณ์น้อยลง ความยืดหยุ่นน้อยลง อะไรก็ตามที่คาดหวังฮาร์ดแวร์จริง หรือรายการโมดูลเคอร์เนลยาว ๆ จะไม่รู้สึกเหมือนอยู่บ้าน
- ขอบเขตยังต้องมีนโยบาย microVM ที่เปิดทราฟฟิกขาออกยังส่งทราฟฟิกที่คุณไม่ต้องการได้ ตัวที่มีคีย์ API ของคุณอยู่ข้างในก็ยังทำให้มันรั่วได้ การแยกส่วนปกป้องโฮสต์จากเกสต์ ไม่ได้ปกป้องความลับของคุณจากโค้ดที่คุณมอบมันให้เอง
แซนด์บ็อกซ์ของเราใช้มันอย่างไร
แซนด์บ็อกซ์ของ EQVPS แต่ละตัวคือ Firecracker microVM หนึ่งตัวที่มีเคอร์เนลของตัวเอง ตั้งแต่ 0.25 vCPU และ 512 MB ไปจนถึง 8 vCPU และ 16 GB มาพร้อม Python 3.12, Node.js 22, bash, git และ curl เข้าอินเทอร์เน็ตขาออกได้และไม่มีพอร์ตขาเข้า แซนด์บ็อกซ์ชั่วคราวจะถูกลบเมื่อคุณใช้เสร็จ ส่วนแบบ persistent จะเก็บดิสก์ไว้ และการหยุดชั่วคราวจะเขียนสแนปช็อตของ microVM ลงดิสก์ จึงไม่มีค่าใช้จ่ายจนกว่าจะกลับมาทำงาน snapshot ที่หยุดชั่วคราวเก็บไว้ 14 วัน หลังจากนั้น sandbox จะถูกลบ และ id ของมันจะส่งคืน 410 sandbox_deleted
เราเลือก microVM แทนคอนเทนเนอร์ด้วยเหตุผลเดียว: โค้ดที่รันในแซนด์บ็อกซ์ โดยการออกแบบแล้วคือโค้ดที่ไม่มีใครรีวิว ผลลัพธ์ของ AI agent, pull request ของคนแปลกหน้า, เบนช์มาร์กของโปรแกรมหนึ่งพันตัวที่โมเดลเขียน สำหรับสิ่งเหล่านี้ เคอร์เนลของตัวเองคือขอบเขตที่คุ้มค่าที่จะจ่าย รายละเอียดของสิ่งที่เราสร้างไว้รอบ ๆ — แพ็กเกจ โควตา ขีดจำกัด 55 วินาทีสำหรับคำสั่งแบบซิงโครนัส — อยู่ในเอกสารแซนด์บ็อกซ์
ถ้าคุณอยากเปรียบเทียบขอบเขตนี้กับตัวเลือกอื่นอย่างลึกซึ้งขึ้น ระดับการแยกส่วนสำหรับโค้ดที่ไม่น่าไว้ใจ วางโปรเซส คอนเทนเนอร์ microVM และ VM เต็มรูปแบบไว้เทียบกัน และถ้าราคารายวินาทีคือสิ่งที่ดึงดูดคุณ การคิดเงินรายวินาทีทำงานอย่างไรจริง ๆ แสดงการคำนวณให้ดู
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกสิ