העיקרון הזה הוא חלק מעמודת הקיימות ב-Google Cloud Well-Architected Framework, ומספק המלצות שיעזרו לכם לשפר את השימוש במשאבים של עומסי העבודה ב- Google Cloud.
סקירה כללית של העקרונות
אופטימיזציה של השימוש במשאבים היא חיונית לשיפור הקיימות של סביבת הענן. כל משאב שמקצים – החל ממחזורי מחשוב ועד לאחסון נתונים – משפיע ישירות על צריכת האנרגיה, על עוצמת השימוש במים ועל פליטת הפחמן. כדי לצמצם את טביעת הרגל הסביבתית של עומסי העבודה, צריך לקבל החלטות מושכלות כשמקצים משאבים בענן, מנהלים אותם ומשתמשים בהם.
המלצות
כדי לבצע אופטימיזציה של השימוש במשאבים, כדאי לעיין בהמלצות שבקטעים הבאים.
הטמעה של שינוי גודל אוטומטי ודינמי
שינוי גודל אוטומטי ודינמי מבטיח שימוש אופטימלי במשאבים, וכך עוזר למנוע בזבוז אנרגיה כתוצאה מתשתית לא פעילה או מוגזמת. הפחתת בזבוז האנרגיה מובילה לעלויות נמוכות יותר ולפליטות פחמן נמוכות יותר.
כדי להטמיע התאמה אוטומטית ודינמית של נפח האחסון, אפשר להשתמש בטכניקות הבאות.
שימוש בהרחבה אופקית
הגדלת הקיבולת לרוחב היא טכניקת ההתאמה לעומס המועדפת לרוב האפליקציות שנוצרו קודם כל לענן. במקום להגדיל את הגודל של כל מופע, מה שנקרא הגדלת הקיבולת לאורך, מוסיפים מופעים כדי לחלק את העומס. לדוגמה, אפשר להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG) כדי להגדיל באופן אוטומטי את הקיבולת של קבוצת מכונות וירטואליות ב-Compute Engine. תשתית עם קיבולת מוגדלת לרוחב היא עמידה יותר, כי כשל במופע לא משפיע על הזמינות של האפליקציה. הגדלת הקיבולת לרוחב היא גם טכניקה יעילה מבחינת משאבים לאפליקציות עם רמות עומס משתנות.
הגדרת מדיניות מתאימה להרחבת נפח האחסון
כדאי להגדיר את ההגדרות של התאמה אוטומטית לעומס בהתאם לדרישות של עומסי העבודה. מומלץ להגדיר מדדים וערכי סף מותאמים אישית שספציפיים להתנהגות האפליקציה. במקום להסתמך רק על ניצול המעבד, כדאי להשתמש במדדים כמו עומק התור למשימות אסינכרוניות, זמן האחזור של הבקשה ומדדים מותאמים אישית של האפליקציה. כדי למנוע שינוי גודל תכוף ולא נחוץ או שינוי גודל מהיר מדי, כדאי להגדיר מדיניות ברורה לשינוי גודל. לדוגמה, לעומסי עבודה שפורסים ב-Google Kubernetes Engine (GKE), כדאי להגדיר מדיניות מתאימה לשינוי גודל האשכול.
שילוב של התאמות ריאקטיביות ופרואקטיביות
בשינוי גודל תגובתי, המערכת משנה את הגודל שלה בתגובה לשינויים בעומס בזמן אמת. הטכניקה הזו מתאימה לאפליקציות שבהן יש עליות בלתי צפויות בעומס.
התאמת קנה מידה פרואקטיבית מתאימה לעומסי עבודה עם דפוסים צפויים, כמו שעות פעילות קבועות ביום ויצירת דוחות שבועיים. לעומסי עבודה כאלה, כדאי להשתמש בהתאמת קנה מידה אוטומטית מתוזמנת כדי להקצות מראש משאבים שיכולים להתמודד עם רמת עומס צפויה. הטכניקה הזו מונעת מאבק על משאבים ומבטיחה חוויית משתמש חלקה יותר עם יעילות גבוהה יותר. היא גם עוזרת לתכנן באופן פרואקטיבי שיאים ידועים בעומס, כמו אירועי מכירות גדולים ומאמצי שיווק ממוקדים.
Google Cloud שירותים ותכונות מנוהלים כמו GKE Autopilot, Cloud Run ו-MIG מנהלים באופן אוטומטי את שינוי הגודל הפרואקטיבי על סמך דפוסי עומס העבודה. כברירת מחדל, אם שירות Cloud Run לא מקבל תנועה, הוא מתרחב לאפס מופעים.
עיצוב אפליקציות ללא מצב
כדי שאפליקציה תהיה ניתנת להרחבה אופקית, הרכיבים שלה צריכים להיות חסרי מצב. המשמעות היא שהסשן או הנתונים של משתמש ספציפי לא מקושרים למופע מחשוב יחיד. כשמאחסנים את מצב הסשן מחוץ למופע המחשוב, למשל ב-Memorystore for Redis, כל מופע מחשוב יכול לטפל בבקשות של כל משתמש. גישת העיצוב הזו מאפשרת הרחבה אופקית חלקה ויעילה.
שימוש בתזמון ובקבוצות
עיבוד באצווה מתאים במיוחד לעומסי עבודה גדולים ולא דחופים. משימות באצווה יכולות לעזור לכם לבצע אופטימיזציה של עומסי העבודה מבחינת יעילות אנרגטית ועלות.
כדי להטמיע תזמון ועבודות אצווה, אפשר להשתמש בטכניקות הבאות.
תזמון לשיעור פליטת פחמן נמוך
כדאי לתזמן את משימות האצווה כך שיפעלו באזורים דלי-פחמן ובפרקי זמן שבהם אחוז האנרגיה הנקייה ברשת החשמל המקומית גבוה. כדי לזהות את השעות במהלך היום שבהן פליטת הפחמן באזור מסוים היא הנמוכה ביותר, אפשר להשתמש בדוח טביעת הרגל הפחמנית.
שימוש במכונות וירטואליות במודל Spot לעומסי עבודה לא קריטיים
Spot VMs מאפשרות לכם ליהנות מקיבולת לא מנוצלת של Compute Engine בהנחה משמעותית. יכול להיות שיתבצע ניתוק של מכונות וירטואליות מסוג Spot, אבל הן מספקות דרך חסכונית לעבד מערכי נתונים גדולים בלי צורך במשאבים ייעודיים שפועלים תמיד. מכונות Spot VM הן אידיאליות למשימות באצווה שהן לא קריטיות ועמידות בכשלים.
איחוד משימות והרצה מקבילה שלהן
כדי לצמצם את התקורה של הפעלה וסגירה של משימות בודדות, כדאי לקבץ משימות דומות לחבילה גדולה אחת. כדאי להריץ את עומסי העבודה האלה בנפח גבוה בשירותים כמו Batch. השירות מקצה ומנהל אוטומטית את התשתית הנדרשת, וכך עוזר להבטיח ניצול אופטימלי של המשאבים.
שימוש בשירותים מנוהלים
שירותים מנוהלים כמו Batch ו-Dataflow מטפלים באופן אוטומטי בהקצאת משאבים, בתזמון ובמעקב. פלטפורמת הענן מטפלת באופטימיזציה של המשאבים. אתם יכולים להתמקד בלוגיקה של האפליקציה. לדוגמה, Dataflow משנה את מספר העובדים באופן אוטומטי על סמך נפח הנתונים בצינור, כך שלא תשלמו על משאבים לא פעילים.
התאמה של משפחות מכונות וירטואליות לדרישות של עומס העבודה
סוגי המכונות שבהם אפשר להשתמש במכונות וירטואליות ב-Compute Engine מקובצים במשפחות של מכונות, שעברו אופטימיזציה לעומסי עבודה שונים. בחירת משפחות מכונות מתאימות בהתאם לדרישות של עומסי העבודה.
| משפחת מכונות | מומלץ לסוגים של עומסי עבודה | הנחיות בנושא קיימוּת |
|---|---|---|
| מכונות למטרות כלליות (E2, N2, N4, Tau T2A/T2D): המכונות האלה מספקות יחס מאוזן בין מעבד לזיכרון. | שרתי אינטרנט, מיקרו-שירותים, מסדי נתונים קטנים עד בינוניים וסביבות פיתוח. | סדרת E2 היא חסכונית מאוד בעלויות ובאנרגיה, כי המשאבים מוקצים באופן דינמי. סדרת Tau T2A משתמשת במעבדים מבוססי-Arm, שלרוב יעילים יותר מבחינת צריכת אנרגיה לכל יחידת ביצועים בעומסי עבודה גדולים. |
| מכונות מותאמות לצריכת מעבד גבוהה (C2, C3): המכונות האלה מספקות יחס גבוה בין מעבד וירטואלי לזיכרון וביצועים גבוהים לכל ליבה. | מחשוב עתיר ביצועים (HPC), עיבוד באצווה, שרתים למשחקים, וניתוח נתונים מבוסס-CPU. | מכונת C-series מאפשרת להשלים משימות שדורשות הרבה משאבי CPU מהר יותר, וכך מקצרת את זמן החישוב הכולל ומפחיתה את צריכת האנרגיה של העבודה. |
| מכונות מותאמות לצריכת זיכרון גבוהה (memory-optimized) (M3, M2): המכונות האלה מיועדות לעומסי עבודה שדורשים כמות גדולה של זיכרון. | מסדי נתונים גדולים בזיכרון ומחסני נתונים, כמו SAP HANA או ניתוח נתונים בזיכרון. | מכונות וירטואליות מותאמות לצריכת זיכרון גבוהה (memory-optimized) מאפשרות לאחד עומסי עבודה שצורכים הרבה זיכרון בפחות צמתים פיזיים. האיחוד הזה מצמצם את סך האנרגיה שנדרשת בהשוואה לשימוש בכמה מופעים קטנים יותר. זיכרון עם ביצועים גבוהים מקטין את זמן האחזור של הגישה לנתונים, מה שיכול להקטין את הזמן הכולל שהמעבד מבלה במצב פעיל. |
| מכונות שמותאמות לאחסון (Z3): המכונות האלה מספקות אחסון מקומי בכונני SSD עם תפוקה גבוהה וזמן אחזור נמוך. | מחסני נתונים, ניתוח יומנים ומסדי נתונים של SQL, NoSQL ווקטורים. | מכונות שמותאמות לאחסון מעבדות קבוצות נתונים גדולות באופן מקומי, וכך עוזרות לחסוך באנרגיה שמשמשת לתעבורת נתונים יוצאת (egress) ברשת בין מיקומים שונים. כשמשתמשים באחסון מקומי למשימות עם IOPS גבוה, נמנעים מהקצאת יתר של כמה מכונות רגילות. |
| מכונות שעברו אופטימיזציה לשימוש במאיצים (A3, A2, G2): המכונות האלה מיועדות לעומסי עבודה שמוגברים על ידי GPU ו-TPU, כמו AI, ML ו-HPC. | אימון והסקת מסקנות של מודלים ללמידת מכונה (ML), וסימולציות מדעיות. | TPU מתוכננים ליעילות אנרגטית אופטימלית. הם מספקים יותר חישובים לכל וואט. מופע עם שיפור מהירות באמצעות GPU, כמו סדרת A3 עם מעבדי GPU מסוג NVIDIA H100, יכול להיות חסכוני יותר באנרגיה באופן משמעותי לאימון מודלים גדולים בהשוואה לחלופה עם מעבד בלבד. למרות שמופע עם שיפור מהירות באמצעות GPU צורך יותר חשמל באופן נומינלי, המשימה מושלמת הרבה יותר מהר. |
שדרוג לסוגי המכונות העדכניים ביותר
שימוש בסוגי המכונות העדכניים ביותר עשוי לעזור לשפר את הקיימות. כשסוגי המכונות מתעדכנים, הם בדרך כלל מתוכננים להיות חסכוניים יותר באנרגיה ולספק ביצועים טובים יותר לוואט. יכול להיות שמכונות וירטואליות שמשתמשות בסוגי המכונות העדכניים ביותר יבצעו את אותה כמות עבודה עם צריכת חשמל נמוכה יותר.
למעבדי CPU, GPU ו-TPU יש בדרך כלל יתרון משיפורים טכניים בארכיטקטורת השבבים, כמו:
- ליבות מיוחדות: שיפורים במעבדים כוללים לעיתים קרובות ליבות מיוחדות או הוראות לעומסי עבודה נפוצים. לדוגמה, למעבדים עשויים להיות ליבות ייעודיות לפעולות וקטוריות או מאיצי AI משולבים. כשמורידים את העומס של המשימות האלה מה-CPU הראשי, המשימות מושלמות בצורה יעילה יותר וצריכת האנרגיה שלהן נמוכה יותר.
- ניהול צריכת חשמל משופר: שיפורים בארכיטקטורות של שבבים כוללים לרוב תכונות מתקדמות יותר לניהול צריכת חשמל, כמו התאמה דינמית של המתח והתדר על סמך עומס העבודה. התכונות האלה לניהול צריכת הסוללה מאפשרות לשבבים לפעול ביעילות מקסימלית ולהיכנס למצבי צריכת הסוללה נמוכה כשהם לא פעילים, וכך לצמצם את צריכת האנרגיה.
השיפורים הטכניים בארכיטקטורת השבבים מספקים את היתרונות הישירים הבאים בתחום הקיימות והעלויות:
- ביצועים טובים יותר לוואט: זהו מדד מרכזי לקיימות. לדוגמה, מכונות ה-VM מסוג C4 מניבות ביצועים טובים יותר ב-40% ביחס למחיר בהשוואה למכונות ה-VM מסוג C3, באותה צריכת אנרגיה. מעבד C4A מספק יעילות אנרגטית גבוהה ב-60% בהשוואה למעבדי x86 דומים. יכולות הביצועים האלה מאפשרות לכם להשלים משימות מהר יותר או להשתמש בפחות מקרים לאותה עומס עבודה.
- צריכת אנרגיה כוללת נמוכה יותר: מעבדים משופרים מאפשרים להשתמש במשאבי מחשוב למשך זמן קצר יותר עבור משימה נתונה, וכך לצמצם את צריכת האנרגיה הכוללת ואת טביעת הרגל הפחמנית. השלכות של פליטת פחמן גבוהות במיוחד בעומסי עבודה קצרי-חיים ועתירי-חישובים, כמו משימות באצווה ואימון מודלים של ML.
- ניצול אופטימלי של משאבים: סוגי המכונות העדכניים מתאימים יותר לתוכנות מודרניות, ויש להם תאימות טובה יותר לתכונות מתקדמות של פלטפורמות ענן. סוגי המכונות האלה בדרך כלל מאפשרים ניצול טוב יותר של משאבים, מה שמקטין את הצורך בהקצאת יתר של משאבים ועוזר לוודא שכל וואט של חשמל מנוצל בצורה יעילה.
פריסת אפליקציות בקונטיינרים
אתם יכולים להשתמש בשירותים מנוהלים מלאים שמבוססים על קונטיינרים, כמו GKE ו-Cloud Run, כחלק מהאסטרטגיה שלכם לשימוש בר-קיימא במחשוב ענן. השירותים האלה עוזרים לייעל את ניצול המשאבים ולאוטומט את ניהול המשאבים.
שימוש ביכולת של Cloud Run לצמצם את הפעולה לאפס
Cloud Run מספק סביבה מנוהלת ללא שרתים, שבה המערכת מתאימה את מספר המופעים באופן אוטומטי לאפס כשאין תנועה נכנסת לשירות או כשמשימה מסתיימת. התאמה אוטומטית לעומס עוזרת לצמצם את צריכת האנרגיה של תשתית לא פעילה. המשאבים מופעלים רק כשהם מעבדים בקשות באופן פעיל. האסטרטגיה הזו יעילה מאוד לעומסי עבודה לסירוגין או לעומסי עבודה מבוססי-אירועים. לעומסי עבודה של AI, אפשר להשתמש במעבדי GPU עם Cloud Run, וכך לשלם רק על השימוש במעבדי GPU.
אוטומציה של אופטימיזציה של משאבים באמצעות GKE
GKE היא פלטפורמה לתזמור קונטיינרים, שמבטיחה שהאפליקציות ישתמשו רק במשאבים שהן צריכות. כדי לעזור לכם להפוך את האופטימיזציה של המשאבים לאוטומטית, GKE מספק את הטכניקות הבאות:
- Bin packing: GKE Autopilot אורז בצורה חכמה כמה קונטיינרים בצמתים הזמינים. השיטה הזו ממקסמת את הניצול של כל צומת ומצמצמת את מספר הצמתים שלא מנוצלים או שמנוצלים באופן חלקי, וכך עוזרת לצמצם את צריכת האנרגיה.
- התאמה אופקית של קבוצות Pod לעומס (HPA): באמצעות HPA, מספר הרפליקות של הקונטיינרים (Pods) מותאם באופן אוטומטי על סמך מדדים מוגדרים מראש, כמו שימוש במעבד או מדדים מותאמים אישית שספציפיים לאפליקציה. לדוגמה, אם יש עלייה פתאומית בתנועה לאפליקציה, GKE מוסיף Pods כדי לעמוד בביקוש. כשהעומס בתנועה יורד, GKE מקטין את מספר ה-Pods. השינוי הדינמי של קנה המידה מונע הקצאת יתר של משאבים, כך שלא תצטרכו לשלם על קיבולת מיותרת של מחשוב או להפעיל אותה.
- התאמה אנכית של קבוצות Pod לעומס (VPA): אפשר להגדיר את GKE כך שישנה באופן אוטומטי את הקצאות ה-CPU והזיכרון ואת המגבלות של קונטיינרים בודדים. ההגדרה הזו מבטיחה שלא יוקצו לקונטיינר יותר משאבים ממה שהוא צריך, וכך עוזרת למנוע הקצאת יתר של משאבים.
- GKE multidimensional Pod autoscaling: עבור עומסי עבודה מורכבים, אפשר להגדיר HPA ו-VPA בו-זמנית כדי לבצע אופטימיזציה של מספר ה-Pods ושל הגודל של כל Pod. הטכניקה הזו עוזרת להבטיח את טביעת הרגל האנרגטית הקטנה ביותר האפשרית לביצועים הנדרשים.
- Topology-Aware Scheduling (TAS): TAS משפר את יעילות הרשת עבור עומסי עבודה של AI ו-ML ב-GKE על ידי מיקום של Pod על סמך המבנה הפיזי של תשתית מרכז הנתונים. TAS ממקם עומסי עבודה באופן אסטרטגי כדי לצמצם את מספר הקפיצות ברשת. המיקום המשותף הזה עוזר להפחית את זמן האחזור של התקשורת ואת צריכת האנרגיה. באמצעות אופטימיזציה של ההתאמה הפיזית בין הצמתים ובין החומרה הייעודית, TAS מזרזת את השלמת המשימות וממקסמת את היעילות האנרגטית של עומסי עבודה גדולים של AI ו-ML.
הגדרת תזמון שמביא בחשבון את פליטת הפחמן
ב-Google, אנחנו מעבירים כל הזמן את עומסי העבודה שלנו למיקומים ולשעות שבהם החשמל הכי נקי. אנחנו גם משתמשים מחדש בציוד ישן יותר או ממחזרים אותו לתרחישי שימוש חלופיים. אתם יכולים להשתמש באסטרטגיית תזמון שמודעת לפליטת פחמן כדי לוודא שעומסי העבודה שלכם במאגרי קונטיינרים משתמשים באנרגיה נקייה.
כדי להטמיע תזמון שמודע לפליטת פחמן, צריך לקבל בזמן אמת מידע על תמהיל האנרגיה שמפעיל את מרכזי הנתונים באזור מסוים. אפשר לקבל את המידע הזה בפורמט שניתן לקריאה על ידי מכונה ממאגר האנרגיה נטולת הפחמן לאזורים Google Cloud ב-GitHub או ממערך נתונים ציבורי ב-BigQuery. הנתונים השעתיים לגבי תמהיל רשת החשמל ושיעור פליטת הפחמן שמשמשים לחישוב מערך הנתונים השנתי של Google לגבי פליטות פחמן מגיעים מ-Electricity Maps.
כדי להטמיע תזמון שמודע לפליטת פחמן, מומלץ להשתמש בטכניקות הבאות:
- העברה גיאוגרפית: מתזמנים את עומסי העבודה להפעלה באזורים שבהם נעשה שימוש בחלק גדול יותר של מקורות אנרגיה מתחדשים. הגישה הזו מאפשרת לכם להשתמש ברשתות חשמל נקיות יותר.
- הזזה זמנית: לעומסי עבודה לא קריטיים וגמישים, כמו עיבוד אצווה, מגדירים את עומסי העבודה כך שיפעלו בשעות שאינן שעות שיא או כשיש הכי הרבה אנרגיה מתחדשת. הגישה הזו נקראת שינוי זמני, והיא עוזרת להפחית את טביעת הרגל הפחמנית הכוללת על ידי ניצול מקורות אנרגיה נקיים יותר כשהם זמינים.
תכנון תוכנית התאוששות מאסון (DR) חסכונית באנרגיה
ההכנה לתוכנית התאוששות מאסון (DR) כוללת לעיתים קרובות הקצאה מראש של משאבים מיותרים באזור משני. עם זאת, משאבים לא פעילים או כאלה שלא מנוצלים מספיק עלולים לגרום לבזבוז משמעותי של אנרגיה. כדאי לבחור אסטרטגיות DR שממקסמות את ניצול המשאבים וממזערות את ההשלכות של פליטת פחמן בלי לפגוע ביעדי זמן ההתאוששות (RTO).
אופטימיזציה של יעילות ההפעלה במצב התחלתי (cold start)
כדי לצמצם את מספר המשאבים הפעילים באזור המשני (DR) או לבטל אותם, אפשר להשתמש בגישות הבאות:
- עדיפות לDR במצב לא פעיל: משאירים את המשאבים באזור ה-DR כבויים או במצב של שינוי גודל לאפס. הגישה הזו עוזרת לצמצם את טביעת הרגל הפחמנית של משאבי מחשוב לא פעילים.
- ניצול יתרונות של מעבר לגיבוי במקרה של כשל (failover) ללא שרתים: שימוש בשירותים מנוהלים ללא שרתים כמו Cloud Run לנקודות קצה של DR. שירות Cloud Run מתרחב לאפס כשלא משתמשים בו, כך שאפשר לשמור על טופולוגיית DR שלא צורכת אנרגיה עד שהתנועה מופנית לאזור ה-DR.
- אוטומציה של השחזור באמצעות תשתית כקוד (IaC): במקום להשאיר את המשאבים באתר DR במצב פעיל (warm), אפשר להשתמש בכלי IaC כמו Terraform כדי להקצות סביבות במהירות רק כשצריך.
איזון בין יתירות לניצול
יתירות של משאבים היא הגורם העיקרי לבזבוז אנרגיה. כדי לצמצם את היתירות, אפשר להשתמש בגישות הבאות:
- עדיף להשתמש בגישה פעילה-פעילה במקום בגישה פעילה-פסיבית: בהגדרה פעילה-פסיבית, המשאבים באתר הפסיבי לא פעילים, ולכן יש בזבוז של אנרגיה. ארכיטקטורה פעילה-פעילה בגודל אופטימלי מבטיחה שכל המשאבים שהוקצו בשני האזורים ישרתו באופן פעיל את התנועה. הגישה הזו עוזרת למקסם את היעילות האנרגטית של התשתית.
- התאמת יתירות: משכפלים נתונים ושירותים באזורים רק כשנדרש שכפול כדי לעמוד בדרישות של זמינות גבוהה או של DR. כל רפליקה נוספת מגדילה את עלות האנרגיה של אחסון מתמיד ושל תעבורת נתונים יוצאת (egress).