[Python-es] Zen para un backend en alta disponibilidad y alta carga

[J. Pablo Martín Cobos]

Buenas Javi,

Muchas gracias por tu respuesta. Respondo entre líneas,

El mar., 21 abr. 2020 a las 21:46, lasizoillo (<lasizoillo en gmail.com>)
escribió:

>
>
> El mar., 21 abr. 2020 a las 20:37, J. Pablo Martín Cobos (<
> goinnn en 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

"Tasks can execute asynchronously (in the *background*) or synchronously
(wait until ready)."

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 ;-)

https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html



>
> 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 en python.org
> https://mail.python.org/mailman/listinfo/python-es
>


Muchas gracias Javi!

Abrazo,

-- 
Pablo Martín Cobos
Ingeniero informático
Desarrollador Python/Django
652 53 37 36
goinnn en gmail.com
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20200422/4d017c93/attachment.html>