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

[J. Pablo Martín Cobos]

Buenas Chema,

Te respondo entre líneas,

El mar., 21 abr. 2020 a las 13:23, Chema Cortes (<pych3m4 en gmail.com>)
escribió:

>
>
> El mar., 21 abr. 2020 a las 12:53, J. Pablo Martín Cobos (<
> goinnn en gmail.com>) escribió:
>
>> Buenas,
>>
>> He escrito un pequeño manifiesto que me gustaría compartir con la
>> comunidad.
>>
>> Espero que os guste yos entretenga en estos días de confinamiento.
>>
>> Si alguno está interesado en contribuir puede hacer un fork y un pull
>> request.
>>
>> Español:
>> https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html
>> Inglés:
>> https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index.html
>> <https://goinnn.github.io/zen-of-high-load-and-high-availability-backend/index-es.html>
>>
>>
> Interesante.
>

Gracias

Lo único que veo que hablas de tareas en primer y segundo plano. No sé si
> te referies a la prioridad de tareas, con el servidor web como tarea más
> prioritaria, o vas más por distinguir entre tareas síncronas y asíncronas,
> ya que también hablas de activar *timeouts*.
>

Primer plano = servidor web
Segundo plano = sistema de colas de tareas (tipo celery)

Por ejemplo en el registro de un usuario, puede que tengas que mandar uno o
varios correos, mandar algún SMS, notificar a algún administrador de alguna
otra forma, etc. Podrías hacerlo todo en primer plano y dejar al usuario
3-10 segundos esperando, y lo que es peor hacer que otras peticiones se
encolen detrás o mucho mejor decirle al usuario: listo, ok! y después hacer
todo lo que tengas que hacer (todas las comunicaciones con sistemas
externos) en segundo plano


> Lo que no he visto nada sobre *resiliencia*. ¿Qué pasa cuando tienes que *amputar
> un brazo* para mantener la alta disponibilidad? ¿O qué pasa cuando se
> empieza a rechazar peticiones por la alta demanda?
>

Respondo aquí también lo de los timeouts.

Un backend puede estar conectado a muchos sistemas (el nuestro a unos 40
sistemas externos):

   1. Servidor de correos
   2. Servicio de SMS
   3. Notificaciones pushes
   4. Servicio de llamadas automáticas
   5. Integraciones con sistemas de clientes
   6. Sistemas de facturación
   7. Otros servicios
   8. Etc


La idea es que por muy crítico que sea mandar un correo, un SMS, llamar a
un servicio que hace que se guarde un PDF, o *cualquier* otra cosa, no hay
nada más crítico que tu sistema.

Si por ejemplo se cae el servidor de correos y tu backend manda muchos
correos, primero tu backend irá lento y finalmente se caerá. Pues la idea
es que es mejor dejar de hacer algo incluso si es crítico (mejor amputar)
que que tu sistema se caiga completamente.

Y esto se puede conseguir no dejando peticiones indefinidamente: 30, 60,
120, etc segundos; sino estableciendo un tiempo máximo a todas las
conexiones que hace tu backend a otro sistema (es decir, un timeout).


La *resilencia* es fundamental para un sistema de alta disponibilidad. Por
> si te sirve de comparación, echa un vistazo al *Manifiesto de Sistemas
> Reactivos*: https://www.reactivemanifesto.org/es
>


Totalmente, nosotros conseguimos la resilencia siguiendo las reglas que he
pasado.

Alguno más se ánima al debate?

Abrazo,


>
>
> --
>
>>
>> Pablo Martín Cobos
>> Ingeniero informático
>> Desarrollador Python/Django
>> 652 53 37 36
>> goinnn en gmail.com
>> _______________________________________________
>> Python-es mailing list
>> Python-es en python.org
>> https://mail.python.org/mailman/listinfo/python-es
>>
>
>
> --
> Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
> https://blog.ch3m4.org
> Buscador Python Hispano: http://busca.ch3m4.org
> <https://blog.ch3m4.org/pages/busqueda-python-es/>
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
>


-- 
Juan 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/20200421/572d56b6/attachment.html>