View a markdown version of this page

Panoramica dell’architettura - Test di carico distribuito su AWS
Diagramma architetturale

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Panoramica dell’architettura

Diagramma architetturale

La distribuzione di questa soluzione con i parametri predefiniti distribuisce i seguenti componenti nel tuo account AWS.

Test di carico distribuito sull'architettura AWS

Test di carico distribuito sull'architettura AWS
Nota

Le CloudFormation risorse AWS vengono create dai costrutti AWS Cloud Development Kit (AWS CDK).

Il flusso di processo di alto livello per i componenti della soluzione distribuiti con il modello AWS è CloudFormation il seguente:

  1. (CloudFront + opzione di distribuzione dell'hosting S3) L'utente della console accede alla console web tramite Amazon CloudFront, che serve l'applicazione AWS Amplify ospitata in un bucket Amazon Simple Storage Service (Amazon S3).

  2. (opzione di distribuzione dell'hosting ALB + ECS Fargate) L'utente della console accede alla console web tramite un Application Load Balancer, che indirizza il traffico verso l'applicazione AWS Amplify in esecuzione su Amazon Elastic Container Service (Amazon ECS) su AWS Fargate all'interno di un Amazon Virtual Private Cloud (Amazon VPC).

  3. (Opzione di distribuzione Headless) Non viene implementato alcun front-end pubblico. La soluzione fornisce la console web come ZIP scaricabile in un bucket Amazon S3 privato. L'utente della console può accedere alla console da un server Web ospitato autonomamente.

  4. Durante la configurazione iniziale, la soluzione crea un utente amministratore predefinito nel pool di utenti di Amazon Cognito e invia un'email di creazione dell'account all'indirizzo e-mail fornito. Il pool di utenti Cognito gestisce l'accesso degli utenti alla console web, all'API REST, alla CLI e al server MCP.

  5. Amazon API Gateway richiama i microservizi AWS Lambda che forniscono la logica aziendale per gestire i dati di test ed eseguire i test.

  6. I microservizi interagiscono con Amazon S3, Amazon DynamoDB e Amazon per memorizzare i dettagli degli scenari di test e EventBridge gestire le pianificazioni dei test. Quando pianifichi l'esecuzione di un test in un momento futuro o a intervalli ricorrenti, i microservizi creano una EventBridge pianificazione dello Scheduler che richiama il microservizio all'ora pianificata.

  7. Per eseguire un test, i microservizi richiamano AWS Step Functions, che orchestra l'esecuzione del test.

  8. EventBridge le regole indirizzano gli eventi di errore delle attività di Amazon ECS e di Step Functions a una funzione Lambda del gestore dei guasti.

  9. Step Functions avvia le attività di Amazon Elastic Container Service (Amazon ECS) su AWS Fargate in ciascuna regione AWS selezionata.

  10. Ogni attività viene eseguita all'interno di un Amazon Virtual Private Cloud (Amazon VPC) nella regione selezionata.

  11. I container per il test di carico utilizzano un'immagine di base di Amazon Linux 2023 e l'immagine utilizzata da un'attività dipende dalla modalità di forma del traffico del test. In modalità Standard, sull'immagine è installato il framework di automazione dei test Taurus. Taurus esegue il test JMeter, k6, Locust o Simple HTTP Endpoint utilizzando i parametri di caricamento impostati nella console. In modalità nativa, un'immagine dedicata per ogni framework esegue il framework direttamente sullo script, senza Taurus e senza parametri di caricamento dalla soluzione. Per informazioni dettagliate sulle modalità, consulta le modalità Traffic shape. Per vedere come viene eseguito il provisioning di ogni framework di test, fai riferimento a Testing framework provisioning. L'opzione ALB + ECS utilizzerà il contenitore dell'host web. Le immagini del contenitore sono ospitate da AWS in un repository pubblico Amazon Elastic Container Registry (Amazon ECR).

  12. Ogni attività di Fargate scrive i risultati dei test per regione su Amazon S3 ed emette i log su Amazon. CloudWatch Una volta completate tutte le regioni, i microservizi aggregano i risultati in DynamoDB.

  13. Se abiliti l'opzione dati in tempo reale, una funzione Lambda riceve i CloudWatch log dalle attività di Fargate durante il test.

  14. La funzione Lambda pubblica i log in un argomento in AWS IoT Core nella regione in cui è distribuito lo stack principale. La console web si iscrive all'argomento per visualizzare le metriche in tempo reale durante l'esecuzione del test.

  15. (Accesso CLI opzionale) Gli utenti possono installare l'interfaccia a riga di comando (CLI) DLT localmente per interagire con la soluzione dal proprio terminale. La CLI si autentica tramite Cognito e chiama direttamente l'API REST, consentendo l'automazione e l'integrazione tramite script. CI/CD

    Nota

    I passaggi seguenti descrivono l'integrazione opzionale del server MCP per l'analisi dei test di carico. AI-assisted Questo componente viene distribuito solo se si seleziona l'opzione MCP Server durante la distribuzione della soluzione.

  16. Un client MCP (strumento di sviluppo AI) si connette all'endpoint Amazon Bedrock AgentCore Gateway per accedere ai dati della soluzione Distributed Load Testing tramite il Model Context Protocol. AgentCore Gateway convalida il token di autenticazione Amazon Cognito dell'utente per verificare l'accesso autorizzato al server MCP.

  17. Una volta completata l'autenticazione, AgentCore Gateway inoltra la richiesta dello strumento MCP alla funzione Lambda del DLT MCP Server.

  18. La funzione Lambda chiama l'API REST DLT esistente per recuperare i dati di test di carico richiesti. Quindi restituisce i dati strutturati a AgentCore Gateway, che li invia al client MCP per AI-assisted analisi e approfondimenti.