Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Considérations relatives à la conception
Options de déploiement
S'il s'agit de la première installation ou si vous ne savez pas quoi installer, déployez le CloudFormation modèle virtual-waiting-room-on-aws-getting-started.template imbriqué, qui installe le noyau, les autorisateurs et des exemples de modèles de salle d'attente. Vous disposez ainsi d'une salle d'attente minimale avec un flux simple.
Protocoles pris en charge
La AWS solution Virtual Waiting Room on peut être intégrée aux éléments suivants :
-
Bibliothèques et outils de vérification des jetons Web JSON
-
Déploiements d'API Gateway existants
-
Clients de l'API REST
-
Clients et fournisseurs OpenID
Stratégies d'entrée dans les salles d'attente
Les stratégies d'entrée encapsulent la logique et les données nécessaires pour déplacer les clients de la salle d'attente vers le site Web. Une stratégie d'entrée peut être implémentée sous la forme d'une fonction Lambda, d'un conteneur, d'une instance Amazon EC2 ou de toute autre ressource de calcul. Il n'est pas nécessaire qu'il s'agisse d'une ressource cloud tant qu'elle peut appeler les API publiques et privées de la salle d'attente. La stratégie d'entrée reçoit des événements concernant la salle d'attente, le site Web ou d'autres indicateurs extérieurs qui l'aident à décider quand un plus grand nombre de clients peuvent se faire émettre des jetons et accéder au site. Il existe plusieurs approches en matière de stratégies d'admission. Le choix que vous adopterez dépend des ressources mises à votre disposition et des contraintes liées à la conception du site Web à protéger.
La principale action entreprise par la stratégie d'entrée consiste à appeler l'API privée increment_serving_num Amazon API Gateway avec une valeur relative indiquant le nombre de clients supplémentaires autorisés à accéder au site. Cette section décrit deux stratégies d'entrée d'échantillons. Ils peuvent être utilisés tels quels, personnalisés ou vous pouvez utiliser une approche complètement différente.
MaxSize
À l'aide de MaxSize cette stratégie, la fonction MaxSizeInlet Lambda est configurée avec le nombre maximum de clients pouvant utiliser le site Web simultanément. Il s'agit d'une valeur fixe. Un client émet une notification Amazon SNS qui invoque la fonction MaxSizeInlet Lambda pour augmenter le compteur de service en fonction de la charge utile des messages. La source du message SNS peut provenir de n'importe où, y compris du code du site Web ou d'un outil de surveillance qui observe le niveau d'utilisation du site.
La fonction MaxSizeInlet Lambda s'attend à recevoir un message qui peut inclure :
-
exited :nombre de transactions terminées -
liste des identifiants de demandes à marquer comme terminés
-
liste des identifiants de demandes à marquer comme abandonnés
Ces données sont utilisées pour déterminer dans quelle mesure le compteur de service doit être incrémenté. Il peut arriver qu'il n'y ait pas de capacité supplémentaire pour augmenter le compteur, en fonction du nombre actuel de clients.
Périodique
Lorsque vous utilisez la stratégie périodique, une CloudWatch règle invoque la fonction PeriodicInlet Lambda toutes les minutes pour augmenter le compteur de service d'une quantité fixe. L'entrée périodique est paramétrée avec l'heure de début, l'heure de fin et le montant de l'incrément. Facultativement, cette stratégie vérifie également une CloudWatch alarme et, si l'alarme est OK active, elle effectue l'incrémentation, sinon elle l'ignore. Les intégrateurs du site peuvent connecter une métrique d'utilisation à une alarme et utiliser cette alarme pour suspendre l'entrée périodique. Cette stratégie ne modifie la position de service que lorsque l'heure actuelle se situe entre les heures de début et de fin, et éventuellement, l'alarme spécifiée est dans l'OKétat.
Personnalisation et extension de la solution
L'administrateur du site de votre organisation doit décider des méthodes d'intégration à utiliser avec la salle d'attente. Deux options s’offrent à vous :
-
Intégration de base directement à l'aide des API et des autorisateurs d'API Gateway.
-
Intégration d'OpenID via un fournisseur d'identité.
Outre l'intégration ci-dessus, vous devrez peut-être configurer la redirection du nom de domaine. Vous êtes également responsable du déploiement d'une page de site de salle d'attente personnalisée.
La AWS solution Virtual Waiting Room on est conçue pour être étendue grâce à deux mécanismes : EventBridge pour la notification unidirectionnelle des événements et les API REST pour la communication bidirectionnelle.
Quotas
La principale limite d'échelle pour Virtual Waiting Room on AWS est la limite d'accélération Lambda pour la région installée. AWS Lorsqu'elle est installée sur un AWS compte avec le quota d'exécution simultanée Lambda par défaut, la AWS solution Virtual Waiting Room on peut gérer jusqu'à 500 clients par seconde demandant une position dans la file d'attente. Le taux de 500 clients par seconde est basé sur le fait que toutes les limites de quotas simultanés de la fonction Lambda sont disponibles exclusivement dans la solution. Si la région du compte est partagée avec d'autres solutions qui invoquent des fonctions Lambda, la salle d'attente virtuelle de la AWS solution doit disposer d'au moins 1 000 appels simultanés disponibles. Vous pouvez utiliser CloudWatch des métriques pour cartographier les appels Lambda simultanés sur votre compte au fil du temps afin de prendre une décision. Vous pouvez utiliser la console Service Quotas
Pour chaque 500 clients supplémentaires par seconde, augmentez votre limite d'accélération de 1 000.
| Nombre d'utilisateurs entrants par seconde attendus | Quota d'exécution simultanée recommandé |
|---|---|
| 0 à 500 | 1 000 (par défaut) |
| 501 à 1 000 | 2 000 |
| 1 001 à 1 500 | 3 000 |
Lambda a une limite de rafale fixe de 3 000 appels simultanés. Pour plus d'informations, reportez-vous à la section Mise à l'échelle des fonctions Lambda. Le code client doit attendre et réessayer certains appels d'API si un code d'erreur est renvoyé indiquant une situation d'accélération temporaire. L'exemple de client de salle d'attente inclut ce code à titre d'exemple de conception de clients utilisés lors d'événements de grande capacité et de forte rafale.
Cette solution est également compatible avec la simultanéité réservée et provisionnée Lambda avec des étapes de configuration personnalisées. Pour plus de détails, reportez-vous à la section Gestion de la simultanéité réservée Lambda.
La limite supérieure d'utilisateurs pouvant entrer dans la salle d'attente, recevoir un jeton et poursuivre une transaction est limitée par la limite supérieure ElastiCache de quatre compteurs Redis. Les compteurs sont utilisés pour indiquer le poste de service de la salle d'attente et pour suivre l'état récapitulatif de la solution. Les compteurs utilisés dans Redis ont une limite supérieure ElastiCache de 9 223 372 036 854 775 807. Une table DynamoDB est utilisée pour stocker une copie de chaque jeton délivré à un utilisateur de la salle d'attente. DynamoDB n'impose aucune limite pratique quant à la taille d'une table.
Déploiements régionaux
Les services utilisés par cette solution sont pris en charge dans toutes les AWS régions. Pour connaître la disponibilité la plus récente des AWS services par région, consultez la liste des services AWS régionaux
