Gracias por la guía. Está genial.
Con ese stack, ante un pico de carga, a mí me ha funcionado parar las colas de tareas en background ya que estas seguían haciendo peticiones a las bases de datos -que es generalmente el recurso más dificil de escalar rápidamente-. Por tanto encender y apagar algunas colas debería ser un comando relativamente a mano.
Sí que hay que tener en cuenta la cantidad de tareas encoladas que puedes almacenar si haces esto para no perder ninguna.
Feature Switching a mi entender es una setting donde activas o desactivas una funcionalidad. A mí me gusta implementarlo con un porcentaje en lugar de un booleano para poder así hacer Canary Releases o Blue-Green deployments. Hay que tener en cuenta que si la feature tiene determinadas migraciones, no se va a poder hacer rollback. Pero no conozco ninguna librería que ayude a implementarlas.
Un saludo!
Sent: Wednesday, April 22, 2020 at 11:38 AM
From: "J. Pablo Martín Cobos" <goi...@gmail.com>
To: "La lista de python en castellano" <python-es@python.org>
Subject: Re: [Python-es] Zen para un backend en alta disponibilidad y alta carga
From: "J. Pablo Martín Cobos" <goi...@gmail.com>
To: "La lista de python en castellano" <python-es@python.org>
Subject: Re: [Python-es] Zen para un backend en alta disponibilidad y alta carga
Buenas Javi,
Muchas gracias por tu respuesta. Respondo entre líneas,
El mar., 21 abr. 2020 a las 21:46, lasizoillo (<lasizoi...@gmail.com>) escribió:
El mar., 21 abr. 2020 a las 20:37, J. Pablo Martín Cobos (<goi...@gmail.com>) escribió:Alguno más se ánima al debate?Con las tareas asíncronas o en segundo plano como las llamas se pueden hacer virguerías.
No es que lo llame yo... es por ejemplo como se define celery :-P
http://www.celeryproject.org/
Aunque a veces eso de los timeouts se queda corto. Planteo un escenario:
Los timeouts solo son un punto de todo lo planteado, si fueran lo único que hay que hacer sería el único punto ;-)
Tengo un sistema de colas de trabajo que ataca a una pila de servicios externos, pongamos 40. Normalmente todo va como un tiro y se come muchos trabajos por segundo, pero por si acaso pongo un timeout de 5 segundos a las tareas. Si por debajo todo usa la misma cola, en plan configuración por defecto de celery, voy a llegar a un punto en el que todas las peticiones con timeout están haciendo de tapón y no dejando entrar a las que cuando entren irán rápidas porque no fallan. Al final hay un número de workers limitado y están mayormente ociosos esperando al timeout. Posibles soluciones:- Segregar las colas de tareas en diferentes colas de mensajes. Las afectadas se encolarán por el tema de los timeouts y las otras seguirán yendo rápido como si nada pasase.- El worker implementa el patrón circuit breaker y mientras dura la avería ese tipo de tareas se encolan a lo dead letters, se descartan o se ejecutan con un plan b que no implique el sistema afectado. Solo se producen timeouts hasta abrir el circuito, luego no se producen más timeouts.- ??? (pon aquí la solución que se te ocurra, porque hay muchas formas de mejora)
Totalmente, lo ideal son varias colas.... y es más varios workers. Dado que aunque tengas varias colas una cola puede llegar a bloquear a otra cola si está en el mismo worker (al menos en celery).
El propósito era tener una guía simple... sin profundizar. Ya que cuando más profundizas menos genérico es, y a un número más reducido de sistemas se puede aplicar.
Pero no siempre se puede dejar al usuario sin confirmación o hacer las cosas "en segundo plano". Si hay fallos de usabilidad puedes tener al usuario repitiendo la operación todo loco. Si le dices "tu operación estará en unos segundos" lo tendrás haciendo polling cada segundo. Es posible que si un caso de uso va regulero el usuario haga reintentos (como podría estar haciendo tu sistema de colas de trabajo con las tareas que te dan timeout) y haciendo que el sistema pase de regulero a muy malito. Para este tipo de cosas puede venir bien el concepto de "feature switching": lo que va regulero lo deshabilitas hasta que tengas el sistema sano otra vez.
Totalmente de acuerdo, no siempre se puede... pero si la mayoría de los casos... por ejemplo nuestras a peticiones a tercero se hacen entorno al 90% en segundo plano. Y tan solo un 10% en primer plano (servidor web).
Aunque si que hay maneras de poder hacerlo siempre, aunque más complejas. Por ejemplo: si te comunicas con el backend a través de un socket... el primer plano podría decirle al segundo plano que hiciera X y cuando esté hecha el segundo plano podría responderle al frontend mediante dicho socket...
Por resumirlo en un rollo de esos zen:- Lo que ahora va mal y en el instante siguiente va mal probablemente seguirá mal: ponlo en cuarentena y no vuelvas a intentarlo en un rato.- Las cosas pueden fallar, pon barreras para que cuando se estropeen no te estropeen el resto. Por ejemplo usa diferentes colas para diferentes tipos de tareas.- A veces es mejor dejar de hacer algo que hacelo mal, usa "feature switching" para esos momentos en los que las cosas no van finas.
No conozco "feature switching" ¿tienes algún enlace al respecto?
_______________________________________________Un saludo,Javi
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
Abrazo,
--
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es
