Pobierz PDF

CASA: A Framework for SLO and Carbon-Aware Autoscaling and Scheduling in Serverless Cloud Computing

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:2409.00550; IEEE IGSC 2024 (15th International Green and Sustainable Computing Conference)
• arXiv: 2409.00550
• Status: read
• Kategoria: Systems
• Tagi: #carbon-awareness #serverless #faas #scheduling #autoscaling #slo #dual-objective-optimization #project/js-runtime-energy

Streszczenie

CASA to framework do jednoczesnej optymalizacji dwóch antagonistycznych celów w klastrze FaaS: (1) SLO violation rate (minimalizacja opóźnień i cold startów poprzez utrzymywanie więcej kontenerów) oraz (2) operational carbon emissions (redukcja zużycia energii przez konsolidację kontenerów). Kluczowa obserwacja: te dwa cele są ze sobą sprzeczne — SLO optimization wymaga rozproszenia kontenerów, carbon optimization ich konsolidacji.

CASA rozwiązuje ten konflikt przez dual-objective optimization z heuristic-switching: framework naprzemiennie stosuje SLO optimizer (local search minimalizujący naruszenia SLO) i Carbon optimizer (local search minimalizujący emisje), przełączając się gdy jeden cel zostanie spełniony lub gdy grozi wpadnięcie w lokalne optimum. Blacklist mechanism zapobiega powtórnemu przeszukiwaniu tych samych punktów. Autoscaling dynamicznie skaluje zasoby kontenerów (CPU, DRAM) w czasie trwania epoki.

Wyniki: CASA redukuje carbon emissions o do 2.6× i SLO violation rate o do 1.4× wobec state-of-the-art przy różnych skalach klastra (2–32 węzłów) i intensywnościach workloadu (5×–40× Azure trace).

Kluczowe Wnioski

• SLO vs Carbon są antagonistyczne: SLO optimizer zwiększa liczbę kontenerów → wyższe emisje; Carbon optimizer konsoliduje → więcej cold startów i SLO violations
• Switching mechanism unika local optima: naprzemienne przełączanie między optymalizatorami pozwala eksplorować szerszą przestrzeń decyzyjną
• Carbon intensity zmienia się godzinowo: Tampa, FL: dzień (high CI) vs noc (low CI) — scheduler powinien uwzględniać temporal variation
• ~50% energii to idle resources: przy keep-alive kontenerów — fundamentalny koszt serverless
• Power model jest polynomial (AMD EPYC 7713): P_i = AU_i^4 + BU_i^3 + CU_i^2 + DU_i + E — nieliniowe skalowanie energii z CPU usage
• Fundamentalna luka dla JE: CASA zakłada że energia kontenera zależy wyłącznie od CPU utilization (power model) — nie uwzględnia, że różne JS runtimes przy tej samej utilization mają różne energy footprints (JIT, GC, heap)
• RL baseline (Q-learning) nie skaluje do 16+ węzłów (Q-table explosion) — CASA z local search jest skalowalny do 32 węzłów

Metodologia

Symulator: Python-based FaaS cluster simulator oparty na Azure Function Trace [Shahrad 2020]. Hardware: AMD EPYC 7713 (128 cores, 64GB DRAM). Kontener baseline: 2 CPU cores + 150MB DRAM.

Power model: pomiary rzeczywiste na EPYC 7713, polynomial regression dla P_i vs core usage U_i. Cooling model: P_cooling = E_t × P_IT gdzie E_t = cooling efficiency at solar time t.

Carbon model: CI z danych Tampa FL, hourly variation. CA = Σ CI_h × (P_IT,h + P_cooling,h). Uwzględnia water cooling carbon (CO_water = I_t × P_cooling).

Epoki: 15-minutowe; workload forecast 3 min przed epoką. Azure trace subsets: 5×, 10×, 20×, 40× intensity.

Główne Koncepcje

• CASA: dual-objective framework; SLO optimizer + Carbon optimizer + Autoscaler; naprzemienne switching z blacklistami; iteracja ceiling gen zapewnia real-time decisions
• SLO Optimizer: local search sortuje funkcje po liczbie naruszeń; shuffle container distribution; blacklist B_SL zapobiega local optima
• Carbon Optimizer: local search sortuje funkcje po request intensity (wyższy request = więcej carbon); shuffle + consolidate; blacklist B_AC
• Deadline Laxity: Laxity = (T_deadline − T_arrival) / T_ave — im wyższe, tym więcej czasu na oczekiwanie/migrację bez SLO violation
• SLO Violation Rate: SL_{f,e} = V_{f,e} / N_{f,e} — dla każdej funkcji f i epoki e
• Cold-start latency model: T_cold = C_cold / B_node + NH × T_switch — uwzględnia congestion sieci gdy wiele kontenerów startuje jednocześnie

Wyniki

vs Score: 1.9× niższe carbon, 1.9× niższy koszt, 1.6× niższy system load. Przy 32 węzłach: 2.6× niższe carbon i 1.4× mniej SLO violations vs RL (best SOTA).

Przydatne Cytaty

“All of these performance-first serverless schedulers lack the focus on energy efficiency, making it difficult to maintain sustainability goals.” (str. 2)

“Energy consumption does not always correlate with the carbon emissions of datacenters because other carbon-related factors must be considered such as the carbon intensity of the energy grid.” (str. 2)

“To co-optimize these two conflicting objectives (carbon emissions and SLO violation rate), we propose a novel dual-objective framework.” (str. 1)

Datasety

• Azure Function Trace 2020 — baseline workload: 424 unique function types, 15-min epoch analysis; subsets 5×–40× intensity
• Alibaba Cloud Trace [Wang et al. 2021] — wzorzec workload patterns (szybkie zmiany request intensity: 0×–13× w 15 min)
• Huawei Cloud Trace [Joosen et al. 2023] — wzorzec workload patterns

Powiązane Tematy

• Fundamentalna luka dla JE-7: CASA optymalizuje kiedy i gdzie uruchomić funkcję, nie jak efektywnie runtime ją wykonuje; rozszerzenie: runtime-aware carbon scheduling (Bun vs Node.js jako różne energy-per-CPU-cycle)
• Power model polynomial P = f(U) mógłby być kalibrowany oddzielnie dla Node.js/Deno/Bun (różne energy przy tej samej CPU utilization ze względu na JIT/GC)
• Wiesner 2021 (temporal shifting) + GreenWhisk (spatial shifting) + CASA (local scheduling) = komplementarne podejścia; JS runtime awareness rozszerza wszystkie trzy
• Scaling waste jest centralnym problemem — analogia do Werner 2025 RE metric

Notatki