با استفاده از Kubeflow در AWS، گردش کار یادگیری ماشینی سرتاسر قابل تکرار، ایمن و قابل توسعه بسازید.

این یک پست وبلاگ مهمان است که با athenahealth نوشته شده است.

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

در فضای هوش مصنوعی (AI)، athenahealth از علم داده و یادگیری ماشین (ML) برای تسریع فرآیندهای تجاری و ارائه توصیه‌ها، پیش‌بینی‌ها و بینش‌ها در چندین سرویس استفاده می‌کند. آتنهلث از اولین پیاده‌سازی خود در خدمات اسناد خودکار، پردازش بدون لمس میلیون‌ها سند ارائه‌دهنده-بیمار، تا کار اخیرش در دستیاران مجازی و بهبود عملکرد چرخه درآمد، همچنان به استفاده از هوش مصنوعی برای کمک به افزایش کارایی، قابلیت‌های خدمات و نتایج بهتر برای ارائه‌دهندگان ادامه می‌دهد. و بیمارانشان

این پست وبلاگ نحوه استفاده از athenahealth را نشان می دهد Kubeflow در AWS (یک توزیع خاص AWS از Kubeflow) برای ایجاد و ساده‌سازی یک گردش کار علم داده سرتاسر که ابزارهای ضروری را حفظ می‌کند، کارایی عملیاتی را بهینه می‌کند، بهره‌وری دانشمندان داده را افزایش می‌دهد و زمینه را برای گسترش آسان‌تر قابلیت‌های ML آنها فراهم می‌کند.

Kubeflow یک پلت فرم منبع باز ML است که برای استقرار گردش کار ML در Kubernetes ساده، قابل حمل و مقیاس پذیر است. Kubeflow با استفاده از ابزارهای منبع باز مرتبط که به خوبی با Kubernetes ادغام می شوند، به این مهم دست می یابد. برخی از این پروژه ها عبارتند از Argo برای ارکستراسیون خط لوله، Istio برای سرویس مش، Jupyter برای نوت بوک، Spark، TensorBoard و Katib. خطوط لوله Kubeflow به ساخت و استقرار گردش‌های کاری ML قابل حمل و مقیاس‌پذیر کمک می‌کند که می‌تواند شامل مراحلی مانند استخراج داده، پیش پردازش، آموزش مدل و ارزیابی مدل در قالب خطوط لوله قابل تکرار باشد.

AWS با ارائه توزیع Kubeflow خود (به نام Kubeflow در AWS) به جامعه منبع باز Kubeflow کمک می کند که به سازمان هایی مانند athenahealth کمک می کند تا گردش های کاری ML بسیار قابل اعتماد، ایمن، قابل حمل و مقیاس پذیر را با کاهش سربار عملیاتی از طریق ادغام با خدمات مدیریت شده AWS ایجاد کنند. AWS گزینه های مختلف استقرار Kubeflow مانند استقرار با را فراهم می کند Cognito آمازون، استقرار با سرویس پایگاه داده رابطه آمازون (آمازون RDS) و سرویس ذخیره سازی ساده آمازون (Amazon S3)، و استقرار وانیل. برای جزئیات در مورد یکپارچه سازی سرویس و افزونه های موجود برای هر یک از این گزینه ها، به مراجعه کنید گسترش.

امروزه Kubeflow در AWS مسیر روشنی را برای استفاده از Kubeflow ارائه می‌کند که با خدمات AWS زیر تکمیل شده است:

بسیاری از مشتریان AWS از Kubeflow در توزیع AWS از جمله athenahealth استفاده می کنند.

در اینجا، تیم athenahealth MLOps در مورد چالش‌هایی که با آن‌ها مواجه شده‌اند و راه‌حل‌هایی که در سفر Kubeflow ایجاد کرده‌اند، بحث می‌کنند.

چالش های محیط ML قبلی

قبل از پذیرش Kubeflow در AWS، دانشمندان داده ما از مجموعه‌ای استاندارد از ابزارها و فرآیندی استفاده می‌کردند که امکان انعطاف‌پذیری در فناوری و گردش کار مورد استفاده برای آموزش یک مدل خاص را فراهم می‌کرد. اجزای نمونه ابزار استاندارد شده عبارتند از یک API هضم داده، ابزارهای اسکن امنیتی، خط لوله CI/CD که توسط تیم دیگری در athenahealth ساخته و نگهداری می‌شود، و یک پلتفرم سرویس مشترک که توسط تیم MLOps ساخته و نگهداری می‌شود. با این حال، همانطور که استفاده ما از هوش مصنوعی و ML بالغ شد، تنوع ابزارها و زیرساخت های ایجاد شده برای هر مدل افزایش یافت. اگرچه ما همچنان قادر به حمایت از روند موجود بودیم، اما شاهد چالش های زیر در افق بودیم:

• نگهداری و رشد - با افزایش تعداد مدل‌های مستقر شده، بازتولید و حفظ محیط‌های آموزشی مدل تلاش بیشتری می‌کرد. هر پروژه مستندات دقیقی داشت که نحوه استفاده از هر اسکریپت برای ساخت مدل نهایی را مشخص می کرد. در بسیاری از موارد، این یک فرآیند پیچیده شامل 5 تا 10 اسکریپت با چندین خروجی بود. اینها باید به صورت دستی با دستورالعمل های دقیق در مورد نحوه استفاده از هر خروجی در فرآیندهای بعدی ردیابی می شدند. حفظ این در طول زمان دست و پا گیر شد. علاوه بر این، با پیچیده‌تر شدن پروژه‌ها، تعداد ابزارها نیز افزایش یافت. برای مثال، بیشتر مدل‌ها از Spark و TensorFlow با GPU استفاده می‌کردند که به تنظیمات محیطی متنوع‌تری نیاز داشت. با گذشت زمان، کاربران به نسخه‌های جدیدتر ابزارها در محیط‌های توسعه خود تغییر می‌دادند، اما وقتی آن نسخه‌ها ناسازگار شدند، نمی‌توانستند اسکریپت‌های قدیمی‌تر را اجرا کنند. در نتیجه، حفظ و تقویت پروژه‌های قدیمی‌تر به زمان و تلاش مهندسی بیشتری نیاز داشت. علاوه بر این، با پیوستن دانشمندان داده جدید به تیم، انتقال دانش و ورود به هواپیما زمان بیشتری می برد، زیرا همگام سازی محیط های محلی شامل بسیاری از وابستگی های غیرمستند می شد. جابجایی بین پروژه ها با مشکلات مشابهی روبرو بود زیرا هر مدل گردش کار خاص خود را داشت.
• دوربین های مداربسته - ما امنیت را جدی می‌گیریم و بنابراین رعایت کلیه تعهدات قراردادی، قانونی و نظارتی مرتبط با ML و علم داده را در اولویت قرار می‌دهیم. داده‌ها باید به روش‌های خاصی مورد استفاده، ذخیره‌سازی و دسترسی قرار گیرند، و ما فرآیندهای قوی را تعبیه کرده‌ایم تا اطمینان حاصل کنیم که شیوه‌هایمان با تعهدات قانونی ما مطابقت دارند و همچنین با بهترین شیوه‌های صنعت همسو هستند. قبل از پذیرش Kubeflow، اطمینان از ذخیره و دسترسی به داده‌ها به روشی خاص مستلزم تأیید منظم در جریان‌های کاری متعدد و متنوع بود. ما می‌دانستیم که می‌توانیم با ادغام این گردش‌های کاری متنوع در یک پلتفرم، کارایی را بهبود بخشیم. با این حال، آن پلتفرم باید به اندازه کافی انعطاف پذیر باشد تا به خوبی با ابزار استاندارد شده ما یکپارچه شود.
• عملیات - ما همچنین فرصتی را برای افزایش کارایی و مدیریت عملیاتی از طریق متمرکز کردن ثبت و نظارت بر گردش کارها دیدیم. از آنجا که هر تیم ابزارهای خود را توسعه داده بود، ما این اطلاعات را از هر گردش کار به صورت جداگانه جمع آوری کرده و آنها را جمع آوری کردیم.

تیم علم داده راه‌حل‌های مختلفی را برای ادغام جریان‌های کاری ارزیابی کرد. علاوه بر پرداختن به این الزامات، ما به دنبال راه حلی بودیم که به طور یکپارچه با زیرساخت ها و ابزارهای استاندارد موجود ادغام شود. ما Amazon EKS و Kubeflow را در AWS به عنوان راه حل گردش کار خود انتخاب کردیم.

چرخه توسعه دانشمند داده با ترکیب Kubeflow

یک پروژه علم داده با یک صفحه تمیز شروع می شود: بدون داده، بدون کد، فقط مشکل تجاری است که می تواند با ML حل شود. اولین کار اثبات مفهوم (POC) برای کشف اینکه آیا داده ها دارای سیگنال کافی برای موثر ساختن یک مدل ML در حل مشکل کسب و کار هستند، با جستجو برای مجموعه داده خام از انبار داده Snowflake ما شروع می شود. این مرحله تکراری است و دانشمندان داده در طول این فرآیند از Kubernetes pods یا Kubeflow Jupyter استفاده می کنند.

خوشه Kubeflow ما از مقیاس‌کننده خودکار خوشه Karpenter استفاده می‌کند، که چرخش منابع را برای دانشمندان داده آسان می‌کند، زیرا آنها فقط باید بر تعریف انواع نمونه‌های مورد نظر تمرکز کنند، در حالی که کار تأمین توسط مجموعه‌ای از تأمین‌کنندگان از پیش تعریف‌شده Karpenter انجام می‌شود. ما ارائه‌دهنده‌های جداگانه‌ای برای انواع نمونه‌های CPU و GPU داریم، و همه نمونه‌هایی که توسط Amazon EKS پشتیبانی می‌شوند، طبق پیکربندی ارائه‌دهنده ما در یکی از این دو دسته قرار می‌گیرند. دانشمندان داده انواع نمونه ها را با استفاده از انتخابگرهای گره انتخاب می کنند و کارپنتر مدیریت چرخه عمر گره را بر عهده می گیرد.

پس از توسعه پرس و جو، دانشمندان داده داده های خام را در مکانی در Amazon S3 استخراج می کنند، سپس یک نوت بوک Jupyter را از رابط کاربری AWS Kubeflow راه اندازی می کنند تا داده ها را بررسی کنند. هدف ایجاد مجموعه ای از ویژگی هایی است که برای آموزش مدل اول استفاده می شود. این به دانشمندان داده اجازه می دهد تا تشخیص دهند که سیگنال کافی در داده ها برای برآورده کردن نیاز تجاری مشتری وجود دارد یا خیر.

پس از رضایت بخش بودن نتایج، دانشمندان داده به مرحله بعدی چرخه توسعه می روند و اکتشافات خود را به یک خط لوله قوی تبدیل می کنند. آنها کد POC را به کد با کیفیت تولید تبدیل می کنند که در مقیاس اجرا می شود. برای اطمینان از انطباق با استفاده از کتابخانه های تایید شده، یک ظرف با تصویر پایه مناسب Docker ایجاد می شود. برای دانشمندان داده ما، ما دریافته‌ایم که ارائه یک تصویر پایه پایتون، تنسورفلو و اسپارک استاندارد، انعطاف‌پذیری کافی را برای اکثر، اگر نه همه، بارهای کاری فراهم می‌کند. سپس می توانند از Dockerfile جزء خود برای سفارشی کردن بیشتر محیط توسعه خود استفاده کنند. این Dockerfile سپس توسط فرآیند CI/CD برای ساختن تصویر اجزایی که در تولید استفاده خواهد شد، استفاده می‌شود، بنابراین سازگاری بین محیط‌های توسعه و تولید حفظ می‌شود.

ما ابزاری داریم که به دانشمندان داده این توانایی را می دهد تا محیط توسعه خود را در یک پاد که در Kubernetes اجرا می شود راه اندازی کنند. هنگامی که این پاد در حال اجرا است، دانشمندان داده می توانند IDE Code Visual Studio را مستقیماً به پاد متصل کرده و کد مدل خود را اشکال زدایی کنند. پس از اجرای موفقیت آمیز کد، می توانند تغییرات خود را به git فشار دهند و یک محیط توسعه جدید با جدیدترین تغییرات ایجاد می شود.

خط لوله استاندارد علم داده شامل مراحلی است که شامل استخراج، پیش پردازش، آموزش و ارزیابی می شود. هر مرحله در خط لوله به‌عنوان یک مؤلفه در Kubeflow ظاهر می‌شود، که از یک غلاف Kubernetes تشکیل شده است که دستوری را با برخی اطلاعات به عنوان پارامتر ارسال می‌کند. این پارامترها می توانند مقادیر ثابت یا ارجاعاتی به خروجی یک جزء قبلی باشند. تصویر Docker مورد استفاده در پاد از فرآیند CI/CD ساخته شده است. جزئیات این فرآیند در گردش کار CI/CD که در بخش بعدی مورد بحث قرار گرفته است ظاهر می شود.

چرخه توسعه در Kubeflow. گردش کار توسعه در سمت چپ با POC شروع می شود. مدل تکمیل شده در پلت فرم سرویس دهی مدل athenahealth که در Amazon ECS اجرا می شود، مستقر شده است.

فرآیند CI/CD پشتیبانی از گردش کار خودکار

به عنوان بخشی از فرآیند CI/CD خود، از جنکینز برای ساخت و آزمایش تمام تصاویر اجزای Kubeflow به صورت موازی استفاده می کنیم. پس از تکمیل موفقیت آمیز، الگوی جزء خط لوله حاوی نشانگرهای مرجع به تصاویر است و خط لوله حاصل در Kubeflow آپلود می شود. پارامترهای موجود در خط لوله جنکینز به کاربران این امکان را می دهد که خطوط لوله را راه اندازی کنند و تست های آموزشی مدل خود را پس از ساخت موفق انجام دهند.

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

ابزار برای اطمینان از استفاده از نشانگرهای مرجع از ساخت CI/CD به طور پیش فرض وجود دارد. اگر مصنوع قابل استقرار در مخزن وجود داشته باشد، منطق CI/CD به استقرار آرتیفکت در پلتفرم سرویس دهی مدل athenahealth (سرویس پیش بینی) که در آمازون ECS اجرا می شود، ادامه می دهد. AWS Fargate. پس از گذراندن تمام این مراحل، دانشمند داده کد را با شاخه اولیه ادغام می کند. خطوط لوله و مصنوعات قابل استقرار سپس به سمت تولید هدایت می شوند.

گردش کار استقرار CI/CD. این نمودار گردش کار ساخت و استقرار علم داده را توصیف می کند. فرآیند CI/CD توسط جنکینز.

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

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

امنیت داده ها

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

برای اطمینان از رعایت استانداردهای انطباق داده ها، زیرساخت AWS خود را مطابق با دستورالعمل های سازمانی athenahealth خود ارائه می کنیم. دو فروشگاه اصلی برای داده‌ها، Amazon RDS برای ابرداده‌های خط لوله بسیار مقیاس‌پذیر و Amazon S3 برای خط لوله و مصنوعات مدل هستند. برای آمازون S3، ما اطمینان می‌دهیم که سطل‌ها رمزگذاری شده‌اند، نقاط پایانی HTTPS اجرا می‌شوند، و خط‌مشی‌های سطل و هویت AWS و مدیریت دسترسی نقش های (IAM) هنگام اجازه دسترسی به داده ها از اصول کمترین امتیاز پیروی می کنند. این برای داده‌های RDS آمازون نیز صادق است: رمزگذاری همیشه فعال است و گروه‌های امنیتی و دسترسی به اعتبار از اصل حداقل امتیاز پیروی می‌کنند. این استانداردسازی تضمین می کند که فقط اشخاص مجاز به داده ها دسترسی دارند و این دسترسی ردیابی می شود.

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

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

برای محدود کردن دسترسی به Amazon S3 و Amazon RDS از داخل Kubeflow در AWS و Amazon EKS، ما از IRSA (IAM Roles for Service Accounts) استفاده می‌کنیم که مجوزهای مبتنی بر IAM را برای منابع در Kubernetes فراهم می‌کند. هر مستاجر در Kubeflow یک حساب خدمات از پیش ایجاد شده منحصر به فرد دارد که ما به یک نقش IAM که به طور خاص برای برآوردن الزامات دسترسی مستاجر ایجاد شده است، متصل می کنیم. دسترسی کاربر به مستاجران نیز با استفاده از عضویت گروه استخرهای کاربر آمازون Cognito برای هر کاربر محدود شده است. هنگامی که یک کاربر در خوشه احراز هویت می شود، توکن تولید شده حاوی ادعاهای گروهی است و Kubernetes RBAC از این اطلاعات برای اجازه یا رد دسترسی به یک منبع خاص در خوشه استفاده می کند. این تنظیمات در بخش بعدی با جزئیات بیشتر توضیح داده شده است.

امنیت خوشه با استفاده از جداسازی چند کاربر

همانطور که در بخش قبل اشاره کردیم، دانشمندان داده تجزیه و تحلیل داده های اکتشافی را انجام می دهند، تجزیه و تحلیل داده ها را اجرا می کنند و مدل های ML را آموزش می دهند. برای تخصیص منابع، سازماندهی داده ها و مدیریت گردش کار بر اساس پروژه ها، Kubeflow در AWS جداسازی را بر اساس فضاهای نام Kubernetes ارائه می دهد. این جداسازی برای تعامل با Kubeflow UI کار می کند. با این حال، هیچ ابزاری برای کنترل دسترسی به API Kubernetes با استفاده از Kubectl ارائه نمی دهد. این بدان معنی است که دسترسی کاربر را می توان در رابط کاربری Kubeflow کنترل کرد، اما نه از طریق Kubectl از طریق Kubernetes API.

معماری شرح داده شده در نمودار زیر با یکپارچه کردن دسترسی به پروژه‌ها در Kubeflow بر اساس عضویت در گروه، به این موضوع می‌پردازد. برای رسیدن به این هدف، ما از Kubeflow در مانیفست‌های AWS استفاده کردیم که با استخرهای کاربر آمازون Cognito ادغام می‌شوند. علاوه بر این، ما از کنترل دسترسی مبتنی بر نقش Kubernetes (RBAC) برای کنترل مجوز در کلاستر استفاده می کنیم. مجوزهای کاربر بر اساس عضویت در گروه آمازون Cognito ارائه شده است. این اطلاعات با توکن تولید شده توسط مشتری OIDC به خوشه ارسال می شود. این فرآیند به لطف قابلیت آمازون EKS داخلی که به ارائه دهندگان هویت OIDC اجازه می دهد تا با خوشه احراز هویت شوند، ساده شده است.

به طور پیش فرض، احراز هویت EKS آمازون توسط احراز هویت IAM انجام می شود، ابزاری که احراز هویت با یک خوشه EKS را با استفاده از اعتبار IAM امکان پذیر می کند. این روش احراز هویت مزایای خود را دارد. با این حال، برای موارد استفاده ما مناسب نیست زیرا athenahealth از Microsoft Azure Active Directory برای سرویس هویت در سراسر سازمان استفاده می کند.

جداسازی فضای نام Kubernetes. دانشمندان داده می توانند عضویت در یک یا چند گروه را در صورت نیاز برای کار خود به دست آورند. دسترسی به طور منظم بررسی می شود و در صورت لزوم حذف می شود.

Azure Active Directory که یک سرویس هویت سازمانی گسترده است، منبع حقیقت برای کنترل دسترسی کاربر به خوشه Kubeflow است. راه‌اندازی برای این کار شامل ایجاد یک Azure Enterprise Application است که به عنوان اصلی سرویس عمل می‌کند و گروه‌هایی را برای مستاجران مختلفی که نیاز به دسترسی به خوشه دارند، اضافه می‌کند. این راه‌اندازی در Azure در آمازون Cognito با راه‌اندازی یک ارائه‌دهنده هویت فدرال OIDC که مسئولیت احراز هویت را به Azure برون‌سپاری می‌کند منعکس شده است. دسترسی به گروه‌های Azure توسط SailPoint IdentityIQ کنترل می‌شود که درخواست‌های دسترسی را به مالک پروژه می‌فرستد تا در صورت لزوم اجازه یا رد شود. در مجموعه کاربران آمازون Cognito، دو کلاینت برنامه ایجاد می‌شود: یکی برای راه‌اندازی احراز هویت برای خوشه Kubernetes با استفاده از ارائه‌دهنده هویت OIDC، و دیگری برای ایمن کردن احراز هویت Kubeflow در رابط کاربری Kubeflow استفاده می‌شود. این کلاینت‌ها برای ارسال ادعاهای گروهی پس از احراز هویت با خوشه پیکربندی شده‌اند، و این ادعاهای گروهی در کنار RBAC برای تنظیم مجوز در خوشه استفاده می‌شوند.

پیوندهای نقش RBAC Kubernetes بین گروه‌ها و نقش خوشه‌ای Kubeflow-edit تنظیم می‌شود که با نصب Kubeflow در خوشه ایجاد می‌شود. این پیوند نقش تضمین می‌کند که هر کاربری که پس از ورود به سیستم از طریق OIDC با خوشه در تعامل است، می‌تواند به فضاهای نامی که برای آنها مجوز دارد، همانطور که در ادعاهای گروه خود تعریف شده است، دسترسی داشته باشد. اگرچه این برای کاربرانی که با استفاده از Kubectl با خوشه تعامل دارند کار می کند، رابط کاربری Kubeflow در حال حاضر دسترسی کاربران را بر اساس عضویت در گروه فراهم نمی کند زیرا از RBAC استفاده نمی کند. در عوض، از منبع Istio Authorization Policy برای کنترل دسترسی کاربران استفاده می کند. برای غلبه بر این چالش، یک کنترل‌کننده سفارشی ایجاد کردیم که کاربران را با نظرسنجی از گروه‌های آمازون Cognito همگام‌سازی می‌کند و پیوندهای نقش مربوطه را برای هر کاربر به جای گروه اضافه یا حذف می‌کند. این راه‌اندازی به کاربران امکان می‌دهد هنگام تعامل با Kubeflow UI و Kubectl از همان سطح مجوز برخوردار باشند.

کارایی عملیات

در این بخش، ما در مورد اینکه چگونه از ابزارهای منبع باز و AWS در دسترس برای مدیریت و اشکال‌زدایی گردش‌های کاری خود و همچنین به حداقل رساندن تأثیر عملیاتی ارتقاء Kubeflow استفاده کردیم، بحث می‌کنیم.

ثبت و نظارت

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

Kubeflow Logging. ما از Grafana UI و Kibana برای مشاهده و غربال کردن لاگ ها استفاده می کنیم

تصویر زیر یک نمای رابط کاربری Kibana از خط لوله ما است.

نمونه نمای رابط کاربری Kibana. Kibana امکان نمایش های سفارشی را فراهم می کند.

ارتقاهای ایمن خوشه Kubeflow

همانطور که کاربران را به Kubeflow در AWS منتقل می کنیم، تجربه کاربری قابل اعتماد و ثابتی را حفظ می کنیم و در عین حال به تیم MLOps اجازه می دهیم با انتشار و ادغام ویژگی های جدید چابک بمانند. در ظاهر، Kustomize برای ما مدولار به نظر می رسد تا کار و ارتقاء یک مؤلفه را در یک زمان بدون تأثیر بر سایر مؤلفه ها امکان پذیر کند، در نتیجه به ما امکان می دهد قابلیت های جدیدی را با کمترین اختلال به کاربران اضافه کنیم. با این حال، در عمل سناریوهایی وجود دارد که در آنها بهترین رویکرد این است که به‌جای اعمال ارتقاء سطح مؤلفه برای خوشه‌های موجود، صرفاً یک خوشه جدید Kubernetes را بچرخانید. ما دو مورد استفاده پیدا کردیم که در آن ایجاد خوشه های کاملاً جدید منطقی تر بود:

• ارتقاء به نسخه Kubernetes که در آن AWS ارتقاء کلاستر را در محل ارائه می دهد. با این حال، آزمایش اینکه آیا هر یک از منابع Kubeflow و Kubernetes مطابق با هدف کار می کنند و مانیفست ها سازگاری عقب مانده را حفظ می کنند، دشوار می شود.
• ارتقاء Kubeflow به نسخه جدیدتر که در آن چندین ویژگی اضافه یا اصلاح شده است و تقریباً همیشه انجام ارتقاء در محل در یک خوشه Kubernetes موجود ایده امیدوارکننده ای نیست.

در پرداختن به این موضوع، ما یک استراتژی توسعه دادیم که ما را قادر می‌سازد تا جایگزین‌های خوشه ای ایمن را بدون تأثیر بر حجم کاری موجود داشته باشیم. برای رسیدن به این هدف، باید معیارهای زیر را رعایت می کردیم:

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

نمودار زیر این معماری را نشان می دهد.

ارتقا ایمن خوشه Kubeflow. هنگامی که تست Kubeflow Candidate موفقیت آمیز بود، از طریق به روز رسانی به Route 53 به Kubeflow Prod ارتقا می یابد.

Kubeflow در مانیفست‌های AWS با ادغام‌های Amazon RDS و Amazon S3 از پیش بسته‌بندی شده است. با این سرویس‌های مدیریت‌شده که به‌عنوان ذخیره‌سازی داده‌های رایج عمل می‌کنند، می‌توانیم یک استراتژی استقرار سبز-آبی تنظیم کنیم. برای دستیابی به این هدف، ما اطمینان حاصل کردیم که ابرداده خط لوله در Amazon RDS، که مستقل از خوشه EKS کار می‌کند، و لاگ‌ها و مصنوعات خط لوله در Amazon S3 باقی می‌مانند. علاوه بر ابرداده‌های خط لوله و مصنوعات، ما همچنین FluentD را برای مسیریابی گزارش‌های غلاف به سرویس جستجوی باز آمازون راه‌اندازی کردیم.

این تضمین می کند که لایه ذخیره سازی کاملاً از لایه محاسباتی جدا شده است و در نتیجه آزمایش تغییرات در طول به روز رسانی نسخه Kubeflow در یک خوشه کاملاً جدید EKS را امکان پذیر می کند. پس از موفقیت آمیز بودن تمام آزمایشات، می توانیم به سادگی آن را تغییر دهیم مسیر آمازون 53 رکورد DNS به خوشه نامزد میزبان Kubeflow. همچنین، خوشه قدیمی را برای چند روز به عنوان پشتیبان در حال اجرا نگه می‌داریم تا در صورت نیاز به عقب برگردیم.

مزایای Amazon EKS و Kubeflow در AWS برای خط لوله ML ما

Amazon EKS و بسته Kubeflow on AWS گردش کار توسعه ما را به الگویی منتقل کردند که قویاً آموزش مدل های تکرارپذیر را تشویق می کند. این ابزارها به ما این امکان را می دهند که خوشه های کاملاً تعریف شده با مستاجران کاملاً تعریف شده داشته باشیم و کدهای کاملاً تعریف شده را اجرا کنیم.

تعداد زیادی از بردهای حاصل از ساخت این پلتفرم کمی کمتر است و بیشتر به نحوه بهبود گردش کار برای توسعه دهندگان و کاربران پلتفرم مربوط می شود. به عنوان مثال، MinIO با دسترسی مستقیم به Amazon S3 جایگزین شد، که ما را به گردش کار اصلی خود نزدیک‌تر می‌کند و تعداد سرویس‌هایی را که باید حفظ کنیم، کاهش می‌دهد. ما همچنین می‌توانیم از Amazon RDS به‌عنوان پشتیبان برای Kubeflow استفاده کنیم، که مهاجرت آسان‌تر بین خوشه‌ها را امکان‌پذیر می‌کند و به ما توانایی پشتیبان‌گیری از خطوط لوله خود را در شب می‌دهد.

ما همچنین بهبودهایی را در ادغام Kubeflow با خدمات مدیریت شده AWS مفید یافتیم. به عنوان مثال، با آمازون RDS، Amazon S3 و Amazon Cognito که از قبل در مانیفست های Kubeflow در AWS پیکربندی شده اند، در زمان و تلاش برای به روز رسانی به توزیع های جدیدتر Kubeflow صرفه جویی می کنیم. زمانی که ما مانیفست رسمی Kubeflow را به صورت دستی اصلاح می‌کردیم، به‌روزرسانی به نسخه جدید از طراحی تا آزمایش چندین هفته طول می‌کشید.

تغییر به Amazon EKS این فرصت را به ما می دهد تا خوشه خود را در Kustomize (اکنون بخشی از Kubectl) و Terraform تعریف کنیم. به نظر می رسد که برای کار با پلت فرم، پس از صرف زمان کافی برای یادگیری، کار با Kubernetes و Terraform بسیار آسان است. پس از تکرارهای زیاد، ابزارهای در دسترس ما انجام عملیات استاندارد پلتفرم مانند ارتقاء یک جزء یا تعویض کل خوشه توسعه را بسیار آسان می کند. در مقایسه با اجرای مشاغل خام ابر محاسبه الاستیک آمازون در نمونه‌های (Amazon EC2)، مقایسه تفاوت فاحش وجود غلاف‌های کاملاً تعریف‌شده با پاک‌سازی منابع تضمین‌شده و مکانیسم‌های امتحان مجدد سخت است.

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

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

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

در نهایت، به دلیل اینکه فرآیندی را برای اضافه کردن مستاجران به خوشه ایجاد کردیم، اکنون روش رسمی تری برای ثبت نام تیم ها به مستاجر در خوشه وجود دارد. از آنجایی که ما از Kubecost برای ردیابی هزینه‌ها در خوشه EKS خود استفاده می‌کنیم، به ما این امکان را می‌دهد که هزینه را به یک پروژه واحد نسبت دهیم نه اینکه هزینه نسبت داده شود در سطح حساب، که شامل همه پروژه‌های علم داده می‌شود. Kubecost گزارشی از پول خرج شده برای هر فضای نام ارائه می‌کند، که به طور محکم با مستاجر یا تیمی که مسئول اجرای خط لوله است، مرتبط است.

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

نتیجه

با اجرای خط لوله Kubeflow در خط لوله AWS در زیرساخت ML سرتاسر ما، ما توانستیم جریان های کاری علم داده خود را با حفظ ابزار ضروری خود (مانند CI/CD و سرویس مدل) ادغام و استاندارد کنیم. دانشمندان داده ما اکنون می توانند بین پروژه ها بر اساس این گردش کار حرکت کنند، بدون اینکه سربار یاد بگیرند که چگونه یک مجموعه ابزار کاملاً متفاوت را حفظ کنند. برای برخی از مدل‌هایمان، ما همچنین از سرعت گردش کار جدید (پنج برابر سریع‌تر) شگفت‌زده شدیم، که امکان تکرارهای آموزشی بیشتر و در نتیجه تولید مدل‌هایی با پیش‌بینی‌های بهتر را فراهم کرد.

ما همچنین پایه محکمی برای افزایش قابلیت‌های MLOps و مقیاس‌بندی تعداد و اندازه پروژه‌هایمان ایجاد کرده‌ایم. به عنوان مثال، همانطور که وضعیت حاکمیت خود را در اصل و نسب مدل و ردیابی سخت تر می کنیم، تمرکز خود را از بیش از 15 گردش کار به تنها یک گردش کاهش داده ایم. و هنگامی که آسیب‌پذیری Log4shell در اواخر سال 2021 آشکار شد، ما توانستیم بر روی یک گردش کار تمرکز کنیم و در صورت نیاز به سرعت آن را اصلاح کنیم. رجیستری ظروف الاستیک آمازون اسکن (Amazon ECR)، ارتقاء سرویس جستجوی باز آمازون، به روز رسانی ابزارهای ما، و موارد دیگر) با کمترین تأثیر بر کار در حال انجام توسط دانشمندان داده. با در دسترس قرار گرفتن پیشرفت‌های AWS و Kubeflow، می‌توانیم آن‌ها را به دلخواه خود اضافه کنیم.

این ما را به یک جنبه مهم و کم بیان از Kubeflow ما در پذیرش AWS می رساند. یکی از نتایج حیاتی این سفر، توانایی ارائه به‌روزرسانی‌ها و پیشرفت‌ها در Kubeflow به طور یکپارچه برای دانشمندان داده ما است. اگرچه ما رویکرد خود را در مورد این موضوع قبلاً مورد بحث قرار دادیم، ما همچنین به مانیفست های Kubeflow ارائه شده توسط AWS تکیه می کنیم. ما سفر Kubeflow خود را به عنوان اثبات مفهوم در سال 2019، قبل از انتشار نسخه 1.0.0 آغاز کردیم. (ما در حال حاضر در نسخه 1.4.1 هستیم و نسخه 1.5 را ارزیابی می کنیم. AWS در حال حاضر روی نسخه 1.6 کار می کند.) در 3 سال گذشته، حداقل شش نسخه با محتوای قابل توجه منتشر شده است. تیم Kubeflow در AWS از طریق رویکرد منضبط خود برای یکپارچه‌سازی و اعتبارسنجی این ارتقاها و انتشار مانیفست‌ها در یک زمان‌بندی قابل پیش‌بینی و قابل اعتماد، در قادر ساختن تیم athenahealth MLOps برای برنامه‌ریزی نقشه راه توسعه ما، و در نتیجه تخصیص منابع و حوزه‌های تمرکز ما بسیار مهم بوده است. ، با اطمینان بیشتر به آینده بروید.

شما می توانید از مخزن AWS Labs GitHub برای ردیابی تمام مشارکت های AWS به Kubeflow. همچنین می‌توانید تیم‌های AWS را در آن پیدا کنید Kubeflow #AWS Slack Channel; بازخورد شما در آنجا به AWS کمک می کند تا ویژگی های بعدی را برای مشارکت در پروژه Kubeflow اولویت بندی کند.

---

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

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

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

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

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

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

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