Feda /dev/ - No Javascript allowed

#37712 >2B de mensajes por segundo para 1 solo cliente (de los que pagan me refiero). Pub/Sub a ese nivel no te lo da nadie. Google Pub/Sub si, si te quieres arruinar. Eso además de lo que ya tenemos ahora, pero con multi-cell que pongamos ya nos vale. Además hay que contar con meter más cosas de delivery guarantees, rate limiting (a ese nivel), observability, monitoring, security, ordering, etc. sin pagar un pastizal, ya que esto es solo para una parte de la app. Los 2B de concurrent connections son lo de menos.

Estaba yo leyéndome bien cómo implementar Scrum, y me he dado cuenta de que en mi trabajo no marcamos ni un check. Hay sprints, un backlog, dailies y toda esa parafernalia, pero nada de implementar Scrum tal y como fue conceptuado.

¿En vuestros trabajos también os lo saltáis a la torera o soy el único?

#37715 y qué más da. En esas cosas siempre es mejor adaptar y ser fluido, no ser puristas

#37713 tengo genuina curiosidad de qué se debe hacer ahí. Es decir, al leer eso tú sabes más o menos por donde tirarías pero... Qué compone semejante sistema para soportar ese volumen y que funcione como debe?

Los servicios se multiplican para soportar tráfico? Se escala con el metal? Se utiliza software ya creado y se adapta o se desarrolla software de 0? Debe ser un equipo grande, quiero decir, un ingeniero no le da para trabajar por un lado lo relacionado con el tráfico en sí y a la vez también desarrollar lo que sea que se haga para hacer algo así.

Osea, si es cuestión de Billones, eso ya de primeras debe ser una burrada de cpus, tarjetas de red y ram, además de un desarrollo a muy bajo nivel para encolar o gestionar el tráfico.

En resumen, se asemeja en algo a una infraestructura tradicional de un servicio tradicional? Backend, bbdd, sharding, cachés, balanceadores etc.

Joder, que luego tiras tú haces un backend y necesitas tirar de mierdas de libs de github cuyo éxito se basa en tirar de threading/multiprocessing, replicar en memoria el mismo servicio y con unos numeros de tráfico órdenes de magnitud más bajos. Vamos, la típica de backend + visor + nginx. Y cualquier problema iteras sobre eso y añades más mierdas.

#37713JuAn4k4:

Los 2B de concurrent connections son lo de menos.

Si ya te lo dije la ultima vez. Que eso no es ningun reto. Ya te conte que yo pique hace poco una gw para http...

1 segundo es una mierda... te diria que en FAANG estas cosas estaran sobre 100ms de latencia te lo podria preguntar... pero 100ms seria un reto. 1 segundo? por favor... yo creo que sin sacar un profiler me quedaria sobre los 200ms.

ademas, a ese nivel lo imortante son las colas, ya te lo dije tambien. esto es algo que te explican el primer dia: es mejor tener 200 ms de median y p99 de 250 y max de 300, que no tener 50ms de median, p99 de 100 y max de 200. como mas compacta la distribucion mas facil planificar la capacidad. de hecho esto es una metrica de google para bloquear merges.

a ojo creo que me haria una median de 200 con un p99 de 500. me pondria ese objetivo.

y los 2B si que te pueden importar para mantener las conexiones, porque para la cola es super importante estas cosas... pero si me dices que solo te importa tener 2B / s... pff muy manco tienes que ser.

https://beej.us/guide/bgnet/html/#intro

saca la capacidad por instancia y saca el coste de escalado... a ver si es rentable o no. haz una simulacion de que capacidad necesitarias y veras que 2B hoy en dia cualquier empresa lo paga...

Sabía perfectamente que iba a haber una respuesta de desu contando que él lo ha hecho mientras le hacen una mamada en 10 minutos y muchísimo mejor.

#37728 El habla de un gw http, eso te lo montas con nginx en una tarde, ya que son stateless. En sockets hay dos diferencias muy grandes, una, la más difícil de resolver es el pub/sub y routing, y la otra es el tener una conexión establecida (no es stateless) - Con lo que ello repercute al re-desplegar, re-balancear etc. Porque una máquina con 2000 conexiones muy parlanchinas puede estar sufriendo y otra con 1M andar sin despeinarse, y que de ese 1M de repente 5K se pongan en marcha.

#37727 xq ya le dije que justo pique una HTTP. Y me parecía interesantes ver diferencias.

Dicho esto no tiene 2B a 1s. Si ahora dice que escriben cada 20ms. Las conexiones dan igual, lo importante es rate de los request. Tiene 100B a 1s.

Que es aún más grande el número.

Ahora si el sla es 1s. Lo que le he dicho sigue aplicando... Difícil liarla, cuestión de meter dinero a algo que funcione y cortar gasto en el futuro... Y me parece difícil liarla mucho.

A ver que dice de ALB, eso sí es jodido.

#37726 si tienes 20ms es xq no dejan aws te iba a decir, xq sino ya mínimo serían 50ms. Yo te decía latencia e2e. Podéis usar ALB de entry point? yo tengo ALB y mi gw detrás.

2b casi te entran en un MacBook de hehxo, pase una vez un tío que se abrió cientos de millones de socket en su pc y tiro benchmarks de req / s XD ahí depende de las garantías de delivery y seguridad.

De lo que dices nse como hacer el stateless para mantener las conexiones calientes.. Xq eso es súper importante. O te entendí mal y te refieres a lo típico mandar los mensajes e instancias? Que es full stateless?

Lo de priority, routing, sharding y demás, a nivel de protocolo y gestionando los pools es súper fácil. Imo más fácil que en HTTP XD a la escala que yo lo he picado claro m. El problema que yo he visto es que la gente lo hace sobre HTTP en lugar de tcp.. Estáis diseñando vuestro propio protocolo para ello o usáis algo ya existente? Me molaría diseñar un protocolo ahí. Además en stream donde de un socket lees unos bytes y de ahí dispatch a otro que ya tienes ready.

Para el ratelimiting que vais a usar?

Como de homogeno son los paquetes. Me dices 20ms, eso es que no hay mucho que transigir. Me puedes dexie los bytes y el tiempo de write?? O tienes un profile de una escritura?? O flsmegraph.

Vais a usar a mano cosas nuevas de Linux a nivel de sys call? En que lenguaje y xq es rust?

Como funciona el discovery al enrutar internamente?? Xq full stateless tu me dirás, propagando? Eso no escala vs estado y sufrir inconsistencias eventuales... Xq hoy en día usamos raft + kv por algo. No veo quitar la. Kv

#37736 El rate es ese 2B de mensajes por segundo. Para el rate limit tenemos 3 soluciones internas mal hechas, usaremos leaking bucket en local, y para El cluster seguramente alguna en cluster pero para menores niveles ya que no aguantan 2B por segundo ni de fly.
Tenemos ALB si, los NLB fallan mucho, tenemos uno en la versión antigua, en la nueva Irán varios con self healing, ya que necesitamos llegar a 99.999% SLA =). Otro challenge, que el ALB te da 99.99% creo recordar, y fallan más de eso. Los NLB aún fallan más.

Contra más stateless hagas los servicios y no tengas nada centralizado, mejor escala. El problema de escalar es la centralización de algo y los estados compartidos.

Cuánto yaml, si, la mayoría horrorform por desgracia.