C Estrategia estudio de caso

by Josué Beltrán

C Estrategia estudio de caso

Superar picos intensos de tráfico y sobrepasar las expectativas del cliente con infraestructuras elásticas.

C Estrategia es una empresa enfocada en dar consultoría a diferentes sectores del gobierno local y federal e industrias que requieran de servicios consultivos multidisciplinarios.

Sus clientes requerían de una solución de infraestructura que les permitiera escalar conforme la demanda en un evento especial: las encuestas presidenciales.

La infraestructura debía contar con varias características, la principal era soportar picos de tráfico intensos y reducir la cantidad de instancias disponibles en función del tráfico.

Para ello Nubity desarrolló una arquitectura en EC2, con motor de base de datos Aurora y Elastic beanstalk para la automatización del escalamiento que estaría administrado por un Elastic Load balancer. Gracias a esta arquitectura se logró administrar el tráfico de manera eficiente y automática, por lo que el cliente sólo se dedicó a darle seguimiento a los eventos durante la puesta en producción.

Implementación y adaptación

Para lograr montar su aplicación JAVA en AWS se migró la base de datos PostgreSQL al motor auto escalable de AWS RDS: Aurora, con lo que se consiguió una compatibilidad transparente al mismo tiempo de la elasticidad que ofrece un motor SQL como Aurora y se utilizó Tomcat para montar el Applet sobre seis EC2.

Gracias a Elastic beanstalk se logró generar plantillas de las instancias requeridas para el proyecto, que se generarían al ritmo que el Balanceador de carga lo solicitara.

Una vez implementado el proyecto se procedió a realizar pruebas de estrés que permitieran comprobar la eficiencia de la solución implementada:

En un cálculo inicial se estimó que los picos más importantes de tráfico serían de 150 mil usuarios distribuidos en varias aplicaciones definidas por zonas geográficas para un total estimado de 370 mil peticiones.

En la solución implementada se estimó que en promedio el máximo de instancias necesarias por zona, sería de 20.

Las pruebas concluyeron satisfactoriamente y la aplicación pudo soportar sin impactar en el rendimiento. El cliente supervisó las pruebas mediante Jmeter por lo que hubo satisfacción completa en la realización.

Rendimiento superior alcanzado

Gracias a las pruebas intensivas hechas previamente se logró mantener la tranquilidad en el día de lanzar a producción. Con Beanstalk el trabajo manual fue de menor a nulo, el equipo se enfocó en monitorizar el comportamiento del tráfico y finalmente, con el apoyo del cliente en el lado de la aplicación, pudo dar testimonio de que las peticiones estimadas fueron muy superiores al comportamiento real y, por la misma razón, el rendimiento fue óptimo en el 100% de los casos y con un pico máximo observado de 5 mil peticiones por segundo.

Al final, la infraestructura se redujo al mínimo posible para mantener los costos a lo más bajo.

Tabla técnica

C Estrategia

Necesitaban diseñar una nueva plataforma que soporte alto tráfico para las encuestas en la elección presidencial mexicana.

Creación y configuración de Beanstalk con seis EC2, configuración de un ELB como público, configuración de seguridad de VPCs, migración de Postgres a Aurora RDS.

  • Elastic Beanstalk
  • Elastic Load Balancer
  • EC2
  • Aurora RDS
  • VPC
  • Jmeter
  • Linux
  • JAVA
  • Tomcat
  • Fue posible escalar la plataforma para soportar tráfico alto cuando fue necesario gracias a Beanstalk.
  • El día en que se salió en producción el rendimiento fue más que óptimo porque se estresó la aplicación más allá de lo propuesto en un inicio.
  • 367,000 usuarios
  • Pico máximo 5mil peticiones/s
  • El uso de Beanstalk ayudó al escalamiento horizontal.
  • Fue valioso hacer pruebas de estrés para revisar el comportamiento lo que se tradujo en tranquilidad.
  • El cliente sabía muy bien el uso de la herramienta Jmeter para monitoreo y simulación.