Automatisch schalen en load balancing van ECS-services

Doeltracking is voor de meeste ECS-services het aanbevolen beleid voor automatisch schalen. De meest gebruikte doelmetriek is ECSServiceAverageCPUUtilization: stel een doel van 50-70% in, waarna ECS taken toevoegt of verwijdert om dat CPU-niveau te handhaven. Een andere krachtige metriek is ALBRequestCountPerTarget: houd het aantal ALB-verzoeken per taak bij en schaal om een doelverwerkingssnelheid per instantie te handhaven. AWS handelt het opschalen en afschalen automatisch af, met geschikte afkoelperioden.

Als je een Application Load Balancer (ALB) aan een ECS-service koppelt, wordt HTTP/HTTPS-verkeer verdeeld over alle actieve taken. De doelgroep van de ALB registreert het IP-adres van elke taak (voor Fargate/awsvpc) of de containerpoort (voor de bridge-modus). ECS registreert nieuwe taken automatisch bij de doelgroep zodra ze starten en verwijdert ze zodra ze stoppen. De ALB voert gezondheidscontroles uit op elke taak; ongezonde taken worden leeggemaakt (verbindingen worden netjes gesloten) voordat de service ze beëindigt.

Een krachtig patroon is om verschillende URL-paden naar verschillende ECS-services te routeren met ALB-routering op basis van paden. Eén ALB met één HTTPS-listener kan als volgt routeren: /api/orders/* naar de ECS-service Orders, /api/users/* naar de ECS-service Users en /api/products/* naar de ECS-service Products. Elke service wordt ondersteund door een eigen ECS-service met onafhankelijk schalen. Hierdoor zijn afzonderlijke load balancers per microservice niet nodig, wat kosten verlaagt en DNS-beheer vereenvoudigt.

Wanneer een ECS-taak wordt beëindigd (tijdens het afschalen of een implementatie), markeert de ALB deze als wordt leeggemaakt en stuurt hij er geen nieuwe verzoeken meer naartoe, terwijl lopende verzoeken kunnen worden voltooid. De vertraging voor het opheffen van de registratie (standaard 300 seconden, configureerbaar van 0 tot 3600 seconden) bepaalt hoelang de ALB wacht voordat hij verbindingen geforceerd sluit. Voor ECS met korte verzoekduur stel je een lagere vertraging voor het opheffen van de registratie in (30-60 seconden) om implementaties en afschaalbewerkingen te versnellen. Voor langdurige verbindingen (WebSocket, bestandsuploads) houd je een hogere vertraging aan.

Naast CPU en geheugen kun je vanuit je toepassing aangepaste CloudWatch-metrieken publiceren (wachtrijdiepte, actieve sessies, zakelijke KPI's) en deze gebruiken om het schalen aan te sturen. Als elke ECS-taak bijvoorbeeld gelijktijdig 50 wachtrijberichten kan verwerken, publiceer je de diepte van de SQS-wachtrij als aangepaste metriek en maak je een doeltrackingbeleid met als doel 50 berichten per taak. Zo ontstaat schalen dat rechtstreeks door bedrijfslogica wordt aangestuurd, in plaats van door infrastructuurmetrieken die mogelijk geen verband houden met de belasting van de toepassing.

Net als EC2 Auto Scaling ondersteunt ECS bescherming tegen het afschalen van taken. Een actieve taak kan via de ECS API zelf een vlag voor bescherming tegen afschalen instellen, zodat de taak tijdens het afschalen niet wordt beëindigd terwijl deze een kritieke taak verwerkt. Dit is nuttig voor ECS-taken die als SQS-werknemers fungeren: een werknemer die net een langdurige taak uit de wachtrij heeft gehaald, kan zichzelf beschermen, de taak voltooien en daarna de bescherming opheffen. Zonder deze bescherming kan het afschalen een taak die halverwege de verwerking is beëindigen, wat dubbele taken of gegevensverlies kan veroorzaken.

Kies je schaalmetriek zorgvuldig. CPU-gebruik is de standaard en werkt goed voor rekenintensieve werkbelastingen. Geheugengebruik (ECSServiceAverageMemoryUtilization) is nuttig voor toepassingen die door geheugen worden beperkt, maar voor meer geheugen moet je extra taken toevoegen. Als je taak wordt beperkt door het geheugen per taak in plaats van door gelijktijdige verwerking, is het mogelijk beter om de geheugentoewijzing in de taakdefinitie aan te passen. ALBRequestCountPerTarget houdt rechtstreeks verband met de gebruikerservaring en is de meest bruikbare metriek voor web-API's: schaal op basis van de werkelijke verzoeksnelheid per taak.

De implementatiecircuitonderbreker van ECS detecteert mislukte implementaties automatisch en zet ze terug naar de laatst stabiele versie. Zonder deze functie zou een slechte implementatie (een container die niet slaagt voor gezondheidscontroles) ervoor zorgen dat ECS eindeloos nieuwe taken probeert te starten. Als de circuitonderbreker is ingeschakeld en een bepaald percentage van de nieuw gestarte taken binnen een detectievenster niet slaagt voor de gezondheidscontroles, markeert ECS de implementatie als MISLUKT en zet het automatisch terug naar de vorige revisie van de taakdefinitie. Zo voorkom je langdurige verslechtering van de service door slechte implementaties.

Een productierijpe architectuur voor een gecontaineriseerde web-API: Route 53 verwijst het domein naar een ALB-DNS-naam; de ALB beëindigt HTTPS (ACM-certificaat), past WAF-regels toe en routeert verzoeken naar een doelgroep van een ECS-service; Fargate-taken in private subnetten verspreid over 3 AZ's verwerken de verzoeken; automatisch schalen van ECS-services past met doeltracking op ALBRequestCountPerTarget de taakentelling aan van 2 tot 50; taken maken verbinding met RDS Aurora en ElastiCache in private subnetten. Alle logboeken gaan naar CloudWatch Logs; metrieken sturen CloudWatch-dashboards en alarmen aan.

In deze les heb je geleerd dat automatisch schalen van ECS-services Application Auto Scaling gebruikt met doeltracking (CPU, ALB-verzoeken of aangepaste metrieken) om de taakentelling aan te passen binnen ingestelde minimale en maximale grenzen, dat ALB-routering op basis van paden één load balancer geschikt maakt voor meerdere ECS-microservices door URL-paden naar verschillende doelgroepen te routeren, en dat de implementatiecircuitonderbreker mislukte implementaties automatisch terugdraait voordat ze langdurige verslechtering van de service veroorzaken. Hiermee is de module over ECS en containers voltooid. Vervolgens verkennen we Amazon EKS voor Kubernetes op AWS.