Blog 

Construyendo arquitecturas altamente escalables

Con Amazon Web Services

A menudo vemos en grupos de emprendimiento de Facebook, o alguna otra red social, miles de Zuckerbergs buscando personas que desarrollen la plataforma que tienen en mente (que en general termina siendo un Uber para algún servicio). Muchas veces salen oferentes regalando su trabajo por 200 lucas, aceptable y respetable obvio, pero yo me pregunto, ¿será que quiere subir esa plataforma a un servidor de 27 lucas al año?, ¿qué pasará si al Zuckerberg le va bien y llega a millones de usuarios?… ¿aguantará?

Construyendo arquitecturas altamente escalables

NO!!!

Pero por otro lado, ¿a todos les va bien?, claramente no. Entonces, ¿tenemos que preocuparnos de esto si ni siquiera tengo la certeza de que me va a ir bien?, ¿para qué voy a pagar por un servidor de 1.000 USD al mes si ni siquiera sé si me va a llegar mi millón de usuarios?

Construyendo arquitecturas altamente escalables

!!!NO ES NECESARIO SOBRE APROVISIONAR!!!

Por suerte no necesitamos ser como el tipo de la foto. Tenemos a Amazon Web Services que nos ayuda a optimizar este proceso de tan alta incertidumbre.

Haciendo altamente escalable una arquitectura en AWS

En este post desarrollamos una aplicación simple, alojada en AWS:Despliegue de aplicaciones Ruby On Rails
Con Capistrano y Amazon EC2medium.com

Esta aplicación es un blog, desarrollado en RAILS y desplegado en una EC2 (Elastic Compute Cloud) de AWS, de las más pequeñas y baratas, que se seguro quedará pequeña en caso de que tu aplicación tenga una crecida repentina de usuarios. Asumiremos que leíste este artículo previamente, así que usaremos algunos conceptos explicados ahí.

Consideremos la siguiente instancia:

Construyendo arquitecturas altamente escalables
Instancia de la familia t3.micro

Primero y necesario para hacer que la aplicación escale, es hacer que la aplicación no dependa de una sola maquina y darle una referencia a AWS para saber desde dónde partir en caso de necesitar levantar una nueva instancia. Para eso existen las AMIs. Que en términos simples es una receta para que la plataforma levante nuevas maquinas a partir de una ya existente.

Construyendo arquitecturas altamente escalables
Creando una AMI a partir de una instancia

Una vez mandada la solicitud para crearla, se debe ir a la sección respectiva de AMIs en el menú lateral:

Construyendo arquitecturas altamente escalables
Menú lateral AWS

La creación de la AMI se tarda un momento, ya que debe hacer la receta considerando todo: configuraciones, datos, la misma aplicación, etc.

Una vez ya creada la imagen, nos debería aparecer de la siguiente forma:

Construyendo arquitecturas altamente escalables
AMI Privada creada

Luego, teniendo ya la receta de la AMI podemos levantar nuevas instancias a partir de ella, solo presionando el click derecho y seleccionando “Launch”:

Construyendo arquitecturas altamente escalables

Ahora, teniendo varias instancias que contienen la misma aplicación, se hace necesario poder balancear la carga de usuarios entre ellas, ¿no?; porque de otra forma estaríamos desde el dominio apuntando a la ip de alguna de ellas, y la otra quedaría sin uso y malgastando los recursos. Por lo que hay que poner una capa intermedia que se preocupe de repartir la carga de usuarios. Esta capa se llama Balanceador de Carga, ALB para AWS.

Bueno, a crearlo. Desde el menú lateral ir a “LOAD BALANCING” justo abajo de “NETWORK & SECURITY”. Luego en el sub-menú a Load Balancers. Esto direccionará al mantenedor de balanceadores de carga.

Construyendo arquitecturas altamente escalables

Haz click en el botón Create Load Balancer.

Construyendo arquitecturas altamente escalables

Selecciona el ALB (Application Load Balancer). Ya que nuestro objetivo es balancear la carga de solicitudes a la aplicación (Capa 7). El Network Load Balancer es para balanceo de carga a nivel de red (Capa 4), que no es el objetivo de este artículo.

Una vez seleccionado el ALB, se nos mostrará el formulario de creación, que es el siguiente:

Construyendo arquitecturas altamente escalables
Formulario de creación de ALB en AWS

Básicamente:

  • En Name poner él como queremos identificar el balanceador. En general se definen reglas de nombrado, como por ejemplo: “APPNAME-ALB”. De esta forma identificamos la aplicación y el tipo de balanceador.
  • Se selecciona para que sea “internet-facing”, porque claramente queremos que este disponible en Internet para nuestros usuarios. IP Address Type, déjalo así nomas. No es necesario dejarlo en ipv6.
  • Los listeners son importantes. Defines los puertos por los cuales se puede acceder a tu balanceador. Obviamente que se definen los comunes, 80 y 443 (para los certificados). De momento dejemos solo el 80, ya que no tenemos el SSL aún y de todas formas más adelante se le puede incorporar a través de AWS Certificate Manager. Esta es una herramienta muy potente de administración, para ir actualizando los certificados una vez vayan venciendo y no tener que ir cambiándolos maquina a maquina. Cobra más importancia ahora, que practicante se asume como una obligación incorporar un SSL a tu web, de otra forma, los buscadores te castigan en tu SEO.

En el mismo paso, tenemos también algo a destacar:

Construyendo arquitecturas altamente escalables
Zonas de disponibilidad en AWS

Las zonas de disponibilidad de AWS, son espacios en los cuales las instancias de tus aplicaciones se encuentran creadas. Tener la aplicación disponible en más de una es muy importante, en caso de caída de alguna zona completa. Es ideal y recomendable que el balanceador de carga tenga instancias en al menos 2 zonas de disponibilidad, y protegernos en parte en casos de desastre y caídas de servicio.

Para más detalles de disponibilidad, redes y subredes, pensamos en publicar un artículo sobre eso. Así que atentos a nuestro blog.

El siguiente paso, te recuerda lo que te mencionaba más arriba, el SSL es importante:

Construyendo arquitecturas altamente escalables

El paso 3, tiene relación con los Grupos de Seguridad de AWS. Como ya he explicado en artículos anteriores, sirven para admitir o denegar acceso a ciertos puertos, en ciertos rangos de ip.

Construyendo arquitecturas altamente escalables

La recomendación general es hacer un Security Group, para cada capa de tu aplicación (un grupo para el balanceador de carga, otro grupo para las instancias EC2 y otro para la base de datos RDS, si es que la tienes claro, en este artículo no tocaremos ese punto, pero si te adelanto que es esencial para balancear la carga con persistencia de datos). Para cada grupo de seguridad se debe utilizar una regla de nombrado, como por ejemplo “APPNAME-GROUPNAME-SG”, teniendo finalmente en este caso: boiler-ALB-SG.

En este caso, creamos un grupo nuevo, y dejamos abierto el puerto 80 (HTTP), para Internet.

Construyendo arquitecturas altamente escalables

El siguiente paso es para configurar el routing, esto se hace a través de la creación de un Target Group (TG), que en términos simples, es un conjunto de instancias a las que el balanceador de carga puede acceder. Este TG se encarga también de chequear el healhty o salud de nuestras instancias, para saber si están disponibles para que las pueda acceder. Al igual que para todos los elementos anteriores, recomiendo usar una regla de nombrado, como por ejemplo: “APPNAME-TG”.

Luego, al continuar al siguiente paso, viene el turno de indicar cuales son aquellas instancias que están en el TG, y a las que el ALB puede acceder.

Construyendo arquitecturas altamente escalables

Basta con ir al final de la página, se seleccionar todas aquellas instancias que queremos agregar y presionar el botón:

Construyendo arquitecturas altamente escalables

Luego de esto, nuestras instancias ya están disponibles para el ALB:

Construyendo arquitecturas altamente escalables

El último paso es un Review de lo que hicimos anteriormente, y para finalizar el proceso seria necesario hacer click en el botón “Crear”. Ahora se empezará a crear todos los recursos necesarios para el ALB.

Configurando el Grupo de Auto-escalado

En el menú lateral, justo abajo de la pestaña de Load Balancing, se encuentra la sección de auto escalado:

Construyendo arquitecturas altamente escalables

Ingresar a la sección de Launch Configurations (LC)

Construyendo arquitecturas altamente escalables

Las “Launch Configurations”, son un conjunto de parámetros que indican al autoscaling group como levantar o apagar una instancia. Estas pueden contener acciones notificaciones de CloudWatch.

Construyendo arquitecturas altamente escalables

Al crear el nuevo LC, se da la opción de utilizar las AMIs de la comunidad, algunas veces te ofrecen aplicaciones casi operativas. Sin embargo lo que queremos es auto-escalar nuestra aplicación, por lo que hay que meterse a la sección “My AMIs”, y seleccionar la que creamos un poco más arriba.

Construyendo arquitecturas altamente escalables

En este proceso los pasos son muy similares a cuando se crean una nueva instancia, vale decir, se indica el tipo de instancia (t3.micro), el storage y grupos de seguridad. No ahondaré tanto en esto porque ya lo hemos visto en publicaciones anteriores, solamente tomaré los pasos importantes para lo que es el LC.

Construyendo arquitecturas altamente escalables

Al igual que todos los elementos de AWS, te recomiendo e insisto porque es muy importante usar una clave de nombrado, como por ejemplo: “APPNAME-LC”. El resto de opciones ignóralas de momento, ya con el tiempo vas a ir aprendiendo para que sirven, o me saldría aquí un artículo de 2 horas de lectura.

Luego, se agregan los grupos de seguridad, el review y listo!

Construyendo arquitecturas altamente escalables

Ahora sigue el Auto Scaling Group (ASG). En la misma sección de menú, abajo del que recién visitamos se encuentra el enlace. Una vez dentro buscar el botón azul.

Construyendo arquitecturas altamente escalables

Así se ve el formulario:

Construyendo arquitecturas altamente escalables

Deja seleccionada la primera opción, para nosotros armar nuestro ASG. Luego has scroll para poder seleccionar el LC que creamos anteriormente:

Construyendo arquitecturas altamente escalables

Luego haz click en “Next Step”

En los siguientes pasos veremos los detalles de un ASG, así que atención.
Como la mayoría de los formularios en AWS suelen abrumar un poco al principio, pero te iremos detallando cada detalle relevante.

Construyendo arquitecturas altamente escalables

Primero que todo el nombre, al igual que todos te recomiendo usar una regla del tipo: “APPNAME-ASG”. La LC ya la seleccionamos anteriormente.

El siguiente parámetro es importante, porque define el tamaño inicial del grupo de instancias y es el cual tu ASG va a intentar mantener siempre. Vamos a dejarlo en 2 para este ejemplo.

En Network procurar la misma VPC de la instancia que la creamos. Así mismo las subnets intenta dejar al menos 2, y que sean las mismas en las que actúa el balanceador de carga. El ASG lanzará instancias en alguna de ellas. Quedando finalmente así:

Construyendo arquitecturas altamente escalables

El siguiente paso es muy importante, si bien no veremos todas las aplicaciones que tiene para este ejemplo, te recomiendo tener en consideración hasta donde se puede llegar con un ASG.

Construyendo arquitecturas altamente escalables

Aquí tenemos 2 opciones

  • Keep this group at its initial size (la configuración que usaremos en este artículo), aquí lo más importante es mantener la operación, si una de las instancias cae, levanta una nueva, hasta completar el número total de instancias predefinidas.
  • Use scaling policies to adjust the capacity of this group, este tipo de escalado es más inteligente y tiene como parámetro principal el siguiente:
Construyendo arquitecturas altamente escalables

Este quiere decir que de acuerdo a los criterios que definamos, va a mantener un mínimo de 2 instancias y un máximo de 2. Obviamente es importante que el máximo sea mayor en al menos 1 unidad al mínimo para poder escalar. 

Los criterios tienen los siguientes parámetros en los que se mueven:

Construyendo arquitecturas altamente escalables
Parámetros para el ASG scaling policies

Donde: 

  • Target Value: es el valor en base al criterio que se seleccione que genera la acción de auto-escalado. Por ejemplo si definimos que sea utilización de CPU, este podría ser saeteado en 90, lo que quiere decir es que cuando el promedio de utilización de CPU de la instancia llegue a 90%, se levantará una nueva instancia, hasta el máximo definido. De lo contrario disminuir hasta el mínimo.
  • Instances need: es el tiempo que se esperará en segundos para ejecutar el escalado, una vez detectado el target value. Si la situación a observar mejora antes del tiempo definido, no se efectuará la acción.

Ahora te detallaré los criterios:

  • Application Load Balancer Request Count Per Target: esto genera la acción de auto escalado en base a un criterio de números de request al balanceador de carga.
  • Average CPU Utilization: este fue explicado en el ejemplo de arriba. Se basa en el porcentaje promedio de utilización de la CPU de las instancias.
  • Average Network In (Bytes): este criterio escala cuando el promedio de la cantidad de información que entra por red supera la cantidad en Bytes indicada.
  • Average Network Out (Bytes): este criterio escala cuando el promedio de la cantidad de información que sale por red supera la cantidad en Bytes indicada.

** Como dato adicional no importante para este artículo, es posible también configurar tópicos de SNS (Simple Notification Service) para que AWS envíe correos de notificación al momento de realizar una acción de auto-escalado.

Construyendo arquitecturas altamente escalables

Luego finalmente, viene la generación de tags (estas puede ser usadas para clasificar la facturación) y el Review de resumen de todas las configuraciones del ASG.

Una vez creado, seleccionar el ASG, edit y ejecutar las siguientes acciones:

  • Aplicación/Balanceadores de carga de red, En Target Groups, elije el grupo de destino (APPNAME-TG).

Ahora al finalizar se levantará una nueva máquina para completar las 2 definidas por el ASG. Prueba apagando una y ver que pasa. Recuerda a el ASG se demora un tiempo en declarar la acción como de auto-escalado.

Conclusiones

Como puedes ver, es posible con un presupuesto conocido adaptar las necesidades de arquitectura de nuestra plataforma a la demanda y de forma automática. Para que nunca más sea necesario comprar servidores de la Nasa, ni tampoco poner a correr una aplicación de un millón de usuarios en un tarro perdido en una oficina del centro de la ciudad.

Con esta cadena de artículos sobre AWS y aplicaciones en ROR, podemos decir que ya tienes todas las herramientas mínimas para desarrollar webs que sean atractivas en el mercado.

Próximamente estaremos escribiendo nuevos artículos para optimizar este proceso con otras herramientas de AWS.

Nuevamente no dudes en hacer tu consulta si la tienes.

Publicado el 27 julio, 2020

Categorías

Etiquetas

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

HABLEMOS

¿TE AYUDAMOS A IMPLEMENTAR SOFTWARE CON TU EMPRESA?

Estaríamos encantados de ayudarte

Icono flecha de Garage Labs de color blanco.

Garage Labs

contacto@garagelabs.cl

+569 8741 1528 | +569 3537 2885

Los Misioneros 1973, Providencia, Chile 

 

Logo de Corfo.
Logo de Innovo.