Pobierz PDF

A Comprehensive Experimentation Framework for Energy-Efficient Design of Cloud-Native Applications

Metadane

• Autorzy: Sebastian Werner, Maria C. Borges, Karl Wolf, Stefan Tai
• Rok: 2025
• Źródło: 22nd IEEE International Conference on Software Architecture (ICSA’25), preprint
• arXiv: 2503.08641
• Status: read
• Kategoria: Systems
• Tagi: #energy-efficiency #cloud-native #serverless #kubernetes #benchmarking #measurement-methodology #rapl #kepler #scaphandre #microservices #icsa #project/js-runtime-energy

Streszczenie

Autorzy prezentują CLUE (Cloud-native Sustainability Evaluator) — zautomatyzowany, rozszerzalny framework do benchmarkowania efektywności energetycznej aplikacji cloud-native opartych na Kubernetes. Motywacją jest luka w narzędziach developerskich: dashboardy dostawców chmurowych oferują tylko zgrubne dane o zużyciu energii (np. miesięczne średnie Google), a istniejące eksperymenty skupiają się na izolowanych komponentach (CPU utilization), pomijając złożoność wielowarstwowych stacków cloud.

Framework mierzy energy trade-offs na wszystkich warstwach stosu (Application, Service, Platform, Isolation, Physical) jednocześnie, porównując alternatywne decyzje architektoniczne dla tej samej aplikacji. CLUE integruje Prometheus, Kepler, Scaphandre oraz zewnętrzne smart plugi (Tapo P115) i obsługuje workloady Locust na Kubernetes. Wyniki są eksportowane jako CSV + raporty seaborn z pełnymi metadanymi reprodukcji.

Showcase przeprowadzono na referencyjnej aplikacji mikrousługowej TeaStore (Java), porównując 5 wariantów: Microservices (baseline), Monolith, Serverless (KNative), Runtime Improvement (GraalVM), Service Reduction. Eksperymenty ujawniły nieoczekiwane zachowania — np. wariant serverless miał WYŻSZE zużycie energii niż bazowy mikrousługowy wbrew oczekiwaniom, co podkreśla konieczność empirycznej weryfikacji taktyk architektonicznych.

Kluczowe Wnioski

• Serverless ≠ bardziej energooszczędny: wariant KNative miał wyższy platform overhead niż baseline microservices — koszty infrastruktury serverless (wiele podów KNative) przekroczyły korzyści ze scale-to-zero; cold starty dla auth functions były główną przyczyną
• GraalVM wygrywa: Runtime Improvement (OpenJDK → GraalVM 17) dał najlepszą latencję (p50: 0.02s vs 0.06s baseline) i najniższe zużycie energii na żądanie — najlepszy stosunek effort-do-zysku
• Monolith: lepsza energia, gorsza jakość: redukcja overhead platformy (~20% mniej), ale katastrofalne failure rate przy stress teście; dobre dla niskiego ruchu, złe dla spiked workloadów
• Mierzenie na jednej warstwie jest niewystarczające: narzędzia jak Kepler i Scaphandre wciąż wykazują rozbieżności z zewnętrznymi miernikami mocy — konieczna walidacja krzyżowa
• Workload ma kluczowe znaczenie: efekty taktyk różnią się znacząco między workloadami (fixed/pausing/stress/shaped) — ta sama taktyka może być dobra przy niskim ruchu i zła przy stress

Metodologia

Eksperyment na self-hosted Kubernetes (v1.28): 4x KVM VM + 2x bare-metal (AMD Ryzen 5 3600, Intel i7-6700K), wszystko x86 Linux. Pomiary energii na poziomie izolacji: Scaphandre (RAPL via qemu na VM), Kepler (RAPL + IPMI na bare-metal), Tapo P115 (total host power). Wszystkie metryki agregowane w Prometheus.

Dla każdego z 5 wariantów × 4 workloadów × 4 repetycji (= 80 przebiegów), czas 15 min każdy. Automatyczne czyszczenie danych i powtarzanie przy błędach. Metryki WR obliczane jako całkowita energia Kepler / liczba udanych żądań Locust.

Główne Koncepcje

• CLUE (Cloud-native Sustainability Evaluator): framework Runner (Builder + Deployer + Workload Generator) + Observer (Collector + Aggregator) + Exporter (Metrics Calculator + Report Generator); open source: https://github.com/ISE-TU-Berlin/Clue
• WR (Request Consumption [Ws]): energia per żądanie — obejmuje runtime aplikacji i framework, wyklucza overhead platformy (Kubernetes)
• RO (Runtime Overhead [0..1]): procent zasobów zużytych przez overhead platformy (Kubernetes, KNative) w stosunku do zasobów SUT
• RU (Resource Utilization [0..1]): faktyczne użycie vs. provisioned resources
• RE (Resource Efficiency [Ws]): energia zmarnowana przez nieefektywne skalowanie (over/under-provisioning)
• Architectural Tactics: >160 zidentyfikowanych taktyk architektonicznych dla efektywności energetycznej; taktyki CLUE ewaluuje empirycznie: T:Choose Efficient Runtime, T:Apply Granular Scaling, T:Reduce Overhead by Removing Intermediaries, T:Adopt Use-case Driven Design
• Kepler: energia kontenerów via RAPL/IPMI/CPU-based estimation; wspiera Kubernetes natively
• Scaphandre: energia hosta via RAPL; obsługuje virtualized environments (qemu) — path dla cloud vendorów

Wyniki

Zużycie energii per request (WR): Runtime Improvement najlepszy we wszystkich workloadach. Serverless najgorszy dla shaped/pausing (dużo idle overhead). Scaling waste (RE): serverless ma największe marnotrawstwo przy niskim ruchu z powodu cold starts i over-provisioned KNative pods.

Przydatne Cytaty

“The tactic that motivated the serverless variant (Apply Granular Scaling) might work, however, only if the system providing this fine granularity is not consuming more energy than a less granular scaling alternative.” (str. 9)

“We found that the change in runtime strongly improved performance […] and lower energy consumption per request […]. We did not detect the introduction of any obvious errors, with the failure rate instead improving, likely due to fewer performance bottlenecks.” (str. 9 — o GraalVM)

“Assessments should be done for the entire application, instead of using focused micro-benchmarks or theoretical settings, enabling developers to start building leaner applications today.” (str. 3)

“Sometimes, Kepler would report almost no consumption data, even though the external power meter showed a change in energy consumption.” (str. 9 — ograniczenie narzędzi)

Datasety

• Brak publicznego datasetu; surowe dane eksperymentalne w repozytorium CLUE: https://github.com/ISE-TU-Berlin/Clue
• TeaStore: referencyjny benchmark mikrousługowy używany jako SUT

Powiązane Tematy

• Kepler i Scaphandre jako narzędzia pomiarowe RAPL dla kontenerów → linkuje z #JE-3
• Runtime energy: GraalVM vs OpenJDK → gap dla Node.js/Deno/Bun (analogia: JVM versions ↔ JS runtimes)
• Serverless platform overhead > scale-to-zero benefits → implikacja dla JE-EXP dotyczących Serverless JS
• CLUE jako wzorzec metodologiczny dla własnych eksperymentów porównawczych
• CI/CD integration dla ciągłego monitorowania sustainability → przyszły kierunek

Notatki