چگونه WebAssembly محاسبات لبه را تغییر می دهد

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

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

پس چگونه مهندسان می‌توانند روش‌های توسعه خود را برای هموارسازی سفر به لبه بهینه کنند؟ پاسخ می تواند در مدل مؤلفه WebAssembly (Wasm) باشد. همانطور که توسعه دهندگان شروع به ایجاد کتابخانه های مؤلفه Wasm می کنند، آنها را به عنوان بزرگترین جعبه لگو در جهان در نظر می گیرند. در گذشته، ما داده های خود را به محاسبات خود آورده بودیم. اکنون وارد عصری می‌شویم که محاسبات خود را به داده‌های خود می‌بریم.

منظور ما از “لبه” چیست؟

تعاریف مختلفی از محاسبات لبه. برخی آن را به عنوان “لبه نزدیک” می بینند، یعنی مرکز داده ای که در نزدیکی کاربر قرار دارد. گاهی اوقات به معنای لبه CDN است. برخی دستگاه‌ها را در «لبه دور» تصور می‌کنند، یعنی دستگاه‌های IoT یا حسگرها در محیط‌های محدود به منابع. وقتی به لبه و نحوه ارتباط آن با WebAssembly (Wasm) فکر می کنیم، منظور دستگاهی است که کاربر در حال حاضر با آن در تعامل است. این می تواند تلفن هوشمند آنها باشد، یا می تواند ماشین آنها باشد، یا می تواند قطار یا هواپیما باشد، حتی مرورگر وب فروتن. “لبه” به معنای توانایی قرار دادن هوش محاسباتی درخواستی در مکان مناسب و در زمان مناسب است.

شکل ۱. برنامه‌های کاربردی در Cosmonic روی هر لبه‌ای از ابرهای عمومی تا کاربران در لبه دور اجرا می‌شوند.

طبق گزارش Edge 2023 NTT، تقریباً ۷۰٪ از شرکت‌ها تصویب لبه با ردیابی سریع برای به دست آوردن مزیت رقابتی (جناسی مورد نظر) یا مقابله با مسائل مهم تجاری. فهمیدن دلیل آن آسان است. انگیزه برای قرار دادن تجربیات ارزشمند و بی‌درنگ در دستگاه‌های شخصی با نیاز به قرار دادن نیروی محاسباتی مستقیماً در فرآیندهای تولید و لوازم صنعتی مطابقت دارد.

تطبیق سریع لبه ها منطقی تجاری است. در ارائه معماری‌های اول تلفن همراه و تجربیات شخصی‌سازی شده کاربر، تأخیر را کاهش می‌دهیم و عملکرد، دقت و بهره‌وری را بهبود می‌بخشیم. مهمتر از همه، ما تجربیات کاربر در سطح جهانی را در زمان مناسب و در مکان مناسب ارائه می دهیم. استانداردهای سمت سرور در حال ظهور سریع، مانند WASI و مدل مؤلفه WebAssembly، به ما این امکان را می دهد که این نتایج را در راه حل های لبه سریعتر، با ویژگی های بیشتر و با هزینه کمتر ارائه دهیم. .

مسیری به انتزاع

در طول ۲۰ سال گذشته، ما پیشرفت زیادی در انتزاع پیچیدگی های رایج از تجربه توسعه داشته ایم. انتقال این لایه‌ها به پلت‌فرم‌های استاندارد به این معنی است که با هر موج نوآوری، تلاش را ساده‌تر کرده، زمان عرضه به بازار را کاهش داده‌ایم و سرعت نوآوری را افزایش داده‌ایم.

شکل ۲. دوران فناوری.

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

Kubernetes در سازماندهی خوشه های بزرگی از کانتینرها، در مقیاس، در سراسر سیستم های توزیع شده عالی است. ارکسترهای کوچکتر و خواهر و برادر آن – K3s، KubeEdge، MicroK8s، MicroShift – این را یک گام فراتر می‌گذارند و به کانتینرها اجازه می‌دهند تا در ردپاهای کوچک‌تری اجرا شوند. موارد استفاده معروفی وجود دارد، مانند موارد استفاده USAF و ایستگاه فضایی بین المللی. آیا می توانید Kubernetes را روی یک دستگاه اجرا کنید؟ کاملا. آیا می توانید آن را به دستگاه های بسیار کوچک پایین بیاورید؟ آره. اما، همانطور که شرکت ها در حال یافتن هستند، نقطه ای وجود دارد که قیمت Kubernetes عملیاتی از ارزش استخراج شده بیشتر است.

چالش های Kubernetes در لبه

در ارتش، ممکن است محدودیت‌های معماری موبایل را با استفاده از زبان اندازه، وزن و قدرت توصیف کنیم – به اختصار SWaP. در یک مقیاس خاص، Kubernetes به خوبی در لبه کار می کند. با این حال، اگر بخواهیم برنامه‌ها را روی Raspberry Pis یا دستگاه‌های شخصی اجرا کنیم، چه؟

بهینه‌سازی کانتینرهای Docker امکان‌پذیر است، اما حتی کوچک‌ترین و بهینه‌ترین کانتینر نیز در حدود ۱۰۰ مگابایت تا ۲۰۰ مگابایت است. برنامه های کاربردی کانتینری مبتنی بر جاوای استاندارد اغلب در گیگا بایت حافظه در هر نمونه اجرا می شوند. این ممکن است برای هواپیماها کار کند، اما، حتی در اینجا، Kubernetes تشنه منابع است. تا زمانی که همه چیز مورد نیاز برای کار با Kubernetes را روی جت خود بیاورید، ۳۰٪ تا ۳۵٪ از منابع آن دستگاه فقط در راه اندازی پلت فرم اشغال می شود، هرگز مهم نیست که کاری را که برای آن در نظر گرفته شده است انجام دهید.

دستگاه‌هایی که به مرکز داده مرکزی، دفتر یا مرکز نگهداری بازمی‌گردند، ممکن است پهنای باند و زمان خرابی برای انجام به‌روزرسانی‌ها را داشته باشند. با این حال، دستگاه های تلفن همراه واقعی “پیشبرد مستقر” ممکن است فقط به طور متناوب از طریق اتصالات با پهنای باند کم به هم متصل شوند یا سرویس دهی آنها دشوار باشد. دارایی‌های سرمایه‌ای مانند کشتی‌ها، ساختمان‌ها و زیرساخت‌های برق ممکن است با عمر مفید ۲۵ تا ۵۰ سال طراحی شوند – تصور حمل و نقل کانتینرهای پیچیده پر از وابستگی‌های ایستا سخت است.

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

حتی ظروف بسیار بهینه شده و کمینه شده نیز می توانند زمان شروع سرد را در چند ثانیه اندازه گیری کنند. برنامه‌های بی‌درنگ (مثلاً برنامه‌های پیام‌رسان، سرویس‌های پخش، و بازی‌های چندنفره)، یعنی آن‌هایی که باید در کمتر از ۲۰۰ میلی‌ثانیه به درخواست رفت و برگشت پاسخ دهند تا احساس تعامل داشته باشند، نیاز دارند که برنامه‌های کانتینری قبل از رسیدن درخواست‌ها به حالت غیرفعال در حال اجرا باشند. مرکز اطلاعات. این هزینه در هر برنامه ترکیب می شود و در تعداد مناطق Kubernetes که شما کار می کنید ضرب می شود. در هر منطقه، برنامه‌های خود را از پیش مستقر کرده و برای برآورده کردن تقاضای مورد انتظار، مقیاس‌بندی می‌کنید. این “مشکل کران پایین Kubernetes” به این معنی است که حتی استقرارهای Kubernetes بسیار بهینه شده نیز اغلب با ظرفیت بیکاری گسترده عمل می کنند.

هزینه بالای مدیریت کانتینر

کانتینرها مزایای زیادی برای زیرساخت فناوری به ارمغان می‌آورند، اما هزینه‌های جدی مدیریت برنامه‌های کاربردی داخل آن کانتینرها را حل نمی‌کنند. گران‌ترین بخش عملیات Kubernetes هزینه نگهداری و به‌روزرسانی «boilerplate» یا کد غیرعملکردی است – نرم‌افزاری که به‌صورت ایستا کامپایل شده و در هر برنامه/کانتینر در زمان ساخت گنجانده می‌شود.

لایه‌های یک کانتینر با باینری‌های برنامه‌ای ترکیب می‌شوند که معمولاً شامل کدهای وارد شده، مملو از آسیب‌پذیری‌ها هستند که در زمان کامپایل ثابت می‌شوند. توسعه دهندگانی که برای ارائه ویژگی های برنامه جدید استخدام شده اند، خود را در نقش “کشاورزی دیگ بخار” می یابند. این بدان معناست که برای ایمن ماندن و مطابقت با دستورالعمل‌های امنیتی و نظارتی، آنها باید دائماً کد غیرعملکردی را که ۹۵ درصد از متوسط ​​برنامه یا میکروسرویس را شامل می‌شود، وصله کنند.

مشکل به ویژه در مقیاس حاد است. Adobe اخیراً در مورد هزینه بالای عملیات خوشه‌های Kubernetes در روز Cloud Native WebAssembly 2023 در آمستردام بحث کرد. مهندسان ارشد ادوبی، کالین مورفی و شان ایزوم به اشتراک گذاشتند، “بسیاری از مردم Kubernetes را اجرا می کنند، اما وقتی این نوع راه اندازی چند مستاجر را اجرا می کنید، در حالی که از نظر عملیاتی عالی است، اجرای آن می تواند بسیار گران باشد.”

همانطور که معمولاً اتفاق می‌افتد، وقتی سازمان‌ها دلیل مشترکی پیدا می‌کنند، در نرم‌افزار منبع باز با هم همکاری می‌کنند. در مورد Adobe< /a>، آنها به پلتفرم WebAssembly به عنوان یک ارائه دهنده خدمات (PaaS) پیوسته اند Cosmonic، BMW، و دیگران برای استفاده از CNCF wasmCloud. با wasmCloud، آنها برای ایجاد زمان اجرای برنامه در اطراف WebAssembly همکاری کرده اند تا بتوانند چرخه عمر برنامه را ساده کنند. با Adobe، آنها از wasmCloud برای آوردن Wasm همراه با املاک چند مستاجر Kubernetes برای ارائه سریع‌تر و با هزینه کمتر ویژگی‌ها.

مزایای Wasm در لبه

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

اندازه کوچک و جعبه ایمنی ایمن Wasm به این معنی است که می توان آن را با خیال راحت در همه جا اجرا کرد. با زمان شروع سرد در محدوده ۵ تا ۵۰ میکروثانیه، Wasm به طور موثر مشکل شروع سرد را حل می کند. هر دو با Kubernetes سازگار است در حالی که به آن وابسته نیست. اندازه کوچک آن به این معنی است که می‌توان آن را به تراکم بسیار بالاتری نسبت به کانتینرها تغییر داد و در بسیاری از موارد، حتی می‌توان آن را در صورت نیاز با هر فراخوانی به طور عملکردی اجرا کرد. اما یک ماژول Wasm در مقایسه با یک برنامه کانتینری micro-K8s چقدر کوچکتر است؟

یک ماژول Wasm بهینه شده معمولاً بین ۲۰ تا ۳۰ کیلوبایت اندازه دارد. در مقایسه با یک ظرف Kubernetes (معمولاً چند صد مگابایت)، واحدهای محاسباتی Wasm که می‌خواهیم توزیع کنیم چندین مرتبه کوچکتر هستند. اندازه کوچکتر آنها زمان بارگذاری را کاهش می‌دهد، قابلیت حمل را افزایش می‌دهد و به این معنی است که می‌توانیم آنها را حتی نزدیک‌تر به کاربران کار کنیم.

مدل مؤلفه WebAssembly

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

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

این بدان معناست که پلتفرم‌هایی مانند wasmCloud می‌توانند جدیدترین و به‌روزترین نسخه‌های یک مؤلفه را در زمان اجرا بارگیری کنند و توسعه‌دهنده را از نگهداری پرهزینه برنامه به برنامه نجات دهد. علاوه بر این، اجزای مختلف را می‌توان در زمان‌ها و مکان‌های مختلف بسته به زمینه، شرایط عملیاتی فعلی، حریم خصوصی، امنیت یا هر ترکیب دیگری از عوامل متصل کرد – همه اینها بدون تغییر برنامه اصلی شما. توسعه دهندگان از کشاورزی دیگ بخاری رها شده اند و برای تمرکز بر ویژگی ها آزاد می شوند. شرکت‌ها می‌توانند این پس‌انداز را در صدها، حتی هزاران برنامه، ترکیب کنند.

مدل مؤلفه WebAssembly با کوچک‌تر شدن، قابل حمل‌تر شدن و ایمن‌تر شدن برنامه‌ها به‌طور پیش‌فرض، تلاش‌ها را افزایش می‌دهد. برای اولین بار، توسعه‌دهندگان می‌توانند بخش‌هایی از برنامه‌های کاربردی خود را که در زبان‌های مختلف پیاده‌سازی شده‌اند، به‌عنوان گزاره‌های ارزش متفاوت انتخاب و انتخاب کنند تا با موارد استفاده متنوع‌تر مطابقت داشته باشند.

می‌توانید در InfoWorld اینجا درباره مدل مؤلفه WebAssembly بیشتر بخوانید.

Wasm در لبه مصرف کننده

این استانداردهای در حال ظهور در حال حاضر انقلابی در نحوه ساخت، استقرار، عملکرد و نگهداری برنامه‌های کاربردی ایجاد کرده‌اند. در جبهه مصرف‌کننده، Amazon Prime Video به مدت ۱۲ ماه با WebAssembly کار کرده است تا روند به روز رسانی را برای بیش از ۸۰۰۰ نوع دستگاه منحصر به فرد از جمله تلویزیون، PVR، کنسول و استیک های جریانی بهبود بخشد. این فرآیند دستی به نسخه‌های بومی جداگانه برای هر دستگاه نیاز دارد که بر عملکرد تأثیر منفی می‌گذارد. این شرکت پس از پیوستن به اتحاد Bytecode (نماینده انجمن Wasm)، JavaScript با Wasm در عناصر انتخابی برنامه Prime Video.

با Wasm، تیم توانست میانگین زمان‌های فریم را از ۲۸ به ۱۸ میلی‌ثانیه و در بدترین حالت زمان‌های فریم را از ۴۵ به ۲۵ میلی‌ثانیه کاهش دهد. استفاده از حافظه نیز بهبود یافته است. در ، Alexandru Ene گزارش می دهد که سرمایه گذاری در Rust و WebAssembly نتیجه داده است: “پس از یک سال و ۳۷۰۰۰ خط کد Rust، عملکرد، پایداری و مصرف CPU را به طور قابل توجهی بهبود بخشیده و استفاده از حافظه را کاهش داده ایم.”

• رایانش لبه< /a>
• رایانش ابری< /a>
• کتابخانه‌های توسعه و چارچوب
• توسعه نرم افزار< /a>
• کوبرنتس
• WebAssembly