Hoy venimos a hablar un poco del mundo en el que nos movemos, rodeado de tecnología y de dispositivos conectados a Internet. Cada vez, más personas utilizan estos servicios y se hacen más comunes en nuestro día a día. Acciones como comprar ropa, libros, regalos e incluso hasta hacer la compra podemos hacerlas por Internet y que nos lleguen a nuestras casas en menos de dos horas gracias a empresas como Amazon. Por todo esto, cada vez es más importante que los recursos web carguen de una manera rápida y que sean capaces de sobrevivir a millones de usuarios a la vez

Para comprobar que una web es capaz de aguantar tal carga de trabajo, vamos a hacer una demostración de cómo se haría una prueba de estrés sobre una web. En esta ocasión utilizaremos Apache Jmeter, un recurso Open-Source que nos ofrece la comunidad de Apache para simular usuarios reales navegando por una web. Este nos permite, además de visitar todas las URLs de una web de forma automatizada, hacer pruebas más complejas haciendo login para simular usuarios reales u otras acciones que nos permitan probar a fondo nuestras aplicaciones web.

En estas pruebas se pueden definir gran cantidad de posibilidades, pero en nuestro caso, nos ceñiremos a generar un gran número de usuarios visitando simultáneamente una de las webs que acabamos  de migrar a nuestra plataforma cloud. La ventaja de tener esta web en cloud es que nos da mucha más flexibilidad a la hora de soportar este tipo de cargas de trabajo. Nos permite, entre otras cosas, que si recibimos un gran número de visitas, como a continuación vamos a simular, la infraestructura de la web sea capaz de crecer para adaptarse a ello.

Apache Jmeter es un programa hecho en Java que nos permite realizar estas pruebas desde nuestro propio portátil generando un número considerable de usuarios. Sin embargo, en nuestro caso queremos generar alrededor de 1’5 Millones de peticiones, por lo que será necesario repartir esta carga entre varios equipos. Para la prueba utilizaremos nuestro portátil junto con tres equipos más que estarán en AWS.

Para ello vamos a basarnos en una arquitectura como la siguiente:

Está formada por nuestro equipo, desde donde configuraremos las pruebas y orquestaremos a los esclavos; exactamente serán tres los que lanzarán las peticiones a la web que queramos probar. También, para poder realizar las pruebas es necesario que los esclavos estén en la misma red privada que el master, por lo que configuraremos un Tunel VPN IPSec de nuestra red a la red de los     esclavos

Empecemos por la configuración de la red:

  1. Lo primero es que definamos en AWS una VPC y subnet donde alojar a nuestros esclavos.
  2. Una vez hayamos credo nuestra red, será necesario conectar a ella nuestro master. En esta ocasión utilizaremos el servicio de AWS de VPN para llevarlo a cabo. Tenemos dos opciones, o buscamos un router en el que se pueda configurar una VPN, o nos la configuramos en local en nuestro equipo.
  3. En el caso de utilizar Linux en nuestro equipo es muy sencillo, necesitamos instalarnos OpenSwan u otra herramienta que nos permita levantar tuneles IPSec, y aplicamos la configuración que nos descargamos de AWS al crear nuestra VPN.
  4. Una vez configurado todo esto empezamos con el JMETER. En nuestra instalación utilizaremos Ubuntu para todos los nodos, tanto el master como con los Slave, y la instalación es muy sencilla.

Empecemos con los slave. Una vez conectado a la máquina, realizaremos una actualización de los paquetes:

  • $ sudo apt-get update

Seguidamente procederemos a instalar Java y Jmeter:

  • $ sudo apt install Jmeter-server
  • $ sudo apt install default-jre

Una vez se haya instalado todo, procederemos a configurar nuestros esclavos. Como esta es una prueba distribuida debemos definir los puertos por los que nuestros esclavos escucharan al master. Para ello editamos el fichero de propiedades de Jmeter:

  • $ vim /usr/share/jmeter/bin/jmeter.properties

Paralelamente modificamos la siguiente linea:

  • “remote_hosts=127.0.0.1” por las IPs de nuestros esclavos “remote_hosts=192.168.0.10,192.168.0.11,192.168.0.12,192.168.0.13,192.168.0.14”; en nuestro caso los esclavos serán los equipos de las IPs de la 10-14.

Una vez tengamos esto configurado, procedemos a arrancar el Jmeter en segundo plano ejecutando el siguiente comando en cada uno de los esclavos:

  • «$ nohup /usr/share/jmeter/bin/jmeter-server  > /dev/null 2>&1 &»

El siguiente paso es instalar el Jmeter en nuestro master y configurarlo. Como utilizamos también Ubuntu en nuestro master, procederemos a instalarlo igual que en los esclavos.

Con esto ya tendremos nuestra infraestructura de pruebas montada y podemos proceder a configurar la prueba y lanzarla. En nuestro master, tenemos que crear un archivo kbdx, que es donde definimos nuestras pruebas, pero lo haremos con una interfaz gráfica es mucho más sencillo.

  • Primero tenemos que configurar el site al que queremos hacer las pruebas y definir el tipo de pruebas queremos hacerle, por lo que tenemos que crear un grupo de hilos
  • A continuación definimos el número de hilos (num. de usuarios) que queremos que ataquen a la web. Nosotros definiremos 100 hilos, 10 veces durante un periodo de 100, pero podemos poner para que ejecute las pruebas hasta que nosotros las paremos. Podemos observarlo en la siguiente captura.
  • Seguidamente tendremos que añadir la petición HTTP por defecto indicando el nombre de la web o IP a la que queremos atacar y el puerto, en nuestro caso el 443.
  • Adicionalmente añadiremos más rutas de nuestra web a las que atacar, por lo que una vez creada por defecto, solo tendremos que añadir muestreadores de peticiones HTTP.
  • Creamos un par de pruebas y pasamos a la parte de los resultados, esto lo debemos añadir en Añadir → Receptor → Gráfico.

En la parte de abajo de la imagen podemos ver las estadísticas representadas en colores:

  • Black: Número total de peticiones enviadas.
  • Azul: Media de las peticiones enviadas.
  • Rojo: Desviación estándar actual.
  • Verde: Throughput rate, representa el número de peticiones por minuto que el servidor puede manejar.

Una vez obtenido esto, podremos analizar nuestro gráfico para ver dónde podemos tener un cuello de botella y mejorar el rendimiento de nuestra web.

Hoy en día la velocidad de una página web es un punto muy importante para que esta tenga visitas, si nuestra web tarda varios segundos en cargar en un móvil, los usuarios se cansarán y acabarán abandonándola, además de las penalizaciones que tendremos en cuanto a SEO.

About Miguel Camba

Cloud Engineer. Miguel is studying a degree in Information Systems at UNED University, and he has AWS Certification Exam Readiness Workshop: AWS Certified Solutions Architect – Associate, 533 Exam: Implementing Microsoft Azure Infrastructure Solutions and in 535 Exam: Architecting Microsoft Azure Solutions. He started his professional career as Head of Information Technology at Complutense University of Madrid, and in 2017 he joined Enimbos as Cloud Engineer.