Implementando Escalabilidad, Alta Disponibilidad y Monitorización en una Arquitectura de AWS

Introducción

El objetivo de este ejercicio técnico es diseñar e implementar una arquitectura en AWS para un portal web, con requisitos de alta disponibilidad, tolerancia a fallos y monitoreo eficiente. Utilizaremos servicios como ASG, EC2, ALB. S3, CloudWatch y SNS.

Descripción General

Podemos ver los componentes principales organizados en diferentes capas, desde la capa de la nube de AWS, pasando por la región y la VPC. Un grupo de auto escalado será el encargado de lanzar o disminuir instancias que consumirán contenido estático desde S3. Por otro lado, el balanceador de carga redistribuirá las peticiones de los usuarios entre las instancias disponibles en nuestro ASG. Cuando una nueva instancia sea lanzada, el ASG enviará una notificación a un tema de SNS y los suscriptores de ese tema recibirán un correo electrónico. CloudWatch monitoreará nuestra arquitectura y activará una alarma cuando una instancia sea terminada, enviando una notificación a un tema de SNS para que los suscriptores reciban una notificación por correo electrónico. Además de monitorear métricas para alarmas independientes, también es parte de la implementación de políticas de auto escalado.

Comenzaremos creando las cosas más básicas pero indispensables para nuestra arquitectura:

1. Crear un Bucket de S3, asigna un nombre descriptivo, habilita el versionado y mantenlo como privado, el resto de las opciones déjalas como predeterminadas, una vez creado el bucket carga un archivo html con el nombre index.html que se mostrara en tu aplicación, puedes descargar mi index.html desde el siguiente repositorio GitHub

2. Rol de servicio EC2: Este rol contendrá políticas de acceso a S3 y CloudWatch, estas políticas permitirán que nuestras instancias copien el archivo index.html desde S3 y que nuestras instancias envíen métricas e interactúen con CloudWatch para crear o modificar alarmas asi como el envio de logs entre otras funcionalidades, vayamos al servicio de IAM para crear el rol.

• Crear Rol

• Rol de servicio

• Casos de uso: EC2

• En politicas asignaremos las ya mencionadas:

1. Grupos de seguridad: Debemos crear 2 grupos de seguridad uno para nuestras instancias y el segundo para nuestro balanceador de carga los cuales permitiran o no el trafico entrante de acuerdo a las reglas de trafico de entrada que asignemos.

Vamos al servicio EC2, en la columna izquierda, "security groups" y creamos el primer grupo para la nuestra web en mi caso le di el nombre de SG-Web-App-Madriz y contiene las siguientes reglas de entrada

El segundo grupo de seguridad es para nuestro ALB yo lo llame "SG-alb-web-madriz" y solo permite trafico http.

Balanceador de carga

Un balanceador de carga ALB (Application Load Balancer) en AWS distribuye automáticamente el tráfico entrante entre múltiples instancias de EC2 en nuestro caso, en diferentes zonas de disponibilidad, optimizando la disponibilidad y la capacidad de respuesta de la aplicación.

Este recurso también se crea desde la sección de EC2, columna izquierda y sección "Balanceadores de carga"

• Crear balanceador de carga de tipo ALB

• Asignamos un nombre en mi caso "alb-asg-web-madriz"

• En esquema: El ALB debe estar expuesto a internet, "Internet facing"

• Tipo de dirección: IPv4

• Mapeo: Seleccionaremos las tres zonas de disponibilidad que aparecen. Un balanceador de carga debe ser capaz de enviar tráfico al menos a dos zonas de disponibilidad, asignando una subred por zona. Esto asegura que nuestra arquitectura sea tolerante a fallos y altamente disponible, ya que, si una zona de disponibilidad falla, el tráfico se redirigirá automáticamente a las instancias en las otras zonas.

• En la seccion del grupo de seguridad seleccionamos el grupo de seguridad creado para el ALB en la primera seccion de este laboratorio, en mi caso lo nombre "SG-alb-web-madriz"

• Agentes de Escucha y Direccionamiento
  Agentes de Escucha: Los agentes de escucha están configurados con el puerto en el que el ALB (Application Load Balancer) escuchará las solicitudes entrantes, como el puerto 80 para HTTP y el puerto 443 para HTTPS.

Grupos de Destino: Son contenedores de instancias donde el balanceador de carga dirigirá el tráfico, considerando la salud de cada instancia, su capacidad y la estrategia de balanceo de carga.

Nuestra arquitectura utilizará un grupo de autoescalado (ASG) que lanzará o terminará instancias según la demanda de nuestra aplicación. Debemos crear este grupo de destino vacío. Al configurar el ASG, gestionaremos cómo cada instancia lanzada se agregará automáticamente a este grupo de destino.

Al crear el grupo de destino debemos especificar lo siguiente:

• El tipo de grupo de destino es de: Instancias

• Asigna un nombre al grupo de destino

• Elija un puerto y protocolo para nuestro grupo destino en este caso eligiremos puerto 80 para HTTP.

• Lo demas queda como preterminado (IPv4, vpc default, version de protocolo, protocolo de comprobacion de estado HTTP)

Nota: Cuando eliges el protocolo y puerto en el grupo de destino, estás definiendo el protocolo y puerto en el que cada instancia en el grupo estará escuchando el tráfico reenviado por el ALB

• El siguiente paso es registrar instancias dentro del grupo destino, pero como nuestras instancias seran levantadas por ASG no debemos especificar ninguna, solo crear el grupo vacio, en el caso que nuestra app no tenga auto escalado y tenga un numero especifico de instancia creadas por nosotros si debemos incluirlas en este grupo.

• Una vez creado el grupo de destino ahora si podemos elegirlo en la lista desplegable en el apartado de agentes de escucha y direccionamiento.

• Para finalizar revisaremos el resumen y crearemos nuestro ALB, así que, damos por terminada esta sección de ALB.

Creando ASG

• Ir al apartado de EC2 en la consola de AWS

• En la columna izquierda al final ubicar "Auto scaling"

• Creemos un grupo de auto scaling

• Debemos asignar un nombre a nuestro grupo de auto escalado y elegir una plantilla de lanzamiento, si te estas preguntando "con que se come eso", no te preocupes ya te lo explico.

Platilla de lanzamiento

Una plantilla de lanzamiento es un conjunto de configuraciones iniciales que tendrá cada instancia que nuestro grupo de autoescalado (ASG) inicie. Se llama plantilla porque es una configuración única que el ASG usará para todas las instancias que lance, asegurando que, independientemente de la instancia a la que el usuario sea dirigido por el balanceador de carga (ALB), verá la misma aplicación. Esto garantiza la consistencia y uniformidad en todas las instancias del ASG.

• Asignar nombre al ASG y luego seleccionamos crear plantilla de lanzamiento, si no tienes ninguna.

• Asignamos un nombre a nuestra plantilla y descripción

Las siguientes configuraciones son las mismas que utilizamos cuando creamos una instancia EC2, con un ligero cambio en la sección de configuración avanzada. Si nunca has creado una instancia EC2, te dejo un laboratorio donde explico los detalles paso a paso. Como crear una instancia EC2 y conectarme con SSH

• Seleccionamos inicio rapido y elegimos la AMI de amazon linux

• Tipo de instancia t2.micro es suficiente para el proposito de este taller.

• El siguiente paso es crear un par de claves de seguridad, recuerda que esto nos ayudara a establecer conexion desde nuestro computador a nuestras instancias.

• En grupos de seguriad elegiremos el grupo creado en la primera seccion, recuerda que creamos uno para el ASG y otro para el ALB, en mi caso le di el nombre "SG-Web-App-Madriz" la unica diferencia que tiene uno del otro es que este grupo de seguridad permite trafico HTTP y SSH mientras que el grupo del ALB solo permite trafico HTTP.

Nota: Ya en otros talleres hemos creado instancias, llaves seguras, grupos de seguridad, por eso no estoy profundizando en estas caracteristicas basicas.

Nos desplazaremos hasta la seccion de configuraciones avanzadas, atencion aqui:

• El primer parametro es el Perfil de la instancia: Un perfil de instancia en AWS es una entidad que permite a las instancias EC2 obtener permisos para interactuar con otros servicios de AWS mediante la asociación de un rol de IAM

• Elegiremos el rol que creamos al inicio de este laboratorio que ya contiene las politicas necesarias que necesitan nuestras instancias.

• Iremos hasta la seccion User-Data: El apartado user-data en AWS permite especificar scripts o comandos que se ejecutan automáticamente al iniciar una instancia EC2, utilizado comúnmente para configuraciones iniciales o instalación de software.

A continuacion te dejo el codigo a implementar en este apartado, solo debes reemplazar el nombre del bucket con el nombre que hayas usado.

#!/bin/bash

# Actualizando el sistema
yum update -y

# Instalando apache
yum install -y httpd

# Iniciando apache
systemctl start httpd

# Habilitar Apache para que se inicie automáticamente al arrancar el sistema
systemctl enable httpd

# Instalar AWS CLI
yum install -y aws-cli

# Mueve el archivo HTML desde el bucket S3 a la instancia, coloca el nombre de tu bucket
aws s3 cp s3://your-bucket/index.html /var/www/html/index.html

# Reiniciar Apache para aplicar los cambios
systemctl restart httpd

También puedes encontrar este archivo en el Repositorio GitHub, solo debes pegar este código o adjuntar el archivo en el recuadro user-data

En este punto ya tienes todo para crear tu plantilla de lanzamiento y ahora puede ser elegida para que a partir de dicha plantilla podamos crear nuestro grupo de auto escalado.

• Hacemos clic en 'Siguiente' y accedemos a las configuraciones de red. Elegiremos la VPC por defecto que estamos usando y seleccionaremos las tres zonas de disponibilidad disponibles en la lista desplegable. Esto asegura que nuestro ASG cubra dichas zonas y pueda lanzar instancias EC2 en cada una de ellas, garantizando así alta disponibilidad

• En el siguiente paso es hora de elegir nuestro balanceador de carga y grupo destino creado anteriormente asi que elegimos la opcion "Asociar balanceador de carga existente" pueden notar que en la lista desplegable aparece el nombre del grupo y a que balanceador de carga pertenece.

• Nos desplazamos hasta las comprobaciones de estado y elegimos "Activar las comprobaciones de estado de Elastic Load Balancing" esto hace que nuestro ALB compruebe el estado de nuestras instancias antes de enviarle trafico, cuando el ALB informe sobre una instancia en mal estado el grupo ASG reemplazara dicha instancia.

• Habilitamos también la recopilación de métricas del ASG para que sean enviadas a CloudWatch y hacer uso de alarmas basadas en métricas, click en siguiente.

• Capacidad Deseada: La definiremos en 2. En condiciones normales, nuestra aplicación tendrá 2 instancias activas en el grupo ASG. Si una instancia se termina por error o cualquier otro motivo, una nueva instancia será lanzada para mantener la capacidad deseada de 2.

• Capacidad Mínima: La definiremos en 1. Nuestro ASG puede escalar hacia abajo hasta un mínimo de 1 instancia. Dado que la capacidad deseada es 2, el ASG solo escalará a 1 si una política de escalado lo indica, en función de la demanda.

• Capacidad Máxima: La definiremos en 3. Si implementamos una política de autoescalado que observe la alta demanda de la aplicación, el ASG escalará como máximo a 3 instancias.

Esto asegura que nuestra arquitectura sea flexible y pueda adaptarse a diferentes niveles de demanda, manteniendo siempre un rendimiento óptimo.

• Añadir notificación: Dentro de la configuración de nuestro ASG podemos activar notificaciones de SNS para que usuarios suscritos a un tema reciban un mensaje cuando el ASG lance o termine instancias.

• Si no tienes un tema debes crear uno, especifica el nombre del tema, los correos electrónicos de los suscriptores que recibirán la notificación.

• Puedes activar todos los eventos, pero para este laboratorio activaremos solo el evento de lanzamiento de una nueva instancia, el evento de cuando una instancia se termine lo haremos con CloudWatch más adelante.

• Es hora de revisar todos los parámetros establecidos en nuestro ASG, si todo está en orden procedemos a crear el grupo de auto escalado.

Inmediatamente el ASG levantara las instancias deseadas con la configuración especificadas en el user-data que además de instalar y poner en marcha apache, acceder al bucket S3 y copiar el archivo index.html

Revisando funcionamiento:

• Vayamos a la consola de EC2 y entremos a la sección de balanceadores de carga, seleccionemos nuestro balanceador de carga y en la pestaña detalles copiemos el nombre de DNS.

Pegamos el nombre de DNS en el navegador y veremos nuestra App.

|

Revisando Instancias

Vayamos al apartado de instancias para verificar que la cantidad de instancias desplegadas cumple con lo especificado en nuestro ASG al momento de crearlo.

Podemos observar que el numero de instancias desplegadas es 2, esto cumple con lo establecido en la capacidad deseada de nuestro ASG.

Antes de realizar pruebas de escalado, agreguemos monitorizacion a nuestra arquitectura.

Monitoreo con CloudWatch

Las alarmas de cloudWatch pueden ser creadas de manera individual utilizando métricas de instancia o ASG, una vez estas métricas alcancen ciertos umbrales dichas alarmas harán alguna acción bien sea enviar un mensaje SNS o activar una política de escalado, en nuestro caso queremos que una alarma se active cuando una instancia sea terminada y nos envié un mensaje por correo electrónico.

• Dirígete a CloudWatch hasta el apartado de alarma

• Crear una alarma y elegir métrica: En este punto queremos medir una métrica que es enviada desde el grupo ASG a CloudWatch.

• Seleccionar Auto Scaling como el servicio de donde se obtendrá la métrica

• Métricas de grupo: En este punto veras una lista de métricas que puedes seleccionar para crear una alarma para este laboratorio usaremos la métrica "GroupTerminatingInstances"

• Seleccionar métrica y pasar al siguiente apartado

• Veras el nombre la métrica

• El grupo ASG del cual proviene la métrica

• Elige la estadística que quieres medir, para este laboratorio usaremos la media.

• El periodo será de 5 minutos

• La condición será que cuando en un periodo de 5 minutos la media de instancias terminadas en nuestro ASG sea mayor o igual a 1 una alarma sea activada.

Que haremos con la alarma?

• Cuando nuestra arquitectura este en modo alarma enviara una notificación SNS a los suscriptores de un tema, podemos elegir el mismo que creamos en el ASG.

• Establece un nombre a la alarma y opcionalmente un mensaje personalizado, en mi caso dejare el prederminado.

Ahora si podemos hacer pruebas de escalado:

• Apaga una de las instancias y una alarma de CloudWatch se activara y un correo electronico recibiras alertandote.

Instancia terminada:

Modo alarma activada porque se cumplio la condicion especificada:

Una notificacion se envio al correo electronico del suscriptor especificado en el tema SNS.

Adicionalmente podemos chequear que nuestro ASG cumpliendo con la capacidad deseada de 2 instancias ya levanto una nueva instancia.

Notificacion SNS por lanzamiento de una nueva instancia:

Con esto hemos puesto a prueba nuestra arquitectura, nuestra App funciona, cuando terminamos una instancia el ALB lo detecta y dirige el tráfico a las únicas instancias saludables es por eso que al terminar una instancia si refrescamos el navegador nuestra App seguirá disponible sin mostrar error para la instancia que está terminada, por otro lado cuando la instancia está terminada una alarma de CloudWatch se activa y envía una notificación de SNS, además nuestro ASG en cumplimiento con la capacidad deseada lanza una nueva instancia y envía una notificación de SNS que informa que una nueva instancia fue lanzada.

Espero que hayan aprendido mucho, no olviden dejar sus interacciones, preguntas o dudas, pueden utilizar esta arquitectura como base e implementar más funcionalidades y así seguir aprendiendo.

Hasta la próxima.