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

Last reviewed 2026-01-28 UTC

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

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

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

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

המלצות

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

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

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

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

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

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

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

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

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