MLO در لبه با Amazon SageMaker Edge Manager و AWS IoT Greengrass

اینترنت اشیا (IoT) مشتریان را در صنایع مختلف مانند تولید، خودرو و انرژی قادر می سازد تا محیط های دنیای واقعی را نظارت و کنترل کنند. با استقرار انواع دستگاه‌های IoT لبه مانند دوربین‌ها، ترموستات‌ها و حسگرها، می‌توانید داده‌ها را جمع‌آوری کنید، آن‌ها را به ابر ارسال کنید و مدل‌های یادگیری ماشین (ML) را برای پیش‌بینی ناهنجاری‌ها، خرابی‌ها و موارد دیگر بسازید. با این حال، اگر مورد استفاده نیاز به پیش‌بینی بلادرنگ دارد، باید راه‌حل اینترنت اشیا خود را با قابلیت‌های ML در لبه (ML@Edge) غنی کنید. ML@Edge مفهومی است که چرخه عمر مدل ML را از چرخه عمر برنامه جدا می کند و به شما امکان می دهد خط لوله ML سرتاسری را اجرا کنید که شامل آماده سازی داده ها، ساخت مدل، تدوین و بهینه سازی مدل، استقرار مدل (به ناوگانی از دستگاه های لبه) است. اجرای مدل و نظارت و حاکمیت مدل. شما یک بار برنامه را مستقر می کنید و هر چند بار که نیاز دارید خط لوله ML را اجرا می کنید.

همانطور که می توانید تصور کنید، اجرای تمام مراحل پیشنهاد شده توسط مفهوم ML@Edge، بی اهمیت نیست. سوالات زیادی وجود دارد که توسعه دهندگان برای پیاده سازی یک راه حل کامل ML@Edge باید به آنها بپردازند، به عنوان مثال:

• چگونه می توانم مدل های ML را روی ناوگان (صدها، هزاران یا میلیون ها) دستگاه در لبه کار کنم؟
• چگونه می توانم مدل خود را در حین استقرار و اجرای آن در لبه ایمن کنم؟
• چگونه می توانم عملکرد مدل خود را کنترل کنم و در صورت نیاز آن را دوباره آموزش دهم؟

در این پست، یاد می گیرید که چگونه به همه این سوالات پاسخ دهید و یک راه حل نهایی برای خودکارسازی خط لوله ML@Edge خود بسازید. نحوه استفاده را خواهید دید Amazon SageMaker Edge Manager, Amazon SageMaker Studioو AWS IoT Greengrass v2 برای ایجاد یک محیط MLOps (ML Operations) که فرآیند ساخت و استقرار مدل‌های ML را به ناوگان بزرگی از دستگاه‌های لبه خودکار می‌کند.

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

بررسی اجمالی راه حل

تولید مدل‌های قوی ML مستلزم همکاری چندین شخصیت، مانند دانشمندان داده، مهندسان ML، مهندسان داده، و سهامداران کسب‌وکار، تحت یک زیرساخت نیمه خودکار پس از عملیات خاص (MLOs) است. همچنین، مدولار کردن محیط برای اینکه به همه این شخصیت‌های مختلف انعطاف‌پذیری و چابکی بدهد تا مؤلفه‌ای را که مسئولیت آن را بر عهده دارند (مستقل از جریان کار) توسعه یا بهبود بخشند، مهم است. نمونه ای از چنین زیرساختی شامل چندین حساب AWS است که این همکاری و تولید مدل های ML را هم در ابر و هم در دستگاه های لبه امکان پذیر می کند. در معماری مرجع زیر، نشان می‌دهیم که چگونه حساب‌ها و سرویس‌های متعددی را که این پلتفرم MLOps سرتاسری را برای ساخت مدل‌های ML و استقرار آنها در لبه تشکیل می‌دهند، سازماندهی کرده‌ایم.

این راه حل از حساب های زیر تشکیل شده است:

• حساب دیتا لیک – مهندسان داده، داده‌ها را از منابع داده‌های متعدد، از جمله پایگاه‌های داده داخلی و دستگاه‌های IoT، جذب، ذخیره و آماده می‌کنند.
• حساب ابزار - اپراتورهای فناوری اطلاعات خطوط لوله CI/CD را برای تحویل خودکار مداوم و استقرار بسته‌های مدل ML در حساب‌های پیش‌تولید و تولید برای دستگاه‌های لبه راه دور مدیریت و بررسی می‌کنند. اجرای خطوط لوله CI/CD با استفاده از خودکار انجام می شود پل رویداد آمازون، که رویدادهای وضعیت تغییر مدل‌ها و اهداف ML را نظارت می‌کند AWS CodePipeline.
• حساب آزمایش و توسعه - دانشمندان داده می توانند برای حل مسائل تجاری بر اساس ML، تحقیق و آزمایش با تکنیک ها و الگوریتم های مدل سازی متعدد انجام دهند و راه حل های مفهومی را اثبات کنند. مهندسان ML و دانشمندان داده با هم همکاری می کنند تا اثبات مفهومی را مقیاس بندی کنند و با استفاده از گردش کار خودکار ایجاد کنند. خطوط لوله آمازون SageMaker برای تهیه داده ها و ساخت، آموزش و بسته بندی مدل های ML. استقرار خطوط لوله از طریق خطوط لوله CI/CD هدایت می شود، در حالی که کنترل نسخه مدل ها با استفاده از رجیستری مدل آمازون SageMaker. دانشمندان داده معیارهای نسخه های چندگانه مدل را ارزیابی می کنند و با راه اندازی خط لوله CI/CD درخواست ارتقای بهترین مدل به تولید را دارند.
• حساب پیش تولید - قبل از ارتقای مدل به محیط تولید، مدل نیاز به آزمایش دارد تا از استحکام در یک محیط شبیه‌سازی اطمینان حاصل شود. بنابراین، محیط پیش تولید شبیه ساز محیط تولید است که در آن نقاط پایانی مدل SageMaker به طور خودکار مستقر و آزمایش می شوند. روش‌های آزمون ممکن است شامل آزمون یکپارچه‌سازی، تست استرس یا آزمون‌های خاص ML بر روی نتایج استنتاج باشد. در این مورد، محیط تولید یک نقطه پایانی مدل SageMaker نیست، بلکه یک دستگاه لبه است. برای شبیه سازی یک دستگاه لبه در پیش تولید، دو رویکرد ممکن است: استفاده از یک ابر محاسبه الاستیک آمازون (Amazon EC2) با مشخصات سخت افزاری یکسان، یا از یک بستر آزمایشی در آزمایشگاه متشکل از دستگاه های واقعی استفاده کنید. با این زیرساخت، خط لوله CI/CD مدل را در شبیه ساز مربوطه مستقر می کند و آزمایش های متعدد را به صورت خودکار انجام می دهد. پس از اجرای موفقیت آمیز آزمایشات، خط لوله CI/CD به تأیید دستی نیاز دارد (به عنوان مثال، از طرف ذینفع اینترنت اشیا برای ارتقای مدل به تولید).
• حساب تولید - در مورد میزبانی مدل در AWS Cloud، خط لوله CI/CD یک نقطه پایانی مدل SageMaker را در حساب تولید مستقر می کند. در این حالت، محیط تولید شامل ناوگان های متعددی از دستگاه های لبه است. بنابراین، خط لوله CI/CD از Edge Manager برای استقرار مدل ها در ناوگان مربوطه از دستگاه ها استفاده می کند.
• دستگاه های لبه – دستگاه های لبه راه دور دستگاه های سخت افزاری هستند که می توانند مدل های ML را با استفاده از Edge Manager اجرا کنند. این امکان را به برنامه کاربردی در آن دستگاه ها می دهد تا مدل ها را مدیریت کند، استنتاج را بر اساس مدل ها اجرا کند، و داده ها را به صورت ایمن در آنها ضبط کند. سرویس ذخیره سازی ساده آمازون (Amazon S3).

پروژه های SageMaker به شما کمک می کند تا فرآیند تأمین منابع در هر یک از این حساب ها را خودکار کنید. ما عمیقاً به این ویژگی نمی پردازیم، اما برای کسب اطلاعات بیشتر در مورد نحوه ساخت یک الگوی پروژه SageMaker که مدل های ML را در سراسر حساب ها مستقر می کند، بررسی کنید استقرار مدل چند حساب با Amazon SageMaker Pipelines.

حساب پیش تولید: دوقلو دیجیتال

پس از فرآیند آموزش، مدل به دست آمده نیاز به ارزیابی دارد. در حساب پیش تولید، یک دستگاه Edge شبیه سازی شده دارید. این نشان دهنده است دوقلوی دیجیتال دستگاه لبه ای که مدل ML روی آن در حال تولید است. این محیط دارای هدف دوگانه انجام تست های کلاسیک (مانند واحد، ادغام و دود) و یک زمین بازی برای تیم توسعه است. این دستگاه با استفاده از یک نمونه EC2 شبیه سازی شده است که در آن تمام اجزای مورد نیاز برای مدیریت مدل ML مستقر شده اند.

خدمات مشمول به شرح زیر است:

• AWS IoT Core - ما استفاده می کنیم AWS IoT Core برای ایجاد اشیاء چیزهای AWS IoT، ایجاد ناوگان دستگاه، ثبت ناوگان دستگاه تا بتواند با ابر تعامل داشته باشد، گواهی‌های X.509 برای احراز هویت دستگاه‌های لبه به AWS IoT Core ایجاد کنید، نقش مستعار را با AWS IoT Core مرتبط کنید که در زمان ایجاد شد. ناوگان ایجاد کرده است، یک نقطه پایانی مخصوص حساب AWS برای ارائه دهنده اعتبارنامه دریافت کنید، یک فایل رسمی Amazon Root CA دریافت کنید و فایل Amazon CA را در Amazon S3 آپلود کنید.
• Amazon Sagemaker Neo – حکیم ساز نئو به طور خودکار مدل‌های یادگیری ماشین را برای استنتاج سریع‌تر و بدون کاهش دقت بهینه می‌کند. از مدل یادگیری ماشینی پشتیبانی می کند که قبلاً با DarkNet، Keras، MXNet، PyTorch، TensorFlow، TensorFlow-Lite، ONNX یا XGBoost ساخته شده و در Amazon SageMaker یا هر جای دیگری آموزش دیده است. سپس پلتفرم سخت افزاری مورد نظر خود را انتخاب می کنید که می تواند یک نمونه میزبانی SageMaker یا یک دستگاه لبه مبتنی بر پردازنده های Ambarella، Apple، ARM، Intel، MediaTek، Nvidia، NXP، Qualcomm، RockChip، Texas Instruments یا Xilinx باشد.
• مدیریت لبه - ما از Edge Manager برای ثبت و مدیریت دستگاه edge در ناوگان Sagemaker استفاده می کنیم. ناوگان مجموعه ای از دستگاه های منطقی گروه بندی شده هستند که می توانید از آنها برای جمع آوری و تجزیه و تحلیل داده ها استفاده کنید. علاوه بر این، بسته‌کننده Edge Manager، مدل بهینه‌سازی شده را بسته‌بندی می‌کند و یک مؤلفه AWS IoT Greengrass V2 ایجاد می‌کند که می‌تواند مستقیماً مستقر شود. می‌توانید از Edge Manager برای استفاده از مدل‌های ML در مجموعه‌ای از دوربین‌های هوشمند، بلندگوهای هوشمند، روبات‌ها و سایر ناوگان دستگاه‌های SageMaker استفاده کنید.
• AWS IoT Greengrass V2 - AWS IoT Greengrass به شما اجازه می دهد تا با استفاده از یک نمونه EC2، اجزا را در دستگاه های شبیه سازی شده مستقر کنید. با استفاده از عامل AWS IoT Greengrass V2 در نمونه های EC2، می توانیم دسترسی، مدیریت و استقرار عامل و مدل Edge Manager را به دستگاه ها ساده کنیم. بدون AWS IoT Greengrass V2، راه‌اندازی دستگاه‌ها و ناوگان برای استفاده از Edge Manager به شما نیاز دارد که به‌طور دستی عامل را از یک سطل انتشار S3 کپی کنید. با ادغام AWS IoT Greengrass V2 و Edge Manager، امکان استفاده از اجزای AWS IoT Greengrass V2 وجود دارد. کامپوننت ها ماژول های نرم افزاری از پیش ساخته شده ای هستند که می توانند دستگاه های لبه را به سرویس های AWS یا خدمات شخص ثالث از طریق AWS IoT Greengrass متصل کنند.
• عامل Edge Manager - عامل Edge Manager از طریق AWS IoT Greengrass V2 در نمونه EC2 مستقر شده است. عامل می تواند چندین مدل را در یک زمان بارگذاری کند و با مدل های بارگذاری شده در دستگاه های لبه استنباط کند. تعداد مدل هایی که نماینده می تواند بارگذاری کند با توجه به حافظه موجود در دستگاه تعیین می شود.
• آمازون S3 - ما از یک سطل S3 برای ذخیره داده های استنتاج گرفته شده از عامل Edge Manager استفاده می کنیم.

ما می‌توانیم یک حساب پیش‌تولید را به‌عنوان یک دوقلو دیجیتال برای آزمایش مدل‌های ML قبل از انتقال آنها به دستگاه‌های لبه واقعی تعریف کنیم. این مزایای زیر را ارائه می دهد:

• چابکی و انعطاف پذیری - دانشمندان داده و مهندسان ML باید به سرعت بررسی کنند که آیا مدل ML و اسکریپت‌های مرتبط (اسکریپت‌های پیش پردازش و استنتاج) روی لبه دستگاه کار می‌کنند یا خیر. با این حال، بخش های IoT و علوم داده در شرکت های بزرگ ممکن است موجودیت های متفاوتی باشند. با تکثیر یکسان پشته فناوری در ابر، دانشمندان داده و مهندسان ML می توانند مصنوعات را قبل از استقرار تکرار و تجمیع کنند.
• ارزیابی ریسک و زمان تولید تسریع شده است - استقرار بر روی دستگاه لبه آخرین مرحله فرآیند است. پس از اینکه همه چیز را در یک محیط ایزوله و مستقل تأیید کردید، آن را ایمن کنید که از نظر کیفیت، عملکرد و یکپارچگی به مشخصات مورد نیاز لبه پایبند باشد. این به جلوگیری از دخالت بیشتر افراد دیگر در بخش اینترنت اشیا برای اصلاح و تکرار نسخه‌های مصنوع کمک می‌کند.
• بهبود همکاری تیمی و افزایش کیفیت و عملکرد - تیم توسعه می تواند فوراً تأثیر مدل ML را با تجزیه و تحلیل معیارهای سخت افزاری لبه و اندازه گیری سطح تعامل با ابزارهای شخص ثالث (مثلاً نرخ I/O) ارزیابی کند. سپس، تیم IoT تنها مسئول استقرار در محیط تولید است و می تواند مطمئن باشد که مصنوعات برای یک محیط تولید دقیق هستند.
• زمین بازی یکپارچه برای آزمایش - با توجه به هدف مدل های ML، محیط پیش تولید در یک گردش کار سنتی باید توسط یک دستگاه لبه خارج از محیط ابری نمایش داده شود. این سطح دیگری از پیچیدگی را معرفی می کند. یکپارچه سازی برای جمع آوری معیارها و بازخورد مورد نیاز است. در عوض، با استفاده از محیط شبیه‌سازی شده دیجیتالی، تعاملات کاهش می‌یابد و زمان عرضه به بازار کوتاه می‌شود.

حساب تولید و محیط لبه

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

ناوگان دستگاه Edge متعلق به حساب تولید AWS است. این حساب دارای تنظیمات امنیتی و شبکه خاصی است تا امکان ارتباط بین دستگاه های ابری و لبه را فراهم کند. سرویس‌های اصلی AWS مستقر در حساب تولید عبارتند از Edge Manager که مسئول مدیریت تمام ناوگان دستگاه، جمع‌آوری داده‌ها و مدل‌های ML است، و AWS IoT Core که اشیاء چیزهای اینترنت اشیا، گواهی‌ها، نام مستعار نقش و نقاط پایانی را مدیریت می‌کند.

در همان زمان، ما باید یک دستگاه لبه را با خدمات و اجزای سازنده برای مدیریت مدل‌های ML پیکربندی کنیم. اجزای اصلی به شرح زیر است:

• AWS IoT Greengrass V2
• یک عامل Edge Manager
• گواهینامه های AWS IoT
• Application.py که مسئول هماهنگی فرآیند استنتاج (بازیابی اطلاعات از منبع داده لبه و انجام استنتاج با استفاده از عامل Edge Manager و مدل ML بارگذاری شده) است.
• اتصال به آمازون S3 یا حساب داده دریاچه برای ذخیره داده های استنباط شده

خط لوله خودکار ML

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

یک خط لوله (ساخته شده با استفاده از خطوط لوله ساختمان مدل SageMaker آمازون) یک سری مراحل به هم پیوسته است که با تعریف خط لوله JSON تعریف می شود. این تعریف خط لوله یک خط لوله را با استفاده از گراف غیر چرخه ای جهت دار (DAG) رمزگذاری می کند. این DAG اطلاعاتی در مورد الزامات و روابط بین هر مرحله از خط لوله شما می دهد. ساختار DAG خط لوله با وابستگی داده ها بین مراحل تعیین می شود. این وابستگی های داده زمانی ایجاد می شوند که ویژگی های خروجی یک مرحله به عنوان ورودی به مرحله دیگر ارسال شود.

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

برای فعال کردن قابلیت‌های اتوماسیون و MLOps، ایجاد مؤلفه‌های مدولار برای ایجاد مصنوعات کد قابل استفاده مجدد که می‌توانند در مراحل مختلف و موارد استفاده ML قابل اشتراک‌گذاری باشند، مهم است. این به شما امکان می دهد تا با خودکار کردن انتقال، به سرعت پیاده سازی را از مرحله آزمایش به مرحله تولید منتقل کنید.

مراحل تعریف خط لوله ML برای فعال کردن آموزش مداوم و نسخه‌سازی مدل‌های ML به شرح زیر است:

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

در ادامه می توانید جزئیات بیشتری از نحوه ساخت خط لوله SageMaker را مشاهده کنید دفتر یادداشت.

خطوط لوله CI/CD را با استفاده از EventBridge فعال کنید

وقتی ساخت مدل را تمام کردید، می توانید فرآیند استقرار را شروع کنید. آخرین مرحله خط لوله SageMaker که در بخش قبل تعریف شد، یک نسخه جدید از مدل را در گروه رجیستری مدل SageMaker خاص ثبت می کند. استقرار نسخه جدیدی از مدل ML با استفاده از وضعیت رجیستری مدل مدیریت می شود. با تأیید یا رد دستی یک نسخه مدل ML، این مرحله رویدادی را که توسط EventBridge ثبت می‌شود، ایجاد می‌کند. سپس این رویداد می‌تواند خط لوله جدیدی (این بار CI/CD) برای ایجاد نسخه جدیدی از مؤلفه AWS IoT Greengrass شروع کند که سپس در حساب‌های پیش تولید و تولید مستقر می‌شود. تصویر زیر قانون EventBridge تعریف شده ما را نشان می دهد.

این قانون با جستجوی به روز رسانی بسته های مدل در وضعیت، گروه بسته مدل SageMaker را نظارت می کند Approved or Rejected.

قانون EventBridge سپس برای هدف قرار دادن CodePipeline پیکربندی می شود، که گردش کار ایجاد یک مؤلفه جدید AWS IoT Greengrass را با استفاده از آن آغاز می کند. Amazon SageMaker Neo و Edge Manager.

بهینه سازی مدل های ML برای معماری هدف

Neo به شما امکان می دهد مدل های ML را برای انجام استنتاج بر روی دستگاه های لبه (و در فضای ابری) بهینه کنید. به طور خودکار مدل های ML را برای عملکرد بهتر بر اساس معماری هدف بهینه می کند و مدل را از چارچوب اصلی جدا می کند و به شما امکان می دهد آن را در زمان اجرا سبک اجرا کنید.

رجوع به موارد زیر شود دفتر یادداشت برای مثالی از نحوه کامپایل یک مدل PyTorch Resnet18 با استفاده از Neo.

بسته استقرار را با گنجاندن جزء AWS IoT Greengrass بسازید

Edge Manager به شما اجازه می دهد تا مدل ها را مدیریت، ایمن، استقرار و نظارت کنید بر روی ناوگانی از دستگاه های لبه. در ادامه مطلب دفتر یادداشت، می توانید جزئیات بیشتری از نحوه ساخت یک ناوگان مینیمالیستی از دستگاه های لبه و اجرای برخی آزمایش ها با این ویژگی را مشاهده کنید.

پس از پیکربندی ناوگان و کامپایل مدل، باید یک کار بسته بندی Edge Manager را اجرا کنید، که مدل را برای استقرار در ناوگان آماده می کند. می توانید با استفاده از Boto3 SDK کار بسته بندی را شروع کنید. برای پارامترهای خود، از مدل بهینه شده و فراداده مدل استفاده می کنیم. با افزودن پارامترهای زیر به OutputConfig، این کار همچنین یک جزء AWS IoT Greengrass V2 را با این مدل آماده می کند:

• PresetDeploymentType
• PresetDeploymentConfig

کد زیر را ببینید:

import boto3
import time

SageMaker_client = boto3.client('SageMaker')

SageMaker_client.create_edge_packaging_job(
    EdgePackagingJobName="mlops-edge-packaging-{}".format(int(time.time()*1000)),
    CompilationJobName=compilation_job_name,
    ModelName="PytorchMLOpsEdgeModel",
    ModelVersion="1.0.0",
    RoleArn=role,
    OutputConfig={
        'S3OutputLocation': 's3://{}/model/'.format(bucket_name),
        "PresetDeploymentType": "GreengrassV2Component",
        "PresetDeploymentConfig": json.dumps(
            {"ComponentName": component_name, "ComponentVersion": component_version}
        ),
    }
)

مدل های ML را در لبه در مقیاس مستقر کنید

اکنون زمان آن است که مدل را در ناوگان دستگاه های لبه خود مستقر کنید. ابتدا باید اطمینان حاصل کنیم که موارد لازم را داریم هویت AWS و مدیریت دسترسی (من هستم) مجوز دستگاه های IoT خود را تهیه کرده و قادر به استقرار مؤلفه ها در آن هستیم. برای شروع نصب دستگاه‌ها به پلتفرم اینترنت اشیا، به دو عنصر اساسی نیاز داریم:

• سیاست IAM - این خط‌مشی امکان تهیه خودکار چنین دستگاه‌هایی را می‌دهد که به کاربر یا نقشی که تأمین‌کننده را انجام می‌دهد، متصل می‌شود. باید مجوز نوشتن اینترنت اشیا برای ایجاد چیز و گروه اینترنت اشیا و همچنین پیوست کردن خط مشی های لازم به دستگاه داشته باشد. برای اطلاعات بیشتر مراجعه کنید حداقل خط مشی IAM برای نصب کننده برای تهیه منابع.
• نقش IAM - این نقش به چیزها و گروه های اینترنت اشیا که ایجاد می کنیم متصل است. شما می توانید این نقش را در زمان ارائه با مجوزهای اولیه ایجاد کنید، اما فاقد ویژگی هایی مانند دسترسی به Amazon S3 یا سرویس مدیریت کلید AWS (AWS KMS) که ممکن است بعداً مورد نیاز باشد. شما می توانید این نقش را از قبل ایجاد کنید و زمانی که دستگاه را تهیه می کنیم دوباره از آن استفاده کنید. برای اطلاعات بیشتر مراجعه کنید دستگاه های اصلی را برای تعامل با AWS مجاز کنید.

نصب و تهیه AWS IoT Greengrass

پس از اینکه خط مشی و نقش IAM را در دست گرفتیم، آماده هستیم نرم افزار AWS IoT Greengrass Core را با تامین خودکار منابع نصب کنید. اگرچه می‌توان منابع اینترنت اشیا را به دنبال مراحل دستی تهیه کرد، اما روش مناسبی برای تهیه خودکار این منابع در طول نصب هسته AWS IoT Greengrass v2 وجود دارد. این گزینه ترجیحی برای نصب سریع دستگاه های جدید در پلت فرم است. بعلاوه default-jdk، نصب پکیج های دیگری لازم است مانند curl, unzipو python3.

وقتی دستگاه خود را تهیه می کنیم، نام چیز IoT باید دقیقاً با دستگاه لبه تعریف شده در Edge Manager یکسان باشد، در غیر این صورت داده ها در سطل S3 مقصد ذخیره نمی شوند.

نصب کننده می تواند نقش و نام مستعار AWS IoT Greengrass را در حین نصب ایجاد کند، اگر آنها وجود نداشته باشند. با این حال، آنها با حداقل مجوز ایجاد می شوند و برای تعامل با سرویس های دیگر مانند Amazon S3 نیاز به افزودن دستی سیاست های بیشتری دارند. توصیه می‌کنیم این منابع IAM را از قبل همانطور که قبلا نشان داده شده است ایجاد کنید، و سپس هنگام ورود دستگاه‌های جدید به حساب، از آنها استفاده مجدد کنید.

بسته بندی اجزای مدل و استنتاج

بعد از اینکه کد ما توسعه یافت، می‌توانیم هم کد (برای استنباط) و هم مدل‌های ML خود را به عنوان اجزاء در دستگاه‌های خود مستقر کنیم.

پس از آموزش مدل ML در SageMaker، می توانید مدل را با Neo با استفاده از یک کار کامپایل Sagemaker بهینه کنید. آرتیفکت‌های مدل کامپایل شده به‌دست‌آمده، می‌توانند با استفاده از بسته‌کننده Edge Manager در یک جزء GreenGrass V2 بسته‌بندی شوند. سپس، می توان آن را به عنوان یک جزء سفارشی در ثبت نام کرد اجزای من بخش در کنسول AWS IoT Greengrass. این مؤلفه قبلاً حاوی دستورات چرخه حیات لازم برای بارگیری و از حالت فشرده‌سازی مصنوع مدل در دستگاه ما است، به طوری که کد استنتاج می‌تواند آن را برای ارسال تصاویر گرفته‌شده از طریق آن بارگذاری کند.

در مورد کد استنتاج باید با استفاده از کنسول یا کامپوننت ایجاد کنیم رابط خط فرمان AWS (AWS CLI). ابتدا، کد استنتاج منبع و وابستگی‌های لازم را به آمازون S3 بسته‌بندی می‌کنیم. پس از آپلود کد، می‌توانیم کامپوننت خود را با استفاده از دستوری در .yaml یا JSON مانند مثال زیر ایجاد کنیم:

---
RecipeFormatVersion: 2020-01-25
ComponentName: dummymodel.inference
ComponentVersion: 0.0.1
ComponentDescription: Deploys inference code to a client
ComponentPublisher: Amazon Web Services, Inc.
ComponentDependencies:
  aws.GreenGrass.TokenExchangeService:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
  dummymodel:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
Manifests:
  - Platform:
      os: linux
      architecture: "*"
    Lifecycle:
      install: |-
        apt-get install python3-pip
        pip3 install numpy
        pip3 install sysv_ipc
        pip3 install boto3
        pip3 install grpcio-tools
        pip3 install grpcio
        pip3 install protobuf
        pip3 install SageMaker
        tar xf {artifacts:path}/sourcedir.tar.gz
      run:
        script: |-
          sleep 5 && sudo python3 {work:path}/inference.py 
    Artifacts:
      - URI: s3://BUCKET-NAME/path/to/inference/sourcedir.tar.gz
        Permission:
          Execute: OWNER

این دستور العمل مثال نام و توضیحات کامپوننت ما و همچنین پیش نیازهای لازم قبل از دستور اجرای اسکریپت ما را نشان می دهد. دستور العمل آرتیفکت را در یک محیط پوشه کاری در دستگاه باز می کند و ما از آن مسیر برای اجرای کد استنتاج خود استفاده می کنیم. دستور AWS CLI برای ایجاد چنین دستور العملی به شرح زیر است:

aws greengrassv2 create-component-version --region $REGION 
                                          --inline-recipe fileb://path/to/recipe.yaml

اکنون می توانید این مؤلفه ایجاد شده در کنسول AWS IoT Greengrass را مشاهده کنید.

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

پس از اینکه مدل و کد استنتاج ما به عنوان مؤلفه تنظیم شد، آماده استقرار آنها هستیم.

برنامه و مدل را با استفاده از AWS IoT Greengrass اجرا کنید

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

عامل Edge Manager مؤلفه ای است که باید روی هر دستگاه لبه نصب شود تا تمام قابلیت های Edge Manager فعال شود. در کنسول SageMaker، یک ناوگان دستگاه تعریف شده است که دارای یک سطل S3 مرتبط است. تمام دستگاه های لبه مرتبط با ناوگان داده های خود را به این مسیر S3 می گیرند و گزارش می دهند. عامل را می توان به عنوان یک مؤلفه در AWS IoT Greengrass v2 مستقر کرد، که نصب و پیکربندی آن را نسبت به زمانی که عامل در حالت مستقل مستقر شده بود آسان تر می کند. هنگام استقرار عامل به عنوان یک جزء، باید پارامترهای پیکربندی آن، یعنی ناوگان دستگاه و مسیر S3 را مشخص کنیم.

ما یک پیکربندی استقرار با اجزای سفارشی برای مدل و کدی که ایجاد کردیم ایجاد می کنیم. این تنظیمات در یک فایل JSON تعریف شده است که نام و هدف استقرار و همچنین اجزای موجود در استقرار را فهرست می کند. می‌توانیم پارامترهای پیکربندی هر جزء را اضافه و به‌روزرسانی کنیم، مانند عامل Edge Manager، جایی که نام ناوگان و سطل را مشخص می‌کنیم.

{
    "targetArn": "targetArn",
    "deploymentName": "dummy-deployment",
    "components": {
        "aws.GreenGrass.Nucleus": {
            "version": "2.5.3",
        },
        "aws.GreenGrass.Cli": {
            "version": "2.5.3"
        },
        "aws.GreenGrass.SageMakerEdgeManager": {
            "version": 1.1.0,
            "configurationUpdate": {
                "merge": {
                "DeviceFleetName": "FLEET-NAME",
                "BucketName": "BUCKET-NAME-URI"
                }
            }
        },
        "dummymodel.inference": {
            "version": "0.0.1"
        },
        "dummymodel": {
            "version": "0.0.1"
        }
    }
}

شایان ذکر است که ما نه تنها مدل، اجزای استنتاج و عامل، بلکه AWS IoT Greengrass CLI و هسته را نیز به عنوان اجزاء اضافه کرده ایم. اولی می تواند به اشکال زدایی برخی از استقرارها به صورت محلی در دستگاه کمک کند. مورد دوم به استقرار اضافه می شود تا در صورت نیاز، دسترسی به شبکه لازم را از خود دستگاه پیکربندی کند (به عنوان مثال، تنظیمات پراکسی)، و همچنین در صورتی که می خواهید یک ارتقا OTA هسته AWS IoT Greengrass v2 را انجام دهید. هسته به دلیل نصب در دستگاه مستقر نشده است و فقط به روز رسانی پیکربندی اعمال می شود (مگر اینکه ارتقاء داده شده باشد). برای استقرار، کافیست دستور زیر را روی پیکربندی قبلی اجرا کنیم. به یاد داشته باشید که ARN هدفی را که استقرار در آن اعمال خواهد شد (یک چیز IoT یا گروه IoT) تنظیم کنید. ما همچنین می توانیم این مؤلفه ها را از کنسول مستقر کنیم.

aws greengrassv2 create-deployment --region $REGION 
                                   --cli-input-json file://path/to/deployment.json

مدل های ML مستقر در لبه را نظارت و مدیریت کنید

اکنون که برنامه شما روی دستگاه‌های لبه اجرا می‌شود، زمان آن فرا رسیده است که نحوه نظارت بر ناوگان را برای بهبود مدیریت، نگهداری و دید، درک کنید. در کنسول SageMaker، را انتخاب کنید مدیریت لبه در صفحه پیمایش، سپس انتخاب کنید ناوگان دستگاه Edge. از اینجا، ناوگان خود را انتخاب کنید.

در صفحه جزئیات ناوگان، می‌توانید برخی فراداده‌های مدل‌هایی که در هر دستگاه از ناوگان شما در حال اجرا هستند را مشاهده کنید. گزارش ناوگان هر 24 ساعت تولید می شود.

داده هایی که توسط هر دستگاه از طریق Edge Agent گرفته می شود به یک سطل S3 در قالب خطوط json (JSONL) ارسال می شود. فرآیند ارسال داده های گرفته شده از نقطه نظر برنامه مدیریت می شود. بنابراین شما آزاد هستید که تصمیم بگیرید که آیا این داده ها را ارسال کنید، چگونه و چند وقت یکبار.

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

نتیجه

در این پست، نحوه ساخت یک راه حل کامل که MLOps و ML@Edge را با استفاده از خدمات AWS ترکیب می کند، یاد گرفتید. ساختن چنین راه حلی بی اهمیت نیست، اما امیدواریم معماری مرجع ارائه شده در این پست بتواند الهام بخش باشد و به شما کمک کند تا یک معماری محکم برای چالش های تجاری خود بسازید. شما همچنین می توانید فقط از قطعات یا ماژول های این معماری استفاده کنید که با محیط MLOps موجود شما ادغام می شوند. با نمونه‌سازی یک ماژول واحد در یک زمان و استفاده از خدمات AWS مناسب برای رسیدگی به هر بخش از این چالش، می‌توانید نحوه ایجاد یک محیط MLOps قوی و همچنین ساده‌تر کردن معماری نهایی را بیاموزید.

به عنوان گام بعدی، ما شما را تشویق می کنیم که Sagemaker Edge Manager را برای مدیریت ML خود در چرخه عمر لبه امتحان کنید. برای اطلاعات بیشتر در مورد نحوه عملکرد Edge Manager، نگاه کنید به با SageMaker Edge Manager مدل ها را در لبه مستقر کنید .

درباره نویسندگان

برونو پیستون یک معمار راه حل های تخصصی AI/ML برای AWS مستقر در میلان است. او با مشتریانی در هر اندازه ای کار می کند تا به آنها کمک کند تا نیازهای فنی خود را عمیقاً درک کنند و راه حل های هوش مصنوعی و یادگیری ماشینی را طراحی کنند که بهترین استفاده را از AWS Cloud و پشته یادگیری ماشین آمازون می کند. زمینه تخصص او عبارتند از: یادگیری ماشینی، صنعتی سازی یادگیری ماشینی و MLOps. او از گذراندن وقت با دوستانش و کشف مکان های جدید و همچنین سفر به مقاصد جدید لذت می برد.

ماتئو کالابرس یک معمار تحویل مشتری AI/ML در تیم خدمات حرفه ای AWS است. او با شرکت‌های بزرگ EMEA در پروژه‌های AI/ML کار می‌کند و به آنها در پیشنهاد، طراحی، ارائه، مقیاس‌بندی و بهینه‌سازی حجم کاری تولید ML کمک می‌کند. تخصص اصلی او عملیات ML (MLOps) و یادگیری ماشین در Edge است. هدف او کوتاه کردن زمان آنها برای ارزش گذاری و تسریع نتایج تجاری با ارائه بهترین شیوه های AWS است. در اوقات فراغت از پیاده روی و مسافرت لذت می برد.

رائول دیاز گارسیا Sr Sr Scientist در تیم خدمات حرفه ای AWS است. او با مشتریان سازمانی بزرگ در سراسر EMEA کار می کند، جایی که به آنها کمک می کند راه حل های مربوط به بینایی کامپیوتر و یادگیری ماشین را در فضای اینترنت اشیا فعال کنند.

سوکراتیس کارتاکیس یک معمار ارشد راه حل های متخصص یادگیری ماشین برای خدمات وب آمازون است. Sokratis بر روی توانمندسازی مشتریان سازمانی برای صنعتی کردن راه‌حل‌های یادگیری ماشین (ML) با بهره‌برداری از خدمات AWS و شکل‌دهی مدل عملیاتی خود، یعنی بنیاد MLOps و نقشه راه تحول با استفاده از بهترین شیوه‌های توسعه، تمرکز دارد. او بیش از 15 سال را صرف اختراع، طراحی، رهبری و پیاده‌سازی راه‌حل‌های نوآورانه ML و اینترنت اشیا (IoT) در سطح تولید نهایی در حوزه‌های انرژی، خرده‌فروشی، سلامت، مالی/بانکداری، ورزش‌های موتوری و غیره کرده است. سوکراتیس دوست دارد اوقات فراغت خود را با خانواده و دوستان یا موتور سواری بگذراند.

سمیر آرائوخو یک معمار راه حل های AI/ML در AWS است. او به مشتریان کمک می کند تا راه حل های AI/ML ایجاد کنند که چالش های تجاری آنها را با استفاده از AWS حل کند. او روی چندین پروژه AI/ML مربوط به بینایی کامپیوتر، پردازش زبان طبیعی، پیش بینی، ML در لبه و غیره کار کرده است. او دوست دارد در اوقات فراغت خود با پروژه های سخت افزاری و اتوماسیون بازی کند و علاقه خاصی به رباتیک دارد.