¿Está destruyendo (¡sic!) El nivel web para evitar un cuello de botella en el equilibrador de carga?

Question

¿Cómo pueden los sitios web grandes que no pueden ser completamente sin estado lograr una escalabilidad extrema en el nivel web?

Hay sitios como eBay y Amazon, que no pueden ser completamente sin estado, ya que tienen un carrito de compras o algo así. No es posible codificar todos los artículos del carrito de compras en la URL, ni es posible codificar todos los elementos en una cookie y enviarlos a cada conexión. Así que Amazon simplemente almacena la ID de sesión en la cookie que se está enviando. Por lo tanto, 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 extrema y estado de estado? Como el sitio tiene un estado, no es factible hacer un simple balanceo de DNS. Así que uno podría asumir 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 descifra el SSL (si está codificado), inspecciona la cookie y decide, dependiendo del identificador de sesión de esa cookie, qué servidor de aplicaciones tiene 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 ese nivel.

Además, el equilibrio de carga se realiza de forma transparente para el usuario, es decir, los usuarios no se reenvían a direcciones diferentes, sino que todos permanecen colectivamente en www.amazon.com todo el tiempo.

Entonces, mi pregunta es: ¿hay algún truco especial con el que se pueda lograr algo así como fragmentación transparente del nivel web (no el nivel de base de datos como se hace comúnmente)? Siempre que la cookie no se inspeccione, no hay forma de saber qué servidor de aplicaciones tiene esta sesión.

Editar: Me di cuenta de que solo existe la necesidad de transparencia, si es necesario que el sitio esté arañado y marcado. P.ej. Si el sitio es una mera aplicación web, algo así como un sistema de reservación de boletos de avión o 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, por ejemplo. a17.ticketreservation.com. En este caso específico, sería factible utilizar múltiples clústeres de servidores de aplicaciones, cada uno detrás de su propio equilibrador de carga. Curiosamente, no encontré un sitio que usara este tipo de concepto. Editar: encontré este concepto discutido en highscalability.com , donde la discusión se refiere a un artículo de Lei Zhu llamado " Equilibrio de carga del lado del cliente para aplicaciones Web 2.0 " . Lei Zhu usa scripts cruzados para hacer este equilibrio 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 sin contenido, que no se necesitan para ser rastreadas o marcadas ( Por ejemplo, sistemas de reserva de entradas o algo así. Entonces no hay necesidad de hacer el balanceo de carga de forma transparente.

Podría haber un simple redireccionamiento desde el sitio principal al servidor, por ejemplo. una redirección de www.ticketreservation.com a a17.ticketreservation.com. A partir de ahí el usuario se queda en el servidor a17. a17 no es un servidor, sino un clúster en sí mismo, mediante 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 manera, se podría lograr una escalabilidad realmente alta, ya que el equilibrador de carga principal detrás de www solo se alcanza una vez al comienzo de cada sesión.

Por supuesto, la redirección a diferentes URL se ve extremadamente desagradable, pero con meras aplicaciones web (que no necesitan ser rastreadas, vinculadas o marcadas), ¿esto debería ser solo un problema óptico para el usuario?

El grupo de redireccionamiento podría sondear la carga de los clústeres de la aplicación y adaptar los redireccionamientos en consecuencia, logrando así el equilibrio y no la mera distribución de la carga.

Answer 1

Fácil. Los servidores web, que son sin estado, tienen carga equilibrada. Los servidores de aplicaciones (nivel medio), que contienen los datos de la sesión, no lo son. Los servidores web pueden usar su cookie de identificación de sesión para determinar con qué servidor de aplicaciones contactar.

Memcached y la velocidad de Microsoft son productos que resuelven esta necesidad exacta.

Editar: ¿Cómo sabe un servidor web con qué servidor de aplicaciones contactar? Esto está incrustado en el hash de identificación de sesión, y se podría hacer genéricamente como quieras. Podría ser tan simple como su ID de sesión siendo servidor: guid. Memcached lo basa en el hash, sin embargo.

Lo importante es que el cliente tiene que ser capaz de averiguar qué servidor de aplicaciones contactar sin estado. La forma más fácil de hacerlo es incrustarla en la clave, aunque un registro (quizás en su propio nivel) también funcionaría y podría proporcionar alguna tolerancia a fallos.

Edit2: volviendo sobre algunas Ebay entrevistas , es posible que haya obtenido los detalles de su Implementación un poco mal. No hacen almacenamiento en caché, y no hacen estado en el nivel medio. Lo que hacen, es tener un nivel intermedio de carga equilibrada (servidores de aplicaciones) particionado por función. Por lo tanto, tendrían un grupo de servidores para, por ejemplo, ver elementos. Y luego otro grupo para vender artículos.

Esos servidores de aplicaciones tienen un " inteligente " DAL que se enruta a bases de datos fragmentadas (particionadas tanto por función como por datos, por lo que los Usuarios A-L en Base de Datos1, Usuarios M-Z en Base de Datos2, Artículos 1-10000 en Artículos1, etc.).

No tienen estado en el nivel medio porque están particionadas por función. Por lo tanto, una experiencia de usuario normal implicaría más de 1 grupo de servidores de aplicaciones. Supongamos que ve un artículo (ViewAppServerPool), luego vaya a ofertar en un artículo (BidAppServerPool). Todos esos servidores de aplicaciones tendrían que permanecer sincronizados, lo que luego requiere un caché distribuido para administrar todo. Pero, su escala es tan grande que ningún caché distribuido podría administrarlo de manera efectiva, ni tampoco un solo servidor de base de datos. Esto significa que tienen que dividir el nivel de datos, y cualquier implementación de caché debería dividirse en los mismos límites.

Esto es similar a lo que publiqué anteriormente, solo bajé una capa. En lugar de que el servidor web determine con qué servidor de aplicaciones contactar, el servidor de aplicaciones determina con qué base de datos contactar. Solo que, en el caso de Ebay, en realidad podría estar afectando a más de 20 servidores de bases de datos debido a su estrategia de partición. Pero, nuevamente, el nivel sin estado tiene algún tipo de regla (s) que usa para contactar al nivel con estado. Sin embargo, las reglas de Ebay son un poco más complicadas que el simplista " User1 está en Server10 " Regla que estaba explicando arriba.

Answer 2

Puede encontrar útil el siguiente documento, que presenta el diseño y la implementación de un sistema de almacenamiento de clave-valor altamente disponible que algunos de los servicios principales de Amazon utilizan para proporcionar un & # 8220; siempre activo & # 8221; experiencia:

Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swami Sivasubramanian, Peter Vosshall y Werner Vogels , y # 8220; Dynamo: Almacén de clave-valor altamente disponible de Amazon & # 8221 ;, en el Procedimiento de el 21º Simposio ACM sobre Principios de Sistemas Operativos, Stevenson, WA, octubre de 2007.

Answer 3

Probablemente tendría que estar en el equipo de ingeniería en uno de estos lugares para estar seguro, pero hay personas que han hecho conjeturas informadas a partir de charlas y otra información que ha salido de ambos lugares:

Ebay Architecture y Amazon Architecture

Solo un solo equilibrador de carga en sí mismo en el mundo de hoy es el equivalente al DNS round robin de años pasados. Hoy tienes cosas como anycast que te permiten jugar todo tipo de trucos. Puede estar bastante seguro de que los usuarios de ebay y amazon usan balanceadores de carga y usan muchos de ellos.

Es posible que desee reducirlo un poco más cuando piense cómo podría funcionar, ya que gran parte del tráfico es apátrida. En una sola solicitud de una página, hay potencialmente muchos objetos que no necesitan saber sobre el estado. Saque esos objetos de la imagen sirviéndolos desde un sistema sin estado (aquí es donde entra el anycast) y la cantidad de solicitudes disminuye dramáticamente.

Si eso no lo lleva al punto de que un solo equilibrador de carga puede manejar la carga, el siguiente paso es dividir las transacciones mediante enrutamiento IP y / o geo-DNS. Sitios tan grandes como ebay y amazon estarán en varios centros de datos con una gran cantidad de conexiones a internet en cada uno. Toma todo lo que viene de internet pop quest-west y lo envía al centro de datos de la costa oeste " quest " servidores, cualquier cosa desde att-west se envía al centro de datos de la costa oeste " att " servidores, cualquier cosa desde quest-east y va al centro de datos de la costa este " quest " servidores, etc. Cada uno de esos sistemas podría ser una isla, un único equilibrador de carga que podría manejar la carga, algunos de los equilibradores de carga que hay por ahí pueden manejar cientos de miles de transacciones por segundo, incluso con cifrado SSL. En la parte posterior, se replica en masa en cada centro de datos constantemente, pero puede estar desincronizado.

Answer 4

No sé cómo lo hacen, pero aquí hay algunas sugerencias:

• Para evitar la sobrecarga de un host de equilibrador de carga, use el DNS de round-robin O
• Redirige diferentes clientes a diferentes direcciones de clúster según la carga, la configuración, la geolocalización, etc.

Para distribuir la carga del nivel medio,

• Incruste la ID del servidor de sesión de nivel medio dentro de la cookie de ID de sesión, como han sugerido otros. De esa manera, la caja frontal que golpeas es irrelevante, se pueden agregar / eliminar sin ningún impacto.
• Si es lo suficientemente importante, tenga un mecanismo para redirigir a los clientes a un servidor de nivel medio alternativo durante una sesión, de modo que uno pueda ser retirado por mantenimiento, etc.
• Los clientes comienzan a usar un servidor de nivel medio recién comisionado cuando inician una nueva sesión

Para distribuir la carga de la base de datos de back-end

• " Convencional " Fragmento de " tiempo real " por cuenta o datos por usuario
• Replica de forma asíncrona datos relativamente estáticos o que cambian lentamente; los usuarios pueden verlo fuera de fecha (pero no la mayor parte del tiempo). Los servidores de nivel medio y los servidores web se conectan a una base de datos local en su propia ubicación