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, tra cui applicazioni supportate, tipi di test, opzioni di pianificazione e considerazioni sulla distribuzione.
Applicazioni supportate
Questa soluzione supporta il test di applicazioni basate su cloud e applicazioni locali purché sia disponibile la connettività di rete dal tuo account AWS all'applicazione. La soluzione supporta API che utilizzano protocolli HTTP o HTTPS.
Tipi di test
Distributed Load Testing su AWS supporta diversi tipi di test: semplici test degli endpoint HTTP, JMeter, K6 e Locust.
Nota
La soluzione distribuisce JMeter, K6 e Locust come componenti di terze parti senza modifiche. Per considerazioni sulla sicurezza, opzioni di applicazione delle patch e informazioni sulla licenza, consulta i 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, ecc.) da un menu a discesa e, facoltativamente, aggiungere intestazioni di richiesta e payload body 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 richiesto dall'applicazione.
Quando configurate un endpoint HTTP, la soluzione converte la configurazione in un piano di test che viene eseguito dal binario Apache JMeter fornito 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 bundle. Se devi eseguire test sugli endpoint HTTP con un JMeter aggiornato, usa invece il tipo di test JMeter. Per considerazioni sulla sicurezza, consulta Apache JMeter.
Test JMeter
Quando crei uno scenario di test utilizzando la console web, puoi 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
Sebbene lo script JMeter possa definire concorrenza (utenti virtuali), tassi di transazione (TPS), tempi di accelerazione e altri parametri di caricamento, la soluzione sostituirà queste configurazioni con i valori specificati nella schermata Traffic Shape durante la creazione del test. La configurazione Traffic Shape controlla il numero di attività, la concorrenza (utenti virtuali per attività), la durata di avvio e la durata di attesa per l'esecuzione del test.
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 fornito in bundle verranno copiati nella directory delle estensioni di JMeter e saranno disponibili per il test di carico.
Nota
Se includi file di input JMeter nel tuo file di script JMeter, devi includere il percorso relativo dei file di input nel tuo file di script JMeter. Inoltre, i file di input devono trovarsi nel percorso relativo. Ad esempio, se 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_INPUT. Se invece usi/home/user/INPUT_FILES, il test fallirà perché non sarà in grado di trovare i file di input.
Se includi i 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, consulta il Manuale dell'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 visualizza un messaggio di conferma della licenza quando crei un nuovo test K6; per i dettagli sulla licenza e sulla sicurezza, consulta Grafana K6.
Importante
Sebbene lo script K6 possa definire concorrenza (utenti virtuali), fasi, soglie e altri parametri di carico, la soluzione sostituirà queste configurazioni con i valori specificati nella schermata Traffic Shape durante la creazione del test. La configurazione Traffic Shape controlla il numero di attività, la concorrenza (utenti virtuali per attività), la durata di avvio e la durata di attesa per l'esecuzione del test.
Test Locust
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
Sebbene lo script Locust possa definire la concorrenza (conteggio utenti), la frequenza di spawn e altri parametri di caricamento, la soluzione sostituirà queste configurazioni con i valori specificati nella schermata Traffic Shape durante la creazione del test. La configurazione Traffic Shape controlla il numero di attività, la concorrenza (utenti virtuali per attività), la durata di avvio e la durata di attesa per l'esecuzione del test.
Pianificazione dei test
La soluzione offre tre opzioni di tempistica di esecuzione per l'esecuzione dei test di carico:
-
Esegui ora: esegue il test di carico subito dopo la creazione
-
Esegui una volta: esegui il test in una data e un'ora specifiche future
-
Esegui secondo una pianificazione: crea test ricorrenti utilizzando le espressioni cron per definire la pianificazione
Quando si seleziona Esegui una volta, si specifica il tempo di esecuzione nel formato a 24 ore e la data di esecuzione in cui deve iniziare l'esecuzione del test di carico.
Quando selezioni Esegui su una pianificazione, puoi inserire 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 preciso con campi per minuti, ore, giorno del mese, mese, giorno della settimana e anno. È inoltre necessario specificare una data di scadenza, che definisce quando l'esecuzione del test programmato deve cessare. Per ulteriori informazioni su come funziona la pianificazione, consulta la sezione Flusso di lavoro di pianificazione dei test di questa guida.
Nota
-
Durata del test: durante la pianificazione, considera la durata totale dei test. Ad esempio, il completamento di un test con un tempo di accelerazione di 10 minuti e un tempo di attesa di 40 minuti richiederà circa 80 minuti.
-
Intervallo minimo: assicurati che l'intervallo tra i test programmati sia più lungo della durata stimata del test. Ad esempio, se il test dura 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
Questa soluzione crea una CloudWatch dashboard Amazon per ogni test che mostra l'output combinato di tutte le attività in esecuzione nel cluster Amazon ECS in tempo reale. La CloudWatch dashboard mostra il tempo di risposta medio, il numero di utenti simultanei, il numero di richieste riuscite e il numero di richieste non riuscite. La soluzione aggrega ogni metrica al secondo e aggiorna la dashboard ogni minuto.
Gestione degli utenti
Durante la configurazione iniziale, fornisci un nome utente e un indirizzo e-mail 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 ai pool di utenti di Amazon Cognito, consulta il blog di AWS Approaches for migrating users to Amazon Cognito
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 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 di 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 sul client dell'app esistente.
Se si implementa l'integrazione opzionale MCP Server, gli utenti federati possono accedere al server MCP anche 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 dello CloudFormation stack o nella console Amazon Cognito)
-
Il prefisso del dominio Cognito della soluzione (disponibile negli CloudFormation stack output 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.
Fase 2: Registrare 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 la sezione 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 di Cognito. Come minimo, associa la dichiarazione di posta elettronica dell'utente dal provider esterno all'attributo Cognitoemail. 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 del 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 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 del client dell'app, 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 CloudFormation il rilevamento della deriva. 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 il client dell'app ai soli provider elencati nel modello.
Poiché questa proprietà viene 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 del SupportedIdentityProviders client dell'app. Per monitorare eventuali modifiche non autorizzate, abilita la CloudTrail registrazione di AWS e crea EventBridge regole Amazon per avvisare CreateIdentityProvider e chiamate UpdateUserPoolClient API destinate al pool di utenti Cognito della soluzione.
Nota
-
L'aggiunta di un provider di identità esterno non elimina 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 di Cognito. Per ulteriori informazioni, consulta la sezione Distribuzione regionale.
-
Prova l'accesso federato con un piccolo gruppo di utenti prima di distribuirlo alla 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. Questo è facoltativo: 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 ulteriori dettagli, consulta la sezione Gestione e ricerca degli account utente nella Amazon Cognito Developer Guide.
Implementazione regionale
Questa soluzione utilizza Amazon Cognito, disponibile solo in regioni AWS specifiche. Pertanto, è necessario distribuire questa soluzione in una regione in cui è disponibile Amazon Cognito. Per la disponibilità dei servizi più aggiornata per regione, consulta l'AWS Regional Services List
