Pobierz PDF

Energy Efficient Scheduling for Serverless Systems

Metadane

• Autorzy: Michail Tsenos, Aristotelis Peri, Vana Kalogeraki
• Afiliacja: Department of Informatics, Athens University of Economics and Business, Greece
• Rok: 2024
• Źródło: arXiv:2410.06695 (preprint, Oct 2024)
• Status: read
• Kategoria: Systems
• Tagi: #serverless #faas #energy-efficiency #scheduling #dvfs #cpu-frequency #slo #queuing-theory #project/js-runtime-energy

Streszczenie

EES (Energy Efficient Scheduler) to scheduler FaaS minimalizujący zużycie energii klastra serwerless poprzez DVFS (Dynamic Voltage and Frequency Scaling) przy jednoczesnym zachowaniu SLO funkcji. Kluczowa motywacja: obniżenie częstotliwości CPU z 4.0→3.6 GHz zwiększa czas wykonania tylko o 10%, ale redukuje energię o 22.5% — fundamentalny trade-off. W środowisku multi-tenant FaaS ten trade-off jest trudny, bo różne funkcje na tym samym serwerze dzielą częstotliwość CPU.

System składa się z dwóch komponentów: PMSU (Processor Management and Scheduling Utility — dynamicznie ustawia częstotliwość CPU i przypina kontenery do konkretnych rdzeni) oraz EES (Energy Efficient Scheduler — wybiera węzły dla kontenerów i optymalne konfiguracje <GHz, repliki> bazując na historycznych danych profilu i modelu kolejkowym M/M/c).

Ewaluacja na 7-węzłowym klastrze Intel i7-7700 (4.2GHz max, 65W TDP) z workloadami Go/Python (Sha256, Linpack, Cars-YOLOv5, Pdf): EES osiąga 14–28% oszczędności energii vs Baseline Performance (BP) przy zachowaniu tej samej lub lepszej wydajności. Baseline Powersave (Linux powersave governor) osiąga gorsze wyniki niż EES — niekompatybilność z CPU lub auto-override przez hardware.

Kluczowe Wnioski

• 22.5% oszczędności energii za 10% spowolnienie: główna motywacja DVFS w serverless; zależy od kształtu krzywej energy×frequency dla danego workloadu
• Podobne CPU utilization = podobna energia: empiryczne założenie systemu; funkcje z podobnym %CPU mają zbliżone profile energetyczne — podstawa profiler-based scheduling
• Linux Powersave governor jest nieprzewidywalny: ustawia min freq ale CPU automatycznie przeskakuje do >3GHz — OS-level DVFS nie działa w praktyce dla FaaS; potrzebny application-aware DVFS
• Cold start minimalna zależność od częstotliwości: Linpack +260ms przy min freq, pozostałe funkcje minimalna zmiana — cold start jest I/O-bounded (HDD) nie CPU-bounded; na SSD/NVMe różnica byłaby jeszcze mniejsza
• Noisy Neighbor problem rozwiązany przez cpuset: przypisanie kontenerów do dedykowanych rdzeni CPU stabilizuje wydajność w multi-tenant środowisku
• Fundamentalna luka dla JE: EES zakłada że funkcje o podobnym CPU utilization mają podobną energię — ignoruje fakt, że różne JS runtimes (Node.js V8 vs Deno V8 vs Bun JavaScriptCore) przy tej samej CPU utilization mogą mieć różne profile energy×frequency ze względu na JIT compilation overhead i GC
• DVFS różnie wpływa na JIT runtimes: wyższe CPU frequency może być proporcjonalnie bardziej opłacalne dla V8 (JIT compilation zysk) niż dla Bun (JavaScriptCore AoT-like) — niezadana hipoteza

Metodologia

Hardware: 7 × Intel Core i7-7700 (4 cores, 3.6GHz base, 4.2GHz Turbo, 65W TDP, 16GB RAM), Ubuntu 20.04 LTS, Linux Kernel 5.15, HDD (nie SSD), Hyper-Threading wyłączony, sieć 1Gbps.

Stack: OpenFaaS templates → Docker containers, Mesosphere Marathon 1.5 + Apache Mesos 1.9 jako orchestrator, Java HTTP reverse proxy jako gateway, Prometheus + Grafana do monitoringu.

Pomiar energii: RAPL (Debian package rapl) — odczyt aktualnego zużycia energii CPU w czasie rzeczywistym, raportowany do Prometheus.

Model kolejkowy: M/M/c z Poisson arrivals — wyznacza minimalną liczbę replik c_i per konfiguracja GHz tak aby ρ_i < 80%. Następnie wybiera <GHz, c_i> minimalizujące enrgCost_i × c_i.

Scheduling greedy:

• Low-Load: dopasuj do węzłów z pasującą częstotliwością → empty nodes z ustawioną częstotliwością
• High-Load: sortuj węzły po impact factor (koszt zmiany freq) → deploy do najmniejszego impact

Workloady: Cars (Python, YOLOv5, CPU+I/O), Sha256 (Go, CPU), Linpack (Python, Very High CPU), Pdf (Python, I/O-medium). Ruch generowany z Azure Function Trace (request rates), Poisson(λ=0.05).

Główne Koncepcje

• EES: Energy Efficient Scheduler — wybór węzłów i konfiguracji <GHz, repliki> dla minimalizacji energii przy zachowaniu SLO
• PMSU: Processor Management and Scheduling Utility — dynamiczne ustawianie freq CPU (cpupower), przypinanie kontenerów do CPU rdzeni (cpuset), pomiar energii (RAPL), raportowanie do Prometheus
• DVFS w multi-tenant FaaS: jeden node, wiele funkcji — zmiana freq wpływa na wszystkie; challenge: SLO violation jednej funkcji może spowodować freq increase szkodzący energetycznie innym
• Profile Run: gdy brak historycznych danych, uruchom profil i dopasuj do funkcji z podobnym CPU utilization; throughput curve jest proporcjonalnie przesunięta
• Impact Factor: w High-Load, koszt zmiany freq per węzeł = (nowa_freq − stara_freq) × czas × moc_delta

Wyniki

EES: 28% oszczędności vs BP, 14% vs BPS. Przy tym EES używa mniej replik dzięki efektywniejszemu schedulingowi.

Wpływ DVFS na cold start:

• Cars, Sha256, Pdf: minimalny wzrost czasu cold start przy niskiej freq
• Linpack: +260ms (CPU-bound cold start, większy impact niż I/O-bound)

Przydatne Cytaty

“By reducing the CPU frequency from 4.0GHz to 3.6GHz we increase the execution time by 10%, but we also reduce the energy consumption by 22.5%.” (str. 2)

“Functions with similar CPU utilization have similar energy consumption.” (str. 4 — podstawowe założenie profiler-based podejścia)

“As we can observe, the average cold-start delay slightly increased with the lower CPU frequency with the exception of Linpack which increased by 260ms.” (str. 8)

“The Linux Powersave governor leads to unpredictable behaviour in the majority of the workloads.” (str. 8)

Datasety

• Azure Function Trace 2020 — używany do wyboru request rates dla workloadów testowych (nie do pełnej analizy trace’ów)
• Custom cluster measurements — profil energii Intel i7-7700 dla Sha256, Linpack, Cars, Pdf przy różnych częstotliwościach

Powiązane Tematy

• Fundamentalna luka dla JE: EES zakłada similar CPU utilization → similar energy — JS runtimes falsyfikują to założenie (V8 vs JavaScriptCore mogą mieć różne kształty krzywej energy×frequency przy tej samej CPU utilization); DVFS-aware JS runtime selection to niezbadany obszar
• DVFS i JIT runtimes: V8 (Node.js/Deno) intensywnie korzysta z JIT compilation podczas warm-up — czy wyższe CPU frequency jest proporcjonalnie bardziej opłacalne dla V8 niż dla Bun (szybszy JIT = mniejsze E_total przy danej częstotliwości)? Bezpośrednie rozszerzenie EES Scaling Component
• cpuset jako rozwiązanie Noisy Neighbor — bezpośrednia relevancja dla JE-1 (izolacja pomiarów energii JS runtimeów w środowisku multi-tenant)
• RAPL (cpupower) jako narzędzie pomiarowe — używane w PMSU do real-time energy monitoring; analogia do PowerJoular w JE-1 metodologii
• PMSU + Prometheus pipeline = wzorzec monitoringu energii per container; adaptowalne do pomiarów energii JS runtimeów w OpenFaaS

Notatki