Come funziona il test di carico distribuito su AWS

Si utilizza la console Web per inviare uno scenario di test che include i dettagli di configurazione all'API della soluzione.

La configurazione dello scenario di test viene caricata su Amazon Simple Storage Service (Amazon S3) come file JSON (). s3://<bucket-name>/test-scenarios/<$TEST_ID>/<$TEST_ID>.json

Una macchina a stati AWS Step Functions viene eseguita utilizzando l'ID di test, il conteggio delle attività, il tipo di test e il tipo di file come input della macchina a stati AWS Step Functions. Se il test è pianificato, creerà innanzitutto una regola CloudWatch Events, che attiva AWS Step Functions alla data specificata. Per maggiori dettagli sul flusso di lavoro di pianificazione, consulta la sezione Flusso di lavoro di pianificazione dei test di questa guida.

I dettagli di configurazione sono archiviati nella tabella degli scenari Amazon DynamoDB.

Nel flusso di lavoro del task runner di AWS Step Functions, la funzione task-status-checker AWS Lambda verifica se le attività di Amazon Elastic Container Service (Amazon ECS) sono già in esecuzione per lo stesso ID di test. Se vengono rilevate attività con lo stesso ID di test in esecuzione, viene generato un errore. Se non ci sono attività Amazon ECS in esecuzione nel cluster AWS Fargate, la funzione restituisce l'ID di test, il conteggio delle attività e il tipo di test.

La funzione task-runner AWS Lambda ottiene i dettagli delle attività dal passaggio precedente ed esegue le attività dei worker di Amazon ECS nel cluster AWS Fargate. L'API Amazon ECS utilizza l' RunTask azione per eseguire le attività dei lavoratori. Queste attività lavorative vengono avviate e quindi attendono un messaggio di avvio dall'attività principale per iniziare il test. L' RunTask azione è limitata a 10 attività per definizione. Se il numero di attività è superiore a 10, la definizione dell'attività verrà eseguita più volte fino all'avvio di tutte le attività dei lavoratori. La funzione genera anche un prefisso per distinguere il test corrente nella funzione di analisi dei risultati di AWS Lambda.

La funzione task-status-checker AWS Lambda verifica se tutte le attività di lavoro di Amazon ECS vengono eseguite con lo stesso ID di test. Se le attività sono ancora in fase di provisioning, attende un minuto e verifica nuovamente. Una volta eseguite tutte le attività di Amazon ECS, restituisce l'ID di test, il conteggio delle attività, il tipo di test, tutte le attività IDs e il prefisso e li passa alla funzione task-runner.

La funzione task-runner AWS Lambda viene eseguita nuovamente, questa volta lanciando una singola attività Amazon ECS che funge da nodo leader. Questa attività ECS invia un messaggio di avvio del test a ciascuna delle attività del lavoratore per avviare i test contemporaneamente.

La funzione task-status-checker AWS Lambda verifica nuovamente se le attività di Amazon ECS sono in esecuzione con lo stesso ID di test. Se le attività sono ancora in esecuzione, attende un minuto e verifica nuovamente. Quando non ci sono attività Amazon ECS in esecuzione, restituisce l'ID di test, il conteggio delle attività, il tipo di test e il prefisso.

Quando la funzione task-runner AWS Lambda esegue le attività di Amazon ECS nel cluster AWS Fargate, ogni attività scarica la configurazione di test da Amazon S3 e avvia il test.

Una volta eseguiti i test, il tempo di risposta medio, il numero di utenti simultanei, il numero di richieste riuscite e il numero di richieste non riuscite per ogni attività vengono registrati in Amazon CloudWatch e possono essere visualizzati in una CloudWatch dashboard.

Se hai incluso dati in tempo reale nel test, la soluzione filtra i risultati dei test in tempo reale CloudWatch utilizzando un filtro di abbonamento. Quindi la soluzione passa i dati a una funzione Lambda.

La funzione Lambda struttura quindi i dati ricevuti e li pubblica su un argomento di AWS IoT Core.

La console Web sottoscrive l'argomento AWS IoT Core per il test e riceve i dati pubblicati sull'argomento per rappresentare graficamente i dati in tempo reale durante l'esecuzione del test.

Al termine del test, le immagini del contenitore esportano un report dettagliato come file XML in Amazon S3. A ogni file viene assegnato un UUID per il nome del file. Ad esempio, s3://dlte-bucket/test-scenarios/ <$TEST_ID> /results/ <$UUID> .json.

Quando i file XML vengono caricati su Amazon S3, la funzione results-parser AWS Lambda legge i risultati nei file XML a partire dal prefisso e analizza e aggrega tutti i risultati in un unico risultato riepilogativo.

La funzione results-parser AWS Lambda scrive il risultato aggregato in una tabella Amazon DynamoDB.

Interazione con il cliente: il cliente interagisce con l'MCP di DLT tramite l'endpoint MCP ospitato da AWS Gateway. AgentCore Gli agenti AI si connettono a questo endpoint per richiedere l'accesso ai dati dei test di carico.

Autorizzazione: AgentCore Gateway gestisce l'autorizzazione sul client dell'applicazione del pool di utenti di Solution Cognito. Il gateway convalida il token Cognito dell'utente per garantire che abbia l'autorizzazione ad accedere al server DLT MCP. Agli utenti autorizzati viene concesso l'accesso con accesso agli strumenti dell'agente limitato alle operazioni di sola lettura.

Specifiche dello strumento: il AgentCore gateway si connette alla funzione Lambda del server DLT MCP. Una specifica dello strumento definisce gli strumenti disponibili che gli agenti AI possono utilizzare per interagire con i dati dei test di carico.

Accesso API in sola lettura: la funzione Lambda è destinata all'accesso API in sola lettura tramite gli endpoint DLT API Gateway esistenti. La funzione fornisce quattro operazioni principali: