Skip to main content
Teoria de colas

Teoría de Colas en el dimensionamiento de un PaaS

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (1 votos, promedio: 5,00 de 5)
Cargando…

Muchas son las ocasiones en las que el dimensionamiento de las infraestructuras y plataformas sobre las que se van a desplegar los distintos servicios de nuestra arquitectura han sido estimadas de manera muy precaria, ya sea por falta de presupuesto o por desconocimiento de cómo se quiere que trabaje nuestro sistema y bajo qué carga de trabajo. Esto provoca que en hora punta de peticiones a nuestros sistemas nos encontremos ante una auténtica denegación de servicio (DoS – Denial of Service) afectando a la disponibilidad de nuestro servicio.

Por otro lado, la proliferación del Cloud y los XaaS (“X” as a Service) basados mayoritariamente en contenedores ligeros tipo Docker, nos proporciona la capacidad de ajustar nuestra infraestructura de una manera reactiva pero nos plantea muchas cuestiones a la hora de que nuestra infraestructura se gestione de manera proactiva o por sí sola. ¿Bajo qué circunstancias se debe ampliar el número de contenedores proporcionando servicio? ¿Y reducirlo? ¿En qué datos empíricos debe basar la infraestructura su toma de decisiones? ¿En el tiempo medio de respuesta o en el número de peticiones por segundo?

Crear una infraestructura capaz de gestionarse a sí misma en función de unas reglas simples puede permitir aprovechar mejor los recursos de los que se dispone en una empresa. Para llegar a ese punto y poder tener datos empíricos de nuestro sistema en funcionamiento, hemos realizado una estimación inicial, por lo que ¿cómo realizamos esa primera estimación? ¿Podría utilizarse dicho cálculo inicial para resolver las cuestiones planteadas en el párrafo anterior, una vez se encuentre el sistema en ejecución?

Los problemas de esperas empezaron a estudiarse formalmente a partir de 1917 con el trabajo de A.K. Erlang sobre el cálculo de probabilidades y el tráfico telefónico. Sus estudios iban encaminados a determinar la probabilidad de que una centralita telefónica estuviera saturada y, por tanto, servían de ayuda al dimensionamiento de la misma. Es en este caso, cuando la demanda de un cierto servicio excede la capacidad del sistema que la atiende, se da lugar a una congestión previa al procesamiento (una cola).

Con el planteamiento del párrafo anterior, detallaremos a continuación cómo dimensionar un sistema antes de tan siquiera haber invertido en él y cómo se puede utilizar el mismo cálculo para redimensionar la plataforma en tiempo de ejecución mediante algún tipo de agente de escalabilidad que desarrollemos en relación con las reglas mostradas.

 

Planteamiento del problema mediante la Teoría de Colas

Sin profundizar demasiado en la Teoría de Colas, lo cual excede el alcance de este post, definiremos un par de variables a tener en cuenta y que serán las que utilizaremos en el cálculo a posteriori:

  • l = media del ratio de llegada de peticiones.
  • µ = media del ratio de servicio.
  • r = factor de utilización del sistema.

Si consideramos para nuestro problema una tasa de llegadas de 300 peticiones por segundo y queremos como requisito funcional que cada uno de nuestros servidores del sistema sirva a 200 peticiones por segundo. ¿Cuál debe ser el número de servidores/contenedores para que el sistema esté funcionando a un 80%? (Se considera que en torno a partir del 85-90%, el sistema comienza a estar saturado y tiende a encolar un gran número de peticiones hasta que se provoca un DoS).

Siguiendo con el planteamiento, si:

  • l = 300 peticiones/segundo.
  • µ = 200 peticiones/segundo.
  • r = 0,8 (80%).

r = l/n*µ (Donde “n” es el número de servidores)

n =  l/r *µ  = 300 /(0.8*200) = 1.875 ~ 2 servidores

 

Esto quiere decir que con dos servidores conseguiremos dar servicio a ese ratio de peticiones por segundo con nuestro ratio de servicio logrando que el factor de saturación de nuestro sistema sea igual o menor al 80%.

 

Experimentación estadística

Obviamente el cálculo anterior expone una manera sencilla de dimensionar el sistema en un papel, pero ¿nuestro sistema se comportará como deseamos con ese factor de saturación y ese número de servidores?

Para llevar a cabo dicha prueba en un entorno de simulación utilizaremos la aplicación de Enterprise Dynamics en la cual implementaremos el sistema como hemos descrito en el apartado anterior, y probaremos si es viable dicho razonamiento para dimensionar nuestra plataforma.

Como se muestra en la siguiente imagen, se ha diseñado el sistema (empezando a describir los componentes de izquierda a derecha) con una fuente de peticiones que realiza una media de unas 300 peticiones por segundo siguiendo una distribución normal, una cola que precede a los dos servidores que sirven unas 200 peticiones por segundo siguiendo una distribución normal también, y para finalizar, un sumidero que simboliza la salida del sistema de las peticiones.

SimulacionConED

Tras simular nuestro sistema durante 4 horas, en las cuales se han realizado más de 4.300.000 peticiones, podemos observar como ambos servidores tienen una tasa de utilización del 75%, inferior a la premisa del 80% que habíamos definido en el apartado anterior, demostrando de este modo que el número de servidores calculados matemáticamente es suficiente para cubrir la tasa de llegadas planteada.

 

Conclusiones

Gracias a esta demostración de la aplicabilidad de la Teoría de Colas en el dimensionamiento de servidores, ya sean físicos o contenedores Docker en un entorno XaaS, se podría dimensionar, tanto de manera previa como de forma proactiva en tiempo de ejecución, nuestra infraestructura para evitar sufrir una denegación de servicio (o al menos minimizar sus posibilidades). También se podría desarrollar un agente de escalabilidad que fuera capaz de capturar la información de cuántas peticiones por segundo está recibiendo nuestra infraestructura y ser capaz de ampliar o disminuir el número de servidores bajo una serie de reglas básicas que implementasen los cálculos mostrados en este post de manera automatizada.

Obviamente, este cálculo se podría aplicar a todo lo que consideremos servidor o con lo que podamos asumir dicha similitud. Un posible ejemplo alejado de los que ya estamos acostumbrados podría ser considerar a los desarrollares como servidores, calculando su nivel de saturación y estrés en función de las tareas por semana que son capaces de desarrollar, pero como digo, es uno de los muchos posibles ejemplos así que recordad que cada problema es un mundo y que en la imaginación está el límite, así que usadla con moderación.

 

 

Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

Elías Grande Rubio ha escrito 7 entradas


Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *