كل المقالات

AWS Lambda MicroVMs: عزل افتراضي بتشغيل فوري لتطبيقات الذكاء الاصطناعي ومتعددة المستأجرين

عمر حسن4 يوليو 2026 في 7:52 ص6 دقيقة للقراءة
AWS Lambda MicroVMs: عزل افتراضي بتشغيل فوري لتطبيقات الذكاء الاصطناعي ومتعددة المستأجرين

أبرز النقاط

  • Lambda MicroVMs توفر عزل الآلات الافتراضية مع سرعة تشغيل شبه فورية باستخدام تقنية Firecracker
  • مصممة لتشغيل أكواد غير موثوقة من المستخدمين أو الذكاء الاصطناعي بأمان تام
  • تحافظ على حالة الذاكرة والقرص طوال الجلسة مع إمكانية الإيقاف المؤقت والاستئناف التلقائي

أعلنت Amazon Web Services عن إطلاق AWS Lambda MicroVMs، وهي بنية حوسبة جديدة ضمن منظومة Lambda تتيح تشغيل الأكواد المُولَّدة من المستخدمين أو أنظمة الذكاء الاصطناعي داخل بيئات تنفيذ معزولة تماماً وقابلة للحفاظ على حالتها. الجديد هنا أنك تحصل على مستوى عزل الآلات الافتراضية الكاملة، مع سرعة تشغيل واستئناف شبه فورية، وتحكم مباشر في دورة حياة البيئة — كل ذلك دون الحاجة لإدارة بنية تحتية أو اكتساب خبرة معقدة في تقنيات الافتراضية.

Advertisement

لماذا تحتاج التطبيقات الحديثة إلى هذا المستوى من العزل؟

خلال السنوات الأخيرة، ظهرت فئة جديدة من التطبيقات متعددة المستأجرين (multi-tenant) تشترك في حاجة جوهرية واحدة: منح كل مستخدم نهائي بيئة تنفيذ خاصة به لتشغيل أكواد لم يكتبها مطور التطبيق الأصلي. مساعدو البرمجة بالذكاء الاصطناعي، بيئات الأكواد التفاعلية، منصات تحليل البيانات، ماسحات الثغرات الأمنية، وخوادم الألعاب التي تشغّل سكربتات المستخدمين — كلها تقع ضمن هذا النمط.

المشكلة أن الخيارات المتاحة حتى الآن كانت تفرض مقايضات صعبة:

  • الآلات الافتراضية التقليدية توفر عزلاً قوياً لكنها تستغرق دقائق للتشغيل
  • الحاويات (Containers) تنطلق في ثوانٍ، لكن معماريتها القائمة على مشاركة النواة تتطلب تقوية أمنية مخصصة لاحتواء الأكواد غير الموثوقة بأمان
  • خدمات Functions-as-a-Service مُحسَّنة لأنماط الطلب-الاستجابة، لكنها غير مصممة للجلسات التفاعلية طويلة الأمد التي تحتاج للاحتفاظ بحالة البيئة عبر تفاعلات متعددة

النتيجة: إما القبول بالمقايضة بين الأداء والأمان، أو استثمار موارد هندسية ضخمة لبناء وتشغيل بنية تحتية افتراضية مخصصة — جهد يتطلب خبرة عميقة ويسحب وقت الفريق بعيداً عن المنتج الفعلي.

كيف تحل Lambda MicroVMs هذه المعضلة؟

Lambda MicroVMs مبنية تحديداً لسد هذه الفجوة. كل MicroVM تمنح مستخدماً واحداً أو جلسة واحدة بيئة معزولة تماماً تنطلق بسرعة، تحتفظ بحالة الذاكرة والقرص طوال مدة الجلسة، وتتوقف مؤقتاً بتكلفة خمول منخفضة حين يبتعد المستخدم.

أكثر من 15 تريليون
عدد استدعاءات Lambda الشهرية التي تعمل بتقنية Firecracker — نفس التقنية التي تُشغّل MicroVMs الجديدة

الميزة الجوهرية أن Firecracker — تقنية الافتراضية خفيفة الوزن التي طورتها AWS وأتاحتها كمصدر مفتوح في 2018 — هي نفسها التي تُشغّل Lambda Functions منذ سنوات. هذا يعني أنك ترث النضج التشغيلي لخدمة تعمل بهذه البنية على نطاق واسع.

رسم توضيحي لمعمارية Firecracker وكيفية عزل MicroVMs
رسم توضيحي لمعمارية Firecracker وكيفية عزل MicroVMs

تجربة عملية: من الصفر إلى بيئة تنفيذ جاهزة

للبدء، تظهر Lambda MicroVMs الآن في قائمة التنقل الجانبية بواجهة AWS Lambda Console. الخطوة الأولى هي إنشاء MicroVM Image. في المثال التالي، تم تجهيز تطبيق Flask بسيط مع ملف Dockerfile، ثم ضغطهما في ملف zip ورفعه إلى Amazon S3.

تطبيق Flask الأساسي يعرض نقطة نهاية بسيطة تُرجع رسالة JSON. ملف Dockerfile يبدأ من صورة AWS الرسمية للـ MicroVMs (public.ecr.aws/lambda/microvms:al2023-minimal)، يُثبّت Python وGunicorn، ثم يُشغّل التطبيق على المنفذ 5000.

أمر إنشاء الصورة عبر CLI:

aws lambda-microvms create-microvm-image --code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name> --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 --build-role-arn <IAM role ARN>

عند تنفيذ الأمر، تسترجع Lambda الملف المضغوط، تُنفذ Dockerfile، تُهيّئ التطبيق، ثم تأخذ snapshot من Firecracker لحالة القرص والذاكرة أثناء التشغيل. سجلات البناء تُبث مباشرة إلى Amazon CloudWatch، وحين تجهز الصورة تظهر في الواجهة مع ARN ورقم الإصدار.

واجهة AWS Console تعرض عملية إنشاء MicroVM Image وسجلات البناء
واجهة AWS Console تعرض عملية إنشاء MicroVM Image وسجلات البناء
Advertisement

التشغيل والإيقاف المؤقت والاستئناف التلقائي

لتشغيل MicroVM، يُمرَّر ARN الصورة مع سياسة الخمول (idle policy). في المثال:

aws lambda-microvms run-microvm --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

هنا السياسة تُوقف الـ MicroVM مؤقتاً بعد 15 دقيقة من عدم النشاط، وتستأنفها تلقائياً عند أول طلب وارد. لا حاجة لإعداد شبكي — Lambda تُعيّن معرّفاً فريداً وعنوان URL مخصصاً للـ MicroVM، ويبدأ تطبيق Flask بالعمل فوراً لأنه يُستأنف من snapshot.

النتيجة: استدعاء API واحد للحصول على بيئة حوسبة مُهيأة بالكامل وجاهزة للعمل.

مخطط يوضح دورة حياة MicroVM من التشغيل إلى الإيقاف المؤقت والاستئناف
مخطط يوضح دورة حياة MicroVM من التشغيل إلى الإيقاف المؤقت والاستئناف

ما السيناريوهات التي تستفيد فعلياً من هذه الخدمة؟

  • مساعدو البرمجة بالذكاء الاصطناعي الذين يحتاجون لتنفيذ أكواد المستخدم في بيئة آمنة (مثل GitHub Copilot Workspace أو Replit Agent)
  • منصات التعليم التفاعلي التي تُشغّل أكواد الطلاب
  • أدوات فحص الثغرات الأمنية التي تُحلل أكواداً غير موثوقة
  • خوادم الألعاب التي تسمح بسكربتات مخصصة من اللاعبين
  • منصات تحليل البيانات التي تُنفذ استعلامات أو نماذج من المستخدمين

كيف تقارن MicroVMs بالبدائل المتاحة؟

في سوق تشغيل الأكواد المعزولة، تتنافس عدة حلول:

  • Fly.io Machines: تقدم microVMs مع إيقاف واستئناف، لكنها تتطلب إدارة شبكية أكبر
  • Modal: تركز على أحمال عمل ML/AI مع cold starts سريعة، لكنها ليست معزولة على مستوى VM
  • Deno Deploy وCloudflare Workers: عزل على مستوى V8 isolates — أسرع لكن أقل عزلاً
  • Google Cloud Run: يدعم الحاويات لكن بدون snapshot/resume للحالة

ميزة AWS هنا تكاملها مع منظومة Lambda الموجودة والنضج التشغيلي لـ Firecracker. لكن التسعير لم يُعلن بالتفصيل بعد — نقطة يجب مراقبتها.

ℹ️

رأي Logicity

Lambda MicroVMs ليست تطوراً تدريجياً بل إعادة تعريف لما يمكن أن تقدمه الحوسبة السحابية بدون خادم. AWS تستهدف تحديداً موجة تطبيقات AI agents التي تحتاج لتنفيذ أكواد ديناميكية بأمان — سوق يتوقع أن ينمو بشكل هائل مع انتشار المساعدين الذكيين. المنافسة مع Fly.io وModal ستشتد، لكن ورقة AWS الرابحة هي التكامل السلس مع بقية خدماتها: IAM، CloudWatch، S3، وVPC. الفرق الهندسية التي تبني منتجات AI تفاعلية يجب أن تضع هذه الخدمة على قائمة التقييم الفوري.

الأسئلة الشائعة

ما الفرق بين Lambda MicroVMs وLambda Functions العادية؟

Lambda Functions مصممة لأنماط الطلب-الاستجابة قصيرة الأمد (حتى 15 دقيقة)، بينما MicroVMs تدعم جلسات طويلة تحافظ على حالة الذاكرة والقرص مع إمكانية الإيقاف المؤقت والاستئناف. MicroVMs أيضاً توفر عزلاً أقوى لتشغيل أكواد غير موثوقة.

هل يمكن استخدام Lambda MicroVMs لتشغيل أكواد ChatGPT أو Claude؟

نعم، هذا أحد السيناريوهات الأساسية. إذا كنت تبني تطبيقاً يستخدم نماذج AI لتوليد أكواد ثم تنفيذها، فـ MicroVMs توفر البيئة المعزولة اللازمة لتشغيل هذه الأكواد بأمان دون المخاطرة بالنظام الأساسي.

ما مناطق AWS التي تدعم Lambda MicroVMs حالياً؟

حسب الإعلان الأولي، الخدمة متاحة في us-east-1. التوسع لمناطق أخرى متوقع لاحقاً، لكن AWS لم تعلن جدولاً زمنياً محدداً بعد.

كم تكلفة تشغيل Lambda MicroVMs؟

لم تُعلن AWS تفاصيل التسعير الكاملة بعد. المتوقع أن يكون النموذج مبنياً على وقت التشغيل الفعلي مع تكلفة مخفضة لحالة الإيقاف المؤقت (suspended)، لكن يُنصح بمراجعة صفحة التسعير الرسمية عند التوفر.

هل تحتاج خبرة في Firecracker لاستخدام MicroVMs؟

لا. AWS تُجرّد كل تعقيدات Firecracker وتقدم واجهة CLI وConsole بسيطة. تحتاج فقط لمعرفة Docker لبناء الصورة، والباقي تتولاه الخدمة.

ℹ️

هل تحتاج مساعدة في التطبيق؟

إذا كنت تخطط لدمج Lambda MicroVMs في منتجك أو تريد تقييم مدى ملاءمتها لحالة استخدامك، تواصل مع فريق Logicity للحصول على استشارة تقنية متخصصة.

Advertisement
ع

عمر حسن

كاتب تقني وابتكار

أُنتِج هذا المقال بمساعدة الذكاء الاصطناعي وراجعه فريق التحرير في لوجيسيتي. اعرف المزيد في سياسة التحرير.

مقالات ذات صلة

اقرأ أيضاً