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.

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.

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.

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.

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.

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.

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.