¿Cómo los grandes sitios web que no pueden ser completamente apátridas logran una escalabilidad extrema en el nivel web?Sharding (sic!) El nivel web para evitar un cuello de botella de equilibrio de carga?
Hay sitios como eBay y Amazon, que no pueden ser completamente apátridas, ya que tienen un carrito de compras o algo así. No es factible codificar cada elemento en el carrito de compras en la URL, ni es factible codificar cada elemento en una cookie y enviarlo en cada conexión. Entonces Amazon simplemente almacena el ID de sesión en la cookie que se envía. Así que entiendo que la escalabilidad del nivel web de eBay y Amazon debería ser mucho más difícil que la escalabilidad del motor de búsqueda de Google, donde todo puede codificarse en la URL.
Por otro lado, tanto eBay como Amazon escalaron de forma absolutamente masiva. Se rumorea que hay unos 15000 servidores de aplicaciones J2EE en eBay.
¿Cómo manejan estos sitios ambos: escalabilidad y estado extremos? Como el sitio es estable, no es factible hacer un simple DNS-Balancing. Entonces uno podría suponer que estas compañías tienen un equilibrador de carga basado en hardware como BigIP, Netscaler o algo así, que es el único dispositivo detrás de la única dirección IP de ese sitio. Este equilibrador de carga descifraría el SSL (si está codificado), inspeccionaría la cookie y decidiría según el id. De sesión de esa cookie cuyo servidor de aplicaciones tenga la sesión de ese cliente.
¿Pero esto simplemente no puede funcionar ya que ningún equilibrador de carga podría manejar la carga de miles de servidores de aplicaciones? Me imagino que incluso estos equilibradores de carga de hardware no se escalan a tal nivel.
Además, el balanceo de carga se realiza de forma transparente para el usuario, es decir, los usuarios no se reenvían a direcciones diferentes, pero todos permanecen colectivamente en www.amazon.com todo el tiempo.
Así que mi pregunta es: ¿hay algún truco especial con el que se pueda lograr algo así como una fusión transparente del nivel web (no el nivel de la base de datos como se hace comúnmente)? Siempre que la cookie no se inspeccione, no hay manera de saber qué servidor de aplicaciones está llevando a cabo esta sesión.
Edit: Me di cuenta de que solo hay necesidad de transparencia, si es necesario que el sitio se filtre y se marque como favorito. P.ej. si el sitio es una mera aplicación web, algo así como un avión o un sistema de reserva de boletos de tren, no debería haber ningún problema con solo redirigir a los usuarios a grupos específicos de servidores web detrás de diferentes URL, p. a17.ticketreservation.com. En este caso específico, sería posible usar múltiples clústeres de servidores de aplicaciones, cada uno detrás de su propio equilibrador de carga. Curiosamente, no encontré un sitio que utiliza este tipo de concepto. Edit: Encontré este concepto discussed en highscalability.com, donde la discusión se refiere a un artículo de Lei Zhu llamado "Client Side Load Balancing for Web 2.0 Applications". Lei Zhu usa scripts cruzados para hacer este balance de carga del lado del cliente de forma transparente.
Incluso si hay inconvenientes, como marcadores, xss, etc., creo que esto suena como una muy buena idea para ciertas situaciones especiales, es decir, aplicaciones web casi sin contenido, que no son necesarias para ser spidered o marcadas (por ejemplo, sistemas de reserva de boletos o algo así). Entonces no hay necesidad de hacer el balanceo de carga de forma transparente.
Podría haber un simple redireccionamiento del sitio principal al servidor, p. una redirección de www.ticketreservation.com a a17.ticketreservation.com. A partir de ahí, el usuario permanece en el servidor a17. a17 no es un servidor, sino un clúster en sí mismo, por el cual se puede lograr la redundancia.
El servidor de redirección inicial podría ser un clúster detrás de un equilibrador de carga. De esta forma, se podría lograr una escalabilidad realmente alta, ya que el equilibrador de carga primario detrás de www solo se golpea una vez al comienzo de cada sesión.
Por supuesto, la redirección a diferentes URL parece extremadamente desagradable, pero con simples aplicaciones web (que no necesitan ser spidered, deep-linked o deep-bookmarked de todos modos), esto debería ser solo un problema óptico para el usuario ?
El redirect-cluster podría sondear la carga de los clústeres de aplicaciones y adaptar los redireccionamientos en consecuencia, logrando así el equilibrio y no la distribución de la mera carga.
¿Cómo encuentran los servidores web sin estado el servidor de aplicaciones correcto? ¿Cada servidor web tiene que saber sobre cada sesión que tiene cualquier servidor de aplicaciones? ¿No sería esta horrible comunicación por encima? – SAL9000
Los balanceadores de carga usan su identificación de sesión o posible su dirección IP como entrada para elegir el servidor de la aplicación. Si cada equilibrador de carga tiene el mismo algoritmo para elegir el servidor de la aplicación, no debería importar a qué equilibrador de carga que vaya, siempre se lo enviará al mismo servidor de aplicaciones. No hay comunicación entre el servidor de aplicaciones y el equilibrador de carga involucrado. –