عکس فوری

چالش

هزینه نگهداری سیستمی که قادر به پردازش ده ها هزار درخواست تقریباً همزمان است، اما بیش از 90 درصد از زمان خود را در حالت بیکار صرف می کند، قابل توجیه نیست.

کانتینری‌سازی توانایی مقیاس‌سازی حجم‌های کاری بر حسب تقاضا را نوید می‌دهد، که شامل کاهش مقیاس زمانی که تقاضا کم است. حفظ بسیاری از غلاف ها در میان تعداد زیادی از خوشه ها فقط برای اینکه سیستم زمان را در فرآیند ارتقاء مقیاس تلف نکند، با نقطه کانتینری شدن حجم کار در تناقض است.

راه حل

فرمیون پلتفرمی به نام SpinKube تولید می‌کند که از WebAssembly (WASM) استفاده می‌کند، که در اصل برای اجرای عناصر کوچک بایت کد در محیط‌های مرورگر وب نامعتبر ایجاد شده بود، به عنوان وسیله‌ای برای اجرای بارهای کاری کوچک در مقادیر زیاد در محیط‌های سرور Kubernetes.

از آنجایی که حجم‌های کاری WASM کوچک‌تر است و نگهداری آن آسان‌تر است، با افزایش تقاضای شبکه بدون صرف زمان زیاد در این فرآیند، می‌توان به‌مدت زمان، پادها را چرخاند.

و از آنجایی که WASM از بایت کد از پیش کامپایل شده تشکیل شده است، می توان آن را بر روی پلتفرم های سروری که توسط Ampere® Altra® قدرت می گیرد، بدون تمام سربار چند رشته ای و میکروکدی که سایر CPU ها معمولاً به محیط خود وارد می کنند اجرا کرد. به این ترتیب، به هر حال غیر ضروری باشد.

پیاده سازی

به عنوان نمایشی از کارایی SpinKube، مهندسان فناوری اطلاعات گروه ZEISS با Ampere، Fermyon و Microsoft همکاری کردند تا سیستمی را تولید کنند که همزمان با افزایش تقاضا در سناریوی به موقع، پادهای WASM جدید را بچرخاند.

این نمایش ثابت می‌کند که در عمل، یک سیستم پردازش سفارش مشتری که بر روی SpinKube اجرا می‌شود، در مقایسه با نمونه مشابهی که با غلاف‌های Kubernetes معمولی اجرا می‌شود، مزایای چشمگیری را به همراه دارد. به گفته کای والتر، معمار برجسته در گروه ZEISS،

زمانی که به یک حجم کاری سنگین با Node.js نگاه می‌کردیم، می‌توانستیم همان تعداد سفارش را در همان زمان با محیط VM پردازنده Ampere با 60 درصد ارزان‌تر از نمونه x86 VM جایگزین پردازش کنیم.

منبع: چگونه ZEISS از SpinKube و Ampere در Azure برای کاهش هزینه تا 60٪ استفاده می کند

زمینه: معمای تامین بیش از حد

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

در واقع، اشتراک بیش از حد منابع به عنوان "بهترین روش" برای مدیران VM آموزش داده می شد. هدف در آن زمان کمک به مدیران برای حفظ KPI برای عملکرد و در دسترس بودن و در عین حال محدود کردن خطرات ناشی از مصرف بیش از حد محاسبات، حافظه و ذخیره‌سازی بود.

تیم Momento به دلیل تجربه گسترده خود با کش اشیاء در AWS، به ذخیره سازی برای محصول اولیه خود رضایت دادند. آن‌ها از آن زمان مجموعه محصولات خود را گسترش داده‌اند تا خدماتی مانند اتوبوس‌های پیام‌های میخانه-زیر را در بر بگیرد. حافظه پنهان بدون سرور Momento، بر اساس پروژه منبع باز Apache Pelikan، به مشتریان خود امکان می دهد تا مدیریت منابع و کارهای بهینه سازی را که با اجرای یک حافظه پنهان کلید ارزش همراه است، به طور خودکار انجام دهند.

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

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

اگرچه آنها در کنار غلاف های فعال نگهداری می شوند، اما اولویت کمی دارند. وقتی تقاضا افزایش می‌یابد و حجم کار نیاز به افزایش دارد، وضعیت یک غلاف متوقف شده به در انتظار تغییر می‌کند.

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

مکث پاد روشی هوشمندانه برای ایجاد سریع‌تر به نظر رسیدن بارهای کاری فعال است. اما زمانی که سطوح اوج تقاضا به مرتبه‌ای بزرگ‌تر از سطوح تقاضای اسمی تبدیل می‌شوند، حجم انبوه غلاف‌های متوقف‌شده بیش از حد تدارک دیده شده، هزینه‌های زیادی را به همراه خواهد داشت.

ZEISS یک پیشرفت را انجام می دهد

این جایی است که ZEISS خودش را پیدا کرد. گروه ZEISS که در سال 1846 تأسیس شد، با فعالیت در بیش از 50 کشور، رهبر جهانی در اپتیک علمی و اپتوالکترونیک است. بخش‌های ZEISS علاوه بر ارائه خدمات به بازارهای مصرف، به کیفیت صنعتی و تحقیقات، فناوری پزشکی و صنایع تولید نیمه‌رسانا نیز خدمات می‌دهند.

رفتار مشتریان در بازارهای مصرفی می تواند بسیار همبسته باشد و در نتیجه گاه به گاه امواج بزرگی از سفارشات با وقفه ای در فعالیت در بین آنها ایجاد می شود. به همین دلیل، سیستم پردازش سفارش در سراسر جهان ZEISS می‌تواند در هر دقیقه به اندازه صفر سفارش مشتری و در دقیقه بعد بیش از 10000 سفارش تقریباً همزمان را دریافت کند.

تامین بیش از حد برای ZEISS عملی نیست. منطق یک سیستم پردازش سفارش بسیار پیش پا افتاده تر از مثلاً یک پروژه تحقیقاتی مبتنی بر هوش مصنوعی است. علاوه بر این، فقط به صورت پراکنده مورد نیاز است. در چنین مواردی، تامین بیش از حد شامل تخصیص خوشه‌های عظیم از غلاف‌ها است که همگی منابع ارزشمندی را مصرف می‌کنند، در حالی که بیش از 90 درصد از وجود خود را اساساً بی‌کار می‌گذرانند. آنچه که ZEISS از زیرساخت دیجیتالی خود نیاز دارد عبارتند از:

خوشه های کارگری با پروفایل های بسیار پایین تر ، انرژی بسیار کمتری مصرف می کنند در حالی که هزینه های عملیاتی را کاهش می دهند.

قابلیت های مدیریت رفتار که امکان تغییرات خودکار و دستی در محیط های ابری را در پاسخ به شرایط شبکه به سرعت در حال تغییر می دهد.

مهاجرت برنامه‌ریزی‌شده در مراحل تکراری ، سیستم پردازش سفارش قبلی را قادر می‌سازد تا در یک برنامه سفر از پیش تعیین‌شده در طول زمان بازنشسته شود و نه همه‌جا.

کل صنعت در حال حاضر درباره بار ذهنی صحبت می کند. یکی از بخش‌های کار من این است که مراقب باشم که تیم‌هایمان را اضافه بار نکنیم. ما در اجرای موارد جهش بزرگی انجام نمی دهیم. ما قصد داریم تیم های ما از مزایای آن بهره ببرند، اما بدون نیاز به آموزش مجدد آنها. ما می‌خواهیم تطبیق کنیم، تکرار کنیم - اندکی بهتر شویم.»

راه‌حل مخمصه ZEISS ممکن است از منبعی باشد که فقط سه سال پیش، اگر غیرممکن نبود، بعید به نظر می‌رسید: WebAssembly (WASM). این برنامه برای اجرای بایت کد باینری و غیرقابل اعتماد در مرورگرهای وب سمت سرویس گیرنده طراحی شده است - در اصل جاوا اسکریپت از پیش کامپایل شده بود. در اوایل سال 2024، توسعه دهندگان منبع باز چارچوبی به نام Spin برای Kubernetes ایجاد کردند.

این چارچوب، میکروسرویس‌های بدون سرور مبتنی بر رویداد را قادر می‌سازد تا در Rust، TypeScript، Python یا TinyGo نوشته شوند و در محیط‌های سرور کم سربار با زمان شروع سرد که فقط در میلی‌ثانیه قابل اندازه‌گیری است، مستقر شوند.

فرمیون و مایکروسافت نگهبانان اصلی پلتفرم SpinKube هستند. این پلتفرم دارای چارچوب Spin، همراه با مولفه containerd-shim-spin است که به فرمیون و مایکروسافت این امکان را می‌دهد تا نگهبانان اصلی پلتفرم SpinKube باشند.

این پلتفرم چارچوب Spin را به همراه مؤلفه containerd-shim-spin ترکیب می‌کند که بارهای کاری WASM را قادر می‌سازد در Kubernetes از طریق کتابخانه runwasi هماهنگ شوند. با استفاده از این مؤلفه ها، یک برنامه بایت کد WASM ممکن است به عنوان یک مصنوع به جای یک تصویر کانتینر معمولی Kubernetes توزیع شود.

برخلاف کانتینر، این مصنوع یک سیستم مستقل و بسته بندی شده با تمام وابستگی هایش نیست. این به معنای واقعی کلمه فقط برنامه ای است که در بایت کد کامپایل شده است. پس از اعمال برنامه Spin در کلاستر تعیین شده خود، اپراتور Spin پایه، غلاف ها، خدمات و وابستگی های اساسی را که برنامه برای عملکرد به عنوان یک ظرف به آن نیاز دارد، در اختیار برنامه قرار می دهد. به این ترتیب، Spin مصنوع WASM را به عنوان یک منبع بومی Kubernetes دوباره تعریف می کند.

پس از اجرا، برنامه Spin مانند یک میکروسرویس بدون سرور عمل می کند - به این معنی که نیازی نیست فقط برای انجام عملکرد اصلی خود، توسط مکان شبکه خود مورد خطاب قرار گیرد. با این حال، Spin این کار را بدون نیاز به اضافه کردن سربار اضافی به مصنوع WASM انجام می دهد - به عنوان مثال، برای گوش دادن به سیگنال های رویداد. جزء شیم نقش شنیداری را بر عهده می گیرد. Spin برنامه WASM را برای عملکرد در یک pod Kubernetes تطبیق می دهد، پس فرآیند ارکستراسیون به هیچ وجه نیازی به تغییر ندارد.

برای نمایش خود، ZEISS سه برنامه Spin را در WASM توسعه داد: یک توزیع کننده و دو گیرنده. یک برنامه توزیع کننده پیام‌های سفارش را از یک صف ورودی دریافت می‌کند، سپس دو برنامه گیرنده سفارش‌ها را پردازش می‌کنند، اولی سفارش‌های ساده‌تری را انجام می‌دهد که زمان کمتری می‌برد، و دومی سفارش‌های پیچیده‌تر را مدیریت می‌کند. پلتفرم Fermyon برای Kubernetes استقرار مصنوعات WASM را با چارچوب Spin مدیریت می کند. سیستم به معنای واقعی کلمه به همین سادگی است.

در عمل، طبق گفته کای والتر، معمار برجسته با گروه ZEISS، یک سیستم نمایشی مبتنی بر SpinKube می‌تواند مجموعه داده‌های آزمایشی از ۱۰۰۰۰ سفارش را با تقریباً ۶۰ درصد هزینه کمتر برای برنامه‌های نمونه Rust و TypeScript با اجرای آن‌ها بر روی Dpds v5 مجهز به آمپر پردازش کند. نمونه هایی در Azure

مهاجرت بدون جابجایی

با همکاری مایکروسافت و فرمیون، ZEISS یک طرح مهاجرت تکراری ایجاد کرد که به آن امکان می‌دهد برنامه‌های Spin خود را در همان گره‌های مبتنی بر arm64 Ampere مستقر کند که ZEISS قبلاً برای سیستم فعلی و معمولی Kubernetes خود استفاده می‌ کرد. سپس برنامه‌های Spin جدید به موازات برنامه‌های قدیمی بدون نیاز به ایجاد مسیرهای شبکه جدید و جداگانه اجرا می‌شوند و سپس ابزاری برای تقسیم ترافیک ورودی بین آن مسیرها A/B طراحی می‌کنند.

ما محیط جدیدی ایجاد نمی کنیم. این چالش برای تیم مایکروسافت و فرمیون بود. ما انتظار داشتیم از خوشه Kubernetes موجود خود مجددا استفاده کنیم و در نقطه ای که مناسب بدانیم، این مسیر جدید را به موازات مسیر قدیمی پیاده سازی کنیم. بدوی هایی که SpinKube ارائه کرد، امکان این نوع همزیستی را فراهم می کند. سپس می‌توانیم از استخرهای گره‌های Arm برای منطقی استفاده کنیم که قبلاً در تراشه‌های Arm مجاز نبود.

برنامه های WASM از حافظه، توان محاسباتی و منابع سیستم بسیار محافظه کارانه تر استفاده می کنند. (به یاد داشته باشید، WASM برای مرورگرهای وب که دارای حداقل محیط هستند ساخته شده است. ) در نتیجه، کل سیستم پردازش سفارش می تواند روی دو تا از کوچکترین و کم هزینه ترین کلاس های نمونه موجود در Azure اجرا شود: استاندارد DS2 (x86) و D2pds v5 ( Ampere Altra 64 بیتی)، هر دو تنها با 2 vCPU در هر نمونه.

با این حال، ZEISS در این پروژه آزمایشی کشف کرد که با حرکت به برنامه‌های WASM که در SpinKube اجرا می‌شوند، می‌تواند به طور شفاف معماری زیربنایی را از نمونه‌های x86 به نمونه‌های D2pds مبتنی بر آمپر تغییر دهد و هزینه‌ها را تقریباً 60 درصد کاهش دهد.

SpinKube و Ampere Altra این امکان را برای سازمان‌های جهانی مانند ZEISS فراهم می‌کنند که بار کاری کالاها را با الزامات مقیاس‌پذیری بالا بر روی پلت‌فرم‌های رایانش ابری ارزان‌تر به نمایش بگذارند و به‌طور بالقوه هزینه‌ها را بیش از یک دوم بدون تأثیر بر عملکرد کاهش دهند.

منابع اضافی

برای یک بحث عمیق در مورد همکاری ZEISS با Ampere، Fermyon و Microsoft، این ویدیو را در کانال YouTube Ampere ببینید: چگونه ZEISS از SpinKube و Ampere در Azure برای کاهش هزینه ها تا 60٪ استفاده می کند.

برای یافتن اطلاعات بیشتر در مورد بهینه سازی کد خود در CPU های Ampere، راهنمای تنظیم ما را در مرکز توسعه دهندگان Ampere تحلیل کنید. همچنین می‌توانید با ثبت‌نام در خبرنامه ماهانه توسعه‌دهندگان Ampere به‌روزرسانی‌ها و پیوندهایی به محتوای روشن‌تر دریافت کنید.

اگر سؤال یا نظری در مورد این مطالعه موردی دارید، به انجمن توسعه دهندگان Ampere بپیوندید، جایی که متخصصانی را در همه زمینه‌های محاسباتی خواهید یافت که آماده پاسخگویی به آنها هستند. همچنین، برای محتوای بیشتر متمرکز بر توسعه‌دهنده، حتماً در کانال YouTube Ampere Computing مشترک شوید.

مراجع

زمان راه اندازی مجدد توسعه نرم افزار توسط مت بوچر، مدیر عامل شرکت فرمیون فرا رسیده است

معرفی Spin 3.0 توسط Radu Matei و Michelle Dhanani، وبلاگ فرمیون

ساخت یک برنامه بدون سرور پایتون WebAssembly با اسپین توسط مت بوچر، مدیر عامل Fermyon

گرفتن چرخش برای چرخش در AKS توسط کای والتر، معمار برجسته، گروه ZEISS

Cloud Native Processors & Efficient Compute — جلسه اجلاس توسعه دهندگان Ampere با حضور شان وارلی، مبشر ارشد Ampere، دور لور مدیر عامل ScyllaDB و کیت گلدنرینگ، مهندس نرم افزار ارشد Fermyon، که در 26 سپتامبر 2024 برگزار شد.

ادغام WebAssembly بدون سرور با SpinKube و خدمات ابری - ویدیویی با حضور سوهان ماهشوار، مدافع توسعه‌دهنده اصلی، AuthZed

خبرکاو