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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מדידה ומעקב

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

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

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

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

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

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

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

אימוץ MLOps

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

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

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

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

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

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

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

תזמון לפליטת פחמן נמוכה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Bin packing: ‫GKE Autopilot אורז בצורה חכמה כמה קונטיינרים בצמתים הזמינים. השיטה הזו ממקסמת את הניצול של כל צומת ומצמצמת את מספר הצמתים שלא מנוצלים או שמנוצלים באופן חלקי, וכך עוזרת לצמצם את צריכת האנרגיה.
  • ‫Horizontal Pod Autoscaling (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 מאיצה את השלמת המשימות וממקסמת את היעילות האנרגטית של עומסי עבודה (workloads) של AI ולמידת מכונה (ML) בקנה מידה גדול.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

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

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

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

שימוש במטמון של ה-Backend

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

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

שלב 2: זיהוי אזורים עם פליטות פחמן גבוהות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

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

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

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

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

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

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

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

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

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

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

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