בנו זרימות עבודה של למידה חישובית מקצה לקצה הניתנים לחזרה, מאובטחת וניתנת להרחבה באמצעות Kubeflow ב-AWS

זהו פוסט בבלוג אורח שנכתב יחד עם athenahealth.

אתונה בריאות ספקית מובילה של תוכנות ושירותים התומכים ברשת לקבוצות רפואיות ומערכות בריאות בפריסה ארצית. רישומי הבריאות האלקטרוניים שלה, ניהול מחזור ההכנסות וכלי המעורבות של המטופלים מאפשרים גישה בכל זמן ובכל מקום, מניבים תוצאות פיננסיות טובות יותר ללקוחותיה ומאפשרים ללקוחות הספקים שלה לספק טיפול איכותי יותר.

בתחום הבינה המלאכותית (AI), athenahealth משתמשת במדעי נתונים ולמידת מכונה (ML) כדי להאיץ תהליכים עסקיים ולספק המלצות, תחזיות ותובנות במגוון שירותים. מהטמעתה הראשונה בשירותי מסמכים אוטומטיים, עיבוד ללא מגע של מיליוני מסמכי ספק-מטופל, ועד לעבודתה העדכנית יותר בעוזרים וירטואליים ושיפור ביצועי מחזור ההכנסות, athenahealth ממשיכה ליישם בינה מלאכותית כדי לסייע ביעילות, יכולות שירות ותוצאות טובות יותר עבור ספקים והמטופלים שלהם.

פוסט זה בבלוג מדגים כיצד אתנה-בריאות משתמשת Kubeflow ב-AWS (הפצה ספציפית ל-AWS של Kubeflow) כדי לבנות ולייעל זרימת עבודה במדעי הנתונים מקצה לקצה, המשמרת כלי עבודה חיוניים, מייעלת את היעילות התפעולית, מגבירה את הפרודוקטיביות של מדעני הנתונים ומתווה את השלב להרחבת יכולות ה-ML שלהם בקלות רבה יותר.

Kubeflow היא פלטפורמת ML בקוד פתוח המוקדשת להפיכת פריסות של זרימות עבודה של ML ב-Kubernetes לפשוטות, ניידות וניתנות להרחבה. Kubeflow משיגה זאת על ידי שילוב כלי קוד פתוח רלוונטיים המשתלבים היטב עם Kubernetes. חלק מהפרויקטים הללו כוללים את ארגו לתזמור צינורות, Istio לרשת שירות, Jupyter למחברות, Spark, TensorBoard ו-Katib. Kubeflow Pipelines עוזר לבנות ולפרוס זרימות עבודה ML ניידות וניתנות להרחבה שיכולות לכלול שלבים כמו מיצוי נתונים, עיבוד מקדים, אימון מודלים והערכת מודלים בצורה של צינורות שניתן לחזור עליהם.

AWS תורמת לקהילת הקוד הפתוח של Kubeflow על ידי מתן הפצת Kubeflow משלה (הנקראת Kubeflow ב-AWS) המסייעת לארגונים כמו athenahealth לבנות זרימות עבודה ML אמינות, מאובטחות, ניידות וניתנות להרחבה עם תקורה תפעולית מופחתת באמצעות אינטגרציה עם שירותים מנוהלים של AWS. AWS מספקת אפשרויות פריסה שונות של Kubeflow כמו פריסה עם אמזון קוגניטו, פריסה עם שירות מסדי נתונים יחסי של אמזון (אמזון RDS) ו- שירות אחסון פשוט של אמזון (Amazon S3), ופריסה וניל. לפרטים על שילוב שירות ותוספות זמינות עבור כל אחת מהאפשרויות הללו, עיין ב פְּרִיסָה.

כיום, Kubeflow ב-AWS מספקת נתיב ברור לשימוש ב-Kubeflow, מתוגבר עם שירותי ה-AWS הבאים:

לקוחות AWS רבים מנצלים את ה-Kubeflow על הפצת AWS, כולל athenahealth.

כאן, צוות MLOps של athenahealth דן באתגרים שהם נתקלו בהם ובפתרונות שהם יצרו במסע ה-Kubeflow שלהם.

אתגרים עם סביבת ה-ML הקודמת

לפני האימוץ שלנו של Kubeflow ב-AWS, מדעני הנתונים שלנו השתמשו בסט סטנדרטי של כלים ובתהליך שאפשרו גמישות בטכנולוגיה ובזרימת העבודה המשמשת להכשרת מודל נתון. רכיבים לדוגמה של הכלים הסטנדרטיים כוללים API להטמעת נתונים, כלי סריקת אבטחה, צינור ה-CI/CD שנבנה ומתוחזק על ידי צוות אחר בתוך athenahealth, ופלטפורמת הגשה משותפת שנבנתה ומתוחזקת על ידי צוות MLOps. עם זאת, ככל שהשימוש שלנו ב-AI ו-ML התבגר, מגוון הכלים והתשתיות שנוצרו עבור כל דגם גדל. למרות שעדיין הצלחנו לתמוך בתהליך הקיים, ראינו את האתגרים הבאים באופק:

• תחזוקה וצמיחה - שחזור ותחזוקה של סביבות אימון מודל לקח יותר מאמץ ככל שמספר הדגמים הפרוסים גדל. כל פרויקט שמר על תיעוד מפורט שמתאר כיצד נעשה שימוש בכל סקריפט לבניית המודל הסופי. במקרים רבים, זה היה תהליך משוכלל שכלל 5 עד 10 סקריפטים עם כמה פלטים כל אחד. היה צורך לעקוב אחר אלה באופן ידני עם הוראות מפורטות כיצד ישמש כל פלט בתהליכים הבאים. השמירה על זה לאורך זמן הפכה למסורבלת. יתרה מכך, ככל שהפרויקטים הפכו מורכבים יותר, גדל גם מספר הכלים. לדוגמה, רוב הדגמים השתמשו ב-Spark ו-TensorFlow עם GPUs, שדרשו מגוון גדול יותר של תצורות סביבה. עם הזמן, המשתמשים היו עוברים לגרסאות חדשות יותר של כלים בסביבות הפיתוח שלהם, אך לאחר מכן לא יכלו להריץ סקריפטים ישנים יותר כאשר גרסאות אלו הפכו לבלתי תואמות. כתוצאה מכך, תחזוקה והגדלה של פרויקטים ישנים דרשו יותר זמן ומאמץ הנדסי. בנוסף, ככל שמדעני נתונים חדשים הצטרפו לצוות, העברת הידע וההטמעה לקחו יותר זמן, מכיוון שסנכרון סביבות מקומיות כלל הרבה תלות לא מתועדת. מעבר בין פרויקטים נתקל באותן בעיות מכיוון שלכל דגם היו זרימות עבודה משלו.
• אבטחה – אנו מתייחסים לאבטחה ברצינות, ולכן נותנים עדיפות לעמידה בכל החובות החוזיות, החוקיות והרגולטוריות הקשורות ל-ML ולמדעי הנתונים. יש להשתמש בנתונים, לאחסן אותם ולגשת אליהם בדרכים ספציפיות, והטמענו תהליכים חזקים כדי להבטיח שהשיטות שלנו עומדות בהתחייבויות החוקיות שלנו וכן מתאימות לשיטות העבודה המומלצות בתעשייה. לפני אימוץ Kubeflow, הבטחה שהנתונים יאוחסנו והגישה אליהם בצורה ספציפית כללה אימות קבוע על פני זרימות עבודה מרובות ומגוונות. ידענו שנוכל לשפר את היעילות על ידי איחוד זרימות העבודה המגוונות הללו על גבי פלטפורמה אחת. עם זאת, הפלטפורמה הזו תצטרך להיות גמישה מספיק כדי להשתלב היטב עם הכלים הסטנדרטיים שלנו.
• תפעול – ראינו גם הזדמנות להגביר את היעילות התפעולית והניהול באמצעות ריכוז הרישום והניטור של זרימות העבודה. מכיוון שכל צוות פיתח כלים משלו, אספנו את המידע הזה מכל זרימת עבודה בנפרד ואספנו אותם.

צוות מדעי הנתונים העריך פתרונות שונים לאיחוד זרימות העבודה. בנוסף למתן מענה לדרישות אלו, חיפשנו פתרון שישתלב בצורה חלקה עם התשתית והכלים הסטנדרטיים הקיימים. בחרנו באמזון EKS וב-Kubeflow ב-AWS כפתרון זרימת העבודה שלנו.

מחזור הפיתוח של מדעני הנתונים המשלב Kubeflow

פרויקט מדעי נתונים מתחיל עם לוח נקי: ללא נתונים, ללא קוד, רק הבעיה העסקית שניתן לפתור עם ML. המשימה הראשונה היא הוכחת קונספט (POC) כדי לגלות אם הנתונים מכילים מספיק אות כדי להפוך מודל ML ליעיל בפתרון הבעיה העסקית, החל בשאילתה עבור מערך הנתונים הגולמי ממחסן הנתונים Snowflake שלנו. שלב זה הוא איטרטיבי, ומדעני הנתונים משתמשים בתרמילים של Kubernetes או במחברות Kubeflow Jupyter במהלך תהליך זה.

אשכול Kubeflow שלנו משתמש ב-Karpenter cluster autoscaler, מה שמקל על יצירת משאבים עבור מדעני נתונים מכיוון שהם צריכים להתמקד רק בהגדרת סוגי המופעים הרצויים, בעוד שעבודת ההקצאה נעשית על ידי קבוצה של ספקי Karpenter מוגדרים מראש. יש לנו אספקה ​​נפרדת לסוגי מופעי CPU ו-GPU, וכל המופעים הנתמכים על ידי Amazon EKS נכנסים לאחת משתי הקטגוריות הללו לפי תצורת הספק שלנו. מדעני הנתונים בוחרים סוגי מופעים באמצעות בוררי צמתים, וקרפנטר דואגת לניהול מחזור חיי הצומת.

לאחר פיתוח השאילתה, מדעני הנתונים מחלצים את הנתונים הגולמיים למיקום ב-Amazon S3, ואז משיקים מחברת Jupyter מממשק המשתמש של AWS Kubeflow כדי לחקור את הנתונים. המטרה היא ליצור את ערכת התכונות שתשמש לאימון הדגם הראשון. זה מאפשר למדעני הנתונים לקבוע אם יש מספיק אות בנתונים כדי למלא את הצורך העסקי של הלקוח.

לאחר שהתוצאות משביעות רצון, מדעני הנתונים עוברים לשלב הבא של מחזור הפיתוח והופכים את התגליות שלהם לצינור חזק. הם ממירים את קוד POC לקוד באיכות ייצור הפועל בקנה מידה. כדי להבטיח תאימות באמצעות ספריות מאושרות, נוצר מיכל עם תמונת הבסיס המתאימה של Docker. עבור מדעני הנתונים שלנו, גילינו שמתן תמונת בסיס Python, TensorFlow ו-Spark סטנדרטית מספקת גמישות מספקת עבור רוב עומסי העבודה, אם לא כולם. לאחר מכן הם יכולים להשתמש ב- Dockerfile של הרכיב שלהם כדי להתאים אישית את סביבת הפיתוח שלהם. Dockerfile זה מנוצל לאחר מכן על ידי תהליך ה-CI/CD כדי לבנות את תמונת הרכיבים שתשמש בייצור, ולכן שומר על עקביות בין סביבות הפיתוח והייצור.

יש לנו כלי שנותן למדעני נתונים את היכולת להשיק את סביבת הפיתוח שלהם בפוד הפועל על Kubernetes. כאשר הפוד הזה פועל, מדעני הנתונים יכולים לצרף את ה-Visual Studio Code IDE ישירות לתרמיל ולאפות באגים בקוד הדגם שלהם. לאחר שהקוד פועל בהצלחה, הם יכולים לדחוף את השינויים שלהם ל-git ונוצרת סביבת פיתוח חדשה עם השינויים האחרונים.

צינור מדעי הנתונים הסטנדרטי מורכב משלבים הכוללים מיצוי, עיבוד מקדים, הדרכה והערכה. כל שלב בצנרת מופיע כרכיב ב-Kubeflow, המורכב מפוד של Kubernetes המריץ פקודה עם מידע מסוים שמועבר כפרמטרים. פרמטרים אלה יכולים להיות ערכים סטטיים או הפניות לפלט מרכיב קודם. תמונת Docker המשמשת בפוד בנויה מתהליך ה-CI/CD. פרטים על תהליך זה מופיעים בזרימת העבודה של CI/CD הנדונה בסעיף הבא.

מחזור פיתוח ב-Kubeflow. זרימת העבודה של הפיתוח מתחילה משמאל עם ה-POC. המודל שהושלם נפרס לפלטפורמת השירות של מודל athenahealth הפועלת ב- Amazon ECS.

תהליך CI/CD התומך בזרימות עבודה אוטומטיות

כחלק מתהליך ה-CI/CD שלנו, אנו משתמשים בג'נקינס כדי לבנות ולבדוק את כל התמונות של רכיבי Kubeflow במקביל. בסיום מוצלח, תבנית רכיב הצינור מכילה מצביעי התייחסות לתמונות, והצינור המתקבל מועלה ל-Kubeflow. פרמטרים בצנרת של Jenkins מאפשרים למשתמשים להשיק את הצינורות ולהריץ את מבחני הכשרת המודל שלהם לאחר בנייה מוצלחת.

לחלופין, כדי לשמור על מחזור פיתוח קצר, מדעני נתונים יכולים גם להשיק את הצינור מהמכונה המקומית שלהם, ולשנות את כל פרמטרי הצינור שהם עשויים להתנסות בהם.

קיים כלים כדי להבטיח שמצביעי ההתייחסות ממבנה ה-CI/CD מנוצלים כברירת מחדל. אם יש חפץ בר-פריסה ב-repo, אזי ההיגיון של CI/CD ימשיך לפרוס את החפץ לפלטפורמת ההגשה של מודל athenahealth (שירות החיזוי) הפועל ב- Amazon ECS עם AWS פרגייט. לאחר שכל השלבים הללו חלפו, מדען הנתונים ממזג את הקוד לענף הראשי. לאחר מכן, הצינורות והחפצים הניתנים לפריסה נדחפים לייצור.

זרימת עבודה של פריסת CI/CD. תרשים זה מתאר את תהליך הבנייה והפריסה של Data Science. תהליך ה-CI/CD מונע על ידי ג'נקינס.

אבטחה

באיחוד תהליכי העבודה שלנו במדעי הנתונים, הצלחנו לרכז את הגישה שלנו לאבטחת צינור ההדרכה. בחלק זה, אנו דנים בגישה שלנו לאבטחת נתונים ואשכולות.

אבטחת מידע

אבטחת מידע היא בעלת חשיבות עליונה ב-athenehealth. מסיבה זו, אנו מפתחים ומתחזקים תשתית התואמת באופן מלא את התקנות והתקנים המגינים על האבטחה והשלמות של נתונים אלו.

כדי להבטיח שאנו עומדים בתקני עמידה בנתונים, אנו מספקים את תשתית ה-AWS שלנו בהתאם להנחיות הארגון שלנו ב-athenehealth. שני המאגרים העיקריים לנתונים הם Amazon RDS עבור מטא נתונים ניתנים להרחבה של צינורות ואמזון S3 עבור חפצי צינור ומודל. עבור Amazon S3, אנו מבטיחים שהדליים מוצפנים, נקודות הקצה של HTTPS נאכפות, ומדיניות הדלי AWS זהות וניהול גישה תפקידי (IAM) פועלים לפי העקרונות של הרשאות הפחותות כאשר מתירים גישה לנתונים. זה נכון גם לנתוני אמזון RDS: ההצפנה תמיד מופעלת, וקבוצות האבטחה והגישה לאישורים פועלים לפי עקרון המינימום הרשאות. סטנדרטיזציה זו מבטיחה שרק לגורמים מורשים תהיה גישה לנתונים, ומעקב אחר גישה זו.

בנוסף לאמצעים אלו, הפלטפורמה עוברת גם הערכות איומי אבטחה וסריקות אבטחה ותאימות מתמשכות.

אנו מתייחסים גם לדרישות שמירת הנתונים באמצעות ניהול מחזור חיים של נתונים עבור כל דלי S3 המכילים נתונים רגישים. מדיניות זו מעבירה נתונים אוטומטית אל קרחון S3 של אמזון לאחר 30 יום מהיצירה. חריגים לכך מנוהלים באמצעות בקשות לאחזור נתונים ומאושרות או נדחות על בסיס כל מקרה לגופו. זה מבטיח שכל זרימות העבודה תואמות למדיניות שמירת הנתונים. זה גם פותר את הבעיה עם שחזור נתונים אם מודל מתפקד בצורה גרועה, ונדרשת אימון מחדש, או כאשר יש להעריך מודל חדש מול איטרציה היסטורית של מערך הנתונים של מודל ישן יותר.

להגבלת הגישה לאמזון S3 ולאמזון RDS מתוך Kubeflow ב-AWS ו-Amazon EKS, אנו משתמשים ב-IRSA (IAM Roles for Service Accounts), המספקת הרשאות מבוססות IAM עבור משאבים בתוך Kubernetes. לכל דייר ב-Kubeflow יש חשבון שירות ייחודי שנוצר מראש, אותו אנו קושרים לתפקיד IAM שנוצר במיוחד כדי למלא את דרישות הגישה לדייר. גישת משתמשים לדיירים מוגבלת גם באמצעות החברות בקבוצת מאגרי המשתמשים של Amazon Cognito עבור כל משתמש. כאשר משתמש מאומת לאשכול, האסימון שנוצר מכיל תביעות קבוצתיות, ו-Kubernetes RBAC משתמש במידע זה כדי לאפשר או לשלול גישה למשאב מסוים באשכול. הגדרה זו מוסברת ביתר פירוט בסעיף הבא.

אבטחת אשכולות באמצעות בידוד מרובה משתמשים

כפי שציינו בסעיף הקודם, מדעני נתונים מבצעים ניתוח נתונים חקרניים, מפעילים ניתוח נתונים ומאמנים מודלים של ML. כדי להקצות משאבים, לארגן נתונים ולנהל זרימות עבודה על סמך פרויקטים, Kubeflow ב-AWS מספקת בידוד המבוסס על מרחבי שמות של Kubernetes. בידוד זה פועל לאינטראקציה עם ממשק המשתמש של Kubeflow; עם זאת, הוא אינו מספק כל כלי לשלוט בגישה ל-Kubernetes API באמצעות Kubectl. משמעות הדבר היא שניתן לשלוט בגישת המשתמש בממשק המשתמש של Kubeflow אך לא דרך ה-API של Kubernetes באמצעות Kubectl.

הארכיטקטורה המתוארת בתרשים הבא מטפלת בבעיה זו על ידי איחוד גישה לפרויקטים ב-Kubeflow בהתבסס על חברות בקבוצה. כדי להשיג זאת, ניצלנו את המניפסטים של Kubeflow ב-AWS, שיש להם אינטגרציה עם מאגרי המשתמשים של Amazon Cognito. בנוסף, אנו משתמשים בקרת גישה מבוססת תפקידים של Kubernetes (RBAC) כדי לשלוט בהרשאות בתוך האשכול. הרשאות המשתמש ניתנות על סמך חברות בקבוצת אמזון קוגניטו. מידע זה מועבר לאשכול עם האסימון שנוצר על ידי לקוח OIDC. תהליך זה מפושט בזכות הפונקציונליות המובנית של Amazon EKS המאפשרת לשייך לספקי זהות של OIDC לבצע אימות עם האשכול.

כברירת מחדל, אימות EKS של אמזון מבוצע על ידי המאמת IAM, שהוא כלי המאפשר אימות עם אשכול EKS באמצעות אישורי IAM. לשיטת אימות זו יש יתרונות; עם זאת, זה לא מתאים למקרה השימוש שלנו מכיוון ש-athenahealth משתמש ב-Microsoft Azure Active Directory לשירות זהות ברחבי הארגון.

בידוד מרחב השמות של Kubernetes. מדעני נתונים יכולים להשיג חברות בקבוצות בודדות או מרובות לפי הצורך לעבודתם. הגישה נבדקת על בסיס קבוע ומוסרת בהתאם.

Azure Active Directory, בהיותו שירות זהות כלל ארגוני, הוא מקור האמת לשליטה בגישה של משתמשים לאשכול Kubeflow. ההגדרה לכך כוללת יצירת אפליקציית Azure Enterprise המשמשת כמנהלת שירות והוספת קבוצות לדיירים שונים הדורשים גישה לאשכול. הגדרה זו ב-Azure משתקפת ב-Amazon Cognito על ידי הגדרת ספק זהות OIDC מאוחד המעביר את אחריות האימות למיקור חוץ ל-Azure. הגישה לקבוצות Azure נשלטת על ידי SailPoint IdentityIQ, אשר שולחת בקשות גישה לבעל הפרויקט כדי לאפשר או לדחות בהתאם. במאגר המשתמשים של Amazon Cognito, נוצרים שני לקוחות יישומים: האחד משמש להגדרת האימות עבור אשכול Kubernetes באמצעות ספק הזהות OIDC, והשני לאבטחת אימות Kubeflow לתוך ממשק המשתמש של Kubeflow. לקוחות אלה מוגדרים להעביר תביעות קבוצתיות עם אימות עם האשכול, ותביעות קבוצתיות אלו משמשות לצד RBAC כדי להגדיר הרשאות בתוך האשכול.

כריכות תפקידים של Kubernetes RBAC מוגדרות בין קבוצות לבין תפקיד האשכול Kubeflow-edit, שנוצר עם התקנת Kubeflow באשכול. קשירת תפקידים זו מבטיחה שכל משתמש המקיים אינטראקציה עם האשכול לאחר התחברות דרך OIDC יכול לגשת למרחבי השמות שיש להם הרשאות עבורם כפי שהוגדרו בתביעות הקבוצה שלו. למרות שזה עובד עבור משתמשים המקיימים אינטראקציה עם האשכול באמצעות Kubectl, ממשק המשתמש של Kubeflow אינו מספק כרגע גישה למשתמשים על סמך חברות בקבוצה מכיוון שהוא אינו משתמש ב-RBAC. במקום זאת, הוא משתמש במשאב ה-Istio Authorization Policy כדי לשלוט בגישה למשתמשים. כדי להתגבר על האתגר הזה, פיתחנו בקר מותאם אישית שמסנכרן משתמשים על ידי סקר קבוצות אמזון קוגניטו ומוסיף או מסיר כריכות תפקידים מתאימות לכל משתמש ולא לפי קבוצה. הגדרה זו מאפשרת למשתמשים לקבל את אותה רמת הרשאות בעת אינטראקציה הן עם ממשק המשתמש של Kubeflow והן עם Kubectl.

יעילות תפעולית

בסעיף זה, אנו דנים כיצד ניצלנו את כלי הקוד הפתוח וה-AWS הזמינים לנו לניהול וניפוי באגים של זרימות העבודה שלנו וכן כדי למזער את ההשפעה התפעולית של שדרוג Kubeflow.

רישום וניטור

עבור רישום, אנו משתמשים ב- FluentD כדי לדחוף את כל יומני המכולה שלנו שירות חיפוש פתוח של אמזון ומדדי מערכת לפרומתאוס. לאחר מכן אנו משתמשים ב-Kibana ובממשק המשתמש של Grafana לחיפוש וסינון יומנים ומדדים. התרשים הבא מתאר כיצד אנו מגדירים זאת.

רישום Kubeflow. אנו משתמשים גם בממשק המשתמש של Grafana וגם ב-Kibana כדי להציג ולסנן את היומנים

צילום המסך הבא הוא תצוגת ממשק משתמש של Kibana מהצינור שלנו.

תצוגת ממשק המשתמש של Kibana לדוגמה. Kibana מאפשר תצוגות מותאמות אישית.

שדרוגי אשכול Kubeflow בטוח

כאשר אנו מצטרפים משתמשים ל-Kubeflow ב-AWS, אנו שומרים על חווית משתמש אמינה ועקבית תוך מתן אפשרות לצוות MLOps להישאר זריז עם שחרור ושילוב תכונות חדשות. על פני השטח, Kustomize נראה מודולרי עבורנו כדי לאפשר עבודה ושדרוג של רכיב אחד בכל פעם מבלי להשפיע על אחרים, ובכך לאפשר לנו להוסיף יכולות חדשות עם מינימום הפרעה למשתמשים. עם זאת, בפועל ישנם תרחישים שבהם הגישה הטובה ביותר היא פשוט ליצור אשכול Kubernetes חדש במקום להחיל שדרוגים ברמת הרכיב עבור אשכולות קיימים. מצאנו שני מקרי שימוש שבהם היה הגיוני יותר ליצור אשכולות חדשים לחלוטין:

• שדרוג לגרסת Kubernetes שבה AWS אכן מספקת שדרוגי אשכול במקום. עם זאת, קשה לבדוק אם כל אחד ממשאבי Kubeflow ו-Kubernetes פועל כמתוכנן והמניפסטים שומרים על תאימות לאחור.
• שדרוג Kubeflow למהדורה חדשה יותר שבה יש מספר תכונות שנוספו או השתנו וכמעט תמיד זה לא רעיון מבטיח לבצע שדרוגים במקום על אשכול Kubernetes קיים.

בטיפול בבעיה זו, פיתחנו אסטרטגיה המאפשרת לנו החלפת אשכולות בטוחים מבלי להשפיע על עומסי העבודה הקיימים. כדי להשיג זאת, היינו צריכים לעמוד בקריטריונים הבאים:

• הפרד את משאבי האחסון והמחשוב של Kubeflow כך שמטא נתונים של הצינור, חפצי הצינור ונתוני המשתמש יישמרו בעת ביטול התצורה של האשכול הישן יותר
• שילוב עם Kubeflow במניפסטים של AWS כך שכאשר מתרחש שדרוג גרסת Kubeflow, נדרשים שינויים מינימליים
• יש לך דרך קלה לחזור אחורה אם דברים משתבשים לאחר שדרוג האשכולות
• יש ממשק פשוט לקידום אשכול מועמדים לייצור

התרשים הבא ממחיש ארכיטקטורה זו.

שדרוג אשכולות Kubeflow בטוח. לאחר שהבדיקה של המועמד Kubeflow מצליחה, הוא מקודם ל-Kubeflow Prod באמצעות עדכון לכביש 53.

מניפסטים של Kubeflow ב-AWS מגיעים ארוזים מראש עם אינטגרציות של Amazon RDS ו-Amazon S3. כששירותים מנוהלים אלה פועלים כמאגרי נתונים נפוצים, אנו יכולים להגדיר אסטרטגיית פריסה כחולה-ירוק. כדי להשיג זאת, וידאנו שמטא-נתונים של הצינור יישמרו ב-Amazon RDS, שפועלת ללא תלות מאשכול ה-EKS, והיומנים והחפצים של הצינור יישמרו ב-Amazon S3. בנוסף למטא נתונים וחפצי צינור, הגדרנו גם את FluentD כדי לנתב יומני תרמילים לשירות Amazon OpenSearch.

זה מבטיח ששכבת האחסון מופרדת לחלוטין משכבת ​​המחשוב ובכך מאפשרת בדיקת שינויים במהלך עדכוני גרסת Kubeflow באשכול EKS חדש לחלוטין. לאחר שכל הבדיקות יצליחו, נוכל פשוט לשנות את כביש אמזון 53 רשומת DNS לאשכול המועמד המארח את Kubeflow. כמו כן, אנו שומרים על האשכול הישן פועל כגיבוי למשך מספר ימים למקרה שנצטרך לחזור אחורה.

היתרונות של Amazon EKS ו-Kubeflow ב-AWS עבור צינור ה-ML שלנו

Amazon EKS וחבילת Kubeflow on AWS העבירו את זרימת העבודה בפיתוח שלנו לדפוס שמעודד מאוד אימון מודלים שניתן לחזור עליהם. כלים אלו מאפשרים לנו לקבל אשכולות מוגדרים במלואם עם דיירים מוגדרים במלואם ולהריץ קוד מוגדר לחלוטין.

הרבה ניצחונות מבניית פלטפורמה זו הם פחות כמותיים והם קשורים יותר לאופן שבו השתפרו זרימות העבודה הן עבור מפתחי הפלטפורמה והן עבור המשתמשים. לדוגמה, MinIO הוחלף בגישה ישירה לאמזון S3, מה שמקרב אותנו לזרימות העבודה המקוריות שלנו ומצמצם את מספר השירותים שעלינו לתחזק. אנחנו גם מסוגלים להשתמש ב-Amazon RDS בתור הקצה העורפי של Kubeflow, מה שמאפשר העברות קלות יותר בין אשכולות ונותן לנו את היכולת לגבות את הצינורות שלנו מדי לילה.

מצאנו גם את השיפורים באינטגרציה של Kubeflow עם שירותים מנוהלים של AWS מועילים. לדוגמה, עם Amazon RDS, Amazon S3 ו-Amazon Cognito המוגדרים מראש במניפסטים של Kubeflow ב-AWS, אנו חוסכים זמן ומאמץ בעדכון להפצות חדשות יותר של Kubeflow. כאשר נהגנו לשנות את המניפסטים הרשמיים של Kubeflow באופן ידני, עדכון לגרסה חדשה ייקח מספר שבועות, מהתכנון ועד לבדיקה.

המעבר לאמזון EKS נותן לנו את ההזדמנות להגדיר את האשכול שלנו ב-Kustomize (כיום חלק מ-Kubectl) וב-Terraform. מסתבר שלעבודה בפלטפורמה, קל מאוד לעבוד עם Kubernetes ו-Terraform לאחר שהקדישו מספיק זמן ללמידה. לאחר איטרציות רבות, הכלים העומדים לרשותנו מקלים מאוד על ביצוע פעולות פלטפורמה סטנדרטיות כמו שדרוג רכיב או החלפת אשכול פיתוח שלם. בהשוואה להרצת משרות ללא גלם ענן מחשוב אלסטי של אמזון (Amazon EC2), קשה להשוות איזה הבדל עצום זה עושה אם יש פודים מוגדרים היטב עם מנגנוני ניקוי משאבים מובטחים ומנגנוני ניסיון חוזר מובנים.

Kubernetes מספקת תקני אבטחה מצוינים, ורק שרטנו את פני השטח של מה שהבידוד מרובה המשתמשים מאפשר לנו לעשות. אנו רואים בבידוד מרובה משתמשים כדפוס שיש לו יותר תמורה בעתיד כאשר פלטפורמת ההדרכה מייצרת נתונים ברמת הייצור, ואנו מביאים מפתחים מחוץ לצוות שלנו.

בינתיים, Kubeflow מאפשר לנו לקבל אימון מודלים שניתן לשחזר. אפילו עם אותם נתונים, שום הכשרה לא מייצרת מודלים זהים, אבל יש לנו את הדבר הטוב הבא. עם Kubeflow, אנו יודעים בדיוק באיזה קוד ונתונים השתמשו כדי להכשיר מודל. ההטמעה השתפרה מאוד מכיוון שכל שלב בצנרת שלנו מוגדר בצורה ברורה ותוכניתית. כאשר למדענים חדשים מוטלת המשימה לתקן באג, הם צריכים הרבה פחות אחיזת יד מכיוון שיש מבנה ברור לאופן השימוש בפלטי קוד בין השלבים.

השימוש ב-Kubeflow מניב גם הרבה שיפורים בביצועים בהשוואה להפעלה על מופע EC2 בודד. לעתים קרובות בהכשרת מודלים, מדעני נתונים זקוקים לכלים ואופטימיזציות שונות עבור עיבוד מקדים והדרכה. לדוגמה, עיבוד מקדים מתנהל לרוב באמצעות כלי עיבוד נתונים מבוזרים, כמו Spark, בעוד שההדרכה מופעלת לרוב באמצעות מופעי GPU. עם צינורות Kubeflow, הם יכולים לציין סוגי מופעים שונים עבור שלבים שונים בצינור. זה מאפשר להם להשתמש במופעי GPU רבי עוצמה בשלב אחד ובצי של מכונות קטנות יותר לעיבוד מבוזר בשלב אחר. כמו כן, מכיוון שצינורות Kubeflow מתארים את התלות בין השלבים, הצינורות יכולים להפעיל שלבים במקביל.

לבסוף, מכיוון שיצרנו תהליך להוספת דיירים לאשכול, יש כעת דרך רשמית יותר לרשום צוותים לדייר באשכול. מכיוון שאנו משתמשים ב-Kubecost כדי לעקוב אחר עלויות באשכול ה-EKS שלנו, זה מאפשר לנו לייחס עלות לפרויקט בודד במקום לייחוס עלות ברמת החשבון, הכוללת את כל פרויקטי מדעי הנתונים. Kubecost מציגה דוח של הכסף שהוצא לכל מרחב שמות, המקושר באופן הדוק לדייר או לצוות שאחראים על הפעלת הצינור.

למרות כל היתרונות, נזהיר לבצע העברה מסוג זה רק אם יש רכישה מוחלטת ממשתמשים. משתמשים שמקדישים זמן מקבלים הרבה יתרונות משימוש באמזון EKS ו-Kubernetes, אבל יש עקומת למידה משמעותית.

סיכום

עם הטמעת צינור Kubeflow על AWS בתשתית ה-ML שלנו מקצה לקצה, הצלחנו לגבש ולתקן את זרימות העבודה של מדעי הנתונים שלנו תוך שמירה על הכלים החיוניים שלנו (כגון CI/CD והגשת מודלים). מדעני הנתונים שלנו יכולים כעת לעבור בין פרויקטים בהתבסס על זרימת עבודה זו ללא תקורה של למידה כיצד לתחזק ערכת כלים שונה לחלוטין. עבור חלק מהדגמים שלנו, הופתענו לטובה גם מהמהירות של זרימת העבודה החדשה (פי חמישה מהירה יותר), שאפשרה איטרציות אימונים רבות יותר וכתוצאה מכך ייצור מודלים עם תחזיות טובות יותר.

הקמנו בסיס איתן להגדלת יכולות ה-MLOps שלנו ולהרחיב את המספר והגודל של הפרויקטים שלנו. לדוגמה, ככל שאנו מקשיחים את עמדת הממשל שלנו בשושלת ומעקב אחר מודלים, צמצמנו את המיקוד שלנו מלמעלה מ-15 זרימות עבודה לאחד בלבד. וכאשר התגלתה הפגיעות של Log4shell בסוף 2021, הצלחנו להתמקד בזרימת עבודה אחת ולתקן במהירות לפי הצורך (ביצוע מרשם מיכל אלסטי של אמזון סריקות (Amazon ECR), שדרוג שירות Amazon OpenSearch, עדכון כלי העבודה שלנו ועוד) עם השפעה מינימלית על העבודה השוטפת של מדעני הנתונים. כאשר שיפורים של AWS ו-Kubeflow הופכים לזמינים, נוכל לשלב אותם כראות עינינו.

זה מביא אותנו להיבט חשוב ומאופק של Kubeflow שלנו על אימוץ AWS. אחת התוצאות הקריטיות של המסע הזה היא היכולת להפיץ שדרוגים ושיפורים ל-Kubeflow בצורה חלקה עבור מדעני הנתונים שלנו. למרות שדיברנו על הגישה שלנו לכך קודם לכן, אנו מסתמכים גם על המניפסטים של Kubeflow שמסופקים על ידי AWS. התחלנו את מסע Kubeflow שלנו כהוכחה לקונספט בשנת 2019, לפני שחרורו של גרסה 1.0.0. (אנחנו כרגע ב-1.4.1, מעריכים את 1.5. AWS כבר עובד על גרסת 1.6.) ב-3 השנים שחלפו, היו לפחות שש מהדורות עם תוכן משמעותי. באמצעות הגישה הממושמעת שלהם לשילוב ואימות השדרוגים הללו ושחרור המניפסטים בלוח זמנים צפוי ואמין, לצוות Kubeflow ב-AWS היה חשיבות מכרעת כדי לאפשר לצוות MLOps athenahealth לתכנן את מפת הדרכים לפיתוח שלנו, וכתוצאה מכך הקצאות המשאבים ותחומי המיקוד שלנו , הלאה לעתיד בביטחון רב יותר.

אתה יכול לעקוב אחר מאגר GitHub של AWS Labs כדי לעקוב אחר כל התרומות של AWS ל-Kubeflow. אתה יכול גם למצוא צוותי AWS ב- ערוץ Slack של Kubeflow #AWS; המשוב שלך שם עוזר ל-AWS לתעדף את התכונות הבאות לתרום לפרויקט Kubeflow.

---

על המחברים

Kanwaljit Khurmi הוא ארכיטקט פתרונות בכיר בחברת Amazon Web Services. הוא עובד עם לקוחות AWS כדי לספק הדרכה וסיוע טכני המסייעים להם לשפר את הערך של הפתרונות שלהם בעת השימוש ב-AWS. Kanwaljit מתמחה בסיוע ללקוחות עם יישומי מכולות ולמידת מכונה.

טיילר קלבך הוא חבר ראשי בצוות הטכני ב-athenahealth. לטיילר ניסיון של כ-7 שנים באנליטיקה, מדעי נתונים, רשתות עצביות ופיתוח יישומי למידת מכונה בתחום הבריאות. הוא תרם למספר פתרונות Machine Learning המשרתים כעת תעבורת ייצור. כיום, עובד כמדען נתונים ראשי בארגון ההנדסה של athenahealth, טיילר היה חלק מהצוות שבנה את פלטפורמת ההדרכה החדשה של למידת מכונה עבור אתנה-בריאות מתחילת המאמץ הזה.

ויקטור קרילוב הוא חבר ראשי בצוות הטכני ב-athenahealth. ויקטור הוא מהנדס ו-Scrum Master, עוזר למדעני נתונים לבנות צינורות למידת מכונה מהירה מאובטחת. ב-athenehealth הוא עבד על ממשקים, הזמנה קלינית, מרשמים, תזמון, אנליטיקה ועכשיו למידת מכונה. הוא מעריך קוד כתוב בצורה נקייה ונבדק היטב ביחידה, אבל יש לו אובססיה לא בריאה עם קוד one-liners. בזמנו הפנוי הוא נהנה להאזין לפודקאסטים תוך כדי טיול עם הכלב שלו.

סאסנק ומורי הוא חבר ראשי בצוות הטכני ב-athenahealth. יש לו ניסיון בעבודה עם פיתוח פתרונות מונעי נתונים על פני תחומים כמו בריאות, ביטוח וביואינפורמטיקה. Sasank עובדת כיום עם תכנון ופיתוח של פלטפורמות הדרכה והסקת למידת מכונה ב-AWS ו-Kubernetes המסייעות בהדרכה ופריסה של פתרונות ML בקנה מידה.

אנו טומקור הוא אדריכל ב-athenahealth. ל-Anu יש למעלה משני עשורים של ניסיון בארכיטקטורה, עיצוב, פיתוח בבניית מוצרי תוכנה שונים בתחום למידת מכונה, תפעול ענן, ביג דאטה, צינורות נתונים מבוזרים בזמן אמת, טכנולוגיית מודעות, ניתוח נתונים, ניתוח מדיה חברתית. אנו עובדת כיום כאדריכלית בארגון הנדסת מוצר של athenahealth בצוותי פלטפורמת למידת מכונה ו-Data Pipeline.

וויליאם טסן הוא מנהל הנדסה בכיר ב-athenahealth. יש לו למעלה מ-20 שנות ניסיון במנהיגות הנדסית בבניית פתרונות בתחום ה-IT בתחום הבריאות, מחשוב מבוזר ב-Big Data, רשתות אופטיות חכמות, מערכות לעריכת וידאו בזמן אמת, תוכנה ארגונית וחיתום שירותי בריאות קבוצתיים. ויליאם מוביל כיום שני צוותים מדהימים ב-athenahealth, צוותי ההנדסה של Machine Learning Operations ו-DevOps, בארגון הנדסת המוצר.