If you're seeing this message, it means we're having trouble loading external resources on our website.

Si estás detrás de un filtro de páginas web, por favor asegúrate de que los dominios *.kastatic.org y *.kasandbox.org estén desbloqueados.

Contenido principal

Sistemas escalables

Internet comenzó como una red para conectar universidades y centros de investigación. Cuando estuvo disponible y asequible para los consumidores, su popularidad se disparó y ahora su uso se estima en 4,500 millones de personas.
Un gráfico con años en el eje x (etiquetados de 1996 a 2015) y número de usuarios en el eje y (de 0 a 3 mil millones). La línea comienza en 75 millones y termina en 3,400 millones. Las divisiones muestran el número de usuarios por región (Europa y Asia Central, Asia Oriental y el Pacífico, América Latina y el Caribe, Asia del Sur, América del Norte, Oriente Medio y África del Norte, África subsahariana).
El número de usuarios de Internet de 1996 a 2015, agrupados por región. Fuente del gráfico: Our World in Data
Afortunadamente, los protocolos que impulsan Internet y Web fueron diseñados para ser escalables. Un sistema escalable es aquel que puede continuar funcionando bien aún cuando se incremente su uso.

Escalabilidad de Internet

¿Qué características aumentan la escalabilidad de Internet?
  • Cualquier dispositivo de cómputo puede enviar datos a través de Internet si sigue los protocolos. No hay ningún proceso burocrático que impida que un dispositivo se conecte o impida que un programador aprenda cómo funcionan los protocolos.
  • El sistema de direccionamiento IPv6 puede direccionar un billón de veces la cantidad de dispositivos conectados hoy día a Internet.
  • El enrutamiento es dinámico, por lo que enrutadores nuevos pueden unirse a la red en cualquier momento y contribuir a mover paquetes de datos por Internet.
Internet se diseñó para ser escalable, pero ningún sistema es infinitamente escalable.
¿Qué amenaza la escalabilidad de Internet? O puesto de otro modo, ¿Qué podría fallar si todos los dispositivos en el mundo se conectaran a Internet ahora mismo y trataran de descargar una película?
Aquí hay algunas ideas:
  • El ancho de banda de conexiones de red es limitado. Muchos datos pueden fluir fácilmente por conexiones de ancho de banda alto, pero pueden fácilmente ahogar conexiones de ancho de bandabajo, y ocasionar retrasos o a paquetes perdidos.
  • El rendimiento de enrutadores es limitado (la cantidad de datos que pueden reenviar por segundo). El rendimiento de un enrutador casero moderno es alrededor de 1 Gbps, mientras que los enrutadores empresariales mucho más costosos pueden reenviar hasta 10 Gbps. Una película promedio ocupa alrededor de 1 a 10 GB, así que una descarga en masa podría causar cuellos de botella en los enrutadores.
  • El número de dispositivos que pueden conectarse a los enrutadores inalámbricos a menudo es limitado, típicamente hasta 250. Si todos intentan usar una red WiFi al mismo tiempo (como en una universidad o biblioteca), puede ser que simplemente no pueden conectarse.
🤔 Basado en todo lo que has aprendido sobre Internet, ¿qué más podría afectar su escalabilidad, para bien o para mal?

Escalabilidad de aplicaciones Web

Una aplicación web que corre sobre Internet también debe ser escalable, ya sea una para iPhone, un sitio web, o un juego multijugador. Ahora que hay miles de millones de personas conectadas a Internet, cualquier aplicación puede experimentar un aumento repentino en el número de usuarios. Si la aplicación no se escala para satisfacer la demanda, los usuarios podrían experimentar una mayor latencia o una interrupción completa. 😬
Durante la pandemia COVID-19, en todo el mundo se le pidió a las personas que permanecieran en sus casas para disminuir la infección, y muchas corrieron a los servicios en línea a buscar versiones virtuales de lo que no podían hacer en persona. Debido a la cantidad de estudiantes que se dirigieron a Khan Academy para prácticas virtuales, nuestro sitio web experimentó un aumento de 250% en la carga de sus servidores.
Un gráfico con fechas en el eje x (del viernes 13 de marzo al miércoles 19 de marzo) y sin etiquetas en el eje y. El gráfico comienza con una joroba el viernes, dos jorobas bajas el fin de semana, y luego jorobas cada vez más grandes de lunes a miércoles. La joroba final es el doble del tamaño de la joroba inicial del viernes.
Solicitudes a nuestro servidor del viernes 13 de marzo al miércoles 18 de marzo. El uso siempre es menor los sábados y domingos.
El uso tan alto tomó a nuestros sistemas por sorpresa, y algunos a duras penas pudieron manejar el diluvio repentino de solicitudes. Por ejemplo, nuestro sistema para notificar a los estudiantes sobre tareas nuevas estaba desbordándose, y las notificaciones tomaban algunos minutos en aparecer (versus unos cuantos segundos).
Un gráfico con tiempo en el eje x (de la medianoche de marzo 16 a las 9:20 AM del día siguiente) y sin etiquetas en el eje y.. Una línea oscila cerca de cero hasta las 6 AM y comienza a dispararse hacia arriba, terminando cerca de la parte superior del eje y.
El gráfico muestra el registro de tareas sin procesar en el sistema de notificación de tareas, con tiempo en el eje x y el número de tareas aún no completadas en el eje y. El registro de tareas típicamente tiene cerca de cero tareas porque el sistema ejecuta las tareas tan pronto las crea, pero en este caso al sistema se asignaron tareas más rápido de lo que podía manejarlas y se acumuló un gran retraso.
Afortunadamente, nuestros ingenieros aumentaron rápidamente la capacidad de esos sistemas, y la mayoría de los usuarios nunca se dieron cuenta que algo no estaba funcionando bien.
Un gráfico con tiempo en el eje x (de la medianoche de marzo 16 a las 9:20 AM) y sin etiquetas en el eje y. Una línea oscila cerca de cero hasta las 6 AM y se comienza a disparar hacia arriba, alcanzando un pico cerca de las 9 AM. Luego se dispara hacia abajo a las 9:30 AM y permanece cerca de cero el resto del tiempo.
El registro de tareas en el sistema de notificación. Los ingenierons aumentaron la capacidad del sistema a las 9:30.

Pruebas de carga

Los equipos de ingeniería pueden prepararse para picos en uso haciendo pruebas de carga: simular gran cantidad de tráfico en un período corto de tiempo para ver si el sistema se dobla bajo la carga. Las pruebas de carga pueden descubrir cuellos de botella o límites predefinidos en el código del sistema.
Illustración de pruebas de carga. Se muestra un servidor con muchas flechas dirigidas hacia él.
¿Alguna vez jugaste Pokémon Go? Es un juego para móviles que apareció en el verano de 2016 y fue un éxito instantáneo. Los desarrolladores del juego hicieron pruebas de carga antes de lanzarlo al mercado, y simularon un tráfico 5 veces mayor al esperado. Los servidores del juego lo manejaron perfectamente.
Sin embargo, subestimaron enormemente la popularidad de Pokémon Go. El día del lanzamiento del juego, sus servidores tuvieron 50 veces el tráfico estimado.
Un gráfico lineal titulado "Transacciones de datos en la nube por segundo". Una línea está etiquetada como el "Objetivo lanzamiento original" y está cerca de la parte inferior del eje y. Otra línea está etiquetada como "Caso peor estimado" y está un poco por encima de la primera línea. La última línea está etiquetada como "Tráfico actual". Comienza entre la primera y la segunda línea, pero se dispara hacia arriba hasta llegar a ser 50 veces más alta que la segunda línea.
Las transacciones por segundo en el repositorio de datos de Pokémon Go. Las transacciones reales superaron enormemente las estimadas. Fuente: Google Cloud Blog
Los servidores del juego no estaban listos para ese nivel tan extremo de carga, así que muchos jugadores fueron saludados por una pantalla desilusionante:
Una pantalla de Pokémon Go que dice "Nuestros servidores están experimentando problemas. Por favor, regrese más tarde".
El equipo se apresuró a mejorar la escalabilidad del sistema, en medio de una creciente demanda de usuarios frustrados y de múltiples ataques de DDoS a sus servidores por parte de cibercriminales.
Un tweet de @PokemonGoApp que dice "Para asegurar que todos los entrenadores puedan experimentar #PokemonGo, seguimos añadiendo nuevos recursos para acomodarlos a todos. Gracias por su paciencia."
Un tweet hecho durante las interrupciones en el lanzamiento. Fuente: Twitter
Después de reconfigurar su arquitectura de servidores para que fuera más escalable, el equipo lanzó Pokémon Go al resto del mundo. En los tres años siguientes, se ha descargado más de mil millones de veces de las tiendas de aplicaciones móviles.

El espectro de escalabilidad

Un sistema es escalable si tiene la capacidad de acomodar una mayor cantidad de uso. Algunos sistemas no son escalables en absoluto y solo pueden manejar exactamente la cantidad de uso para el que fueron diseñados.
Los sistemas escalables pueden manejar uso extra, pero su capacidad varía. Algunos sistemas solo pueden escalarse hasta manejar el doble del uso actual; otros sistemas pueden escalarse hasta manejar 1000x el uso actual.
Cuando diseñamos sistemas con un alcance potencialmente global—como la misma Internet o las aplicaciones que corren sobre ella—tenemos que considerar siempre la escalabilidad de nuestro enfoque.

🙋🏽🙋🏻‍♀️🙋🏿‍♂️¿Tienes alguna pregunta sobre este tópico? Nos encantaría contestarte; ¡simplemente pregunta en el área de preguntas abajo!

¿Quieres unirte a la conversación?

  • Avatar sneak peak purple style para el usuario J.
    Nota: Los sistemas escalables son los que se adaptan a la cantidad de usuarios que pueden entrar al sistema, evitando que este caiga. Hay otros que solo pueden escalar hasta cierto punto.
    (1 voto)
    Avatar Default Khan Academy avatar para el usuario
¿Sabes inglés? Haz clic aquí para ver más discusiones en el sitio en inglés de Khan Academy.