Componenti della soluzione - Sala d'attesa virtuale su AWS

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à.

Componenti della soluzione

API pubbliche e private per sale d'attesa

Lo scopo principale della AWS soluzione Virtual Waiting Room on è controllare la generazione di JSON Web Tokens (JWT) per i client in modo controllato per evitare esplosioni di nuovi utenti che potrebbero sovraccaricare il sito Web di destinazione. I JWT possono essere utilizzati per la protezione del sito, impedendo l'accesso alle pagine Web fino all'ottenimento del token della sala d'attesa e anche per l'autorizzazione all'accesso all'API.

Il modello principale installa un'API pubblica e un'API privata (autorizzata da IAM) utilizzata per la maggior parte delle operazioni di Virtual Waiting Room. AWS L'API pubblica è configurata con una CloudFront distribuzione con più politiche di memorizzazione nella cache basate sul percorso dell'API. Vengono creati una tabella DynamoDB EventBridge e un bus eventi. Il modello aggiunge un nuovo VPC con due zone di disponibilità (AZ), un cluster ElastiCache per Redis in entrambe le AZ e diverse funzioni Lambda. Le funzioni Lambda che interagiscono con ElastiCache for Redis hanno interfacce di rete all'interno del VPC e tutte le altre funzioni Lambda hanno una connettività di rete predefinita. Le API principali rappresentano il livello più basso di interazione con la soluzione. Altre funzioni Lambda, l'istanza Amazon Elastic Compute Cloud (Amazon EC2) e i container possono fungere da estensioni e richiamare le API principali per creare sale d'attesa, controllare il traffico in ingresso e reagire agli eventi generati dalla soluzione.

Inoltre, lo stack principale genera un allarme per tutti gli errori della funzione Lambda e le condizioni di accelerazione, nonché allarmi per ogni implementazione di API Gateway per i codici di stato 4XX e 5XX.

Diagramma dei componenti della sala d'attesa virtuale sulle API pubbliche e private AWS

Sala d'attesa virtuale sul componente API pubbliche e private di AWS

  1. CloudFront la distribuzione fornisce chiamate API pubbliche per il client e memorizza nella cache i risultati laddove appropriato.

  2. L'API pubblica di Amazon API Gateway elabora le richieste di coda dalla sala d'attesa virtuale, monitora la posizione della coda e supporta la convalida dei token che consentono l'accesso al sito Web di destinazione.

  3. La coda SQS regola il traffico verso la funzione che elabora i AWS Lambda messaggi in coda.

  4. La funzione AssignQueueNum Lambda convalida ogni messaggio ricevuto nel batch, incrementa il contatore di coda ElastiCache per Redis e archivia ogni richiesta in Redis con la posizione di coda ElastiCache associata.

  5. La funzione GetPublicKey Lambda recupera il valore della chiave pubblica da Secrets Manager.

  6. La funzione GenerateToken Lambda genera un JWT per una richiesta valida a cui è stato consentito di completare la transazione nel sito di destinazione. Scrive un evento nel bus degli eventi personalizzato della sala d'attesa che indica che è stato generato un token. Se in precedenza è stato generato un token per questa richiesta, non viene generato alcun nuovo token.

  7. La funzione GetQueueNumber Lambda recupera e restituisce la posizione numerica del client nella coda di Redis. ElastiCache

  8. La funzione GetServingNumber Lambda recupera e restituisce il numero attualmente servito dalla ElastiCache sala d'attesa di Redis.

  9. La funzione GetWaitingNum Lambda restituisce il numero attualmente in coda nella sala d'attesa e non ha ancora ricevuto un token.

  10. Gli endpoint VPC consentono alle funzioni Lambda nel VPC di comunicare con i servizi all'interno della soluzione.

  11. ElastiCache for Redis cluster archivia tutte le richieste di accesso alla sala d'attesa con un Event ID valido. Memorizza inoltre diversi contatori come il numero di richieste in coda, il numero attualmente servito, il numero di token generati, il numero di sessioni completate e il numero di sessioni abbandonate.

  12. Risorse API private API Gateway per supportare le funzioni amministrative. Le API private sono autenticate da AWS IAM.

  13. La funzione GetExpiredTokens Lambda restituisce un elenco di ID di richiesta con token scaduti.

  14. La funzione AuthGenerateToken Lambda genera un token per una richiesta valida a cui è stato consentito di completare la transazione nel sito di destinazione. L'emittente e il periodo di validità di un token inizialmente impostati durante l'implementazione dello stack principale possono essere ignorati. Scrive un evento nel bus degli eventi personalizzato della sala d'attesa che indica che è stato generato un token. Se il token è stato precedentemente generato per questa richiesta, non viene generato alcun nuovo token.

  15. La funzione IncrementServingCounter Lambda incrementa il bancone di servizio della sala d'attesa memorizzato in ElastiCache Redis dato un incremento di valore.

  16. La funzione GetNumActiveTokens Lambda interroga DynamoDB per il numero di token che devono ancora scadere, non sono stati utilizzati per completare la transazione e non sono stati contrassegnati come abbandonati.

  17. La funzione ResetState Lambda reimposta tutti i contatori memorizzati in Redis. ElastiCache Inoltre, elimina e ricrea le tabelle TokenTableQueuePositionEntryTime, e DynamoDBServingCounterIssuedAt. Inoltre, esegue l'invalidazione della cache. CloudFront

  18. La funzione UpdateSession Lambda aggiorna lo stato di una sessione (token) memorizzata nella tabella DynamoDBTokenTable. Lo stato della sessione è indicato da un numero intero. Le sessioni impostate su uno stato pari a indicano che sono state completate e 1 -1 indicano che sono state abbandonate. Scrive un evento nel bus degli eventi personalizzato della sala d'attesa indicante che una sessione è stata aggiornata.

  19. La tabella TokenTable DynamoDB memorizza i dati dei token.

  20. La tabella QueuePositionEntryTime DynamoDB memorizza i dati sulla posizione della coda e sull'ora di immissione.

  21. La tabella ServingCounterIssuedAt DynamoDB memorizza gli aggiornamenti del contatore di servizio.

  22. La funzione GetQueuePositionExpireTime Lambda viene richiamata quando il client richiede il tempo di scadenza della posizione di coda rimanente.

  23. La funzione SetMaxQueuePositionExpired Lambda imposta la posizione massima della coda scaduta corrispondente ai valori della tabella. ServingCounterIssuedAt Viene eseguita ogni minuto se il IncrSvcOnQueuePositionExpiry parametro è impostato su true durante la distribuzione dello stack principale.

  24. La funzione GenerateEvents Lambda scrive diverse metriche della sala d'attesa nel bus eventi personalizzato della sala d'attesa. Viene eseguita ogni minuto se il parametro Enable Events Generation è impostato su true durante l'implementazione dello stack principale.

  25. AWS Secrets Manager archivia le chiavi per le operazioni con i token e altri dati sensibili.

  26. Amazon EventBridge Custom Event Bus riceve un evento ogni volta che viene generato un token e una sessione viene aggiornata nella tabella TokenTable DynamoDB. Riceve anche eventi quando il bancone di servizio viene spostato nella SetMaxQueuePositionExpired Lambda. Viene scritto con varie metriche relative alla sala d'attesa, se attivato durante l'implementazione del core stack.

  27. La regola CloudWatch degli eventi Amazon viene creata se il parametro Enable Events Generation è impostato su true durante la distribuzione dello stack principale. Questa regola di evento avvia la funzione GenerateEvents Lambda ogni minuto.

Authorizers

La soluzione include uno stack di autorizzazioni API Gateway Lambda. Lo stack è composto da un ruolo IAM e una funzione Lambda. La funzione APIGatewayAuthorizer Lambda è un autorizzatore per API Gateway in grado di convalidare la firma e le attestazioni di un token emesso dalla Virtual Waiting Room on API. AWS La funzione Lambda fornita con lo stack può essere utilizzata per proteggere le API cloud fino a quando un utente non ha attraversato la sala d'attesa e non riceve un token di accesso. L'autorizzatore recupera e memorizza automaticamente nella cache la chiave pubblica e la configurazione dall'API principale per la verifica dei token. Può essere utilizzato senza modifiche e può essere installato in qualsiasi AWS regione che lo supporti. AWS Lambda

Adattatore OpenID

Lo stack di adattatori OpenID implementa un API Gateway e funzioni Lambda che fungono da provider di identità OpenID. L'adattatore OpenID fornisce un set di API compatibili con OIDC che possono essere utilizzate con software di hosting web esistenti che supportano i provider di identità OIDC, come AWS Elastic Load Balancers, WordPress o come provider di identità federato per Amazon Cognito o un servizio simile. L'adattatore consente a un cliente di utilizzare la sala d'attesa nel flusso Authn/Authz quando utilizza un software di off-the-shelf web hosting con opzioni di integrazione limitate. Lo stack installa anche una CloudFront distribuzione con un bucket Amazon S3 come origine e un altro bucket S3 per la registrazione delle richieste. L'adattatore OpenID fornisce una pagina di sala d'attesa di esempio, simile a quella fornita nello stack di sala d'attesa di esempio, ma progettata per un flusso di autenticazione OpenID. Il processo di autenticazione prevede l'individuazione di una posizione nella coda della sala d'attesa e l'attesa che la posizione di servizio sia uguale o superiore a quella del cliente. La pagina della sala d'attesa OpenID reindirizza al sito di destinazione, che utilizza l'API OpenID per completare l'acquisizione del token e la configurazione della sessione per il client. Gli endpoint dell'API di questa soluzione vengono mappati direttamente alle specifiche di flusso name-for-name ufficiali di OpenID Connect 1.0,. Per i dettagli, fare riferimento a OpenID Connect Core 1.0 Authentication.

AWS Diagramma dei componenti dell'adattatore OpenID Virtual Waiting Room

Sala d'attesa virtuale sul AWS componente adattatore OpenID

  1. CloudFront la distribuzione fornisce il contenuto del bucket S3 all'utente.

  2. Il bucket S3 ospita pagine di esempio per le sale d'attesa.

  3. L'API Amazon API Gateway fornisce un set di API compatibili con OIDC che possono essere utilizzate con software di hosting Web esistenti che supportano la funzione di autorizzazione Lambda del provider di identità OIDC.

  4. La funzione APIHandler Lambda gestisce le richieste per tutti i percorsi di risorse API Gateway. Diverse funzioni Python all'interno dello stesso modulo sono mappate su ciascun percorso API. Ad esempio, il percorso della /authorize risorsa in API Gateway richiama la funzione authorize() Lambda.

  5. Le impostazioni OIDC sono memorizzate in Secrets Manager.

Esempi di strategie di ingresso

Le strategie di ingresso determinano quando il banco di servizio della soluzione deve passare ad accogliere più utenti nel sito di destinazione. Per ulteriori informazioni concettuali sulle strategie di ingresso nelle sale d'attesa, consulta Considerazioni di progettazione.

Esistono due esempi di strategie di ingresso fornite dalla soluzione: e periodica. MaxSize

AWS Diagramma dei componenti delle strategie di ingresso della sala d'attesa virtuale

Componente delle strategie Virtual Waiting Room on AWS Inlet

Opzione strategica di ingresso Max Size:

  1. Un client emette una notifica Amazon SNS che richiama la funzione MaxSizeInlet Lambda per aumentare il contatore di server in base al payload del messaggio.

  2. La funzione MaxSizeInlet Lambda prevede di ricevere un messaggio indicante che utilizza per determinare di quanto incrementare il contatore di servizio.

Opzione di strategia di ingresso periodica:

  1. Una CloudWatch regola richiama una funzione Lambda ogni minuto per aumentare il contatore di servizio di una quantità fissa.

  2. La funzione PeriodicInlet Lambda incrementa il contatore di servizio in base alla dimensione specificata se il tempo è compreso tra l'ora di inizio e quella di fine fornita. Facoltativamente, controlla un CloudWatch allarme e, se l'allarme è attivo, esegue l'incremento, altrimenti OK lo salta.

Esempio di sala d'attesa

La sala d'attesa di esempio si integra con le API pubbliche e private oltre all'autorizzatore personalizzato per dimostrare una soluzione minimale per le sale end-to-end d'attesa. La pagina Web principale viene archiviata in un bucket S3 e utilizzata come origine per. CloudFront Guida l'utente attraverso i seguenti passaggi:

  1. Mettiti in fila nella sala d'attesa per entrare nel sito.

  2. Ottieni la posizione del cliente in fila.

  3. Ottieni la posizione di servizio della sala d'attesa.

  4. Ottieni un set di token quando la posizione di servizio è uguale o superiore a quella del cliente.

  5. Usa il token per chiamare un'API protetta dall'autorizzatore Lambda.

Sala d'attesa virtuale (Esempio di diagramma dei componenti del sito dell'evento)

Sala d'attesa virtuale su AWS Sample Componente del sito dell'evento

  1. Il bucket S3 ospita il contenuto di esempio per la sala d'attesa e il pannello di controllo.

  2. CloudFront la distribuzione fornisce il contenuto del bucket S3 all'utente.

  3. Esempio di implementazione di API Gateway con percorsi di risorse simili allo shopping come e. /search /checkout Questa API viene installata dallo stack e configurata con il token authorizer. È inteso come esempio di un modo semplice per proteggere un'API con la sala d'attesa. Le richieste che presentano un token valido vengono inoltrate a Lambda, altrimenti viene restituito un errore. L'API non presenta funzionalità diverse dalla risposta della funzione Lambda allegata.