Entornos elásticos en la

nube: Elastic Beanstalk

Cuando realizamos una app web acorde a los cánones de hoy día, en
muy contadas ocasiones no es necesario tener en cuenta la
arquitectura sobre la que va a correr esta aplicación. Preguntas
frecuentes al respecto son: ¿Cuántos servidores vamos a necesitar?
¿Qué tipo de microprocesadores? ¿Cuánta memoria? ¿Servidor de
bases de datos en el mismo servidor o independiente?
Todas estas preguntas y muchas más son muy importantes dada la
disponibilidad que debemos asegurar a nuestros usuarios. También es
importante que la experiencia al manejar la aplicación sea buena, no
podemos permitir segundos y segundos de carga de nuestras
pantallas.
Un último punto, y no por ello menos importante, es la variabilidad del
tráfico que vamos a tener en nuestra aplicación. Imaginemos que
lanzamos una campaña de Black Friday y esperamos que las visitas
durante un par de días se multipliquen por 5 o por 10. Ahora
imaginemos que superamos nuestras expectativas y nuestros
servidores se caen porque no son capaces de soportar esa carga.
Aunque parezca extremo este ejemplo no está lejos de la realidad, no
sería la primera vez que ocurre esto.
Pero claro, esto es el siglo XXI y hay soluciones para este tipo de
cosas y, una de ellas, es un entorno elástico en la nube.
Elastic Beanstalk: ¿Qué es un entorno elástico?
Un entorno elástico es, básicamente, un entorno capaz de adaptarse
de forma automática al tráfico y la carga que se requiere de él en un
momento determinado. Normalmente incorpora un sistema de auto-
escalado en base a algún parámetro ya fijado: número de
requests/segundo, porcentaje de uso de la CPU u otros valores que
puedan darnos un indicador de que necesitamos aumentar o disminuir
el número de servidores en los que está desplegada nuestra
aplicación.
En realidad, un entorno elástico se compone de muchas partes que ya
conocemos pero coordinadas para que la gestión por nuestra parte
sea la mínima posible, ya que es muy importante que sea
autogestionado. Vamos a ver cuáles son estas partes principales y,
para ello, nos vamos a basar en uno de los principales servicios en el
mercado que nos proporciona este sistema: Elastic Beanstalk de
Amazon Web Services.
Elastic Beanstalk lo que hace es ofrecernos un sistema automático
que gestiona los distintos componentes para que nosotros no
tengamos que configurar cada uno de ellos por separado y orquestar
su funcionamiento en conjunto con “mínima” intervención por nuestra
parte.
Además, Elastic Beanstalk nos facilita mucho el proceso de
despliegue, ya que identifica cada parte de nuestro software y lo
coloca exactamente donde debería estar sin necesidad de complejas
recetas o scripts de despliegue por nuestra parte, tan solo tenemos
que usar su CLI propio que realiza la mayoría de estas tareas por
nosotros.
Componentes principales de un entorno elástico
Balanceador de carga
Un balanceador de carga será la parte que gestionará todo el tráfico a
nuestros servidores. Este sistema será el responsable de dirigir el
tráfico entrante a los distintos módulos de nuestro entorno en función
del tipo de solicitud que esté atendiendo y la carga individual de cada
uno de los elementos
Servidores con sistema de autoescalado
Aquí tenemos quizá la principal ventaja del entorno elástico: podremos
definir un rango de servidores que podremos usar. Por ejemplo,
usando Elastic Beanstalk podremos definir el tipo de instancia que
vamos a usar y definir un sistema de autoescalado de entre 1 y 8
servidores. De esta manera, dependiendo de la carga que tengamos
en cada momento tendremos más o menos servidores arrancados.
Hay algo importante a tener en cuenta con los servidores en los
entornos elásticos: normalmente, arrancan servidores nuevos y paran
cuando no son necesarios. Este detalle afecta a muchos niveles como,
por ejemplo, en la gestión de logs. Es importante tener un sistema de
gestión de logs, ya que si se almacenan en el servidor, cuando este
desaparezca los perderemos también. Cuando trabajamos en AWS
con Elastic Beanstalk, por ejemplo, podremos almacenar estos logs
periódicamente en S3.
Servidor de base de datos
Cuando usamos Elastic Beanstalk, normalmente, trabajaremos con el
servicio RDS como servidor de base de datos en caso de que usemos
una base de datos relacional. De cualquier manera, en un entorno
elástico el servidor de base de datos está independizado de los
servidores, así que debemos de mantener la base de datos
independiente para que no se vea afectada por el arranque y paro de
los distintos servidores.
Otra cosa muy importante en los entornos elásticos con respecto a los
servidores de base de datos es que debemos tener previsto que
cuando aumente el número de servidores arrancados también lo hará
el número de conexiones simultáneas en nuestra base de datos. Por
lo tanto, si llega un punto en que nuestro servidor de base de datos no
soporta el número de conexiones que le estén llegando, nuestro
sistema funcionará bastante mal y el número de errores a nuestros
usuarios se multiplicará. Este es uno de los puntos más importantes a
la hora de calcular la arquitectura que vamos a necesitar.
Almacenamiento
Normalmente, el almacenamiento, al igual que el servidor de base de
datos se mantiene independiente. En este caso, con Elastic Beanstalk
usaremos el servicio S3 para almacenar los datos de nuestra
aplicación en un Bucket que será accesible desde cualquier parte
tanto de nuestro backend, frontend o cualquiera de los servidores que
tengamos arrancados en un momento determinado.
Hay otros muchos componentes que podremos usar: CDN para la
distribución de contenidos si nuestra app trabaja en distintas partes del
mundo como cloudFront, sistema de gestión de alarmas automático
como cloudwatch, etc. En fin, podemos llegar a disponer de una
arquitectura realmente compleja pero como los principales elementos
en nuestra arquitectura son los que hemos mencionado, es lo mínimo
que necesitaremos para hacer correr nuestra aplicación en un entorno
elástico en la nube.
Elastic Beanstalk: conclusiones
Debemos tener muy claro los recursos que vamos a necesitar o, mejor
dicho, el rango de recursos en el que nos queremos mover, ya que
algo muy importante a tener en cuenta en sistemas elásticos es que
va a ser muy difícil saber a priori cuánto nos va a costar la
infraestructura exactamente ya que, al disponer de recursos elásticos,
dependerá del uso que hagamos. También debemos intentar optimizar
lo máximo posible el funcionamiento de nuestra aplicación porque, con
un entorno elástico, cuanto menos optimizada esté nuestra aplicación
más nos costará nuestra arquitectura, ya que consumiremos más
recursos.
Un entorno elástico en la nube nos puede ahorrar muchos problemas
y, desde luego, es un gran avance. Pero hay que recordar que es
importantísima la gestión del mismo. Es necesario dedicarle tiempo y
optimizar su funcionamiento para ahorrar costes ya que, si
simplemente lo dejamos funcionar, podría depararnos alguna sorpresa
desagradable cuando nos llegue la factura.