Firecracker คืออะไร และทำไมบริษัท Agent Infra ทั้งหลายถึงให้ความสำคัญกับมัน?

ทุกวัน AWS Lambda ทำงานฟังก์ชันนับล้านล้านครั้ง AWS Fargate จัดการคอนเทนเนอร์นับล้านตัว แต่ละตัวคือ เครื่องเสมือน เต็มรูปแบบ ที่มีเคอร์เนิร์นเนลของตัวเอง ซึ่งบูตขึ้นมาในเวลาเพียงเสี้ยววินาที

ทำยังไง?

คำตอบคือโค้ด Rust ประมาณ 50,000 บรรทัดที่ชื่อ Firecracker ซึ่งเกิดขึ้นเพราะอุตสาหกรรมยอมรับในที่สุดว่าคอนเทนเนอร์ Linux ที่ควบคุมการใช้ทรัพยากรักเรซอร์สนั้นไม่ได้ถูกออกแบบมาให้เป็นขอบเขตแดนความปลอดภัย

ปัญหาการแยกตัวแยก

ทุก Docker คอนเทนเนอร์บนแล็ปท็อปของคุณคือฟีเจอร์เคอร์เนิร์นเนล Linux สามอย่างที่อยู่ในเสื้อโค้ตตัวเดียวกัน:

• Namespaces คือผ้าปิดตา โพรเซสภายในจะเห็นระบบแบบส่วนตัวของระบบ: รายการ PID ของตัวเอง, สแต็กเครือข่าย, ตารางเมานต์, โฮสต์เนมสต์เนม และ ID ผู้ใช้ PID 1 ภายในคอนเทนเนอร์คือ PID สุ่มบางตัวบนโฮสต์ คอนเทนเนอร์มองไม่เห็นโพรเซสอื่นด้วยซ้ำ
• cgroups คอนโทรลกรุ๊ปคืองบประมาณ Control groups คือเลเยอร์บัญชีและจำกัดอัตราของเนิร์นเนล พวกมันจำกัดว่าโพรเซสทรีจะใช้ CPU, หน่วยความจำ, I/O ดิสก์ และแบนด์วิดท์เครือข่ายได้มากแค่ไหน
• seccomp + capabilities คือรายการอนุญาต capabilities แบ่งอำนาจของ root ออกเป็น ~40 สิทธิพิเศษแยกกัน (ผูก (ผูกพอร์ตต่ำ, โหลดโมดูลเนิร์นเนล, เมานต์ระบบไฟล์ ฯลฯ) เพื่อให้คุณให้เฉพาะที่ต้องการ seccomp คือตัวกรองต่อโพรเซสที่ตัดสินใจว่าซิสคอลไหน (API เดียวของยูเซอร์สเปซเข้าเนิร์นเนล) ที่โพรเซสจะทำได้

คุณสามารถพิสูจน์เองได้โดยไม่ต้องติดตั้ง Docker:

ทุกอย่างอื่นที่ Docker ทำ (เลเยอร์อิมเมจ, รีจิสทรี, DNS) คือการจัดการบนพื้นฐานนั้น

การป้องกันทั้งหมดนั้นไหลผ่านเนิร์นเนล Linux ตัวเดียว ซึ่งมีโค้ดประมาณ 30 ล้านบรรทัด ที่เปิดเผย 400+ ซิสคอล ทุกคอนเทนเนอร์บนโฮสต์เรียกใช้เนิร์นเนลเดียวกันนั้น บั๊กหนึ่งในซิสคอลใด ๆ ก็จบเกมสำหรับทุกเทนนต์บนเครื่องนั้น

เครื่องเสมือนเต็มรูปแบบแก้ปัญหาการแยกด้วยกำลัง: ทุก VM มีเนิร์นเนลของตัวเอง

CPU สมัยใหม่มี "โหมดเกสต์" ที่รันคำสั่งเกสต์บนซิลิคอนจริง โฮสคอนจริง โฮสต์จะถูกดึงเข้ามาเมื่อเกสต์ทำสิ่งที่ต้องสิทธิพิเศษ (แตะฮาร์ดแวร์จริง, ฟอลต์, ถูกขัดจังหวะ) ไฮเปอร์ไวเซอร์ คือเลเยอร์บางที่ตัดสินช่วงเวลาเหล่านั้น

Linux มีไฮเปอร์ไวเซอร์เป็นโมดูลเนิร์เนลที่ชื่อ KVM เปิดเผยที่ /dev/kvm มันทำงานบนส่วนขยายเวอร์ชวลไลเซชันของฮาร์ดแวร์ (vmx บน Intel, svm)

ปัญหาของ VM เต็มรูปแบบคือมันช้าและใหญ่ QEMU VM แบบคลาสสิกจำลองพีซีสมมติกรรมทั้งตัว (BIOS, PCI bus, IDE controller, VGA, PS/2 keyboard) เพราะนั่นคือสิ่งที่ OS ปี 1998 คาดว่าจะบูตกับ อิมเมจเป็นร้อยเมกะไบต์ บูตใช้เวลาวินาที ฟุตพริ้นท์หน่วยความจำหลายร้อย MiB ก่อนที่เวิร์กโหลดของคุณจะเริ่ม สำหรับคำขอเว็บที่อยู่ 40ms คุณจะใช้เวลา 40 เท่าบูตเครื่อง

คุณจึงติดอยู่ระหว่าง:

• คอนเทนเนอร์: บูต 50ms, โอเวอร์เฮด 5 MiB, พื้นผิวการโจมตีมมเนิร์นเนลร่วมกัน
• VM: บูต 5+ วินาที, โอเวอร์เฮด 300+ MiB, แยกด้วยฮาร์ดแวร์

ทุกคนที่รันโค้ดหลายเทนนต์ที่ไม่น่าเชื่อถือ (AWS และผู้ขาย AI แซนด์บ็อกซ์ที่มีอยู่) ต้องการทั้งสองด้านของการแลกเปลี่ยนนั้นพร้อมกัน

เข้าสู่ไมโคร VM

VMM (Virtual Machine Monitor) คือโพรเซสยูเซอร์สเปซที่ขับไฮเปอร์ไวเซอร์: มันตั้งค่าหน่วยความจำเกสต์, เสียบปลั๊กอุปกรณ์เสมือน และบอก KVM ให้เริ่มรันโค้ดเกสต์โค้ด

ไมโคร VM คือ VMM ที่ลบพีซีปี 1998 ออก: ไม่มี BIOS, ไม่มี PCI bus, ไม่มี VGA, ไม่มี USB, ไม่มี ACPI (ไม่มีฮาร์ดแวร์รุ่นเก่าที่เดสก์ท็อปจริงบูตผ่านการบูต และไม่เกี่ยวข้องกับฟังก์ชันคอล 40ms) สิ่งที่เหลือ: KVM, คอนโซลอนุกรม และอุปกรณ์ virtio สองสามตัว (net, block, vsock)

virtio คืออินเทอร์เฟซอุปกรณ์มาตรฐาน "ฉันรู้ว่าฉันกำลังรันใน VM" เกสต์ร่วมมือกับไฮเปอร์ไวเซอร์ผ่าน NIC และดิสก์เสมือนน้ำหนักเบา (virtio-net, virtio-block) แทนที่จะแสร้งทำเป็นขับ Intel e1000 จริงหรือ IDE คอนโทรลเลอร์ ความร่วมมือนั้น บวกกับฮาร์ดแวร์รุ่นเก่าที่หายไปทั้งหมดข้างต้น เป็นเหตุผลใหญ่ที่สุดที่ไมโคร VM บูตเร็ว

ผลลัพธ์:

• ~125ms บูตจาก VMM เปิดตัวถึงยูเซอร์สเปซเกสต์ที่รัน init
• <5 MiB โอเวอร์เฮดหน่วยความจำ VMM ต่อ VM (หน่วยความจำบัญชีที่โฮสต์จ่ายต่อ VM ก่อนที่เวิร์กโหลดเกสต์จะจัดสรรอะไรให้ตัวเอง)
• 150 VMs/วินาที อัตราการสร้างบนโฮสต์เดียว
• ~2–8% ผลกระทบประสิทธิภาพรันไทม์เทียบกับเครื่องเปล่า

การแยกระดับฮาร์ดแวร์เดียวกับ VM เต็มรูปแบบที่มีความหนาแน่นระดับเดียวกับคอนเทนเนอร์

Firecracker คือ VMM โพรเซสที่คุยกับ /dev/kvm และบูตไมโคร VM จริง ๆ ส่วนที่เหลือของโพสแต็กนี้ตั้งแต่ต้นจนจบ

Firecracker

ในพฤศจิกายน 2018 AWS เปิดซอร์ส Firecracker ที่ re:Invent มันรัน Lambda ในโปรดักชันอยู่แล้ว สิ่งที่ทำให้ import pandas ของคุณ cold-start เร็วพอที่จะคิดเงินต่อมิลลิวินาที ในปี 2020 ทีมตีพิมพ์สถาปัตยกรรมที่ NSDI '20

สถาปัตยกรรม

Forked จาก crosvm ของ Google เขียนใหม่ใน Rust โดยลบโค้ดมากกว่าคมากกว่าครึ่ง ทุกโพรเซส Firecracker คือหนึ่งไมโคร VM มีสามประเภทเธรด (บันทึกใน docs/design.md):

• API เธรดคือโต๊ะออเดอร์ REST เซิร์ฟเวอร์ที่ผูกกับ Unix socket (ซ็อกเก็ตเฉพาะที่ที่อยู่เป็นไฟล์บนดิสก์ ไม่ใช่พอร์ต TCP) รับการกำหนดค่าก่อนบูตและการกระทำจำกัดหลังจากนั้น
• VMM เธรดคือพื้นโรงงานฮาร์ดแวร์ มันแสร้งเป็นทุกอุปกรณ์ที่เกสต์เห็น เมื่อเกสต์แตะสิ่งที่คิดว่าเป็น NIC register CPU หยุดเกสต์ชั่วคราว VMM จัดการ ("เกสต์เตะคิว TX ระบายมัน") และดำเนินต่อ กลไก: เกสต์อ่าน/เขียนที่อยู่มหั CPU ดักจับเหล่านั้นไปยังโฮสต์[^mmio]
• vCPU เธรดคือนักวิ่ง หนึ่งต่อ CPU เกสต์ แต่ละตัวในลูปแน่น: ขอ KVM ให้รันเกสต์จนกว่าสิ่งที่น่าสนใจจะเกิดขึ้น (แตะอุปกรณ์, ขัดจังหวะ, หยุด), จัดการ, ลูป

พวกมันคุยกันผ่าน Rust channels (คิวข้อความในโพรเซส, lock-free ระหว่างเธรด) เกสต์เห็นสี่อุปกรณ์เท่านั้น

สี่อุปกรณ์

• virtio-net คือ NIC ของ VM ไม่มีการจำลองปี 1998 เกสต์เขียนแพ็กเก็ตลง virtqueue (ริงบัฟเฟอร์ในหน่วยความจำร่วม); VMM ระบายออกผ่าน TAP อุปกรณ์ฝั่งโฮสต์ (อินเทอร์เฟซอีเทอร์เน็ตเสมือนที่เนิร์เนลเปิดเผยเป็นไฟล์) ขับเคลื่อนด้วย io_uring หรือ epoll เพื่อให้ VMM เธรดไม่บล็อก
• virtio-block คือดิสก์ของ VM แค่ I/O ไฟล์บนโฮสต์ เกสต์ใส่คำขอเซกเตอร์คำขอลง virtqueue; VMM ออก pread/pwrite ธรรมดากับไฟล์โฮสต์ ไม่มี IDE, ไม่มี AHCI, ไม่มี SCSI
• virtio-vsock คืออินเตอร์คอมของ VM ไปยังโฮสต์ ระบุด้วย (context-id, port) tuple แทนคู่ IP/พอร์ต เพื่อให้เอเยนต์ในเกสต์สามารถติดต่อกลับบ้าน (ล็อก, ping สุขภาพ, สแนปชอตเมทาดาต้า) โดยไม่มี IP เกสต์และไม่มีอะไรบนสายให้ปลอม
• 8250 serial UART คือคอนโซลบูต ชิปอนุกรมรุ่นเล็กที่จำลองที่อยู่คงที่ ใช้สำหรับล็อกช่วงต้นก่อนที่ virtio จะขึ้น ถูก ใช้งานทั่วไป ไม่หายไป

การบูตไมโคร VM ตั้งแต่ต้นจนจบ

API คือระนาบควบคุมทั้งหมด: ช่องทางการกำหนดค่า แยกจากระนาบข้อมูล (vCPU เธรดที่รันเกสต์โค้ดจริง) คุณเริ่มไบนารีที่ชี้ไปที่ Unix socket:

จากนั้นคุณ PUT การกำหนดค่าเข้าไป:

สี่ HTTP calls นั่นคือระนาบควบคุมทั้งหมด

หอมหัวใหญ่ความปลอดภัย

ขอบเขต KVM เดียวก็แข็งแรงแล้ว Firecracker ห่ออีกสองชั้นรอบมัน

jailer คือผู้สร้างแซนด์บ็อกซ์ งานเดียวคือกัก VMM ก่อนที่มันจะทำงาน มันสร้าง chroot (ฟีเจอร์ Linux ที่ล็อกโพรเซสให้อยู่ในไดเรกทอรีเดียวราวกับว่าไดเรกทอรีนั้นคือรากของระบบไฟล์ โพรเซสไม่สามารถตั้งชื่ออะไรที่อยู่เหนือมัน), ลงใน PID namespace ใหม่เพื่อไม่ให้เห็นโพรเซสอื่นของโฮสต์, สลับไปยัง uid/gid ที่ไม่มีสิทธิพิเศษ, ใช้ cgroup จำกัด CPU/หน่วยความจำ และจากนั้น exec ไบนารี Firecracker ภายในคุกนั้น:

ตอนนี้โพรเซส VMM ไม่มีระบบไฟล์ยกเว้น chroot เฉพาะ ไม่มีมุมมองโพรเซสอื่นบนโฮสต์ และไม่มี root capabilities ถ้าการหลบหนีจากเกสต์ไปโฮสต์ผ่าน virtio หรือ KVM ผู้โจมตีจะลงจอดใน chroot นั้นด้วย cgroup จำกัด

Seccomp คือรายการอนุญาตซิสคอลต่อเธรด สิ่งที่ไม่อยู่ในรายการถูกฆ่าถูกฆ่า (หรือคืน EPERM) ก่อนถึงตัวจัดการซิสคอลแฮนเดอร์ของเนิร์นเนล Firecracker มีสามระดับสามระดับ:

1. ระดับ 0: ปิด อย่าใช้ในโปรดักชัน
2. ระดับ 1: รายการอนุญาตตามหมายเลขซิสคอล
3. ระดับ 2: จำกัดค่าอาร์กิวเมนต์ด้วย (เช่น ioctl ใช้ได้ แต่เฉพาะกับ KVM_RUN เป็นคำสั่ง) ค่าเริ่มต้นและแนะนำ

แต่ละเธรดได้พื้นผิวที่น้อยที่สุดเท่าที่เป็นไปได้: API เธรดไม่ต้องการ ioctl(KVM_RUN); vCPU เธรดไม่ต้องการ socket() มุมมองแบบง่ายของกฎหนึ่งข้อกำหนดหนึ่ง:

แต่ละชั้นต้องล้มเหลวอย่างอิสระเพื่อให้ผู้โจมตีถึงโฮสต์

สแนปชอต: โก้ดเบื้อง Lambda SnapStart

ถ่ายสแนปชอตของไมโคร VM ที่กำลังรัน กู้คืนในมิลลิวินาที บนโฮสต์อื่น เข้าโพร VMM ใหม่ ข้ามการบูตเนิร์นเนล ข้าม init ข้าม JIT อุ่นเครื่อง

คุณหยุด VM ที่กำลังรันและ dump หน่วยความจำ + สถานะอุปกรณ์ลงดิสก์:

สแนปชอตจับสถานะหลังอุ่นเครื่อง ดังนั้น VM ที่กู้คืนตื่นขึ้นกลางชีวิต ไม่ใช่ตอนเริ่มต้น

นี่คือสิ่งที่ AWS Lambda SnapStart ทำ: เริ่มต้น Java Lambda ครั้งเดียว ถ่ายสแนปชอตไมโคร VM และกู้คืนสแนปชอตนั้นในทุก cold start ต่อมา (ประกาศ) JVM cold starts จาก 8+ วินาทีกลายเป็นต่ำกว่าวินาที

พวกมันทำงานร่วมกันอย่างไร

gVisor คือการออกแบบที่แตกต่าง: เนิร์นเนลยูเซอร์สเปซใน Go, การใช้งานอินเทอร์เฟซซิสคอล Linux ใหม่ที่รันเป็นโพรเซสปกติ ซิสคอลของเกสต์ไปที่ gVisor แทนเนิร์นเนลโฮสต์ และ gVisor ตัดสินใจว่าจะส่งต่ออะไร (ถ้ามี) ปลายทาง เริ่มเร็ว่าไมโคร VM, โอเวอร์เฮดซิสคอล 10–30% บนเส้นทางร้อน และขอบเขตความเชื่อถือที่แตกต่าง

Firecracker อยู่ในกล่อง "เนิร์นเนลของตัวเอง แต่ไม่มี PCI BIOS": การแยกฮาร์ดแวร์, โมเดลอุปกรณ์เล็ก, และบูตในมิลลิวินาที

เลือกเครื่องมือของคุณ:

ใครใช้สิ่งนี้

มันเกือบเร็วกว่าที่จะรายการแพลตฟอร์มเซิร์ฟเลสที่ไม่ได้อยู่บนไมโคร VM

Firecracker ในโปรดักชัน:

• AWS Lambda และ AWS Fargate: กรณีการใช้งานดั้งเดิม ทุก Lambda invocation ลงใน Firecracker microVM; Fargate tasks คือ Firecracker VMs ที่มีรันไทม์คอนเทนเนอร์บางอยู่ข้างใน
• Fly.io Machines: ทุก fly machine run คือ Firecracker microVM, กระจายทั่วโลก, ด้วย cold starts ต่ำกว่าวินาทีและดิสก์ถาวร
• เกือบทุกแซนด์บ็อกซ์การเรียกใช้โค้ AI agent ที่คุณใช้ในสิบแปดเดือนที่ผ่านมาที่ผ่านมาอยู่ใน Firecracker microVM

รูปร่างของ API แซนด์บ็อกซ์โดยประมาณเหมือนกันข้ามผู้ขายในตอนนี้:

ในโค้ดประมาณสี่บรรทัด: Firecracker microVM บูต, เนิร์นเนลเริ่มต้น, โพรเซสเอเยนต์ในเกสต์รับคำสั่งของคุณผ่าน vsock, รันมัน, สตรีมผลลัพธ์กลับ, และ VM ตาย

ยุค Agent: ทำไมทั้งหมดนี้สำคัญตอนนี้

เมื่อปีที่แล้ว

ปีที่แล้ว "แซนด์บ็อกซ์ AI คืออะไร?" เป็นคำถามเฉพาะ หาก LLM สร้างโค้ด มันอาจไม่ปลอดภัย 100% ที่จะรันบนเครื่องใด ๆ ดังนั้นคุณจะรันในแซนด์บ็อกซ์ชั่วคราว

วันนี้ทุกผลิตภัณฑ์ AI จริงจังมี agent แซนด์บ็อกซ์ของพวกเขาก็ดีขึ้น แต่รูปร่างของ agent เปลี่ยนไป และคำตอบรันไทม์เก่าไม่เข้ากับรูปร่างใหม่

In-process agents vs host-level agents

รอบแรกของ AI agents อยู่ในแอปพลิเคชันของคุณ คุณนำเข้าไลบราเชื่อมต่อลูป และรันในแบ็กเอนด์ที่มีอยู่:

ทุก call คือ HTTP round-trip ไปยังโมเดล ทุก tool call คือฟังก์ชันในโพรเซสของคุณเอง "แซนด์บ็อกซ์" คือเซิร์ฟเวอร์ของคุณเอง นี่คือโลกของ Vercel AI SDK, LangChain, OpenAI Agents SDK มันทำงานได้ดีและยังคงที่และยังคงส่งส่วนใหญ่ของ production agents ในวันนี้

รอบสองแตกต่าง Claude Code, Codex, และ OpenCode คือ host-level agents: ไบนารีที่เข้าควบคุมเครื่อง ไม่ใช่ไลบรารีที่อยู่ในของคุณ พวกเขาคาดหวังเชลล์จริง, package manager, และดิสก์ที่เขียนได้ เมื่อคุณให้ Claude Code งาน มันรันสิ่งนี้:

นั่นคือ shell/bash มันต้องการระบบไฟล์จริง, fork/exec จริง, package manager, ดิสก์ที่คุณเขียนได้, เครือข่ายที่คุณเข้าถึงได้ ไม่มีสิ่งใดแสดงเป็น tool schema chat-completion และไม่มีสิ่งใดปลอดภัยที่จะรันในคอนเทนเนอร์เนิร์นเนลร่วมกับเทนนต์อื่น

แล็บกำลัง post-training โมเดลของพวกเขาบน harnesses เหล่านี้ (โครงสร้างรอบโมเดล): เชลล์, ตัวแก้ไขไฟล์, ตัวรันเทสต์, ลูป agent เอง นั่นหมายถึงช่องว่างระหว่าง "โมเดล + harness ที่มันถูกฝึก" และ "โมเดล + DIY scaffolding" กำลังใหญ่ขึ้นทุกไตรมาส

เครื่อง Linux ทั้งเครื่องต่อ agent รันโค้ดที่ไม่น่าเชื่อถือที่ agent เพิ่งสร้างขึ้น คืองานที่ Firecracker ถูกสร้างมา การบรรจบกันข้างต้นไม่ใช่เรื่องบังเอิญ

เราเริ่มเห็นการทดลองมากขึ้นกับ agents ที่แยก compute & harness Anthropic's Managed Agents เป็นตัวอย่าง ที่ harness agent ถูกเรียกใช้ข้างแซนด์บ็อกซ์ไม่ใช่ข้างใน

บางบริษัทถึงกับสร้างระบบไฟล์โฮสเต็ม (เช่น Archil และ Mesa), เพื่อให้ agents ค้นหาและจัดเก็บได้ดีขึ้น

เมื่อ agents ดีขึ้นและเปลี่ยนไปตามกาลเวลา จะมีข้อเสนอ infra ที่น่าสนใจอีกมากมายที่สร้างบน Firecracker

สิ่งที่คุณจ่ายจริงสำหรับแพลตฟอร์ม agent infra

แซนด์บ็อกซ์ "รันโค้ดใด ๆ" ทั่วไปกลายเป็นสินค้าโภคภัณฑ์แล้ว โครงสร้างพื้นฐานเป็นโอเพนซอร์สเต็มรูปแบบ เลเยอร์ microVM คือ Firecracker หรือ Cloud Hypervisor ภายใต้ Apache 2.0 การแปลงคอนเทนเนอร์เป็น rootfs คือสคริปต์ Go 200 บรรทัด วิศวกรที่มีความสามารถสามารถตั้งค่าแพลตฟอร์มแซนด์บ็อกซ์ที่ทำงานได้ในสุดสัปดาห์

คุณจ่ายสำหรับสิ่งที่เชื่อมต่อกับ VM microVM เปลือยคือค่าเริ่มต้น

พื้นผิวผลิตภัณฑ์ที่น่าสนใจ:

• Observability คือผลิตภัณฑ์ ไม่ใช่เครื่องช่วยดีบัก ทุกสิ่งที่ agent ทำ (stdout, syscalls, การเขียนไฟล์, คำขอเครือข่าย) ไหลผ่านซ็อกเก็ตเดียวไปยังตัวรวบรวมฝั่งโฮสต์ ผู้สร้าง agent ต้องการ session replay เต็มรูปแบบ และ artifacts ต่อการกระทำเพื่อสร้างผลิตภัณฑ์ที่ดีที่สุด
• ความลับถูก broker ที่สาย ไม่เคยส่งให้เกสต์ เกสต์เห็นเฉพาะ env vars ตัวแทน; echo $SECRET ในแซนด์บ็อกซ์คืนตัวแทน โฮสต์-side egress proxy (ทุกแพ็กเก็ตขาออกต้องข้ามมัน) แทนที่ credential จริงที่ TAP ฝั่งโฮสต์ (ปลายทางของ VM's virtual NIC ที่เป็นของเนิร์นเนล ซึ่งเกสต์ไม่เห็นหรือระบุ) ต่อรายการอนุญาตที่ชัดเจน พร้อมร่องรอยการตรวจสอบต่อ session agent สามารถรันโค้ดที่มันสร้างเมื่อห้าวินาทีก่อนและยังไม่สามารถขโมย credential ที่มันไม่เคยมี
• Identity ถูกเซ็นที่โฮสต์ ไม่ใช่ภายใน agent คำขอขาออกสามารถพก cryptographic per-session identity (รวมถึง Web Bot Auth signatures ที่สร้างบน HTTP Message Signatures + Ed25519) ที่สร้างโดยโฮสก่อนที่แพ็กเก็ตออกจากบริดจ์ คีย์เซ็นไม่เข้า microVM
• คอมพิวต์อื่นถูกรวมใน microVM เดียวกับรันไทม์ Browserbase จับคู่ agent runtime 1:1 กับเบราว์เซอร์บนโฮสต์เดียวกัน มักเป็น microVM เดียวกัน microVM เดียว ระยะทางกายภาพระหว่างโพรเซส agent และ Chromium เป็นศูนย์: CDP commands (Chrome DevTools Protocol, รูปแบบ JSON-over-WebSocket ที่ใช้ขับ Chrome โดยโปรแกรม) ไปผ่าน Unix socket ไม่ใช่ข้ามเครือข่ายของบริการ ดังนั้น action latency เป็นมิลลิวินาทีหลักเดียว เฟรม screencast ไม่ต้องข้ามอินเทอร์เน็ตสาธารณะเพื่อลง session replay

และคุณไม่สามารถเย็บทั้งหมดนี้อย่างสะอาดบน Docker ตะเข็บไม่มี การเดิมพันของเราคือตลาด agent runtime จะไม่ชนะด้วย raw compute แต่ด้วย observability, secrets, identity, partnerships, และ compute ที่อยู่ร่วมกันที่ยุบเป็นพื้นผิวผลิตภัณฑ์เดียว

ทางเลือก runtime ที่น่าจับตา

• Bubblewrap: user-namespace sandboxing ที่ไม่มีสิทธิพิเศษ ผู้ใช้ที่ไม่ใช่ root สามารถสร้างแซนด์บ็อกซ์โดยไม่ต้อง sudo โดยใช้เนิร์นเนล primitives เดียวกับที่ Flatpak ใช้กักแอปเดสก์ท็อป เบากว่า VM ยังคงใช้เนิร์นเนลโฮสต์ ดังนั้นไม่ใช่ตัวแทน microVM สำหรับโค้ดที่ไม่น่าเชื่อถือจริง แต่เป็นเลเยอร์แยกซ้อนที่ดีภายใน microVM หรือตัวเลือกที่ดีสำหรับโค้ดที่เชื่อถือได้บนโฮสต์ของคุณเอง
• V8 isolates: โมเดล Cloudflare Workers แต่ละ isolate คือบริบทการทำงาน JS แยกต่างหากที่มีฮีปของตัวเอง ทุกตัวใช้ V8 โพรเซสเดียวกับผู้เช่าเป็นพัน ๆ Startup ~5ms เร็วกว่า microVM สองอันดับ ขอบเขตความเชื่อถือคือแซนด์บ็อกซ์ของ V8 เอง ในอดีตมันยืนได้ดี แต่เป็นเส้นที่บางกว่าไฮเปอร์ไวเซอร์มาก ข้อเสียอื่น: คุณได้เฉพาะ Node-flavored semantics ไม่มี fork, exec, โมดูลเนทีฟ, ระบบไฟล์จำลอง ร้ายแรงสำหรับโค้ด agent JS บริสุทธิ์ ไร้ประโยชน์ถ้าคุณต้อง pip install numpy
• gVisor: เนิร์นเนลยูเซอร์สเปซของ Google ใน Go การแยกที่แข็งแรงโดยไม่ต้อง nested virt (VM เกสต์ที่รันใน VM อื่น ซึ่งผู้ให้บริการคลาวด์ส่วนใหญ่ปิดโดยค่าเริ่มต้น; gVisor ไม่ต้องการ ดังนั้นมันทำงานใน GKE ทันที) จ่าย ~10–30% บนเวิร์กโหลดที่ใช้ syscall มาก จุดกึ่งกลางที่มั่นคงเมื่อ hardware virt ไม่พร้อมใช้งาน
• WASM sandboxes (wasmtime, wasmer): deterministic, เล็ก, เร็ว แต่ระบบนิเวศตื้น WASI (API ซิสคอลมาตรฐานสำหรับ WASM) กำลังเติบโต ยังไม่ใช่เป้าหมาย drop-in สำหรับ "รันไบนารี Python/Node ตามอำเภอใจนี้" ในตอนนี้

ถ้าคุณสร้างสำหรับโค้ดวัตถุประสงค์ทั่วไปที่ไม่น่าเชื่อถือ: Firecracker (หรือ Cloud Hypervisor, VMM/virtio design ที่คล้ายกัน) ถ้าคุณสร้างสำหรับเวิร์กโหลด JS ที่รู้จัก: V8 isolates ทุกอย่างอื่นคือคำตอบเฉพาะสำหรับคำถามเฉพาะ

ภาพใหญ่

Firecracker นำหนึ่งในแนวคิดที่เก่าที่สุดในคอมพิวเตอร์ เครื่องเสมือน และลบพอที่จะทำให้มันถูก มันเดิมพันว่าการแยกด้วยฮาร์ดแวร์คุ้มค่าถ้าคุณทำให้มันเร็วพอ

การเดิมพันนั้นจะจ่ายสำหรับเซิร์ฟเลสเสมอ สิ่งที่เปลี่ยนไปคือเวิร์กโหลด "โค้ดหลายเทนนต์ที่ไม่น่าเชื่อถือ" เติบโตจาก "ฟังก์ชันเว็บที่ฉันไม่ต้องการแซนด์บ็อกซ์" เป็น "agent ที่สร้างคำสั่งตามอำเภอใจที่อาจแตะ prod" เส้นรอบวงย้ายและความทนทานต่อการหลบหนีเนิร์นเนลร่วมกันจาก "ความเสี่ยงที่ยอมรับได้" เป็น "ไม่สามารถปล่อย"

และมันก็เป็น มันเป็นไบนารี Rust ยาว 50,000 บรรทัดที่คุยกับ /dev/kvm

คอนเทนเนอร์แพคเกจซอฟต์แวร์ ไมโคร VM แยกมัน วิศวกรรมที่น่าสนใจของทศวรรษหน้าคือทุกสิ่งที่คุณห่อรอบกล่อง

→ Kyle

โพสต์บล็อกนี้มีส่วนประกอบแบบอินเทอร์แอคทีฟและแอนิเมชัน (ที่ไม่แสดงในบทความ X ถ้าคุณต้องการเห็นเวอร์ชันนั้น อยู่ที่นี่: https://www.browserbase.com/blog/what-is-firecracker.