Pobierz PDF

FaasMeter: Energy-First Serverless Computing

Metadane

• Autorzy: Abdul Rehman, Alexander Fuerst, Prateek Sharma
• Rok: 2024
• Źródło: arXiv:2408.06130 (Indiana University)
• arXiv: 2408.06130
• Status: read
• Kategoria: Systems
• Tagi: #energy-efficiency #serverless #faas #measurement-methodology #power-monitoring #kalman-filter #shapley-values #rapl #disaggregation #project/js-runtime-energy

Streszczenie

FaasMeter to system sterowania FaaS (Functions as a Service) traktujący energię jako zasób pierwszej klasy — obejmujący monitorowanie, rozliczanie, kontrolę i wycenę energii. Autorzy twierdzą, że jest to pierwsza praca poświęcona energetycznemu profilowaniu funkcji FaaS. Kluczowe wyzwanie to disagregacja energii z zaszumionego, gruboziarnistego systemu pomiarów mocy wśród dziesiątek lub setek współbieżnych, heterogenicznych funkcji o bardzo krótkim czasie życia (<1s).

Metodologia opiera się na trzech komponentach: (1) statystycznej disagregacji z użyciem regresji liniowej na próbkach czasowych, (2) filtrze Kalmana do ciągłej aktualizacji szacunków przy zmieniających się workloadach, oraz (3) wartościach Shapleya do sprawiedliwego podziału energii zasobów współdzielonych (control plane, idle power). Zintegrowany z control plane Ilúvatar (open source, Rust+Python, ~6000 LOC), FaasMeter osiąga dokładność 98.4–99.8% cosine similarity z marginalną energią jako ground truth.

Kluczowy wniosek metodologiczny: istniejące narzędzia jak Scaphandre (RAPL-based, CPU-only) są nieodpowiednie dla FaaS — działają tylko na x86, mają overhead 5% CPU własnego, błąd 100–130% dla funkcji disk-intensive (dd), i nie radzą sobie z ARM (Jetson). Nowe metryki walidacyjne autorów (individual-difference, cosine-similarity, total-error, latency-normalized-variance) stanowią benchmark dla oceny przyszłych narzędzi energetycznych.

Kluczowe Wnioski

• Scaphandre jest nieodpowiedni dla FaaS: CPU-only, błąd 10–23× na serwerze, overhead >5%, nie działa na ARM — wyniki w projektach porównawczych runtimeów JS należy krytycznie oceniać jeśli używają Scaphandre
• Energetyczne profilowanie w izolacji jest wadliwe: footprint funkcji zmienia się >10× w zależności od obciążenia serwera — niezbędna jest metoda marginalnej energii lub statystyczna disagregacja
• Marginal energy (T(S) − T(S−f)) / invocations = właściwy ground truth dla funkcji FaaS; eliminuje problem różnych stanów mocy CPU
• Energia ≠ inne metryki: wysoka wariancja, zależność od stanów mocy sprzętu (CPU frequency, idle states) czyni ją wyjątkowo trudną do pomiaru w porównaniu z latencją
• Kalman filter radzi sobie z non-stationarity workloadów FaaS — analogicznie do JIT warm-up w JS runtimeach (#JE-3)
• Koszty keep-alive (memory footprint sandboxed containers) wykraczają poza czas wykonania i muszą być modelowane osobno
• Azure Function Trace: inter-arrival times 0.01s–1 dzień, execution 0.1s–100s, heavy-tailed — JS API workload jest reprezentatywny

Metodologia

Hardware: 3 platformy: Server (2× Xeon Platinum 8160, 96 cores, idle 95W), Desktop (Intel i5-12500, idle 15W, external meter Instek GPM-8310), Edge (Nvidia Jetson Orin AGX, CPU+GPU). Moc mierzona: IPMI/BMC (serwer), plug-level meter (desktop, 0.25s), tegrastats + external meter (Jetson), RAPL (perf, wszystkie x86).

Disagregacja: okno δ=1s, macierz kontrybucji C (M funkcji × N próbek) z czasy wykonania jako proxy; regresja liniowa min||CX−W||. Szacowanie control plane przez normalizację CPU%. Kalman filter: α=0.8, β=0.2, γ=0.1, okno inicjalne 100s, następnie 60s.

Walidacja: Azure function traces z funkcjami z FunctionBench. >100 śladów workloadów na 3 platformach. Warm starts (>99%, wystarczający keep-alive cache). Cold starts tagowane osobno.

Główne Koncepcje

• FaasMeter: control plane FaaS + energy profiler; integracja z Ilúvatar; pipeline: power sources → statistical disaggregation + Kalman → Shapley attribution → energy footprints → capping/pricing
• Statistical Disaggregation: min||CX−W|| gdzie C=czasy wykonania funkcji, W=moc systemu; δ=1s kompromis między szumem a rzadkością macierzy
• Kalman Filter dla FaaS: ciągła aktualizacja footprintów z uwzględnieniem wariancji latencji funkcji (σ(T)) i liczby wywołań (A) — kluczowe dla non-stationary workloadów
• Shapley Values dla fair attribution: idle power → równy podział; control plane energy → proporcjonalnie do invocation frequency; J_total = J_indiv + φ_cp + φ_idle
• Marginal Energy (Mf): różnica całkowitej energii workloadu z/bez funkcji f, podzielona przez liczbę wywołań — gold standard walidacji; eliminuje wpływ idle power
• Cosine Similarity (J·J*/||J||·||J*||): primary external validity metric — mierzy proporcje footprintów, nie wartości bezwzględne; FaasMeter: 0.984–0.998 vs Scaphandre: 0.623–0.910
• Latency-Normalized Variance σ(J)/σ(T): metryka stabilności wyceny energetycznej; <40 dla 90% workloadów = porównywalne z wariancją wyceny opartej na latencji
• Ilúvatar: open source FaaS control plane (Rust), 50–100× niższa wariancja latencji niż OpenWhisk — lepsze środowisko testowe dla JS runtimeów

Wyniki

Dokładność FaasMeter (cosine similarity vs marginal energy):

Energie per invokację (Desktop, funkcje reprezentatywne):

• dd (I/O, 0.7s): 16.0J (ground truth) → FaasMeter: ~16J; Scaphandre: ~0J (nie widzi I/O)
• AES (CPU, 1.4s): 21.3J → FaasMeter: ~21J; Scaphandre: ~20J
• CNN (CPU heavy, 1.3s): 37.0J → FaasMeter: ~38J; Scaphandre: ~28J (underestimates)

Power capping: overshoot <3%. Total-Error <10% dla >50% workloadów. CoV (σ(J)/E[J]) <0.3 na wszystkich platformach dla 60% traces → stabilność wyceny.

Przydatne Cytaty

“Existing power profiling tools, such as Scaphandre, PowerAPI, and others are not suitable for FaaS workloads and have many shortcomings. They rely on CPU power measurements (e.g., RAPL) and do not consider system-wide energy; do not account for shared resources; do not scale well to large number of concurrent functions.” (str. 2)

“Measuring energy in isolation is not suitable as a validation approach for function-level profiling, and additional metrics and validation methodology is needed.” (str. 6)

“Using noisy system-level power is one of FaasMeter’s main features, and these results illustrate its robustness and accuracy. It provides more than an order of magnitude accuracy compared to existing process and CPU based tools.” (str. 13)

“FaasMeter only considers server-level power. Shared FaaS components such as networking and storage hardware may be divided using our fair division policies. The energy costs of keep-alive may also be considered as a separate component in the footprint.” (str. 15 — ograniczenia)

Datasety

• Azure Function Trace 2020 — workloady FaaS: heavy-tailed IAT (0.01s–1dzień), execution time (0.1s–100s); mapped to FunctionBench
• FunctionBench — benchmark workloadów serverless: dd, image, video, AES, json, CNN, ml_train

Powiązane Tematy

• Scaphandre nieodpowiedni dla FaaS → implikacja dla JE-3: potrzeba metodologii wykraczającej poza CPU-only RAPL
• Marginal energy jako właściwy ground truth → adoptować do porównania runtimeów JS w JE-1 i JE-3
• Kalman filter dla non-stationary → analogia do JIT warm-up i GC pauses w Node.js/V8 (#JE-3)
• FunctionBench workloady (dd, AES, json, CNN) → wzorzec dla JS runtime benchmark suite (#JE-8)
• Keep-alive energy modeling → wchodzi w skład JE-6 (cold start vs keep-warm energy)
• [82] Wagner et al. 2023 “Energy Consumption of WebAssembly Binaries in IoT” — bezpośrednio powiązany z JE-4

Notatki