Een bedrijf ontwikkelt machine learning-modellen op AWS als onafhankelijke microservices. Elke microservice haalt bij het opstarten ongeveer 1 GB aan modelgegevens op uit Amazon S3 en laadt deze in het geheugen. Gebruikers hebben toegang tot de ML-modellen via een asynchrone API en kunnen enkele of batchverzoeken verzenden. Het bedrijf bedient honderden gebruikers. Gebruikspatronen zijn onregelmatig: sommige modellen kunnen dagen of weken inactief zijn, terwijl andere batches van duizenden verzoeken ontvangen. Welke oplossing voldoet aan deze vereisten?

De correcte optie gebruikt SQS voor asynchrone verwerking en ECS voor de ML-modellen. SQS is ideaal voor asynchrone API-verzoeken en onregelmatige gebruikspatronen, omdat het verzoeken buffert en ontkoppelt. ECS-services zijn geschikt voor het laden van 1 GB aan modelgegevens in het geheugen, wat te groot is voor Lambda's geheugenlimiet (maximaal 10 GB, maar 1 GB is al aanzienlijk en kan de opstarttijden van Lambda beïnvloeden). Auto scaling op basis van de SQS-wachtrijgrootte zorgt ervoor dat de ECS-resources efficiënt schalen met de vraag, wat kosten bespaart tijdens inactieve perioden en prestaties garandeert tijdens pieken. De andere opties zijn minder geschikt: NLB met Lambda: Lambda heeft een geheugenlimiet die het laden van 1 GB aan modelgegevens in het geheugen bemoeilijkt. Bovendien is NLB voor TCP/UDP verkeer, niet HTTP/HTTPS, en Lambda is niet direct schaalbaar via NLB auto scaling. ALB met ECS: Hoewel ALB en ECS geschikt zijn voor de workload, is dit een synchrone benadering. De vereiste is een asynchrone API, wat SQS beter afhandelt, vooral bij onregelmatige patronen en batchverzoeken. SQS met Lambda: Opnieuw is de geheugenlimiet van Lambda een probleem voor het laden van 1 GB aan gegevens.