Throttling pattern

El patr贸n Throttling permite controlar la cantidad de recursos que una aplicaci贸n puede utilizar antes de estrangular los procesos no esenciales a favor de mantener a flote el barco, evitando una interrupci贸n del servicio o el incumplimiento de los SLA.

Problem谩tica

Hoy en d铆a es bastante com煤n encontrarnos en situaciones donde nuestra aplicaci贸n recibe una carga inusual de trabajo, que pone en peligro el funcionamiento de la aplicaci贸n, a tal punto que puede ralentizar los tiempos de respuesta, abortar operaciones o finalmente, terminar tumbando la aplicaci贸n por completo.

Si bien, este tipo de problemas son f谩cilmente manejables con estrategias de autoescalado, tiene la limitante de que esto no es inmediato, si no que requiere breve periodo de tiempo para aprovisionar m谩s instancias de un servicio determinado, lo que podr铆as dar lugar a una breve interrupci贸n del servicio.

Puedes aprender m谩s de escalamiento en mi art铆culo donde explico que es el escalamiento horizontal y vertical.

Soluci贸n

La soluci贸n que propone el patr贸n Throttling es permitir que la aplicaci贸n utilice recursos hasta cierto l铆mite, y luego limitar (en realidad es estrangular, pero se escucha muy extra帽o) el funcionamiento de la aplicaci贸n para evitar comprometer los tiempos de respuesta o el funcionamiento total de la aplicaci贸n.

El termino estrangular (Throttling) puede resultar un poco confuso, pero se refiere a la capacidad de una aplicaci贸n o servicio priorizar el funcionamiento vital de la aplicaci贸n, y limitando o denegando el servicio a todos aquellos menos importantes.

Dicho lo anterior, existen varias formas en las que podemos limitar el uso de recursos de una aplicaci贸n, entre las que destacan:

1 – Limitar el n煤mero de peticiones

Una de las estrategias m谩s ampliamente utilizada es el estrangulamiento por n煤mero de peticiones, que consiste en limitar el n煤mero de peticiones que un cliente puede realizar al servicio en un tiempo determinado, lo que obliga a la aplicaci贸n a medir el numero de solicitudes por cliente, y finalmente denegar el servicio cuando el umbral ha sido alcanzado.

Este enfoque es especialmente 煤til cuando ofrecemos un API a nuestros clientes, los cuales pueden utilizar a demanda cualquier servicio que proporcionemos, sin embargo, como no tenemos el control de cuantas llamadas realicen, es importante blindas nuestra API para que no hagan un uso irresponsable de los servicios que les proporcionamos y terminen degradando o tumbando el API.

Por ejemplo, hay casos donde un cliente utiliza t茅cnicas irresponsables como el Pooling para consultar con demasiada frecuencia cierta informaci贸n, lo que puede implicar el uso de una gran cantidad de recursos del servidor para atender cada petici贸n.

Pooling pattern

Puedes leer m谩s del patr贸n Pooling en el siguiente art铆culo de mi libro de arquitectura de software.

Pero el uso excesivo de los recursos del servidor no solo se puede dar por un uso irresponsable, si no que se puede dar el caso de que nuestro cliente presente un crecimiento natural en su operaci贸n, lo que implica un mayor n煤mero de peticiones al API, lo que implicar铆a un uso mayor al negociado al comienzo.

Throttling con Nginx

Una de las formas m谩s simples de implementar el patr贸n Throttling por n煤mero de peticiones es utilizar Nginx, un proxy web que permite limitar el n煤mero de peticiones por medio de configuraci贸n:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
 
server {
    location /login/ {
        limit_req zone=mylimit;
        
        proxy_pass http://my_upstream;
    }
}

El ejemplo muestra como limitar las llamadas al servicio de login (/login/) con una taza de 10 request por segundo (rate=10r/s).

Puedes ver el ejemplo completo en la documentaci贸n de Nginx (https://www.nginx.com/blog/rate-limiting-nginx/)

2 – Priorizar servicios esenciales

Otra de las estrategias m谩s utilizadas para implementar el Throttling es limitar o denegar los servicios no esenciales, de esta forma, podemos simplemente denegar el servicio a ciertas operaciones hasta que el sistema se ve restablecido o utilizar una estrategia menos agresiva como degradar la calidad del servicio para permitir liberar recursos para que los procesos esenciales puedan seguir funcionando.

Para implementar esta estrategia es importante poder identificar cuales son los procesos vitales y cuales son prescindibles, de tal forma que podamos apagarlos o degradarlos de forma r谩pida, evitando que el sistema llegue a un estado de saturaci贸n.

Un ejemplo bastante contundente de esta estrategia es la que utilizo Netflix durante la pandemia del COVID-19, en el ancho de banda de Europa se satur贸 por la masiva cantidad de gente que se quedaba en casa y solo podr铆a ver TV, lo que oblig贸 a Netflix a degradar la calidad del servicio a HD en lugar de ofrecer 4K o Full HD.

3 鈥 Distribuci贸n prioritarias de solicitudes

Esta estrategia se utiliza mucho en sistema multitenant, donde varios inquilinos utilizan la misma aplicaci贸n, sin embargo, se les ofrece un SLA diferente seg煤n el nivel de cada cliente. Mediante esta estrategia es posible priorizar los mensajes mediante de colas de mensaje de prioridad y atender estos mensajes seg煤n su prioridad, de esta forma damos prioridad a nuestros clientes premium y dejamos en espera o denegamos el servicio al resto de clientes.

Esta estrategia es muy utiliza por ejemplo en aplicaciones en la nube donde tenemos clientes gratuitos y clientes premium, lo que nos permite garantizar una experiencia constante a los clientes premium y a los clientes gratuitos los dejamos en espera hasta que el sistema se regulariza. Ya que al final, lo m谩s importante es mantener contentos a los clientes que si esta pagando por el servicio.

驴Quieres aprender m谩s patrones arquitect贸nicos como este y convertirte en arquitecto de software? te invito a que veas mi libro de arquitectura de software

Consideraciones

A pesar de que Throttling es un excelente patr贸n, no todo es felicidad, pues hay ciertas cosas que debemos de considerar antes de implementarlo, y que son clave para su 茅xito.

  • Lo primero es m谩s importante, la aplicaci贸n debe de a ver sido dise帽ada desde el comienzo para soportar esta capacidad, pues es necesarios desde el inicio, determinar los servicios vitales y de los que podemos preceder por un breve periodo de tiempo.
  • Este patr贸n debe de actuar r谩pido, ya que ante un pico de demanda, si el patr贸n no estrangula r谩pidamente el servicio, puede que el servicio se degrade por un breve periodo de tiempo o incluso, se caiga antes de que el estrangulamiento entre.
  • Es importante distinguir entre un error de la aplicaci贸n y uno de estrangulamiento, ya que de esta forma el cliente podr谩 saber el motivo por el cual su invocaci贸n est谩 siendo rechazada.
  • El estrangulamiento de puede utilizar como una estrategia temporal en lo que el autoescalado se lleva a cabo.
  • Finalmente y no menos importante, el sistema deber谩 de tener la capacidad de regresar a su estado una vez que la carga de trabajo se ha normalizado, de lo contrario quedar谩n los servicios estrangulados por tiempo indeterminado.
  • El estrangulamiento debe de ser un proceso autom谩tico y no manual, lo que quiere decir que este debe de entrar de forma autom谩tica por ciertas reglas determinadas y no por un operador que active y desactive componentes.

Cuando deber铆amos de usar Throttling

  • Cuando necesitamos garantizar el cumplimiento de los SLA a pesar de los picos altos de demanda.
  • Evitar que un solo cliente monopolice los recursos del servidor.
  • Para permitir la operatividad del servicio a pesar de un pico de demanda no esperado.
  • En ciertas ocasiones nos pueden servir como una v谩lvula para impedir que ciertas aplicaciones consuman m谩s recursos de los esperados, sobre pasando un l铆mite de facturaci贸n, muy parecido a lo que hacen lo que hace AWS o Azure en sus servicios en la nube.

Conclusiones

Throlling es uno de los patrones m谩s utilizados para servicios que son habilitados para ser utilizados por terceros, donde no tenemos el control sobre la cantidad o demanda que puedan necesitar, logrando protegernos de picos de demanda no esperados o que sobre pasan un umbral esperado.

Deja un comentario

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