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