انتقال ارتش ایجنت‌های کدنویس به زیرساخت اختصاصی؛ فکتوری از ابزار قدرتمند OpenCompute رونمایی کرد

انتقال ناوگان ایجنت‌ها به زیرساخت اختصاصی مشتریان توسط فکتوری

شرکت Factory، نام آشنای پشت ایجنت کدنویسی Droid، از سیستم کنترلی جدیدی به نام OpenCompute رونمایی کرد. این ابزار به کاربران اجازه می‌دهد ناوگانی از سندباکس‌های ویژه ایجنت‌ها را روی سرور‌های اختصاصی خودشان راه‌اندازی و مدیریت کنند. سندباکس (Sandbox) در واقع یک ماشین یا کانتینر کاملاً ایزوله است که ایجنت هوش مصنوعی می‌تواند در آن کدها را کلون کند، پکیج‌ها و وابستگی‌ها را بنشاند، دستورات سیستمی را اجرا کرده و کارش را به پایان برساند. با OpenCompute، مدل سندباکس‌های مدیریت‌شده فکتوری مستقیماً به زیرساخت انتخابی خود مشتری‌ها می‌آید؛ یعنی همه پردازش‌ها درست بیخ گوش کدها، پسوردها و سرویس‌های داخلی شرکت‌ها انجام می‌شود و چیزی به بیرون درز نمی‌کند.

در حال حاضر OpenCompute در قالب پیش‌نمایش خصوصی (Private Preview) در دسترس مشتریان فکتوری قرار گرفته است. علاوه بر این، فکتوری قصد دارد این پروژه را متن‌باز (Open Source) کند و قراردادهای درایور و تست‌های اعتبارسنجی آن را هم به اشتراک بگذارد؛ هرچند در این معرفی اولیه، هنوز تاریخ انتشار دقیق یا نوع لایسنس نرم‌افزاری آن مشخص نشده است.

چرا قابلیت قدیمی ریموت کنترل پاسخگوی ظرفیت منعطف و شناور نبود؟

راهکار قبلی شرکت فکتوری برای استقرار ایجنت‌ها که Remote Control نام داشت، به ایجنت Droid اجازه می‌داد روی یک سیستم کاری رجیسترشده، ماشین مجازی یا سرور محلی شرکت اجرا شود و از طریق یک ارتباط خروجی به فکتوری متصل بماند. این مدل برای یک ماشین ثابت و اختصاصی که به یک کاربر یا سرویس مشخص تعلق دارد بسیار مناسب بود؛ مثلاً برای سیستم‌های کاری توسعه‌دهندگان، VMهای برنامه‌نویسی یا سیستم‌هایی با سخت‌افزارهای خاص کاربرد داشت.

اما ماجرا برای کار‌های خودکار و پیش‌بینی‌نشده کاملاً فرق می‌کند؛ پردازش‌های خودکار به ظرفیتی شناور و منعطف نیاز دارند که دقیقاً همگام با نوسانات تقاضا ایجاد شود و بعد از اتمام کار غیبش بزند! مثلاً یک سیستم مانیتورینگ ممکن است با دیدن یک خطا، قبل از اینکه کسی بتواند دستی یک ماشین مجازی بسازد، ایجنت را برای بررسی حادثه اعزام کند؛ یا کار‌های زمان‌بندی‌شده و رگبار درخواست‌های کاربران در اسلک (Slack) به چندین محیط ایزوله و همزمان نیاز داشته باشند. اینجاست که OpenCompute وارد میدان می‌شود؛ این ابزار وظیفه ساخت، تعلیق موقت و حذف کامل سندباکس‌ها را روی سرور‌های خود شرکت‌ها بر عهده می‌گیرد و به محض اتمام مأموریت، تمام منابع مصرفی را آزاد می‌کند.

درایورها تفاوت میان پلتفرم‌ها را هضم می‌کنند

سیستم OpenCompute تمام زیرساخت‌های اجرای سندباکس را پشت یک رابط برنامه‌نویسی (API) مشترک برای چرخه حیات پنهان می‌کند. هر ارائه‌دهنده زیرساخت در قالب یک میکروسرویس مستقل gRPC با این سیستم یکپارچه می‌شود و از یک پروتکل ساختاریافته سرویس‌به‌سرویس بهره می‌برد تا دستورات OpenCompute را به عملیات بومی همان پلتفرم (برای ساخت، بررسی، کنترل و حذف محیط‌ها) ترجمه کند.

فکتوری اعلام کرده که در حال حاضر درایورهای آماده‌ای برای AWS Lambda MicroVMs، کوبرنتیز (Kubernetes)، ماشین‌های مجازی EC2، محیط‌های Kubernetes Agent Sandbox، پلتفرم Agent Substrate گوگل و حتی چند ارائه‌دهنده آزمایشی توسعه داده است. معماری ماژولار این درایورها طوری طراحی شده که تیم‌ها بتوانند بدون دستکاری و فورک کردن هسته اصلی سیستم کنترلی، محیط‌های اجرایی جدیدی به آن اضافه کنند.

پروفایل‌های قابلیتی (Capability Profiles) به محیط‌های مختلف با ویژگی‌های گوناگون اجازه می‌دهند بر اساس قراردادهایی کاملاً شفاف به این چرخه متصل شوند:

• هسته اصلی (Core): شامل تمام عملیات حیاتی چرخه حیات که هر درایور استاندارد موظف به پشتیبانی از آنهاست.
• پروفایل‌های اختیاری: امکاناتی نظیر تعلیق (Suspend)، عکس‌برداری لحظه‌ای (Snapshot) و انشعاب (Fork) برای پلتفرم‌هایی که از این قابلیت‌ها پشتیبانی می‌کنند.
• تست‌های اعتبارسنجی (Conformance tests): بررسی‌های مبتنی بر جعبه سیاه (Black-box) که عملکرد واقعی و قابل‌مشاهده درایور را می‌سنجند.
• رد زودهنگام درخواست‌ها (Early rejection): اگر عملیاتی توسط پلتفرم مقصد پشتیبانی نشود، درخواست قبل از شروع فرآیند تخصیص منابع رد می‌شود.

صفحه کنترلی این سیستم که با زبان گو (Go) نوشته شده، وضعیت مطلوب سیستم را به شکلی پایدار درون دیتابیس Postgres ذخیره می‌کند. سپس یک حلقه تطبیق (Reconciliation Loop) به طور مداوم وضعیت مطلوب را با وضعیت واقعی ارائه‌دهنده زیرساخت مقایسه کرده، فرآیند راه‌اندازی را کلید می‌زند، پیشرفت کار را زیر نظر می‌گیرد، خطاهای قابل‌جبران را دوباره امتحان می‌کند و مراحل تغییر وضعیت را پیش می‌برد. جالب اینکه حتی اگر در حین انجام عملیات، سرویس ری‌استارت شود، سابقه تسک‌ها کاملاً دست‌نخورده باقی می‌ماند.

اتصالات خروجی مرز اعتماد و امنیت را مشخص می‌کنند

سیستم OpenCompute کاملاً داخل محیط اختصاصی مشتری اجرا می‌شود و خودش یک اتصال وب‌سوکت رمزنگاری‌شده (TLS) به سمت فکتوری برقرار می‌کند. این یعنی در فرآیند استقرار، هیچ نیازی به باز کردن پورت ورودی در فایروال یا داشتن اندپوینت عمومی برای کنترل پلن وجود ندارد. هنگام فعال‌سازی، OpenCompute یک کلید عمومی را در فکتوری ثبت می‌کند؛ در حالی که کلید خصوصی کاملاً در اختیار مشتری باقی می‌ماند و می‌تواند درون سرویس مدیریت کلید ابری (KMS) امن نگهداری شود.

علاوه بر این، هر سندباکس نیز یک کانکشن خروجی برای انتقال ترافیک کنترلی ایجاد می‌کند. از آنجا که اجرای کدها درون شبکه داخلی خود مشتری اتفاق می‌افتد، ایجنت‌های Droid بدون نیاز به افشای عمومی سیستم‌ها، می‌توانند مستقیماً به ریپازیتوری‌های محلی، رجیستری‌های پکیج و سرویس‌های داخلی دسترسی داشته باشند. البته معماری فعلی نیازمند اتصال فعال به فکتوری است؛ بنابراین نباید آن را یک سیستم کاملاً آفلاین یا قطع از اینترنت (Air-gapped) در نظر گرفت.

البته باید توجه داشت که بومی‌سازی کامل داده‌ها تنها به محل سرور‌های پردازشی وابسته نیست. اجرای مدل‌های هوش مصنوعی (Inference)، ذخیره‌سازی نشست‌ها و همگام‌سازی، کانفیگ‌های جداگانه‌ای دارند. برای نگه داشتن تمام این جریان‌های داده در داخل شبکه، تیم‌ها باید تنظیمات نشست‌ها را شخصی‌سازی کرده و از کلیدهای اختصاصی (BYOK) یا مدل‌های هاست‌شده روی سرور‌های خودشان استفاده کنند.

این مدل مناسب چه بارهای کاری و سناریوهایی است؟

فکتوری ابزار OpenCompute را دقیقاً برای سازمان‌هایی ساخته که به ظرفیت منعطف و شناور ایجنت‌های کدنویس نیاز دارند، اما حاضر نیستند کنترل زیرساخت‌های اجرایی خود را از دست بدهند. سناریوهای اصلی کاربرد این سیستم عبارتند از:

1. نشست‌های تعاملی Droid که برای هر تسک برنامه‌نویسی، یک محیط سندباکس کاملاً تازه و تمیز دریافت می‌کنند.
2. سیستم‌های اتوماسیون زمان‌بندی‌شده که به محض ورود کار‌های جدید، به شکل مستقل اجرا می‌شوند.
3. بررسی و رفع حوادث فنی که با هشدارهای سیستم‌های مانیتورینگ تحریک می‌شوند.
4. رگبار درخواست‌های تفویض‌شده به ایجنت‌ها توسط اعضای تیم در پیام‌رسان اسلک.

فکتوری مدعی شده که تیم فنی‌اش تنها در عرض شش هفته، این پروژه را از یک پروتوتایپ اولیه به نخستین استقرار عملیاتی نزد یک مشتری رسانده است؛ آن هم با پشتیبانی از یک زیرساخت سازمانی کاملاً سفارشی! حتی به گفته این شرکت، نخستین درایور اختصاصی این پروژه توسط خود ایجنت‌های Droid و در طول پرواز هوایی تیم به سمت مقر مشتری کدنویسی شده است. اگرچه این روایت به خوبی نشان می‌دهد که فرآیند توسعه درایورها چقدر می‌تواند سریع باشد، اما هنوز بنچمارک مستقل یا ارزیابی رسمی از کارایی و زمان توسعه واقعی آن منتشر نشده است.

شرط‌بندی بزرگ روی ارکستراسیون پرتابل و چندمنظوره

پروژه OpenCompute پا به بازاری می‌گذارد که رقبای نام‌آشنایی همچون E2B، دیتونا (Daytona)، مدال (Modal)، سندباکس‌های ایجنت کوبرنتیز، سابستریت گوگل و میکرو وی‌ام‌های AWS Lambda در آن حضور دارند. البته این پروژه‌ها از سرویس‌های هاست‌شده سندباکس گرفته تا سیستم‌های ارکستراسیون و ران‌تایم‌های پردازشی را شامل می‌شوند و در لایه‌های مختلفی با هم رقابت می‌کنند.

فکتوری با هوشمندی OpenCompute را بالا‌تر از تمام این بسترها و به عنوان یک لایه ارکستراسیون مشترک قرار داده است. این رویکرد به توسعه‌دهندگان اجازه می‌دهد از یک چرخه حیات یکسان روی ران‌تایم‌های مختلف استفاده کنند، قابلیت‌های هر زیرساخت را به روشنی بشناسند و هر زمان لازم بود سرور‌های داخلی خود را از طریق درایور به آن وصل کنند. در نهایت، موفقیت واقعی این ابزار به کیفیت و پایداری این درایورها، جزئیات لایسنس نسخه متن‌باز و نحوه عملکرد بی‌نقص کنترل پلن در مدیریت ناوگان‌های بزرگ و ترکیبی از ارائه‌دهندگان مختلف وابسته خواهد بود.