Hola a todos y bienvenidos de nuevo.
Ahora, en el vídeo de hoy, vamos a discutir acerca de la arquitectura de escalado basado en Amazon SKUs en una visión
general de alto nivel.
Ahora bien, en muchas de las organizaciones, el número de instancias EC dos que se estarían ejecutando en el entorno de
producción está directamente correlacionado con el número de mensajes que forman parte del rescate.
Por ejemplo, digamos que hay diez mensajes en la cola de EE.UU., y puesto que hay dos instancias
EC dos que se están ejecutando cada instancia EC dos se encargará y procesará cinco mensajes y después de procesarlos
suben los artefactos al bucket S3.
Supongamos que mañana hay una gran rebaja y en EE.UU. en lugar de diez mensajes hay 10.000
mensajes.
Ahora, como hay un número elevado de mensajes en la cola, hay dos opciones.
La primera es que sólo tienes dos instancias fáciles de ejecutar y el procesamiento de 10.000 mensajes te llevará mucho
tiempo.
Así que esa es la primera opción.
La segunda opción es aumentar el número de instancias de EC two que se están ejecutando en el entorno
de producción, digamos de 2 a 20.
Así que ahora 20 es dos instancias se están ejecutando, 10.000 mensajes serán procesados en forma mucho más rápida.
Sin embargo, aumentar el número de instancias de EC two también incrementará el coste.
Ahora, una vez finalizada la venta, el número de mensajes en la cola se ha reducido de 10.000
a diez.
Así que ahora lo que tienes que hacer, tienes que terminar la CE extra.
Dos instancias que estamos ejecutando para reducir el coste global.
Ahora, en un entorno de producción, se desea implementar este tipo de arquitectura en la que las dos instancias
de la CE se lanzan y terminan en función del número de mensajes en la cola.
De hecho, en muchas organizaciones se aplica este tipo de arquitectura.
En resumen, veamos rápidamente qué hay que hacer para conseguir este
tipo de arquitectura.
Ahora bien, si estás haciendo uso de un grupo de autoescalado, en estos casos puedes configurarlo para que lance o finalice
las instancias easy two en función del número de mensajes que formen parte del rescate.
Ahora, esto se puede explicar con este diagrama donde tienes una aplicación que está leyendo el número
de mensajes que forman parte de la cola y está almacenando los datos en cloud watch.
Ahora, dependiendo de los datos en cloud watch, el escalado automático lanza un nuevo conjunto de instancias o termina
el conjunto adicional de instancias que estamos ejecutando.
Ahora la pregunta que surge es ¿cómo sabe esta aplicación específica cuántos mensajes hay en
rescate?
Y la respuesta a esto es una de las seis columnas de atributos, número aproximado de mensajes.
Así que vamos a investigarlo rápidamente.
Ahora, para la demostración de hoy, tengo un rescate y hay dos mensajes que están disponibles.
Así, si abrimos el rescate, obtendremos la URL de la cola.
A partir de esta URL, puede comprobar cuántos mensajes hay.
Así que vamos a investigarlo rápidamente.
Así que tengo un comando CLI nos llaman ocho obtener atributos, especificamos la cola URL por aquí y especificamos el
nombre del atributo y el nombre del atributo aquí es número aproximado de mensajes.
Esto es muy similar a lo que estábamos discutiendo y la región es AP Sudeste uno.
Ahora si pulso rápidamente enter aquí, ves que el número de mensajes que está mostrando es dos y esto es lo mismo
que la aplicación puede hacer y puede publicarlo a un servicio central desde el cual el auto escalado
lanzará y terminará las instancias según sea necesario.
Así que este es uno de los diseños de arquitectura que se puede implementar en caso de que si usted tiene un caso de uso en el
que desea lanzar y terminar instancias basadas en el número de mensajes.
Con esto concluiremos el vídeo de hoy.