עמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework מספק המלצות לתכנון, ליצירה ולניהול של עומסי עבודה ב- Google Cloudשמתחשבים בטביעת הרגל הפחמנית וחסכוניים באנרגיה.
קהל היעד של המסמך הזה כולל מקבלי החלטות, אדריכלים, אדמינים, מפתחים ומפעילים שמתכננים, בונים, פורסים ומתחזקים עומסי עבודה ב- Google Cloud.
להחלטות שקשורות לארכיטקטורה ולתפעול יש השפעה משמעותית על צריכת האנרגיה, על ההשפעה על המים ועל טביעת הרגל הפחמנית שנובעת מעומסי העבודה בענן. כל עומס עבודה, בין אם מדובר באתר קטן או במודל ML בקנה מידה גדול, צורך אנרגיה ותורם לפליטות פחמן ולעוצמת השימוש במשאבי מים. כשמשלבים קיימות בארכיטקטורת הענן ובתהליך התכנון, יוצרים מערכות יעילות, חסכוניות וידידותיות לסביבה. ארכיטקטורה בת קיימא היא גמישה ומותאמת, ויוצרת לולאת משוב חיובית של יעילות גבוהה יותר, עלות נמוכה יותר והשפעה סביבתית נמוכה יותר.
קיימוּת מובנית: תוצאות עסקיות הוליסטיות
קיימות היא לא פשרה על חשבון יעדים עסקיים מרכזיים אחרים, אלא שיטות עבודה שמתמקדות בקיימות עוזרות להאיץ את היעדים העסקיים האחרים. בחירות בארכיטקטורה שמתעדפות משאבים ופעולות דלי-פחמן עוזרות לכם לבנות מערכות שהן גם מהירות, זולות ומאובטחות יותר. מערכות כאלה נחשבות בנות קיימא לפי עיצוב, כלומר אופטימיזציה של הקיימות מובילה לתוצאות חיוביות כוללות מבחינת ביצועים, עלות, אבטחה, עמידות וחוויית משתמש.
אופטימיזציה של הביצועים
מערכות שעברו אופטימיזציה לביצועים משתמשות באופן טבעי בפחות משאבים. אפליקציה יעילה שמבצעת משימה מהר יותר דורשת משאבי מחשוב למשך זמן קצר יותר. לכן, הציוד הבסיסי צורך פחות קילוואט-שעה (kWh) של אנרגיה. ביצועים אופטימליים גם מקצרים את זמן האחזור ומשפרים את חוויית המשתמש. המשאבים לא מבזבזים זמן ואנרגיה בהמתנה לתהליכים לא יעילים. כשמשתמשים בחומרה ייעודית (לדוגמה, GPU ו-TPU), מאמצים אלגוריתמים יעילים וממקסמים את העיבוד המקביל, משפרים את הביצועים ומצמצמים את טביעת הרגל הפחמנית של עומס העבודה בענן.
הוזלת עלויות
ההוצאות התפעוליות בענן תלויות בשימוש במשאבים. בגלל הקשר הישיר הזה, כשאתם מבצעים אופטימיזציה של העלויות באופן קבוע, אתם גם מפחיתים את צריכת האנרגיה ואת פליטות הפחמן. כשמבצעים התאמה של מכונות וירטואליות, מטמיעים שינוי גודל אוטומטי אגרסיבי, מארכבים נתונים ישנים ומבטלים משאבים לא פעילים, מצמצמים את השימוש במשאבים ואת העלויות של הענן. בנוסף, אתם מצמצמים את טביעת הרגל הפחמנית של המערכות שלכם, כי מרכזי הנתונים צורכים פחות אנרגיה כדי להריץ את עומסי העבודה.
אבטחה ועמידות
אבטחה ואמינות הן תנאים מוקדמים לסביבת ענן בת קיימא. מערכת שנפגעה – למשל, מערכת שהושפעה מהתקפת מניעת שירות (DoS) או מפרצה באבטחת מידע – יכולה להגדיל באופן דרמטי את צריכת המשאבים. אירועים כאלה יכולים לגרום לעליות חדות בנפח התנועה, ליצור מחזורי מחשוב בלתי מבוקרים לצורך צמצום הנזק, ולחייב פעולות ארוכות ומורכבות של ניתוח פורנזי, ניקוי ושחזור נתונים. אמצעי אבטחה חזקים יכולים לעזור למנוע עליות חדות מיותרות בשימוש במשאבים, כדי שהפעולות שלכם יישארו יציבות, צפויות וחסכוניות באנרגיה.
חוויית משתמש
מערכות שמתמקדות ביעילות, בביצועים, בנגישות ובשימוש מינימלי בנתונים יכולות לעזור למשתמשי הקצה לצמצם את השימוש באנרגיה. אפליקציה שטוענת מודל קטן יותר או מעבדת פחות נתונים כדי לספק תוצאות מהר יותר, עוזרת לצמצם את צריכת האנרגיה של מכשירי הרשת ומכשירי משתמשי הקצה. החיסכון הזה באנרגיה מועיל במיוחד למשתמשים עם רוחב פס מוגבל או למשתמשים במכשירים ישנים יותר. בנוסף, ארכיטקטורה בת-קיימא עוזרת לצמצם את הנזק לכדור הארץ וממחישה את המחויבות שלכם לטכנולוגיה עם אחריות חברתית.
הערך של מעבר לענן מבחינת קיימוּת
העברת עומסי עבודה מקומיים לענן יכולה לעזור לצמצם את טביעת הרגל הסביבתית של הארגון. המעבר לתשתית ענן יכול להפחית את צריכת האנרגיה ואת הפליטות שקשורות אליה פי 1.4 עד 2 בהשוואה לפריסות מקומיות טיפוסיות. מרכזי נתונים בענן הם מתקנים מודרניים שתוכננו בהתאמה אישית, והם בנויים ליעילות גבוהה של צריכת אנרגיה (PUE). למרכזי נתונים ישנים מקומיים לרוב אין את קנה המידה שנדרש כדי להצדיק השקעות במערכות מתקדמות של קירור וחלוקת חשמל.
אחריות משותפת וגורל משותף
במאמר אחריות משותפת וגורל משותף ב- Google Cloud מתואר איך האבטחה של עומסי העבודה בענן היא אחריות משותפת של Google ושלכם, הלקוחות. מודל האחריות המשותפת הזה רלוונטי גם לקיימות.
Google אחראית לקיימות של Google Cloud, כלומר ליעילות האנרגטית ולייעול השימוש במים במרכזי הנתונים, בתשתית ובשירותי הליבה שלנו. אנחנו משקיעים באופן קבוע באנרגיה מתחדשת, בקירור בעל מודעות סביבתית ובאופטימיזציה של החומרה. בדוח הסביבתי של Google בנושא קיימוּת לשנת 2025 אפשר לקרוא מידע נוסף על האסטרטגיה וההתקדמות של Google בנושא קיימוּת.
אתם, הלקוחות, אחראים לקיימוּת בענן, כלומר לבצע אופטימיזציה של עומסי העבודה כדי להיות יעילים אנרגטית. לדוגמה, אפשר להתאים את גודל המשאבים, להשתמש בשירותים ללא שרת (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 בנושא קיימוּת.
הערכת עומסי עבודה באמצעות סקיל אג'נטי
כדי לאפשר לסוכני AI להעריך את עומסי העבודה בענן בהתאם לעקרונות ולהמלצות שבעמוד התווך הזה, אתם יכולים להשתמש במיומנות google-cloud-waf-sustainability שזמינה במאגר Google Agent Skills ב-GitHub.
כדי להתקין את היכולת, מריצים את הפקודה הבאה בלקוח או במסוף של הסוכן:
npx skills add google/skills --skill google-cloud-waf-sustainability
כשמוצגת בקשה, מציינים את סוכני ה-AI שרוצים להתקין בשבילם את המיומנות ומגדירים את היקף ההתקנה (פרויקט או גלובלי).
עקרונות הליבה
ההמלצות בנושא קיימות ב-Well-Architected Framework ממופות לעקרונות הליבה הבאים:
- שימוש באזורים שצורכים אנרגיה דלת-פחמן
- אופטימיזציה של עומסי עבודה של AI ו-ML ליעילות אנרגטית
- אופטימיזציה של השימוש במשאבים למטרות קיימוּת
- פיתוח תוכנה חסכונית באנרגיה
- אופטימיזציה של נתונים ואחסון למטרות קיימוּת
- מדידה ושיפור מתמידים של הקיימות
- קידום תרבות של קיימוּת
- התאמת שיטות העבודה בתחום הקיימוּת להנחיות הרווחות בתחום
שותפים ביצירת התוכן
מחבר: Brett Tackaberry | אדריכל ראשי
תורמי תוכן אחרים:
- Adrien Feudjio | | Product Manager, Carbon Footprint
- Alex Stepney | Lead Principal Architect
- Daniel Lees | Cloud Security Architect
- דניס פרל | מנהלת שיווק גלובלי, קיימוּת
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Laura Hyatt | Customer Engineer, FSI
- ניקולס פינטו | מהנדס לקוחות, מומחה למודרניזציה של אפליקציות
- Radhika Kanakam | Program Lead, Google Cloud Well-Architected Framework
שימוש באזורים שצורכים אנרגיה דלת פחמן
העיקרון הזה, שנכלל בעמודה 'קיימות' ב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 מציין את אחוז האנרגיה נטולת הפחמן מתוך סך האנרגיה שנצרכת במהלך שעה. מדד 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 גבוה יותר, תוכלו להפחית באופן משמעותי את פליטות הפחמן שקשורות למשימות האלה בלי להשפיע על הביצועים או על העלות. הגישה הזו נקראת הסטת זמן, ובה משתמשים באופי הדינמי של שיעור פליטת הפחמן של רשת החשמל כדי לבצע אופטימיזציה של עומסי העבודה למטרות קיימוּת.
אופטימיזציה של עומסי עבודה של AI ו-ML ליעילות אנרגטית
העיקרון הזה, שמופיע בעמוד התווך של קיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות לאופטימיזציה של עומסי עבודה של AI ו-ML כדי לצמצם את צריכת האנרגיה ואת טביעת הרגל הפחמנית שלהם.
סקירה כללית של העקרונות
כדי לבצע אופטימיזציה של עומסי עבודה של AI ו-ML למטרות קיימוּת, צריך לאמץ גישה הוליסטית לתכנון, לפריסה ולהפעלה של עומסי העבודה. לבחור מודלים מתאימים וחומרה ייעודית כמו יחידות Tensor Processing Unit (TPU), להריץ את עומסי העבודה באזורים דלי-פחמן, לבצע אופטימיזציה כדי לצמצם את השימוש במשאבים וליישם שיטות עבודה מומלצות.
שיטות ארכיטקטוניות ותפעוליות שמייעלות את העלות והביצועים של עומסי עבודה של AI ו-ML, מובילות באופן טבעי לצריכת אנרגיה נמוכה יותר ולטביעת רגל פחמנית קטנה יותר. נקודת המבט של AI ו-ML ב-Well-Architected Framework מתארת עקרונות והמלצות לתכנון, ליצירה ולניהול של עומסי עבודה של AI ו-ML שעומדים ביעדים שלכם בתחום התפעול, האבטחה, האמינות, העלות והביצועים. בנוסף, מרכז הארכיטקטורה של Cloud מספק ארכיטקטורות מפורטות ומדריכי עיצוב לעומסי עבודה של AI ו-ML ב- Google Cloud.
המלצות
כדי לבצע אופטימיזציה של עומסי עבודה של AI ו-ML ליעילות אנרגטית, כדאי להביא בחשבון את ההמלצות שבקטעים הבאים.
תכנון ארכיטקטורה יעיל אנרגטית באמצעות TPU
עומסי עבודה של AI ו-ML יכולים לדרוש הרבה משאבי מחשוב. צריכת האנרגיה של עומסי עבודה של AI ו-ML היא נקודה מרכזית בקיימוּת. יחידות TPU מאפשרות לשפר משמעותית את יעילות האנרגיה והקיימוּת של עומסי העבודה של AI ו-ML.
יחידות TPU הן מאיצים מותאמים אישית שנועדו במיוחד לעומסי עבודה של AI ו-ML. הארכיטקטורה המיוחדת של יחידות ה-TPU הופכת אותן ליעילות מאוד לכפל מטריצות בקנה מידה גדול, שהוא הבסיס ללמידה עמוקה. יחידות TPU יכולות לבצע משימות מורכבות בקנה מידה גדול וביעילות רבה יותר מאשר מעבדים לשימוש כללי, כמו מעבדי CPU או GPU.
יחידות TPU מספקות את היתרונות הישירים הבאים בתחום הקיימות:
- צריכת אנרגיה נמוכה יותר: יחידות TPU מתוכננות ליעילות אנרגטית אופטימלית. הם מספקים יותר חישובים לכל ואט של אנרגיה שנצרכת. הארכיטקטורה המיוחדת שלהם מפחיתה באופן משמעותי את דרישות ההספק של משימות אימון והסקת מסקנות בקנה מידה גדול, מה שמוביל להפחתת העלויות התפעוליות ולצריכת אנרגיה נמוכה יותר.
- אימון והסקה מהירים יותר: הביצועים יוצאי הדופן של יחידות TPU מאפשרים לאמן מודלים מורכבים של AI תוך שעות במקום ימים. ההפחתה המשמעותית הזו בזמן החישוב הכולל תורמת באופן ישיר לצמצום טביעת הרגל הסביבתית.
- פחות צורך בקירור: יחידות ה-TPU כוללות קירור נוזלי מתקדם, שמספק ניהול תרמי יעיל ומפחית באופן משמעותי את האנרגיה שמשמשת לקירור מרכז הנתונים.
- אופטימיזציה של מחזור החיים של ה-AI: יחידות ה-TPU משלבות חומרה ותוכנה כדי לספק פתרון אופטימלי לכל אורך מחזור החיים של ה-AI, מעיבוד הנתונים ועד לפרסום המודל.
שימוש בשיטות המומלצות של 4Ms לבחירת משאבים
Google ממליצה על כמה שיטות מומלצות לצמצום משמעותי של צריכת האנרגיה ופליטות הפחמן בעומסי עבודה של AI ו-ML. השיטות המומלצות האלה נקראות 4M:
- מודל: בחירת ארכיטקטורות יעילות של מודלים ל-ML. לדוגמה, מודלים דלילים משפרים את איכות ה-ML ומפחיתים את החישוב פי 3 עד 10 בהשוואה למודלים צפופים.
- מכונה: בוחרים מעבדים ומערכות שמותאמים לאימון ML. המעבדים האלה משפרים את הביצועים ואת היעילות האנרגטית פי 2 עד פי 5 בהשוואה למעבדים לשימוש כללי.
- מיכון: פריסת עומסי עבודה אינטנסיביים בענן. עומסי העבודה שלכם צורכים פחות אנרגיה וגורמים לפליטות נמוכות יותר, פי 1.4 עד 2 בהשוואה לפריסות מקומיות. מרכזי נתונים בענן משתמשים במחסנים חדשים יותר שתוכננו במיוחד כדי להיות יעילים באנרגיה, ויש להם יחס גבוה של יעילות צריכת החשמל (PUE). מרכזי נתונים מקומיים הם לרוב ישנים וקטנים יותר, ולכן השקעה במערכות חלוקת חשמל וקירור חסכוניות באנרגיה עשויה להיות לא כלכלית.
- מפה: בוחרים Google Cloud מיקומים שמשתמשים באנרגיה הנקייה ביותר. הגישה הזו עוזרת לצמצם את טביעת הרגל הפחמנית ברוטו של עומסי העבודה שלכם פי 5 עד 10. מידע נוסף זמין במאמר אנרגיה נטולת פחמן באזורי Google Cloud .
למידע נוסף על השיטות המומלצות של 4Ms ומדדי היעילות, קראו את המאמרים הבאים:
- טביעת הרגל הפחמנית של אימון למידת מכונה תגיע לנקודת שיווי משקל ואז תצטמצם
- The data center as a computer: An introduction to the design of warehouse-scale machines, second edition
אופטימיזציה של מודלי AI ואלגוריתמים לאימון ולהיקש
לארכיטקטורה של מודל AI ולאלגוריתמים שמשמשים לאימון ולהסקת מסקנות יש השפעה משמעותית על צריכת האנרגיה. כדאי לשקול את ההמלצות הבאות.
בחירת מודלים יעילים של AI
בחרו מודלים קטנים ויעילים יותר של AI שעומדים בדרישות הביצועים שלכם. אל תבחרו במודל הכי גדול שזמין כברירת מחדל. לדוגמה, גרסה קטנה יותר של מודל שעברה זיקוק, כמו DistilBERT, יכולה לספק ביצועים דומים עם תקורה חישובית נמוכה משמעותית והסקת מסקנות מהירה יותר ממודל גדול יותר כמו BERT.
שימוש בפתרונות יעילים במיוחד שמותאמים לדומיין
מומלץ לבחור פתרונות ML ייעודיים שמספקים ביצועים טובים יותר ודורשים כוח מחשוב נמוך משמעותית בהשוואה למודל בסיסי גדול. הפתרונות המיוחדים האלה לרוב מאומנים מראש ומותאמים במיוחד. הם יכולים להפחית באופן משמעותי את צריכת האנרגיה ואת מאמצי המחקר בעומסי עבודה של אימון והסקת מסקנות. הנה כמה דוגמאות לפתרונות ייעודיים לתחומים ספציפיים:
- Earth AI הוא פתרון יעיל אנרגטית שמנתח כמויות גדולות של נתונים גיאו-מרחביים גלובליים כדי לספק תובנות פרקטיות, מדויקות ובזמן אמת.
- WeatherNext יוצר תחזיות מזג אוויר גלובליות מהירות ויעילות יותר, וגם מדויקות יותר, בהשוואה לשיטות קונבנציונליות שמבוססות על פיזיקה.
להשתמש בטכניקות מתאימות לדחיסת מודלים
הנה כמה דוגמאות לטכניקות שבהן אפשר להשתמש כדי לדחוס מודלים:
- גיזום: הסרה של פרמטרים מיותרים מרשת עצבית. אלה פרמטרים שלא תורמים באופן משמעותי לביצועי המודל. השיטה הזו מקטינה את המודל ואת משאבי המחשוב שנדרשים להסקת מסקנות.
- קוונטיזציה: הקטנת הדיוק של פרמטרים של מודל. לדוגמה, אפשר להפחית את הדיוק מנקודה צפה של 32 ביט למספרים שלמים של 8 ביט. הטכניקה הזו יכולה לעזור להקטין באופן משמעותי את הזיכרון שבשימוש ואת צריכת החשמל בלי לפגוע באופן משמעותי ברמת הדיוק.
- זיקוק ידע: אימון מודל תלמיד קטן יותר כדי לחקות את ההתנהגות של מודל מורה גדול ומורכב יותר. המודל של התלמיד יכול להשיג רמת ביצועים גבוהה עם פחות פרמטרים ועם שימוש בפחות אנרגיה.
שימוש בחומרה ייעודית
כמו שמוסבר בקטע שיטות מומלצות לבחירת משאבים לפי 4Ms, כדאי לבחור מעבדים ומערכות שעברו אופטימיזציה לאימון למידת מכונה. המעבדים האלה משפרים את הביצועים והם יעילים אנרגטית פי 2 עד פי 5 בהשוואה למעבדים לשימוש כללי.
שימוש בכוונון יעיל בפרמטרים
במקום לשנות את כל מיליארדי הפרמטרים של המודל (כוונון עדין מלא), השתמשו בשיטות של כוונון יעיל בפרמטרים (PEFT) כמו Low-Rank Adaptation (LoRA). בשיטה הזו, מקפיאים את המשקלים של המודל המקורי ומאמנים רק מספר קטן של שכבות חדשות וקלות. הגישה הזו עוזרת להפחית את העלויות ואת צריכת האנרגיה.
שיטות מומלצות לפעולות של AI ו-ML
שיטות העבודה התפעוליות משפיעות באופן משמעותי על הקיימוּת של עומסי העבודה של AI ו-ML. כדאי להביא בחשבון את ההמלצות הבאות.
אופטימיזציה של תהליכי אימון מודלים
כדי לבצע אופטימיזציה של תהליכי אימון המודלים, אפשר להשתמש בשיטות הבאות:
- עצירה מוקדמת: עוקבים אחרי תהליך האימון ועוצרים אותו כשלא רואים שיפור נוסף בביצועי המודל ביחס לקבוצת נתונים לתיקוף. השיטה הזו עוזרת למנוע חישובים מיותרים ושימוש מיותר באנרגיה.
- טעינת נתונים יעילה: כדאי להשתמש בפייפליינים של נתונים יעילים כדי לוודא שיחידות ה-GPU וה-TPU תמיד בשימוש ולא מחכות לנתונים. השיטה הזו עוזרת למקסם את ניצול המשאבים ולצמצם את בזבוז האנרגיה.
- כוונון היפר-פרמטרים אופטימלי: כדי למצוא היפר-פרמטרים אופטימליים בצורה יעילה יותר, אפשר להשתמש בשיטות כמו אופטימיזציה בייסיאנית או למידת חיזוק. הימנעו מחיפושי Grid מקיפים, שיכולים להיות פעולות שדורשות הרבה משאבים.
שיפור יעילות ההסקה
כדי לשפר את היעילות של משימות הסקת מסקנות באמצעות AI, אפשר להשתמש בשיטות הבאות:
- עיבוד באצווה: קיבוץ של כמה בקשות להסקת מסקנות באצוות וניצול של עיבוד מקבילי במעבדי GPU ו-TPU. הטכניקה הזו עוזרת להפחית את עלות האנרגיה לכל חיזוי.
- שמירה מתקדמת במטמון: הטמעה של אסטרטגיית שמירה במטמון בכמה שכבות, שכוללת שמירה במטמון של מפתח/ערך (KV) ליצירה אוטורגרסיבית ושמירה במטמון של הנחיות סמנטיות לתשובות של האפליקציה. השיטה הזו עוזרת לעקוף חישובי מודלים מיותרים, ויכולה להפחית באופן משמעותי את צריכת האנרגיה ואת פליטות הפחמן.
מדידה ומעקב
עוקבים אחרי הפרמטרים הבאים ומודדים אותם:
- שימוש ועלות: השתמשו בכלים המתאימים כדי לעקוב אחרי השימוש בטוקנים, צריכת האנרגיה וטביעת הרגל הפחמנית של עומסי העבודה של ה-AI. הנתונים האלה עוזרים לכם לזהות הזדמנויות לאופטימיזציה ולדווח על ההתקדמות שלכם לעבר יעדי הקיימות.
- ביצועים: עוקבים אחרי ביצועי המודל בסביבת הייצור.
לזהות בעיות כמו שינויים בנתונים, שיכולים להצביע על כך שצריך לכוונן מחדש את המודל. אם צריך לאמן מחדש את המודל, אפשר להשתמש במודל המקורי שעבר כוונון עדין כנקודת התחלה, וכך לחסוך הרבה זמן, כסף ואנרגיה על עדכונים.
- כדי לעקוב אחרי מדדי ביצועים, משתמשים ב-Cloud Monitoring.
- כדי לקשר בין שינויים במודל לבין שיפורים במדדי הביצועים, אפשר להשתמש בהערות לאירועים.
למידע נוסף על תפעול של שיפור מתמשך, קראו את המאמר מדידה ושיפור מתמשכים של קיימוּת.
הטמעה של תזמון שמודע לפליטת פחמן
תכננו את המשימות בצינור עיבוד הנתונים של למידת המכונה כך שיפעלו באזורים עם תמהיל האנרגיה הנקי ביותר. אתם יכולים להשתמש בדוח "טביעת רגל פחמנית" כדי לזהות את האזורים שבהם פליטת הפחמן היא הנמוכה ביותר. תזמנו משימות שדורשות משאבים רבים כמשימות באצווה בתקופות שבהן רשת החשמל המקומית כוללת אחוז גבוה יותר של אנרגיה נטולת פחמן (CFE).
אופטימיזציה של צינורות עיבוד נתונים
כדי לבצע פעולות של ML וכוונון, צריך קבוצת נתונים נקייה ואיכותית. לפני שמתחילים משימות של למידת מכונה, כדאי להשתמש בשירותים מנוהלים לעיבוד נתונים כדי להכין את הנתונים בצורה יעילה. לדוגמה, אפשר להשתמש ב-Dataflow לעיבוד בסטרימינג וברצף (batch), וב-Managed Service for Apache Spark לצינורות עיבוד נתונים מנוהלים של Spark ו-Hadoop. פייפליין נתונים שעבר אופטימיזציה עוזר לוודא שעומס העבודה של הכוונון העדין לא יחכה לנתונים, וכך תוכלו למקסם את ניצול המשאבים ולצמצם את בזבוז האנרגיה.
אימוץ MLOps
כדי להפוך את כל מחזור החיים של למידת המכונה לאוטומטי ולנהל אותו, אתם יכולים להטמיע שיטות של תפעול למידת מכונה (MLOps). השיטות האלה עוזרות לוודא שהמודלים מנוטרים, מאומתים ונפרסים מחדש באופן יעיל ורציף, וכך למנוע אימון או הקצאת משאבים מיותרים.
שימוש בשירותים מנוהלים
במקום לנהל את התשתית שלכם, אתם יכולים להשתמש בשירותי ענן מנוהלים כמו Gemini Enterprise Agent Platform. פלטפורמת הענן מטפלת בניהול המשאבים הבסיסיים, כך שאתם יכולים להתמקד בתהליך הכוונון. להשתמש בשירותים שכוללים כלים מובנים לכוונון היפר-פרמטרים, למעקב אחרי מודלים ולניהול משאבים.
המאמרים הבאים
- כמה אנרגיה ה-AI של Google צורך? עשינו את החישוב
- Ironwood: ה-TPU הראשון של Google לעידן הסקת המסקנות
- דוח הסביבה של Google בנושא קיימוּת לשנת 2025
- למידה יעילה יותר בהקשר עם GLaM
- סקירה כללית על שמירת הקשר במטמון
אופטימיזציה של השימוש במשאבים למען קיימוּת
העיקרון הזה, שמופיע בעמוד התווך של קיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לשפר את השימוש במשאבים של עומסי העבודה ב- Google Cloud.
סקירה כללית של העקרונות
כדי לשפר את הקיימוּת של סביבת הענן, חשוב לבצע אופטימיזציה של השימוש במשאבים. כל משאב שמקצים – החל ממשאבי מחשוב ועד למאגר נתונים – משפיע ישירות על צריכת האנרגיה, על עוצמת השימוש במים ועל פליטת הפחמן. כדי לצמצם את טביעת הרגל הסביבתית של עומסי העבודה, אתם צריכים לקבל החלטות מושכלות כשאתם מקצים משאבים בענן, מנהלים אותם ומשתמשים בהם.
המלצות
כדי לבצע אופטימיזציה של השימוש במשאבים, כדאי להשתמש בהמלצות שבקטעים הבאים.
הטמעה של התאמה אוטומטית ודינמית של נפח האחסון
התאמה אוטומטית ודינמית לעומס מבטיחה שימוש אופטימלי במשאבים, וכך מונעת בזבוז אנרגיה מתשתיות לא פעילות או מהקצאת יתר של משאבים. הפחתה של בזבוז אנרגיה מובילה לעלויות נמוכות יותר ולפליטות פחמן נמוכות יותר.
כדי להטמיע יכולת התאמה אוטומטית ודינמית לעומס, אפשר להשתמש בשיטות הבאות.
שימוש בהתאמה אופקית לעומס (horizontal scaling)
התאמה אופקית היא שיטת ההתאמה המועדפת לרוב האפליקציות עם עדיפות לענן. במקום להגדיל את הגודל של כל מכונה, פעולה שנקראת שינוי קנה מידה אנכי, מוסיפים מכונות כדי לפזר את העומס. לדוגמה, אתם יכולים להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG) כדי להרחיב אופקית באופן אוטומטי קבוצה של מכונות וירטואליות ב-Compute Engine. תשתית עם התאמה אופקית היא גמישה יותר, כי כשל במכונה לא משפיע על הזמינות של האפליקציה. התאמה אופקית לעומס היא גם טכניקה יעילה לשימוש במשאבים באפליקציות עם רמות עומס משתנות.
הגדרת מדיניות מתאימה לשינוי גודל
מגדירים את ההגדרות של התאמה אוטומטית לעומס (autoscaling) בהתאם לדרישות של עומסי העבודה. הגדרת מדדים מותאמים אישית וערכי סף שספציפיים להתנהגות האפליקציה. במקום להסתמך רק על ניצול המעבד (CPU), כדאי להשתמש במדדים כמו עומק התור למשימות אסינכרוניות, זמן האחזור של הבקשות ומדדי אפליקציות בהתאמה אישית. כדי למנוע שינוי קנה מידה תכוף ומיותר או תנודות, הגדירו כללי מדיניות ברורים לשינוי קנה מידה. לדוגמה, לעומסי עבודה שאתם פורסים ב-Google Kubernetes Engine (GKE), הגדירו מדיניות מתאימה להתאמה אוטומטית לעומס (automatic scaling) של אשכולות.
שילוב של התרחבות ריאקטיבית ופרואקטיבית
בשינוי גודל תגובתי, המערכת משנה את הגודל שלה בתגובה לשינויים בעומס בזמן אמת. השיטה הזו מתאימה לאפליקציות שיש בהן עליות חדות ובלתי צפויות בעומס.
התאמת משאבים יזומה מתאימה לעומסי עבודה עם דפוסים צפויים, כמו שעות פעילות קבועות ודיווח שבועי. בעומסי עבודה כאלה, כדאי להשתמש בהתאמה אוטומטית לעומס לפי לוח זמנים כדי להקצות מראש משאבים שיכולים להתמודד עם רמת עומס צפויה. השיטה הזו מונעת תחרות על משאבים ומבטיחה חוויית משתמש חלקה ויעילה יותר. השיטה הזו גם עוזרת לתכנן באופן יזום עליות חדות ידועות בעומס, כמו אירועי מכירות גדולים ומאמצי שיווק ממוקדים.
תכונות ושירותים מנוהלים שלGoogle Cloud , כמו GKE Autopilot, Cloud Run ו-MIG, מנהלים באופן אוטומטי את ההתאמה הפרואקטיבית לעומס על סמך למידה מדפוסי עומסי העבודה שלכם. כברירת מחדל, כששירות Cloud Run לא מקבל תנועה, הוא מתרחב לאפס מופעים.
תכנון אפליקציות ללא שמירת מצב (stateless)
כדי שאפליקציה תתאים להרחבה אופקית, הרכיבים שלה צריכים להיות ללא שמירת מצב (stateless). כלומר, הסשן או הנתונים של משתמש ספציפי לא קשורים למכונה ספציפית של Compute. כשמאחסנים את מצב הסשן מחוץ למופע המחשוב, למשל ב-Memorystore for Redis, כל מופע מחשוב יכול לטפל בבקשות מכל משתמש. הגישה הזו מאפשרת התאמה אופקית חלקה ויעילה לעומס.
שימוש בתזמון ובקבוצות
עיבוד באצווה מתאים במיוחד לעומסי עבודה גדולים ולא דחופים. משימות באצווה יכולות לעזור לכם לבצע אופטימיזציה של עומסי העבודה (workloads) כדי לחסוך באנרגיה ובעלויות.
כדי להטמיע תזמון ומשימות באצווה, אפשר להשתמש בטכניקות הבאות.
תזמון לפי שיעור פליטת פחמן נמוך
תזמנו את משימות ה-batch כך שיפעלו באזורים דלי-פחמן ובפרקי זמן שבהם רשת החשמל המקומית מכילה אחוז גבוה של אנרגיה נקייה. כדי לזהות את השעות ביום שבהן פליטת הפחמן היא הנמוכה ביותר באזור מסוים, אפשר להשתמש בדוח טביעת הרגל הפחמנית.
שימוש ב-VM במודל Spot לעומסי עבודה לא קריטיים
VM במודל Spot מאפשרות לכם ליהנות מהנחה משמעותית על קיבולת לא מנוצלת של Compute Engine. אפשר להפסיק לפני הזמן (preempt) את ה-VM במודל Spot, אבל הן מספקות דרך חסכונית לעבד קבוצות נתונים גדולות בלי צורך במשאבים ייעודיים בזמינות תמידית. VM במודל Spot מתאימות במיוחד למשימות באצווה שהן לא קריטיות ועמידות בכשלים.
איחוד משימות והרצה שלהן במקביל
כדי לצמצם את התקורה של הפעלה וכיבוי של משימות נפרדות, קבצו משימות דומות לאצווה גדולה אחת. כדאי להריץ את עומסי העבודה הגדולים האלה בשירותים כמו Batch. השירות מקצה ומנהל אוטומטית את התשתית הנדרשת, וכך עוזר להבטיח ניצול אופטימלי של המשאבים.
שימוש בשירותים מנוהלים
שירותים מנוהלים כמו Batch ו-Dataflow מטפלים באופן אוטומטי בהקצאת משאבים, בתזמון ובמעקב. פלטפורמת הענן מטפלת באופטימיזציה של המשאבים. אתם יכולים להתמקד בלוגיקה של האפליקציה. לדוגמה, Dataflow מבצע התאמה אוטומטית לעומס של מספר ה-workers בהתאם לנפח הנתונים בפייפליין, כך שלא תשלמו על משאבים בהמתנה לפעילות.
התאמה של משפחות המכונות הווירטואליות לדרישות של עומסי העבודה
סוגי המכונות שבהם אפשר להשתמש במכונות וירטואליות ב-Compute Engine מקובצים במשפחות של מכונות, שעברו אופטימיזציה לעומסי עבודה שונים. בחרו את משפחות המכונות שמתאימות לדרישות של עומסי העבודה שלכם.
| משפחת מכונות | מומלץ לסוגים של עומסי עבודה | הנחיות בנושא קיימוּת |
|---|---|---|
| אינסטנסים לשימוש כללי (E2, N2, N4, Tau T2A/T2D): האינסטנסים האלה מספקים יחס מאוזן בין מעבד לזיכרון. | שרתי אינטרנט, מיקרו-שירותים, מסדי נתונים קטנים עד בינוניים וסביבות פיתוח. | סדרת E2 היא חסכונית מאוד בעלויות ובאנרגיה, בזכות הקצאה דינמית של משאבים. בסדרת Tau T2A נעשה שימוש במעבדים מבוססי-Arm, שלרוב יעילים יותר מבחינת צריכת אנרגיה לכל יחידת ביצועים בעומסי עבודה גדולים. |
| מכונות מותאמות לצריכת מעבד גבוהה (C2, C3): המכונות האלה מספקות יחס גבוה בין מעבד וירטואלי לזיכרון וביצועים גבוהים לכל ליבה. | מחשוב עתיר ביצועים (HPC), עיבוד באצווה, שרתי גיימינג וניתוח נתונים מבוסס-CPU. | מכונה מסדרה C מאפשרת להשלים מהר יותר משימות שדורשות שימוש אינטנסיבי ב-CPU, וכך לצמצם את זמן המחשוב הכולל ואת צריכת האנרגיה של המשימה. |
| Memory-optimized instances (M3, M2): המכונות האלה מיועדות לעומסי עבודה שדורשים כמות גדולה של זיכרון. | מסדי נתונים גדולים בזיכרון ומחסני נתונים, כמו SAP HANA או ניתוח נתונים בזיכרון. | מכונות שמותאמות לצריכת זיכרון גבוהה מאפשרות לאחד עומסי עבודה שצורכים הרבה זיכרון בפחות צמתים פיזיים. האיחוד הזה מפחית את כמות האנרגיה הכוללת שנדרשת בהשוואה לשימוש בכמה מכונות קטנות יותר. זיכרון עם ביצועים גבוהים מפחית את זמן האחזור של הגישה לנתונים, וכך יכול להפחית את משך הזמן הכולל שבו המעבד (CPU) נמצא במצב פעיל. |
| מכונות שמותאמות לאחסון (Z3): המכונות האלה מספקות אחסון SSD מקומי עם תפוקה גבוהה וזמן אחזור קצר. | מחסני נתונים, ניתוח יומנים ומסדי נתונים של SQL, NoSQL ווקטורים. | מכונות שמותאמות לאחסון מעבדות מערכי נתונים גדולים באופן מקומי, מה שעוזר לצמצם את האנרגיה שמשמשת ליציאת נתונים מהרשת במיקומים שונים. כשמשתמשים באחסון מקומי למשימות עם IOPS גבוה, נמנעים מהקצאת יתר של כמה מכונות רגילות. |
| מכונות שעברו אופטימיזציה לשימוש במאיצים (A3, A2, G2): המכונות האלה מיועדות לעומסי עבודה שמוגברים על ידי GPU ו-TPU, כמו AI, ML ו-HPC. | אימון מודלים של למידת מכונה (ML) והסקת מסקנות, וסימולציות מדעיות. | יחידות TPU מתוכננות לניצול אנרגיה אופטימלי. הם מספקים יותר חישובים לוואט. מופע עם האצת GPU, כמו סדרת A3 עם מעבדי GPU של NVIDIA H100, יכול להיות חסכוני יותר באנרגיה באופן משמעותי לאימון מודלים גדולים בהשוואה לחלופה שמבוססת על CPU בלבד. למרות שלמכונה עם האצת GPU יש צריכת חשמל נומינלית גבוהה יותר, המשימה מסתיימת הרבה יותר מהר. |
שדרוג לסוגי המכונות העדכניים ביותר
שימוש בסוגי המכונות העדכניים ביותר יכול לעזור לשפר את הקיימוּת. כשמעדכנים את סוגי המכונות, בדרך כלל הם מתוכננים להיות חסכוניים יותר באנרגיה ולספק ביצועים גבוהים יותר לכל ואט. יכול להיות שמכונות וירטואליות שמשתמשות בסוגי המכונות העדכניים ביותר יבצעו את אותה כמות עבודה עם צריכת חשמל נמוכה יותר.
מעבדים (CPU), מעבדים גרפיים (GPU) ויחידות TPU נהנים לעיתים קרובות מהתקדמות טכנית בארכיטקטורת השבבים, כמו:
- ליבות ייעודיות: פיתוחים במעבדים כוללים לעיתים קרובות ליבות ייעודיות או הוראות לעומסי עבודה נפוצים. לדוגמה, למעבדים יכולות להיות ליבות ייעודיות לפעולות וקטוריות או למאיצי AI משולבים. כשמעבירים את המשימות האלה מהמעבד המרכזי, הן מבוצעות בצורה יעילה יותר וצורכות פחות אנרגיה.
- ניהול משופר של צריכת החשמל: פיתוחים בארכיטקטורות של שבבים כוללים לעיתים קרובות תכונות מתוחכמות יותר לניהול צריכת החשמל, כמו התאמה דינמית של המתח והתדירות על סמך עומס העבודה. התכונות האלה לניהול צריכת הסוללה מאפשרות לשבבים לפעול ביעילות מקסימלית ולהיכנס למצבי צריכת הסוללה נמוכה כשהם לא פעילים, וכך לצמצם את צריכת האנרגיה.
השיפורים הטכניים בארכיטקטורת השבבים מספקים את היתרונות הישירים הבאים לקיימוּת ולעלות:
- ביצועים גבוהים יותר לוואט: זהו מדד מרכזי לקיימוּת. לדוגמה, במכונות וירטואליות מסוג C4, יחס המחיר-ביצועים גבוה ב-40% בהשוואה למכונות וירטואליות מסוג 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. השיטה הזו עוזרת להבטיח את טביעת הרגל האנרגטית הקטנה ביותר האפשרית לביצועים הנדרשים.
- תזמון מבוסס-טופולוגיה (TAS): TAS משפר את יעילות הרשת של עומסי עבודה של AI ו-ML ב-GKE על ידי מיקום Pods על סמך המבנה הפיזי של תשתית מרכז הנתונים. TAS ממקם עומסי עבודה באופן אסטרטגי כדי לצמצם את מספר הדילוגים ברשת. המיקום המשותף הזה עוזר לצמצם את זמן האחזור של התקשורת ואת צריכת האנרגיה. באמצעות אופטימיזציה של ההתאמה הפיזית של הצמתים והחומרה הייעודית, TAS מאיץ את השלמת המשימות וממקסם את יעילות האנרגיה של עומסי עבודה של AI ו-ML בקנה מידה גדול.
הגדרת תזמון שמביא בחשבון את פליטת הפחמן
ב-Google אנחנו מעבירים כל הזמן את עומסי העבודה שלנו למיקומים ולזמנים שבהם החשמל הכי נקי. אנחנו גם משתמשים מחדש בציוד ישן יותר או ממירים אותו לשימושים חלופיים. אתם יכולים להשתמש באסטרטגיית התזמון הזו, שמתחשבת בפליטת פחמן, כדי לוודא שעומסי העבודה בקונטיינרים משתמשים באנרגיה נקייה.
כדי להטמיע תזמון שמותאם לטביעת הרגל הפחמנית, אתם צריכים מידע בזמן אמת על תמהיל האנרגיה שמפעיל את מרכזי הנתונים באזור. אפשר לקבל את המידע הזה בפורמט שניתן לקריאה על ידי מכונה ממאגר הנתונים של אנרגיה ללא פליטת פחמן Google Cloud באזורים ב-GitHub או ממערך נתונים ציבורי ב-BigQuery. הנתונים השעתיים לגבי תמהיל מקורות האנרגיה ברשת ושיעור פליטת הפחמן, שמשמשים לחישוב קבוצת הנתונים השנתית של Google לגבי פליטת פחמן, מגיעים מחברת Electricity Maps.
כדי להטמיע תזמון שמודע לפליטת פחמן, מומלץ להשתמש בטכניקות הבאות:
- שינוי מיקום גיאוגרפי: תזמון עומסי העבודה כך שיפעלו באזורים שבהם משתמשים בשיעור גבוה יותר של מקורות אנרגיה מתחדשת. כך אתם יכולים להשתמש ברשתות חשמל נקיות יותר.
- העברה זמנית: בעומסי עבודה לא קריטיים וגמישים, כמו עיבוד ברצף (batch processing), כדאי להגדיר את עומסי העבודה כך שיפעלו בשעות שאינן שעות השיא או כשיש שפע של אנרגיה מתחדשת. הגישה הזו נקראת "הסטה זמנית", והיא עוזרת לצמצם את טביעת הרגל הפחמנית הכוללת על ידי ניצול מקורות אנרגיה נקיים יותר כשהם זמינים.
תכנון תוכנית התאוששות מאסון (DR) חסכונית באנרגיה
הכנה להתאוששות מאסון (DR) כוללת בדרך כלל הקצאה מראש של משאבים מיותרים באזור משני. עם זאת, משאבים לא פעילים או משאבים שלא מנוצלים במלואם יכולים לגרום לבזבוז אנרגיה משמעותי. בוחרים אסטרטגיות DR שממקסמות את ניצול המשאבים ומצמצמות את ההשלכות של פליטת פחמן, בלי לפגוע ביעדי זמן ההתאוששות (RTO).
אופטימיזציה של יעילות ההפעלה במצב התחלתי (cold start)
כדי לצמצם את מספר המשאבים הפעילים באזור המשני (DR) או לבטל אותם, אפשר להשתמש בגישות הבאות:
- לתת עדיפות להתאוששות מאסון במצב קר: להשאיר את המשאבים באזור ה-DR כבויים או במצב של צמצום הפעולה לאפס. הגישה הזו עוזרת לצמצם את טביעת הרגל הפחמנית של משאבי מחשוב לא פעילים.
- שימוש ביתירות כשל ללא שרת (serverless): שימוש בשירותים מנוהלים ללא שרת (serverless) כמו Cloud Run לנקודות קצה (endpoints) של התאוששות מאסון. ב-Cloud Run, הפעולה מצטמצמת לאפס כשהוא לא בשימוש, כך שאפשר לשמור על טופולוגיית DR שלא צורכת אנרגיה עד שהתנועה מופנית לאזור ה-DR.
- אוטומציה של השחזור באמצעות תשתית כקוד (IaC): במקום להפעיל את המשאבים באתר DR (במצב המתנה), אפשר להשתמש בכלי IaC כמו Terraform כדי להקצות במהירות סביבות רק כשצריך.
איזון בין יתירות לניצול
יתירות של משאבים היא גורם עיקרי לבזבוז אנרגיה. כדי לצמצם את הכפילות, אפשר להיעזר בשיטות הבאות:
- עדיף להשתמש בגישה פעילה-פעילה במקום בגישה פעילה-פסיבית: בהגדרה פעילה-פסיבית, המשאבים באתר הפסיבי לא פעילים, ולכן יש בזבוז של אנרגיה. ארכיטקטורה פעילה-פעילה בגודל אופטימלי מבטיחה שכל המשאבים שהוקצו בשני האזורים ישרתו באופן פעיל את התנועה. הגישה הזו עוזרת למקסם את יעילות האנרגיה של התשתית.
- יתירות בגודל המתאים: משכפלים נתונים ושירותים בין אזורים רק כשהשכפול נחוץ כדי לעמוד בדרישות של זמינות גבוהה או DR. כל רפליקה נוספת מגדילה את עלות האנרגיה של האחסון המתמיד ותעבורת הנתונים היוצאת (egress).
פיתוח תוכנה חסכונית באנרגיה
העיקרון הזה, שנכלל בעמודה 'קיימות' ב-Google Cloud Well-Architected Framework, מספק המלצות לכתיבת תוכנה שמצמצמת את צריכת האנרגיה ואת העומס על השרת.
סקירה כללית של העקרונות
כשפועלים לפי השיטות המומלצות לפיתוח אפליקציות בענן, מייעלים את האנרגיה שמשמשת את משאבי התשתית בענן: AI, מחשוב, אחסון ורשת. אתם גם עוזרים להפחית את כמות המים שנדרשת למרכזי הנתונים ואת האנרגיה שמכשירים של משתמשי קצה צורכים כשהם ניגשים לאפליקציות שלכם.
כדי ליצור תוכנה חסכונית באנרגיה, צריך לשלב שיקולים של קיימות לאורך מחזור החיים של התוכנה, החל משלבי התכנון והפיתוח ועד לשלבי הפריסה, התחזוקה והארכיון. בספר האלקטרוני Build Software Sustainably של Google Cloud מוסבר בפירוט איך משתמשים ב-AI כדי לפתח תוכנות שמצמצמות את ההשפעה של עומסי העבודה בענן על הסביבה.
המלצות
ההמלצות בקטע הזה מחולקות לקבוצות לפי תחומי ההתמקדות הבאים:
- צמצום עבודת החישוב: העדיפו קוד קצר וממוקד שמבטל לוגיקה מיותרת ומונע חישובים מיותרים או עומס של תכונות.
- שימוש באלגוריתמים ובמבני נתונים יעילים: בחרו אלגוריתמים יעילים מבחינת זמן וזיכרון, שמפחיתים את העומס על המעבד (CPU) ומצמצמים את השימוש בזיכרון.
- אופטימיזציה של פעולות חישוב ונתונים: פיתוח במטרה להשתמש ביעילות בכל המשאבים הזמינים, כולל CPU, זיכרון, קלט/פלט של דיסק ורשת. לדוגמה, כשמחליפים לולאות המתנה פעילה בלוגיקה מבוססת-אירועים, נמנעים מדגימה מיותרת.
- הטמעת אופטימיזציה של חזית האתר: כדי לצמצם את צריכת החשמל במכשירי משתמשי הקצה, כדאי להשתמש באסטרטגיות כמו מזעור, דחיסה וטעינה עצלה של תמונות ונכסים.
צמצום עבודת החישוב
כדי לכתוב תוכנה חסכונית באנרגיה, צריך לצמצם את כמות העבודה החישובית הכוללת שהאפליקציה מבצעת. כל הוראה מיותרת, לולאה עודפת ותכונה נוספת צורכות אנרגיה, זמן ומשאבים. כדי ליצור תוכנה שמבצעת חישובים מינימליים, אפשר להיעזר בהמלצות הבאות.
כתיבת קוד רזה וממוקד
כדי לכתוב קוד מינימלי שנדרש להשגת התוצאות הרצויות, אפשר להשתמש בגישות הבאות:
- הסרת לוגיקה מיותרת ותכונות מיותרות: כותבים קוד שמבצע רק את הפונקציות החיוניות. מומלץ להימנע מתכונות שמגדילות את התקורה החישובית והמורכבות, אבל לא מספקות ערך מדיד למשתמשים.
- Refactor: כדי לשפר את היעילות האנרגטית לאורך זמן, כדאי לבדוק באופן קבוע את האפליקציות כדי לזהות תכונות שלא בשימוש. צריך להסיר או לשנות את התכונות האלה בהתאם.
- הימנעו מפעולות מיותרות: אל תחשבו ערך או תפעילו פעולה עד שהתוצאה נדרשת. השתמשו בשיטות כמו הערכה עצלה, שמעכבות את החישובים עד שרכיב תלוי באפליקציה צריך את הפלט.
- תנו עדיפות לקריאוּת של הקוד וליכולת להשתמש בו שוב: כתבו קוד קריא שאפשר להשתמש בו שוב. הגישה הזו מצמצמת את הכפילות ופועלת לפי העיקרון של 'אל תחזור על עצמך' (DRY), שיכול לעזור להפחית את פליטת הפחמן מפיתוח ותחזוקה של תוכנה.
שימוש בשמירה לקצה העורפי במטמון
שמירה במטמון בקצה העורפי מבטיחה שהאפליקציה לא תבצע את אותה פעולה שוב ושוב. שיעור גבוה של מציאות במטמון מוביל להפחתה כמעט לינארית בצריכת האנרגיה לכל בקשה. כדי להטמיע שמירה במטמון בקצה העורפי, אפשר להשתמש בשיטות הבאות:
- שמירת נתונים שמשתמשים בהם לעיתים קרובות במטמון: אחסון נתונים שמשתמשים בהם לעיתים קרובות במיקום אחסון זמני עם ביצועים גבוהים. לדוגמה, אפשר להשתמש בשירות לשמירה במטמון בזיכרון כמו Memorystore. כשאפליקציה מאחזרת נתונים ממטמון, נפח השאילתות במסד הנתונים ופעולות הקלט/פלט בדיסק מצטמצם. כתוצאה מכך, העומס על מסדי הנתונים והשרתים בקצה העורפי פוחת.
- שמירת תגובות מה-API במטמון: כדי להימנע מקריאות מיותרות ויקרות לרשת, כדאי לשמור במטמון את התוצאות של בקשות API תכופות.
- תעדוף של שמירה במטמון בזיכרון: כדי למנוע פעולות קלט/פלט איטיות בדיסק ושאילתות מורכבות במסד הנתונים, כדאי לאחסן נתונים בזיכרון במהירות גבוהה (RAM).
- בוחרים אסטרטגיות מתאימות לכתיבה במטמון:
- האסטרטגיה של כתיבה דרך המטמון מבטיחה שהנתונים ייכתבו באופן סינכרוני למטמון וגם למאגר הקבוע. האסטרטגיה הזו מגדילה את הסבירות למציאה במטמון (cache hit), כך שהאחסון המתמיד מקבל פחות בקשות קריאה שצורכות הרבה אנרגיה.
- אסטרטגיית הכתיבה לאחור (write-behind) משפרת את הביצועים של אפליקציות שכוללות הרבה פעולות כתיבה. הנתונים נכתבים קודם במטמון, ומסד הנתונים מתעדכן באופן אסינכרוני מאוחר יותר. האסטרטגיה הזו מפחיתה את עומס הכתיבה המיידי במסדי נתונים איטיים יותר.
- שימוש במדיניות חכמה של פינוי נתונים מהמטמון: כדי לשמור על מטמון רזה ויעיל. כדי להסיר נתונים ישנים או נתונים שלא משתמשים בהם הרבה, וכדי לפנות מקום לנתונים שמשתמשים בהם לעיתים קרובות, כדאי להשתמש במדיניות כמו זמן חיים (TTL), הכי פחות בשימוש לאחרונה (LRU) והכי פחות בשימוש (LFU).
שימוש באלגוריתמים ובמבני נתונים יעילים
האלגוריתמים ומבני הנתונים שאתם בוחרים קובעים את מורכבות החישוב הגולמית של התוכנה. כשבוחרים אלגוריתמים ומבני נתונים מתאימים, מצמצמים את מספר מחזורי המעבד ואת פעולות הזיכרון שנדרשות להשלמת משימה. פחות מחזורי CPU ופעולות זיכרון מובילים לצריכת אנרגיה נמוכה יותר.
בחירת אלגוריתמים לסיבוכיות זמן אופטימלית
לתת עדיפות לאלגוריתמים שמשיגים את התוצאה הנדרשת בזמן הקצר ביותר. הגישה הזו עוזרת לצמצם את משך השימוש במשאבים. כדי לבחור אלגוריתמים שמשפרים את השימוש במשאבים, אפשר להשתמש בשיטות הבאות:
- התמקדו בהפחתת המורכבות: כדי להעריך את המורכבות, אל תסתכלו רק על מדדי זמן הריצה, אלא גם על המורכבות התיאורטית של האלגוריתם. לדוגמה, בהשוואה למיון בועות, מיון מיזוג מפחית באופן משמעותי את עומס החישוב ואת צריכת האנרגיה עבור מערכי נתונים גדולים.
- כדי להימנע מעבודה מיותרת: כדאי להשתמש בפונקציות מובנות ומותאמות בשפת התכנות או במסגרת שבחרתם. הפונקציות האלה מיושמות בדרך כלל בשפה ברמה נמוכה יותר וחסכונית יותר באנרגיה, כמו C או ++C, כך שהן מותאמות טוב יותר לחומרה הבסיסית בהשוואה לפונקציות עם קוד בהתאמה אישית.
בחירת מבני נתונים ליעילות
מבני הנתונים שבוחרים קובעים את המהירות שבה אפשר לאחזר, להוסיף או לעבד נתונים. המהירות הזו משפיעה על השימוש במעבד (CPU) ועל השימוש בזיכרון. כדי לבחור מבני נתונים יעילים, השתמשו בגישות הבאות:
- אופטימיזציה של חיפוש ואחזור: לפעולות נפוצות כמו בדיקה אם פריט קיים או אחזור של ערך ספציפי, כדאי להשתמש במבני נתונים שעברו אופטימיזציה למהירות. לדוגמה, מיפויי גיבוב או קבוצות גיבוב מאפשרים חיפושים בזמן כמעט קבוע, וזו גישה חסכונית יותר באנרגיה מאשר חיפוש ליניארי במערך.
- מצמצמים את הזיכרון שבשימוש: מבני נתונים יעילים עוזרים לצמצם את הזיכרון שבשימוש הכולל של אפליקציה. הפחתת הגישה לזיכרון והניהול שלו מובילה לצריכת חשמל נמוכה יותר. בנוסף, פרופיל זיכרון קטן יותר מאפשר לתהליכים לפעול בצורה יעילה יותר, וכך לדחות את שדרוגי המשאבים.
- שימוש במבנים ייעודיים: משתמשים במבני נתונים שנועדו לפתור בעיה מסוימת. לדוגמה, אפשר להשתמש במבנה נתונים מסוג עץ חיפוש לחיפוש מהיר של תחילת מחרוזת, ולהשתמש בתור עדיפויות כשצריך לגשת רק לערך הגבוה או הנמוך ביותר בצורה יעילה.
אופטימיזציה של פעולות המחשוב והנתונים
כשמפתחים תוכנה, חשוב להתמקד בשימוש יעיל ופרופורציונלי במשאבים בכל סטאק התוכנות. התייחסו למעבד (CPU), לזיכרון, לדיסק ולרשת כמשאבים מוגבלים ומשותפים. להבין ששימוש יעיל במשאבים מוביל להפחתה משמעותית בעלויות ובצריכת האנרגיה.
אופטימיזציה של ניצול המעבד וזמן חוסר הפעילות
כדי לצמצם את הזמן שבו המעבד (CPU) נמצא במצב פעיל וצורך אנרגיה בלי לבצע עבודה משמעותית, אפשר להשתמש בשיטות הבאות:
- עדיף להשתמש בלוגיקה מבוססת-אירועים במקום בסקרים: כדאי להחליף לולאות פעילות עתירות משאבים או בדיקות קבועות (סקרים) בלוגיקה מבוססת-אירועים. ארכיטקטורה מבוססת-אירועים מבטיחה שרכיבי האפליקציה יפעלו רק כשהם מופעלים על ידי אירועים רלוונטיים. הגישה הזו מאפשרת עיבוד על פי דרישה, וכך אין צורך בסקרים שצורכים הרבה משאבים.
- מניעת תדירות גבוהה קבועה: כותבים קוד שלא מאלץ את המעבד לפעול כל הזמן בתדירות הגבוהה ביותר. כדי לצמצם את צריכת האנרגיה, מערכות שלא נמצאות בשימוש צריכות להיות מסוגלות להיכנס למצבי צריכת חשמל נמוכה או למצבי שינה.
- שימוש בעיבוד אסינכרוני: כדי למנוע נעילה של שרשורים בזמני המתנה, כדאי להשתמש בעיבוד אסינכרוני. הגישה הזו מפנה משאבים ומובילה לניצול גבוה יותר של המשאבים באופן כללי.
ניהול יעיל של הזיכרון ושל הקלט/פלט (I/O) של הדיסק
שימוש לא יעיל בזיכרון ובדיסק מוביל לעיבוד מיותר ולצריכת חשמל מוגברת. כדי לנהל את הזיכרון ואת הקלט/פלט ביעילות, השתמשו בשיטות הבאות:
- ניהול זיכרון מחמיר: ביצוע פעולות לשחרור יזום של משאבי זיכרון שלא בשימוש. הימנעו משמירת אובייקטים גדולים בזיכרון לפרקי זמן ארוכים מהנדרש. הגישה הזו מונעת צווארי בקבוק בביצועים ומפחיתה את צריכת החשמל שנדרשת לגישה לזיכרון.
- אופטימיזציה של קלט/פלט בדיסק: מפחיתים את התדירות של אינטראקציות הקריאה והכתיבה של האפליקציה עם משאבי אחסון מתמידים. לדוגמה, אפשר להשתמש במאגר נתונים זמני (buffer) כדי לאחסן נתונים. לכתוב את הנתונים לאחסון מתמיד במרווחים קבועים או כשהמאגר מגיע לגודל מסוים.
- פעולות באצווה: איחוד של פעולות קטנות בדיסק שמתבצעות לעיתים קרובות לכמה פעולות גדולות באצווה. פעולה באצווה צורכת פחות אנרגיה מאשר הרבה עסקאות קטנות ונפרדות.
- שימוש בדחיסה: כדי לצמצם את כמות הנתונים שנכתבים לדיסקים או נקראים מהם, אפשר להשתמש בטכניקות מתאימות לדחיסת נתונים. לדוגמה, כדי לדחוס נתונים שמאוחסנים ב-Cloud Storage, אתם יכולים להשתמש בהמרת קידוד שמבטלת דחיסה.
מצמצמים את התנועה ברשת
משאבי רשת צורכים כמות משמעותית של אנרגיה במהלך פעולות העברת נתונים. כדי לשפר את התקשורת ברשת, אפשר להשתמש בשיטות הבאות:
- צמצום גודל המטען הייעודי (payload): תכננו את ממשקי ה-API והאפליקציות כך שיעבירו רק את הנתונים שנדרשים לבקשה. הימנעו מאחזור או החזרה של מבני JSON או XML גדולים במקרים שבהם נדרשים רק כמה שדות. מוודאים שמבני הנתונים שמוחזרים הם תמציתיים.
- צמצום מספר ההלוך ושוב ברשת: כדי לצמצם את מספר ההלוך ושוב ברשת שנדרשים להשלמת פעולת משתמש, כדאי להשתמש בפרוטוקולים חכמים יותר. לדוגמה, עדיף להשתמש ב-HTTP/3 על פני HTTP/1.1, לבחור ב-GraphQL על פני REST, להשתמש בפרוטוקולים בינאריים ולאחד קריאות ל-API. כשמפחיתים את נפח הקריאות לרשת, מפחיתים את צריכת האנרגיה גם בשרתים וגם במכשירי משתמשי הקצה.
הטמעת אופטימיזציה של ממשק המשתמש
אופטימיזציה של ממשק המשתמש מצמצמת את כמות הנתונים שמשתמשי הקצה צריכים להוריד ולעבד, וכך מפחיתה את העומס על המשאבים במכשירים של משתמשי הקצה.
מזעור הקוד והנכסים
כשמשתמשי הקצה צריכים להוריד ולעבד משאבים קטנים יותר ומובנים בצורה יעילה יותר, המכשירים שלהם צורכים פחות חשמל. כדי לצמצם את נפח ההורדה ואת עומס העיבוד במכשירי משתמשי הקצה, אפשר להשתמש בטכניקות הבאות:
- הקטנה ודחיסה: בקובצי JavaScript, CSS ו-HTML, הסירו תווים מיותרים כמו רווחים לבנים והערות באמצעות כלים מתאימים להקטנה. חשוב לוודא שקבצים כמו תמונות דחוסים ועברו אופטימיזציה. אתם יכולים להפוך את המזעור והדחיסה של נכסי אינטרנט לאוטומטיים באמצעות צינור עיבוד נתונים של CI/CD.
- טעינה מדורגת: טוענים תמונות, סרטונים ונכסים לא קריטיים רק כשהם נחוצים בפועל, למשל כשהרכיבים האלה נגללים לאזור התצוגה של דף אינטרנט. הגישה הזו מצמצמת את נפח העברת הנתונים הראשונית ואת עומס העיבוד במכשירי משתמשי הקצה.
- חבילות JavaScript קטנות יותר: כדי להסיר קוד שלא נמצא בשימוש מחבילות JavaScript, אפשר להשתמש בכלי מודרני ליצירת חבילות של מודולים ובטכניקות כמו tree shaking. הגישה הזו יוצרת קבצים קטנים יותר שנטענים מהר יותר וצורכים פחות משאבי שרת.
- שמירה במטמון הדפדפן: משתמשים בכותרות HTTP של שמירה במטמון כדי להנחות את הדפדפן של המשתמש לאחסן נכסים סטטיים באופן מקומי. שמירה במטמון הדפדפן עוזרת למנוע הורדות חוזרות ותנועה מיותרת ברשת בביקורים הבאים.
תעדוף חוויית משתמש (UX) קלה
לעיצוב של ממשק המשתמש יכולה להיות השפעה משמעותית על מורכבות החישובים של עיבוד תוכן חזיתי. כדי ליצור ממשקי קצה (frontend) שמספקים חוויית משתמש קלה, אפשר להשתמש בטכניקות הבאות:
- עיבוד יעיל: הימנעו משינויים תכופים ב-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 והדיסקים הקבועים. יוצרים תגים שמציינים את בעלי הנתונים, את מטרת הנתונים ואת תקופת השמירה. כדי לוודא שהתגים הנדרשים, כמו תקופת שמירה, חלים על המשאבים, אפשר להשתמש באילוצים של שירות מדיניות הארגון. התגים מאפשרים לכם להפוך את ניהול מחזור החיים לאוטומטי, ליצור דוחות FinOps מפורטים ולהפיק דוחות על פליטות פחמן.
בחירת הגודל המתאים לביטול ההקצאה של אחסון לחישוב
מומלץ לבדוק באופן קבוע דיסקים לאחסון מתמיד שמצורפים למכונות של Compute Engine, ולוודא שלא הוקצו להם יותר מדי משאבים. השתמשו בתמונות מצב רק כשהן נחוצות לגיבוי. מחיקת תמונות מצב ישנות שלא בשימוש. במסדי נתונים, כדאי להשתמש במדיניות שמירת נתונים כדי לצמצם את הגודל של הדיסקים לאחסון מתמיד.
אופטימיזציה של פורמט האחסון
לאחסון שמשמש לעומסי עבודה של ניתוח נתונים, עדיף להשתמש בפורמטים דחוסים של עמודות כמו Parquet או Avro שעבר אופטימיזציה, על פני פורמטים שמבוססים על שורות כמו JSON או CSV. אחסון עמודתי מפחית באופן משמעותי את הדרישות הפיזיות של מקום בכונן ומשפר את יעילות הקריאה. האופטימיזציה הזו עוזרת לצמצם את צריכת האנרגיה של פעולות החישוב והקלט/פלט המשויכות.
אופטימיזציה של האזוריות ותנועת הנתונים
המיקום הפיזי והתנועה של הנתונים משפיעים על צריכת משאבי הרשת ועל האנרגיה שנדרשת לאחסון. כדי לבצע אופטימיזציה של אזוריות הנתונים, אפשר להשתמש בשיטות הבאות.
בחירת אזורי אחסון דלי-פחמן
בהתאם לדרישות התאימות שלכם, כדאי לאחסן נתונים Google Cloud באזורים שבהם נעשה שימוש באחוז גבוה יותר של אנרגיה נטולת פחמן (CFE) או שבהם שיעור פליטת הפחמן ברשת נמוך יותר. להגביל את היצירה של קטגוריות אחסון באזורים עם פליטת פחמן גבוהה, באמצעות האילוץ מיקומי משאבים במדיניות הארגון. במאמר אנרגיה נטולת פחמן באזורי Google Cloud מוסבר על נתוני CFE ושיעור פליטת הפחמן באזורי Google Cloud .
מצמצמים את הרפליקציה
שכפלו נתונים בין אזורים רק כדי לעמוד בדרישות החובה של תוכנית התאוששות מאסון (DR) או זמינות גבוהה (HA). פעולות שכפול בין אזורים ובמספר אזורים מגדילות באופן משמעותי את עלות האנרגיה ואת טביעת הרגל הפחמנית של הנתונים.
אופטימיזציה של מיקומי עיבוד הנתונים
כדי להפחית את צריכת האנרגיה בהעברת נתונים ברשת, כדאי לפרוס עומסי עבודה שדורשים משאבי מחשוב רבים, כמו אימון AI ועיבוד ב-BigQuery, באותו אזור שבו נמצא מקור הנתונים.
אופטימיזציה של העברת נתונים עבור השותפים והלקוחות שלכם
כדי להעביר כמויות גדולות של נתונים בין שירותי ענן, מיקומים וספקים, עודדו את השותפים והלקוחות שלכם להשתמש ב-Storage Transfer Service או בממשקי API לשיתוף נתונים. הימנעו מהעלאת כמויות גדולות של נתונים. במערכי נתונים ציבוריים, השתמשו בקטגוריות של המבקש משלם כדי להעביר את עלויות העיבוד וההעברה של הנתונים ואת ההשפעה על הסביבה למשתמשי הקצה.
למדוד ולשפר את הקיימוּת באופן קבוע
העיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם למדוד ולשפר באופן קבוע את הקיימוּת של עומסי העבודה ב- Google Cloud.
סקירה כללית של העקרונות
כדי לוודא שעומסי העבודה בענן יישארו קיימים, אתם צריכים מדדים מדויקים ושקופים. מדדים שניתנים לאימות מאפשרים לכם לתרגם את יעדי הקיימות לפעולות. לכל משאב שאתם יוצרים בענן יש טביעת רגל פחמנית משויכת. כדי לבנות ולתחזק ארכיטקטורות ענן ברות-קיימא, צריך לשלב את מדידת נתוני הפחמן בלולאת המשוב התפעולית.
ההמלצות בקטע הזה מספקות מסגרת לשימוש בטביעת הרגל הפחמנית כדי לכמת את פליטות הפחמן, לזהות מוקדים של פליטות פחמן, להטמיע אופטימיזציות ממוקדות של עומסי עבודה ולאמת את התוצאות של מאמצי האופטימיזציה. המסגרת הזו מאפשרת לכם להתאים ביעילות את יעדי האופטימיזציה של העלויות ליעדים של הפחתת פליטת פחמן שאפשר לאמת.
המתודולוגיה לדיווח על טביעת הרגל הפחמנית
הכלי "טביעת רגל פחמנית" מספק דוח שקוף, שניתן לבדיקה ותואם לתקנים גלובליים, על פליטות הגזים שקשורות לענן. הדוח עומד בתקנים בינלאומיים, בעיקר בפרוטוקול גז החממה (GHG) לדיווח ולחישוב של פליטות פחמן. בדוח טביעת הרגל הפחמנית נעשה שימוש בשיטות חשבונאות מבוססות-מיקום ומבוססות-שוק. הנהלת חשבונות מבוססת-מיקום מבוססת על פקטור הפליטות של הרשת המקומית. בחישוב מבוסס-שוק נלקחות בחשבון רכישות האנרגיה נטולת פחמן (CFE) של Google. הגישה הכפולה הזו עוזרת לכם להבין את ההשפעה של עומסי העבודה שלכם על הרשת הפיזית וגם את היתרון של הפחתת פליטת הפחמן ב- Google Cloud.
במאמר מתודולוגיה של דיווח על טביעת רגל פחמנית אפשר לקרוא מידע נוסף על אופן הכנת הדוח בנושא טביעת רגל פחמנית, כולל מקורות הנתונים שבהם נעשה שימוש, הכללות של היקף 3 ומודל ההקצאה ללקוחות.
המלצות
כדי להשתמש במדידת פחמן לשיפור מתמשך, כדאי לעיין בהמלצות שבסעיפים הבאים. ההמלצות מחולקות לשלבים של בשלות בהטמעה של פעולות בענן שתוכננו מראש להיות ידידותיות לסביבה:
- שלב 1: קביעת נקודת ייחוס
- שלב 2: זיהוי נקודות חמות
- שלב 3: הטמעת אופטימיזציה ממוקדת
- שלב 4: הפיכת שיטות העבודה והדיווח בנושא קיימוּת לחלק מהתרבות הארגונית
שלב 1: קביעת נקודת השוואה
בשלב הזה מגדירים את הכלים הנדרשים ומוודאים שהנתונים נגישים ומשולבים בצורה נכונה.
- הענקת הרשאות: מעניקים הרשאות לצוותים כמו FinOps, SecOps ופלטפורמת הנדסה כדי שיוכלו לגשת ללוח הבקרה טביעת רגל פחמנית במסוף Google Cloud . מקצים את התפקיד "צפייה בטביעת הרגל הפחמנית" (
roles/billing.carbonViewer) בממשק לניהול זהויות והרשאות גישה (IAM) לחשבון החיוב המתאים. - ייצוא אוטומטי של נתונים: לפני שאתם מייצאים נתונים, ודאו שGoogle Cloud היררכיית המשאבים (תיקיות ופרויקטים) וההערות על המשאבים (תגים ותוויות) משקפות בצורה מדויקת את הארגון של היחידות העסקיות. הנתונים של "דיווח על טביעת רגל פחמנית" נצברים ברמת הפרויקט, ולכן חשוב להגדיר היררכיה ברורה כדי לשייך את פליטות הגזים בצורה נכונה. הגדרת ייצוא אוטומטי של נתוני טביעת הרגל הפחמנית ל-BigQuery. הנתונים המיוצאים מאפשרים לכם לבצע ניתוח מעמיק, ליצור קורלציה בין נתוני פליטת פחמן לבין נתוני עלות ושימוש, ולהפיק דוחות בהתאמה אישית.
- הגדרת מדדי ביצועים מרכזיים (KPI) שקשורים לפחמן: קובעים מדדים שמקשרים בין פליטות פחמן לבין ערך עסקי. לדוגמה, שיעור פליטת הפחמן הוא מדד למספר הקילוגרמים של CO2 שווה ערך לכל לקוח, עסקה או יחידת הכנסה.
שלב 2: זיהוי נקודות חמות של פליטת פחמן
לזהות את התחומים שבהם ההשפעה על הסביבה היא הגדולה ביותר, על ידי ניתוח הנתונים המפורטים בדוח "טביעת רגל פחמנית". כדי לבצע את הניתוח הזה, השתמשו בשיטות הבאות:
- תעדוף לפי היקף: כדי לזהות במהירות את הגורמים הגדולים ביותר לפליטת פחמן ברוטו, אפשר לנתח את הנתונים בלוח הבקרה לפי פרויקט, אזור ושירות.
- שימוש בחשבונאות כפולה: כשאתם מעריכים את ההשלכות של פליטת פחמן באזור מסוים, כדאי להביא בחשבון גם את הפליטות מבוססות-המיקום (ההשפעה הסביבתית של רשת החשמל המקומית) וגם את הפליטות מבוססות-השוק (היתרון של ההשקעות של Google באנרגיה ללא פחמן).
- התאמה לעלות: שילוב נתוני הפחמן ב-BigQuery עם נתוני החיוב, והערכת ההשפעה של פעולות האופטימיזציה על הקיימוּת ועל העלות. למרות שהעלות וטביעת הרגל הפחמנית בדרך כלל עולות ויורדות ביחד, אתם יכולים להשתמש בעלות רק כאינדיקטור ראשוני. לדוגמה, באזורים יקרים עם ציוני אנרגיה נטולת פחמן (CFE) גבוהים, לעומסי העבודה יכולות להיות עלויות גבוהות אבל פליטות נמוכות לפי השוק. חשוב תמיד לאמת את הנחות האופטימיזציה באמצעות מדדים אמיתיים שמבוססים על מיקום ומדדים שמבוססים על שוק.
- הוספת הערות לנתונים כדי למדוד את התשואה על המאמץ (ROE): מוסיפים הערות לנתוני הפחמן ב-BigQuery עם אירועים ספציפיים, כמו התאמת משאב או הוצאה משימוש של שירות גדול. ההערות מאפשרות לשייך את ההפחתה בפליטות הפחמן ובעלויות ליוזמות אופטימיזציה ספציפיות, כדי שתוכלו למדוד ולהציג את התוצאה של כל יוזמה.
שלב 3: הטמעת אופטימיזציה ממוקדת
זהו שלב הביצוע להטמעת פעולות בענן שתוכננו מראש תוך התחשבות בקיימוּת. כדי לבצע אופטימיזציה של משאבים ספציפיים שזיהיתם כגורמים משמעותיים לעלויות ולפליטות פחמן, כדאי להשתמש בשיטות הבאות:
- הוצאה משימוש של פרויקטים לא פעילים: כחלק מתהליכי העבודה של ניהול שירותי IT (ITSM), כדאי לבדוק באופן קבוע את שירות ההמלצות לפרויקטים לא פעילים שמשולב עם נתוני טביעת הרגל הפחמנית. כדי להשיג הפחתה מיידית ומאומתת בפליטות הפחמן ובעלויות, כדאי להפוך את הבדיקה וההסרה של פרויקטים שלא בשימוש לאוטומטית באמצעות כרטיסי הנדסה במעקב.
- בחירת הגודל המתאים למשאבים: כדי להתאים את קיבולת המשאבים שהוקצו לשימוש בפועל, אפשר להשתמש בהמלצות של Active Assist לבחירת הגודל המתאים, כמו המלצות לבחירת סוג המכונה למכונות וירטואליות ב-Compute Engine. למשימות עתירות-חישוב ועומסי עבודה של AI, מומלץ להשתמש בסוגי המכונות ובמודלים של AI היעילים ביותר.
- תזמון מודע לפליטת פחמן: בעומסי עבודה באצווה שלא קריטיים מבחינת זמן, שלבו את נתוני ה-CFE האזוריים בלוגיקת התזמון. במקרים שבהם הדבר אפשרי, כדאי להגביל את יצירת המשאבים החדשים לאזורים דלי-פחמן באמצעות האילוץ מיקומי משאבים בשירות מדיניות הארגון.
- צמצום התפשטות הנתונים: הטמעת מדיניות משילות מידע כדי לוודא שנתונים שניגשים אליהם לעיתים רחוקות מועברים לסוג אחסון נתונים בשימוש נדיר מתאים (Nearline, Coldline או Archive) או נמחקים באופן סופי. האסטרטגיה הזו עוזרת להפחית את עלויות האנרגיה של משאבי האחסון.
- שיפור קוד האפליקציה: תיקון חוסר יעילות ברמת הקוד שגורם לשימוש מופרז במשאבים או לחישובים מיותרים.
למידע נוסף, קראו את המאמרים הבאים:
- שימוש באזורים שצורכים אנרגיה דלת-פחמן
- אופטימיזציה של עומסי עבודה של AI ו-ML
- אופטימיזציה של השימוש במשאבים
- פיתוח תוכנה חסכונית באנרגיה
- אופטימיזציה של נתונים ואחסון לצורך קיימות
שלב 4: הפיכת שיטות העבודה והדיווח בנושא קיימוּת לחלק מהתרבות הארגונית
בשלב הזה, אתם מטמיעים את מדידת הפחמן במסגרת הממשל שלכם. הגישה הזו עוזרת לוודא שלארגון יש את היכולות ואמצעי הבקרה שנדרשים כדי לשפר את הקיימוּת באופן רציף ולדווח על כך באופן שניתן לאימות.
- הטמעה של ניהול GreenOps: הקמת פונקציה או קבוצת עבודה רשמית של GreenOps כדי לשלב נתונים של טביעת רגל פחמנית עם נתוני החיוב ב-Cloud. אפשר לשלב את הייצוא החודשי של נתוני פליטת פחמן ל-BigQuery ישירות בלוחות הבקרה הקיימים של FinOps, כמו Looker. הצגת נתוני הפחמן והעלות בממשק אחד עוזרת להבטיח שהקיימוּת תהיה חלק ממחזור הבדיקה התפעולית הרגילה. הפונקציה הזו צריכה להגדיר אחריות ליעדים של צמצום פליטת פחמן בפרויקטים, להתאים את האופטימיזציה של העלויות ליעדי הקיימות וליישם דיווח כדי לעקוב אחרי יעילות הפחמן ביחס להוצאות.
- שימוש בנתוני טביעת הרגל הפחמנית לצורכי דיווח ותאימות: אתם יכולים להשתמש בנתוני טביעת הרגל הפחמנית המאומתים והניתנים לביקורת ב-BigQuery כדי ליצור גילויים נאותים רשמיים בנושאי סביבה, חברה וממשל (ESG). הגישה הזו מאפשרת לכם לעמוד בדרישות של בעלי העניין לשקיפות, ועוזרת להבטיח עמידה בתקנות חובה ובתקנות וולונטריות.
- השקעה בהדרכה ובהעלאת המוּדעוּת: הטמעת הדרכה חובה בנושא קיימות לצוותים טכניים ולא טכניים רלוונטיים. הצוותים שלכם צריכים לדעת איך לגשת לנתונים של טביעת הרגל הפחמנית, איך לפרש אותם ואיך ליישם את המלצות האופטימיזציה בתהליכי העבודה היומיומיים ובבחירות העיצוביות שלהם. למידע נוסף, קראו את המאמר הדרכה בנושא קיימוּת לפי תפקיד.
- הגדרת דרישות פחמן: משלבים מדדי פליטת פחמן כדרישות לא פונקציונליות (NFR) בקריטריונים לקבלת האפליקציה לפריסות חדשות. השיטה הזו עוזרת להבטיח שאדריכלים ומפתחים יתעדפו אפשרויות עיצוב דל-פחמן כבר מההתחלה של מחזור החיים של פיתוח האפליקציה.
- אוטומציה של GreenOps: אפשר להשתמש בסקריפטים, בתבניות ובצינורות עיבוד נתונים של תשתית כקוד (IaC) כדי להפוך את היישום של ההמלצות של Active Assist לאוטומטי. כך הצוותים יכולים ליישם את ההמלצות באופן עקבי ומהיר בכל הארגון.
לקדם תרבות של קיימוּת
העיקרון הזה, שמופיע בעמוד התווך של הקיימוּת ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לבנות תרבות שבה הצוותים בארגון מודעים לשיטות הקיימוּת ומיומנים בהן.
סקירה כללית של העקרונות
כדי ליישם שיטות קיימוּת, צריך יותר מכלים וטכניקות. צריך לשנות את התרבות הארגונית באמצעות חינוך ואחריותיות. הצוותים שלכם צריכים להיות מודעים לנושאים שקשורים לקיימות, ולהיות בעלי מיומנות מעשית בשיטות של קיימות.
- מודעות לקיימוּת היא הידע ההקשרי שלכל החלטה שקשורה לארכיטקטורה ולתפעול יש השפעות מוחשיות על הקיימוּת. הצוותים צריכים להבין שהענן הוא לא אוסף מופשט של משאבים וירטואליים, אלא שהוא מופעל על ידי משאבים פיזיים שצורכים אנרגיה ומייצרים פליטות פחמן.
- מיומנות בשיטות קיימוּת כוללת ידע בפירוש נתונים של פליטות פחמן, ניסיון בהטמעת ניהול קיימוּת בענן ומיומנויות טכניות לשכתוב קוד לשיפור יעילות אנרגטית.
כדי להתאים את שיטות הקיימות למטרות הארגון, הצוותים צריכים להבין איך השימוש באנרגיה על ידי תשתית הענן והתוכנה תורם לטביעת הרגל הפחמנית של הארגון. הדרכה מתוכננת היטב עוזרת לוודא שכל בעלי העניין – ממפתחים ואדריכלים ועד אנשי מקצוע בתחום הפיננסים ומהנדסי תפעול – מבינים את ההקשר של הקיימות בעבודה היומיומית שלהם. ההבנה המשותפת הזו מאפשרת לצוותים לעבור מעמידה פסיבית בדרישות לתאימות לאופטימיזציה אקטיבית, וכך להפוך את עומסי העבודה בענן לבר-קיימא כבר בשלב התכנון. קיימוּת הופכת לדרישה לא פונקציונלית (NFR) מרכזית, כמו דרישות אחרות שקשורות לאבטחה, עלות, ביצועים ואמינות.
המלצות
כדי להגביר את המודעות לנושא הקיימוּת ולשפר את המיומנות בשיטות קיימוּת, כדאי לפעול לפי ההמלצות שבקטעים הבאים.
לספק הקשר עסקי והתאמה ליעדים הארגוניים
קיימות היא לא רק תרגיל טכני, היא דורשת שינוי תרבותי שמתאים את הפעולות של כל אחד למשימה הסביבתית של הארגון. כשצוותים מבינים את הסיבה ליוזמות קיימות, הם נוטים יותר לאמץ את היוזמות כעקרונות ליבה ולא כמשימות אופציונליות.
התמונה הגדולה
כדאי לעזור לצוותים להבין איך בחירות ארכיטקטוניות ספציפיות, כמו בחירת אזור דל-פחמן או אופטימיזציה של פייפליין, תורמות למחויבות הכוללת של הארגון לקיימוּת. להסביר בצורה ברורה איך הבחירות האלה משפיעות על הקהילה המקומית ועל התעשייה. להפוך מדדי פחמן מופשטים לאינדיקטורים מוחשיים של התקדמות לקראת יעדים של אחריות חברתית תאגידית (CSR).
לדוגמה, הודעה כמו זו שבהמשך מודיעה לצוותים על התוצאה החיובית ועל ההכרה של ההנהלה בהחלטה להעביר עומס עבודה לאזור דל-פחמן ולהשתמש בסוג מכונה חסכונית באנרגיה. בהודעה מוזכר השווי של פליטת CO2, כדי לעזור לצוות שלכם להבין את ההשפעה של אמצעים לצמצום פליטת פחמן.
"העברנו את המנוע לניתוח נתונים לאזור us-central1 עם
תקשור יעדים פיננסיים ויעדי קיימות
השקיפות חיונית כדי להתאים את שיטות העבודה לקיימות ליעדים. ככל שניתן, שתפו את יעדי הקיימות ואת ההתקדמות בהשגתם עם כל הארגון. הדגשת ההתקדמות בתחום הקיימוּת בדוחות הכספיים השנתיים. התקשורת הזו מבטיחה שהצוותים הטכניים יראו את העבודה שלהם כחלק חיוני מההתחייבויות של הארגון כלפי הציבור ומהבריאות הפיננסית שלו.
אימוץ גישה של גורל משותף
ללמד את הצוותים על האופי השיתופי של קיימות בענן. Google אחראית לקיימות של הענן, כולל היעילות של התשתית ומרכזי הנתונים. אתם (הלקוחות) אחראים לקיימות של המשאבים ועומסי העבודה שלכם בענן. כשמציגים את שיתוף הפעולה הזה כשותפות של גורל משותף, זה מחזק את ההבנה שהארגון שלכם ו-Google פועלים יחד כדי להשיג תוצאות סביבתיות אופטימליות.
להעביר הדרכות בנושא קיימות שמבוססות על תפקידים
כדי לוודא שקיימות היא מיומנות מעשית ולא מושג תיאורטי, כדאי להתאים את ההדרכה בנושא קיימות לתפקידים ספציפיים. הכלים והשיטות לקיימוּת שמדעני נתונים יכולים להשתמש בהם שונים מאוד מאלה שזמינים למנתחי FinOps, כפי שמתואר בטבלה הבאה:
| תפקיד | התמקדות באימון |
|---|---|
| מדעני נתונים ומהנדסי למידת מכונה (ML) | שיעור פליטת הפחמן של המחשוב: הדגמת ההבדלים בין הרצת משימות אימון של AI במערכות מדור קודם לבין מאיצי AI ייעודיים. הדגישו איך מודל עם פחות פרמטרים יכול להפיק את הדיוק הנדרש עם צריכת אנרגיה נמוכה משמעותית. |
| מפתחים | יעילות הקוד וצריכת המשאבים: הסבירו איך קוד עם זמן אחזור ארוך או לולאות לא יעילות משפיעים ישירות על זמן הריצה של המעבד (CPU) ועל צריכת האנרגיה. הדגישו את החשיבות של קונטיינרים קלים ואת הצורך באופטימיזציה של ביצועי האפליקציה כדי לצמצם את טביעת הרגל הסביבתית של התוכנה. |
| אדריכלים | קיימות מובנית: מתמקדים בבחירת אזור ובמיקום עומס העבודה. הסבר איך בחירה באזור Low CO2 עם אחוז גבוה של אנרגיה מתחדשת (כמו northamerica-northeast1) משנה באופן מהותי את פרופיל הפחמן של כל חבילת האפליקציות שלכם, עוד לפני שכותבים שורת קוד אחת. |
| מהנדסי פלטפורמה ומהנדסי תפעול | ניצול מיטבי: חשוב להדגיש את העלות הסביבתית של משאבים לא פעילים והקצאת יתר של משאבים. להציג תרחישים של התאמה אוטומטית לעומס (automatic scaling) ושל התאמה לגודל הנכון (right-sizing) כדי להבטיח שימוש יעיל במשאבי הענן. הסבר על יצירה ומעקב של מדדים שקשורים לקיימות, כמו שימוש, ועל המרת מדדים כמו זמן מחשוב למדדים מקבילים של פליטות פחמן. |
| FinOps | כלכלת יחידות של פחמן: התמקדות בקשר בין ההוצאות הפיננסיות לבין ההשפעה על הסביבה. להסביר איך שיטות עבודה של GreenOps מאפשרות לארגון לעקוב אחרי פליטת פחמן לכל עסקה, וכך להפוך את הקיימות למדד ביצועים מרכזי (KPI) שחשוב לא פחות ממדדי ביצועים מרכזיים רגילים כמו עלות וניצול. |
| מנהלי מוצר | קיימות כתכונה: איך לשלב יעדים לצמצום פליטת הפחמן בתוכניות השיווקיות של המוצרים. הסבר איך התהליך שעובר המשתמש הפשוט יכול לעזור להפחית את צריכת האנרגיה של משאבי הענן ושל מכשירי משתמשי הקצה. |
| מנהיגים עסקיים | התאמה אסטרטגית ודיווח: התמקדות באופן שבו הקיימות בענן משפיעה על ציוני ESG (סביבה, חברה וממשל) ועל המוניטין הציבורי. להמחיש איך בחירות שמתחשבות בסביבה עוזרות להפחית את הסיכון הרגולטורי ולעמוד בהתחייבויות לקהילה ולתעשייה. |
תומכים בקיימות ומכירים בהצלחה
כדי לשמור על התקדמות לטווח ארוך, צריך לעשות יותר מתיקונים טכניים פנימיים ולהתחיל להשפיע על השותפים ועל התעשייה.
עוזרים למנהלים לתמוך בקיימות
לספק למנהלים את הנתונים וההרשאות שהם צריכים כדי לתעדף את ההשפעה על הסביבה, בדומה למדדים עסקיים אחרים כמו מהירות היציאה לשוק ועלות. כשהמנהלים מקבלים את הנתונים האלה, הם מתחילים לראות את הקיימות כסטנדרט של איכות ויעילות, ולא כמאפיין רצוי שמאט את הייצור. הם פועלים באופן פעיל כדי לקדם תכונות חדשות של ספקי שירותי ענן, כמו נתוני פחמן מפורטים יותר ומעבדים חדשים וידידותיים יותר לסביבה באזורים ספציפיים.
התאמה לסטנדרטים ולמסגרות מקובלים בתחום
כדי לוודא שהמאמצים שלכם בתחום הקיימות הם אמינים ומדידים, חשוב להתאים את השיטות הפנימיות שלכם לתקנים מוכרים ברמה הגלובלית והאזורית. מידע נוסף זמין במאמר בנושא התאמת שיטות הקיימות להנחיות בתעשייה.
תמריצים למאמצי קיימוּת
כדי להבטיח שקיימות תהפוך לחלק בלתי נפרד מתרבות ההנדסה, הצוותים צריכים להבין את הערך של מתן עדיפות לקיימות. מעבר מיעדים ברמה גבוהה למדדי KPI ספציפיים ומדידים שמתגמלים שיפור ויעילות.
הגדרת מדדי KPI ודרישות לא פונקציונליות (NFR) שקשורים לפחמן
התייחסו לקיימות כאל דרישה טכנית מרכזית. כשמגדירים מדדי ביצועים מרכזיים (KPI) שקשורים לפליטות פחמן, כמו גרמים של שווי ערך לפחמן דו-חמצני למיליון בקשות או עוצמת פליטות פחמן לכל הפעלה של אימון AI, אפשר לראות את ההשפעה על הקיימות ולפעול בהתאם. לדוגמה, לשלב קיימות בדרישות הלא פונקציונליות של כל פרויקט חדש. במילים אחרות, כמו שמערכת צריכה לעמוד ביעד ספציפי של זמן אחזור או זמינות, היא צריכה גם לעמוד בתקציב מוגדר של פליטות פחמן.
מדידת התשואה על המאמץ
עזרו לצוותים שלכם לזהות הזדמנויות לשיפור הקיימות שדורשות מאמץ קטן אבל יש להן השפעה גדולה, כמו העברת משימה באצווה לאזור אחר, לעומת תרגיל מורכב של ארגון הקוד מחדש שעשוי להניב רווחים מינימליים. לספק תובנות לגבי התשואה על המאמץ (ROE). כשצוות בוחר משפחת מעבדים יעילה יותר, הוא צריך לדעת בדיוק כמה פליטות פחמן נמנעו ביחס לזמן ולמאמץ שנדרשו כדי לעבור למעבד החדש.
הכרה וציון של צמצום פליטת הפחמן
ההשפעה על הקיימות לרוב חבויה ברקע של התשתית. כדי לשמור על המומנטום של ההתקדמות בתחום הקיימות, חשוב להציג את ההצלחות לכל הארגון. לדוגמה, אפשר להשתמש בהערות בלוחות הבקרה כדי לסמן מתי הצוות פרס את האופטימיזציה הספציפית לקיימוּת. החשיפה הזו מאפשרת לצוותים להצביע על נתונים בלוח הבקרה ולקבל הכרה על ההצלחות שלהם.
התאמה של שיטות ליישום קיימות להנחיות המקובלות בתחום
העיקרון הזה, שמופיע בעמוד התווך של קיימוּת ב-Google Cloud Well-Architected Framework, מספק סקירה כללית של ההנחיות והמסגרות הרווחות בתחום, שבהתאם להן כדאי להתאים את מאמצי הקיימוּת שלכם.
סקירה כללית של העקרונות
כדי לוודא שהיוזמות שלכם בתחום הקיימות מבוססות על שיטות מוכרות בעולם למדידה, לדיווח ולאימות, מומלץ להתאים את היוזמות שלכם להנחיות הבאות בתחום:
כשמיישרים קו עם ההנחיות החיצוניות המשותפות האלה, המיזמים מקבלים את האמינות והיכולת לעבור ביקורת שמשקיעים, גופים רגולטוריים ובעלי עניין חיצוניים אחרים דורשים. אתם גם מעודדים אחריותיות בקרב צוותי ההנדסה, מטמיעים קיימוּת בהדרכות לעובדים ומשלבים בהצלחה את פעולות הענן במחויבויות של הארגון לדיווח על סביבה, חברה וממשל (ESG).
הנחיות W3C לקיימוּת באינטרנט
הנחיות W3C בנושא קיימות באינטרנט (WSG) הן מסגרת חדשה של שיטות מומלצות שפותחה על ידי קבוצת עבודה של W3C כדי לתת מענה להשפעה הסביבתית של מוצרים ושירותים דיגיטליים. ההנחיות מתייחסות לכל מחזור החיים של פתרון דיגיטלי, כולל אסטרטגיה עסקית ואסטרטגיית מוצר, עיצוב חוויית משתמש (UX), פיתוח אתרים, אירוח, תשתית ומערכות. המטרה העיקרית של WSG היא לאפשר למפתחים ולאדריכלים לבנות אתרים ואפליקציות אינטרנט שצורכים פחות אנרגיה, ולהפחית את התנועה ברשת, את העיבוד בצד הלקוח ואת צריכת המשאבים בצד השרת. ההנחיות האלה משמשות כנקודת התייחסות קריטית להתאמה בין הקיימוּת ברמת האפליקציה לבין החלטות ארכיטקטוניות ברמת הענן.
Green Software Foundation
הקרן לתוכנה ירוקה (GSF) מתמקדת בבניית סביבה עסקית בתעשייה סביב תוכנה בת קיימא. המטרה שלה היא לקדם את היצירה של תוכנה שמתוכננת, נבנית ומופעלת באופן שממזער את טביעת הרגל הפחמנית. ה-GSF פיתח את מפרט שיעור פליטת הפחמן של תוכנות (SCI), שמספק תקן משותף למדידת שיעור פליטת הפחמן של כל תוכנה. התאמה ל-GSF עוזרת למפתחים לקשר את יעילות האפליקציה ישירות להשפעה של סביבת הענן על פליטת הפחמן.
פרוטוקול גזי חממה
פרוטוקול גז החממה (GHG) הוא קבוצה של תקנים שנמצאים בשימוש נרחב למדידה, לניהול ולדיווח ציבורי על פליטות של גזי חממה. הפרוטוקול פותח בשותפות בין World Resources Institute (WRI) לבין World Business Council for Sustainable Development (WBCSD). פרוטוקול GHG מספק את המסגרת החיונית לניהול חשבונות של פליטת גזי חממה בחברות. הדוח על טביעת הרגל הפחמנית מספק נתונים על היקפי פליטות שרלוונטיים לשימוש בענן. למידע נוסף, קראו את המאמר המתודולוגיה לדיווח על טביעת רגל פחמנית.
הקפדה על פרוטוקול GHG עוזרת להבטיח שליוזמות הקיימות שלכם תהיה אמינות, ושהגורמים החיצוניים יוכלו לבדוק את נתוני פליטת הפחמן שלכם. בנוסף, אתם יכולים למנוע את התפיסה של התייפייפות ירוקה ולעמוד בדרישות של בדיקת הנאותות של המשקיעים, הרגולטורים ובעלי העניין החיצוניים. נתונים מאומתים ומבוקרים עוזרים לארגון להוכיח אחריות ולבנות אמון במחויבויות לקיימוּת שמוצגות לציבור.