כיצד Medidata השתמשה בהסקה אסינכרונית של אמזון SageMaker כדי להאיץ את תחזיות הסקת ML עד פי 30 מהר יותר

הפוסט הזה נכתב בשיתוף עם Rajnish Jain, Priyanka Kulkarni ו-Daniel Johnson מ-Medidata.

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

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

אמזון SageMaker היא פלטפורמת למידת מכונה מנוהלת במלואה (ML) בתוך נוף ה-AWS המאובטח. עם SageMaker, מדעני נתונים ומפתחים יכולים לבנות ולאמן מודלים של ML במהירות ובקלות, ולאחר מכן לפרוס אותם ישירות בסביבה מתארחת מוכנה לייצור. לאירוח דגמי ML מאומנים, SageMaker מציעה מגוון רחב של אפשרויות. בהתאם לסוג דפוס התנועה ולדרישות האחזור, תוכל לבחור באחת ממספר האפשרויות הללו. לדוגמה, מסקנות בזמן אמת מתאים לעומסי עבודה מתמשכים עם דרישות השהייה של אלפיות שניות, גדלי עומס של עד 6 MB וזמני עיבוד של עד 60 שניות. עם מסקנות ללא שרת, אתה יכול לפרוס במהירות מודלים של ML להסקת מסקנות מבלי שתצטרך להגדיר או לנהל את התשתית הבסיסית, ואתה משלם רק עבור קיבולת המחשוב המשמשת לעיבוד בקשות מסקנות, שהיא אידיאלית לעומסי עבודה לסירוגין. עבור בקשות עם נתונים לא מובנים גדולים עם גדלי עומס של עד 1 GB, עם זמני עיבוד של עד 15 דקות ודרישות השהייה כמעט בזמן אמת, אתה יכול להשתמש הסקה אסינכרונית. הפיכת אצווה הוא אידיאלי עבור תחזיות לא מקוונות על קבוצות גדולות של נתונים הזמינות מראש.

בפוסט שיתופי זה, אנו מדגימים כיצד AWS סייעה ל-Meddata לנצל את יכולות האירוח השונות בתוך SageMaker כדי להתנסות עם אפשרויות ארכיטקטורה שונות לניבוי ההצלחה התפעולית של ניסויים קליניים מוצעים. אנו גם מאשרים מדוע Medidata בחרה במסקנות אסינכרוניות של SageMaker עבור העיצוב הסופי שלה וכיצד הארכיטקטורה הסופית הזו עזרה ל-Medidata לשרת את לקוחותיה עם תחזיות עד פי 30 מהר יותר תוך שמירה על עלויות תשתית ML נמוכות יחסית.

אבולוציה של אדריכלות

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

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

המרת אצווה של SageMaker

במקור נעשה שימוש ב-Medidata המרת אצווה של SageMaker להסקת ML לעמוד בדרישות הנוכחיות ולפתח מוצר קיימא מינימלי (MVP) לפתרון חיזוי חדש עקב שימוש נמוך ודרישות ביצועים רופפות של האפליקציה. כאשר מתחילה עבודת טרנספורמציה אצווה, SageMaker מאתחל מופעי מחשוב ומחלק את עומס העבודה של ההסקה או העיבוד המקדים ביניהם. זוהי שיטה בעלת ביצועים גבוהים ותפוקה גבוהה להמרת נתונים ויצירת מסקנות. זה אידיאלי עבור תרחישים שבהם אתה מתמודד עם קבוצות גדולות של נתונים, אינך זקוק להשהייה בתת-שנייה, וצריך לעבד מראש או לשנות את הנתונים או להשתמש במודל מיומן כדי להפעיל עליהם תחזיות אצווה בצורה מבוזרת. זרימת העבודה של שינוי אצווה של Sagemaker משתמשת גם היא שירות אחסון פשוט של אמזון (Amazon S3) כשכבה המתמשכת, שממפה לאחת מדרישות הנתונים שלנו.

בתחילה, שימוש בהמרת אצווה של SageMaker עבד היטב עבור ה-MVP, אך ככל שהדרישות התפתחו ו-Medidata נדרשה לתמוך בלקוחותיה כמעט בזמן אמת, טרנספורמציה אצווה לא הייתה מתאימה מכיוון שזו הייתה שיטה לא מקוונת ולקוחות צריכים להמתין בין 5- 15 דקות לתגובות. זה כלל בעיקר את עלות ההפעלה עבור אשכול המחשוב הבסיסי להסתובב בכל פעם שיש צורך לעבד עומס עבודה אצווה. ארכיטקטורה זו דרשה גם הגדרה אמזון CloudWatch כללי אירועים למעקב אחר ההתקדמות של משימת חיזוי האצווה יחד עם שימוש במסד נתונים לבחירה כדי לעקוב אחר המצבים והמטא נתונים של העבודה שפוטרה. ארכיטקטורת ה-MVP מוצגת בתרשים הבא.

הזרימה של ארכיטקטורה זו היא כדלקמן:

1. המטען בתפזורת הנכנס נמשך כקלט למיקום S3. אירוע זה בתורו מפעיל an AWS למבדה פונקציית שלח.
2. הפונקציה Submit מתחילה עבודת טרנספורמציה של SageMaker באמצעות לקוח זמן הריצה של SageMaker.
3. הפונקציה Submit מעדכנת גם מסד נתונים של מעקב אחר מצבים ומטא נתונים עם מזהה המשרה ומגדירה את מצב המשרה ל inProgress. הפונקציה גם מעדכנת את מזהה העבודה עם מידע המטא-נתונים התואם לה.
4. אשכול המחשוב החולף (לפי דרישה) הנדרש לעיבוד המטען מסתובב, ומתחיל משימת שינוי אצווה של SageMaker. במקביל, העבודה משדרת גם התראות סטטוס ומידע רישום אחר ליומני CloudWatch.
5. כלל האירועים של CloudWatch לוכד את הסטטוס של משימת ההמרה האצווה ושולח הודעת סטטוס ל- שירות התראה פשוט של אמזון נושא (Amazon SNS) מוגדר ללכוד מידע זה.
6. נושא ה-SNS נרשם על ידי פונקציית Notification Lambda המופעלת בכל פעם שכלל אירוע מופעל על ידי CloudWatch וכאשר יש הודעה בנושא SNS.
7. פונקציית ההודעה מעדכנת את המצב של משימת ההמרה להצלחה או כישלון במסד הנתונים של המעקב.

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

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

מסקנות בזמן אמת של SageMaker

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

הסקת מסקנות בזמן אמת של SageMaker היא בעלת פסק זמן של 60 שניות להפעלת נקודת קצה, וגודל המטען המקסימלי להפעלה מוגבל ל-6 MB. מכיוון שהלוגיקת ההסקה של Medidata היא מורכבת ודורשת לעתים קרובות יותר מ-60 שניות, הסקת מסקנות בזמן אמת לבדה לא יכולה להיות אופציה מעשית להתמודדות עם בקשות בכמות גדולה שבדרך כלל דורשות פתיחה ועיבוד של מזהים תפעוליים בודדים רבים מבלי לבנות מחדש את צינור ה-ML הקיים. בנוסף, נקודות קצה של הסקת מסקנות בזמן אמת צריכות להיות בגודל כדי להתמודד עם עומס שיא. זה יכול להיות מאתגר מכיוון שלMeddata יש פרצים מהירים של תעבורה גבוהה. קנה מידה אוטומטי עשוי לתקן את הבעיה הזו, אבל זה ידרוש כוונון ידני כדי להבטיח שיש מספיק משאבים לטפל בכל הבקשות בכל זמן נתון. לחלופין, נוכל לנהל תור בקשות כדי להגביל את מספר הבקשות במקביל בזמן נתון, אבל זה יכניס תקורה נוספת.

למבדה

הצעות ללא שרתים כמו Lambda מבטלות את הטרחה של אספקה ​​וניהול שרתים, ודואגות אוטומטית לשינוי קנה מידה בתגובה לעומסי עבודה משתנים. הם יכולים להיות גם הרבה יותר זולים עבור שירותים בנפח נמוך יותר מכיוון שהם לא פועלים 24/7. למדה פועלת היטב לעומסי עבודה שיכולים לסבול התחלות קרות לאחר תקופות של חוסר פעילות. אם פונקציה ללא שרת לא הופעלה במשך כ-15 דקות, הבקשה הבאה חווה מה שמכונה התחלה קרה מכיוון שיש לספק את המיכל של הפונקציה.

Medidata בנתה מספר עיצובי ארכיטקטורת הוכחה לקונספט (POC) כדי להשוות את Lambda עם חלופות אחרות. כיישום פשוט ראשון, קוד ההסקת ML נארז כתמונת Docker ונפרס כמיכל באמצעות Lambda. כדי לאפשר תחזיות מהירות יותר עם הגדרה זו, פונקציית Lambda המופעלת דורשת טביעת רגל גדולה של זיכרון מסודר. עבור מטענים גדולים יותר, יש תקורה נוספת לדחיסת הקלט לפני קריאה לנקודת הקצה Lambda Docker. דרושות גם תצורות נוספות עבור כללי האירוע של CloudWatch כדי לשמור את הקלט והפלטים, לעקוב אחר התקדמות הבקשה ולהשתמש במסד נתונים לבחירה כדי לעקוב אחר המצבים הפנימיים והמטא נתונים של הבקשות שנורו. בנוסף, יש גם תקורה תפעולית לקריאה וכתיבת נתונים לאמזון S3. Medidata חישבה את העלות החזויה של גישת Lambda בהתבסס על הערכות שימוש וקבעה שהיא תהיה יקרה הרבה יותר מ- SageMaker ללא יתרונות נוספים.

מסקנות אסינכרוניות של SageMaker

הסקה אסינכרונית היא אחת מהצעות ההסקה החדשות ביותר ב- SageMaker שמשתמשת בתור פנימי לבקשות נכנסות ומעבדת אותן באופן אסינכרוני. אפשרות זו אידיאלית עבור מסקנות עם גדלי מטען גדולים (עד 1 GB) או זמני עיבוד ארוכים (עד 15 דקות) שצריך לעבד עם הגעת הבקשות. הסקה אסינכרונית מאפשרת לך לחסוך בעלויות על ידי שינוי קנה מידה אוטומטי של ספירת המופעים לאפס כאשר אין בקשות לעיבוד, כך שאתה משלם רק כאשר נקודת הקצה שלך מעבדת בקשות.

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

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

בהתבסס על עיצובי הארכיטקטורה השונים שנדונו בעבר, זיהינו מספר צווארי בקבוק ואתגרי מורכבות בארכיטקטורות אלו. עם השקת הסקה אסינכרונית ובהתבסס על הניסויים והביצועים הנרחבים שלנו, Medidata החליטו לבחור בהסקה אסינכרונית של SageMaker לארכיטקטורה הסופית שלהם לאירוח, בשל מספר סיבות שפורטו קודם לכן. SageMaker תוכנן מהיסוד כדי לתמוך בעומסי עבודה של ML, בעוד ש-Lambda הוא יותר כלי למטרות כלליות. עבור מקרה השימוש הספציפי שלנו וסוג עומס העבודה, מסקנות אסינכרוניות של SageMaker זולה יותר מ- Lambda. כמו כן, פסק הזמן של הסקת מסקנות אסינכרונית של SageMaker ארוך בהרבה (15 דקות) בהשוואה לזמן קצוב להסקה בזמן אמת של 60 שניות. זה מבטיח שהמסק אסינכרוני יכול לתמוך בכל עומסי העבודה של Medidata ללא שינוי. בנוסף, מסקנות אסינכרוניות של SageMaker מעמידה בתורים בקשות במהלך פרצי תעבורה מהירים במקום להפיל אותן, וזו הייתה דרישה חזקה לפי מקרה השימוש שלנו. טיפול בחריגים ושגיאות מטופל עבורך באופן אוטומטי. הסקה אסינכרונית גם מקלה על הטיפול בגדלים גדולים של מטען, שהוא דפוס נפוץ עם דרישות ההסקה שלנו. דיאגרמת הארכיטקטורה הסופית באמצעות מסקנות אסינכרוניות של SageMaker מוצגת באיור הבא.

הזרימה של הארכיטקטורה הסופית שלנו היא כדלקמן:

1. הפונקציה Submit מקבלת את המטען בתפזורת מיישומי צרכנים במעלה הזרם והיא מוגדרת להיות מונעת אירועים. פונקציה זו מעלה את המטען למיקום המיועד מראש של Amazon S3.
2. לאחר מכן, הפונקציה Submit מפעילה את נקודת הקצה הא-סינכרונית של SageMaker, ומספקת לה את המצביע של Amazon S3 למטען הנטען.
3. הפונקציה גם מעדכנת את מצב הבקשה ל inProgress במסד הנתונים של מעקב אחר מצב ומטא נתונים.
4. נקודת הסיום הא-סינכרונית של SageMaker קוראת את הקלט מ-Amazon S3 ומפעילה את לוגיקה ההסקה. כאשר ההסקת ML מצליחה או נכשלת, פלט ההסקה נכתב בחזרה לאמזון S3 והסטטוס נשלח לנושא SNS.
5. פונקציית Notification Lambda נרשמת לנושא SNS. הפונקציה מופעלת בכל פעם שמתפרסמת הודעת עדכון סטטוס לנושא.
6. הפונקציה Notification מעדכנת את מצב הבקשה להצלחה או כישלון במסד הנתונים של מעקב אחר מצב ומטא נתונים.

לסיכום, ארכיטקטורת ה-MVP של טרנספורמציה אצווה שהתחלנו איתה ארכה 5-15 דקות לרוץ בהתאם לגודל הקלט. עם המעבר להסקת הסקה אסינכרונית, הפתרון החדש פועל מקצה לקצה תוך 10-60 שניות. אנו רואים מהירות של לפחות פי חמישה יותר עבור תשומות גדולות יותר ועד פי 30 מהר יותר עבור תשומות קטנות יותר, מה שמוביל לשביעות רצון לקוחות טובה יותר מתוצאות הביצועים. הארכיטקטורה הסופית המתוקנת מפשטת מאוד את הארכיטקטורה הקודמת של אוהד-אאוט/אי-סינכרוני מכיוון שאיננו צריכים לדאוג לגבי חלוקת המטען הנכנס, השרצת עובדים והאצלת ואיחוד עבודה בין פונקציות ה-Lambda של העובדים.

סיכום

עם מסקנות אסינכרוניות של SageMaker, הלקוחות של Medidata המשתמשים ביישום החזוי החדש הזה חווים כעת מהירות המהירה עד פי 30 לחיזויים. בקשות אינן נשמטות במהלך עליות תעבורה מכיוון שנקודת הקצה הא-סינכרונית של ההסקה האסינכרונית מעמידה בתורים בקשות במקום מורידה אותן. הודעת ה-SNS המובנית הצליחה להתגבר על ההתראה המותאמת של יומן האירועים של CloudWatch שבנתה Medidata כדי להודיע ​​לאפליקציה כשהעבודה הושלמה. במקרה זה, גישת ההסקה האסינכרונית זולה יותר מלמבדה. מסקנות אסינכרוניות של SageMaker היא אופציה מצוינת אם הצוות שלך מפעיל עומסי עבודה כבדים של ML עם תעבורה מתפרצת תוך ניסיון למזער עלויות. זוהי דוגמה מצוינת לשיתוף פעולה עם צוות AWS כדי לדחוף את הגבולות ולהשתמש בטכנולוגיית קצה מדמם ליעילות מירבית.

לשלבים מפורטים כיצד ליצור, להפעיל ולנטר נקודות קצה אסינכרוניות, עיין ב תיעוד, המכיל גם א מחברת מדגם כדי לעזור לך להתחיל. למידע על מחירים, בקר תמחור SageMaker של אמזון. לדוגמאות על שימוש בהסקה אסינכרונית עם נתונים לא מובנים כגון ראייה ממוחשבת ועיבוד שפה טבעית (NLP), עיין ב הפעל מסקנות של חזון מחשב על סרטונים גדולים עם נקודות קצה אסינכרוניות של Amazon SageMaker ו שפר מחקר בעל ערך גבוה עם נקודות קצה א-סינכרוניות של מסקנות חיבוק ו-Amazon SageMaker, בהתאמה.

---

על המחברים

ראג'ניש ג'יין הוא מנהל בכיר להנדסה ב-Medidata AI הממוקם בניו יורק. Rajnish עומד בראש הנדסה של חבילת יישומים המשתמשים בלמידת מכונה ב-AWS כדי לעזור ללקוחות לשפר את ההצלחה התפעולית של ניסויים קליניים מוצעים. הוא נלהב מהשימוש בלמידת מכונה כדי לפתור בעיות עסקיות.

פריאנקה קולקרני הוא מהנדס תוכנה מוביל ב-Acorn AI בחברת Medidata Solutions. היא מעצבת ומפתחת פתרונות ותשתיות לתמיכה בתחזיות ML בקנה מידה. היא מהנדסת מונעת נתונים המאמינה בבניית פתרונות תוכנה חדשניים להצלחת לקוחות.

דניאל ג'ונסון הוא מהנדס תוכנה בכיר בתוך Acorn AI בחברת Medidata Solutions. הוא בונה ממשקי API כדי לתמוך בתחזיות ML סביב היתכנות של ניסויים קליניים מוצעים.

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

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