Me ha sorprendido leer algunos tweets de la situación que ya sabemos, del sitio que sigue caído, del gobierno que ya discutimos, porque se asume que para llegar a 70K requests por segundo se necesita replicar la infra de Google.
Hilo de opciones para pensar en como hacerlo:
Hilo de opciones para pensar en como hacerlo:
Como todos sabemos (o no) existe dos maneras principales de escalabilidad: crecer horizontalmente (más instancias/servers de tu app) o verticalmente (servidores más potentes).
Pero ya existe tanto infraestructura, techstacks y setups que "out of the box" te permiten...
Pero ya existe tanto infraestructura, techstacks y setups que "out of the box" te permiten...
llegar a cientos requests por segundo (rps).
¿Ejemplo?
WordPress.
Así es, el "love it hate it" que powerea el 40% de la web (W3Techs) y montado en un GCP c2-standard-30, te permite llegar a 233.40 rps.
Benchmarks:
[kinsta.com/blog/php-bench…](kinsta.com/blog/php-bench…)
¿Ejemplo?
WordPress.
Así es, el "love it hate it" que powerea el 40% de la web (W3Techs) y montado en un GCP c2-standard-30, te permite llegar a 233.40 rps.
Benchmarks:
[kinsta.com/blog/php-bench…](kinsta.com/blog/php-bench…)
Ahora, ni WordPress es considerado el mega-producto en performance, ni c2-standard-30 es el servidor con más galleta de GCP.
Pero, estamos obteniendo rps out-of-the-box, lo cual, por lo cual si quisiera llevar a 1,000 rps, lo que haría sería:
Pero, estamos obteniendo rps out-of-the-box, lo cual, por lo cual si quisiera llevar a 1,000 rps, lo que haría sería:
Poner:
1 load balancer (LB)
4 instancias de WP en servidores diferentes
1 DB (por aquello de evitar duplicación de datos).
La razón es que al aplicar *matemática burda* y asumir que 4 servidores detrás de un LB con 4 instancias, lo multiplica por 4:
233.40 rps * 4 = 933.6 rps
1 load balancer (LB)
4 instancias de WP en servidores diferentes
1 DB (por aquello de evitar duplicación de datos).
La razón es que al aplicar *matemática burda* y asumir que 4 servidores detrás de un LB con 4 instancias, lo multiplica por 4:
233.40 rps * 4 = 933.6 rps
Close enough.
Pero ya sale el primer peine: la DB.
¿Cómo hacer que una sola instancia aguante las peticiones de todas las instancias?
Mi primera opción: me iría directo a AWS Aurora Serverless y dejo que escale automáticamente.
aws.amazon.com/rds/aurora/ser…
Pero ya sale el primer peine: la DB.
¿Cómo hacer que una sola instancia aguante las peticiones de todas las instancias?
Mi primera opción: me iría directo a AWS Aurora Serverless y dejo que escale automáticamente.
aws.amazon.com/rds/aurora/ser…
(Perdón, no conozco a detalle los productos de GCP pero estoy seguro que tiene algo parecido).
¿Pá que me meto en optimización de DBs si puedo dejarlo a que el servidor tenga escalabalidad y monitoreo propio?
¿Pá que?...
¿Pá que me meto en optimización de DBs si puedo dejarlo a que el servidor tenga escalabalidad y monitoreo propio?
¿Pá que?...
Ahora, es importante recalcar que aquí no nos hemos metido en configuraciones complejas: todo está funcionando "out of the box" y sin tunearles nada.
Simplemente estuvimos enchufando cables y dejando que hagan lo que tienen que hacer.
Pero ¿y si metemos un servidor más potente?
Simplemente estuvimos enchufando cables y dejando que hagan lo que tienen que hacer.
Pero ¿y si metemos un servidor más potente?
En GCP, nos brincamos de un c2-standard-30 a un c2-standard-60 que ofrece el doble de CPUs y doble de RAM.
Siguiendo nuestra lógica de matemática burda esto nos haría decir que duplicamos nuestros rps, pues todo se dobló: CPU y RAM:
933.6 * 2 = 1,867.2 rps
Siguiendo nuestra lógica de matemática burda esto nos haría decir que duplicamos nuestros rps, pues todo se dobló: CPU y RAM:
933.6 * 2 = 1,867.2 rps
Y adivinen que: así es, seguimos sin meternos en tuneo o cosas complejas.
Y obviamente *asumiendo* que tu desarrollo no altera demasiado WP ni es tan complejo (lo cual sabemos que puede ser muy lejos de ser la realidad) y no tienes un desmadre de relaciones en tu DB de Aurora.
Y obviamente *asumiendo* que tu desarrollo no altera demasiado WP ni es tan complejo (lo cual sabemos que puede ser muy lejos de ser la realidad) y no tienes un desmadre de relaciones en tu DB de Aurora.
Pero ya sabemos en teoría como llegar a +1,800 rps, lo que nos dice que nos saldría bastante caro y con bastantes servidores el poder llegar a 70,000 rps.
¿Por qué? Pues porque:
70,000 / 1800 = 38.8
Asumiendo lo que ya asumimos y con esos benchmarks en pie, necesitaríamos 38.8 instancias de apps montadas en un 38.8 c2-standard-60 de GCP.
Ahora, teóricamente es posible... ¿Pero cómo lo testeamos?
70,000 / 1800 = 38.8
Asumiendo lo que ya asumimos y con esos benchmarks en pie, necesitaríamos 38.8 instancias de apps montadas en un 38.8 c2-standard-60 de GCP.
Ahora, teóricamente es posible... ¿Pero cómo lo testeamos?
Para estos números yo he usado algunas opciones como:
- crear rudimentariamente un proceso que es clonado cientos de veces que lanza peticiones concurrentes (digamos, un set de cronjobs que lanzan cientos de curl requests)
- Neoload
- flood.io
- crear rudimentariamente un proceso que es clonado cientos de veces que lanza peticiones concurrentes (digamos, un set de cronjobs que lanzan cientos de curl requests)
- Neoload
- flood.io
El 1ro es gratis, pero pues todo te lo tienes que aventar a pelo para crear un proceso de procesos concurrentes (no paralelismo) que puedas contabilizar y esperar lo mejor.
En el 2do creas tus escenarios y lo integras con tu app y flujo.
En el 2do creas tus escenarios y lo integras con tu app y flujo.
Con flood.io tienes un SaaS que te permite hacer load testing en ya sea tu pipeline de CI/CD o en algún server.
Ahora, aquí a lo mejor no necesitas probarlo en 38.8 servidores y con 70,000 requests. Pero digamos, queremos probar primero que todo lo que decimos es opción:
38.8 / 4 = 9.7
70k / 4 = 17,500
Testeando con 1/4 de lo planeado podemos ver si vamos en el camino correcto.
38.8 / 4 = 9.7
70k / 4 = 17,500
Testeando con 1/4 de lo planeado podemos ver si vamos en el camino correcto.
Una vez con resultados, podemos empezar a evaluar y preguntarnos ¿y si estamos haciendo las cosas bien?
Es el momento de entender los temas específicos de una aplicación:
Existen LBs, cache, posibles sesiones que se guardan en el servidor, limites por default en threads, (cont)
Es el momento de entender los temas específicos de una aplicación:
Existen LBs, cache, posibles sesiones que se guardan en el servidor, limites por default en threads, (cont)
diferentes opciones que no son WP, otros lenguajes de programación, CDNs, límites por default en las conexiones a DB, etc.
TODO y cada parte cuenta cuanto quieres escalabilidad.
TODO y cada parte cuenta cuanto quieres escalabilidad.
Podemos empezar con lo básico: ya sabemos que no necesitamos WP para todo esto. No vamos a bloggear, vamos a asumir que:
- Cargamos página estática
- Metemos CURP
- Se valida y registra el CURP en la DB
- Se pone un timestamp
Y ya
- Cargamos página estática
- Metemos CURP
- Se valida y registra el CURP en la DB
- Se pone un timestamp
Y ya
Para esto, podemos seleccionar el benchmark de Swoole, un framework de PHP que nos da 110,515 rps "out of the box", en un server mucho menos poderoso que los 38 que vimos con WP:
- CentOS 7 64bit
- 8GB Memory
- 24 Cores
- E5-2620 v2 @ 2.10GHz
- PHP 7.1
(swoole.co.uk/benchmark)
- CentOS 7 64bit
- 8GB Memory
- 24 Cores
- E5-2620 v2 @ 2.10GHz
- PHP 7.1
(swoole.co.uk/benchmark)
Pero claro, Uds son más expertos que yo en escalabilidad que yo y sabemos que PHP es anticuado y viejo y no sirve para esto, sin importar que Vimeo, Slack, PornHub, Wikipedia, Mailchimp y otros sitios de alto impacto usan PHP, así que pasémonos a otro flavor: Node.js.
Como podrán saber, decir Node.js es decir "quien sabe que habrán hecho" porque hay tantos sabores y colores, que no podemos comparar equitativamente algo hecho con Koa vs Express vs creíste ciegamente en el GitHub de quien sabe quien, aparte, puedes haberlo montado con pm2,
sin pm2, con Supervisord, sin Supervisord, integrado o sin Sentry, etc.
Igual que otros lenguajes pues.
Pero, vamos a buscar algo "performante" y veamos Fastify.
fastify.io
Igual que otros lenguajes pues.
Pero, vamos a buscar algo "performante" y veamos Fastify.
fastify.io
Nos da un benchmark de 64,683 r/s, nada mal.
Nos da casi la mitad de lo que nos da Swoole pero sabemos que PHP es del diablo.
Así que nos aferramos a decir que Node.js está mejor.
Nos da casi la mitad de lo que nos da Swoole pero sabemos que PHP es del diablo.
Así que nos aferramos a decir que Node.js está mejor.
No perdón, antes de irnos, se me olvidó decir:
Igual si estás usando Express pásate al framework de Phalcon de PHP, te da (en el benchmark de 2016) casi el doble de lo que te da Express en Node.js:
toptal.com/phalcon/phalco…
Igual si estás usando Express pásate al framework de Phalcon de PHP, te da (en el benchmark de 2016) casi el doble de lo que te da Express en Node.js:
toptal.com/phalcon/phalco…
Ya ahora si dejamos el tema de que PHP si sirve y otras leyendas urbanas...
Pero, hasta aquí ¿te has dado cuenta que he estado comparando rps entre libs y frameworks sin compartir si lo hicieron en el mismo server con las mismas características?
Pero, hasta aquí ¿te has dado cuenta que he estado comparando rps entre libs y frameworks sin compartir si lo hicieron en el mismo server con las mismas características?
Esto lo acentúo porque: si no entendiste cómo hicieron el benchmark: el benchmark no te sirve de nada.
Necesitas el contexto del benchmark para evaluar "rápido" o lento, lo cual las conversaciones tuiteras olvidan en aclarar, claro está.
Necesitas el contexto del benchmark para evaluar "rápido" o lento, lo cual las conversaciones tuiteras olvidan en aclarar, claro está.
Pero regresamos a nuestro problema: 70k y queremos meterle Node.js con Fastify.
Los benchmarks de ellos nos meten en otro problema:
Utilizaron Azure (la nube de Microsoft) así que nuestro GCP sale volando y ya no sabemos ni que pedo con la vida.
Los benchmarks de ellos nos meten en otro problema:
Utilizaron Azure (la nube de Microsoft) así que nuestro GCP sale volando y ya no sabemos ni que pedo con la vida.
- **Machine:** Linux fv-az50-626 5.4.0-1036-azure #38~18.04.1-Ubuntu SMP Wed Jan 6 18:26:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | 2 vCPUs | 7GB.
- **Method:** `autocannon -c 100 -d 40 -p 10 localhost:3000` (two rounds; one to warm-up, one to measure).
- **Node:** `v12.20.1`
- **Method:** `autocannon -c 100 -d 40 -p 10 localhost:3000` (two rounds; one to warm-up, one to measure).
- **Node:** `v12.20.1`
Por suerte alguien hizo pruebas de Fastify en AWS para un "hello world" (out of the box) obtiene +30,000 rps:
"benchmarks in this post were run on an Amazon EC2 m4.xlarge instance, with an Intel Xeon E5-2686 v4 @ 2.30GHz (4 cores, 8 threads) and 16GiB RAM." We used Node 8.4.0
"benchmarks in this post were run on an Amazon EC2 m4.xlarge instance, with an Intel Xeon E5-2686 v4 @ 2.30GHz (4 cores, 8 threads) and 16GiB RAM." We used Node 8.4.0
El node es un poco viejito, pero sirve (v8)
[nearform.com/blog/reaching-…](nearform.com/blog/reaching-…)
[nearform.com/blog/reaching-…](nearform.com/blog/reaching-…)
Eah! ya viste como bajamos de casi 40 servidores "out of the box" a pensar en únicamente 2 instancias de AWS EC2 m4.xlarge con Fastify (que nuevamente, NO SON los servidores con más galleta).
Entonces, asumiendo que queremos únicamente llegar a 70,000 requests por segundo "out of the box":
- 1 load balancer
- 2 instancia de EC2 m4.xlarge
- 1 instancia de Aurora Serverless
- Node.js (usen la v14 que es LTS)
- Fastify
¡Voilá! Tiempo de testear...
- 1 load balancer
- 2 instancia de EC2 m4.xlarge
- 1 instancia de Aurora Serverless
- Node.js (usen la v14 que es LTS)
- Fastify
¡Voilá! Tiempo de testear...
Ahora, claro: no debemos *sobre-simplicar* las cosas, pues cuando entra la aplicación en desarrollo empieza a crearse un pequeño o gran monstruo: otras bases de datos, CDNs, limtantes de memoria, validaciones, workflows.
Pero hablemos de posibles ideas para prevenir lo que paso.
Pero hablemos de posibles ideas para prevenir lo que paso.
- Cache
¿Qué pasa si una persona regresa y quiere de nuevo su "hello world"? ¿Podemos utilizar un cache sin tener que llegar a nuestra DB para dárselo?
¿Qué pasa si una persona regresa y quiere de nuevo su "hello world"? ¿Podemos utilizar un cache sin tener que llegar a nuestra DB para dárselo?
Throttling:
Tener un sistema de monitoreo que detecte CPU, I/O en la DB, si esta supera el 80% lanza un flag que empieza a hace que la aplicación deje de procesar requests nuevos y regrese un HTTP 429
developer.mozilla.org/en-US/docs/Web…
Tener un sistema de monitoreo que detecte CPU, I/O en la DB, si esta supera el 80% lanza un flag que empieza a hace que la aplicación deje de procesar requests nuevos y regrese un HTTP 429
developer.mozilla.org/en-US/docs/Web…
Como nota, API Gateway en AWS te da un default de 10,000 r/s segundo antes de empezar a mandar 429 automáticamente:
docs.aws.amazon.com/apigateway/lat…
docs.aws.amazon.com/apigateway/lat…
* CRQS
Normalmente pensamos en sistemas "CRUD", pero, y si separas los reads de los writes? En cualquier base de datos (en mi experiencia) esto hace que sean mucho más eficientes.
El concepto es para sistemas distribuidos y Event Driven Architectures.
hackernoon.com/cqrs-command-q…
Normalmente pensamos en sistemas "CRUD", pero, y si separas los reads de los writes? En cualquier base de datos (en mi experiencia) esto hace que sean mucho más eficientes.
El concepto es para sistemas distribuidos y Event Driven Architectures.
hackernoon.com/cqrs-command-q…
Solo por no extender el thread... Pero son solo ideas que vas incorporando y puliendo en base a tus necesidades.
Al final del día, con este setup idealmente llegamos a miles de requests por segundo, donde ahora nos toca empezar evaluar como escalar nuestro desarrollo con rps.
Al final del día, con este setup idealmente llegamos a miles de requests por segundo, donde ahora nos toca empezar evaluar como escalar nuestro desarrollo con rps.
Lo importante a entender en temas de tráfico pueden ser resueltos y que existen muchísimas herramientas allá afuera que te permiten hacerlo sin volverte Google.
Y repito:
*No quiero simplificar* un proceso técnico que sí requiere análisis más detallados, benchmarks y casos y tests de usuarios.
Pero también si quiero decirles que con herramientas que están disponibles y no almacenadas en algún lugar secreto de Google, se puede hacer.
*No quiero simplificar* un proceso técnico que sí requiere análisis más detallados, benchmarks y casos y tests de usuarios.
Pero también si quiero decirles que con herramientas que están disponibles y no almacenadas en algún lugar secreto de Google, se puede hacer.
Oséase: ni tanto que queme al santo, ni tanto que no lo alumbre.
En mi experiencia: he tenido la oportunidad de obtener 15,000 requests por segundo en microservicios:
1. Sin serverless
2. Sin kubernetes
3. Sin magia complicada
Simplemente: tuneando servicios existentes. Y más de eso, si lo hice con serverless.
1. Sin serverless
2. Sin kubernetes
3. Sin magia complicada
Simplemente: tuneando servicios existentes. Y más de eso, si lo hice con serverless.
Si quieres aprender como lo hacen algunas personas:
5K y 20K requests por segundo (via AWS ECS)
[medium.com/followanalytic…](medium.com/followanalytic…)
5K y 20K requests por segundo (via AWS ECS)
[medium.com/followanalytic…](medium.com/followanalytic…)
1 millon de requests por segundio (via Fargate)
"1 AWS Network Load Balancer to have a single target to test 150 Fargate containers with 2 cores and 4GB RAM each running our testapp".
[stormforger.com/blog/perf-test…](stormforger.com/blog/perf-test…)
"1 AWS Network Load Balancer to have a single target to test 150 Fargate containers with 2 cores and 4GB RAM each running our testapp".
[stormforger.com/blog/perf-test…](stormforger.com/blog/perf-test…)
1 millón de requests por segundo (via Kubernetes)
[kubernetes.io/blog/2015/11/o…](kubernetes.io/blog/2015/11/o…)
[kubernetes.io/blog/2015/11/o…](kubernetes.io/blog/2015/11/o…)
P.D No se asusten por números grandes. Existen soluciones técnicas que bigtech ha venido solucionando y que puedes re-utilizar, siempre y cuando le eches coco y adecues a tus necesidades.
P.D Mi matemática fue tan burda que el cálculo de los 38 servers está mal:
Son 38 clústers de servers de 4.
Lo que equivaldría a 172 servers.
Así que cada que leíste 38, cambialo por 172.
Urge ese edit button*.
Son 38 clústers de servers de 4.
Lo que equivaldría a 172 servers.
Así que cada que leíste 38, cambialo por 172.
Urge ese edit button*.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
