Green Ops תזמון עומסי ענן לפי פליטות ודרישות שירות
גרסה לימודית מתוקנת; תאריך המקור האנגלי: 2026-06-11T20:58:42.362+03:00. המהדורה בעברית משתמשת בתאריך הפרסום שלה בפועל, ולא בתאריך המקור באנגלית. כל דוגמאות הקוד והמספרים להמחשה בלבד ולא הורצו או נמדדו במסגרת ההכנה הזאת. English original
שלום לכולם, כאן אלכס. ברוכים השבים למהדורה נוספת של Coding with Alex ב־sysseder.com.
ב־10 ביוני 2026 דיווח Ember שלפי נתונים חודשיים רשמיים ונתונים שעתיים ראשוניים, ייצור החשמל הסולארי בארצות הברית עבר את הפחם לראשונה בחודש קלנדרי מתועד — מאי 2026. זהו ממצא חודשי, לא מעבר שנתי ולא טענה שהשמש מספקת את רוב החשמל בארצות הברית. לצוותי תוכנה השאלה הרלוונטית היא כיצד תנאי החשמל המקומיים משפיעים על מחשוב גמיש. [מקור 1]
הייצור הסולארי משתנה עם אור היום, מזג האוויר והעונה; רשתות משתמשות גם ברוח, מים, גרעין, ייצור מאובנים, אגירה ויבוא. לתחנות שניתן לשלוט בייצורן יש מגבלות תפעוליות, ולא גמישות מיידית בלתי מוגבלת. מרכזי נתונים ניזונים מהמערכות המשתנות האלה, ולכן החלטות מודעות פחמן דורשות מדידות או תחזיות אזוריות, ולא רק אור שמש. [מקור 1] [מקור 2]
נבחן תזמון וניתוב מודעי פחמן תוך שמירה מפורשת על דרישות השירות. דוגמת ה־Python משתמשת בנתונים סינתטיים בלבד ואינה פונה ל־API בתשלום, מתזמנת משימה או מדגימה חיסכון שנמדד בפליטות. [מקור 1]
Green Ops מוסיף שיקולי פחמן בלי לוותר על זמינות [מקור 1]
במשך עשרות שנים ארכיטקטורת ענן הונעה בשלושה עמודי תווך: ביצועים, זמינות ועלות. אם שרת עמוס או זמן התגובה של API מזנק, מוסיפים מחשוב. קבוצות הרחבה אוטומטית מפעילות עוד מכונות וירטואליות ו־Kubernetes מתזמן עוד pods.
השפעת הפחמן של משימה תלויה בצריכת האנרגיה ובאות הפליטות האזורי המתאים בשעת הביצוע. אחר צהריים עשיר בשמש עשוי להיות דל פחמן יותר מערב ברשתות מסוימות, אך 13:00 אינה תמיד נקייה יותר מ־20:00. רוח, מים, גרעין, יבוא, אגירה ושיטת החשבונאות הממוצעת או השולית יכולים לשנות את ההשוואה. [מקור 1] [מקור 2]
כמפתחים, עומדים לרשותנו שני מנופים עיקריים להפיכת יישומים למודעי פחמן:
- הסטה בזמן: מעבירים עבודה שאפשר לדחות לחלונות דלי פליטות יותר, תוך עמידה במועדי השלמה ובמגבלות משאבים. [מקור 1]
- הסטה במרחב: בוחנים אזורים מותרים לפי פליטות שנמדדו או נחזו, לאחר מגבלות השהיה, מיקום נתונים, עקביות, אמינות והעברה. [מקור 1]
איך מודדים את עצימות הפחמן של הרשת בזמן אמת
בחרו אות שמתאים להחלטה: עצימות פחמן ממוצעת מתארת תמהיל חשמל, ואילו פליטות שוליות אומדות את ההשפעה של שינוי נוסף בעומס. אל תערבבו יחידות ואל תטענו שאחד מהם מודד ישירות את טביעת הרגל המלאה של היישום. [מקור 1] [מקור 2]
Electricity Maps ו־WattTime מפרסמים ממשקי API לחשמל ולפליטות, אך האותות, היחידות, הכיסוי האזורי, אופקי התחזית ותוכניות הגישה שלהם שונים. אותות הפליטות השוליות של WattTime אינם בני החלפה עם סדרה ממוצעת ב־gCO2e/kWh. בדקו את נקודת הקצה והמינוי שנבחרו; אין הנחה של גישה חינמית גורפת או תחזית אחידה ל־24–72 שעות. הדוגמה אינה יוצרת עלות API. [Electricity Maps] [WattTime API] [מקור 1] [מקור 2] [מקור 3]
נבחן את הזרימה הארכיטקטונית המושגית של יישום מודע פחמן:
Conceptual flow, not a deployed system:
Scheduler -> validated regional forecast + job requirements
-> choose feasible lower-emissions window
-> check freshness, capacity and deadline
-> orchestrator schedules job OR applies safe fallback
Low emissions do not necessarily coincide with peak solar.תרגום הזרימה המתוקנת: מתזמן מקבל תחזית אזורית מאומתת ודרישות משימה, בוחר חלון אפשרי עם פחות פליטות, בודק טריות, קיבולת ומועד סיום, ואז מתזמר משימה או מפעיל מדיניות גיבוי בטוחה. פחות פליטות אינן בהכרח שיא ייצור שמש.
בניית מתזמן משימות מודע פחמן ב־Python
נכתוב סקריפט Python מעשי. דמיינו פלטפורמת SaaS המייצרת דוחות PDF כבדים למשתמשים או מבצעת המרות וידאו גדולות. המשימות אינן רגישות לזמן; הן רק צריכות להסתיים בתוך חלון של 12 שעות.
בחרו חלון בר־ביצוע בעצימות נמוכה מתוך תחזית שנבדקה, ולא פשוט את השעות הבהירות ביותר. משך המשימה המשוער חייב להיכנס לפני המועד האחרון. כאשר צריכת האנרגיה משתנה לאורך הזמן, יש למזער פליטות משוקללות באנרגיה ולא ממוצע לא משוקלל. [מקור 1]
הדוגמה הסינתטית המתוקנת משתמשת רק בספרייה התקנית של Python; אין צורך להתקין לקוח HTTP או pandas.
# Runtime-untested example uses only the Python standard library.
# No third-party packages, API call, credentials or paid plan are required.הדוגמה הבאה, שלא הורצה, יוצרת 12 מרווחים שעתיים סינתטיים במפורש עם זמני UTC הכוללים אזור זמן. הערכים אינם תצפיות או עקומת שמש טיפוסית של קליפורניה. היא מאמתת רציפות, ערכים, משך ומועד אחרון ואז מחזירה חלון מוצע; היא אינה מפעילה או מתזמנת עומס עבודה. הממוצע השעתי מניח בקירוב הספק קבוע של המשימה.
# Runtime-untested. Synthetic data only; no real API or job execution.
from datetime import datetime, timedelta, timezone
import math
HOUR = timedelta(hours=1)
def synthetic_forecast(start):
# Arbitrary illustrative values, NOT California observations or predictions.
values = [420, 380, 310, 220, 160, 120, 140, 190, 260, 330, 390, 430]
return [
{"start": start + i * HOUR, "intensity": float(value)}
for i, value in enumerate(values)
]
def choose_window(forecast, duration_hours, earliest, deadline):
if isinstance(duration_hours, bool) or not isinstance(duration_hours, int):
raise ValueError("duration must be an integer number of hours")
if duration_hours <= 0 or len(forecast) < duration_hours:
raise ValueError("invalid duration or insufficient forecast")
for stamp in (earliest, deadline):
if stamp.utcoffset() is None:
raise ValueError("timezone-aware timestamps required")
if deadline <= earliest:
raise ValueError("invalid deadline")
previous = None
for slot in forecast:
start = slot["start"]
if start.utcoffset() is None:
raise ValueError("timezone-aware forecast required")
if previous is not None and start - previous != HOUR:
raise ValueError("forecast must be ordered, continuous hourly slots")
value = slot["intensity"]
if not math.isfinite(value) or value < 0:
raise ValueError("invalid intensity")
previous = start
candidates = []
for i in range(len(forecast) - duration_hours + 1):
window = forecast[i:i + duration_hours]
start = window[0]["start"]
end = start + duration_hours * HOUR
if start < earliest or end > deadline:
continue
# Valid only for equal hourly energy use / roughly constant job power.
average = sum(slot["intensity"] for slot in window) / duration_hours
candidates.append((average, start, end))
if not candidates:
raise ValueError("no complete feasible window")
return min(candidates, key=lambda x: (x[0], x[1]))
if __name__ == "__main__":
now = datetime.now(timezone.utc)
start = now.replace(minute=0, second=0, microsecond=0) + HOUR
deadline = now + 12 * HOUR
average, proposed_start, proposed_end = choose_window(
synthetic_forecast(start), 2, start, deadline
)
print("SYNTHETIC / UNTESTED; no workload has been scheduled")
print("Illustrative zone only; not a provider zone identifier")
print("Proposed UTC window:", proposed_start.isoformat(), proposed_end.isoformat())
print("Illustrative average gCO2e/kWh:", average)
מתזמר יכול להשתמש בחלון מוצע רק לאחר התחשבות במצב התור, בקיבולת, במרווח ביטחון למועד האחרון, בגיל התחזית, בניסיונות חוזרים, באידמפוטנטיות ובגיבוי לכשל. הסטת משימה לבדה אינה מוכיחה תועלת ליציבות הרשת או הפחתת פליטות שנמדדה. [מקור 1]
הסטה במרחב בעקבות השמש
הסטה בזמן מתאימה למשימות אצווה שאפשר לדחות, אך מה לגבי ממשקי API למשתמשים בהשהיה נמוכה? אי אפשר לדחות בקשת תשלום של משתמש עד מחר אחר הצהריים רק מפני שהשמש שקעה.
לעבודה חסרת מצב מתאימה או לקריאות מנתונים משוכפלים, מיקום אזורי עשוי לספק דרגת חופש נוספת. הוא חייב להישאר בתוך יעדי ההשהיה והזמינות וכללי מיקום הנתונים. כתיבות עם מצב ופעולות רגישות לעקביות דורשות תכנון נפרד, והעברת נתונים יכולה להוסיף צריכת אנרגיה ועלות כספית. [מקור 1]
ניתוב מרובה אזורים בעזרת DNS או Anycast
מדיניות DNS, מאזני עומסים וניתוב קצה יכולים להפנות תעבורה, אך אינם ממזערים אוטומטית פליטות פחמן. בקר מפורש צריך לשלב נתוני פליטות תקפים עם תקינות, השהיה ואילוצי מדיניות; גם מטמון DNS מגביל את מהירות כניסת השינויים לתוקף.
אל תניחו ש־eu-west-1, eu-central-1, us-east-1 או us-west-2 נקיים יותר רק מפני שאצלם אחר הצהריים. השתמשו במיפוי נכון בין הרשת לאזור ובאות פליטות מתאים, ואז כללו את העברת הנתונים ואת אילוצי השירות לפני העברת עומס מעבר לאוקיינוס. [מקור 1] [מקור 2] [מקור 3]
אופטימיזציה ברמת התשתית KEDA והרחבה מודעת פחמן
כמהנדסי DevOps, לא תמיד נרצה לכתוב קוד יישום מותאם לטיפול במדדי פחמן. נרצה שהתשתית תעשה זאת באופן מובנה.
KEDA יכול לצרוך מדדים חיצוניים, לרבות ערך Prometheus שמספקת מדיניות או תוכנת ייצוא משלכם. אין בכך להפוך מודעות פחמן לתכונה מובנית או לאמת את Carbon-Aware KEDA Operator שהוזכר במקור. כאן משתמשים ב־scaler הכללי המתועד של Prometheus ומשאירים את רכיב המדיניות מפורש. [מקור 1]
מדיניות מודעת פחמן עשויה להתיר יותר עבודה הניתנת לדחייה בחלון מתאים ודל פליטות ופחות כשהפליטות גבוהות, תוך הגנה על מועדי השלמה. הספים שלהלן הם דוגמאות מדיניות, לא הגדרות כלליות שנבדקו; שינוי דינמי של maxReplicas דורש לוגיקת בקרה נפרדת. [מקור 1] [מקור 2]
- דוגמת מדיניות לעצימות נמוכה מ־150 gCO2e/kWh: מתירים יותר עבודה מתאימה מהתור, בכפוף לקיבולת ולתקרה של 50 עותקים שהוגדרה בנפרד. אין פירוש הדבר שזו שעת שיא שמש בכל רשת. [מקור 1]
- דוגמת מדיניות לעצימות גבוהה מ־350 gCO2e/kWh: דוחים רק עבודה שמועדיה מאפשרים זאת, ושומרים מינימום מוגדר של שני עובדים. מידע חסר או עבודה דחופה דורשים גיבוי מפורש; עצימות גבוהה אינה שם נרדף ללילה או לייצור בגז. [מקור 1]
רעיון KEDA עם מדד עבודה מותרת שממומש בנפרד [מקור 1]
# Runtime-untested CONCEPT. Requires a separately implemented policy exporter.
# Raw carbon intensity is NOT used as demand: higher metrics usually scale UP.
# Export eligible backlog after carbon policy, deadline and freshness checks.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: carbon-aware-worker-scaler
namespace: default
spec:
scaleTargetRef:
name: background-worker
minReplicaCount: 2
maxReplicaCount: 50
pollingInterval: 60
fallback:
failureThreshold: 3
replicas: 2
triggers:
- type: prometheus
metricType: AverageValue
metadata:
serverAddress: http://prometheus-k8s.monitoring.svc.cluster.local:9090
query: sum(carbon_aware_backlog_work_units{queue="reports"})
threshold: "100"
ignoreNullValues: "false"
# Metric: finite non-negative work units permitted by the external policy.
# Threshold: illustrative work units per replica, NOT gCO2e/kWh.
# Fallback of 2 is illustrative; protect deadlines with a reviewed policy.
# Authentication/TLS, metric freshness and missing-series detection are not supplied.
תפקיד המפתח בעתיד מתחדש
אבן הדרך החודשית ההיסטורית של השמש היא הקשר מועיל, לא הוכחה שייצור מאובנים נעלם. תוכנת ענן רצה על תשתית פיזית, ולכן יש להעריך יעילות ותזמון לפי גבולות מערכת שקופים וצריכת אנרגיה שנמדדה לעומס העבודה. [מקור 1] [מקור 2]
תכנון מודע פחמן יכול לסייע בהפחתת פליטות כאשר האות הנבחר, גמישות העבודה וההשפעות הכוללות תומכים בכך. השוו לקו בסיס ודווחו על אי־ודאות, העברות נוספות, עבודה שנכשלה או בוצעה שוב וכל תקורת אנרגיה. שילוב מדד ב־CI/CD או בהרחבה אוטומטית אינו כשלעצמו ראיה לחיסכון. [מקור 1]
עכשיו תורכם: האם ניסיתם ממשקי API מודעי פחמן או כלי Green Ops בצינורות ה־DevOps שלכם? כתבו בתגובות, ואל תשכחו להירשם לניוזלטר לעוד העמקות טכניות!
עד הפעם הבאה, המשיכו לתכנת נקי.