העיקרון הזה, שמופיע בעמוד התווך של קיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לשפר את השימוש במשאבים של עומסי העבודה ב- Google Cloud.
סקירה כללית של העקרונות
כדי לשפר את הקיימוּת של סביבת הענן, חשוב לבצע אופטימיזציה של השימוש במשאבים. כל משאב שמוקצה – ממשאבי מחשוב ועד למאגר נתונים – משפיע ישירות על צריכת האנרגיה, על צריכת המים ועל פליטות הפחמן. כדי לצמצם את טביעת הרגל הסביבתית של עומסי העבודה, צריך לקבל החלטות מושכלות כשמקצים משאבים בענן, מנהלים אותם ומשתמשים בהם.
המלצות
כדי לבצע אופטימיזציה של השימוש במשאבים, כדאי להשתמש בהמלצות שבקטעים הבאים.
הטמעת התאמה אוטומטית ודינמית לעומס
התאמה אוטומטית ודינמית לעומס מבטיחה שימוש אופטימלי במשאבים, וכך מונעת בזבוז אנרגיה מתשתיות לא פעילות או מהקצאת יתר של משאבים. החיסכון באנרגיה מתורגם לעלויות נמוכות יותר ולפחות פליטות פחמן.
כדי להטמיע יכולת התאמה אוטומטית ודינמית לעומס, אפשר להשתמש בשיטות הבאות.
שימוש בהתאמה אופקית לעומס (horizontal scaling)
התאמה אופקית היא השיטה המועדפת להתאמה של רוב האפליקציות שנועדו לענן. במקום להגדיל את הגודל של כל מכונה, פעולה שנקראת שינוי קנה מידה אנכי, מוסיפים מכונות כדי לפזר את העומס. לדוגמה, אתם יכולים להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG) כדי להרחיב אופקית באופן אוטומטי קבוצה של מכונות וירטואליות ב-Compute Engine. תשתית עם התאמה אופקית לעומס היא גמישה יותר, כי כשל במכונה לא משפיע על הזמינות של האפליקציה. התאמה לעומס אופקית היא גם שיטה יעילה לניצול משאבים באפליקציות עם רמות עומס משתנות.
הגדרת מדיניות התאמה לעומס (scaling) מתאימה
קובעים את ההגדרות של ההתאמה לעומס (autoscaling) לפי הדרישות של עומסי העבודה. הגדירו מדדים וספים מותאמים אישית שספציפיים להתנהגות של האפליקציה. במקום להסתמך רק על ניצול המעבד (CPU), כדאי להשתמש במדדים כמו עומק התור למשימות אסינכרוניות, זמן האחזור של הבקשות ומדדי אפליקציות בהתאמה אישית. כדי למנוע שינוי קנה מידה תכוף ומיותר או תנודות, הגדירו כללי מדיניות ברורים לשינוי קנה מידה. לדוגמה, לעומסי עבודה שאתם פורסים ב-Google Kubernetes Engine (GKE), הגדירו מדיניות מתאימה להתאמה אוטומטית לעומס (automatic scaling) של אשכולות.
שילוב של התאמה ריאקטיבית ופרואקטיבית של משאבים
בשינוי קנה מידה תגובתי, המערכת משנה את קנה המידה בתגובה לשינויים בעומס בזמן אמת. השיטה הזו מתאימה לאפליקציות שיש בהן עליות חדות ובלתי צפויות בעומס.
התאמה יזומה של קנה המידה מתאימה לעומסי עבודה עם דפוסים צפויים, כמו שעות פעילות קבועות ודוחות שבועיים. בעומסי עבודה כאלה, כדאי להשתמש בהתאמה אוטומטית מתוזמנת לעומס כדי להקצות מראש משאבים, כך שהם יוכלו להתמודד עם רמת העומס הצפויה. השיטה הזו מונעת תחרות על משאבים ומבטיחה חוויית משתמש חלקה ויעילה יותר. השיטה הזו גם עוזרת לתכנן מראש את ההתמודדות עם עליות צפויות בעומס, כמו אירועי מכירות גדולים ומאמצי שיווק ממוקדים.
תכונות ושירותים מנוהלים שלGoogle Cloud , כמו GKE Autopilot, Cloud Run ו-MIG, מנהלים באופן אוטומטי את ההתאמה היזומה לעומס על ידי למידה מדפוסי עומסי העבודה שלכם. כברירת מחדל, כששירות Cloud Run לא מקבל תנועה, הוא מצמצם את הפעולה לאפס מכונות.
תכנון אפליקציות ללא שמירת מצב (stateless)
כדי שאפליקציה תתאים להרחבה אופקית, הרכיבים שלה צריכים להיות ללא שמירת מצב (stateless). כלומר, הסשן או הנתונים של משתמש ספציפי לא קשורים למכונה אחת. כשמאחסנים את מצב הסשן מחוץ למכונה, למשל ב-Memorystore for Redis, כל מכונה יכולה לטפל בבקשות מכל משתמש. הגישה הזו מאפשרת התאמה אופקית חלקה ויעילה לעומס.
שימוש בתזמון ובקבוצות
עיבוד באצווה מתאים במיוחד לעומסי עבודה גדולים ולא דחופים. משימות באצווה יכולות לעזור לכם לבצע אופטימיזציה של עומסי העבודה (workloads) מבחינת יעילות אנרגטית ועלות.
כדי להטמיע תזמון ומשימות באצווה, אפשר להשתמש בשיטות הבאות.
תזמון לפי שיעור פליטת פחמן נמוך
תזמנו את משימות ה-Batch כך שירוצו באזורים דלי-פחמן ובפרקי זמן שבהם רשת החשמל המקומית מכילה אחוז גבוה של אנרגיה נקייה. כדי לזהות את השעות ביום שבהן פליטת הפחמן באזור מסוים היא הנמוכה ביותר, אפשר להשתמש בדוח טביעת הרגל הפחמנית.
שימוש ב-VM במודל Spot לעומסי עבודה לא קריטיים
VM במודל Spot מאפשרות לכם לנצל את הקיבולת הלא מנוצלת של Compute Engine בהנחה משמעותית. אפשר להפסיק לפני הזמן (preempt) את ה-VM במודל Spot, אבל הן מספקות דרך חסכונית לעבד קבוצות נתונים גדולות בלי צורך במשאבים ייעודיים בזמינות תמידית. VM במודל Spot מתאימות במיוחד למשימות באצווה שהן לא קריטיות ועמידות בכשלים.
איחוד משימות והרצה שלהן במקביל
כדי לצמצם את התקורה של הפעלה וכיבוי של משימות נפרדות, כדאי לקבץ משימות דומות לאצווה גדולה אחת. אפשר להריץ את עומסי העבודה האלה בנפח גבוה בשירותים כמו Batch. השירות מקצה ומנהל באופן אוטומטי את התשתית הנדרשת, וכך עוזר להבטיח ניצול אופטימלי של המשאבים.
שימוש בשירותים מנוהלים
שירותים מנוהלים כמו Batch ו-Dataflow מטפלים באופן אוטומטי בהקצאת משאבים, בתזמון ובמעקב. פלטפורמת הענן מטפלת באופטימיזציה של המשאבים. אתם יכולים להתמקד בלוגיקה של האפליקציה. לדוגמה, Dataflow מבצע התאמה אוטומטית לעומס של מספר ה-workers בהתאם לנפח הנתונים בפייפליין, כך שלא תשלמו על משאבים בהמתנה לפעילות.
התאמה של משפחות המכונות הווירטואליות לדרישות של עומסי העבודה
סוגי המכונות שאפשר להשתמש בהם במכונות הווירטואליות של Compute Engine מקובצים במשפחות מכונות, שמותאמות לעומסי עבודה שונים. בוחרים את משפחות המכונות שמתאימות לדרישות של עומסי העבודה.
| משפחת מכונות | מומלץ לסוגים של עומסי עבודה | הנחיות בנושא קיימוּת |
|---|---|---|
| מכונות למטרות כלליות: המכונות האלה מספקות יחס מאוזן בין המעבד (CPU) לזיכרון. | שרתי אינטרנט, מיקרו-שירותים, מסדי נתונים קטנים עד בינוניים וסביבות פיתוח. | סדרת E2 חסכונית מאוד בעלויות ובאנרגיה בזכות הקצאת המשאבים הדינמית שלה. בסדרות C4A, N4A ו-Tau T2A נעשה שימוש במעבדים מבוססי Arm, שלרוב חסכוניים יותר באנרגיה לכל יחידת ביצועים בעומסי עבודה גדולים. |
| מכונות מותאמות לצריכת מעבד גבוהה (compute-optimized): המכונות האלה מספקות יחס גבוה בין vCPU לזיכרון וביצועים גבוהים לכל ליבה. | מחשוב עתיר ביצועים (HPC), עיבוד ברצף (batch processing), שרתי גיימינג וניתוח נתונים מבוסס-מעבד (CPU). | מכונה מותאמת לצריכת מעבד גבוהה (compute-optimized) מאפשרת להשלים משימות שדורשות שימוש אינטנסיבי ב-CPU מהר יותר, וכך לצמצם את זמן המחשוב הכולל ואת צריכת האנרגיה של המשימה. |
| מכונות מותאמות לצריכת זיכרון גבוהה (memory-optimized): המכונות האלה מיועדות לעומסי עבודה שדורשים כמות גדולה של זיכרון. | מסדי נתונים גדולים בזיכרון ומחסני נתונים, כמו SAP HANA או ניתוח נתונים בזיכרון. | מכונות שמותאמות לצריכת זיכרון גבוהה מאפשרות לאחד עומסי עבודה שצורכים הרבה זיכרון בפחות צמתים פיזיים. האיחוד הזה מפחית את כמות האנרגיה הכוללת שנדרשת בהשוואה לשימוש בכמה מכונות קטנות יותר. זיכרון עם ביצועים גבוהים מפחית את זמן האחזור של הגישה לנתונים, וכך יכול להפחית את משך הזמן הכולל שבו המעבד נמצא במצב פעיל. |
| מכונות עם אופטימיזציה לאחסון: המכונות האלה מספקות אחסון SSD מקומי עם תפוקה גבוהה וזמן אחזור קצר. | אחסון נתונים, ניתוח נתוני יומן ומסדי נתונים מסוג SQL, NoSQL ווקטורים. | מכונות שמותאמות לאחסון מעבדות קבוצות נתונים עצומות באופן מקומי, וכך חוסכות את האנרגיה שנדרשת כדי להעביר נתונים ברשת בין מיקומים שונים. כשמשתמשים באחסון מקומי למשימות עם IOPS גבוה, נמנעים מהקצאת יתר של כמה מכונות רגילות. |
| מכונות שעברו אופטימיזציה למאיצים: המכונות האלה מיועדות לעומסי עבודה שמואצים באמצעות GPU ו-TPU, כמו AI, למידת מכונה ו-HPC. | אימון והסקת מסקנות של מודלים ללמידת מכונה (ML), וסימולציות מדעיות. | יחידות TPU מתוכננות לניצול אופטימלי של אנרגיה. הם מספקים יותר חישובים לוואט. מכונה עם האצת GPU, כמו סדרת A3 עם מעבדי GPU מסוג NVIDIA H100, יכולה להיות חסכונית יותר באנרגיה לאימון מודלים גדולים, בהשוואה לחלופה עם מעבד (CPU) בלבד. למרות שלמכונה עם האצת GPU יש צריכת חשמל נומינלית גבוהה יותר, המשימה מסתיימת הרבה יותר מהר. |
שדרוג לסוגי המכונות העדכניים ביותר
שימוש בסוגי המכונות העדכניים ביותר יכול לעזור לשפר את הקיימוּת. כשמעדכנים את סוגי המכונות, בדרך כלל הן מתוכננות להיות חסכוניות יותר באנרגיה ולספק ביצועים גבוהים יותר לכל ואט. מכונות וירטואליות שמשתמשות בסוגי המכונות העדכניים ביותר יכולות להשלים את אותה כמות עבודה עם צריכת חשמל נמוכה יותר.
מעבדים (CPU), מעבדים גרפיים (GPU) ויחידות TPU נהנים לעיתים קרובות מהתקדמות טכנולוגית בארכיטקטורת השבבים, כמו:
- ליבות ייעודיות: פיתוחים במעבדים כוללים לעיתים קרובות ליבות ייעודיות או הוראות לעומסי עבודה נפוצים. לדוגמה, למעבדים יכולות להיות ליבות ייעודיות לפעולות וקטוריות או למאיצי AI משולבים. כשמעבירים את המשימות האלה מהמעבד המרכזי, הן מסתיימות בצורה יעילה יותר וצורכות פחות אנרגיה.
- ניהול משופר של צריכת החשמל: פיתוחים בארכיטקטורות של שבבים כוללים לעיתים קרובות תכונות מתוחכמות יותר לניהול צריכת החשמל, כמו התאמה דינמית של המתח והתדירות על סמך עומס העבודה. התכונות האלה לניהול צריכת החשמל מאפשרות לשבבים לפעול ביעילות שיא ולהיכנס למצבי צריכת חשמל נמוכה כשהם לא בשימוש, וכך לצמצם את צריכת האנרגיה.
השיפורים הטכניים בארכיטקטורת השבבים מספקים את היתרונות הישירים הבאים לקיימוּת ולעלות:
- ביצועים גבוהים יותר לוואט: זהו מדד מרכזי לקיימוּת. לדוגמה, במכונות וירטואליות מסוג C4, יחס המחיר-ביצועים גבוה ב-40% בהשוואה למכונות וירטואליות מסוג C3 עם אותה צריכת אנרגיה. מעבד C4A מספק יעילות אנרגטית גבוהה ב-60% בהשוואה למעבדי x86 דומים. יכולות הביצועים האלה מאפשרות לכם להשלים משימות מהר יותר או להשתמש בפחות מכונות לאותו עומס.
- צריכת אנרגיה כוללת נמוכה יותר: מעבדים משופרים מאפשרים להשתמש במשאבי המחשוב למשך זמן קצר יותר לביצוע משימה נתונה, וכך להפחית את צריכת האנרגיה הכוללת ואת טביעת הרגל הפחמנית. ההשפעה של פליטת הפחמן גבוהה במיוחד בעומסי עבודה קצרי-טווח שדורשים משאבי מחשוב רבים, כמו משימות באצווה ואימון מודלים של למידת מכונה.
- ניצול אופטימלי של משאבים: סוגי המכונות העדכניים יותר מתאימים בדרך כלל לתוכנות מודרניות, ויש להם תאימות טובה יותר לתכונות מתקדמות של פלטפורמות ענן. סוגי המכונות האלה בדרך כלל מאפשרים ניצול טוב יותר של המשאבים, מה שמפחית את הצורך בהקצאת יתר ועוזר להבטיח שכל ואט של חשמל מנוצל בצורה פרודוקטיבית.
פריסת אפליקציות בקונטיינרים
כחלק מהאסטרטגיה שלכם למחשוב ענן בר-קיימא, אתם יכולים להשתמש בשירותים מנוהלים לחלוטין שמבוססים על קונטיינרים, כמו GKE ו-Cloud Run. השירותים האלה עוזרים לייעל את ניצול המשאבים ולהפוך את ניהול המשאבים לאוטומטי.
שימוש ביכולת של Cloud Run לצמצם את הפעולה לאפס
ב-Cloud Run יש סביבה מנוהלת בלי שרת (serverless) שמתאימה אוטומטית את מספר המכונות לאפס כשאין תעבורת נתונים נכנסת לשירות או כשהמשימה מסתיימת. התאמה אוטומטית לעומס עוזרת למנוע צריכת אנרגיה בתשתית בלי פעילות. המשאבים מופעלים רק כשהם מעבדים בקשות באופן פעיל. האסטרטגיה הזו יעילה מאוד לעומסי עבודה לסירוגין או מבוססי-אירועים. לעומסי עבודה של AI, אתם יכולים להשתמש במעבדי GPU עם Cloud Run, וכך לצרוך מעבדי GPU ולשלם עליהם רק כשאתם משתמשים בהם.
אופטימיזציה אוטומטית של משאבים באמצעות GKE
GKE היא פלטפורמה לתזמור קונטיינרים, שמוודאת שהאפליקציות משתמשות רק במשאבים שהן צריכות. כדי לעזור לכם להפוך את אופטימיזציית המשאבים לאוטומטית, GKE מספק את השיטות הבאות:
- סידור בקונטיינרים (bin packing): ב-GKE Autopilot, קונטיינרים מרובים נארזים בצורה חכמה בצמתים הזמינים. סידור בקונטיינרים ממקסם את השימוש בכל צומת ומפחית את מספר הצמתים שלא נמצאים בשימוש או שלא מנוצלים מספיק, וכך עוזר להפחית את צריכת האנרגיה.
- התאמה אופקית של קבוצות Pod לעומס (HPA): באמצעות HPA, מספר הרפליקות של הקונטיינרים (קבוצות Pod) מותאם באופן אוטומטי על סמך מדדים מוגדרים מראש, כמו שימוש ב-CPU או מדדים ספציפיים לאפליקציה בהתאמה אישית. לדוגמה, אם יש עלייה חדה בתנועה באפליקציה, GKE מוסיף פודים כדי לעמוד בביקוש. כשהתנועה פוחתת, GKE מצמצם את מספר ה-Pods. ההתאמה הדינמית הזו מונעת הקצאת יתר של משאבים, כך שלא תשלמו על קיבולת מחשוב מיותרת ולא תפעילו אותה.
- התאמה אנכית של קבוצות Pod לעומס (VPA): אתם יכולים להגדיר את GKE כך שיתאים באופן אוטומטי את ההקצאות והמגבלות של המעבד (CPU) והזיכרון לקונטיינרים ספציפיים. ההגדרה הזו מבטיחה שלא יוקצו לקונטיינר יותר משאבים ממה שהוא צריך, וכך עוזרת למנוע הקצאת יתר של משאבים.
- שינוי קנה מידה אוטומטי רב-ממדי של Pod ב-GKE: בעומסי עבודה מורכבים, אתם יכולים להגדיר HPA ו-VPA בו-זמנית כדי לשפר את מספר ה-Pods ואת הגודל של כל Pod. השיטה הזו עוזרת להבטיח שהביצועים הנדרשים יושגו עם טביעת הרגל האנרגטית הקטנה ביותר.
- תזמון מבוסס-טופולוגיה (TAS): התכונה TAS משפרת את יעילות הרשת של עומסי עבודה של AI ו-ML ב-GKE, על ידי מיקום Pods על סמך המבנה הפיזי של תשתית מרכז הנתונים. TAS ממקם עומסי עבודה באופן אסטרטגי כדי לצמצם את מספר הדילוגים ברשת. המיקום המשותף הזה עוזר לצמצם את זמן האחזור בתקשורת ואת צריכת האנרגיה. באמצעות אופטימיזציה של ההתאמה הפיזית של הצמתים והחומרה הייעודית, TAS מאיץ את השלמת המשימות וממקסם את יעילות האנרגיה של עומסי עבודה של AI ו-ML בקנה מידה גדול.
הגדרת תזמון עם מודעות לפליטת פחמן
ב-Google, אנחנו מעבירים כל הזמן את עומסי העבודה שלנו למיקומים ולזמנים שבהם החשמל הכי נקי. אנחנו גם משתמשים מחדש בציוד ישן, או מפרקים אותו, למטרות אחרות. אתם יכולים להשתמש באסטרטגיית התזמון הזו, שמתחשבת בפליטת פחמן, כדי לוודא שעומסי העבודה בקונטיינרים משתמשים באנרגיה נקייה.
כדי להטמיע תזמון שמותאם לפליטת פחמן, אתם צריכים מידע בזמן אמת על תמהיל האנרגיה שמפעיל את מרכזי הנתונים באזור. אתם יכולים לקבל את המידע הזה בפורמט קריא למכונה ממאגר הנתונים אנרגיה נטולת פחמן באזורי Google Cloud ב-GitHub או ממערך נתונים ציבורי ב-BigQuery. הנתונים השעתיים לגבי תמהיל מקורות האנרגיה ברשת ושיעור פליטת הפחמן, שמשמשים לחישוב קבוצת הנתונים השנתית של Google לגבי פליטות פחמן, מגיעים מחברת Electricity Maps.
כדי להטמיע תזמון עם מודעות לפליטת פחמן, מומלץ להשתמש בשיטות הבאות:
- העברה גיאוגרפית: תזמון עומסי העבודה כך שיפעלו באזורים שבהם משתמשים בשיעור גבוה יותר של מקורות אנרגיה מתחדשת. כך תוכלו להשתמש ברשתות חשמל נקיות יותר.
- העברה זמנית: לעומסי עבודה לא קריטיים וגמישים, כמו עיבוד באצווה, הגדירו את עומסי העבודה כך שיפעלו בשעות שאינן שעות שיא או כשיש הכי הרבה אנרגיה מתחדשת. הגישה הזו נקראת "הסטה זמנית", והיא עוזרת לצמצם את טביעת הרגל הפחמנית הכוללת על ידי ניצול מקורות אנרגיה נקיים יותר כשהם זמינים.
תכנון תוכנית התאוששות מאסון (DR) חסכונית באנרגיה
ההכנה לתוכנית התאוששות מאסון (DR) כוללת לעיתים קרובות הקצאה מראש של משאבים מיותרים באזור משני. עם זאת, משאבים לא פעילים או כאלה שלא מנוצלים במלואם יכולים לגרום לבזבוז אנרגיה משמעותי. בחרו אסטרטגיות DR שממקסמות את ניצול המשאבים ומצמצמות את ההשלכות של פליטת הפחמן, בלי לפגוע ביעדי זמן ההתאוששות (RTO).
אופטימיזציה של יעילות ההפעלה במצב התחלתי (cold start)
כדי לצמצם או לבטל את המשאבים הפעילים באזור המשני (DR), אפשר להשתמש בגישות הבאות:
- לתת עדיפות להתאוששות מאסון במצב קר: להשאיר את המשאבים באזור ה-DR כבויים או במצב של צמצום הפעולה לאפס. הגישה הזו עוזרת לצמצם את טביעת הרגל הפחמנית של משאבי מחשוב לא פעילים.
- שימוש ביתירות כשל ללא שרת (serverless): שימוש בשירותים מנוהלים ללא שרת (serverless) כמו Cloud Run לנקודות קצה (endpoints) של התאוששות מאסון. ב-Cloud Run, כשאין שימוש, המערכת מצמצמת את הפעולה לאפס, כך שאפשר לשמור על טופולוגיית DR שלא צורכת אנרגיה עד שתעבורת הנתונים מופנית לאזור ה-DR.
- אוטומציה של השחזור באמצעות תשתית כקוד (IaC): במקום להשאיר את המשאבים באתר ה-DR פועלים (חמים), אפשר להשתמש בכלי IaC כמו Terraform כדי להקצות במהירות סביבות רק כשצריך.
איזון בין יתירות לניצול
יתירות של משאבים היא גורם עיקרי לבזבוז אנרגיה. כדי לצמצם את היתירות, אפשר להשתמש בשיטות הבאות:
- העדיפו הגדרת active-active על פני active-passive: בהגדרת active-passive, המשאבים באתר הפסיבי לא פעילים, וכתוצאה מכך אנרגיה מתבזבזת. ארכיטקטורה פעילה-פעילה בגודל אופטימלי מבטיחה שכל המשאבים שהוקצו בשני האזורים משרתים את התנועה באופן פעיל. הגישה הזו עוזרת למקסם את יעילות האנרגיה של התשתית.
- יתירות בגודל המתאים: משכפלים נתונים ושירותים בין אזורים רק כשהשכפול נחוץ כדי לעמוד בדרישות של זמינות גבוהה או DR. כל רפליקה נוספת מגדילה את עלות האנרגיה של האחסון המתמיד ותעבורת הנתונים היוצאת (egress).