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 a partire da costrutti di AWS Cloud Development Kit (AWS CDK).

Il flusso di processo di alto livello per i componenti della soluzione distribuiti con il CloudFormation modello AWS è 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 distribuito 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'e-mail 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 di business per gestire i dati di test ed eseguire i test.

  6. I microservizi interagiscono con Amazon S3, Amazon DynamoDB e Amazon per archiviare i dettagli degli scenari di test e gestire le EventBridge pianificazioni dei test. Quando si pianifica l'esecuzione di un test in un momento futuro o in base a intervalli ricorrenti, i microservizi creano una EventBridge pianificazione 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 le attività di Amazon ECS e gli eventi di errore Step Functions a una funzione Lambda del gestore degli errori.

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

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

  11. Il contenitore di test di carico utilizza un'immagine di base Amazon Linux 2023 con il framework di automazione dei test Taurus installato. Taurus esegue il test JMeter, K6, Locust o Single HTTP Endpoint. Per i dettagli su come viene fornito ogni framework di test, consulta Testing framework provisioning. L'opzione ALB + ECS utilizzerà il contenitore web host. Le immagini dei container sono ospitate da AWS in un repository pubblico Amazon Elastic Container Registry (Amazon ECR).

  12. Ogni attività 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 si abilita l'opzione live data, una funzione Lambda riceve i CloudWatch log delle attività di Fargate durante il test.

  14. La funzione Lambda pubblica i log relativi a un argomento in AWS IoT Core nella regione in cui è distribuito lo stack principale. La console web sottoscrive l'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 esegue l'autenticazione tramite Cognito e richiama direttamente l'API REST, abilitando 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 Cognito dell'utente per garantire l'accesso autorizzato al server MCP.

  17. Una volta completata l'autenticazione, AgentCore Gateway inoltra la richiesta dello strumento MCP alla funzione Lambda del server DLT MCP. La funzione Lambda restituisce i dati strutturati a AgentCore Gateway, che li invia al client MCP per AI-assisted analisi e approfondimenti.

  18. La funzione Lambda elabora la richiesta e interroga le risorse AWS appropriate (tabelle DynamoDB, bucket S3 o CloudWatch log) per recuperare i dati di test di carico richiesti.