Seminar NestJS – Performance, Observability und Deployment

Performanceprobleme entstehen häufig außerhalb des offensichtlichen Codes: übermäßige Datenbankzugriffe, große Serialisierung, blockierende Arbeit, unkontrollierte Parallelität oder falsch dimensionierte Laufzeitgrenzen. Optimierung ohne Messung verschiebt solche Probleme nur.

Der Kurs verbindet Messung, Instrumentierung und Bereitstellung. Ein Dienst wird unter reproduzierbarer Last untersucht, gezielt optimiert, mit Telemetrie ausgestattet und anschließend kontrolliert ausgerollt sowie zurückgenommen.

Inhaltsübersicht

• Lernziele
• Messmodell und reproduzierbare Baseline
• Engpassanalyse und gezielte Optimierung
• Logging, Metriken und Tracing
• Health Checks und kontrolliertes Deployment
• Praxisprojekt: Analyse und Rollout eines API-Dienstes
• Prüfpunkte und typische Fehler

Lernziele

• Repräsentative Lastprofile, Baselines und messbare Performanceziele definieren.
• CPU-, Speicher-, Event-Loop-, Datenbank- und Serialisierungsengpässe eingrenzen.
• Strukturierte Logs, Metriken, Traces und Korrelationsdaten konsistent implementieren.
• Liveness, Readiness, Startup und Abhängigkeitsprüfungen korrekt trennen.
• Container, Ressourcenlimits, Konfiguration, Secrets und Shutdown-Verhalten gestalten.
• Rollout, Smoke Tests, Beobachtungsschwellen und Rollback ausführen.

Messmodell und reproduzierbare Baseline

Eine belastbare Analyse beginnt mit einem festen Lastprofil und klaren Zielgrößen. Durchschnittswerte allein reichen nicht; Verteilung, Sättigung und Fehlerzustände müssen sichtbar sein.

1. Kritische Nutzerabläufe, Datenmengen, Parallelität und Zielantwortzeiten festlegen.
2. Testdaten und Umgebung reproduzierbar vorbereiten.
3. Baseline für Durchsatz, Perzentile, Fehlerquote, CPU, Speicher und Event-Loop-Verzögerung erfassen.
4. Datenbankabfragen, externe Aufrufe und Serialisierungszeiten getrennt messen.
5. Warmup, Cache-Zustand und Messdauer kontrollieren.
6. Messprotokoll mit Version, Konfiguration und Lastparametern speichern.

Entscheidungskriterien und Hinweise

• Vergleichsmessungen verwenden dieselbe Umgebung und dasselbe Lastprofil.
• Perzentile und Fehlerquote werden gemeinsam mit dem Durchsatz bewertet.

Engpassanalyse und gezielte Optimierung

Optimierungen werden einzeln durchgeführt und jeweils gegen die Baseline verglichen. So bleiben Wirkung und Nebenwirkungen nachvollziehbar.

1. Blockierende oder CPU-intensive Arbeit erkennen und aus dem Request-Pfad verlagern.
2. Provider-Scopes, Objektallokationen und große Transformationen prüfen.
3. Datenbank-Roundtrips, N+1-Abfragen, Indizes und Pagination optimieren.
4. Serialisierung und Antwortfelder auf den tatsächlichen Clientbedarf begrenzen.
5. Caching mit Schlüssel, Gültigkeit, Invalidierung und Fehlverhalten definieren.
6. HTTP-Adapter und Kompression anhand realer Payloads bewerten.
7. Parallelität, Connection Pools und Backpressure gemeinsam dimensionieren.

Entscheidungskriterien und Hinweise

• Caching wird erst nach identifiziertem Engpass und mit Invalidierungsstrategie eingesetzt.
• Laufzeitgrenzen werden gemeinsam mit Datenbank- und Netzwerkpools dimensioniert.

Logging, Metriken und Tracing

Logs erklären diskrete Ereignisse, Metriken zeigen Trends und Grenzwerte, Traces verbinden Latenz über Abhängigkeiten. Telemetrie wird an konkrete Betriebsfragen gekoppelt.

1. Korrelations-ID am Eingang übernehmen oder erzeugen und durch alle Schichten weitergeben.
2. Strukturierte Logs mit Ereignisname, Dienstversion, Dauer und Ergebnis erstellen.
3. Sensible Daten, Tokens und große Payloads aus Logs entfernen.
4. Metriken für Request-Rate, Fehler, Dauer, Sättigung, Datenbank und Hintergrundarbeit definieren.
5. Traces für HTTP, Datenbank und externe Aufrufe instrumentieren.
6. Sampling, Kardinalität und Aufbewahrung an Betriebszielen ausrichten.
7. Alarmregeln aus Symptomen und Nutzerwirkung ableiten.

Entscheidungskriterien und Hinweise

• Metrik-Labels enthalten keine ungebremsten IDs oder Freitexte.
• Logs und Traces nutzen dieselbe Korrelation, ohne sensible Inhalte zu vervielfachen.

Health Checks und kontrolliertes Deployment

Health Checks steuern Prozessüberwachung und Traffic-Zuweisung. Zu aggressive Abhängigkeitsprüfungen können gesunde Instanzen unnötig aus dem Verkehr nehmen.

1. Liveness auf interne Prozessfähigkeit begrenzen.
2. Readiness nach tatsächlicher Fähigkeit zur Annahme von Traffic bewerten.
3. Startup-Prüfung für langsame Initialisierung und Migrationen berücksichtigen.
4. Container nicht privilegiert, mit reproduzierbarem Build und externen Secrets ausführen.
5. Ressourcenrequests, Limits, Grace Period und Shutdown-Hooks abstimmen.
6. Rollout mit Readiness, Smoke Test, Telemetrievergleich und Abbruchschwellen absichern.
7. Rollback einschließlich Konfiguration und Datenbankverträglichkeit testen.

Entscheidungskriterien und Hinweise

• Liveness und Readiness prüfen bewusst unterschiedliche Zustände.
• Deployment ist ein kontrollierter Prozess und nicht nur das Starten eines neuen Containers.

Praxisprojekt: Analyse und Rollout eines API-Dienstes

Ein API-Dienst enthält bewusst mehrere Engpässe: N+1-Abfragen, große Antworten, blockierende Transformation und unkontrollierte Parallelität. Die Anwendung besitzt zunächst nur einfache Textlogs und einen unzureichenden Health-Endpunkt.

Nach der Optimierung wird ein Container-Release ausgerollt. Smoke Tests und Telemetrie entscheiden über Fortsetzung oder Rollback; eine fehlerhafte Konfiguration wird gezielt eingebracht.

1. Lastprofil und Baseline mit reproduzierbaren Testdaten erzeugen.
2. Engpass über Messwerte und Traces lokalisieren.
3. Datenzugriff, Serialisierung und Parallelität einzeln optimieren.
4. Strukturierte Logs, Metriken und Tracing mit Korrelationsdaten ergänzen.
5. Liveness-, Readiness- und Startup-Prüfungen getrennt implementieren.
6. Container mit Ressourcen- und Shutdown-Konfiguration bauen.
7. Rollout mit Smoke Tests und Telemetrievergleich durchführen.
8. Fehlerhafte Konfiguration erkennen und kontrolliert zurückrollen.

Prüfpunkte und typische Fehler

• Performanceziele, Lastprofil und Testdaten sind vor der Optimierung festgelegt.
• Jede Optimierung besitzt einen messbaren Vorher-Nachher-Nachweis.
• Metrik-Labels und Logfelder erzeugen keine unkontrollierte Kardinalität.
• Readiness und Liveness prüfen unterschiedliche Zustände.
• Ressourcenlimits passen zu Connection Pools, Parallelität und Shutdown-Zeit.
• Ein Rollout wird bei verschlechterten Nutzerkennzahlen abgebrochen.