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à.
Considerazioni di natura progettuale
Questa sezione descrive importanti decisioni di progettazione e opzioni di configurazione per la soluzione Distributed Load Testing on AWS, comprese le applicazioni supportate, i tipi di test, le opzioni di pianificazione e le considerazioni sulla distribuzione.
Applicazioni supportate
Questa soluzione supporta il test di applicazioni basate su cloud e applicazioni locali purché si disponga della connettività di rete dal proprio account AWS all'applicazione. La soluzione supporta le API che utilizzano i protocolli HTTP o HTTPS.
Tipi di test di
Distributed Load Testing on AWS supporta diversi tipi di test: semplici test sugli endpoint HTTP, JMeter, k6 e Locust. Ogni tipo di test, ad eccezione del semplice endpoint HTTP, può essere eseguito in entrambe le modalità traffic shape. Per ulteriori informazioni, consulta le modalità Modalità Traffic Shape Traffic shape.
Nota
La soluzione distribuisce JMeter, k6 e Locust come componenti di terze parti senza modifiche. Per considerazioni sulla sicurezza, opzioni di patch e informazioni sulla licenza, fai riferimento ai framework di test. Third-party
Semplici test sugli endpoint HTTP
La console web fornisce un'interfaccia di configurazione degli endpoint HTTP che consente di testare qualsiasi endpoint HTTP o HTTPS senza scrivere script personalizzati. È possibile definire l'URL dell'endpoint, selezionare il metodo HTTP (GET, POST, PUT, DELETE e così via) da un menu a discesa e, facoltativamente, aggiungere intestazioni di richiesta e payload del corpo personalizzati. Questa configurazione consente di testare le API con token di autorizzazione personalizzati, tipi di contenuto o qualsiasi altra intestazione HTTP e corpo di richiesta richiesti dall'applicazione.
Quando si configura un endpoint HTTP, la soluzione converte la configurazione in un piano di test eseguito dal binario Apache JMeter in bundle tramite il framework Taurus. I semplici test HTTP Endpoint non accettano un archivio di test, quindi non possono sovrascrivere il binario o i plugin JMeter in dotazione. Se devi eseguire test sugli endpoint HTTP con un JMeter patchato, utilizza invece il tipo di test JMeter. Test JMeter Per considerazioni sulla sicurezza, fate riferimento a Apache JMeter. Apache JMeter
Poiché la soluzione genera il piano di test per questo tipo di test, i test Simple HTTP Endpoint vengono eseguiti solo in modalità Standard. La modalità nativa richiede il caricamento di uno script. Per ulteriori informazioni, consulta le modalità Traffic shape.
Test JMeter
Quando si crea uno scenario di test utilizzando la console web, è possibile caricare uno script di test JMeter. La soluzione carica lo script nel bucket S3 degli scenari. Quando le attività di Amazon ECS vengono eseguite, scaricano lo script JMeter da S3 ed eseguono il test.
Importante
In modalità Standard, lo script JMeter può definire la concorrenza (utenti virtuali), i tassi di transazione (TPS), i tempi di avvio e altri parametri di caricamento. La soluzione li sostituisce tutti con i valori specificati nella schermata Traffic Shape durante la creazione del test. Tale configurazione controlla il numero di attività, la concorrenza (utenti virtuali per attività), la durata dell'avvio e la durata del blocco per l'esecuzione del test.
In modalità nativa, la soluzione viene eseguita jmeter -n -t sullo script e non passa parametri di caricamento. I gruppi di thread e i timer vengono eseguiti esattamente come sono stati creati. Per ulteriori informazioni, consulta le modalità Traffic shape.
Se disponi di file di input JMeter, puoi comprimere i file di input insieme allo script JMeter. Puoi scegliere il file zip quando crei uno scenario di test.
Se desideri includere dei plugin, tutti i file .jar inclusi in una sottodirectory /plugins nel file zip in dotazione verranno copiati nella directory delle estensioni di JMeter e saranno disponibili per il test di carico.
Nota
Se si includono file di input JMeter nel file di script JMeter, è necessario includere il percorso relativo dei file di input nel file di script JMeter. Inoltre, i file di input devono trovarsi nel percorso relativo. Ad esempio, quando i file di input e il file di script di JMeter si trovano nella home/user directory/e si fa riferimento ai file di input nel file di script JMeter, il percorso dei file di input deve essere. /FILE_DI INPUT. Se invece usi/home/user/INPUT_FILES, il test fallirà perché non sarà in grado di trovare i file di input.
Se includi plugin JMeter, i file .jar devono essere raggruppati in una sottodirectory denominata /plugins all'interno della radice del file zip. Rispetto alla radice del file zip, il percorso dei file jar deve essere. /plugins/BUNDLED_PLUGIN.jar.
Per ulteriori informazioni su come utilizzare gli script JMeter, fare riferimento al Manuale utente di JMeter.
test k6
La soluzione supporta i test basati sul framework k6. Puoi caricare il file di test k6 insieme a tutti i file di input necessari in un file di archivio. La console web mostra un messaggio di conferma della licenza quando si crea un nuovo test k6. Per i dettagli sulla licenza e sulla sicurezza, fai riferimento a Grafana k6.
Importante
In modalità Standard, lo script k6 può definire concorrenza (utenti virtuali), fasi, soglie e altri parametri di caricamento. La soluzione li sostituisce tutti con i valori specificati nella schermata Traffic Shape durante la creazione del test. Tale configurazione controlla il numero di attività, la concorrenza (utenti virtuali per attività), la durata dell'avvio e la durata del blocco per l'esecuzione del test.
In modalità nativa, la soluzione viene eseguita k6 run sullo script e non passa parametri di caricamento. k6 applica il blocco di opzioni, gli scenari, le fasi e le soglie esattamente come sono stati scritti. Per ulteriori informazioni, consulta le modalità Traffic shape.
Test di locuste
La soluzione supporta i test basati sul framework Locust. È possibile caricare il file di test Locust insieme a tutti i file di input necessari in un file di archivio.
Importante
In modalità Standard, lo script Locust può definire la concorrenza (numero di utenti), la frequenza di generazione e altri parametri di caricamento. La soluzione li sostituisce tutti con i valori specificati nella schermata Traffic Shape durante la creazione del test. Tale configurazione controlla il numero di attività, la concorrenza (utenti virtuali per attività), la durata dell'avvio e la durata del blocco per l'esecuzione del test.
In modalità nativa, la soluzione viene eseguita locust --headless sullo script e non passa parametri di caricamento. Locust applica LoadTestShape le classi e i set di attività ponderati esattamente come scritti. Lo script non deve essere impostatoprocesses, perché la soluzione conta le richieste solo quando Locust viene eseguito come un singolo processo. Per ulteriori informazioni, consulta le modalità Modalità Traffic Shape Traffic shape.
Denominazione degli script di test
Quando carichi un singolo .py file, la soluzione lo memorizza con l'ID di test e vi fa riferimento direttamente, in modo che il file possa avere qualsiasi nome. Quando si carica un .zip archivio, la soluzione cerca nell'archivio un file denominatolocustfile.py. Se l'archivio contiene uno script Python con un altro nome, il test ha esito negativo all'avvio del contenitore con il messaggioNo test script (.py) in zip file.
Dipendenze Python personalizzate
Il contenitore per il test di carico include Locust e le sue dipendenze. Non include pacchetti Python di terze parti. Se il tuo script Locust importa un pacchetto che non è presente nel contenitore, il test ha esito negativo. ModuleNotFoundError Per rendere disponibili pacchetti aggiuntivi, includi un requirements.txt file nella radice del tuo .zip archivio. Il contenitore installa i pacchetti elencati requirements.txt prima dell'inizio del test.
È possibile fornire le dipendenze in due modi:
- Installa da PyPI
-
Includi solo un
requirements.txtfile. Il contenitore installa i pacchetti elencatirequirements.txtda PyPI all'avvio dell'attività. Ciò richiede l'accesso a Internet in uscita dalle sottoreti in cui vengono eseguite le attività di test di carico. - Installazione da ruote in dotazione (offline)
-
Includi un
requirements.txtfile e unapackagessottodirectory contenenti i file Python wheel ().whl. Il contenitore si installa solo dalle ruote in dotazione e non contatta PyPI. Questa opzione funziona in ambienti senza accesso a Internet in uscita. Il raggruppamento delle ruote determina inoltre le versioni esatte dei pacchetti, quindi una nuova versione di PyPI non può modificare l'ambiente di test tra una esecuzione e l'altra.
L'esempio seguente mostra il layout dell'archivio:
my-test.zip ├── locustfile.py # Required — must use this name ├── requirements.txt # Optional — packages to install └── packages/ # Optional — wheels, for offline install only └── *.whl
Entrambi requirements.txt e la packages sottodirectory devono trovarsi nella radice dell'archivio, accantolocustfile.py. Omettili entrambi se il tuo script importa solo i pacchetti già forniti dal contenitore. La packages sottodirectory ha effetto solo insieme a un requirements.txt file; da sola, viene ignorata e non viene installato alcun pacchetto.
Dipendenze transitive
Quando si raggruppano le ruote, è requirements.txt necessario elencare tutti i pacchetti richiesti dalle dipendenze, non solo i pacchetti che si importano direttamente. L'installazione offline non contatta PyPI. Una dipendenza transitiva mancante causa il fallimento dell'installazione e l'interruzione dell'attività prima dell'inizio del test.
Preparazione delle ruote per il contenitore
Il container per il test di carico esegue Linux sull'architettura x86_64 con Python 3.11. Le ruote compilate per un sistema operativo, un'architettura o una versione di Python diversi non vengono installate. I pacchetti scritti in Python puro vengono distribuiti come ruote indipendenti dalla piattaforma e funzionano ovunque, ma i pacchetti contenenti estensioni compilate richiedono una ruota creata per la piattaforma del contenitore. Poiché il contenitore non include un compilatore, non può creare una distribuzione dei sorgenti all'avvio dell'attività.
Esegui il comando seguente per scaricare le ruote compatibili con la piattaforma del contenitore. Puoi eseguire questo comando da qualsiasi sistema operativo, inclusi macOS e Windows. Quindi includi la packages directory risultante nel tuo archivio:
pip download -r requirements.txt \ --dest packages \ --platform manylinux2014_x86_64 \ --python-version 3.11 \ --only-binary=:all:
Le --python-version opzioni --platform and sono destinate al contenitore, non al computer su cui si esegue il comando. L'--only-binary=:all:opzione fa sì che il comando abbia esito negativo anziché tornare silenziosamente a una distribuzione di origine che il contenitore non può creare. Il manylinux2014 tag specifica una ruota compatibile con glibc 2.17 e versioni successive, che include la versione del contenitore.
Per raggruppare un pacchetto che gestisci tu stesso, crea una ruota dalla cartella dei sorgenti del pacchetto conpip wheel . --wheel-dir packages, quindi aggiungi il nome del pacchetto a. requirements.txt
Modalità Traffic Shape
Ogni test viene eseguito in una delle due modalità di configurazione del traffico, Standard o Native. La modalità determina tre fattori: da che parte controlla il carico, quale immagine del contenitore viene utilizzata dalle attività di Fargate e quali parametri di carico la soluzione invia al framework di test. Per indicazioni sulla scelta di una modalità quando crei un test, consulta le modalità Traffic shape nella sezione Usa la soluzione.
Modalità standard
Le attività di Fargate utilizzano l'immagine con Taurus installato. Taurus riceve dalla soluzione il conteggio delle attività, la concorrenza, l'incremento e la durata delle sospensioni. Traduce questi valori nei controlli di carico propri del framework sottostante. Taurus ha la precedenza sul carico dichiarato dallo script. Riscrive o ignora un blocco di opzioni k6, un gruppo di thread LoadTestShape Locust o JMeter. Gli utenti virtuali generati da una regione sono il numero di attività moltiplicato per la concorrenza per ogni attività. Quella forma è la stessa per ogni framework. Ecco come la soluzione eseguiva tutti i test precedenti alla versione 4.3.0.
Modalità nativa
Le attività di Fargate utilizzano l'immagine dedicata per il framework del test, che non include Taurus. Invece di scrivere una configurazione di Taurus, la soluzione richiama direttamente il framework:,, o. jmeter -n -t k6 run locust --headless Non trasmette parametri di carico. Il tuo script è l'unica autorità sul traffico che genera.
Da questa progettazione derivano due conseguenze ed entrambe influiscono sul dimensionamento di un test:
-
Le attività moltiplicano il carico. Ogni attività esegue un processo quadro indipendente senza coordinamento tra le attività. Di conseguenza, una regione genera una copia completa del carico dichiarato dello script per ogni attività. Ad esempio, uno script k6 contenente 200 utenti virtuali, eseguito su cinque attività, colloca 1.000 utenti virtuali sul bersaglio. Task count è l'unico controllo del carico che la soluzione offre in questa modalità. Si muove in multipli interi di ciò che dichiara lo script.
-
Una durata di sicurezza limita la corsa. Poiché lo script decide quando termina il test, la soluzione richiede una durata di sicurezza fino a 24 ore. Se il test è ancora in esecuzione allo scadere della durata, la soluzione interrompe il framework. Raccoglie i risultati per la parte eseguita e registra l'esecuzione come completata anziché fallita.
Pianificazione dei test
La soluzione offre tre opzioni di temporizzazione dell'esecuzione per l'esecuzione dei test di carico:
-
Esegui ora: esegui il test di carico subito dopo la creazione
-
Esegui una volta: esegui il test in una data e ora specifiche nel futuro
-
Esegui in base a una pianificazione: crea test ricorrenti utilizzando espressioni cron per definire la pianificazione
Quando si seleziona Run Once, si specifica il tempo di esecuzione nel formato 24 ore e la data di esecuzione in cui il test di carico deve iniziare a essere eseguito.
Quando si seleziona Esegui in base a una pianificazione, è possibile immettere manualmente un'espressione cron o selezionare uno dei modelli cron più comuni (ad esempio ogni ora, ogni giorno a un'ora specifica, nei giorni feriali o mensili). L'espressione cron utilizza un formato di pianificazione dettagliato con campi per minuti, ore, giorno del mese, mese, giorno della settimana e anno. È inoltre necessario specificare una data di scadenza, che definisce quando il test pianificato deve interrompere l'esecuzione. Per ulteriori informazioni sulla pianificazione delle regole di convalida, consulta la sezione Vincoli di pianificazione di questa guida.
Nota
-
Durata del test: considera la durata totale dei test durante la pianificazione. Ad esempio, un test con un tempo di avvio di 10 minuti e un tempo di attesa di 40 minuti richiederà circa 80 minuti per essere completato.
-
Intervallo minimo: assicurati che l'intervallo tra i test programmati sia più lungo della durata stimata del test. Ad esempio, se il test richiede circa 80 minuti, programmalo in modo che venga eseguito non più di ogni 3 ore.
-
Limitazione oraria: il sistema non consente di programmare i test con una differenza di solo un'ora anche se la durata stimata del test è inferiore a un'ora.
Test simultanei
Ogni volta che viene eseguito un test di carico, la funzione task-runner AWS Lambda crea una CloudWatch dashboard Amazon denominata EcsLoadTesting-<testId>-<region>
in ciascuna regione in cui viene eseguito il test. La CloudWatch dashboard mostra l'output combinato di tutte le attività eseguite nel cluster Amazon ECS in tempo reale: tempo di risposta medio, numero di utenti simultanei, numero di richieste riuscite e numero di richieste non riuscite. La soluzione aggrega ogni metrica per secondo e aggiorna la dashboard ogni minuto.
Le esecuzioni successive dello stesso scenario di test aggiornano la stessa dashboard, quindi il tuo account contiene una dashboard per ogni scenario di test in ogni regione. Queste dashboard rimangono nel tuo account una volta completati i test. Sono soggette a un addebito mensile fino a quando non le elimini. La soluzione elimina le dashboard di uno scenario quando si elimina lo scenario di test (ad esempio, tramite la console web). Le dashboard non vengono eliminate quando si eliminano gli stack della soluzione. CloudFormation Per ulteriori informazioni, consulta la sezione Costo e la sezione Eliminazione manuale delle risorse conservate di questa guida.
Gestione degli utenti
Durante la configurazione iniziale, fornisci un nome utente e un indirizzo email che Amazon Cognito utilizza per concederti l'accesso alla console web della soluzione. La console non fornisce l'amministrazione degli utenti. Per aggiungere altri utenti, devi utilizzare la console Amazon Cognito. Per ulteriori informazioni, consulta la sezione Gestione degli utenti nei pool di utenti nella Amazon Cognito Developer Guide.
Per la migrazione degli utenti esistenti verso i pool di utenti di Amazon Cognito, consulta il blog AWS Approaches for migrating users to Amazon Cognito user pool.
Federazione del provider di identità
Il pool di utenti Amazon Cognito della soluzione supporta la federazione con provider di identità esterni (IdPs) utilizzando i protocolli SAML 2.0 o OpenID Connect (OIDC). La federazione consente agli utenti di accedere alla console web utilizzando le proprie credenziali aziendali o organizzative esistenti anziché le credenziali. Cognito-native Gli utenti federati ricevono le stesse autorizzazioni di accesso degli utenti creati direttamente nel pool di utenti Cognito.
La soluzione implementa già il pool di utenti, il dominio, il client dell'app e l'interfaccia utente ospitata di Cognito. Per abilitare la federazione, devi solo registrare il tuo provider di identità e abilitarlo sull'app client esistente.
Se si implementa l'integrazione opzionale del server MCP, anche gli utenti federati possono accedere al server MCP utilizzando le stesse credenziali del pool di utenti Cognito.
Prerequisiti
Prima di configurare la federazione, è necessario quanto segue:
-
Un provider di identità esterno che supporti SAML 2.0 o OIDC
-
Accesso amministrativo per configurare l'IdP esterno (per impostare URI di reindirizzamento o URL ACS)
-
L'ID del pool di utenti Cognito della soluzione (disponibile nelle risorse CloudFormation dello stack o nella console Amazon Cognito)
-
Il prefisso di dominio Cognito della soluzione (disponibile negli output CloudFormation dello stack o nella console Cognito in Integrazione app > Dominio)
Passaggio 1: configura il tuo provider di identità
Configura il tuo provider di identità esterno con i seguenti valori in modo che possa comunicare con il pool di utenti Cognito della soluzione.
Per i provider di identità SAML:
-
ID dell'entità SP:
urn:amazon:cognito:sp:_<UserPoolId>_ -
URL ACS:
\https://<cognito-domain>.auth.<region>.amazoncognito.com/saml2/idpresponse
Per i provider di identità OIDC:
-
URI di reindirizzamento:
\https://<cognito-domain>.auth.<region>.amazoncognito.com/oauth2/idpresponse
Per informazioni dettagliate sulle esigenze del tuo IdP, consulta Aggiungere provider di identità SAML a un pool di utenti o Aggiungere provider di identità OIDC a un pool di utenti nella Amazon Cognito Developer Guide.
Passaggio 2: registra il provider di identità in Cognito
Aggiungi il tuo provider di identità esterno al pool di utenti Cognito esistente della soluzione utilizzando la console Amazon Cognito.
Per istruzioni dettagliate, consulta Aggiungere l'accesso al pool di utenti tramite una terza parte nella Amazon Cognito Developer Guide.
Fase 3: Configurare le mappature degli attributi
Configura le mappature degli attributi tra le dichiarazioni del tuo provider di identità e gli attributi del pool di utenti Cognito. Come minimo, associa l'attestazione e-mail dell'utente inviata dal provider esterno all'attributo Cognito. email Prendi in considerazione anche la mappatura name o nickname se il tuo provider di identità li fornisce.
Per istruzioni, consulta Specificare le mappature degli attributi dei provider di identità per il tuo pool di utenti nella Amazon Cognito Developer Guide.
Passaggio 4: abilitare il provider di identità sul client dell'app
Nella console Amazon Cognito, trova il client dell'app creato dalla soluzione e abilita il tuo nuovo provider di identità nelle impostazioni dell'interfaccia utente ospitata.
Per istruzioni, consulta la sezione Configurazione di un client di app per pool di utenti nella Amazon Cognito Developer Guide.
Nota
La soluzione configura già gli URL di callback e disconnessione dell'app client, gli ambiti OAuth e il dominio dell'interfaccia utente ospitato. Non è necessario modificare queste impostazioni: abilita solo il tuo provider di identità sul client dell'app esistente.
Importante
La soluzione omette intenzionalmente la SupportedIdentityProviders proprietà dalla configurazione del client dell' CloudFormation app. Ciò consente di aggiungere provider di identità dopo l'implementazione senza attivare il rilevamento della deriva. CloudFormation Se questa proprietà fosse impostata nel modello, qualsiasi modifica manuale dell'IdP tramite la console o la CLI verrebbe sovrascritta al successivo aggiornamento dello stack, ripristinando nel client dell'app solo i provider elencati nel modello.
Poiché questa proprietà è omessa, CloudFormation non tiene traccia o gestisce i provider di identità abilitati sul client dell'app. Dopo aver configurato la federazione, sei responsabile della gestione dei contenuti dell'SupportedIdentityProvidersapp client. Per monitorare eventuali modifiche non autorizzate, abilita la CloudTrail registrazione di AWS e crea EventBridge regole Amazon per inviare avvisi CreateIdentityProvider e chiamate UpdateUserPoolClient API destinate al pool di utenti Cognito della soluzione.
Nota
-
L'aggiunta di un provider di identità esterno non rimuove la possibilità per Cognito-native gli utenti esistenti di accedere con le proprie credenziali correnti.
-
Gli utenti federati sono soggetti agli stessi vincoli di disponibilità regionali del pool di utenti Cognito. Per ulteriori informazioni, consulta la sezione Distribuzione regionale.
-
Prova l'accesso federato con un piccolo gruppo di utenti prima di implementarlo nella tua organizzazione.
Disattivazione o eliminazione dell'utente Cognito predefinito
Dopo aver configurato la federazione, potresti voler disabilitare o eliminare l'utente predefinito creato durante la distribuzione dello stack. Questa operazione è facoltativa: l'utente predefinito continua a lavorare insieme all'accesso federato.
Per disabilitare un utente, accedi al pool di utenti Cognito della soluzione nella console Amazon Cognito
Per maggiori dettagli, consulta la sezione Gestione e ricerca di account utente nella Amazon Cognito Developer Guide.
Implementazione regionale
Questa soluzione utilizza Amazon Cognito, disponibile solo in specifiche regioni AWS. Pertanto, è necessario distribuire questa soluzione in una regione in cui Amazon Cognito è disponibile. Per la disponibilità più aggiornata dei servizi per regione, consulta l'elenco dei servizi regionali AWS.
