Automatische ECS-Service-Skalierung und Load Balancing

Eine festgelegte gewünschte Anzahl für einen ECS-Service kann nicht auf Schwankungen im Traffic reagieren – entweder Sie stellen zu viele Ressourcen bereit (und verschwenden Geld) oder zu wenige (und beeinträchtigen die Leistung). ECS Service Auto Scaling passt die gewünschte Anzahl von Tasks automatisch anhand von CloudWatch-Metriken an. Im Hintergrund nutzt der Dienst Application Auto Scaling – dasselbe Framework wie DynamoDB, Aurora und ElastiCache. ECS Service Auto Scaling unterstützt Richtlinien für Target Tracking, Step Scaling und Scheduled Scaling.

Bevor Sie Skalierungsrichtlinien hinzufügen, registrieren Sie den ECS-Service in Application Auto Scaling als skalierbares Ziel. Geben Sie die minimale und maximale Task-Anzahl, den Clusternamen und den Servicenamen als Ressourcen-ID an. Dadurch wird der Bereich festgelegt, innerhalb dessen die automatische Skalierung arbeitet. Die Mindestanzahl stellt sicher, dass immer eine grundlegende Kapazität verfügbar ist; die Höchstzahl verhindert, dass eine unkontrollierte Skalierung die Fargate-Kapazität oder EC2-Instances erschöpft.

Target Tracking ist für die meisten ECS-Services die empfohlene Richtlinie für die automatische Skalierung. Die häufigste Zielmetrik ist ECSServiceAverageCPUUtilization – legen Sie ein Ziel von 50–70 % fest, und ECS fügt Tasks hinzu oder entfernt sie, um diese CPU-Auslastung beizubehalten. Eine weitere leistungsfähige Metrik ist ALBRequestCountPerTarget: Dabei wird die Anzahl der ALB-Anfragen pro Task überwacht und so skaliert, dass eine Zielrate von Anfragen pro Instance beibehalten wird. AWS übernimmt die Auf- und Abwärtsskalierung automatisch und verwendet dafür geeignete Abkühlzeiten.

Wenn Sie einen Application Load Balancer (ALB) mit einem ECS-Service verbinden, wird der HTTP-/HTTPS-Traffic auf alle laufenden Tasks verteilt. Die ALB-Zielgruppe registriert die IP-Adresse jedes Tasks (bei Fargate/awsvpc) oder den Container-Port (im Bridge-Modus). ECS registriert neue Tasks beim Start automatisch in der Zielgruppe und entfernt sie beim Beenden aus dieser. Der ALB führt für jeden Task Health Checks durch; fehlerhafte Tasks werden ordnungsgemäß entleert (Verbindungen werden kontrolliert geschlossen), bevor der Service sie beendet.

Ein besonders leistungsfähiges Muster besteht darin, verschiedene URL-Pfade mithilfe von ALB path-based routing an unterschiedliche ECS-Services weiterzuleiten. Ein einzelner ALB mit einem HTTPS-Listener kann beispielsweise /api/orders/* an den ECS-Service Orders, /api/users/* an den ECS-Service Users und /api/products/* an den ECS-Service Products weiterleiten – jeweils mit einem eigenen ECS-Service und unabhängiger Skalierung. Dadurch werden separate Load Balancer für jeden Microservice überflüssig, was Kosten senkt und die DNS-Verwaltung vereinfacht.

Wenn ein ECS-Task beendet werden soll (während einer Abwärtsskalierung oder eines Deployments), markiert der ALB ihn als draining und leitet keine neuen Anfragen mehr an ihn weiter, lässt jedoch laufende Anfragen noch abschließen. Die deregistration delay (standardmäßig 300 Sekunden, konfigurierbar von 0 bis 3600 Sekunden) gibt an, wie lange der ALB wartet, bevor er Verbindungen zwangsweise schließt. Bei ECS mit kurzen Anfragezeiten sollten Sie eine niedrigere Deregistrierungsverzögerung (30–60 Sekunden) festlegen, um Deployments und Abwärtsskalierungen zu beschleunigen. Für langlebige Verbindungen (WebSockets, Datei-Uploads) sollten Sie eine längere Verzögerung beibehalten.

Über CPU und Arbeitsspeicher hinaus können Sie benutzerdefinierte CloudWatch-Metriken aus Ihrer Anwendung veröffentlichen (z. B. Warteschlangentiefe, aktive Sitzungen oder Geschäfts-KPIs) und damit die Skalierung steuern. Wenn beispielsweise jeder ECS-Task 50 Warteschlangennachrichten gleichzeitig verarbeiten kann, veröffentlichen Sie die Tiefe der SQS-Warteschlange als benutzerdefinierte Metrik und erstellen eine Target-Tracking-Richtlinie mit einem Ziel von 50 Nachrichten pro Task. So wird die Skalierung direkt durch die Geschäftslogik gesteuert, statt sich auf Infrastrukturmetriken zu stützen, die möglicherweise nicht mit der Anwendungslast korrelieren.

Ähnlich wie bei EC2 Auto Scaling unterstützt ECS den Schutz von Tasks vor Abwärtsskalierung. Ein laufender Task kann über die ECS-API selbst ein Schutz-Flag setzen, um während einer Abwärtsskalierung nicht beendet zu werden, solange er einen kritischen Auftrag verarbeitet. Das ist nützlich für ECS-Tasks, die als SQS-Worker fungieren: Ein Worker, der gerade einen langen Auftrag aus der Warteschlange entnommen hat, kann sich selbst schützen, den Auftrag abschließen und den Schutz anschließend wieder aufheben. Ohne diesen Schutz könnte die Abwärtsskalierung einen Task mitten in der Verarbeitung beenden und dadurch doppelte Auftragsausführung oder Datenverlust verursachen.

Wählen Sie Ihre Skalierungsmetrik sorgfältig. CPU-Auslastung ist der Standard und eignet sich für rechenintensive Workloads. Arbeitsspeicherauslastung (ECSServiceAverageMemoryUtilization) ist für speicherintensive Anwendungen hilfreich. Eine Erhöhung des Arbeitsspeichers erfordert jedoch das Hinzufügen von Tasks – wenn Ihr Task durch den Arbeitsspeicher pro Task und nicht durch die Anzahl gleichzeitig verarbeiteter Anfragen begrenzt ist, kann es sinnvoller sein, die Speicherzuweisung in der Task-Definition anzupassen. ALBRequestCountPerTarget korreliert direkt mit der Benutzererfahrung und ist für Web-APIs die aussagekräftigste Metrik: Skalieren Sie anhand der tatsächlichen Anfragerate pro Task.

Der ECS Deployment Circuit Breaker erkennt fehlschlagende Deployments automatisch und führt ein Rollback auf die letzte stabile Version durch. Ohne ihn würde ein fehlerhaftes Deployment (etwa ein Container, der Health Checks nicht besteht) dazu führen, dass ECS unbegrenzt versucht, neue Tasks zu starten. Wenn der Circuit Breaker aktiviert ist und innerhalb eines Erkennungszeitraums ein bestimmter Prozentsatz der neu gestarteten Tasks die Health Checks nicht besteht, markiert ECS das Deployment als FAILED und führt automatisch ein Rollback auf die vorherige Revision der Task-Definition durch. Dadurch werden länger andauernde Beeinträchtigungen des Service durch fehlerhafte Deployments verhindert.

Eine produktionsreife Architektur für eine containerisierte Web-API: Route 53 löst die Domain in den DNS-Namen eines ALB auf; der ALB beendet HTTPS (ACM-Zertifikat), wendet WAF-Regeln an und leitet Anfragen an eine ECS service target group weiter. Fargate-Tasks in privaten Subnetzen über drei AZs hinweg verarbeiten die Anfragen. ECS Service Auto Scaling passt mithilfe von Target Tracking auf ALBRequestCountPerTarget die Task-Anzahl zwischen 2 und 50 an. Die Tasks verbinden sich mit RDS Aurora und ElastiCache in privaten Subnetzen. Alle Logs werden an CloudWatch Logs gesendet; Metriken steuern CloudWatch-Dashboards und Alarme.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: ECS Service Auto Scaling verwendet Application Auto Scaling mit Target Tracking (CPU, ALB-Anfragen oder benutzerdefinierte Metriken), um die Task-Anzahl innerhalb konfigurierter Mindest- und Höchstgrenzen anzupassen. ALB path-based routing ermöglicht es einem Load Balancer, mehrere ECS-Microservices bereitzustellen, indem URL-Pfade an unterschiedliche Zielgruppen weitergeleitet werden. Der Deployment Circuit Breaker führt bei fehlschlagenden Deployments automatisch ein Rollback durch, bevor diese zu länger andauernden Beeinträchtigungen des Service führen. Damit ist das Modul zu ECS und Containern abgeschlossen – als Nächstes beschäftigen wir uns mit Amazon EKS für Kubernetes auf AWS.