Pobierz PDF

A Framework for SLO, Carbon, and Wastewater-Aware Sustainable FaaS Cloud Platform Management

Metadane

• Autorzy: Sirui Qi, Hayden Moore (Colorado State University), Ninad Hogade, Dejan Milojicic, Cullen Bash (Hewlett Packard Labs), Sudeep Pasricha (Colorado State University)
• Rok: 2024
• Źródło: arXiv:2410.11875 (workshop/short paper, Oct 2024)
• Uwaga: Ten sam zespół co CASA (su-casa-slo-carbon-serverless-2024) — rozszerzenie o wastewater jako trzeci cel
• Status: read
• Kategoria: Systems
• Tagi: #carbon-awareness #serverless #faas #scheduling #autoscaling #slo #multi-objective-optimization #wastewater #evolutionary-algorithm #project/js-runtime-energy

Streszczenie

SFCM (Sustainable FaaS Cloud Management) to pierwsza praca jednocześnie co-optymalizująca trzy cele środowiskowe w FaaS: (1) SLO violation rate, (2) carbon emissions, (3) wastewater generation. Nowatorstwo względem CASA (tego samego zespołu): dodanie wymiaru wastewater — datacenter zużywają 626 miliardów litrów wody rocznie w USA; cooling units evaporują wodę, a hotspoty termiczne zwiększają zużycie chłodzenia.

SFCM używa hybrydowego algorytmu: local search (add/remove/shuffle kontenerów per funkcja) + evolutionary algorithm (EA) (crossover par rozwiązań z populacji) + search history (boost local search przez śledzenie częstości aktualizacji każdego punktu). To rozszerzenie podejścia CASA — zamiast naprzemiennego przełączania między dwoma optymalizatorami, SFCM utrzymuje populację rozwiązań i łączy local search z globalną eksploracją EA.

Wyniki (50-węzłowy klaster, 2× AMD EPYC 7713, Azure Function Trace, 8-godzinny test): SFCM-Balance redukuje SLO violations/carbon/water o 45%/25%/26% vs HYBRID baseline; vs SCORE (lepszy SOTA): 14% mniej carbon, 20% mniej water, <1% kompromis na SLO.

Kluczowe Wnioski

• Wastewater jako nowa metryka zrównoważoności: carbon ≠ water; woda chłodząca i wastewater treatment generują oddzielny ślad węglowy; SLO-focused scheduling może zwiększać zużycie wody przez thermal hotspoty
• SFCM generuje Pareto front: w odróżnieniu od SCORE i HYBRID (single-point solutions), SFCM zwraca zestaw rozwiązań dominujących Pareto — operator może wybrać preferencje
• Trzy cele antagonistyczne: SLO wymaga więcej kontenerów → więcej energii → więcej carbon + water; carbon minimizacja konsoliduje → cold starts + SLO violations; water zależy od thermal distribution
• HYBRID jako słaby baseline: metoda akademicka (IEEE TEVC 2012), nie specifcznie FaaS; SFCM dominuje go o 45%/25%/26%
• Fundamentalna luka dla JE: model carbon/water oparty na CPU utilization i energii — nie uwzględnia że JS runtime wybór (Node.js vs Bun) zmienia energię per request, a tym samym carbon i water footprint; bardziej efektywny runtime JS = mniej cooling wastewater

Metodologia

Algorytm SFCM:

• Populacja: zbiór ważnych planów scheduling (lokalizacja kontenerów) + autoscaling (CPU, memory per kontener)
• Local Search: add/remove/shuffle kontenerów dla losowego function ID; accepts jeśli weighted sum objectives lepsza
• EA Model: crossover par (searched + unsearched) → offsprings; zastąp dominowane punkty; reset search history dla zastąpionych
• Search History: boost local search przez preferencje dla frequently-updated points; przeskakiwanie z local optima przez EA

Model carbon+wastewater (bazuje na SHIELD [ref 8]): carbon z elektryczności generation + potable water production + wastewater treatment; wastewater z cooling evaporation + thermal hotspots.

Hardware: 50 węzłów, 2× AMD EPYC 7713 (64 cores) = 128 cores/node, 256GB RAM.

Workload: Azure Function Trace 2020 — 424 unique function IDs, 15-min epoki, 90% funkcji executes <30s, 13–62 function IDs per epoch.

Baselines: SCORE (Kubernetes scoring, [ref 9]), HYBRID (hybryda VMs+containers, IEEE TEVC 2012, [ref 10]).

Główne Koncepcje

• SFCM: Sustainable FaaS Cloud Management; populacja + local search + EA + search history; 3 objectives: SLO/carbon/water
• SFCM warianty: SFCM-SLO (minimalizacja SLO), SFCM-Carbon, SFCM-Water, SFCM-Balance (weighted sum wszystkich 3)
• Wastewater model: cooling evaporation + thermal hotspot impact; woda ≠ energia; różne geograficzne i czasowe profile
• Relacja SFCM ↔ CASA: CASA (IGSC 2024) = dual-objective (SLO + carbon) z heuristic-switching; SFCM = trzy cele + EA; ten sam zespół, rozszerzony framework

Wyniki

vs HYBRID baseline: SFCM-Balance redukuje o 45% SLO violations, 25% carbon, 26% water.

Przydatne Cytaty

“Energy usage does not directly correlate to carbon or water emissions.” (str. 1)

“SFCM provides a diverse set of solutions, many of which dominate the solutions produced by state-of-the-art FaaS scheduling frameworks.” (str. 2)

“SLO-focused FaaS scheduling can exacerbate water use in a datacenter.” (Abstract)

Datasety

• Azure Function Trace 2020 — 2-tygodniowy trace Microsoft Azure, 424 unique function IDs, 15-minutowe epoki; ten sam zbiór co w CASA

Powiązane Tematy

• Fundamentalna luka dla JE: SFCM optymalizuje scheduling (kiedy/gdzie uruchomić), nie wybór runtime (czym uruchomić) — bardziej efektywny runtime JS redukuje energy per request, co bezpośrednio przekłada się na mniejsze carbon + mniejsze wastewater (cooling); nowy wymiar JE: JS runtime selection wpływa na trójkę (carbon, water, SLO) jednocześnie
• Powiązane z CASA (su-casa-slo-carbon-serverless-2024) — ten sam zespół, ta sama platforma (CSU + HPE Labs), rozszerzenie o wastewater
• SHIELD [ref 8] (Qi et al., IGSC 2023) — poprzednik SFCM dla ogólnych data centers; wastewater model source
• GreenCourier [ref 1] (Chadha 2023) — geo-spatial carbon shifting FaaS; SFCM nie wymaga migracji między DC (brak latency penalty)
• Raspberry Pi testbed + water scarcity + edge computing: edge FaaS z małymi JS runtimeami = potencjalnie zerowe wastewater (powietrzne chłodzenie) — dodatkowa motywacja dla JE-4

Notatki