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

Last reviewed 2026-01-28 UTC

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

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

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

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

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

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

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

הוזלת עלויות

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

אבטחה וחוסן

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

חוויית משתמש

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

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

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

אחריות משותפת וגורל משותף

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

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

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

עקרונות ליבה

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

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

Author: Brett Tackaberry | Principal Architect

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

  • סוג תחנות הכוח שמספקות חשמל לרשת במהלך תקופה מסוימת.
  • אנרגיה נקייה שמשויכת ל-Google ומסופקת לרשת במהלך התקופה הזו.

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

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

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

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

כדי לבצע אופטימיזציה של עומסי עבודה של AI ו-ML לצורך קיימות, צריך לאמץ גישה הוליסטית לתכנון, לפריסה ולהפעלה של עומסי העבודה. בחירת מודלים מתאימים וחומרה ייעודית כמו Tensor Processing Units ‏ (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, מעיבוד נתונים ועד להצגת מודלים.

פועלים לפי השיטות המומלצות לשימוש בשיטת 4M לבחירת משאבים

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

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

מידע נוסף על השיטות המומלצות של 4M ומדדי היעילות זמין במאמרי המחקר הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מדידה ומעקב

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

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

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

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

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

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

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

שימוש ב-MLOps

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

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

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

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

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

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

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

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

המלצות

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

הטמעה של שינוי גודל אוטומטי ודינמי

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

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

שימוש בהרחבה אופקית

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

הגדרת מדיניות מתאימה להרחבת נפח האחסון

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

שילוב של התאמות ריאקטיביות ופרואקטיביות

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

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

Google Cloud שירותים ותכונות מנוהלים כמו GKE Autopilot,‏ Cloud Run ו-MIG מנהלים באופן אוטומטי את שינוי הגודל הפרואקטיבי על סמך דפוסי עומס העבודה. כברירת מחדל, אם שירות Cloud Run לא מקבל תנועה, הוא מתרחב לאפס מופעים.

עיצוב אפליקציות ללא מצב

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

שימוש בתזמון ובקבוצות

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

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

תזמון לשיעור פליטת פחמן נמוך

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

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

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

איחוד משימות והרצה מקבילה שלהן

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

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

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

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

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

משפחת מכונות מומלץ לסוגים של עומסי עבודה הנחיות בנושא קיימוּת
מכונות לשימוש כללי (E2, ‏ N2, ‏ N4, ‏ Tau T2A/T2D): המכונות האלה מספקות יחס מאוזן בין מעבד לזיכרון. שרתי אינטרנט, מיקרו-שירותים, מסדי נתונים קטנים עד בינוניים וסביבות פיתוח. סדרת E2 היא חסכונית מאוד בעלויות ובאנרגיה, כי המשאבים מוקצים באופן דינמי. סדרת Tau T2A משתמשת במעבדים מבוססי-Arm, שלרוב יעילים יותר מבחינת צריכת אנרגיה לכל יחידת ביצועים בעומסי עבודה גדולים.
מכונות מותאמות לצריכת מעבד גבוהה (C2, ‏ C3): המכונות האלה מספקות יחס גבוה בין מעבד וירטואלי לזיכרון וביצועים גבוהים לכל ליבה. מחשוב עתיר ביצועים (HPC), עיבוד באצווה, שרתים למשחקים, וניתוח נתונים מבוסס-CPU. מכונת C-series מאפשרת להשלים משימות שדורשות הרבה משאבי CPU מהר יותר, וכך מקצרת את זמן החישוב הכולל ומפחיתה את צריכת האנרגיה של העבודה.
מכונות מותאמות לצריכת זיכרון גבוהה (memory-optimized) (M3, ‏ M2): המכונות האלה מיועדות לעומסי עבודה שדורשים כמות גדולה של זיכרון. מסדי נתונים גדולים בזיכרון ומחסני נתונים, כמו SAP HANA או ניתוח נתונים בזיכרון. מכונות וירטואליות מותאמות לצריכת זיכרון גבוהה (memory-optimized) מאפשרות לאחד עומסי עבודה שצורכים הרבה זיכרון בפחות צמתים פיזיים. האיחוד הזה מצמצם את סך האנרגיה שנדרשת בהשוואה לשימוש בכמה מופעים קטנים יותר. זיכרון עם ביצועים גבוהים מקטין את זמן האחזור של הגישה לנתונים, מה שיכול להקטין את הזמן הכולל שהמעבד מבלה במצב פעיל.
מכונות שמותאמות לאחסון (Z3): המכונות האלה מספקות אחסון מקומי בכונני SSD עם תפוקה גבוהה וזמן אחזור נמוך. מחסני נתונים, ניתוח יומנים ומסדי נתונים של SQL,‏ NoSQL ווקטורים. מכונות שמותאמות לאחסון מעבדות קבוצות נתונים גדולות באופן מקומי, וכך עוזרות לחסוך באנרגיה שמשמשת לתעבורת נתונים יוצאת (egress) ברשת בין מיקומים שונים. כשמשתמשים באחסון מקומי למשימות עם IOPS גבוה, נמנעים מהקצאת יתר של כמה מכונות רגילות.
מכונות שעברו אופטימיזציה לשימוש במאיצים (A3,‏ A2,‏ G2): המכונות האלה מיועדות לעומסי עבודה שמוגברים על ידי GPU ו-TPU, כמו AI,‏ ML ו-HPC. אימון והסקת מסקנות של מודלים ללמידת מכונה (ML), וסימולציות מדעיות.

TPU מתוכננים ליעילות אנרגטית אופטימלית. הם מספקים יותר חישובים לכל וואט.

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

שדרוג לסוגי המכונות העדכניים ביותר

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

למעבדי CPU,‏ GPU ו-TPU יש בדרך כלל יתרון משיפורים טכניים בארכיטקטורת השבבים, כמו:

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

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

  • ביצועים טובים יותר לוואט: זהו מדד מרכזי לקיימות. לדוגמה, מכונות ה-VM מסוג C4 מניבות ביצועים טובים יותר ב-40% ביחס למחיר בהשוואה למכונות ה-VM מסוג C3, באותה צריכת אנרגיה. מעבד C4A מספק יעילות אנרגטית גבוהה ב-60% בהשוואה למעבדי x86 דומים. יכולות הביצועים האלה מאפשרות לכם להשלים משימות מהר יותר או להשתמש בפחות מקרים לאותה עומס עבודה.
  • צריכת אנרגיה כוללת נמוכה יותר: מעבדים משופרים מאפשרים להשתמש במשאבי מחשוב למשך זמן קצר יותר עבור משימה נתונה, וכך לצמצם את צריכת האנרגיה הכוללת ואת טביעת הרגל הפחמנית. השלכות של פליטת פחמן גבוהות במיוחד בעומסי עבודה קצרי-חיים ועתירי-חישובים, כמו משימות באצווה ואימון מודלים של ML.
  • ניצול אופטימלי של משאבים: סוגי המכונות העדכניים מתאימים יותר לתוכנות מודרניות, ויש להם תאימות טובה יותר לתכונות מתקדמות של פלטפורמות ענן. סוגי המכונות האלה בדרך כלל מאפשרים ניצול טוב יותר של משאבים, מה שמקטין את הצורך בהקצאת יתר של משאבים ועוזר לוודא שכל וואט של חשמל מנוצל בצורה יעילה.

פריסת אפליקציות בקונטיינרים

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

שימוש ביכולת של Cloud Run לצמצם את הפעולה לאפס

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

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

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

  • Bin packing: ‫GKE Autopilot אורז בצורה חכמה כמה קונטיינרים בצמתים הזמינים. השיטה הזו ממקסמת את הניצול של כל צומת ומצמצמת את מספר הצמתים שלא מנוצלים או שמנוצלים באופן חלקי, וכך עוזרת לצמצם את צריכת האנרגיה.
  • התאמה אופקית של קבוצות Pod לעומס (HPA): באמצעות HPA, מספר הרפליקות של הקונטיינרים (Pods) מותאם באופן אוטומטי על סמך מדדים מוגדרים מראש, כמו שימוש במעבד או מדדים מותאמים אישית שספציפיים לאפליקציה. לדוגמה, אם יש עלייה פתאומית בתנועה לאפליקציה, GKE מוסיף Pods כדי לעמוד בביקוש. כשהעומס בתנועה יורד, GKE מקטין את מספר ה-Pods. השינוי הדינמי של קנה המידה מונע הקצאת יתר של משאבים, כך שלא תצטרכו לשלם על קיבולת מיותרת של מחשוב או להפעיל אותה.
  • התאמה אנכית של קבוצות Pod לעומס (VPA): אפשר להגדיר את GKE כך שישנה באופן אוטומטי את הקצאות ה-CPU והזיכרון ואת המגבלות של קונטיינרים בודדים. ההגדרה הזו מבטיחה שלא יוקצו לקונטיינר יותר משאבים ממה שהוא צריך, וכך עוזרת למנוע הקצאת יתר של משאבים.
  • ‫GKE multidimensional Pod autoscaling: עבור עומסי עבודה מורכבים, אפשר להגדיר HPA ו-VPA בו-זמנית כדי לבצע אופטימיזציה של מספר ה-Pods ושל הגודל של כל Pod. הטכניקה הזו עוזרת להבטיח את טביעת הרגל האנרגטית הקטנה ביותר האפשרית לביצועים הנדרשים.
  • ‫Topology-Aware Scheduling (TAS): ‏TAS משפר את יעילות הרשת עבור עומסי עבודה של AI ו-ML ב-GKE על ידי מיקום של Pod על סמך המבנה הפיזי של תשתית מרכז הנתונים. ‫TAS ממקם עומסי עבודה באופן אסטרטגי כדי לצמצם את מספר הקפיצות ברשת. המיקום המשותף הזה עוזר להפחית את זמן האחזור של התקשורת ואת צריכת האנרגיה. באמצעות אופטימיזציה של ההתאמה הפיזית בין הצמתים ובין החומרה הייעודית, TAS מזרזת את השלמת המשימות וממקסמת את היעילות האנרגטית של עומסי עבודה גדולים של AI ו-ML.

הגדרת תזמון שמביא בחשבון את פליטת הפחמן

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

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

כדי להטמיע תזמון שמודע לפליטת פחמן, מומלץ להשתמש בטכניקות הבאות:

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

תכנון תוכנית התאוששות מאסון (DR) חסכונית באנרגיה

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

אופטימיזציה של יעילות ההפעלה במצב התחלתי (cold start)

כדי לצמצם את מספר המשאבים הפעילים באזור המשני (DR) או לבטל אותם, אפשר להשתמש בגישות הבאות:

  • עדיפות לDR במצב לא פעיל: משאירים את המשאבים באזור ה-DR כבויים או במצב של שינוי גודל לאפס. הגישה הזו עוזרת לצמצם את טביעת הרגל הפחמנית של משאבי מחשוב לא פעילים.
  • ניצול יתרונות של מעבר לגיבוי במקרה של כשל (failover) ללא שרתים: שימוש בשירותים מנוהלים ללא שרתים כמו Cloud Run לנקודות קצה של DR. שירות Cloud Run מתרחב לאפס כשלא משתמשים בו, כך שאפשר לשמור על טופולוגיית DR שלא צורכת אנרגיה עד שהתנועה מופנית לאזור ה-DR.
  • אוטומציה של השחזור באמצעות תשתית כקוד (IaC): במקום להשאיר את המשאבים באתר DR במצב פעיל (warm), אפשר להשתמש בכלי IaC כמו Terraform כדי להקצות סביבות במהירות רק כשצריך.

איזון בין יתירות לניצול

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

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

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

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

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

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

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

המלצות

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

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

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

כתיבת קוד יעיל וממוקד

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

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

שימוש במטמון של השרת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניהול יעיל של הזיכרון והקלט/פלט בדיסק

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

  • ניהול זיכרון קפדני: מומלץ לנקוט פעולות כדי לשחרר באופן יזום משאבי זיכרון שלא נמצאים בשימוש. כדאי להימנע מהחזקת אובייקטים גדולים בזיכרון למשך תקופות ארוכות מהנדרש. הגישה הזו מונעת צווארי בקבוק בביצועים ומצמצמת את צריכת החשמל לגישה לזיכרון.
  • אופטימיזציה של קלט/פלט בדיסק: צמצום התדירות של אינטראקציות הקריאה והכתיבה של האפליקציה עם משאבי אחסון קבוע. לדוגמה, אפשר להשתמש במאגר זיכרון ביניים כדי לאחסן נתונים. לכתוב את הנתונים לאחסון מתמיד במרווחים קבועים או כשהמאגר מגיע לגודל מסוים.
  • פעולות אצווה: איחוד של פעולות דיסק קטנות ותכופות לכמה פעולות אצווה גדולות יותר. פעולת אצווה צורכת פחות אנרגיה מאשר הרבה עסקאות קטנות ונפרדות.
  • שימוש בדחיסה: כדי להקטין את נפח הנתונים שנכתבים לדיסקים או נקראים מהם, אפשר להשתמש בטכניקות מתאימות לדחיסת נתונים. לדוגמה, כדי לדחוס נתונים שמאוחסנים ב-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 App ‏ (PWA). האתרים והאפליקציות האלה נטענים מהר יותר ודורשים פחות משאבי שרת.
  • נגישות וביצועים: אתרים רספונסיביים שנטענים במהירות הם לרוב יותר בני קיימא ונגישים. עיצוב אופטימלי ונקי מאלמנטים מיותרים מצמצם את המשאבים שנצרכים בזמן רינדור התוכן. אתרים שעברו אופטימיזציה לביצועים ולמהירות יכולים לעזור להגדיל את ההכנסות. על פי מחקר של Deloitte ו-Google,‏ Milliseconds Make Millions, שיפור של 0.1 שניות (100 אלפיות השנייה) במהירות האתר מוביל לעלייה של 8.4% בהמרות באתרים קמעונאיים ולעלייה של 9.2% בערך ההזמנה הממוצע.

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

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

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

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

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

המלצות

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

מתן עדיפות לנתונים בעלי ערך גבוה

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

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

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

הסרת נתוני צל ונתונים לא גלויים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

צמצום השכפול

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

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

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

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

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

מדידה ושיפור מתמשכים של הקיימות

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

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

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

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

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

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

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

המלצות

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

שלב 1: קביעת נתון בסיסי

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

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

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

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

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

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

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

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

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

שלב 4: הטמעת שיטות עבודה ודיווח בנושא קיימות

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

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

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

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

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

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

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

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

המלצות

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

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

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

התחברות לתמונה הגדולה

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

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

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

הצגת יעדים פיננסיים ויעדי קיימות

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

אימוץ גישה של גורל משותף

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

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

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

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

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

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

עוזרים למנהלים לתמוך בקיימות

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

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

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

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

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

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

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

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

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

הכרה בצמצום פליטת הפחמן וחגיגתו

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

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

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

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

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

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

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

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

Green Software Foundation

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

‫Greenhouse Gas Protocol

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

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