העיקרון הזה, שנכלל בעמודה 'קיימות' של Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לשפר את השימוש במשאבים של עומסי העבודה ב- Google Cloud.
סקירה כללית של העקרונות
אופטימיזציה של השימוש במשאבים היא חיונית לשיפור הקיימות של סביבת הענן. כל משאב שמקצים – החל ממחזורי מחשוב ועד לאחסון נתונים – משפיע ישירות על צריכת האנרגיה, על עוצמת השימוש במים ועל פליטת הפחמן. כדי לצמצם את טביעת הרגל הסביבתית של עומסי העבודה, צריך לקבל החלטות מושכלות כשמקצים משאבים בענן, מנהלים אותם ומשתמשים בהם.
המלצות
כדי לבצע אופטימיזציה של השימוש במשאבים, כדאי לעיין בהמלצות שבקטעים הבאים.
הטמעה של שינוי גודל אוטומטי ודינמי
התאמה אוטומטית ודינמית לעומס מבטיחה שימוש אופטימלי במשאבים, וכך עוזרת למנוע בזבוז אנרגיה כתוצאה מתשתית בלי פעילות או מתשתית עם הקצאת יתר של משאבים. הפחתה של בזבוז אנרגיה מובילה לעלויות נמוכות יותר ולפליטת פחמן נמוכה יותר.
כדי להטמיע התאמה אוטומטית ודינמית של נפח האחסון, אפשר להשתמש בטכניקות הבאות.
שימוש בהרחבה אופקית
הרחבה אופקית היא שיטת ההרחבה המועדפת לרוב האפליקציות בעלות עדיפות לענן. במקום להגדיל את הגודל של כל מופע, תהליך שנקרא הגדלה אנכית, מוסיפים מופעים כדי לפזר את העומס. לדוגמה, אפשר להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG) כדי להרחיב באופן אוטומטי קבוצה של מכונות וירטואליות ב-Compute Engine. תשתית עם קנה מידה אופקי עמידה יותר כי כשל במופע לא משפיע על הזמינות של האפליקציה. התאמה אופקית לעומס היא גם טכניקה יעילה לחיסכון במשאבים באפליקציות עם רמות עומס משתנות.
הגדרת מדיניות מתאימה להרחבת נפח האחסון
הגדרת ההגדרות של התאמה אוטומטית לעומס (autoscaling) בהתאם לדרישות של עומסי העבודה. הגדרת מדדים וערכי סף מותאמים אישית שספציפיים להתנהגות האפליקציה. במקום להסתמך רק על ניצול המעבד, כדאי להשתמש במדדים כמו עומק התור למשימות אסינכרוניות, זמן האחזור של הבקשה ומדדים מותאמים אישית של האפליקציה. כדי למנוע שינוי גודל או תנודות מיותרים בתדירות גבוהה, צריך להגדיר מדיניות ברורה לשינוי גודל. לדוגמה, לעומסי עבודה שפורסים ב-Google Kubernetes Engine (GKE), צריך להגדיר מדיניות מתאימה להתאמה אוטומטית של האשכול.
שילוב של התרחבות ריאקטיבית ופרואקטיבית
בשינוי גודל תגובתי, המערכת משנה את הגודל שלה בתגובה לשינויים בעומס בזמן אמת. הטכניקה הזו מתאימה לאפליקציות שבהן יש עליות בלתי צפויות בעומס.
התאמת קנה מידה פרואקטיבית מתאימה לעומסי עבודה עם דפוסים צפויים, כמו שעות עבודה קבועות ביום ויצירת דוחות שבועיים. בעומסי עבודה כאלה, כדאי להשתמש בהתאמה אוטומטית לעומס לפי לוח זמנים כדי להקצות מראש משאבים שיכולים להתמודד עם רמת עומס צפויה. הטכניקה הזו מונעת מאבקים על משאבים ומבטיחה חוויית משתמש חלקה יותר ויעילות גבוהה יותר. הטכניקה הזו גם עוזרת לכם לתכנן מראש עליות ידועות בעומס, כמו אירועי מכירות גדולים ומאמצי שיווק ממוקדים.
Google Cloud שירותים ותכונות מנוהלים כמו GKE Autopilot, Cloud Run ו-MIG מנהלים באופן אוטומטי את שינוי הגודל הפרואקטיבי על ידי למידה מדפוסי עומס העבודה. כברירת מחדל, אם שירות Cloud Run לא מקבל תנועה, הוא מתרחב לאפס מופעים.
עיצוב אפליקציות ללא מצב
כדי שאפליקציה תהיה ניתנת להרחבה אופקית, הרכיבים שלה צריכים להיות חסרי מצב. המשמעות היא שהסשן או הנתונים של משתמש ספציפי לא מקושרים למופע מחשוב יחיד. כשמאחסנים את מצב הסשן מחוץ למופע המחשוב, למשל ב-Memorystore for Redis, כל מופע מחשוב יכול לטפל בבקשות מכל משתמש. גישת העיצוב הזו מאפשרת הרחבה אופקית חלקה ויעילה.
שימוש בתזמון ובקבוצות
עיבוד באצווה מתאים במיוחד לעומסי עבודה (workloads) גדולים ולא דחופים. משימות באצווה יכולות לעזור לכם לבצע אופטימיזציה של עומסי העבודה (workloads) שלכם כדי לחסוך באנרגיה ולהוזיל עלויות.
כדי להטמיע תזמון ועבודות אצווה, אפשר להשתמש בטכניקות הבאות.
תזמון לשיעור פליטת פחמן נמוך
כדאי לתזמן את העבודות באצווה כך שיפעלו באזורים דלי-פחמן, ובפרקי זמן שבהם אחוז האנרגיה הנקייה ברשת החשמל המקומית גבוה. כדי לזהות את השעות הכי פחות פחמניות באזור מסוים, אפשר להשתמש בדוח על טביעת רגל פחמנית.
שימוש ב-VMs במודל 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 ווקטורים. | מכונות שמותאמות לאחסון מעבדות מערכי נתונים גדולים באופן מקומי, מה שעוזר לצמצם את האנרגיה שמשמשת ליציאת נתונים מהרשת במיקומים שונים. כשמשתמשים באחסון מקומי למשימות שדורשות מספר גבוה של פעולות קלט/פלט בשנייה, נמנעים מהקצאת יתר של כמה מופעים רגילים. |
| מכונות שעברו אופטימיזציה לשימוש במאיצים (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 כדי להקצות סביבות במהירות רק כשצריך.
איזון בין יתירות לניצול
יתירות של משאבים היא גורם עיקרי לבזבוז אנרגיה. כדי לצמצם את הכפילות, אפשר להיעזר בשיטות הבאות:
- עדיף להשתמש בגישה פעילה-פעילה במקום בגישה פעילה-פסיבית: בהגדרה פעילה-פסיבית, המשאבים באתר הפסיבי לא פעילים, ולכן יש בזבוז של אנרגיה. ארכיטקטורה פעילה-פעילה בגודל אופטימלי מבטיחה שכל המשאבים שהוקצו בשני האזורים ישרתו באופן פעיל את התנועה. הגישה הזו עוזרת למקסם את היעילות האנרגטית של התשתית.
- התאמת יתירות: שכפול נתונים ושירותים באזורים שונים רק כשנדרש שכפול כדי לעמוד בדרישות של זמינות גבוהה או של התאוששות מאסון. כל רפליקה נוספת מגדילה את עלות האנרגיה של האחסון המתמיד ושל תעבורת הנתונים היוצאת (egress) ברשת.