Buenas Ismael, Respondo entre líneas,
El mié., 22 abr. 2020 a las 21:19, Ismael de Esteban (<ism...@null.net>) escribió: > Gracias por la guía. Está genial. > Muchas gracias. Era algo que siempre estaba sobre la mesa... pero que faltaba plasmarlo por escrito... y de paso ya pues compartirlo con la comunidad. > 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. > En nuestro caso en más de 3 años no nos ha pasado nunca que las colas lleguen a atascarse... la mayoría de las tareas tardan *como mucho* décimas de segundos (lo normal es menos incluso)... aunque tenemos algunas de segundos, minutos e incluso horas. Las que pueden tardar minutos u horas son tipo cron... con lo que no atascan la cola solo la ocupan parcialmente. > > 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. > > Nosotros esto no lo hacemos para ganar alta disponibilidad. Lo hacemos por clientes, unos clientes ven una cosa y otros otras. Si que es verdad que algunas funcionalidades se pueden habilitar y deshabilitar globalmente por un administrador. Y es verdad que este podría deshabilitarlas por alta carga... pero no está pensado para eso, sino por otros motivos propios de nuestra lógica de negocio. Muchas gracias de nuevo! Abrazo, > 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 > 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 > > "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@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 > goi...@gmail.com > _______________________________________________ Python-es mailing list > Python-es@python.org https://mail.python.org/mailman/listinfo/python-es > _______________________________________________ > Python-es mailing list > Python-es@python.org > https://mail.python.org/mailman/listinfo/python-es > -- Pablo Martín Cobos Ingeniero informático Desarrollador Python/Django 652 53 37 36 goi...@gmail.com
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es
