Un'azienda sta creando una nuova soluzione di machine learning su AWS. I modelli sono implementati come microservizi indipendenti che scaricano circa 1 GB di dati del modello da Amazon S3 all'avvio e li caricano in memoria. Gli utenti accedono ai modelli tramite un'API asincrona: inviano una richiesta o un batch di richieste e specificano dove devono essere inviati i risultati. Centinaia di utenti utilizzeranno i modelli con pattern di utilizzo irregolari: alcuni modelli potrebbero rimanere inattivi per giorni o settimane, mentre altri ricevono picchi di migliaia di richieste. Quale design dovrebbe raccomandare un architetto di soluzioni per soddisfare questi requisiti?

L'opzione corretta utilizza Amazon SQS per desacopiare l'API dai microservizi di machine learning, gestendo i picchi di richieste e garantendo che nessun dato venga perso. I modelli sono distribuiti come servizi Amazon ECS, che sono adatti per carichi di lavoro che richiedono il caricamento di 1 GB di dati in memoria all'avvio, cosa che sarebbe problematica per le funzioni Lambda a causa dei limiti di memoria e tempo di esecuzione. AWS Auto Scaling su ECS permette di scalare dinamicamente sia il cluster che il numero di copie del servizio in base alla dimensione della coda SQS, ottimizzando i costi e garantendo la disponibilità anche con pattern di utilizzo irregolari. Le altre opzioni sono meno adatte: L'uso di Lambda direttamente con un NLB non è ideale perché Lambda ha limiti di memoria e tempo di esecuzione che potrebbero non essere sufficienti per caricare 1 GB di dati del modello. L'opzione con ALB e ECS con App Mesh è meno efficiente perché l'ALB non gestisce l'elaborazione asincrona e non fornisce il desacoppiamento necessario per i pattern di utilizzo irregolari. L'opzione con SQS e Lambda con Auto Scaling delle vCPU per Lambda è errata perché Lambda scala automaticamente in base alle invocazioni e non tramite vCPU configurabili dall'utente. Inoltre, i limiti di memoria di Lambda rimangono un problema.