השמיים מסגרת AWS Machine Learning Operations (MLOps). הוא תהליך איטרטיבי וחוזר על עצמו להתפתחות מודלים של AI לאורך זמן. כמו DevOps, מתרגלים משיגים יעילות בקידום החפצים שלהם באמצעות סביבות שונות (כגון הבטחת איכות, אינטגרציה וייצור) לצורך בקרת איכות. במקביל, לקוחות מאמצים במהירות אסטרטגיות ריבוי חשבונות באמצעות ארגוני AWS ו מגדל השליטה של AWS ליצור סביבות מאובטחות ומבודדות. שילוב זה יכול להציג אתגרים להטמעת MLOps עם שירותי AI מאומנים מראש של AWS, כגון תוויות מותאמות אישית של Amazon Rekognition. פוסט זה דן בדפוסי עיצוב להפחתת המורכבות הזו תוך שמירה על שיטות אבטחה מומלצות.
סקירה כללית
לקוחות בכל ענף תעשייה מזהים את הערך של הפעלת למידת מכונה (ML) ביעילות וצמצום הזמן לספק ערך עסקי. רוב שירותי הבינה המלאכותית שעברו הכשרה מראש של AWS נותנים מענה למצב זה באמצעות יכולות יציאה מהקופסה לראייה ממוחשבת, תרגום וזיהוי הונאה, בין מקרי שימוש נפוצים אחרים. מקרי שימוש רבים דורשים תחזיות ספציפיות לתחום החורגות מתשובות כלליות. שירותי הבינה המלאכותית יכולים לכוונן עדין את תוצאות המודל החזוי באמצעות נתונים עם תווית הלקוח עבור תרחישים אלו.
עם הזמן, אוצר המילים הספציפי לתחום משתנה ומתפתח. לדוגמה, נניח שיצרן כלים יוצר מודל ראייה ממוחשבת כדי לזהות את המוצרים שלו בתמונות (כגון פטישים ומברגים). במהדורה עתידית, העסק מוסיף תמיכה עבור מפתח ברגים ומסורים. התוויות החדשות הללו מחייבות שינויי קוד באתרי היצרן ובאפליקציות המותאמות אישית. כעת, יש תלות ששני החפצים חייבים לשחרר בו זמנית.
המסגרת של AWS MLOps נותנת מענה לאתגרי השחרור הללו באמצעות תהליכים איטרטיביים וחוזרים על עצמם. לפני הגעה למשתמשי קצה הייצור, חפצי הדגם חייבים לעבור בשערים איכותיים שונים כמו קוד יישום. אתה בדרך כלל מיישם את השערים האיכותיים האלה באמצעות מספר חשבונות AWS בתוך ארגון AWS. גישה זו מעניקה את הגמישות לנהל באופן מרכזי את תחומי האפליקציות הללו ולאכוף מעקות בטיחות ודרישות עסקיות. זה הופך נפוץ יותר ויותר להחזיק עשרות או אפילו מאות חשבונות בתוך הארגון שלך. עם זאת, עליך לאזן את צורכי בידוד עומס העבודה שלך מול גודל הצוות והמורכבות.
למתרגלים של MLOps יש נהלים סטנדרטיים לקידום חפצים בין חשבונות (כגון QA לייצור). דפוסים אלה פשוטים ליישום, תוך הסתמכות על העתקת קוד ומשאבים בינאריים ביניהם שירות אחסון פשוט של אמזון (אמזון S3) דליים. עם זאת, שירותי AI שהוכשרו מראש של AWS אינם תומכים כעת בהעתקת המודל המותאם אישית המאומן בין חשבונות AWS. עד שמנגנון כזה קיים, עליך לאמן מחדש את המודלים בכל חשבון AWS באמצעות אותו מערך נתונים. גישה זו כרוכה בזמן ובעלות להכשרת המודל מחדש בחשבון חדש. מנגנון זה יכול להיות אפשרות מעשית עבור חלק מהלקוחות. עם זאת, בפוסט זה, אנו מדגימים את האמצעים להגדיר ולפתח מודלים מותאמים אישית אלה באופן מרכזי תוך שיתוף מאובטח שלהם בין חשבונות של ארגון AWS.
סקירת פתרונות
פוסט זה דן בדפוסי עיצוב לשיתוף מאובטח של מודלים ספציפיים לתחום AI Service שעבר הכשרה מראש של AWS. שירותים אלו כוללים גלאי הונאות של אמזון, אמזון תעתיק, ו אמזון, אם להזכיר כמה. למרות שאסטרטגיות אלה ישימות באופן נרחב, אנו מתמקדים בתוויות מותאמות אישית של זיהוי כדוגמה קונקרטית. אנו נמנעים בכוונה לצלול עמוק מדי לתוך ניואנסים ספציפיים ל-Rekognition Custom Labs.
הארכיטקטורה מתחילה עם AWS Control Tower מוגדר בחשבון הניהול. AWS Control Tower מספק את הדרך הקלה ביותר להגדיר ולנהל סביבת AWS מאובטחת מרובת חשבונות. כפי שמוצג בתרשים הבא, אנו משתמשים מפעל חשבון ב-AWS Control Tower כדי ליצור חמישה חשבונות AWS:
- חשבון CI/CD לתזמור פריסה (לדוגמה, עם AWS CodeStar)
- חשבון ייצור עבור משתמשי קצה חיצוניים (לדוגמה, אתר ציבורי)
- חשבון אבטחת איכות לצוותי פיתוח פנימיים (כגון קדם ייצור)
- חשבון ML עבור דגמים מותאמים אישית ומערכות תומכות
- בית אגם AWS חשבון המחזיק בנתוני לקוחות קנייניים
תצורה זו עשויה להיות גרגירית או גסה מדי, בהתאם לדרישות הרגולטוריות, התעשייה והגודל שלך. מתייחס ניהול סביבת ריבוי החשבונות באמצעות AWS Organizations ו-AWS Control Tower לקבלת הדרכה נוספת.
צור את המודל של זיהוי תוויות מותאמות אישית
הצעד הראשון ליצירת מודל של זיהוי תוויות מותאמות אישית הוא בחירת חשבון AWS לארח אותו. ייתכן שתתחיל את מסע ה-ML שלך באמצעות חשבון ML יחיד. גישה זו מאחדת כל כלי עבודה ונהלים למקום אחד. עם זאת, ריכוזיות זו עלולה לגרום לנפיחות בחשבון האישי ולהוביל לסביבות מונוליטיות. ארגונים בוגרים יותר מפלח חשבון ML זה לפי צוות או עומס עבודה. ללא קשר לפירוט, האובייקט זהה להגדרה מרכזית ולאמן מודלים פעם אחת.
פוסט זה מדגים שימוש במודל של זיהוי תוויות מותאמות אישית עם חשבון ML יחיד וחשבון אגם נתונים נפרד (ראה את התרשים הבא). כאשר הנתונים נמצאים בחשבון אחר, עליך להגדיר מדיניות משאבים לספק גישה חוצת חשבונות לדלי S3 חפצים. הליך זה משתף בצורה מאובטחת את תוכן הדלי עם חשבון ML. ראה את דוגמאות להתחלה מהירה לקבלת מידע נוסף על יצירת מודל ספציפי לדומיין של Amazon Rekognition.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AWSRekognitionS3AclBucketRead20191011", "Effect": "Allow", "Principal": { "Service": "rekognition.amazonaws.com" }, "Action": [ "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::S3:" }, { "Sid": "AWSRekognitionS3GetBucket20191011", "Effect": "Allow", "Principal": { "Service": "rekognition.amazonaws.com" }, "Action": [ "s3:GetObject", "s3:GetObjectAcl", "s3:GetObjectVersion", "s3:GetObjectTagging" ], "Resource": "arn:aws:s3:::S3:/*" }, { "Sid": "AWSRekognitionS3ACLBucketWrite20191011", "Effect": "Allow", "Principal": { "Service": "rekognition.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::S3:" }, { "Sid": "AWSRekognitionS3PutObject20191011", "Effect": "Allow", "Principal": { "Service": "rekognition.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::S3:/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } } ]
}
אפשר גישה חוצת חשבונות
לאחר בניית ופריסה של המודל, נקודת הקצה זמינה רק בחשבון ML. אין להשתמש בא מפתח סטטי כדי לשתף גישה. אתה חייב גישת נציג לחשבון הייצור (או QA) באמצעות AWS זהות וניהול גישה (IAM) תפקידים. כדי ליצור תפקיד חוצה-חשבונות בחשבון ML, בצע את השלבים הבאים:
- במסוף התוויות מותאמות אישית של זיהוי, בחר פרויקטים ובחר את שם הפרויקט שלך.
- בחרו מודלים ושם הדגם שלך.
- על השתמש במודל הכרטיסייה, גלול מטה אל השתמש במודל שלך סָעִיף.
- העתק את הדגם של שם משאב אמזון (ARN). יש לעצב אותו בצורה הבאה:
arn:aws:rekognition:region-name:account-id:project/model-name/version/version-id/timestamp
. - צור תפקיד עם
rekognition:DetectCustomLabels
הרשאות לדגם ARN ומדיניות אמון המאפשרתsts:AssumeRole
מחשבון הייצור (או QA) (לדוגמה,arn:aws:iam::PROD_ACCOUNT_ID_HERE:root
). - אופציונלי, צרף מדיניות נוספת עבור כל פעולות ספציפיות לעומס עבודה (כגון גישה ל-S3 buckets).
- לחלופין, הגדר את ה אלמנט מצב לאכוף דרישות האצלה נוספות.
- רשום את ה-ARN של התפקיד החדש לשימוש בסעיף הבא.
הפעל את נקודת הקצה
עם מדיניות האבטחה במקום, הגיע הזמן לבדוק את התצורה. גישה פשוטה כוללת יצירת ענן מחשוב אלסטי של אמזון (Amazon EC2) מופע ושימוש ב- ממשק שורת הפקודה של AWS (AWS CLI). הפעל את נקודת הקצה עם השלבים הבאים:
- בחשבון הייצור (או QA), צור תפקיד עבור Amazon EC2.
- צרף פוליסה המאפשרת
sts:AssumeRole
ל-ARN חוצה תפקידים של חשבון ML. - הפעל מופע של Amazon Linux 2 עם התפקיד מהשלב הקודם.
- חכה שזה יספק, אם כך להתחבר למופע של Linux באמצעות SSH.
- הפעל את הפקודה
aws iam assume-role
כדי לעבור לתפקיד חוצה-חשבונות מהסעיף הקודם. - התחל את נקודת הסיום של הדגם, אם עדיין לא פועל, באמצעות מסוף הזיהוי או ה- גרסת התחלה-פרויקט פקודת AWS CLI.
- הפעל את הפקודה זיהוי aws-זיהוי תוויות מותאמות אישית כדי לבדוק את הפעולה.
אתה יכול גם לבצע בדיקה זו באמצעות AWS SDK ומשאב מחשוב אחר (לדוגמה, AWS למבדה).
הימנעות מהאינטרנט הציבורי
בסעיף הקודם, הבקשה לזיהוי תוויות מותאמות אישית משתמשת בשער האינטרנט של הענן הפרטי הווירטואלי (VPC) וחוצה את האינטרנט הציבורי. הצפנת TLS/SSL מאבטחת מספיק את ערוץ התקשורת לעומסי עבודה רבים. אתה יכול להשתמש AWS PrivateLink ל לאפשר חיבורים בין ה-VPC לשירותים התומכים ללא צורך בשער אינטרנט, מכשיר NAT, חיבור VPN, שער מעבר או חיבור ישיר חיבור. לאחר מכן, בקשת זיהוי התוויות המותאמות אישית לעולם אינה משאירה את רשת AWS חשופה לאינטרנט הציבורי. AWS PrivateLink תומך בכל השירותים שבהם נעשה שימוש בפוסט זה. אתה יכול גם לאכוף שירותי AI שהוכשרו מראש באמצעות קישוריות פרטית עם IAM במדיניות צולבת התפקידים. שליטה זו מוסיפה רמה נוספת של הגנה שמונעת מלקוחות עם הגדרות שגויות להשתמש בנקודת הקצה הפונה לאינטרנט של שירות AI המאומן מראש. למידע נוסף, ראה שימוש בזיהוי אמזון עם נקודות קצה של Amazon VPC, AWS PrivateLink עבור Amazon S3, ו שימוש בנקודות קצה של ממשק AWS STS VPC.
התרשים הבא ממחיש את תצורת נקודת הקצה של VPC בין חשבון הייצור, חשבון ML וחשבון QA.
בניית צינור CI/CD לקידום מודלים
AWS ממליצה לספק באופן רציף יותר הדרכה ונתוני בדיקה כדי לתייג בהתאמה אישית את מערך הנתונים של פרויקט Amazon Rekognition לשפר דגמים. לאחר הוספת נתונים נוספים לפרויקט, מודל חדש יכול לשפר את הדיוק או לשנות תוויות.
ב-MLOps, חפצי מודל חייבים להיות עקביים. כדי להשיג זאת עם שירותי AI מאומנים מראש, AWS ממליצה לקדם את נקודת הקצה של המודל על ידי עדכון ההתייחסות של הקוד ל-ARN של גרסת הדגם החדשה. גישה זו מונעת הדרכה מחדש של המודל הספציפי לתחום בכל סביבה (כגון QA וחשבונות ייצור). היישומים שלך יכולים להשתמש ב-ARN של הדגם החדש כמשתנה זמן ריצה באמצעות מנהל מערכות AWS בתוך ריבוי חשבון או סביבה רב שלבית.
שלוש רמות פירוט מגבילות את הגישה למודל חוצה-חשבונות, במיוחד ברמת החשבון, הפרויקט והדגם. המודלים הם אימפוטנטיים ויש להם ARN ייחודי שממפה לאימון נקודת זמן ספציפי: arn:aws:rekognition:account:region:project/project_name/version/name/timestamp
.
התרשים הבא ממחיש את סיבוב המודל מ-QA לייצור.
בארכיטקטורה הקודמת, יישומי הייצור וה-QA מבצעים קריאות API כדי להשתמש בנקודות הקצה של מודל v2 או v3 דרך נקודות הקצה של VPC המתאימות. הם מקבלים את ה-ARN מחנות התצורה שלו (לדוגמה, חנות הפרמטרים של מנהל המערכות של אמזון or AWS AppConfig). תהליך זה עובד עם n מספר סביבות, אך אנו מדגימים רק שימוש בשני חשבונות למען הפשטות. לחלופין, הסרת גרסאות הדגם שהוחלפו מונעת צריכה נוספת של משאבים אלה.
לחשבון ML יש תפקיד IAM עבור כל סביבה ספציפית (כגון חשבון Production) שדורש גישה. צינור ה-CI/CD כחלק מהפריסה משנה את המדיניות המוטבעת של תפקיד IAM כדי לאפשר גישה למודל המתאים.
שקול את התרחיש של קידום Model-v2 מחשבון ה-QA לחשבון הייצור. תהליך זה דורש את השלבים הבאים:
- במסוף זיהוי תוויות מותאמות אישית, העבר את נקודת הקצה Model-v2 למצב פועל.
- הענק לתפקיד חוצה-חשבונות IAM בחשבון ML גישה לגרסה החדשה של Model-v2.
שים לב כי אלמנט משאב תומך בתווים כלליים ב-ARN.
- שלח קריאת בדיקה ל-Model-v2 מאפליקציית הייצור באמצעות תפקיד האצלה.
- לחלופין, הסר את הגישה של התפקיד חוצה-חשבונות ל-Model-v1.
- לחלופין, חזור על שלבים 2-3 עבור כל חשבון AWS נוסף.
- לחלופין, עצור את נקודת הקצה Model-v1 כדי למנוע הוצאות.
הפצת מדיניות גלובלית ממישור הבקרה של IAM למישור הנתונים של IAM בכל אזור היא פעולה עקבית בסופו של דבר. עיצוב זה יכול ליצור עיכובים קלים עבור תצורות רב-אזוריות.
צור מעקות בטיחות באמצעות מדיניות בקרת שירות
שימוש בתפקידים חוצי-חשבונות יוצר מנגנון מאובטח לשיתוף משאבי AI מנוהלים מאומנים מראש. אבל מה קורה כאשר המדיניות של התפקיד הזה מתירנית מדי? אתה יכול להפחית סיכונים אלה על ידי שימוש במדיניות בקרת שירות (SCPs) כדי להגדיר מעקות הרשאות בין חשבונות. מעקות בטיחות מציינים את מקסימום הרשאות זמין עבור זהות IAM. יכולות אלו יכולות למנוע מחשבון צרכן לדוגמה לעצור את נקודת הקצה המשותפת של Amazon Rekognition. לאחר הגדרת דרישות מעקה בטיחות מתאימות, יחידות ארגוניות בתוך ארגונים לאפשר ניהול מרכזי של מדיניות זו על פני מספר חשבונות.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyModifyingRekgnotionProjects", "Effect": "Deny", "Action": [ "rekognition:CreateProject*", "rekognition:DeleteProject*", "rekognition:StartProject*", "rekognition:StopProject*", ], "Resource": [ “arn:aws:rekognition:*:*:project/* ] } ]
}
אתה יכול גם להגדיר בקרות בילוש כדי לפקח על התצורה שלהם ולוודא שהיא לא נסחפת מחוץ לתאימות. AWS IAM Access Analyzer תומך בהערכת מדיניות ברחבי הארגון ובדיווח על הרשאות שאינן בשימוש. בנוסף, תצורת AWS מאפשר הערכה, ביקורת והערכת תצורות של משאבי AWS. יכולת זו תומכת בדרישות אבטחה ותאימות סטנדרטיות, כגון אימות ותיקון הגדרות ההצפנה של דלי S3.
סיכום
אתה צריך פתרונות חדשים מהקופסה כדי להוסיף יכולות ML כמו ראייה ממוחשבת, תרגום וזיהוי הונאה. אתה גם צריך גבולות אבטחה שמבודדים את הסביבות השונות שלך למטרות בקרת איכות, תאימות ורגולציה. שירותי בינה מלאכותית מאומנים מראש של AWS ומגדל הבקרה של AWS מספקים את הפונקציונליות הזו באופן נגיש ומאובטח בקלות.
שירותי AI שהוכשרו מראש של AWS אינם תומכים כעת בהעתקת המודל המותאם אישית המאומן בין חשבונות AWS. עד שמנגנון כזה קיים, עליך לאמן מחדש את המודלים בכל חשבון AWS באמצעות אותו מערך נתונים. פוסט זה מדגים גישת עיצוב חלופית באמצעות מדיניות IAM חוצת חשבונות לשיתוף נקודות קצה של מודל תוך שמירה על בקרת אבטחה חזקה. יתר על כן, אתה יכול להפסיק לשלם עבור עבודות הכשרה מיותרות! למידע נוסף על מדיניות חוצה-חשבונות, ראה מדריך IAM: האצלת גישה בין חשבונות AWS באמצעות תפקידי IAM.
על הכותבים
נייט בכמאייר הוא אדריכל פתרונות בכיר ב-AWS שחוקר בנוודים את ניו יורק, שילוב ענן אחד בכל פעם. הוא מתמחה במעבר ומודרניזציה של עומסי העבודה של לקוחות. חוץ מזה, נייט הוא סטודנט במשרה מלאה ויש לו שני ילדים.
מריו בורגואן הוא ארכיטקט פתרונות שותפים בכיר עבור AWS, מומחה בינה מלאכותית/ML, והמנהיג הטכנולוגי העולמי עבור MLOps. הוא עובד עם לקוחות ארגוניים ושותפים בפריסת פתרונות AI בענן. יש לו יותר מ-30 שנות ניסיון בלמידת מכונה ובינה מלאכותית בסטארט-אפים ובארגונים, החל ביצירת אחת ממערכות למידת המכונה המסחריות הראשונות לביג דאטה. מריו מבלה את יתרת זמנו במשחק עם שלושת ה-Tervurens הבלגים שלו, בבישול ארוחות ערב למשפחתו, וללמוד על מתמטיקה וקוסמולוגיה.
טים מרפי הוא ארכיטקט פתרונות בכיר עבור AWS, שעובד עם לקוחות ארגוניים בתעשיות שונות כדי לבנות פתרונות מבוססי עסקים בענן. הוא בילה את העשור האחרון בעבודה עם סטארט-אפים, מלכ"רים, ארגונים מסחריים וסוכנויות ממשלתיות, תוך פריסת תשתיות בקנה מידה. בזמנו הפנוי כשהוא לא מתעסק בטכנולוגיה, סביר להניח שתמצאו אותו באזורים מרוחקים של כדור הארץ מטייל בהרים, גולש גלים או רוכב על אופניים בעיר חדשה.
- "
- 100
- 98
- אודות
- גישה
- חֶשְׁבּוֹן
- לרוחב
- פעולה
- פעולות
- נוסף
- כתובת
- AI
- שירותי AI
- תעשיות
- מאפשר
- כְּבָר
- למרות
- אמזון בעברית
- בין
- אחר
- API
- ישים
- בקשה
- יישומים
- גישה
- ארכיטקטורה
- זמין
- AWS
- הטוב ביותר
- שיטות עבודה מומלצות
- נתונים גדולים
- לְהַתְפִּיחַ
- לִבנוֹת
- עסקים
- יכולות
- מקרים
- לגרום
- האתגרים
- עִיר
- ענן
- קוד
- שילוב
- מסחרי
- Common
- תקשורת
- הענות
- לחשב
- מצב
- תְצוּרָה
- הקשר
- חיבורי
- קישוריות
- קונסול
- צרכן
- צְרִיכָה
- תוכן
- לִשְׁלוֹט
- עלויות
- יוצרים
- לקוחות
- נתונים
- עָשׂוֹר
- עיכובים
- לפרוס
- פריסה
- פריסה
- עיצוב
- איתור
- צעצועי התפתחות
- מכשיר
- אחר
- לא
- תחומים
- מטה
- כדור הארץ
- בקלות
- השפעה
- הצף
- נקודת קצה
- מִפְעָל
- סביבה
- דוגמה
- ניסיון
- משפחה
- ראשון
- גמישות
- להתמקד
- הבא
- מסגרת
- הונאה
- פונקציונלי
- עתיד
- גייטס
- גלוֹבָּלִי
- ממשלה
- HTTPS
- מאות
- זהות
- ליישם
- לכלול
- בנפרד
- תעשיות
- תעשייה
- מידע
- תשתית
- השתלבות
- מִמְשָׁק
- אינטרנט
- בדידות
- IT
- הילדים
- תוויות
- עוֹפֶרֶת
- למידה
- רמה
- קו
- לינוקס
- מכונה
- למידת מכונה
- ניהול
- מנהל
- ניהול
- יַצרָן
- מפות
- מתימטיקה
- ML
- מודל
- מודלים
- רוב
- רשת
- ניו יורק
- תפעול
- אפשרות
- תזמור
- ארגון
- ארגונים
- אחר
- שותף
- שותפים
- מדיניות
- מדיניות
- התחזיות
- מנהל
- פְּרָטִי
- תהליך
- תהליכים
- הפקה
- מוצרים
- פּרוֹיֶקט
- קניינית
- .
- מספק
- ציבורי
- למטרות
- איכות
- לקבל
- ממליצה
- הפחתה
- רגולטורים
- לשחרר
- לדרוש
- דרישות
- משאב
- משאבים
- תוצאות
- סיכונים
- ריצה
- סולם
- Sdk
- לבטח
- אבטחה
- מדיניות אבטחה
- שרות
- שירותים
- סט
- שיתוף
- משותף
- שיתופים
- פָּשׁוּט
- מידה
- פתרונות
- מתמחה
- במיוחד
- התחלה
- חברות סטארט
- מדינה
- הצהרה
- אחסון
- חנות
- אסטרטגיות
- סטודנט
- תמיכה
- תומך
- מתג
- מערכות
- נבחרת
- טק
- טכנולוגיה
- מבחן
- דרך
- זמן
- הדרכה
- מעבר
- תרגום
- סומך
- ייחודי
- להשתמש
- ערך
- וירטואלי
- חזון
- VPN
- גלים
- אתר
- אתרים
- מה
- בתוך
- לְלֹא
- עובד
- עובד
- שנים