Resiliencia y pruebas efectivas

Para garantizar la Resiliencia de un sistema, debemos probar nuestro systema, desde la app hasta la infra de nuestra appa, para esto podemos hacer uso de estas dos grandes teorias:

Functional Testing
Son los tests que se llevan acabo para probar la funcionalidad de los features desarrollados de la app, podemos desarrollar por ej:

• Unit Testing
• Integration Testing
• end to end testing

Non-Functional Testing
Estos son los tests que se llevan acabo en la aplicacion ya desplegada, no en produccion sino un hambiente controlado, lo mas parecido a prod, por ejemplo:

• Performance Testing o pruebas de stress: donde medimos la capacidad de nuestra app de respodenr normalmente bajo una carga de stress
• Recovery Testing: comprobamos que tan bien un sistema se recupera de un fallo de hardware
• Security testing

no paga que sea un audiocurso, quiero video

• Para mejorar la resiliencia de los servidores en alta concurrencia, usara CDN(Content Distribution Network), nos permite hostear o cachear contenido estático de nuestro servidores.
• Stress Testing, para medir la carga de trátfico de nuestra aplicación, Orquestadores para alta disponiblidad como kubernetes.

Load Testing, básicamente es un DoS con buenas intenciones que ayuda en la detección y reacción de los servidores y tecnología para anticiparnos a eventos no deseados

Algunas herramientas para hacer pruebas de carga o de estres podrian revisar estas:

• Apache JMeter
• Locust
• k6
• Gatling

Automatizar pruebas funcionales implica realizar pruebas unitarias, pruebas de integracion y pruebas punta a punta basicamente. Es decir, hacer prueba en el codigo, pruebas en los servicios y realizar pruebas en la interfaz grafica respectivamente. Como se muestra en la piramide de automatizacion.

La forma que tiene esta grafica indica que la base son las pruebas unitarias, es decir que cuantas mas y mejor elaboradas sean, mejor. Mientras las pruebas de UI son que tenemos que se debe evitar haciendo pocas como sea posibles debido a lo costosas y fragiles que son. En otras palabras, mientras mas antes sean descubiertos los defectos en nuestro software menos costosas seran para las empresas el arreglarlos.

Tambien, se debe estar conciente que es imposible automatizar TODO debido a que implicaria un gasto enorme de implementacion y mantenimineto constante en cada ciclo de desarrollo. Es decir, estas pruebas tienen que ser eficientes y aplicadas solo a flujos robustos e importantes para el funcionamiento del sistema.

¿Cómo podemos garantizar la resiliencia en un sistema de alta concurrencia?
Podemos implementar métodos para mejorar la resiliencia de nuestra aplicación.

Ya hemos tocado el tema de escalamiento vertical, escalamiento horizontal y cuándo usar cada uno; esto ya nos ayudará muchísimo a la hora de afrontar problemas en alta concurrencia. Después hay varios servicios externos que nos pueden ayudar; el más común, es el CDN (Content Delivery Network) que nos permite hostear o cachear generalmente contenido estático en servidores externos a los nuestros. Básicamente trabaja como un proxy delante de nuestra aplicación, el cual que va a recibir la mayoría del tráfico y va a servir el contenido para los clientes sin que todo el tráfico llegue a nuestros servidores. Con esto, la necesidad de escalamiento disminuye ya que la mayoría del tráfico no la recibirían nuestros servidores.

¿Cómo se prueba de manera efectiva y eficiente un sistema de alta concurrencia?
Para comenzar, primero hay que asegurarnos de que nuestra aplicación funcione bien (pruebas unitarias y end to end testing). A la hora de medir la capacidad de nuestra aplicación para recibir tráfico, tenemos que acudir al stress testing. El stress testing usa diferentes herramientas para simular tráfico a nuestra aplicación, tráfico como si fuesen muchos usuarios al mismo tiempo. Hay muchos sistemas que pueden ayudarnos en esto, y esto es muy importante a la hora de medir los recursos que nuestra aplicación necesita para correr en la nube.

¿Cómo protegernos de las caídas de los recursos en producción?
Esto está muy relacionado con el escalamiento vertical y horizontal. Si escalamos nuestra aplicación monolita verticalmente, al final seguiremos teniendo un solo servidor; si dicho servidor falla y se cae, toda la aplicación dejará de funcionar.

Esta es otra de las ventajas del escalamiento horizontal: al nosotros tener diferentes copias de nuestra aplicación corriendo, podemos asegurarnos de que si uno de los recursos comienza a fallar, los otros estarán disponibles para recibir el tráfico. Esta sería la principal forma de protegernos de las caídas de recursos (leak de memoria, uso excesivo de CPU, etc.).

Hay sistemas de orquestamiento de recursos (el más común es Kubernetes) que nos permiten definir health checks, que sería básicamente definir un path de nuestra aplicación para que nuestro orquestador sepa si el recurso está listo para recibir tráfico o no. En caso de que un recurso tenga un leak de memoria o un uso excesivo de CPU, el health check comenzará a fallar por lo que el orquestador no le enviará tráfico.

Esta es la forma más común de escalar horizontalmente y la forma más común de enfrentar este problema en alta concurrencia.

CDN: Red de distribución de contenido, almacena el contenido estático de otro sitio con el fin de balancear las peticiones (Trafico) que se realizan a un sitio.

Buenísimo Pablo !!! para la proxima le dice IMPRESIONANTE Pablo

En la empresa estamos trabajando con k6 para trabajar load test. simula muchos usuario durante un intervalo de tiempo

A probar…

Con los load testing hay que tener cuidado, se deben hacer, solo hay que estar seguro que el load test no afecte a otros servicios que comparten infraestructura, de preferencia hacerlas si el ambiente esta aislado, si no están aislados se debe notificar a los que podrían verse afectados.