Wasmer ได้เปิดตัวการรองรับ Python แบบเต็มรูปแบบสำหรับ WebAssembly บนแพลตฟอร์ม Edge ของพวกเขา โดยสัญญาว่าจะให้ประสิทธิภาพใกล้เคียงระบบดั้งเดิมพร้อมกับรักษาความสามารถในการแยกส่วน (sandboxing) แบบสมบูรณ์ การพัฒนานี้ตอบสนองความต้องการที่เพิ่มขึ้นสำหรับสภาพแวดล้อมการรัน Python ที่ปลอดภัย โดยเฉพาะสำหรับงาน AI และสถานการณ์โค้ดที่ไม่น่าเชื่อถือ
การประกาศนี้ได้จุดประกายความสนใจอย่างมากในชุมชนนักพัฒนา โดยหลายคนมองว่านี่เป็นโซลูชันที่มีศักยภาพสำหรับการรันโค้ด Python อย่างปลอดภัยในสภาพแวดล้อมการผลิต ต่างจากโซลูชันที่เน้นเบราว์เซอร์อย่าง Pyodide แนวทางของ Wasmer มุ่งเป้าไปที่แอปพลิเคชันฝั่งเซิร์ฟเวอร์พร้อมความเข้ากันได้กับเฟรมเวิร์กแบบเต็มรูปแบบ
 |
|---|
| การสนับสนุน Python ใหม่ของ Wasmer สัญญาว่าจะมอบประสิทธิภาพและความเข้ากันได้ที่ดีขึ้นสำหรับแอปพลิเคชัน WebAssembly |
การอ้างประสิทธิภาพแสดงผลลัพธ์ที่น่าประทับใจ
Wasmer อ้างว่าการใช้งาน Python ของพวกเขารันด้วยความเร็วที่แทบจะแยกแยะไม่ออกจากประสิทธิภาพ Python ดั้งเดิม โดยเบนช์มาร์กแสดงให้เห็นการรันที่เร็วกว่า 4 เท่าเมื่อเทียบกับการใช้งาน Python บน WebAssembly แบบก่อนหน้า บริษัทกำลังทดสอบการปรับปรุงที่อาจผลักดันประสิทธิภาพไปถึง 95% ของความเร็ว Python ดั้งเดิม ซึ่งจะเป็นความสำเร็จที่สำคัญสำหรับสภาพแวดล้อมการรันแบบแยกส่วน
อย่างไรก็ตาม ผู้ใช้ในช่วงแรกได้พบปัญหาบางอย่างกับการใช้งานปัจจุบัน กระบวนการคอมไพล์เริ่มต้นอาจใช้เวลาถึง 10 นาทีในการรันครั้งแรก เนื่องจากระบบคอมไพล์ Python ด้วยการปรับปรุง LLVM Wasmer รับทราบข้อจำกัดนี้และวางแผนที่จะแจกจ่ายไบนารีที่คอมไพล์แล้วเพื่อขจัดความล่าช้าในการคอมไพล์
การเปรียบเทียบประสิทธิภาพ
| เมตริก | Wasmer Python | Previous WASM Python | Native Python |
|---|---|---|---|
| ประสิทธิภาพปัจจุบัน | เร็วกว่าเดิม 4 เท่า | มาตรฐานอ้างอิง | เป้าหมายการทดสอบ |
| การปรับปรุงที่วางแผนไว้ | 95% ของความเร็วแบบ native | ไม่มี | 100% |
| Cold Start | ~10 นาที (การรันครั้งแรก) | แตกต่างกัน | ทันที |
| การรันครั้งต่อไป | เร็ว (มี cache แล้ว) | แตกต่างกัน | ทันที |
การรองรับเฟรมเวิร์กแบบเต็มรูปแบบทำให้โดดเด่น
หนึ่งในแง่มุมที่น่าสนใจที่สุดของการใช้งานของ Wasmer คือการรองรับเฟรมเวิร์กอย่างครอบคลุม นักพัฒนาสามารถรันแอปพลิเคชัน FastAPI, Django, Flask และ Starlette โดยไม่ต้องปรับเปลี่ยนใดๆ แพลตฟอร์มยังรองรับ WebSockets, threading และไลบรารี Python ดั้งเดิมรวมถึง numpy, pandas และ Pillow
ความเข้ากันได้อย่างกว้างขวางนี้แก้ไขข้อจำกัดหลักที่พบในโซลูชันคู่แข่ง Cloudflare Workers กับ Pyodide ตัวอย่างเช่น ขาดการรองรับ WebSocket ความสามารถ threading และการรัน subprocess AWS Lambda ต้องการอแดปเตอร์และไม่รองรับ WebSockets โดยธรรมชาติ
การรองรับ Framework และ Library
รองรับอย่างเต็มรูปแบบ:
- FastAPI (พร้อม WebSockets )
- Django
- Flask
- Starlette
- numpy
- pandas
- Pillow
- LangChain
- pyppeteer
เร็วๆ นี้:
- certifi
- psycopg2
- gunicorn / gevent
- Pyarrow
- scipy
- การรองรับ SQLite
ความปลอดภัยและการแยกส่วนขับเคลื่อนความสนใจในการนำมาใช้
ผลกระทบด้านความปลอดภัยได้สร้างการอภิปรายอย่างมากในหมู่นักพัฒนา หลายคนกำลังสำรวจ WebAssembly เป็นทางเลือกแทน Docker containers สำหรับการรันโค้ดที่ไม่น่าเชื่อถือ โดยเฉพาะในสถานการณ์ที่เกี่ยวข้องกับสคริปต์ที่สร้างโดย AI หรือโค้ดที่ผู้ใช้ส่งมา
ฉันต้องการสามารถรันโค้ดจากแหล่งที่ไม่น่าเชื่อถือ (คนอื่น ผู้ใช้แอปพลิเคชัน SaaS ของฉัน LLMs) ในสภาพแวดล้อมที่ฉันสามารถควบคุมรัศมีการระเบิดได้หากมีสิ่งผิดปกติเกิดขึ้น
แม้ว่า Docker containers จะให้การแยกส่วน แต่นักพัฒนาบางคนแสดงความกังวลเกี่ยวกับช่องโหว่การหลบหนีคอนเทนเนอร์ โดยเฉพาะเมื่อต้องจัดการกับโค้ดที่สร้างโดย AI ที่อาจเป็นอันตราย การออกแบบ WebAssembly เป็นสภาพแวดล้อมการรันแบบแยกส่วนเสนอชั้นความปลอดภัยเพิ่มเติมที่ดึงดูดนักพัฒนาที่ทำงานกับสถานการณ์โค้ดที่ไม่น่าเชื่อถือ
การใช้งานทางเทคนิคและข้อจำกัดปัจจุบัน
แนวทางของ Wasmer เกี่ยวข้องกับการคอมไพล์ตัวแปล Python เป็น WebAssembly แทนที่จะแปลงโค้ด Python โดยตรง พวกเขาได้ใช้งานการรองรับ dynamic linking สำหรับไฟล์ .so/.dylib/.wasm และสร้าง Python Package Index ของตนเองด้วยไลบรารีดั้งเดิมยอดนิยมที่คอมไพล์สำหรับ WASIX (ส่วนขยาย WebAssembly System Interface ของพวกเขา)
ข้อจำกัดปัจจุบันรวมถึงเวลาคอมไพล์เริ่มต้นที่ยาวนานและแพ็กเกจที่ขาดหายไปบางส่วน ไลบรารียอดนิยมอย่าง scipy, certifi และ psycopg2 ยังอยู่ในระหว่างการพัฒนา แม้ว่า numpy และแพ็กเกจสำคัญอื่นๆ จำนวนมากจะพร้อมใช้งานแล้วผ่าน package index ที่กำหนดเองของพวกเขา
แพลตฟอร์มรองรับทั้งการรันไทม์ผ่าน Wasmer CLI และการปรับใช้ไปยัง Wasmer Edge สำหรับแอปพลิเคชันแบบเซิร์ฟเวอร์เลส การทดสอบเริ่มต้นแสดงให้เห็นว่าระบบสามารถจัดการแอปพลิเคชันที่ซับซ้อนรวมถึงการประมวลผลภาพด้วย Pillow และแม้กระทั่งการควบคุมเบราว์เซอร์อัตโนมัติด้วย pyppeteer
การเปรียบเทียบแพลตฟอร์ม
| คุณสมบัติ | Wasmer Edge | Cloudflare Workers | AWS Lambda |
|---|---|---|---|
| WebSockets | ✅ | ❌ | จำกัด (ผ่าน API Gateway ) |
| Threading | ✅ | ❌ | ❌ |
| Subprocesses | ✅ | ❌ | ❌ |
| Native Libraries | ✅ | จำกัด | จำกัด |
| ความซับซ้อนในการตั้งค่า | ต่ำ | ปานกลาง | สูง (ต้องใช้ adapters ) |
| การรองรับ Framework | รองรับได้อย่างสมบูรณ์ | จำกัด | ต้องปรับแต่ง |
มองไปข้างหน้า
การใช้งาน Python ของ Wasmer แสดงถึงก้าวสำคัญไปสู่การนำ WebAssembly มาใช้จริงสำหรับแอปพลิเคชันฝั่งเซิร์ฟเวอร์ แม้ว่าความล่าช้าในการคอมไพล์เริ่มต้นและความพร้อมใช้งานของแพ็กเกจยังคงเป็นความท้าทาย แต่การผสมผสานของประสิทธิภาพใกล้เคียงระบบดั้งเดิม การรองรับเฟรมเวิร์กอย่างครอบคลุม และความสามารถในการแยกส่วนที่แข็งแกร่ง ทำให้นี่เป็นตัวเลือกที่น่าสนใจสำหรับนักพัฒนาที่แสวงหาสภาพแวดล้อมการรัน Python ที่ปลอดภัย
ความสำเร็จของการใช้งานนี้อาจมีอิทธิพลต่อการนำ WebAssembly มาใช้อย่างกว้างขวางสำหรับงานฝั่งเซิร์ฟเวอร์ โดยเฉพาะในสถานการณ์ที่ความปลอดภัยและการแยกส่วนเป็นข้อกังวลสำคัญ
อ้างอิง: Python on the Edge: Fast, sandboxed, and powered by WebAssembly