Performance- und Ressourcenoptimierung

Bereitstellen von Anwendungen auf AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Langsam und teuer

Die App wirkt bei Traffic-Spitzen langsam
Die Lambda-Rechnung springt im selben Monat
Tuning macht sie schneller und günstiger

Ein Geschwindigkeits- und Kostenmesser zeigt eine langsame und teure Funktion, mit Zeiger Richtung Optimierung

Parallelität: Kosten vs. Cold Start

Reserved: deckeln und schützen

Deckelt und garantiert Kapazität für eine Funktion
Günstigste Steuerung, hilft aber nicht bei Cold Starts

Provisioned: für Wärme zahlen

Hält Instanzen vorgewärmt, kein Cold Start
Teurer; nur dort nutzen, wo Latenz wirklich zählt

Speicher richtig dimensionieren mit der Dauer-Kosten-Kurve

Dauer-Kosten-Kurve bei steigendem Speicher: Dauerkurve fällt und flacht ab, Gesamtkosten bilden eine U-Form, günstigste Speichereinstellung markiert

Mehr Speicher = mehr CPU = kürzere Dauer
Kosten = Speicherpreis × Dauer
Der günstigste Punkt liegt oft mittig
Profiliere bei mehreren Größen, dann wählen

Caching auf Anwendungsebene

Arbeit im Ausführungskontext wiederverwenden
Eine warme Lambda behält Globals zwischen Aufrufen
Konfig, Clients und Hot-Lookups cachen
ElastiCache für einen geteilten Cache über Instanzen

Lambda-Ausführungskontext-Caching: globales Client-Objekt wird über warme Aufrufe wiederverwendet, und ElastiCache-Cluster teilt Hot-Daten über mehrere Funktionsinstanzen

CloudFront-Caching am Edge

CloudFront: Antworten an Edge-Standorten cachen
Wiederholte Anfragen ohne Backend bedienen
Cache-Keys können Header, Query-Strings, Cookies enthalten
Statischer und cachebarer Content skaliert kostenlos

CloudFront Edge-Caching: Globus mit Edge-Standorten, die gecachte Antworten nahe bei Nutzer:innen liefern, ohne das Backend zu treffen, mit Cache-Key-Konfiguration für Header und Query-Strings

Die richtige Cache-Ebene wählen

Drei gestapelte Cache-Ebenen: CloudFront am Edge für statische, weit geteilte Inhalte, In-Memory pro Instanz für Hot-Objekte, und ElastiCache oder DAX für geteilte, häufige Lesezugriffe

Edge (CloudFront): statische, breit geteilte Inhalte
Application (in-memory): pro Instanz Hot-Objekte
Data (ElastiCache/DAX): geteilte Hot-Reads
Stapeln; jede Ebene senkt andere Kosten

Optimierung zusammenführen

Speicher per Dauer-Kosten-Kurve dimensionieren
Provisioned Concurrency nur dort, wo Latenz zählt
Auf Edge-, App- und Daten-Ebene cachen
Messen, eine Sache ändern, erneut messen

Optimierungsübersicht: Dauer-Kosten-Kurve für Speicherdimensionierung, Entscheidung zu Provisioned Concurrency, Diagramm der drei Cache-Ebenen und der Zyklus Messen–Ändern–Messen

Lass uns üben!

Bereitstellen von Anwendungen auf AWS