בדף הזה מוסבר על השיטות המומלצות ליצירת ארכיטקטורה מרובת דיירים לאירוח קוד לא מהימן באמצעות Cloud Run. בתור לקוח Google Cloud , 'דייר' מוגדר כאחד הלקוחות שלכם, ו'קוד לא מהימן' הוא קוד שסופק על ידי הדיירים האלה להרצה בפלטפורמה שלכם.
תרחישים לדוגמה
תרחישי שימוש בארכיטקטורות כאלה כוללים:
- פלטפורמות לאירוח אפליקציות: אתם מספקים פלטפורמה שבה הלקוחות שלכם יכולים לפרוס את הקוד שלהם. לדוגמה, פלטפורמת אירוח באינטרנט (הלקוחות מספקים שרת אינטרנט) או פלטפורמת Functions-as-a-Service (הלקוחות מספקים פונקציה).
- פלטפורמות לאירוח סוכנים: הלקוחות שלכם משתמשים בערכות SDK כדי לבנות סוכני AI, והפלטפורמה שלכם מריצה אותם ברקע.
- פלטפורמות של מודלים שעברו כוונון עדין: אתם מציעים אפשרות להתאים אישית מודלים של AI לכל לקוח בנפרד. הפלטפורמה מריצה אותם לפי דרישה באמצעות מעבדי GPU.
- פונקציות בהגדרת המשתמש (UDF): התוכנה מאפשרת ללקוחות להגדיר לוגיקה מותאמת אישית באמצעות קוד. לדוגמה, אתם מספקים מנוע ניתוח ורוצים לאפשר ללקוחות לכתוב פונקציות בהתאמה אישית, או שאתם מספקים שער API ורוצים לאפשר ללקוחות לסנן או לשנות בקשות על סמך לוגיקה מותאמת אישית משלהם.
- הרחבת תוכנה כשירות (SaaS): יכול להיות שאתם מציעים SaaS ורוצים לאפשר ללקוחות להרחיב את היכולות שלו באמצעות תוספים. יכול להיות שהתוספים האלה נכתבו על ידי לקוחות או שותפים.
Google Cloud לקוחות משתמשים בהצלחה ב-Cloud Run בסביבת ייצור בתרחישים לדוגמה האלה.
אתגרים של פלטפורמות מרובות דיירים
האתגרים הנפוצים ביצירת ארכיטקטורה כזו כוללים:
- אבטחה: אי אפשר לסרוק או לנקות את הקוד שסופק. קוד לא מהימן יכול לכלול פעולות זדוניות או תלות פגיעה. אם הקוד הלא מהימן לא מבודד בצורה נכונה, הוא עלול לגשת למידע אישי רגיש ששייך לדיירים אחרים. אריזת הקוד במאגר לא מספקת גבול אבטחה חזק מספיק. צריך גם להגביל את הפעולות שהקוד יכול לבצע באמצעות העיקרון של הרשאות מינימליות.
- יעילות עלות: ארכיטקטורה כזו עלולה להיות יקרה אם כל דייר נושא בעלויות קבועות עבור הפלטפורמה שלכם.
- ניהול דיירים: ניהול של מאות אלפי דיירים יכול להיות מורכב, במיוחד כשמדובר במחיקת נתונים.
היתרונות של Cloud Run
ארכיטקטורה שמבוססת על Cloud Run מציעה פתרון לאתגרים נפוצים עם יתרונות רבים, כמו אבטחה, יעילות בעלויות וניהול דיירים.
אבטחה
Cloud Run מספק תכונות אבטחה מוכנות לשימוש שרלוונטיות לארכיטקטורה הזו:
- בידוד של משאבי מחשוב: ב-Cloud Run יש בידוד קפדני בין מופעי קונטיינרים, בין אם הם שייכים לאותו שירות או לשירותים שונים מפרויקטים שונים. מידע נוסף על אבטחת קונטיינרים וסביבות הרצה זמין במאמר סקירה כללית על תכנון האבטחה.
- עדכוני אבטחה: אפשר להפעיל עדכוני אבטחה אוטומטיים של תמונות בסיס כדי שמערכת ההפעלה וזמן הריצה של עומסי העבודה שנפרסו יהיו מעודכנים ויתוקנו בלי שיהיה צורך בפריסות מחדש בקנה מידה גדול.
- בידוד רשת: Cloud Run לא רק מפעיל את הקונטיינרים בסביבת ארגז חול, אלא גם מספק מחסנית רשת מרובת דיירים.
- זהות שירות: אפשר להגדיר לעומסי עבודה ב-Cloud Run זהויות ייעודיות עם הרשאות מוגבלות.
עלות-תועלת
- צמצום הפעולה לאפס ותשלום לפי שימוש: מופעים של Cloud Run מצטמצמים אוטומטית לאפס כשלא נעשה בהם שימוש, וכך עומסי עבודה מתארחים מחויבים רק כשהם צריכים לפעול. כך מתקבל ניצול יעיל מאוד של המשאבים בהשוואה לארכיטקטורות שמסתמכות על מכונות וירטואליות שפועלות כל הזמן.
- חיוב לפי בקשה: בנוסף לאפשרות של שינוי קנה מידה לאפס, אתם יכולים ליהנות ממודל חיוב מפורט עוד יותר שבו החיוב מתבצע רק כשבקשות מעובדות, וכך להשיג יעילות גבוהה יותר בעלויות.
- הפעלה מהירה לפי דרישה: כשמצמצמים את קנה המידה, שירותי Cloud Run יכולים להגדיל אותו במהירות, כך שמשתמש הקצה של האפליקציה שנפרסה לא יחווה זמן אחזור ארוך.
- תיוג אוטומטי של עלויות: כל העלויות שמדווחות על ידי Cloud Run מתויגות, כך שתוכלו להקצות עלויות ולעקוב אחרי הדיירים באופן אוטומטי.
- התחייבויות להוזלת העלויות הכוללות: ברמת החשבון לחיוב, אפשר להשתמש בהנחות תמורת התחייבות גמישה לשימוש כדי לייעל את ההוצאות על כל שימוש בסיסי ב-Cloud Run.
ניהול דיירים
בגלל האופי של Cloud Run, שמאפשר שימוש לפי דרישה, העלויות לא גבוהות יותר כשמשתמשים בכמה פרויקטים של Google Cloud , וכך אפשר לנהל דיירים כמו שמתואר במאמר ארגון הפרויקטים של Google Cloud .
ארכיטקטורת טירגוט לפלטפורמות מרובות דיירים
ברמת העל, זו הארכיטקטורה המומלצת:
ארגון הפרויקטים ב- Google Cloud
צריך להגדיר Google Cloud ארגון וחיוב אופליין, ולפנות לצוות ניהול החשבון כדי ליידע אותו שאתם פועלים כחשבון מפיץ. יכול להיות ש-Google Cloud ישתף איתכם פעולה כדי לוודא שמוגדרים ערוצי תקשורת מתאימים לצמצום התנהלות פוגעת.
חובה להשתמש בתיקיות כדי לארגן את הפרויקטים. חשוב במיוחד להפריד בין הפרויקטים שמריצים את הקוד של הצד הראשון לבין הפרויקטים שמריצים קוד לא מהימן של הדיירים. Google Cloud צריך להפוך את צירוף הדיירים לאוטומטי, כך שלא יהיה צורך בהתערבות אנושית כדי ליצור את הפרויקטים והמשאבים של הדייר.
Google ממליצה להשתמש בפרויקט אחד לכל דייר. Google Cloud אפשר גם לארח כמה דיירים באותו פרויקט, אבל יש לכך מגבלות נוספות:
דייר יחיד לכל Google Cloud פרויקט (מומלץ)
בארכיטקטורה הזו, כל דייר בפלטפורמה מתארח בGoogle Cloud פרויקט ייעודי, ויש לכך יתרונות רבים:
- אבטחה פשוטה יותר: הפרויקט ב- Google Cloud הוא גבול ברור לכל המשאבים שהוא מכיל. המשמעות היא שאם לדייר מסוים נדרשת גישה למספר משאבים שלGoogle Cloud , כמו מספר שירותי Cloud Run או קטגוריה של Cloud Storage, אפשר להשתמש בפרויקט כגבול מאובטח.
- פחות מוגבל:
- מספר המשאבים בפרויקט נתון מוגבל. לדוגמה, ב-Cloud Run אפשר ליצור רק 1,000 שירותים לכל אזור בפרויקט. יש הגבלות דומות על מספר חשבונות השירות ומשאבים קשורים אחרים.
- מספר הפרויקטים הוא מכסה בפני עצמו, ואפשר להגדיל אותו. אין מגבלות על המספר הזה בארגון Google Cloud . יש מגבלה רכה של 100,000 פרויקטים לכל חשבון לחיוב, ואפשר להגדיל אותה על ידי פנייה אל Google. הארגון שלכם יכול גם ליצור הרבה חשבונות לחיוב ולקבץ אותם ב'קבוצת חשבונות' (כרגע בתצוגה מקדימה פרטית).
- מעקב וניהול פשוטים יותר:
- שימוש בפרויקט לכל דייר מאפשר תהליכי מחיקת נתונים פשוטים יותר, כי מחיקת נתונים של דייר מסתכמת במחיקת הפרויקט הרלוונטי.
- Google Cloud השירותים Monitoring ו-Logging פועלים בכל הפרויקטים ויכולים לאפשר לכם לעקוב אחרי כלל המכשירים בארגון.
- מכסות ברמת הפרויקט מאפשרות לכם להגביל את השימוש במשאבי Cloud Run לדייר מסוים, ואולי להתאים את המגבלות לחבילות התמחור שלכם.
- מדיניות ארגונית בהתאמה אישית מאפשרת להחיל על כל הפרויקטים בתיקייה הגבלות ספציפיות, כמו אזורים זמינים או הקצאה מקסימלית של CPU או זיכרון.
יצירת פרויקט ואתחול של ממשקי API ומשאבים עלולים לגרום לזמן אחזור. Google ממליצה להשתמש במאגר של פרויקטים שנוצרו מראש ולהקצות אותם לדיירים כשצריך. Google Cloud
מספר דיירים לכל Google Cloud פרויקט (לא מומלץ)
אפשר לארח כמה דיירים באותו פרויקט Google Cloud, אבל Google לא ממליצה על הארכיטקטורה הזו.
לשירותים רבים Google Cloud יש מגבלות משאבים לכל פרויקט. לדוגמה, ב-Cloud Run יש מגבלה שלא ניתן לשנות של 1,000 שירותי Cloud Run לכל אזור בפרויקט. לכן, אירוח של כמה דיירים בכל פרויקט עדיין יחייב אתכם לנהל מספר פרויקטים, מה שיגדיל את מורכבות ניהול הדיירים. Google Cloud מבחינת אבטחה, פרויקטים מתוכננים כגבול אבטחה. אם מארחים שני דיירים נפרדים באותם פרויקטים, צריך להיות זהירים יותר בכל מה שקשור לאבטחה.Google Cloud לדוגמה, באמצעות הקפדה על שימוש בחשבונות שירות ייעודיים ובהרשאות מפורטות.
ניתוב בקשות ודומיינים מותאמים אישית
אם רוצים לחשוף את שירותי Cloud Run של הדייר למשתמשי קצה, צריך להוסיף דומיין משלכם ולהשתמש בלוגיקה משלכם לניתוב. לדוגמה, כדי למפות תת-דומיין ל Google Cloud פרויקט שמארח את השירות של הדייר.
אפשר להטמיע שירות ניתוב מותאם אישית, אבל Google ממליצה להשתמש במאזן עומסים גלובלי חיצוני לאפליקציות עם Service Extensions ללוגיקת ניתוב. אפשר להטמיע Service Extensions כתוספים (כשהלוגיקה מופעלת בשורה עם עיבוד הבקשה) או כהפניות (הלוגיקה של הניתוב מועברת לשירות נפרד של Cloud Run שיכול לקרוא לאחד ממסדי הנתונים הרב-אזוריים שלGoogle Cloudשניתנים להתאמה לעומס, כמו Spanner).
שימוש במאזן עומסים של אפליקציות יאפשר לכם גם להוסיף שכבת מטמון באמצעות Cloud CDN, ולהוסיף הגנה מפני מתקפות מניעת שירות מבוזרות (DDoS) לפלטפורמה שלכם באמצעות Cloud Armor.
מוניטין וניצול לרעה
כל פלטפורמת אירוח שמאפשרת להריץ קוד לא מהימן חשופה לניצול לרעה.
מומלץ להשתמש בחשבון אחר לחיוב ב-Cloud לכל אחת מרמות המוניטין שאתם מציעים. לדוגמה, לא כדאי לקשר את הדיירים ברמה החינמית לאותו חשבון לחיוב שאליו מקושרים לקוחות שמשלמים סכומים גבוהים. Google יכולה להתייחס לחשבונות חיוב כאלה ברמות מוניטין שונות.
כפי שמתואר במאמר ארגון הפרויקטים Google Cloud , בנוסף להפרדה לפי חשבונות לחיוב, מומלץ להשתמש בתיקיות כדי לארגן את הפרויקטים. Google יכולה לעזור לכם להגדיר מכסות ברמת התיקייה כדי להבטיח שכל המשאבים בתיקייה לא יצרכו יותר מהמקסימום שהוגדר, וכך תוכלו לנהל טוב יותר את העלויות בפלטפורמה.
כברירת מחדל, Google מסירה באופן אוטומטי עומסי עבודה פוגעניים בהתאם לתנאים ולהגבלות שלGoogle Cloud . Google יכולה גם לרשום ב-Cloud Logging אירועים של זיהוי התנהלות פוגעת, ואז תוכלו לפעול בהתאם.