El backend de Meta Threads fue construido con Python 3.10

 (twitter.com/llanga)
2 puntos por GN⁺ 2023-07-07 | 1 comentarios | Compartir por WhatsApp

"¿Sabían que el backend de #MetaThreads fue construido con #Python 3.10?

Se ejecuta sobre el fork #Cinder de Instagram, y este fork incluye varias funciones interesantes que no están en Python 3.10 estándar, como un compilador JIT, módulos de carga diferida y módulos estáticos precompilados."

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-07
Comentarios de Hacker News

  • Resulta bastante irónico para quienes dicen que “Python no es lo suficientemente rápido para un backend de producción”. Después de todo, la misma empresa ha operado la red social más grande del mundo hecha con PHP + MySQL

    • Técnicamente es cierto, pero desde hace mucho tiempo no ejecutan PHP puro tal cual. Lo convertían a código x86 con HHVM JIT y lo ejecutaban de forma nativa en la máquina, además de meterle muchísima optimización
      La máquina virtual que hace el JIT también está completamente en C++, y su distribución de MySQL es un fork interno fuertemente modificado para escalar. Incluye separación entre almacenamiento y cómputo, sharding, un motor de almacenamiento basado en RocksDB en lugar de InnoDB, y cosas como Raft para replicación síncrona
      Realmente invirtieron una cantidad enorme de ingeniería excelente para hacer escalable la infraestructura de backend
      Material de referencia útil:
      [1] https://engineering.fb.com/2016/08/31/core-data/myrocks-a-sp...
      [2] https://research.facebook.com/file/529018501538081/hhvm-jit-...
      [3] https://research.facebook.com/file/700800348487709/HHVM_ICPE...
    • Fui ingeniero en los primeros años de Facebook, y el PHP de esa etapa inicial no se parecía en nada al PHP que se usaba para plantillas de sitios web. Había bibliotecas dedicadas de todo tipo que permitían un estilo de programación mucho más sofisticado
      Piensa en helpers funcionales, ejecución asíncrona sobre miles de núcleos y cosas como árboles de expansión que cruzaban centros de datos usando SSH. Como dato adicional, muchas de las buenas herramientas que yo usaba las creó Evan Priestley, quien también hizo Phabricator y varios sistemas muy potentes
    • Correcto. Python puro no era lo suficientemente rápido, así que hubo que hacer más trabajo
      “Está corriendo sobre el fork Cinder de Instagram, que incluye JIT, módulos con carga diferida, módulos estáticos precompilados y varios cambios interesantes frente a Python 3.10 puro”
      Eso salió en el tuit
      En lo personal, no me importa qué lenguaje use la gente. Todos sabemos que si hay dinero, puedes simplemente agregar más servidores. Bueno, hasta que el CFO y el CTO deciden que la siguiente gran prioridad es “reducir costos” por la desaceleración económica
      Me sorprende que en 2023 todavía se discuta la “preparación para producción” de los lenguajes de programación principales. Parece una competencia de “niños cool”
    • ¿Te refieres a esa empresa que para escalar de verdad tuvo que crear dos implementaciones de PHP y un traductor a C++?
    • La elección del lenguaje suele ser un caso de no ver el bosque por estar mirando los árboles. Elegir C++ en lugar de Python para ahorrar nanosegundos o ciclos se vuelve insignificante frente a gastar milisegundos en el límite de red leyendo de servicios de caché o bases de datos

  • Las partes que de verdad requieren mucho rendimiento están en varios servicios de agregación y recomendación basados en C++. Pero el servidor web, correctamente, es Django

    • Este tema realmente me interesa mucho. Me da curiosidad cómo saben que el servidor web es Django. Lo busqué, pero no encontré nada
      ¿Por qué usarían Django? Lo he usado en proyectos pequeños, pero no me pareció tan rápido y pensé que no encajaría en una app tan grande. Me gustaría conocer las ventajas y desventajas
      ¿Por qué no hacerlo en C++ o Rust? Aunque las partes pesadas estén en un lenguaje compilado, ¿Python no terminaría limitando el tiempo de respuesta? Puede que sea una pregunta ingenua de aficionado
    • Me parece interesante y hasta agradable que hayan decidido usar Django, pero me gustaría ver la fuente
    • Django no es un servidor web, es un framework WSGI/ASGI. Me pregunto qué usarán realmente para terminar el HTTP
    • Me pregunto cuánto usan anotaciones de tipos y verificación de tipos en el codebase
    • Corríjanme si me equivoco, pero Django no es un servidor web. Es un framework que se usa junto con un servidor de aplicaciones como gunicorn y un servidor web como nginx

  • “Está corriendo sobre el fork Cinder de Instagram, que incluye JIT, módulos con carga diferida, módulos estáticos precompilados y varios cambios interesantes frente a Python 3.10 puro”
    O sea, no es simplemente Python 3.10 a secas

    • He porteado código de Cinder a CPython. Este fork tiene varias optimizaciones que podrían incorporarse a CPython con relativa facilidad, y Facebook también está abierto a portar funcionalidades
      No sé si Facebook quiere seguir manteniendo el fork, pero del lado de CPython están abiertos a integrar ese tipo de funciones si tienen sentido
    • También hay que recordar que Python 3.10 está 9 versiones mayores por delante de 3.1
    • En sentido estricto, Python es una especificación, no una implementación

  • Es irónico que un artículo sobre el backend de Threads esté publicado en Twitter

    • Si quieren encontrar la verdadera ironía, aquí está: una app llamada Threads funcionando sobre Python, que tiene un bloqueo global del intérprete que complica el threading
      ¿Entendieron? Threads, threading… bueno, ya me voy
    • Threads, igual que Instagram, es una app solo para móviles. En un navegador de escritorio no se puede usar Threads de verdad, así que probablemente por eso se compartió como publicación de Twitter
      Incluso si hubiera sido una publicación de Threads, probablemente no se habría podido enviar a HN
    • Todavía no hay una app web. Parece que sí se puede enlazar directamente a un thread, pero solo muestra lo enlazado y ni siquiera enseña el árbol de discusión
      Aún no está abierto a la web. Dicen que en algún momento lo estará
    • ¿Por qué están votando esto negativamente? Es una observación válida
    • ¿Threads tiene ahora una versión web, o sigue siendo solo una app?

  • Está claro que el backend se superpone hasta cierto punto. https://www.threads.net/t/C es la primera publicación de Instagram, pero también aparece en Threads, y tiene exactamente la misma cantidad de likes que en Instagram
    Pero en https://www.threads.net/@kevin dice que no hay threads

  • Python es solo el servidor web. Los componentes realmente sensibles al rendimiento, como el proxy de borde, los balanceadores de carga, los servicios backend, las bases de datos, el caché y los servicios de almacenamiento, en su mayoría están en C++

    • Considero que el servidor web que maneja todas o la mayoría de las solicitudes sí es una parte sensible al rendimiento del sistema. En muchos casos, solo con reescribirlo de Python a Go se obtiene una mejora de rendimiento de 2 a 3 veces, y a escala FAANG eso puede marcar una gran diferencia en costos de hardware
    • Esa es precisamente la forma en que se pensó usar Python, y siempre se ha usado así desde hace mucho

  • He trabajado con Cinder y con servidores web. Puedo responder preguntas técnicas :)

    • Me pregunto si Cinder podría ayudar con la optimización de streaming en tiempo real. Nosotros recibíamos flujos UDP y, tras pasar por varias magias de gstreamer y nvidia deepstream, hacíamos inferencia de aprendizaje automático sobre el flujo en tiempo real. Según entiendo, un desarrollador senior lo implementó en Python
      Pero aquí la latencia era un gran problema y, como siempre, se bajó la prioridad de la optimización para poder llegar al MVP
      Así que me pregunto si Cinder puede usarse para optimizar streaming de datos en tiempo real, o si esta pregunta en sí significa que no entendí el caso de uso
      Como referencia, también usábamos Django, aunque ahora me pregunto si debimos haber cambiado a FastAPI. Esa es otra pregunta aparte
    • Me pregunto cuál es la funcionalidad con mayor impacto y más probabilidades de integrarse en CPython
    • Me pregunto si recomendarías usar Cinder en un stack compuesto por Django, Cython y Numpy
    • ¿Podrías explicar con más detalle la parte del servidor web? ¿Implementa WSGI?
    • ¿Quién puede beneficiarse de Cinder? ¿Para qué tipo de carga de trabajo está hecho? El README se queda un poco corto

  • Me gustaría saber más sobre el rollout. Se están sumando muchísimo más de 1 millón de usuarios nuevos por hora, lo cual es bastante impresionante

    • Supongo que ahora mismo habrán sobreaprovisionado enormemente para aguantar las primeras semanas, quizá meses, del crecimiento esperado
      Aun así, seguro hay muchos detalles interesantes que valdría la pena escuchar
    • El total de usuarios activos mensuales de todos los productos de Meta es de 3.8 mil millones
      Unos cuantos millones de usuarios nuevos ni siquiera representan el 0.1% del total. Está totalmente dentro de un rango de variación previsible
    • Simplemente está corriendo sobre la infraestructura compartida de Meta, que fue construida para manejar esa escala

  • Nunca hay que olvidar https://github.com/twitter/the-algorithm/pull/447

    • Por fin ya hay una diferencia entre los dos

  • Threads reutiliza el backend/API de Instagram. Instagram fue basado en Python desde el principio, y por eso Threads también terminó usando Python
    Eso no significa que debas elegir Python al crear una app nueva como esta cuando existen alternativas que no requieren un fork interno. Si lees la publicación completa, se entiende bastante fácil, pero la interfaz de Hacker News de “leer solo el título” parece estar distorsionándolo

    • Cálmense. Python es un lenguaje lo suficientemente bueno