Well-Architected Framework: עקרון הקיימות

Last reviewed 2026-10-28 UTC

עמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework מספק המלצות לתכנון, ליצירה ולניהול של עומסי עבודה ב- Google Cloudשמתחשבים בצריכת האנרגיה ובפליטת הפחמן.

קהל היעד של המסמך הזה כולל מקבלי החלטות, אדריכלים, אדמינים, מפתחים ומפעילים שמתכננים, בונים, פורסים ומתחזקים עומסי עבודה ב- Google Cloud.

להחלטות שקשורות לארכיטקטורה ולתפעול יש השפעה משמעותית על צריכת האנרגיה, על ההשפעה על המים ועל טביעת הרגל הפחמנית שנובעת מעומסי העבודה בענן. כל עומס עבודה, בין אם מדובר באתר קטן או במודל ML בקנה מידה גדול, צורך אנרגיה ותורם לפליטות פחמן ולצריכת משאבי מים. כשמשלבים קיימוּת בארכיטקטורת הענן ובתהליך התכנון, בונים מערכות יעילות, משתלמות וגם ידידותיות לסביבה. ארכיטקטורה בת-קיימא היא גמישה ומותאמת, ויוצרת לולאת משוב חיובית של יעילות גבוהה יותר, עלות נמוכה יותר והשפעה סביבתית נמוכה יותר.

קיימות מובנית: תוצאות עסקיות הוליסטיות

קיימות היא לא פשרה על חשבון יעדים עסקיים מרכזיים אחרים, אלא שיטות עבודה שמתמקדות בקיימות עוזרות להאיץ את היעדים העסקיים האחרים. בחירות ארכיטקטוניות שמתעדפות משאבים ופעולות דלי-פחמן עוזרות לכם לבנות מערכות שהן גם מהירות, זולות ומאובטחות יותר. מערכות כאלה נחשבות למערכות שתוכננו מראש לקיימוּת, שבהן אופטימיזציה לקיימוּת מובילה לתוצאות חיוביות כוללות מבחינת ביצועים, עלות, אבטחה, עמידות וחוויית המשתמש.

אופטימיזציה של הביצועים

מערכות שעברו אופטימיזציה לביצועים משתמשות באופן טבעי בפחות משאבים. אפליקציה יעילה שמבצעת משימה מהר יותר דורשת משאבי מחשוב למשך זמן קצר יותר. לכן, החומרה הבסיסית צורכת פחות קילוואט-שעה (kWh) של אנרגיה. ביצועים אופטימליים גם מובילים לזמן אחזור קצר יותר ולחוויית משתמש טובה יותר. לא מבזבזים זמן ואנרגיה על משאבים שממתינים לתהליכים לא יעילים. כשמשתמשים בחומרה ייעודית (לדוגמה, GPUs ו-TPUs), מאמצים אלגוריתמים יעילים וממקסמים את העיבוד המקביל, משפרים את הביצועים וגם מצמצמים את טביעת הרגל הפחמנית של עומס העבודה בענן.

הוזלת עלויות

ההוצאות התפעוליות בענן תלויות בשימוש במשאבים. בגלל הקשר הישיר הזה, כשמבצעים אופטימיזציה של העלויות באופן קבוע, גם צריכת האנרגיה ופליטות הפחמן מצטמצמות. כשמתאימים את הגודל של המכונות הווירטואליות, מטמיעים התאמה אוטומטית לעומס (autoscaling) בצורה אגרסיבית, מעבירים נתונים ישנים לארכיון ומסירים משאבים לא פעילים, מפחיתים את השימוש במשאבים ואת העלויות בענן. בנוסף, אתם מצמצמים את טביעת הרגל הפחמנית של המערכות שלכם, כי מרכזי הנתונים צורכים פחות אנרגיה כדי להריץ את עומסי העבודה.

אבטחה ועמידות

אבטחה ואמינות הן תנאים מוקדמים לסביבת ענן בת קיימא. מערכת שנפגעה – לדוגמה, מערכת שהושפעה מהתקפת מניעת שירות (DoS) או מפרצה באבטחת מידע – יכולה להגדיל באופן דרמטי את צריכת המשאבים. האירועים האלה יכולים לגרום לעלייה חדה בנפח התנועה, ליצור מחזורי מחשוב בלתי נשלטים לצורך הפחתת הסיכון, ולחייב פעולות ארוכות ומאומצות לניתוח משפטי, לניקוי ולשחזור נתונים. אמצעי אבטחה חזקים יכולים לעזור למנוע עליות חדות מיותרות בשימוש במשאבים, כדי שהפעולות שלכם יישארו יציבות, צפויות וחסכוניות באנרגיה.

חוויית משתמש

מערכות שמתעדפות יעילות, ביצועים, נגישות ושימוש מינימלי בנתונים יכולות לעזור לצמצם את צריכת האנרגיה של משתמשי הקצה. אפליקציה שטוענת מודל קטן יותר או מעבדת פחות נתונים כדי לספק תוצאות מהר יותר, עוזרת להפחית את האנרגיה שנצרכת על ידי מכשירי הרשת ומכשירי משתמשי הקצה. ההפחתה הזו בצריכת האנרגיה מועילה במיוחד למשתמשים עם רוחב פס מוגבל או למשתמשים במכשירים ישנים יותר. בנוסף, ארכיטקטורה בת-קיימא עוזרת לצמצם את הנזק לכדור הארץ וממחישה את המחויבות שלכם לטכנולוגיה עם אחריות חברתית.

הערך של מעבר לענן מבחינת קיימוּת

העברת עומסי עבודה מקומיים לענן יכולה לעזור לצמצם את טביעת הרגל הסביבתית של הארגון. המעבר לתשתית ענן יכול להפחית את צריכת האנרגיה ואת הפליטות שקשורות אליה פי 1.4 עד 2 בהשוואה לפריסות מקומיות טיפוסיות. מרכזי נתונים בענן הם מתקנים מודרניים שתוכננו בהתאמה אישית כדי להשיג יעילות צריכת חשמל גבוהה (PUE). במרכזי נתונים מקומיים ישנים יותר, בדרך כלל אין את קנה המידה שנדרש כדי להצדיק השקעות במערכות מתקדמות לקירור ולהפצת חשמל.

אחריות משותפת ושת"פ הדוק

במאמר אחריות משותפת ושת"פ הדוק ב- Google Cloud מתואר איך האבטחה של עומסי העבודה בענן היא אחריות משותפת של Google ושלכם, הלקוחות. מודל האחריות המשותפת הזה חל גם על קיימוּת.

‫Google אחראית לקיימות של Google Cloud, כלומר ליעילות אנרגטית ולייעול השימוש במים במרכזי הנתונים, בתשתיות ובשירותי הליבה שלנו. אנחנו משקיעים באופן קבוע באנרגיה מתחדשת, בקירור בעל מודעות סביבתית ובאופטימיזציה של החומרה. מידע נוסף על אסטרטגיית הקיימוּת של Google וההתקדמות שלה זמין בדוח הסביבתי של Google בנושא קיימוּת לשנת 2026.

אתם, הלקוחות, אחראים לקיימוּת בענן, כלומר לאופטימיזציה של עומסי העבודה כדי להיות יעילים אנרגטית. לדוגמה, אתם יכולים להתאים את גודל המשאבים, להשתמש בשירותים בלי שרת (serverless) שמאפשרים לצמצם את הפעולה לאפס, ולנהל ביעילות את מחזורי החיים של הנתונים.

אנחנו גם דוגלים במודל של גורל משותף: קיימוּת היא לא רק חלוקת משימות, אלא שותפות בין הלקוחות לבין Google כדי לצמצם את טביעת הרגל הסביבתית של כל המערכת.

שימוש ב-AI כדי להשפיע על העסק

העמוד הזה, שעוסק בעקרון הקיימוּת של Well-Architected Framework, כולל הנחיות שיעזרו לכם לתכנן מערכות AI שפועלות באופן ידידותי לסביבה. עם זאת, אסטרטגיית קיימוּת מקיפה לא מתמקדת רק בהשפעה הסביבתית של עומסי עבודה של AI. האסטרטגיה צריכה לכלול דרכים להשתמש ב-AI כדי לייעל את הפעולות וליצור ערך עסקי חדש.

ה-AI משמש כזרז לקיימוּת על ידי הפיכת מערכי נתונים עצומים לתובנות פרקטיות. הוא מאפשר לארגונים לעבור מציות לתקנות בדיעבד לאופטימיזציה יזומה, למשל בתחומים הבאים:

  • יעילות תפעולית: ייעול הפעילות באמצעות ניהול מלאי משופר, אופטימיזציה של שרשרת האספקה וניהול אנרגיה חכם.
  • שקיפות וסיכונים: שימוש בנתונים כדי להשיג שקיפות מפורטת בשרשרת האספקה, לעמוד בתקנות ולבנות מודלים של סיכוני אקלים.
  • ערך וצמיחה: פיתוח מקורות הכנסה חדשים בתחום הפיננסים והמסחר החוזר.

‫Google מציעה את המוצרים והתכונות הבאים כדי לעזור לכם להפיק תובנות מהנתונים ולפתח יכולות לעתיד בר-קיימא:

  • ‫Google Earth AI: משתמש בנתונים גיאו-מרחביים בקנה מידה פלנטרי כדי לנתח שינויים סביבתיים ולעקוב אחרי ההשפעות על שרשרת האספקה.
  • WeatherNext: מספקת תחזיות מזג אוויר מתקדמות וניתוח סיכונים של אקלים כדי לעזור לכם לבנות חוסן מול תנודתיות האקלים.
  • תובנות גיאו-מרחביות באמצעות Google Earth: שימוש בנתונים גיאו-מרחביים כדי להוסיף נתוני הקשר עשירים למיקומים, וכך לבחור אתרים, לתכנן משאבים ולבצע פעולות בצורה חכמה יותר.
  • אופטימיזציה של מסלולים במפות Google: אופטימיזציה של מסלולי לוגיסטיקה ומשלוחים כדי לשפר את היעילות ולהפחית את צריכת הדלק ואת פליטות הגז מתחבורה.

שיתופי פעולה עם שותפים ולקוחות

‫Google Cloud ו-TELUS שיתפו פעולה כדי לקדם את הקיימוּת בענן, על ידי העברת עומסי עבודה לתשתית של Google שהיא ניטרלית מבחינת פליטת פחמן, ושימוש בניתוח נתונים כדי לשפר את הפעילות. השותפות הזו מספקת יתרונות חברתיים וסביבתיים באמצעות יוזמות כמו טכנולוגיית עיר חכמה, שמשתמשת בנתונים בזמן אמת כדי להפחית את עומסי התנועה ואת פליטות הפחמן ברשויות המקומיות בקנדה. למידע נוסף על שיתוף הפעולה הזה, קראו את המאמר Google Cloud and TELUS collaborate for sustainability.

הערכת עומסי עבודה באמצעות מיומנות של סוכן

כדי לאפשר לסוכני AI להעריך את עומסי העבודה בענן בהתאם לעקרונות ולהמלצות שמופיעים במאמר הזה, אתם יכולים להשתמש במיומנות google-cloud-waf-sustainability שזמינה במאגר Google Agent Skills ב-GitHub.

כדי להתקין את המיומנות, מריצים את הפקודה הבאה בטרמינל או בלקוח של הנציג:

npx skills add google/skills --skill google-cloud-waf-sustainability

כשמוצגת בקשה, מציינים את סוכני ה-AI שרוצים להתקין בשבילם את המיומנות ומגדירים את היקף ההתקנה (פרויקט או גלובלי).

אם כבר התקנתם את המיומנות, אתם יכולים לעדכן אותה לגרסה העדכנית ביותר על ידי הפעלת הפקודה הבאה:

npx skills update

עקרונות הליבה

ההמלצות בעמוד התווך של הקיימוּת ב-Well-Architected Framework ממופות לעקרונות הליבה הבאים:

שותפים ביצירת התוכן

מחבר: Brett Tackaberry | אדריכל ראשי

תורמים אחרים:

שימוש באזורים שצורכים אנרגיה דלת-פחמן

העיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לבחור אזורים דלי-פחמן לעומסי העבודה שלכם ב- Google Cloud.

סקירה כללית של העקרונות

כשמתכננים לפרוס עומס עבודה ב- Google Cloud, אחת מההחלטות הארכיטקטוניות החשובות היא בחירת האזור של Google Cloud לעומס העבודה. ההחלטה הזו משפיעה על טביעת הרגל הפחמנית של עומס העבודה שלכם. כדי לצמצם את טביעת הרגל הפחמנית, אסטרטגיית בחירת האזור צריכה לכלול את הרכיבים הבאים:

  • בחירה מבוססת-נתונים: כדי לזהות אזורים ולתעדף אותם, כדאי להביא בחשבון את האינדיקטור סמל של עלה Low CO2 ואת המדד אנרגיה נטולת פחמן (CFE).
  • ניהול מבוסס-מדיניות: הגבלת יצירת המשאבים למיקומים אופטימליים מבחינה סביבתית, באמצעות האילוץ מיקומי משאבים בשירות מדיניות הארגון.
  • גמישות תפעולית: אתם יכולים להשתמש בשיטות כמו שינוי זמנים ותזמון תוך התחשבות בשיעור פליטת הפחמן, כדי להריץ עומסי עבודה באצווה בשעות שבהן שיעור פליטת הפחמן של רשת החשמל הוא הנמוך ביותר.

החשמל שמשמש להפעלת האפליקציה ועומסי העבודה בענן הוא גורם חשוב שמשפיע על בחירת האזורים ב- Google Cloud . בנוסף, כדאי להביא בחשבון את הגורמים הבאים:

  • מיקום אחסון הנתונים וריבונות: המיקום שבו אתם צריכים לאחסן את הנתונים הוא גורם בסיסי שקובע את בחירת האזור ב- Google Cloud. הבחירה הזו משפיעה על העמידה בדרישות המקומיות בנוגע למיקום אחסון הנתונים.
  • זמן אחזור למשתמשי קצה: המרחק הגיאוגרפי בין משתמשי הקצה לבין האזורים שבהם אתם פורסים את האפליקציות משפיע על חוויית המשתמש ועל ביצועי האפליקציה.
  • עלות: המחירים של משאבי Google Cloud יכולים להיות שונים באזורים שונים.

הכלי Google Cloud Region Picker עוזר לכם לבחור את האזורים האופטימליים ב- Google Cloud בהתאם לדרישות שלכם לגבי טביעת הרגל הפחמנית, העלות וזמן האחזור. אתם יכולים גם להשתמש ב-Cloud Location Finder כדי למצוא מיקומים בענן ב- Google Cloud ובספקים אחרים, על סמך הדרישות שלכם לגבי קרבה, שימוש באנרגיה נטולת פחמן (CFE) ופרמטרים אחרים.

המלצות

כדי לפרוס את עומסי העבודה בענן באזורים דלי-פחמן, כדאי לפעול לפי ההמלצות שבקטעים הבאים. ההמלצות האלה מבוססות על ההנחיות במאמר אנרגיה נטולת פחמן באזורי Google Cloud .

הסבר על שיעור פליטת הפחמן באזורי הענן

מרכזי הנתונים שלGoogle Cloud באזור מסוים משתמשים באנרגיה מרשת החשמל שבה נמצא האזור. ‫Google מודדת את ההשלכות של פליטת פחמן באזור באמצעות מדד ה-CFE, שמחושב כל שעה. ‫CFE מציין את אחוז האנרגיה נטולת הפחמן מתוך כלל האנרגיה שנצרכת במהלך שעה. המדד CFE תלוי בשני גורמים:

במאמר אנרגיה נטולת פחמן באזורי Google Cloud מפורט המידע על אחוז ה-CFE הממוצע המצטבר לשעה בכל אזור שלGoogle Cloud . אפשר גם לקבל את הנתונים האלה בפורמט קריא למכונה מהמאגר אנרגיה נטולת פחמן באזורי Google Cloud ב-GitHub וממערך נתונים ציבורי ב-BigQuery.

שילוב של CFE באסטרטגיית בחירת המיקום

כדאי לשקול את ההמלצות הבאות:

  • בחירת האזור הכי נקי לאפליקציות שלכם. אם אתם מתכננים להריץ אפליקציה במשך זמן רב, כדאי להריץ אותה באזור עם אחוז ה-CFE הגבוה ביותר. בעומסי עבודה באצווה, יש לכם יותר גמישות בבחירת האזור כי אתם יכולים לחזות מתי עומס העבודה צריך לפעול.
  • בחירת אזורים דלי-פחמן. בדפים מסוימים באתר Google Cloud ובבוררי המיקומים במסוף Google Cloud , מוצג הסמל סמל של עלה Low CO2 באזורים שבהם ההשלכות של פליטת הפחמן הן הנמוכות ביותר.
  • להגביל את יצירת המשאבים לאזורים ספציפיים דלי-פחמן Google Cloud, באמצעות האילוץ מיקומי משאבים במדיניות הארגון. לדוגמה, כדי לאפשר יצירת משאבים רק באזורים דלי-פחמן בארה"ב, יוצרים אילוץ שמציין את קבוצת הערכים in:us-low-carbon-locations.

כשבוחרים מיקומים למשאבי Google Cloud , כדאי גם להביא בחשבון את השיטות המומלצות לבחירת אזור, כולל גורמים כמו דרישות לגבי מיקום אחסון הנתונים, זמן אחזור למשתמשי קצה, יתירות של האפליקציה, זמינות של שירותים ותמחור.

שימוש בתזמון לפי שעה ביום

שיעור פליטת הפחמן של רשת חשמל יכול להשתנות באופן משמעותי במהלך היום. ההבדלים תלויים בשילוב של מקורות האנרגיה שמספקים חשמל לרשת. אתם יכולים לתזמן עומסי עבודה, במיוחד כאלה שהם גמישים או לא דחופים, כך שיפעלו כשרשת החשמל מספקת שיעור גבוה יותר של CFE.

לדוגמה, ברשתות רבות יש אחוזי CFE גבוהים יותר בשעות השפל או כשמקורות מתחדשים כמו אנרגיה סולארית ואנרגיית רוח מספקים יותר חשמל לרשת. אם תזמנו משימות עתירות מחשוב, כמו אימון מודלים והסקת מסקנות באצווה בקנה מידה גדול, בשעות שבהן ה-CFE גבוה יותר, תוכלו להפחית באופן משמעותי את פליטות הפחמן שקשורות למשימות האלה בלי להשפיע על הביצועים או על העלות. הגישה הזו נקראת הסטת זמן, ובה משתמשים באופי הדינמי של שיעור פליטת הפחמן ברשת כדי לבצע אופטימיזציה של עומסי העבודה למטרות קיימוּת.

אופטימיזציה של עומסי עבודה של AI ו-ML ליעילות אנרגטית

העיקרון הזה, שמופיע בעמוד התווך של קיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות לאופטימיזציה של עומסי עבודה של AI ו-ML כדי לצמצם את צריכת האנרגיה ואת טביעת הרגל הפחמנית שלהם.

סקירה כללית של העקרונות

כדי לבצע אופטימיזציה של עומסי עבודה של AI ו-ML למטרות קיימוּת, צריך לאמץ גישה הוליסטית לתכנון, לפריסה ולהפעלה של עומסי העבודה. לבחור מודלים מתאימים וחומרה ייעודית כמו יחידות Tensor Processing Unit‏ (TPU), להריץ את עומסי העבודה באזורים דלי-פחמן, לבצע אופטימיזציה כדי לצמצם את השימוש במשאבים וליישם שיטות עבודה מומלצות.

שיטות ארכיטקטוניות ותפעוליות שמייעלות את העלות והביצועים של עומסי עבודה של AI ו-ML, מובילות באופן טבעי לצריכת אנרגיה מופחתת ולטביעת רגל פחמנית נמוכה יותר. נקודת המבט של AI ו-ML ב-Well-Architected Framework מתארת עקרונות והמלצות לתכנון, ליצירה ולניהול של עומסי עבודה של AI ו-ML שעומדים ביעדים שלכם מבחינת תפעול, אבטחה, אמינות, עלות וביצועים. בנוסף, מרכז הארכיטקטורה של Cloud מספק ארכיטקטורות מפורטות ומדריכי תכנון לעומסי עבודה של AI ו-ML ב- Google Cloud.

המלצות

כדי לבצע אופטימיזציה של עומסי עבודה של AI ו-ML ליעילות אנרגטית, כדאי להביא בחשבון את ההמלצות שבקטעים הבאים.

תכנון ארכיטקטורה יעיל אנרגטית באמצעות יחידות TPU

עומסי עבודה של AI ו-ML יכולים לדרוש הרבה משאבי מחשוב. צריכת האנרגיה של עומסי עבודה של AI ו-ML היא נקודה מרכזית בקיימוּת. יחידות TPU מאפשרות לשפר משמעותית את יעילות האנרגיה והקיימוּת של עומסי העבודה של AI ו-ML.

יחידות TPU הן מאיצים שתוכננו בהתאמה אישית ונועדו במיוחד לעומסי עבודה של AI ו-ML. הארכיטקטורה המיוחדת של יחידות ה-TPU הופכת אותן ליעילות מאוד לכפל מטריצות בקנה מידה גדול, שהוא הבסיס ללמידה עמוקה. יחידות TPU יכולות לבצע משימות מורכבות בקנה מידה גדול, ביעילות רבה יותר מאשר מעבדים לשימוש כללי כמו מעבדי CPU או GPU.

יחידות TPU מספקות את היתרונות הישירים הבאים לקיימוּת:

  • צריכת אנרגיה נמוכה יותר: יחידות ה-TPU מתוכננות ליעילות אנרגטית אופטימלית. הם מספקים יותר חישובים לכל ואט של אנרגיה שנצרכת. הארכיטקטורה המיוחדת שלהם מפחיתה משמעותית את דרישות ההספק של משימות אימון והסקה בקנה מידה גדול, מה שמוביל להפחתת עלויות התפעול ולצריכת אנרגיה נמוכה יותר.
  • אימון והסקה מהירים יותר: הביצועים יוצאי הדופן של יחידות ה-TPU מאפשרים לאמן מודלים מורכבים של AI תוך שעות במקום ימים. ההפחתה המשמעותית הזו בזמן החישוב הכולל תורמת ישירות לטביעת רגל סביבתית קטנה יותר.
  • פחות צורך בקירור: יחידות ה-TPU כוללות קירור נוזלי מתקדם, שמספק ניהול תרמי יעיל ומפחית באופן משמעותי את האנרגיה שמשמשת לקירור מרכז הנתונים.
  • אופטימיזציה של מחזור החיים של ה-AI: יחידות TPU משלבות חומרה ותוכנה כדי לספק פתרון אופטימלי לכל אורך מחזור החיים של ה-AI, מעיבוד הנתונים ועד להצגת המודל.

שיטות מומלצות לבחירת משאבים לפי 4Ms

‫Google ממליצה על כמה שיטות מומלצות לצמצום משמעותי של צריכת האנרגיה ופליטת הפחמן בעומסי עבודה של AI ו-ML. השיטות המומלצות האלה:

  • מודל: לתרחישי שימוש מיוחדים, בחרו מודלים ייעודיים שמשתמשים בפחות משאבי מחשוב מאשר מודלים גדולים לשימוש כללי.
  • מכונה: בוחרים מעבדים ומערכות שמותאמים לאימון ML. המעבדים האלה משפרים את הביצועים ואת היעילות האנרגטית פי 2 עד 5 בהשוואה למעבדים לשימוש כללי.
  • מיכון: פריסת עומסי עבודה אינטנסיביים בענן. עומסי העבודה שלכם צורכים פחות אנרגיה וגורמים לפליטות נמוכות יותר, פי 1.4 עד 2 בהשוואה לפריסות מקומיות. במרכזי נתונים בענן משתמשים במחסנים חדשים יותר, שתוכננו בהתאמה אישית כדי לשפר את יעילות צריכת האנרגיה, ויש להם יחס גבוה של יעילות צריכת האנרגיה (PUE). מרכזי נתונים מקומיים הם בדרך כלל ישנים וקטנים יותר, ולכן השקעה במערכות קירור וחלוקת חשמל חסכוניות באנרגיה לא תמיד משתלמת.
  • מפה: בחירת Google Cloud מיקומים שמשתמשים באנרגיה הנקייה ביותר. הגישה הזו עוזרת לצמצם את טביעת הרגל הפחמנית ברוטו של עומסי העבודה פי 5 עד 10. מידע נוסף זמין במאמר אנרגיה נטולת פחמן באזורי Google Cloud .

למידע נוסף על השיטות המומלצות של 4Ms ומדדי היעילות, אפשר לקרוא את המאמרים הבאים:

אופטימיזציה של מודלי AI ואלגוריתמים לאימון ולהיקש

לארכיטקטורה של מודל ה-AI ולאלגוריתמים שמשמשים לאימון ולהסקת מסקנות יש השפעה משמעותית על צריכת האנרגיה. כדאי לשקול את ההמלצות הבאות.

בחירת מודלים יעילים של AI

בחרו מודלים קטנים ויעילים יותר של AI שעומדים בדרישות הביצועים שלכם. אל תבחרו במודל הכי גדול שזמין כברירת מחדל. לדוגמה, גרסת מודל קטנה ומזוקקת כמו DistilBERT יכולה לספק ביצועים דומים עם תקורה חישובית נמוכה משמעותית והסקה מהירה יותר מאשר מודל גדול יותר כמו BERT.

שימוש בפתרונות יעילים במיוחד שמותאמים לדומיין

בחרו פתרונות ML ייעודיים שמספקים ביצועים טובים יותר ודורשים הרבה פחות משאבי מחשוב מאשר מודל בסיס גדול. הפתרונות הייעודיים האלה בדרך כלל מאומנים מראש ועוברים אופטימיזציה ברמה גבוהה. הם יכולים להפחית באופן משמעותי את צריכת האנרגיה ואת מאמצי המחקר בעומסי עבודה של אימון והסקה. הנה כמה דוגמאות לפתרונות ייעודיים לתחומים ספציפיים:

  • ‫Earth AI הוא פתרון יעיל אנרגטית שמשלב כמויות גדולות של נתונים גיאו-מרחביים גלובליים כדי לספק תובנות פרקטיות, מדויקות ובזמן אמת.
  • ‫WeatherNext יוצר תחזיות מזג אוויר גלובליות מהירות, יעילות ומדויקות יותר בהשוואה לשיטות רגילות שמבוססות על פיזיקה.

להשתמש בטכניקות מתאימות לדחיסת מודלים

הנה כמה דוגמאות לשיטות שבהן אפשר להשתמש כדי לדחוס מודלים:

  • גיזום: הסרת פרמטרים מיותרים מרשת נוירונים. אלה פרמטרים שלא תורמים באופן משמעותי לביצועים של המודל. השיטה הזו מקטינה את המודל ואת משאבי המחשוב שנדרשים להסקת מסקנות.
  • קוונטיזציה: הפחתת הדיוק של הפרמטרים במודל. לדוגמה, להפחית את הדיוק מנקודה צפה (floating-point) של 32 ביט למספרים שלמים של 8 ביט. הטכניקה הזו יכולה לעזור להפחית באופן משמעותי את הזיכרון שבשימוש ואת צריכת החשמל, בלי לפגוע באופן ניכר ברמת הדיוק.
  • זיקוק ידע: אימון מודל תלמיד קטן יותר כדי לחקות את ההתנהגות של מודל מורה גדול ומורכב יותר. מודל התלמיד יכול להגיע לרמת ביצועים גבוהה עם פחות פרמטרים ופחות אנרגיה.

שימוש בחומרה ייעודית

כמו שמוסבר במאמר שיטות מומלצות לבחירת משאבים לפי 4Ms, כדאי לבחור מעבדים ומערכות שמותאמים לאימון למידת מכונה. המעבדים האלה משפרים את הביצועים ואת היעילות האנרגטית פי 2 עד 5 בהשוואה למעבדים לשימוש כללי.

שימוש בכוונון יעיל בפרמטרים

במקום לשנות את כל מיליארדי הפרמטרים של המודל (כוונון מלא), השתמשו בשיטות של כוונון יעיל בפרמטרים (PEFT) כמו Low-Rank Adaptation ‏ (LoRA). בשיטה הזו, מקפיאים את המשקלים של המודל המקורי ומאמנים רק מספר קטן של שכבות חדשות וקלות. הגישה הזו עוזרת להפחית את העלויות ואת צריכת האנרגיה.

שיטות מומלצות לתפעול של AI ו-ML

שיטות העבודה התפעוליות משפיעות באופן משמעותי על הקיימוּת של עומסי העבודה ב-AI וב-ML. כדאי להביא בחשבון את ההמלצות הבאות.

אופטימיזציה של תהליכי אימון מודלים

כדי לבצע אופטימיזציה של תהליכי אימון המודלים, אפשר להשתמש בשיטות הבאות:

  • עצירה מוקדמת: עוקבים אחרי תהליך האימון ועוצרים אותו כשלא רואים שיפור נוסף בביצועי המודל בהשוואה לקבוצת הנתונים לתיקוף. השיטה הזו עוזרת למנוע חישובים מיותרים וצריכת אנרגיה מיותרת.
  • טעינת נתונים יעילה: משתמשים בפייפליינים יעילים כדי לוודא שה-GPU וה-TPU תמיד מנוצלים ולא ממתינים לנתונים. השיטה הזו עוזרת למקסם את ניצול המשאבים ולצמצם את בזבוז האנרגיה.
  • כוונון היפר-פרמטרים אופטימלי: כדי למצוא היפר-פרמטרים אופטימליים בצורה יעילה יותר, השתמשו בשיטות כמו אופטימיזציה בייסיאנית או למידת חיזוק. הימנעו מחיפושי Grid מקיפים, שיכולים להיות פעולות שדורשות משאבים רבים.

שיפור יעילות ההסקה

כדי לשפר את היעילות של משימות הסקת מסקנות של AI, אפשר להשתמש בשיטות הבאות:

  • אצווה: קיבוץ של כמה בקשות להסקת מסקנות באצוות וניצול היתרונות של עיבוד מקביל במעבדי GPU ו-TPU. השיטה הזו עוזרת להפחית את עלות האנרגיה לכל חיזוי.
  • שמירה מתקדמת במטמון: מטמיעים אסטרטגיית שמירה במטמון בכמה שכבות, שכוללת שמירה במטמון של מפתח/ערך (KV) ליצירה אוטורגרסיבית ושמירה במטמון של הנחיות סמנטיות לתשובות של האפליקציה. השיטה הזו עוזרת לעקוף חישובי מודלים מיותרים, ויכולה להפחית באופן משמעותי את צריכת האנרגיה ואת פליטות הפחמן.

מדידה ומעקב

עוקבים אחרי הפרמטרים הבאים ומודדים אותם:

  • שימוש ועלות: השתמשו בכלים המתאימים כדי לעקוב אחרי השימוש בטוקנים, צריכת האנרגיה וטביעת הרגל הפחמנית של עומסי העבודה שלכם ב-AI. הנתונים האלה עוזרים לכם לזהות הזדמנויות לאופטימיזציה ולדווח על ההתקדמות לקראת יעדי הקיימוּת.
  • ביצועים: עוקבים באופן רציף אחרי ביצועי המודל בסביבת הייצור. לזהות בעיות כמו סטיית נתונים, שיכולה להצביע על כך שצריך לכוונן את המודל שוב. אם אתם צריכים לאמן מחדש את המודל, אתם יכולים להשתמש במודל המקורי שעבר כוונון עדין כנקודת התחלה, ולחסוך הרבה זמן, כסף ואנרגיה על עדכונים.
    • כדי לעקוב אחרי מדדי הביצועים, משתמשים ב-Cloud Monitoring.
    • כדי לקשר בין שינויים במודל לבין שיפורים במדדי הביצועים, אפשר להשתמש בהערות לאירועים.

למידע נוסף על תפעול של שיפור מתמשך, קראו את המאמר מדידה ושיפור מתמשכים של קיימוּת.

הטמעת תזמון עם מודעות לפליטת פחמן

תכננו את המשימות בצינור עיבוד הנתונים של למידת המכונה כך שיפעלו באזורים עם תמהיל האנרגיה הנקי ביותר. אתם יכולים להשתמש בדוח טביעת הרגל הפחמנית כדי לזהות את האזורים עם פליטת הפחמן הנמוכה ביותר. תזמנו משימות שדורשות משאבים רבים כמשימות באצווה בתקופות שבהן רשת החשמל המקומית כוללת אחוז גבוה יותר של אנרגיה נטולת פחמן (CFE).

אופטימיזציה של צינורות עיבוד נתונים

פעולות ML וכוונון עדין דורשים קבוצת נתונים נקייה ואיכותית. לפני שמתחילים משימות של למידת מכונה, כדאי להשתמש בשירותים מנוהלים לעיבוד נתונים כדי להכין את הנתונים בצורה יעילה. לדוגמה, אפשר להשתמש ב-Dataflow לעיבוד בסטרימינג וברצף, וב-Managed Service for Apache Spark לצינורות עיבוד נתונים מנוהלים של Spark ו-Hadoop. פייפליין נתונים שעבר אופטימיזציה עוזר לוודא שעומס העבודה של הכוונון לא ממתין לנתונים, וכך אתם יכולים למקסם את ניצול המשאבים ולצמצם את בזבוז האנרגיה.

שימוש ב-MLOps

כדי להפוך את כל מחזור החיים של למידת המכונה לאוטומטי ולנהל אותו, אתם יכולים להטמיע שיטות של תפעול למידת מכונה (MLOps). השיטות האלה עוזרות לוודא שהמודלים מנוטרים, מאומתים ונפרסים מחדש באופן יעיל, וכך למנוע אימון או הקצאת משאבים מיותרים.

שימוש בשירותים מנוהלים

במקום לנהל תשתית משלכם, אתם יכולים להשתמש בשירותי ענן מנוהלים כמו Gemini Enterprise Agent Platform. פלטפורמת הענן מטפלת בניהול המשאבים הבסיסיים, כך שאתם יכולים להתמקד בתהליך הכוונון. להשתמש בשירותים שכוללים כלים מובְנים לכוונון היפר-פרמטרים, למעקב אחרי מודלים ולניהול משאבים.

המאמרים הבאים

אופטימיזציה של השימוש במשאבים למטרות קיימוּת

העיקרון הזה, שמופיע בעמוד התווך של קיימוּת ב-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, מספר הרפליקות של הקונטיינרים (Pods) מותאם באופן אוטומטי על סמך מדדים מוגדרים מראש, כמו שימוש ב-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).

פיתוח תוכנה חסכונית באנרגיה

העיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות לכתיבת תוכנה שמפחיתה את צריכת האנרגיה ואת העומס על השרת.

סקירה כללית של העקרונות

כשאתם פועלים לפי השיטות המומלצות לפיתוח אפליקציות בענן, אתם מייעלים את צריכת האנרגיה של משאבי תשתית הענן: AI, מחשוב, אחסון ורשת. בנוסף, אתם עוזרים להפחית את צריכת המים של מרכזי הנתונים ואת צריכת האנרגיה של מכשירי משתמשי הקצה כשהם ניגשים לאפליקציות שלכם.

כדי לפתח תוכנה חסכונית באנרגיה, צריך לשלב שיקולי קיימוּת בכל שלבי מחזור החיים של התוכנה, החל מהתכנון והפיתוח ועד לפריסה, לתחזוקה ולארכוב. בספר האלקטרוני של Google Cloud , Build Software Sustainably, מוסבר בפירוט איך משתמשים ב-AI כדי לפתח תוכנות שמצמצמות את ההשפעה הסביבתית של עומסי העבודה בענן.

המלצות

ההמלצות בקטע הזה מקובצות לפי תחומי המיקוד הבאים:

צמצום עבודת החישוב

כדי לכתוב תוכנה חסכונית באנרגיה, צריך לצמצם את כמות החישובים הכוללת שהאפליקציה מבצעת. כל הוראה מיותרת, לולאה עודפת ותכונה נוספת צורכות אנרגיה, זמן ומשאבים. כדי לפתח תוכנה שמבצעת חישובים מינימליים, כדאי להשתמש בהמלצות הבאות.

כתיבת קוד קצר וממוקד

כדי לכתוב קוד מינימלי שחיוני להשגת התוצאות הנדרשות, השתמשו בגישות הבאות:

  • הימנעו מלוגיקה מיותרת ומעומס תכונות: כתבו קוד שמבצע רק את הפונקציות החיוניות. הימנעו מתכונות שמגדילות את התקורה החישובית ואת המורכבות, אבל לא מספקות ערך מדיד למשתמשים.
  • Refactor: כדי לשפר את היעילות האנרגטית לאורך זמן, כדאי לבדוק באופן קבוע את האפליקציות כדי לזהות תכונות שלא בשימוש. צריך להסיר או לשנות את התכונות האלה בהתאם.
  • הימנעו מפעולות מיותרות: אל תחשבו ערך ואל תפעילו פעולה עד שהתוצאה נדרשת. השתמשו בשיטות כמו הערכה עצלה, שמעכבת את החישובים עד שרכיב תלוי באפליקציה צריך את הפלט.
  • תנו עדיפות לקריאוּת וליכולת השימוש החוזר בקוד: כתבו קוד קריא שאפשר להשתמש בו שוב. הגישה הזו מצמצמת את הכפילויות ופועלת לפי עיקרון ה-DRY (אל תחזרו על עצמכם), שיכול לעזור להפחית את פליטות הפחמן שנובעות מפיתוח ותחזוקה של תוכנות.

שימוש בשמירה לקצה העורפי במטמון

שמירה במטמון בקצה העורפי מבטיחה שהאפליקציה לא תבצע את אותה פעולה שוב ושוב. שיעור גבוה של מציאות במטמון מוביל להפחתה כמעט לינארית בצריכת האנרגיה לכל בקשה. כדי להטמיע שמירה במטמון בקצה העורפי, אפשר להשתמש בשיטות הבאות:

  • שמירת נתונים נפוצים במטמון: אחסון נתונים שניגשים אליהם לעיתים קרובות במיקום זמני עם ביצועים גבוהים. לדוגמה, אפשר להשתמש בשירות לשמירה במטמון בזיכרון כמו Memorystore. כשאפליקציה מאחזרת נתונים ממטמון, נפח השאילתות במסד הנתונים ופעולות הקלט/פלט בדיסק מצטמצם. כתוצאה מכך, העומס על מסדי הנתונים והשרתים בקצה העורפי פוחת.
  • שמירת התגובות מה-API במטמון: כדי להימנע מקריאות מיותרות ויקרות לרשת, כדאי לשמור במטמון את התוצאות של בקשות API תכופות.
  • תעדוף של שמירה במטמון בזיכרון: כדי להימנע מפעולות קלט/פלט איטיות בדיסק ומשאילתות מורכבות במסד הנתונים, כדאי לאחסן נתונים בזיכרון במהירות גבוהה (RAM).
  • בוחרים אסטרטגיות מתאימות לכתיבה במטמון:
    • אסטרטגיית הכתיבה דרך המטמון מבטיחה שהנתונים ייכתבו באופן סינכרוני למטמון וגם למאגר המתמיד. האסטרטגיה הזו מגדילה את הסבירות למציאה במטמון (cache hit), כך שהאחסון המתמיד מקבל פחות בקשות קריאה שצורכות הרבה אנרגיה.
    • אסטרטגיית הכתיבה לאחור (write-behind) משפרת את הביצועים של אפליקציות שכוללות הרבה פעולות כתיבה. הנתונים נכתבים קודם במטמון, ומסד הנתונים מתעדכן באופן אסינכרוני מאוחר יותר. האסטרטגיה הזו מפחיתה את עומס הכתיבה המיידי במסדי נתונים איטיים יותר.
  • שימוש במדיניות פינוי חכמה: כדי לשמור על מטמון קטן ויעיל. כדי להסיר נתונים ישנים או לא שימושיים ולפנות מקום לנתונים שצריך לעיתים קרובות, השתמשו במדיניות כמו זמן חיים (TTL), הכי פחות בשימוש לאחרונה (LRU) והכי פחות בשימוש (LFU).

שימוש באלגוריתמים ובמבני נתונים יעילים

האלגוריתמים ומבני הנתונים שתבחרו יקבעו את מורכבות החישוב הגולמי של התוכנה. כשבוחרים אלגוריתמים ומבני נתונים מתאימים, מצמצמים את מספר מחזורי המעבד (CPU) ופעולות הזיכרון שנדרשים כדי להשלים משימה. פחות מחזורי מעבד ופעולות זיכרון מובילים לצריכת אנרגיה נמוכה יותר.

בחירת אלגוריתמים לסיבוכיות זמן אופטימלית

תנו עדיפות לאלגוריתמים שמשיגים את התוצאה הנדרשת בזמן הקצר ביותר. הגישה הזו עוזרת לצמצם את משך השימוש במשאבים. כדי לבחור אלגוריתמים שמבצעים אופטימיזציה של השימוש במשאבים, אפשר להשתמש בגישות הבאות:

  • התמקדות בהפחתת המורכבות: כדי להעריך את המורכבות, כדאי להסתכל מעבר למדדים של זמן הריצה ולהביא בחשבון את המורכבות התיאורטית של האלגוריתם. לדוגמה, בהשוואה למיון בועות, מיון מיזוג מפחית באופן משמעותי את העומס החישובי ואת צריכת האנרגיה של מערכי נתונים גדולים.
  • הימנעו מעבודה מיותרת: השתמשו בפונקציות מובנות שעברו אופטימיזציה בשפת התכנות או במסגרת שבחרתם. הפונקציות האלה מיושמות בדרך כלל בשפה ברמה נמוכה יותר וחסכונית יותר באנרגיה, כמו C או ++C, כך שהן מותאמות טוב יותר לחומרה הבסיסית בהשוואה לפונקציות שקודדו בהתאמה אישית.

בחירת מבני נתונים יעילים

מבני הנתונים שתבחרו קובעים את המהירות שבה אפשר לאחזר, להוסיף או לעבד נתונים. המהירות הזו משפיעה על השימוש במעבד (CPU) ועל השימוש בזיכרון. כדי לבחור מבני נתונים יעילים, השתמשו בגישות הבאות:

  • אופטימיזציה לחיפוש ולאחזור: לפעולות נפוצות כמו בדיקה אם פריט קיים או אחזור של ערך ספציפי, כדאי להשתמש במבני נתונים שמותאמים למהירות. לדוגמה, טבלאות גיבוב (hash maps) או קבוצות גיבוב (hash sets) מאפשרות חיפושים בזמן כמעט קבוע, וזו גישה חסכונית יותר באנרגיה מאשר חיפוש ליניארי במערך.
  • צמצום הזיכרון שבשימוש: מבני נתונים יעילים עוזרים לצמצם את הזיכרון הכולל שבשימוש באפליקציה. הפחתת הגישה לזיכרון והניהול שלו מובילה לצריכת חשמל נמוכה יותר. בנוסף, פרופיל זיכרון מצומצם מאפשר לתהליכים לפעול בצורה יעילה יותר, וכך לדחות את שדרוגי המשאבים.
  • שימוש במבנים ייעודיים: השתמשו במבני נתונים שנועדו לפתור בעיה מסוימת. לדוגמה, השתמשו במבנה נתונים מסוג trie לחיפוש מהיר של תחילת מחרוזת, והשתמשו בתור עדיפות כשאתם צריכים לגשת רק לערך הגבוה ביותר או הנמוך ביותר ביעילות.

אופטימיזציה של פעולות המחשוב והנתונים

כשמפתחים תוכנה, חשוב להתמקד בשימוש יעיל ופרופורציונלי במשאבים בכל סטאק התוכנות. המעבד (CPU), הזיכרון, הדיסק והרשת הם משאבים מוגבלים ומשותפים. להבין ששימוש יעיל במשאבים מוביל להפחתה משמעותית בעלויות ובצריכת האנרגיה.

אופטימיזציה של ניצול המעבד וזמן חוסר הפעילות

כדי לצמצם את הזמן שבו המעבד (CPU) נמצא במצב פעיל וצורך אנרגיה בלי לבצע עבודה משמעותית, אפשר להשתמש בגישות הבאות:

  • העדפת לוגיקה מבוססת-אירועים על פני דגימה: החליפו לולאות עמוסות שצורכות הרבה משאבים או בדיקה מתמדת (דגימה) בלוגיקה מבוססת-אירועים. ארכיטקטורה מבוססת-אירועים מבטיחה שרכיבי האפליקציה יפעלו רק כשהם מופעלים על ידי אירועים רלוונטיים. הגישה הזו מאפשרת עיבוד על פי דרישה, וכך אין צורך בסקרים שצורכים הרבה משאבים.
  • מניעת תדירות גבוהה קבועה: כותבים קוד שלא מאלץ את המעבד לפעול כל הזמן בתדירות הגבוהה ביותר שלו. כדי לצמצם את צריכת האנרגיה, מערכות שלא נמצאות בשימוש צריכות להיות מסוגלות להיכנס למצבי צריכת חשמל נמוכה או למצבי שינה.
  • שימוש בעיבוד אסינכרוני: כדי למנוע נעילה של שרשורים בזמני המתנה, כדאי להשתמש בעיבוד אסינכרוני. הגישה הזו מפנה משאבים ומובילה לניצול גבוה יותר של המשאבים באופן כללי.

ניהול יעיל של הזיכרון ושל הקלט/פלט (I/O) של הדיסק

שימוש לא יעיל בזיכרון ובדיסק מוביל לעיבוד מיותר ולצריכת חשמל מוגברת. כדי לנהל את הזיכרון ואת הקלט/פלט ביעילות, השתמשו בשיטות הבאות:

  • ניהול זיכרון מחמיר: ביצוע פעולות לשחרור יזום של משאבי זיכרון שלא בשימוש. אל תשמרו אובייקטים גדולים בזיכרון לפרקי זמן ארוכים יותר מהנדרש. הגישה הזו מונעת צווארי בקבוק בביצועים ומפחיתה את צריכת החשמל שנדרשת לגישה לזיכרון.
  • אופטימיזציה של קלט/פלט בדיסק: צמצום התדירות של אינטראקציות הקריאה והכתיבה של האפליקציה עם משאבי אחסון מתמידים. לדוגמה, אפשר להשתמש במאגר נתונים זמני (buffer) כדי לאחסן נתונים. כותבים את הנתונים באחסון מתמיד במרווחי זמן קבועים או כשהמאגר מגיע לגודל מסוים.
  • פעולות באצווה: מאחדים פעולות קטנות ותכופות בדיסק לפעולות גדולות יותר באצווה. פעולה באצווה צורכת פחות אנרגיה מאשר הרבה טרנזקציות קטנות ונפרדות.
  • שימוש בדחיסה: כדי להפחית את כמות הנתונים שנכתבים בדיסקים או נקראים מהם, אפשר להשתמש בשיטות מתאימות לדחיסת נתונים. לדוגמה, כדי לדחוס נתונים שמאוחסנים ב-Cloud Storage, אתם יכולים להשתמש בהמרת קידוד עם פריסה.

צמצום התנועה ברשת

משאבי הרשת צורכים הרבה אנרגיה במהלך פעולות של העברת נתונים. כדי לבצע אופטימיזציה של התקשורת ברשת, אפשר להשתמש בשיטות הבאות:

  • צמצום גודל המטען הייעודי (payload): תכננו את ממשקי ה-API והאפליקציות כך שיעבירו רק את הנתונים שנדרשים לבקשה. הימנעו מאחזור או החזרה של מבני JSON או XML גדולים במקרים שבהם נדרשים רק כמה שדות. חשוב לוודא שמבני הנתונים שמוחזרים הם תמציתיים.
  • צמצום מספר הנסיעות הלוך ושוב: כדי לצמצם את מספר הנסיעות הלוך ושוב ברשת שנדרשות להשלמת פעולת משתמש, השתמשו בפרוטוקולים חכמים יותר. לדוגמה, עדיף להשתמש ב-HTTP/3 על פני HTTP/1.1, לבחור ב-GraphQL על פני REST, להשתמש בפרוטוקולים בינאריים ולאחד קריאות ל-API. כשמפחיתים את נפח הקריאות לרשת, מפחיתים את צריכת האנרגיה גם בשרתים וגם במכשירי משתמשי הקצה.

הטמעת אופטימיזציה של ממשק המשתמש

אופטימיזציה של ממשק המשתמש מצמצמת את הנתונים שמשתמשי הקצה צריכים להוריד ולעבד, וכך מפחיתה את העומס על המשאבים של מכשירי משתמשי הקצה.

צמצום הקוד והנכסים

כשמשתמשי הקצה צריכים להוריד ולעבד משאבים קטנים יותר ומובנים בצורה יעילה יותר, המכשירים שלהם צורכים פחות חשמל. כדי לצמצם את נפח ההורדה ואת עומס העיבוד במכשירי משתמשי הקצה, כדאי להשתמש בשיטות הבאות:

  • צמצום ודחיסה: בקובצי JavaScript,‏ CSS ו-HTML, הסירו תווים מיותרים כמו רווחים לבנים והערות באמצעות כלי צמצום מתאימים. חשוב לוודא שקבצים כמו תמונות דחוסים ועברו אופטימיזציה. אתם יכולים להפוך את המזעור והדחיסה של נכסי האינטרנט לאוטומטיים באמצעות צינור עיבוד נתונים של CI/CD.
  • טעינה מדורגת: טוענים תמונות, סרטונים ונכסים לא קריטיים רק כשהם נחוצים בפועל, למשל כשהרכיבים האלה נגללים לאזור התצוגה של דף אינטרנט. הגישה הזו מצמצמת את נפח העברת הנתונים הראשונית ואת עומס העיבוד במכשירי משתמשי הקצה.
  • חבילות JavaScript קטנות יותר: הסירו קוד שלא בשימוש מחבילות ה-JavaScript באמצעות כלים מודרניים לאריזת מודולים וטכניקות כמו tree shaking. הגישה הזו מאפשרת ליצור קבצים קטנים יותר שנטענים מהר יותר ומשתמשים בפחות משאבי שרת.
  • שמירה במטמון הדפדפן: משתמשים בכותרות של שמירה במטמון HTTP כדי להורות לדפדפן של המשתמש לאחסן נכסים סטטיים באופן מקומי. שמירה במטמון הדפדפן עוזרת למנוע הורדות חוזרות ותנועה מיותרת ברשת בביקורים הבאים.

תעדוף של חוויית משתמש (UX) קלה ומהירה

לעיצוב של ממשק המשתמש יכולה להיות השפעה משמעותית על המורכבות החישובית של עיבוד תוכן בקצה הקדמי. כדי לפתח ממשקי קצה קדמי המספקים חוויית שימוש קלה, השתמשו בשיטות הבאות:

  • עיבוד יעיל: הימנעו משינויים תכופים ב-Document Object Model (DOM) שדורשים משאבים רבים. כתבו קוד שמצמצם את מורכבות העיבוד ומבטל עיבוד מחדש מיותר.
  • תבניות עיצוב קלות משקל: במקרים המתאימים, עדיף להשתמש באתרים סטטיים או ב-Progressive Web Apps ‏ (PWA). אתרים ואפליקציות כאלה נטענים מהר יותר ודורשים פחות משאבי שרת.
  • נגישות וביצועים: אתרים רספונסיביים שנטענים מהר הם בדרך כלל נגישים יותר ופחות מזיקים לסביבה. עיצוב אופטימלי ונקי מצמצם את המשאבים שנדרשים לעיבוד התוכן. אתרים שעברו אופטימיזציה לביצועים ולמהירות יכולים לעזור להגדיל את ההכנסות. לפי מחקר של Deloitte ו-Google, Milliseconds Make Millions, שיפור של 0.1 שניות (100 אלפיות השנייה) במהירות האתר מוביל לעלייה של 8.4% בהמרות באתרים קמעונאיים ולעלייה של 9.2% בערך ההזמנה הממוצע.

אופטימיזציה של נתונים ואחסון למטרות קיימוּת

העיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לשפר את יעילות האנרגיה ואת טביעת הרגל הפחמנית של משאבי האחסון ב- Google Cloud.

סקירה כללית של העקרונות

הנתונים שמאוחסנים הם לא משאב פסיבי. בכל שלב במחזור החיים של הנתונים, יש צריכת אנרגיה ופליטות פחמן. כל ג'יגה-בייט של נתונים שמאוחסנים דורש תשתית פיזית שמופעלת, מקוררת ומנוהלת באופן רציף. כדי ליצור ארכיטקטורת ענן בת קיימא, צריך להתייחס לנתונים כנכס חשוב אבל יקר מבחינה סביבתית, ולתת עדיפות למשילות מידע (data governance) יזומה.

ההחלטות שלכם לגבי שמירת הנתונים, האיכות והמיקום שלהם יכולות לעזור לכם להפחית באופן משמעותי את עלויות הענן ואת צריכת האנרגיה. צמצמו את כמות הנתונים שאתם מאחסנים, בצעו אופטימיזציה של המיקום ושל אופן האחסון של הנתונים, והטמיעו אסטרטגיות אוטומטיות למחיקה ולארכוב. כשמצמצמים את עומס הנתונים, משפרים את ביצועי המערכת ומפחיתים באופן משמעותי את טביעת הרגל הסביבתית של הנתונים לטווח הארוך.

המלצות

כדי לבצע אופטימיזציה של משאבי האחסון ומחזור החיים של הנתונים למטרות קיימוּת, כדאי לפעול לפי ההמלצות שבקטעים הבאים.

תעדוף של נתונים בעלי ערך גבוה

נתונים מאוחסנים שלא בשימוש, כפולים או מיושנים ממשיכים לצרוך אנרגיה כדי להפעיל את התשתית הבסיסית. כדי לצמצם את טביעת הרגל הפחמנית שקשורה לאחסון, אפשר להשתמש בשיטות הבאות.

זיהוי והסרה של כפילויות

קבעו כללי מדיניות כדי למנוע שכפול מיותר של מערכי נתונים בכמה פרויקטים או שירותים של Google Cloud . השתמשו במאגרי נתונים מרכזיים כמו מערכי נתונים ב-BigQuery או קטגוריות של Cloud Storage כמקורות אמת יחידים, ותנו גישה מתאימה למאגרים האלה.

הסרת נתונים לא מתועדים ונתונים לא מנוהלים

נתונים לא ידועים הם נתונים שהתועלת או הבעלים שלהם לא ידועים. נתונים לא מורשים הם עותקים לא מורשים של נתונים. סורקים את מערכות האחסון ומוצאים נתונים לא ידועים ונתונים לא מנוהלים באמצעות פתרון לגילוי נתונים ולקטלוג, כמו Knowledge Catalog. חשוב לבדוק את הממצאים האלה באופן קבוע ולהטמיע תהליך לארכוב או למחיקה של נתונים לא מתועדים ונתונים לא מנוהלים, לפי הצורך.

צמצום נפח הנתונים של עומסי עבודה ב-AI

שומרים רק את המאפיינים והנתונים המעובדים שנדרשים לאימון המודל ולהצגת התוצאות. כשאפשר, כדאי להשתמש בשיטות כמו דגימת נתונים, צבירת נתונים ויצירת נתונים סינתטיים כדי להשיג ביצועי מודל בלי להסתמך על מערכי נתונים גולמיים עצומים.

שילוב בדיקות של איכות הנתונים

הטמיעו צינורות עיבוד נתונים אוטומטיים לאימות ולניקוי נתונים באמצעות שירותים כמו Managed Service for Apache Spark,‏ Dataflow או Knowledge Catalog בנקודת הטמעת הנתונים. נתונים באיכות נמוכה מבזבזים נפח אחסון. הוא גם מוביל לצריכת אנרגיה מיותרת כשמשתמשים בנתונים האלה מאוחר יותר לניתוח או לאימון AI.

בדיקת צפיפות הערך של הנתונים

בודקים מדי פעם קבוצות נתונים בנפח גבוה, כמו יומנים וזרמי IoT. בדקו אם אפשר לסכם, לצבור או לדגום את הנתונים כדי לשמור על צפיפות המידע הנדרשת ולהקטין את נפח האחסון הפיזי.

בחינה ביקורתית של הצורך בגיבויים

העריכו את הצורך בגיבויים של נתונים שאתם יכולים ליצור מחדש במינימום מאמץ. דוגמאות לנתונים כאלה כוללות תוצאות ETL זמניות, מטמונים זמניים ונתוני אימון שנגזרים ממקור יציב וקבוע. שמרו גיבויים רק של נתונים ייחודיים או כאלה שקשה לשחזר.

אופטימיזציה של ניהול מחזור החיים של האחסון

להפוך את מחזור החיים של האחסון לאוטומטי, כך שכאשר התועלת של הנתונים פוחתת, הנתונים מועברים לסוג אחסון חסכוני באנרגיה או מוצאים משימוש, לפי הצורך. השתמשו בשיטות הבאות.

בחירת סוג האחסון המתאים ב-Cloud Storage

באמצעות ניהול מחזור החיים של אובייקטים, אתם יכולים להעביר באופן אוטומטי נתונים ב-Cloud Storage לסוגי אחסון עם פליטת פחמן נמוכה יותר, על סמך תדירות הגישה.

  • השתמשו ב-Standard Storage רק לקבוצות נתונים שאתם משתמשים בהן באופן פעיל, כמו מודלים נוכחיים של ייצור.
  • העברת נתונים כמו מערכי נתונים ישנים יותר לאימון AI או גיבויים שניגשים אליהם בתדירות נמוכה יותר לאחסון Nearline או Coldline Storage.
  • לשמירה לטווח ארוך, השתמשו ב-Archive Storage, שמותאם ליעילות אנרגטית בקנה מידה גדול.

הטמעת מדיניות מחמירה בנושא מחזור החיים של הנתונים

הגדירו כללי מדיניות ברורים ואוטומטיים של אורך חיים (TTL) לנתונים לא חיוניים, כמו קובצי יומן, פריטי מידע זמניים של מודלים ותוצאות ביניים מיושנות. אפשר להשתמש בכללי מחזור חיים כדי למחוק נתונים כאלה באופן אוטומטי אחרי פרק זמן מוגדר.

הוספת תגים למשאבים

לחייב שימוש בתגים ובתוויות עקביים של משאבים בכל הקטגוריות של Cloud Storage, מערכי הנתונים של BigQuery והדיסקים הקבועים. יוצרים תגים שמציינים את הבעלים של הנתונים, את מטרת הנתונים ואת תקופת השמירה. כדי לוודא שהתגים הנדרשים, כמו תקופת שמירה, חלים על המשאבים, אפשר להשתמש באילוצים של שירות מדיניות הארגון. התגים מאפשרים לכם להפוך את ניהול מחזור החיים לאוטומטי, ליצור דוחות FinOps מפורטים ולהפיק דוחות על פליטות פחמן.

התאמת הגודל וביטול ההקצאה של אחסון המחשוב

בדקו באופן קבוע את הדיסקים לאחסון מתמיד שמחוברים למכונות של Compute Engine, וודאו שהם לא מוקצים יתר על המידה. השתמשו בתמונות מצב רק כשהן נחוצות לגיבוי. מוחקים קובצי snapshot ישנים שלא בשימוש. במסדי נתונים, כדאי להשתמש במדיניות שמירת נתונים כדי להקטין את הגודל של הדיסקים לאחסון מתמיד.

אופטימיזציה של פורמט האחסון

לאחסון שמשמש לעומסי עבודה של ניתוח נתונים, עדיף להשתמש בפורמטים דחוסים של עמודות כמו Parquet או Avro שעבר אופטימיזציה, על פני פורמטים שמבוססים על שורות כמו JSON או CSV. אחסון בעמודות מפחית באופן משמעותי את הדרישות הפיזיות של המקום בכונן ומשפר את יעילות הקריאה. האופטימיזציה הזו עוזרת לצמצם את צריכת האנרגיה של פעולות החישוב והקלט/פלט שמשויכות אליה.

אופטימיזציה של האזוריות ותנועת הנתונים

המיקום הפיזי והתנועה של הנתונים משפיעים על צריכת משאבי הרשת ועל האנרגיה שנדרשת לאחסון. כדי לבצע אופטימיזציה של אזוריות הנתונים, אפשר להשתמש בשיטות הבאות.

בחירת אזורי אחסון דלי-פחמן

בהתאם לדרישות התאימות שלכם, אחסנו נתונים באזורים ב- Google Cloud שמשתמשים באחוז גבוה יותר של אנרגיה נטולת פחמן (CFE) או ששיעור פליטת הפחמן ברשת שלהם נמוך יותר. להגביל את היצירה של קטגוריות אחסון באזורים עם פליטת פחמן גבוהה, באמצעות האילוץ מיקומי משאבים במדיניות הארגון. במאמר אנרגיה נטולת פחמן באזורי Google Cloud מוסבר על נתוני CFE ושיעור פליטת הפחמן באזורי Google Cloud .

צמצום הרפליקציה

שכפלו נתונים בין אזורים רק כדי לעמוד בדרישות החובה של תוכנית התאוששות מאסון (DR) או של זמינות גבוהה (HA). פעולות של שכפול בין אזורים ובמספר אזורים מגדילות באופן משמעותי את עלות האנרגיה ואת טביעת הרגל הפחמנית של הנתונים.

אופטימיזציה של מיקומי עיבוד הנתונים

כדי להפחית את צריכת האנרגיה בהעברת נתונים ברשת, כדאי לפרוס עומסי עבודה שדורשים משאבי מחשוב רבים, כמו אימון AI ועיבוד ב-BigQuery, באותו אזור שבו נמצא מקור הנתונים.

אופטימיזציה של העברת נתונים לשותפים וללקוחות

כדי להעביר כמויות גדולות של נתונים בין שירותי ענן, מיקומים וספקים, עודדו את השותפים והלקוחות שלכם להשתמש ב-Storage Transfer Service או בממשקי API לשיתוף נתונים. הימנעו מהעלאת כמויות גדולות של נתונים. במערכי נתונים ציבוריים, השתמשו בקטגוריות המבקש משלם כדי להעביר את עלויות העיבוד וההעברה של הנתונים ואת ההשפעה על הסביבה למשתמשי הקצה.

מדידה ושיפור של הקיימוּת באופן שוטף

העיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם למדוד ולשפר באופן קבוע את הקיימוּת של עומסי העבודה ב- Google Cloud.

סקירה כללית של העקרונות

כדי לוודא שעומסי העבודה בענן יישארו קיימים, צריך מדדים מדויקים ושקופים. מדדים שניתנים לאימות מאפשרים לכם לתרגם את יעדי הקיימות לפעולות. לכל משאב שאתם יוצרים בענן יש טביעת רגל פחמנית משויכת. כדי לבנות ולתחזק ארכיטקטורות ענן ברות-קיימא, צריך לשלב את מדידת נתוני הפחמן בלולאת המשוב התפעולי.

ההמלצות בקטע הזה מספקות מסגרת לשימוש בטביעת רגל פחמנית כדי לכמת את פליטות הפחמן, לזהות נקודות חמות של פחמן, להטמיע אופטימיזציות ממוקדות של עומסי עבודה ולאמת את התוצאות של מאמצי האופטימיזציה. המסגרת הזו מאפשרת לכם להתאים ביעילות בין יעדי האופטימיזציה של העלויות לבין יעדים ניתנים לאימות להפחתת פליטות הפחמן.

המתודולוגיה לדיווח על טביעת הרגל הפחמנית

הכלי "טביעת רגל פחמנית" מספק דוח שקוף, שניתן לבדיקה ותואם לתקנים גלובליים, על פליטות הגזים שקשורות לענן. הדוח עומד בתקנים בינלאומיים, בעיקר בפרוטוקול גז החממה (GHG) לדיווח ולחישוב של פליטות פחמן. בדוח טביעת רגל פחמנית נעשה שימוש בשיטות חשבונאות מבוססות-מיקום ומבוססות-שוק. חישוב מבוסס-מיקום מבוסס על פקטור הפליטות של רשת החשמל המקומית. בחשבונאות מבוססת-שוק מביאים בחשבון את רכישות האנרגיה נטולת הפחמן (CFE) של Google. הגישה הכפולה הזו עוזרת להבין את ההשפעה על הרשת הפיזית ואת היתרון של עומסי העבודה ב- Google Cloudמבחינת פליטת הפחמן.

במאמר המתודולוגיה של הדיווח על טביעת הרגל הפחמנית מוסבר איך מכינים את הדוח, כולל מקורות הנתונים שבהם משתמשים, הכללות של היקף 3 ומודל ההקצאה ללקוחות.

המלצות

כדי להשתמש במדידת פחמן לשיפור מתמשך, כדאי לעיין בהמלצות שבסעיפים הבאים. ההמלצות בנויות לפי שלבי הבשלות של הטמעת פעולות בענן שתוכננו מראש תוך התחשבות בקיימוּת:

שלב 1: קביעת נקודת השוואה

בשלב הזה מגדירים את הכלים הנדרשים ומוודאים שהנתונים נגישים ומשולבים בצורה נכונה.

  1. מתן הרשאות: נותנים הרשאות לצוותים כמו FinOps,‏ SecOps והנדסת פלטפורמות, כדי שהם יוכלו לגשת למרכז הבקרה של טביעת הרגל הפחמנית במסוף Google Cloud . מקצים את התפקיד "צפייה בטביעת הרגל הפחמנית" (roles/billing.carbonViewer) בממשק לניהול זהויות והרשאות גישה (IAM) לחשבון החיוב המתאים.
  2. ייצוא אוטומטי של נתונים: לפני שאתם מייצאים נתונים, ודאו שהיררכיית המשאבים (תיקיות ופרויקטים) וההערות על המשאבים (תגים ותוויות) משקפות במדויק את הארגון של היחידות העסקיות שלכם.Google Cloudהנתונים של טביעת הרגל הפחמנית נצברים ברמת הפרויקט, ולכן חשוב להגדיר היררכיה ברורה כדי לשייך את פליטות הגז בצורה נכונה. להגדיר ייצוא אוטומטי של נתוני טביעת הרגל הפחמנית ל-BigQuery. הנתונים שמיוצאים מאפשרים לכם לבצע ניתוח מעמיק, לקשר בין נתוני הפחמן לנתוני העלות והשימוש ולהפיק דוחות בהתאמה אישית.
  3. הגדרת מדדי ביצועים מרכזיים (KPI) שקשורים לפחמן: קובעים מדדים שמקשרים בין פליטות פחמן לערך העסקי. לדוגמה, שיעור פליטת הפחמן הוא מדד למספר הקילוגרמים של CO2 שווה ערך לכל לקוח, עסקה או יחידת הכנסה.

שלב 2: זיהוי מוקדים של פליטת פחמן

כדי לזהות את התחומים שבהם ההשפעה על הסביבה היא הגדולה ביותר, אפשר לנתח את הנתונים המפורטים בדוח "טביעת רגל פחמנית". כדי לבצע את הניתוח הזה, השתמשו בשיטות הבאות:

  • תעדוף לפי היקף: כדי לזהות במהירות את פולטי הפחמן הגדולים ביותר, נתחו את הנתונים בלוח הבקרה לפי פרויקט, אזור ושירות.
  • שימוש בחשבונאות כפולה: כשאתם מעריכים את ההשלכות של פליטת פחמן באזור מסוים, כדאי להביא בחשבון גם את הפליטות מבוססות-המיקום (ההשפעה הסביבתית של רשת החשמל המקומית) וגם את הפליטות מבוססות-השוק (היתרון של ההשקעות של Google באנרגיה ללא פחמן).
  • התאמה לעלות: שילוב נתוני הפחמן ב-BigQuery עם נתוני החיוב, והערכת ההשפעה של פעולות האופטימיזציה על הקיימוּת ועל העלות. למרות שהעלות וטביעת הרגל הפחמנית בדרך כלל נמצאות במגמה דומה, אפשר להשתמש בעלות רק כאינדיקטור ראשוני. לדוגמה, באזורים יקרים עם ציוני אנרגיה נטולת פחמן (CFE) גבוהים, לעומסי העבודה יכולה להיות עלות גבוהה אבל פליטות נמוכות לפי השוק. תמיד צריך לאמת את הנחות האופטימיזציה מול מדדים אמיתיים שמבוססים על מיקום ומדדים שמבוססים על השוק.
  • הוספת הערות לנתונים כדי למדוד את החזר ההשקעה (ROE): מוסיפים הערות לנתוני הפחמן ב-BigQuery עם אירועים ספציפיים, כמו התאמת משאב או הוצאה משימוש של שירות גדול. ההערות מאפשרות לשייך את ההפחתה בפליטות הפחמן ובעלויות ליוזמות אופטימיזציה ספציפיות, כדי שתוכלו למדוד ולהציג את התוצאות של כל יוזמה.

שלב 3: הטמעת אופטימיזציה ממוקדת

זהו שלב הביצוע להטמעת פעולות בענן שתוכננו מראש תוך התחשבות בקיימוּת. כדי לבצע אופטימיזציה של משאבים ספציפיים שזיהיתם כגורמים משמעותיים לעלויות ולפליטות פחמן, אתם יכולים להשתמש בשיטות הבאות:

  • הוצאה משימוש של פרויקטים לא פעילים: כחלק מתהליכי העבודה של ניהול שירותי IT‏ (ITSM), כדאי לבדוק באופן קבוע את שירות ההמלצות לפרויקטים לא פעילים שמשולב עם נתוני טביעת הרגל הפחמנית. כדי להשיג הפחתה מיידית ומאומתת בפליטות הפחמן ובעלויות, כדאי להפוך לאוטומטי את תהליך הבדיקה וההסרה של פרויקטים שלא בשימוש באמצעות כרטיסי הנדסה במעקב.
  • התאמת גודל המשאבים: התאמת קיבולת המשאבים שהוקצו לניצול בפועל באמצעות המלצות של Active Assist להתאמת גודל, כמו המלצות לסוגי מכונות וירטואליות של Compute Engine. למשימות שדורשות הרבה משאבי מחשוב ולעומסי עבודה של AI, השתמשו בסוגי המכונות ובמודלים של AI הכי יעילים.
  • תזמון מבוסס-פחמן: בעומסי עבודה באצווה שלא קריטיים מבחינת הזמן, שלבו את נתוני ה-CFE האזוריים בלוגיקת התזמון. במידת האפשר, הגבילו את היצירה של משאבים חדשים לאזורים דלי-פחמן באמצעות האילוץ מיקומי משאבים בשירות מדיניות הארגון.
  • צמצום התפשטות הנתונים: כדאי להטמיע מדיניות של משילות מידע (data governance) כדי לוודא שנתונים שניגשים אליהם לעיתים רחוקות מועברים לסוג אחסון מתאים לשימוש נדיר (Nearline,‏ Coldline או Archive) או נמחקים באופן סופי. האסטרטגיה הזו עוזרת להפחית את עלות האנרגיה של משאבי האחסון.
  • שיפור קוד האפליקציה: תיקון חוסר יעילות ברמת הקוד שגורם לשימוש מופרז במשאבים או לחישובים מיותרים.

למידע נוסף, קראו את המאמרים הבאים:

שלב 4: הפיכת שיטות העבודה והדיווח בנושא קיימוּת לחלק מהתרבות הארגונית

בשלב הזה, אתם מטמיעים את מדידת הפחמן במסגרת הממשל שלכם. הגישה הזו עוזרת לוודא שלארגון יש את היכולות ואמצעי הבקרה שנדרשים כדי לשפר את הקיימוּת באופן רציף ולדווח על כך בצורה שניתנת לאימות.

  • הטמעת ניהול תקין של GreenOps: הגדירו פונקציה או קבוצת עבודה רשמית של GreenOps כדי לשלב את נתוני טביעת הרגל הפחמנית עם נתוני החיוב ב-Cloud. לשלב את הייצוא החודשי של נתוני פליטת הפחמן ל-BigQuery ישירות בלוחות הבקרה הקיימים של FinOps, כמו Looker. הצגת נתוני הפחמן והעלות בממשק אחד עוזרת להבטיח שהקיימוּת תהיה חלק ממחזור הבדיקה התפעולית הרגילה. התפקיד הזה צריך להגדיר את האחריות ליעדי הפחתת פליטת הפחמן בפרויקטים, להתאים את אופטימיזציית העלויות ליעדי הקיימוּת ולהטמיע דיווח כדי לעקוב אחרי יעילות הפחמן ביחס להוצאות.
  • שימוש בנתוני טביעת הרגל הפחמנית לצורכי דיווח ותאימות: אתם יכולים להשתמש בנתוני טביעת הרגל הפחמנית המאומתים והניתנים לביקורת ב-BigQuery כדי ליצור גילויים נאותים רשמיים בנושאי סביבה, חברה וממשל (ESG). הגישה הזו מאפשרת לכם לעמוד בדרישות של בעלי העניין לשקיפות, ועוזרת להבטיח עמידה בתקנות חובה ובתקנות וולונטריות.
  • השקעה בהדרכה ובהעלאת המוּדעוּת: הטמעת הדרכה חובה בנושא קיימוּת לצוותים טכניים ולא טכניים רלוונטיים. הצוותים שלכם צריכים לדעת איך לגשת לנתונים של טביעת הרגל הפחמנית, איך לפרש אותם ואיך ליישם את ההמלצות לאופטימיזציה בתהליכי העבודה היומיומיים ובבחירות העיצוביות שלהם. למידע נוסף, קראו את המאמר הדרכה בנושא קיימוּת לפי תפקיד.
  • הגדרת דרישות פחמן: משלבים מדדי פליטת פחמן כדרישות לא פונקציונליות (NFR) בקריטריונים לקבלת האפליקציה לפריסות חדשות. כך אפשר לוודא שהאדריכלים והמפתחים יתעדפו אפשרויות תכנון דלות-פחמן כבר מתחילת מחזור החיים של פיתוח האפליקציה.
  • אוטומציה של GreenOps: אוטומציה של הטמעת ההמלצות של Active Assist באמצעות סקריפטים, תבניות וצינורות עיבוד נתונים של תשתית כקוד (IaC). כך הצוותים יכולים ליישם את ההמלצות באופן עקבי ומהיר בכל הארגון.

לקדם תרבות של קיימוּת

העיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לבנות תרבות שבה הצוותים בארגון מודעים לשיטות הקיימוּת ומיומנים בהן.

סקירה כללית של העקרונות

כדי ליישם שיטות קיימוּת, צריך יותר מכלים וטכניקות. צריך לשנות את התרבות הארגונית באמצעות חינוך ואחריותיות. הצוותים שלכם צריכים להיות מודעים לנושאים שקשורים לקיימות, ולהיות בעלי מיומנות מעשית בשיטות קיימות.

  • מודעות לקיימוּת היא הידע ההקשרי שלכל החלטה שקשורה לארכיטקטורה ולתפעול יש השפעות מוחשיות על הקיימוּת. הצוותים צריכים להבין שהענן הוא לא אוסף מופשט של משאבים וירטואליים, אלא שהוא מופעל על ידי משאבים פיזיים שצורכים אנרגיה ומייצרים פליטות פחמן.
  • מיומנות בשיטות קיימוּת כוללת ידע בפירוש נתונים של פליטות פחמן, ניסיון בהטמעת ניהול קיימוּת בענן ומיומנויות טכניות לשכתוב קוד לשיפור יעילות אנרגטית.

כדי להתאים את שיטות העבודה לקיימוּת ליעדים של הארגון, הצוותים צריכים להבין איך צריכת האנרגיה של תשתית הענן והתוכנה משפיעה על טביעת הרגל הפחמנית של הארגון. הדרכה מתוכננת היטב עוזרת לוודא שכל בעלי העניין – ממפתחים ואדריכלים ועד לאנשי כספים ומהנדסי תפעול – מבינים את ההקשר של קיימוּת בעבודה היומיומית שלהם. ההבנה המשותפת הזו מאפשרת לצוותים לעבור מעמידה פסיבית בדרישות לאופטימיזציה אקטיבית, וכך להפוך את עומסי העבודה בענן לקיימים כבר בשלב התכנון. קיימוּת הופכת לדרישה לא פונקציונלית (NFR) מרכזית, כמו דרישות אחרות שקשורות לאבטחה, עלות, ביצועים ואמינות.

המלצות

כדי להגביר את המודעות לנושאים שקשורים לקיימוּת ולשפר את המיומנות בשיטות עבודה שקשורות לקיימוּת, כדאי לפעול לפי ההמלצות שבקטעים הבאים.

לספק הקשר עסקי ולהתאים את עצמו ליעדים של הארגון

קיימות היא לא רק תרגיל טכני, היא דורשת שינוי תרבותי שמתאים את הפעולות של כל אחד למשימה הסביבתית של הארגון. כשצוותים מבינים את הסיבה שמאחורי יוזמות הקיימוּת, יש סיכוי גבוה יותר שהם יאמצו את היוזמות כעקרונות ליבה ולא כמשימות אופציונליות.

התמונה הגדולה

כדאי לעזור לצוותים להבין איך בחירות ארכיטקטוניות ספציפיות, כמו בחירת אזור דל-פחמן או אופטימיזציה של פייפליין, תורמות למחויבות הכוללת של הארגון לקיימוּת. חשוב להסביר בצורה ברורה איך הבחירות האלה משפיעות על הקהילה המקומית ועל התעשייה. הפיכת מדדי פחמן מופשטים לאינדיקטורים מוחשיים של התקדמות לקראת יעדי אחריות חברתית תאגידית (CSR).

לדוגמה, הודעה כמו זו שלמטה מיידעת את הצוותים על התוצאה החיובית ועל ההכרה של ההנהלה בהחלטה להעביר עומס עבודה לאזור דל-פחמן ולהשתמש בסוג מכונה חסכונית בחשמל. ההודעה מתייחסת לשווה ערך ל-CO2, שעוזר לצוות שלכם להבין את ההקשר של ההשפעה של אמצעים להפחתת פליטת הפחמן.

"העברנו את מנוע ניתוח הנתונים שלנו לאזור us-central1 עם סמל של עלה פליטת CO2 נמוכה, ושדרגנו את האשכולות שלנו למכונות מבוססות-Axion מסוג C4A. השינויים האלה שיפרו באופן משמעותי את פרופיל הפחמן שלנו. השינוי הזה הוביל להפחתה של 75% בשיעור פליטת הפחמן של המנוע שלנו לניתוח נתונים, כלומר הפחתה של 12 טון שווה ערך פחמן דו-חמצני (CO2) ברבעון הזה. המיגרציה הזו השפיעה באופן משמעותי על היעדים העסקיים שלנו, וכללנו אותה בניוזלטר של הרבעון הרביעי ששלחנו לדירקטוריון".

העברת מידע על יעדים פיננסיים ויעדי קיימוּת

השקיפות חיונית כדי להתאים את שיטות הקיימוּת ליעדים. ככל שניתן, כדאי לשתף את יעדי הקיימוּת ואת ההתקדמות בהשגתם עם כל הארגון. הדגשת ההתקדמות בתחום הקיימוּת בדוחות הכספיים השנתיים. תקשורת כזו מבטיחה שהצוותים הטכניים יראו את העבודה שלהם כחלק חיוני מההתחייבויות של הארגון כלפי הציבור ומהבריאות הפיננסית שלו.

אימוץ גישה של שת"פ הדוק

להסביר לצוותים על האופי השיתופי של קיימות בענן. ‫Google אחראית לקיימוּת של הענן, כולל היעילות של התשתית ושל מרכזי הנתונים. אתם (הלקוחות) אחראים לקיימוּת של המשאבים ועומסי העבודה שלכם בענן. כשמציגים את שיתוף הפעולה הזה כשותפות של שת"פ הדוק, זה מחזק את ההבנה שהארגון שלכם ו-Google פועלים יחד כדי להשיג תוצאות סביבתיות אופטימליות.

הדרכה בנושא קיימוּת לפי תפקיד

כדי לוודא שקיימוּת היא מיומנות מעשית ולא מושג תיאורטי, צריך להתאים את ההדרכה בנושא קיימוּת לתפקידים ספציפיים. הכלים והשיטות לקיימוּת שמדעני נתונים יכולים להשתמש בהם שונים מאוד מאלה שזמינים למנתחי FinOps, כפי שמתואר בטבלה הבאה:

תפקיד התמקדות באימון
מדעני נתונים ומהנדסי למידת מכונה (ML) שיעור פליטת הפחמן של המחשוב: הדגמת ההבדלים בין הרצת משימות אימון של AI במערכות מדור קודם לבין מאיצי AI ייעודיים. הדגישו איך מודל עם פחות פרמטרים יכול להפיק את הדיוק הנדרש עם צריכת אנרגיה נמוכה משמעותית.
מפתחים יעילות הקוד וצריכת המשאבים: הסבירו איך קוד עם זמן אחזור ארוך או לולאות לא יעילות משפיעים ישירות על זמן הריצה של המעבד (CPU) ועל צריכת האנרגיה. להדגיש את החשיבות של קונטיינרים קלים ואת הצורך באופטימיזציה של ביצועי האפליקציה כדי לצמצם את טביעת הרגל הסביבתית של התוכנה.
אדריכלים קיימוּת בתכנון: התמקדות בבחירת האזור ובמיקום עומס העבודה. להראות איך בחירה באזור עם סמל של עלה פליטת CO2 נמוכה ואחוז גבוה של אנרגיה מתחדשת (כמו northamerica-northeast1) משנה באופן מהותי את פרופיל הפחמן של כל מחסנית האפליקציות, עוד לפני שכותבים שורת קוד אחת.
מהנדסי פלטפורמות ומהנדסי תפעול ניצול מקסימלי: הדגשת העלות הסביבתית של משאבים לא פעילים והקצאת יתר. להציג תרחישים של התאמה אוטומטית לעומס (automatic scaling) והתאמה לגודל הנכון (right-sizing) כדי להבטיח שימוש יעיל במשאבי הענן. הסבירו איך ליצור ולעקוב אחרי מדדים שקשורים לקיימוּת, כמו ניצול, ואיך לתרגם מדדים כמו זמן מחשוב למדדים מקבילים של פליטות פחמן.
FinOps כלכלת יחידות של פחמן: התמקדות בקשר בין ההוצאה הכספית לבין ההשפעה על הסביבה. להדגים איך שיטות GreenOps מאפשרות לארגון לעקוב אחרי פליטת הפחמן לכל טרנזקציה, וכך להפוך את הקיימוּת למדד ביצועים מרכזי (KPI) שחשוב לא פחות ממדדי KPI רגילים כמו עלות וניצול.
מנהלי מוצר קיימות כתכונה: איך לשלב יעדים להפחתת פליטות פחמן בתוכניות השיווקיות של המוצרים. להראות איך התהליך שעובר המשתמש בצורה פשוטה יותר יכול לעזור להפחית את צריכת האנרגיה גם במשאבי הענן וגם במכשירי משתמשי הקצה.
מנהיגים עסקיים התאמה אסטרטגית ודיווח: התמקדות באופן שבו הקיימוּת בענן משפיעה על ציוני ESG (סביבה, חברה וממשל) ועל המוניטין הציבורי. להמחיש איך בחירות שמתחשבות בסביבה עוזרות להפחית את הסיכון הרגולטורי ולעמוד בהתחייבויות לקהילה ולתעשייה.

תמיכה בקיימות והכרה בהצלחה

כדי לשמור על התקדמות לטווח ארוך, צריך לעבור מעבר לתיקונים טכניים פנימיים ולהתחיל להשפיע על השותפים ועל התעשייה.

מנהלים יכולים לקדם קיימוּת

לספק למנהלים את הנתונים וההרשאות שהם צריכים כדי לתת עדיפות להשפעה על הסביבה, בדומה למדדים עסקיים אחרים כמו מהירות ההגעה לשוק ועלות. כשהמנהלים מקבלים את הנתונים האלה, הם מתחילים לראות בקיימוּת תקן של איכות ויעילות, ולא יכולת ש"נחמד שיש" אבל מאטה את הייצור. הם פועלים באופן פעיל כדי לקדם תכונות חדשות של ספקי שירותי ענן, כמו נתוני פחמן מפורטים יותר ומעבדים חדשים וידידותיים יותר לסביבה באזורים ספציפיים.

התאמה לסטנדרטים ולמסגרות המקובלים בתחום

כדי לוודא שהמאמצים שלכם בתחום הקיימוּת אמינים וניתנים למדידה, כדאי להתאים את השיטות הפנימיות לתקנים גלובליים ואזוריים מוכרים. למידע נוסף, קראו את המאמר התאמת שיטות הקיימוּת להנחיות הרווחות בתחום.

תמריצים למאמצי קיימוּת

כדי להבטיח שקיימות תהפוך לחלק בלתי נפרד מתרבות ההנדסה, הצוותים צריכים להבין את הערך של מתן עדיפות לקיימות. עוברים מיעדים ברמה גבוהה למדדי KPI ספציפיים וניתנים למדידה שמתגמלים על שיפור ויעילות.

הגדרת מדדי KPI ודרישות לא פונקציונליות (NFR) בנושא פחמן

התייחסו לקיימוּת כאל דרישה טכנית בסיסית. כשמגדירים מדדי KPI לפחמן, כמו שווה ערך לגרמים של CO2 למיליון בקשות או שיעור פליטת הפחמן לכל הרצת אימון של AI, ההשפעה על הקיימוּת הופכת לגלויה וניתן לפעול לפיה. לדוגמה, לשלב קיימוּת בדרישות הלא פונקציונליות של כל פרויקט חדש. במילים אחרות, כמו שמערכת צריכה לעמוד ביעד ספציפי של זמן אחזור או זמינות, היא צריכה גם לעמוד בתקציב מוגדר של פליטות פחמן.

מדידת ההחזר על המאמץ

עזרו לצוותים שלכם לזהות הישגים בתחום הקיימוּת שדורשים מאמץ קטן אבל יש להם השפעה גדולה, כמו העברת משימה באצווה לאזור אחר, לעומת תרגיל מורכב של ארגון הקוד מחדש שעשוי להניב רווחים מינימליים. לספק תובנות לגבי ההחזר על המאמץ (ROE). כשצוות בוחר משפחת מעבדים יעילה יותר, הוא צריך לדעת בדיוק כמה פליטות פחמן נמנעו ביחס לזמן ולמאמץ שנדרשו כדי לעבור למעבד החדש.

הכרה וציון של הפחתת פליטות הפחמן

ההשפעה על הקיימות מסתתרת לעיתים קרובות ברקע של התשתית. כדי לשמור על המומנטום של ההתקדמות בתחום הקיימוּת, חשוב להציג את ההצלחות לכל הארגון. לדוגמה, אפשר להשתמש בהערות בלוחות הבקרה כדי לסמן מתי הצוות פרס את האופטימיזציה הספציפית לקיימוּת. החשיפה הזו מאפשרת לצוותים להצביע על נתונים בלוח הבקרה ולקבל הכרה על ההצלחות שלהם.

התאמת שיטות הקיימוּת להנחיות הרווחות בתחום

בעיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מפורטות ההנחיות הרווחות בתחום והמסגרות שבהן כדאי להשתמש כדי להשיג את יעדי הקיימוּת.

סקירה כללית של העקרונות

כדי לוודא שיוזמות הקיימוּת שלכם מבוססות על שיטות מדידה, דיווח ואימות שמוכרות ברחבי העולם, מומלץ להתאים את היוזמות להנחיות הבאות:

כשאתם מתאימים את יוזמות הקיימוּת שלכם להנחיות החיצוניות המשותפות האלה, היוזמות שלכם מקבלות את האמינות ואת יכולת הביקורת שמשקיעים, גופים רגולטוריים ובעלי עניין חיצוניים אחרים דורשים. אתם גם מעודדים אחריותיות בקרב צוותי ההנדסה, מטמיעים קיימוּת בהדרכות לעובדים ומשלבים בהצלחה את פעולות הענן במחויבויות של כלל הארגון לדיווח על סביבה, חברה וממשל (ESG).

הנחיות W3C לקיימוּת באינטרנט

הנחיות W3C לקיימות באינטרנט (WSG) הן מסגרת מתפתחת של שיטות מומלצות שפותחו על ידי קבוצת עבודה של W3C כדי לטפל בהשפעה הסביבתית של מוצרים ושירותים דיגיטליים. ההנחיות מתייחסות לכל מחזור החיים של פתרון דיגיטלי, כולל אסטרטגיית מוצר ואסטרטגיה עסקית, עיצוב חוויית המשתמש (UX), פיתוח אתרים, אירוח, תשתית ומערכות. המטרה העיקרית של WSG היא לאפשר למפתחים ולאדריכלים לבנות אתרים ואפליקציות אינטרנט שצורכים פחות אנרגיה, ולהפחית את התנועה ברשת, את העיבוד בצד הלקוח ואת צריכת המשאבים בצד השרת. ההנחיות האלה משמשות כנקודת התייחסות קריטית להתאמת הקיימוּת ברמת האפליקציה להחלטות הארכיטקטוניות ברמת הענן.

Green Software Foundation

Green Software Foundation (GSF) מתמקדת בבניית סביבה עסקית סביב תוכנות שפועלות באופן בר-קיימא. המטרה של הקרן היא לעודד יצירת תוכנות שתוכננו, נבנו ומופעלות באופן שמצמצם את טביעת הרגל הפחמנית. ה-GSF פיתח את המפרט של שיעור פליטת הפחמן של תוכנה (SCI), שמספק תקן משותף למדידת שיעור פליטות הפחמן של כל תוכנה. התאמה ל-GSF עוזרת למפתחים לקשר בין היעילות של האפליקציה לבין ההשפעה של סביבת הענן על פליטת הפחמן.

פרוטוקול גזי חממה

פרוטוקול גז החממה (GHG) הוא קבוצה של תקנים שנמצאים בשימוש נרחב למדידה, לניהול ולדיווח ציבורי על פליטות של גזי חממה. הפרוטוקול פותח בשותפות בין World Resources Institute‏ (WRI) לבין World Business Council for Sustainable Development‏ (WBCSD). פרוטוקול GHG מספק את המסגרת החיונית לדיווח על פליטות גזים של חברות. בדוח טביעת הרגל הפחמנית מוצגים נתונים על היקפי פליטות שרלוונטיים לשימוש בענן. מידע נוסף זמין במאמר המתודולוגיה לדיווח על טביעת רגל פחמנית.

הקפדה על פרוטוקול GHG עוזרת להבטיח שהיוזמות שלכם בתחום הקיימוּת יהיו אמינות, ושגורמים חיצוניים יוכלו לבדוק את נתוני פליטות הפחמן שלכם. בנוסף, אתם יכולים למנוע תפיסה של התייפייפות סביבתית ולעמוד בדרישות של בדיקת הנאותות של המשקיעים, הרגולטורים ובעלי העניין החיצוניים. נתונים מאומתים ומבוקרים עוזרים לארגון להוכיח אחריות ולבנות אמון בהתחייבויות פומביות לקיימוּת.