La integración estuvo acompañada de una lucha con literalmente cada milisegundo de latencia, una actualización de la infraestructura y el desarrollo de tecnologías de entrega de contenido, que tuvimos que idear nosotros mismos. Te contamos qué nos encontramos durante el trabajo, qué sucedió al final y por qué los usuarios lo necesitan.
Por qué integrar la nube con CDN en absoluto
En primer lugar, una nube pública es una capacidad escalable. Se pueden utilizar de cualquier forma: para desarrollar y probar servicios, así como para almacenar y procesar datos. En G-Core Labs lanzamos la nube el año pasado y ya logramos usarla en proyectos de alta carga. Por ejemplo, nuestro cliente desde hace mucho tiempo, Wargaming, usa esta solución para varias tareas a la vez:
- Probar nuevas funciones y servicios de diferentes proyectos;
- Preparación de prototipos de prueba con desarrolladores externos que necesitan acceso a recursos personalizados y controlados aislados;
- Funcionamiento del juego online "Calibre" en máquinas virtuales.
La nube hace frente a todo lo anterior con una explosión, pero el trabajo no termina ahí. No importa para qué se utilicen estas o aquellas capacidades, el resultado de su trabajo aún debe entregarse en el punto de destino. Independientemente de si estamos hablando de un juego en línea o de formaciones militares reales, aquí es donde surge el problema: que es extremadamente difícil entregar rápidamente datos pesados a regiones remotas con equipos militares de varias toneladas. Esta tarea se puede simplificar integrando la nube con la red de entrega de contenido. Con la ayuda de CDN, la parte transportable (datos estáticos) se puede lanzar "por aire" directamente al destino, y todo lo que queda es enviar datos dinámicos "sobredimensionados" desde la nube. Con este enfoque, puede comenzar a trabajar de manera segura incluso en otros continentes, ya que la integración permite a los competidores más rápidos entregar contenido pesado en todo el mundo.
Reducir, distribuir, acelerar: cómo CDN ayuda a la nube
Vayamos a los detalles. Sabemos de primera mano que se necesita mucho tiempo para entregar contenido pesado a regiones remotas directamente desde la nube, y puede resultar costoso aumentar constantemente la capacidad de la infraestructura de acuerdo con el aumento de carga. Afortunadamente, además de la nube pública, terminamos con nuestro propio CDN, que incluso ingresó en el Libro Guinness de los Récords, brindando una experiencia ininterrumpida de jugar World of Tanks durante los períodos pico.
Para matar dos pájaros de un tiro, necesitábamos integrarlo con la nube. Entonces podríamos ofrecer a los usuarios una solución que costaría menos que una actualización de la infraestructura y permitiría una entrega de datos más rápida a regiones remotas. Así que comenzamos la primera fase de trabajo y resolvimos los problemas clave:
1. Los servicios en la nube estaban bajo carga constante.Los usuarios de proyectos de alta carga solicitaban regularmente contenido de las nubes de nuestros clientes. Esto resultó en una carga alta y un retorno de datos largo. Se necesitaba una solución que redujera fácilmente el número de referencias a la fuente. Para hacer esto, integramos servidores de nube pública y servidores de caché CDN, y también creamos una interfaz única para administrar estos servicios. Con su ayuda, los usuarios pueden mover datos estáticos a los puntos de presencia deseados en la red. Debido a esto, las llamadas a la nube ocurren solo en las primeras solicitudes de contenido. Funciona de forma estándar: CDN toma datos de la fuente y los envía al usuario, así como al servidor de caché más cercano, desde donde se distribuye el contenido en solicitudes posteriores;
2. Los datos se transfirieron durante mucho tiempo entre la nube y la CDN.Al combinar la nube con una red de entrega de contenido, notamos que se podía reducir la latencia de entrega de datos. Para ahorrar tantos milisegundos valiosos como fuera posible, tuvimos que implementar el intercambio de tráfico entre los servidores de caché y la nube dentro de la red troncal;
3. La carga en la fuente fue desigual. Incluso después de conectar la CDN, las solicitudes restantes a la nube se distribuyeron de manera ineficiente. Arreglamos esto con balanceadores HTTP (S). Ahora, en el momento de la solicitud de contenido, determinan de qué fuente (máquina virtual o depósito de almacenamiento en la nube) se deben tomar los datos para el almacenamiento en caché;
4. El contenido pesado tardó mucho en llegar a los usuarios.Para reducir el tiempo de espera, aumentamos constantemente la capacidad y la geografía de la presencia de CDN. Ahora los usuarios ya no tienen que esperar a que el contenido les llegue al otro lado del mundo; en el momento del contacto, la red de distribución de contenido selecciona el más cercano de los 100 puntos de presencia en los cinco continentes. Como resultado, el tiempo de respuesta promedio en todo el mundo es de 30 ms.
Habiendo tratado estos problemas, ya hemos dado por finalizado el trabajo. Pero la nube con CDN tenía otros planes para nosotros.
Así se templaba el acero: modernizamos la infraestructura
En un momento, quedó claro que el efecto de todos nuestros esfuerzos no podía manifestarse por completo mientras usábamos la configuración de hardware anterior. Para que los servidores y las aplicaciones alojadas en ellos funcionen mejor y el contenido se transfiera más rápido, se requirió una actualización de la infraestructura. Las estrellas en el cielo convergieron a principios de este año: comenzamos a actualizar tan pronto como se lanzó la línea de procesadores escalables Intel Xeon de segunda generación.
Ahora, la configuración estándar del servidor se ve así:
- Los servicios en la nube se ejecutan en procesadores Intel Xeon Gold 6152, 6252 y 5220, tienen hasta 1 TB de RAM, así como SSD y HDD con triple replicación;
- Los servidores de caché CDN están equipados con Intel Xeon Platinum, RAID virtual en la CPU y SSD D3-S4610.
Como resultado de la actualización, el rendimiento ha aumentado tanto que hemos abandonado algunos de los servidores y reducido el costo de su funcionamiento. Parecía que todo lo anterior sería más que suficiente para el trabajo de cualquier proyecto. Pero un día esto no fue suficiente.
Blindaje, fragmentación y distribución geográfica: acelerar la entrega de contenido en condiciones extremas
La desgracia nunca llega sola. Esto es especialmente cierto cuando se trata de proyectos globales. Falta de infraestructura distribuida geográficamente, altas cargas debido a muchos usuarios de todo el mundo y un mar de datos heterogéneos que necesitan entregar rápidamente: uno de nuestros clientes, un gran recurso de medios, necesitaba lidiar con todas estas complejidades a la vez. Pocos detalles:
- El contenido llegó a los usuarios durante mucho tiempo y, en ocasiones, no llegó a ellos debido a grandes retrasos y problemas de red. La dificultad era que todo el gran grupo de servidores con datos estaba ubicado en un punto geográfico;
- Los usuarios de todo el mundo accedieron a la fuente de contenido, lo que provocó una mayor carga en la infraestructura y generó altos costos de mantenimiento, así como una entrega de datos lenta;
- Los usuarios necesitaban ofrecer una gran cantidad de contenido actualizado constantemente que fuera exclusivo de cada región.
Las capacidades básicas de integración de la nube con una CDN eran indispensables. Comenzamos a desarrollar soluciones adicionales.
Cómo se nos ocurrió el blindaje regional
Hemos introducido este concepto, y ahora un servicio existente, específicamente para resolver el problema de la lejanía de la fuente del contenido. Debido a que todos los servidores del cliente estaban ubicados en un punto geográfico, los datos de ellos tardaron mucho en llegar a usuarios de diferentes partes del mundo. La situación se complicó por el hecho de que era necesario entregar contenido diferente y constantemente actualizado a diferentes regiones. El almacenamiento en caché de datos simple en servidores perimetrales no solucionaría el problema; a menudo, todavía accederían a la fuente en la otra parte del mundo.
Resolvimos el problema mediante la implementación de un gran grupo de servidores de caché en puntos de intercambio de tráfico populares en diferentes continentes. Los "escudos regionales" se han convertido en una especie de capas entre la fuente y los servidores de borde en los países del usuario. Ahora todo el contenido demandado en las partes correspondientes del mundo primero recaía sobre ellos y luego se transmitía a los servidores de caché. Por lo tanto, el blindaje redujo la carga en la fuente del cliente de una vez y redujo las demoras para los usuarios finales. El cliente, a su vez, ahorraba en alojar varios pools de servidores con el mismo contenido en diferentes partes del mundo, ya que con este principio de trabajo bastaba con una fuente de datos.
¿Por qué necesitaba fragmentación de contenido?
Los blindajes regionales han resuelto el problema de la entrega de contenido a largo plazo a diferentes partes del mundo en su totalidad. Sin embargo, ahora surgió una nueva dificultad: dado que el cliente tenía una gran cantidad de datos y se actualizaba constantemente, no terminaba en la caché de los servidores de borde a los que accedían los usuarios. Esto llevó al hecho de que una gran cantidad de solicitudes de los servidores de caché se vertían constantemente en grupos regionales, cuyo número en un grupo llegó a 20-30 piezas. Para eliminar parte de esta carga de los escudos y entregar contenido a los usuarios aún más rápido, agregamos la capacidad de tomar los datos necesarios del servidor de borde más cercano en el grupo.
Ahora, los servidores de caché en las regiones de presencia comenzaron a acceder a los escudos solo cuando no había datos en todo el grupo. Además, incluso en estos casos, el contenido se solicitó inmediatamente del servidor que lo contenía; gracias a la fragmentación, los servidores de borde "sabían" de antemano dónde estaba un archivo específico y no sondearon todo el grupo de escudos regionales para esto. Este principio de funcionamiento redujo el número de solicitudes al grupo y permitió distribuir el contenido de manera eficiente en lugar de almacenar copias de los datos en cada servidor. Como resultado, los escudos tenían más contenido y, como resultado, ponían menos estrés en la fuente del cliente.
La creación de una infraestructura de este tipo no podía dejar de presentar una dificultad más. Dado el número de servidores de caché en los grupos, sería una tontería suponer que ninguno de ellos puede fallar. En tal situación, como en el caso de agregar un nuevo servidor al grupo, la caché en los grupos tuvo que redistribuirse de manera óptima. Para hacer esto, hemos implementado la organización de una caché fragmentada con un algoritmo de hash consistente en el bloque ascendente en nginx:
upstream cache_servers {
hash $cache_key consistent;
server edge1.dc1.gcorelabs.com;
server edge2.dc1.gcorelabs.com;
server edge3.dc1.gcorelabs.com;
}
La aparición de servidores no disponibles en el grupo también estuvo plagada de otro problema: otros servidores continuaron enviándoles solicitudes y esperaron una respuesta. Para deshacernos de este retraso, escribimos un algoritmo para detectar dichos servidores en el grupo. Ahora, debido al hecho de que se transfieren automáticamente al estado inactivo en el grupo ascendente, ya no accedemos a servidores inactivos y no esperamos datos de ellos.
Como resultado de estos trabajos, redujimos el costo de los servicios para el cliente, lo salvamos de los serios costos de organizar su propia infraestructura y aceleramos significativamente la entrega de datos a los usuarios, a pesar de todas las dificultades.
Quién necesita una nube con CDN
El trabajo de integración ha terminado y nuestros clientes ya están utilizando el producto. Compartimos cuál de ellos saca más provecho de esto.
Digamos de inmediato que la solución no fue útil para todos. No esperábamos nada más: para algunos, solo el almacenamiento y las máquinas virtuales son suficientes, y para otros, las redes de entrega de contenido. Por ejemplo, cuando toda la audiencia de un proyecto está en la misma región, prácticamente no hay necesidad de conectar la CDN a la nube. Para minimizar las demoras, en este caso, un servidor ubicado no lejos de los usuarios será suficiente.
La integración se revela en todo su esplendor cuando necesita dar contenido pesado de forma rápida y remota a un gran número de usuarios. Aquí hay un par de ejemplos de cómo una nube con CDN ayuda a diferentes proyectos:
- Los servicios de transmisión que son críticos para la latencia y el almacenamiento en búfer garantizan un funcionamiento estable y transmisiones de alta calidad;
- Los servicios de entretenimiento en línea entregan juegos pesados a diferentes partes del mundo más rápido y reducen la carga en los servidores, incluso en los picos de carga;
- Los proyectos de medios hacen que los anuncios se carguen más rápido y permanezcan accesibles cuando el tráfico aumenta;
- Las tiendas en línea se cargan más rápido en diferentes países, incluso durante las promociones y ventas.
Seguimos viendo exactamente cómo están usando la nube con CDN. A nosotros, como a usted, nos interesan los números: cuánto se reduce la carga en la infraestructura, cuánto más rápido reciben los usuarios el contenido en regiones específicas y cuánto ayuda la integración a ahorrar dinero. Compartiremos todo esto en casos futuros.