Wir haben horizontal auf 50 Instanzen skaliert. Der Engpass ist nur weitergewandert.

Phase 1: Engpass in der Anwendung

  • 5 App-Server, 100% CPU
  • Lösung: Auf 20 Server skalieren
  • Ergebnis: App-CPU 30%

Phase 2: Engpass in der Datenbank

  • Datenbank: 100% CPU, 5000 Verbindungen
  • Lösung: Connection Pooling, Read Replicas
  • Ergebnis: Datenbank-CPU 60%

Phase 3: Engpass im Load Balancer

  • Die ALB-Skalierung hinkte einem steilen Traffic-Spike hinterher — ALBs skalieren automatisch über LCUs, aber nicht sofort, und unser Spike war schneller
  • Lösung: vor bekannten Traffic-Events vorskaliert (in Abstimmung mit dem AWS Support) und den spitzenlastigsten internen TCP-Traffic auf einen NLB verlegt
  • Ergebnis: Traffic verteilt

Phase 4: Engpass in der Message Queue

  • RabbitMQ-Einzelknoten gesättigt
  • Lösung: Geclusterte Queue, partitionierte Topics
  • Ergebnis: Nachrichten fließen

Die Lektion:

Theory of constraints, applied to systems:

System throughput = min(
    app_capacity,
    db_capacity,
    network_capacity,
    queue_capacity,
    external_api_capacity
)

Was wir gelernt haben:

  • Den Engpass VOR dem Skalieren identifizieren
  • Den gesamten Pfad lasttesten
  • Alle Komponenten überwachen, nicht nur die Apps
  • Manchmal ist vertikales Skalieren günstiger

Lasttests über den gesamten Pfad — vom Client bis zur Datenbank und zurück, nicht nur die App-Schicht — sind eine Standardübung in unseren DevOps-Engagements, denn die Komponente, die Sie nicht getestet haben, ist die, in der der nächste Engpass sitzt.

Lektion: Eine Komponente zu skalieren verschiebt den Engpass zur nächsten. Planen Sie die Kapazität Ende-zu-Ende.

← Zurück zu Lessons Learned

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers auf dem Pager — damit Geschichten wie diese im Archiv bleiben.

Tags: #Skalierung #Performance #Engpass #Architektur