Bonjour, tout le monde, et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons discuter de l'architecture de la mise à l'échelle basée sur les UGS
d'Amazon à un niveau élevé.
Or, dans de nombreuses organisations, le nombre d'instances EC two qui fonctionneraient dans l'environnement
de production est en corrélation directe avec le nombre de messages faisant partie du sauvetage.
Par exemple, disons qu'il y a dix messages dans la file d'attente US, et comme il y a deux instances EC
two en cours d'exécution, chaque instance EC two va prendre en charge et traiter cinq messages et, après le traitement,
télécharger les artefacts dans le seau S3.
Imaginons que demain, il y ait une grande vente et qu'aux États-Unis, au lieu de dix messages,
il y en ait 10 000.
Maintenant, comme il y a un grand nombre de messages dans la file d'attente, il y a deux options.
La première est que vous n'avez que deux instances faciles à utiliser et que le traitement de 10 000 messages prend beaucoup
de temps.
C'est donc la première option.
La deuxième option consiste à augmenter le nombre d'instances EC two qui fonctionnent dans l'environnement
de production, disons de 2 à 20.
Ainsi, maintenant, 20 est deux instances fonctionnent, 10 000 messages seront traités beaucoup plus rapidement.
Toutefois, l'augmentation du nombre d'instances EC two entraîne également une augmentation du coût.
Maintenant, une fois la vente terminée, le nombre de messages dans la file d'attente a été ramené de 10 000
à dix.
Donc maintenant, ce que vous devez faire, c'est terminer la CE supplémentaire.
Deux instances que nous exécutons pour réduire le coût global.
Maintenant, dans un environnement de production, vous voulez mettre en œuvre ce type d'architecture où deux instances
EC sont lancées et terminées en fonction du nombre de messages dans la file d'attente.
Et en fait, dans beaucoup d'organisations, vous verrez ce genre d'architecture mise en œuvre.
Pour avoir une vue d'ensemble de haut niveau, examinons rapidement ce qu'il faut faire pour
réaliser ce type d'architecture.
Maintenant, si vous utilisez un groupe de mise à l'échelle automatique, dans ce cas vous pouvez le configurer pour lancer ou
terminer les deux instances faciles en fonction du nombre de messages qui font partie du sauvetage.
Cela peut être expliqué à l'aide de ce diagramme où vous avez une application qui lit le nombre de messages
qui font partie de la file d'attente et qui stocke les données dans le cloud watch.
Maintenant, en fonction des données dans la surveillance du nuage, la mise à l'échelle automatique lance un nouvel ensemble d'instances
ou met fin à l'ensemble supplémentaire d'instances que nous exécutons.
Maintenant, la question qui se pose est la suivante : comment cette application spécifique sait-elle combien de messages il y a dans
le sauvetage ?
Et la réponse à cette question est l'une des six colonnes d'attributs, le nombre approximatif de messages.
Alors allons-y et examinons-la rapidement.
Maintenant, pour la démo d'aujourd'hui, j'ai un sauvetage et il y a deux messages disponibles.
Donc si on ouvre le secours, on obtient l'URL de la file d'attente.
Et sur la base de cette URL, vous pouvez vérifier combien de messages sont présents.
Alors allons-y et examinons-la rapidement.
J'ai donc une commande CLI call us eight us get attributes, nous spécifions l'URL de la file d'attente ici et nous spécifions
le nom de l'attribut et le nom de l'attribut ici est le nombre approximatif de messages.
C'est très similaire à ce dont nous discutions et la région est celle du Sud-Est.
Maintenant, si j'appuie rapidement sur la touche entrée ici, vous voyez que le nombre de messages qu'il montre est de deux et c'est
la même chose que l'application peut faire et elle peut le publier à un service central à partir duquel la mise à
l'échelle automatique lancera et terminera les instances selon les besoins.
C'est donc l'une des conceptions architecturales qui peut être mise en œuvre si vous avez un cas d'utilisation où vous voulez
lancer et terminer des instances en fonction du nombre de messages.
C'est ainsi que se termine la vidéo d'aujourd'hui.