Pobierz PDF

GreenWhisk: Emission-Aware Computing for Serverless Platform

Metadane

• Autorzy: Jayden Serenari, Sreekanth Sreekumar, Kaiwen Zhao, Saurabh Sarkar, Stephen Lee
• Rok: 2024
• Źródło: arXiv:2409.03029 (University of Pittsburgh, TryCarbonara); IC2E 2024
• arXiv: 2409.03029
• Status: read
• Kategoria: Systems
• Tagi: #carbon-awareness #serverless #faas #load-balancing #renewable-energy #grid-carbon-intensity #openwhisk #scheduling #project/js-runtime-energy

Streszczenie

GreenWhisk to pierwsza pełna rearchitektura serverless platform (Apache OpenWhisk) pod kątem carbon efficiency. Autorzy identyfikują dwa tryby pracy: grid-connected (serwery podłączone do sieci energetycznej z węglem jako kosztem) i grid-isolated (zasilanie off-grid: solar + baterie z dostępnością energii jako ograniczeniem). Kluczowy problem: klasyczny OpenWhisk optymalizuje locality (consistent hashing → mniej cold starts), ale ignoruje zróżnicowanie carbon intensity między lokalizacjami i w czasie.

GreenWhisk rozwiązuje to przez: (1) Energy Interface API eksponujące dane o carbon intensity (WattTime) i dostępności energii (solar, baterie) do load balancera; (2) Carbon-aware Load Balancer oparty na ważonym consistent hashing gdzie wagą jest odwrotność carbon intensity lub dostępna energia; (3) Retry Queue (Redis priority queue) umożliwiający opóźnienie wywołania funkcji do momentu niższego carbon intensity lub dostępności energii.

Wyniki symulacji (1 rok, 18 serwerów, 9 lokalizacji w USA): GreenWhisk unika 2093 kg CO₂ wobec 950 kg dla baseline (consistent hashing) — 2.2× lepiej. W trybie grid-isolated: 50% redukcja downtime i shutdowns serwerów solarnych wobec OpenWhisk. Narzut na latencję: minimalny (porównywalny do OpenWhisk; Greedy jest gorszy latencyjnie bo ignoruje locality).

Kluczowe Wnioski

• Carbon efficiency vs. locality trade-off: Greedy (tylko carbon) unika najwięcej emisji (2565 kg) ale generuje więcej cold starts i wyższą latencję; GreenWhisk balansuje (2093 kg) z minimalnym wpływem na latencję
• Retry Queue jako mechanizm temporal shifting: funkcje mogą być opóźniane do niżej-emisyjnych okiennych — analogia do temporal workload shifting (Wiesner 2021)
• Grid-isolated = 50% mniej downtime: GreenWhisk równomiernie rozkłada obciążenie energetyczne między lokalizacje, OpenWhisk skupia na jednym węźle → jego bateria wyczerpuje się szybciej
• Marginal emissions (MOER) jako właściwa metryka: nie absolutes gCO₂/kWh lecz “unikniętych emisji” przy przeniesieniu workloadu między lokalizacjami — analogia do marginal energy w FaasMeter
• Skalowanie z liczbą węzłów: więcej lokalizacji = więcej okazji do spatial carbon arbitrage; per-node unikniętych emisji maleje (diminishing returns)
• Runtime energy ignorowany: GreenWhisk optymalizuje gdzie i kiedy uruchomić funkcję, nie jak efektywnie runtime ją wykonuje — fundamentalna luka dla projektu JE

Metodologia

Hardware: 10× Raspberry Pi 4 (8GB RAM, ARM) + 10× serwer (Intel Xeon Silver 4114, 12×32GB) + kontroler (Intel i7 11gen). Multi-arch Docker images (armv7 + amd64) dla Node.js, Python, Ruby. Implementacja w Scala (2870 LOC zmian w OpenWhisk).

Symulacja: Java simulator, 1 rok, Azure Function Trace (3 subsets: Rare 125fn/15req/min, Medium 50fn/54req/min, High 50fn/354req/min), 18 serwerów w 9 lokalizacjach geograficznych USA.

Dane: WattTime MOER (Marginal Operating Emissions Rate, lbs/MWh) dla 9 lokalizacji (Henderson NV, The Dalles OR, Douglas Co. GA, New Albany OH, itd.), Solcast GTI dla solar profiles.

Model energii serwera: power = P_idle + λ·(P_peak − P_idle) (liniowy model, λ = utilization 0–1).

Główne Koncepcje

• GreenWhisk: OpenWhisk + Energy Interface API + Carbon-aware Load Balancer + Retry Queue; grid-connected i grid-isolated mode
• Carbon-aware Load Balancer: weighted consistent hashing; waga = −carbon_intensity_i / Σcarbon_intensity_j (grid-connected) lub avail_energy_i / Σavail_energy_j (grid-isolated); dystans = −ln((1−(server−function)) mod 1)
• Retry Queue: Redis priority queue z priorytetem odwrotnie proporcjonalnym do czasu dodania; domyślnie max 3 retries przed notyfikacją usera; umożliwia temporal shifting
• Energy buffer: minimalny poziom baterii (20% pojemności) jako buffer na opóźnienia komunikacji między Energy Profile a kontrolerem
• MOER (Marginal Operating Emissions Rate): emisje unikniętych CO₂ przy przeniesieniu obciążenia z jednej lokalizacji do innej; bardziej precyzyjna niż average emissions factor; dostarczone przez WattTime API
• Grid-connected vs grid-isolated: dwa ortogonalne scenariusze; w grid-isolated zero carbon footprint ale intermittent energy supply — wyzwanie dostępności, nie emisji

Wyniki

Grid-isolated: GreenWhisk 8 shutdowns / 4.5h downtime vs OpenWhisk 14 / 8.6h. Battery criticalities: 243 vs 309.

Przydatne Cytaty

“Prior research indicates that introducing additional control mechanisms to manage function execution can result in a nearly 15x increase in consumption compared to traditional self-managed services.” (str. 1 — overhead serverless platform)

“While significant efforts have been dedicated to optimizing energy and carbon efficiency at the system or application level, there has been little work in addressing the carbon efficiency of existing cloud platforms.” (str. 1)

“GreenWhisk strikes a balance between both locality and emissions, providing a middle-ground solution.” (str. 8)

“Our approach does not involve explicit power control. Instead, we expose this information to the platform and introduce mechanisms for high-level algorithms to optimize carbon efficiency.” (str. 10 — Related Work)

Datasety

• Azure Function Trace 2020 — subsampled traces (Rare 125fn, Medium 50fn, High 50fn); używane do generowania workloadów w symulacji i emulacji
• WattTime MOER dataset — marginal emissions data dla 9 US lokalizacji (Google data center sites)
• Solcast Solar API — GTI (Global Tilted Irradiance) dla solar profiles w każdej lokalizacji

Powiązane Tematy

• Carbon intensity shifting analogia do FaasMeter marginal energy — oba używają “marginal” jako właściwą metrykę
• Fundamentalna luka dla JE: GreenWhisk zakłada stałą energię per function (tylko time/space shifting) — nie uwzględnia, że zmiana runtimes (Node.js → Bun) zmniejsza energię per invocation; hybrid approach: GreenWhisk + runtime awareness
• Wiesner 2021 “Let’s wait awhile” (temporal workload shifting) — komplementarny do GreenWhisk; obie prace to carbon-aware scheduling, nie runtime optimization
• [#JE-7] Runtime-aware scheduling: rozszerzenie GreenWhisk o wymiar runtime energy efficiency
• Raspberry Pi jako testbed — bezpośredni sprzęt edge do testów JS runtimeów na ARM

Notatki