Well-Architected Framework: Sustainability pillar

Last reviewed 2026-01-28 UTC

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

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

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

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

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

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

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

הוזלת עלויות

ההוצאות התפעוליות ב-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 TELUS ו-Google משתפות פעולה למען קיימות.

עקרונות ליבה

ההמלצות בנושא קיימות ב-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 אפשר גם להשתמש בCloud Location Finder כדי למצוא מיקומים בענן ב- 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.

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

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

העיקרון הזה, שנכלל בעמודה 'קיימות' בGoogle Cloud Well-Architected Framework, מספק המלצות לאופטימיזציה של עומסי עבודה של 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. הארכיטקטורה הייחודית של TPUs הופכת אותם ליעילים מאוד לביצוע פעולות של כפל מטריצות בקנה מידה גדול, שמהוות את הבסיס ללמידה עמוקה. מעבדי TPU יכולים לבצע משימות מורכבות בהיקף גדול וביעילות רבה יותר ממעבדים למטרות כלליות, כמו מעבדי CPU או GPU.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מדידה ומעקב

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

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

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

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

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

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

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

שימוש ב-MLOps

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

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

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

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

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

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

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

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

המלצות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש ב-VM במודל Spot לעומסי עבודה לא קריטיים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

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

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

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

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

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

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

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

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

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

הטמעה של צינורות לאימות נתונים אוטומטי ולניקוי נתונים באמצעות שירותים כמו Dataproc,‏ Dataflow או Dataplex Universal Catalog בנקודת הטמעת הנתונים. נתונים באיכות נמוכה גורמים לבזבוז של נפח האחסון. בנוסף, זה מוביל לצריכת אנרגיה מיותרת כשהנתונים משמשים בהמשך לניתוח או לאימון של AI.

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

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

הערכה ביקורתית של הצורך בגיבויים

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

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

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

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

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

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

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

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

תיוג משאבים בהרשאה

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

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

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

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

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

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

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

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

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

צמצום השכפול

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

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

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

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

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

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

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

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

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

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

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

  • הטמעה של GreenOps governance: הקמת צוות או קבוצת עבודה רשמיים של 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 ייעודיים. הדגשתי איך מודל עם פחות פרמטרים יכול להפיק את רמת הדיוק הנדרשת עם צריכת אנרגיה נמוכה משמעותית.
מפתחים יעילות הקוד וצריכת המשאבים: להסביר איך קוד עם זמן אחזור גבוה או לולאות לא יעילות מתורגמים ישירות לזמן ריצה ממושך של המעבד ולצריכת אנרגיה מוגברת. חשוב להדגיש את החשיבות של קונטיינרים קלי משקל ואת הצורך באופטימיזציה של ביצועי האפליקציה כדי לצמצם את טביעת הרגל הסביבתית של התוכנה.
אדריכלים קיימות בכל השלבים: התמקדות בבחירת אזור ובמיקום עומס העבודה. הסבר איך בחירה באזור סמל של עלה עם פליטות נמוכות של 2CO עם אחוז גבוה של אנרגיה מתחדשת (כמו northamerica-northeast1) משנה באופן מהותי את פרופיל הפחמן של כל חבילת האפליקציות שלכם לפני שכותבים שורת קוד אחת.
מהנדסי פלטפורמה ומהנדסי תפעול ניצול מיטבי: חשוב להדגיש את העלות הסביבתית של משאבים לא פעילים והקצאת יתר של משאבים. להציג תרחישים של התאמה אוטומטית לעומס ובחירת הגודל המתאים כדי להבטיח שימוש יעיל במשאבי הענן. תסביר איך ליצור ולעקוב אחרי מדדים שקשורים לקיימות, כמו ניצול, ואיך לתרגם מדדים כמו זמן מחשוב למדדים מקבילים של פליטות פחמן.
FinOps כלכלת יחידות של פחמן: התמקדות בקשר בין ההוצאות הפיננסיות לבין ההשפעה על הסביבה. להסביר איך שיטות GreenOps מאפשרות לארגון לעקוב אחרי פליטת הפחמן לכל עסקה, וכך להפוך את הקיימות למדד ביצועים מרכזי (KPI) שחשוב לא פחות ממדדי ביצועים מרכזיים רגילים כמו עלות וניצול.
מנהלי מוצר קיימות כתכונה: הדגמה של שילוב מטרות לצמצום פליטות פחמן במפות דרכים של מוצרים. הסבר איך מסלולי משתמש פשוטים יכולים לעזור להקטין את צריכת האנרגיה של משאבי הענן ושל מכשירי משתמשי הקצה.
מנהיגים עסקיים התאמה אסטרטגית ודיווח: התמקדות בהשפעה של קיימות בענן על דירוגים סביבתיים, חברתיים וממשלתיים (ESG) ועל המוניטין הציבורי. הסבר איך בחירות שקשורות לקיימות עוזרות להפחית את הסיכון הרגולטורי ולעמוד בהתחייבויות לקהילה ולתעשייה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Green Software Foundation

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

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

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

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