Netflix es el líder en el mercado de la televisión por Internet, la empresa que creó y está desarrollando activamente este segmento. Netflix es conocido no solo por su extenso catálogo de películas y series de televisión disponibles en casi todos los rincones del planeta y en cualquier dispositivo con pantalla, sino también por su infraestructura confiable y su cultura de ingeniería única.
En DevOops 2019 se presentó un claro ejemplo del enfoque de Netflix para desarrollar y soportar sistemas complejos. - Director de Desarrollo en Netflix. Graduado de la Facultad de Matemática Computacional y Matemáticas de la Universidad Estatal de Nizhny Novgorod. Lobachevsky, Sergey, uno de los primeros ingenieros de Open Connect - equipo CDN en Netflix. Creó sistemas para monitorear y analizar datos de video, lanzó un popular servicio para evaluar la velocidad de la conexión a Internet FAST.com y durante los últimos años ha estado trabajando para optimizar las solicitudes de Internet para que la aplicación Netflix funcione lo más rápido posible para los usuarios.
El informe recibió las mejores críticas de los participantes de la conferencia y hemos preparado una versión de texto para usted.
En su informe, Sergei habló en detalle.
- sobre lo que afecta el retraso de las solicitudes de Internet entre el cliente y el servidor;
- cómo reducir este retraso;
- cómo diseñar, mantener y monitorear sistemas tolerantes a errores;
- cómo lograr resultados en poco tiempo y con un riesgo mínimo para el negocio;
- cómo analizar resultados y aprender de los errores.
Las respuestas a estas preguntas no solo las necesitan quienes trabajan en grandes corporaciones.
Los principios y técnicas presentados deben ser conocidos y practicados por todos los que desarrollan y respaldan productos de Internet.
Lo siguiente es la narración desde la perspectiva del hablante.
La importancia de la velocidad de Internet
La velocidad de las solicitudes de Internet está directamente relacionada con los negocios. Consideremos la industria de las compras: Amazon en 2009 que un retraso de 100 ms resulta en una pérdida del 1% de las ventas.
Cada vez hay más dispositivos móviles, seguidos de sitios y aplicaciones móviles. Si su página tarda más de 3 segundos en cargarse, está perdiendo aproximadamente la mitad de sus usuarios. CON Google tiene en cuenta la velocidad de carga de tu página en los resultados de búsqueda: cuanto más rápida sea la página, mayor será su posición en Google.
La velocidad de conexión también es importante en las instituciones financieras donde la latencia es crítica. En 2015, Hibernia Networks un cable de 400 millones de dólares entre Nueva York y Londres para reducir la latencia entre las ciudades en 6 ms. ¡Imagínese 66 millones de dólares por 1 ms de reducción de latencia!
según , las velocidades de conexión superiores a 5 Mbit/s ya no afectan directamente a la velocidad de carga de un sitio web típico. Sin embargo, existe una relación lineal entre la latencia de la conexión y la velocidad de carga de la página:
Sin embargo, Netflix no es un producto típico. El impacto de la latencia y la velocidad en el usuario es un área activa de análisis y desarrollo. Hay carga de aplicaciones y selección de contenido que dependen de la latencia, pero la carga de elementos estáticos y la transmisión también dependen de la velocidad de conexión. Analizar y optimizar los factores clave que influyen en la experiencia del usuario es un área de desarrollo activa para varios equipos de Netflix. Uno de los objetivos es reducir la latencia de las solicitudes entre los dispositivos Netflix y la infraestructura de la nube.
En el informe nos centraremos específicamente en reducir la latencia utilizando el ejemplo de la infraestructura de Netflix. Consideremos desde un punto de vista práctico cómo abordar los procesos de diseño, desarrollo y operación de sistemas distribuidos complejos y dedicar tiempo a la innovación y los resultados, en lugar de diagnosticar problemas operativos y averías.
Dentro de Netflix
Miles de dispositivos diferentes admiten aplicaciones de Netflix. Son desarrollados por cuatro equipos diferentes, que crean versiones separadas del cliente para Android, iOS, TV y navegadores web. Y dedicamos mucho esfuerzo a mejorar y personalizar la experiencia del usuario. Para ello, ejecutamos cientos de pruebas A/B en paralelo.
La personalización está respaldada por cientos de microservicios en la nube de AWS, que brindan datos de usuario personalizados, envío de consultas, telemetría, Big Data y codificación. La visualización del tráfico se ve así:
A la izquierda está el punto de entrada y luego el tráfico se distribuye entre varios cientos de microservicios respaldados por diferentes equipos de backend.
Otro componente importante de nuestra infraestructura es Open Connect CDN, que entrega contenido estático al usuario final: vídeos, imágenes, código de cliente, etc. La CDN está ubicada en servidores personalizados (OCA - Open Connect Appliance). En su interior hay conjuntos de unidades SSD y HDD que ejecutan FreeBSD optimizado, con NGINX y un conjunto de servicios. Diseñamos y optimizamos componentes de hardware y software para que dicho servidor CDN pueda enviar la mayor cantidad de datos posible a los usuarios.
El "muro" de estos servidores en el punto de intercambio de tráfico de Internet (Internet eXchange - IX) se ve así:
Internet Exchange brinda a los proveedores de servicios de Internet y de contenido la capacidad de "conectarse" entre sí para intercambiar datos de manera más directa en Internet. Hay aproximadamente entre 70 y 80 puntos de Internet Exchange en todo el mundo donde están instalados nuestros servidores, y los instalamos y mantenemos de forma independiente:
Además, también proporcionamos servidores directamente a los proveedores de Internet, que instalan en su red, mejorando la localización del tráfico de Netflix y la calidad del streaming para los usuarios:
Un conjunto de servicios de AWS es responsable de enviar solicitudes de video de los clientes a los servidores CDN, así como de configurar los propios servidores: actualizar el contenido, el código del programa, la configuración, etc. Para este último, también construimos una red troncal que conecta servidores en puntos de intercambio de Internet con AWS. La red backbone es una red global de cables y routers de fibra óptica que podemos diseñar y configurar en función de nuestras necesidades.
En , nuestra infraestructura CDN ofrece aproximadamente ⅛ del tráfico de Internet del mundo durante las horas pico y ⅓ del tráfico en América del Norte, donde Netflix ha estado presente por más tiempo. Números impresionantes, pero para mí uno de los logros más sorprendentes es que todo el sistema CDN es desarrollado y mantenido por un equipo de menos de 150 personas.
Inicialmente, la infraestructura CDN se diseñó para entregar datos de video. Sin embargo, con el tiempo nos dimos cuenta de que también podemos usarlo para optimizar las solicitudes dinámicas de los clientes en la nube de AWS.
Acerca de la aceleración de Internet
Hoy en día, Netflix tiene 3 regiones de AWS y la latencia de las solicitudes a la nube dependerá de qué tan lejos esté el cliente de la región más cercana. Al mismo tiempo, tenemos muchos servidores CDN que se utilizan para entregar contenido estático. ¿Hay alguna forma de utilizar este marco para acelerar las consultas dinámicas? Sin embargo, desafortunadamente, es imposible almacenar en caché estas solicitudes: las API están personalizadas y cada resultado es único.
Creemos un proxy en el servidor CDN y comencemos a enviar tráfico a través de él. ¿Será más rápido?
Material
Recordemos cómo funcionan los protocolos de red. Hoy en día, la mayor parte del tráfico en Internet utiliza HTTP, que depende de los protocolos de capa inferior TCP y TLS. Para que un cliente se conecte al servidor, realiza un protocolo de enlace y, para establecer una conexión segura, el cliente necesita intercambiar mensajes con el servidor tres veces y al menos una vez más para transferir datos. Con una latencia por ida y vuelta (RTT) de 100 ms, tardaríamos 400 ms en recibir el primer bit de datos:
Si colocamos los certificados en el servidor CDN, el tiempo de intercambio entre el cliente y el servidor se puede reducir significativamente si el CDN está más cerca. Supongamos que la latencia del servidor CDN es de 30 ms. Luego tardará 220 ms en recibir el primer bit:
Pero las ventajas no terminan ahí. Una vez que se ha establecido una conexión, TCP aumenta la ventana de congestión (la cantidad de información que puede transmitir a través de esa conexión en paralelo). Si se pierde un paquete de datos, las implementaciones clásicas del protocolo TCP (como TCP New Reno) reducen la "ventana" abierta a la mitad. El crecimiento de la ventana de congestión y la velocidad de recuperación de la pérdida nuevamente dependen del retraso (RTT) en el servidor. Si esta conexión sólo llega hasta el servidor CDN, esta recuperación será más rápida. Al mismo tiempo, la pérdida de paquetes es un fenómeno estándar, especialmente en las redes inalámbricas.
El ancho de banda de Internet puede verse reducido, especialmente durante las horas pico, debido al tráfico de los usuarios, lo que puede provocar atascos. Sin embargo, en Internet no existe forma de dar prioridad a unas solicitudes sobre otras. Por ejemplo, dé prioridad a las solicitudes pequeñas y sensibles a la latencia sobre los flujos de datos "pesados" que cargan la red. Sin embargo, en nuestro caso, tener nuestra propia red troncal nos permite hacer esto en parte de la ruta de solicitud, entre la CDN y la nube, y podemos configurarla completamente. Puede asegurarse de que se prioricen los paquetes pequeños y sensibles a la latencia y que los flujos de datos grandes lleguen un poco más tarde. Cuanto más cerca esté la CDN del cliente, mayor será la eficiencia.
Los protocolos a nivel de aplicación (OSI nivel 7) también tienen un impacto en la latencia. Nuevos protocolos como HTTP/2 optimizan el rendimiento de las solicitudes paralelas. Sin embargo, tenemos clientes de Netflix con dispositivos más antiguos que no admiten los nuevos protocolos. No todos los clientes se pueden actualizar o configurar de forma óptima. Al mismo tiempo, entre el proxy CDN y la nube existe un control total y la capacidad de utilizar protocolos y configuraciones nuevos y óptimos. La parte ineficaz con protocolos antiguos sólo funcionará entre el cliente y el servidor CDN. Además, podemos realizar solicitudes multiplex en una conexión ya establecida entre la CDN y la nube, mejorando la utilización de la conexión a nivel TCP:
Medimos
A pesar de que la teoría promete mejoras, no nos apresuramos inmediatamente a poner el sistema en producción. En lugar de ello, primero debemos demostrar que la idea funcionará en la práctica. Para ello es necesario responder varias preguntas:
- velocidad: ¿un proxy será más rápido?
- Confiabilidad: ¿Se romperá más a menudo?
- Complejidad: ¿Cómo integrarse con aplicaciones?
- costo de: ¿Cuánto cuesta implementar infraestructura adicional?
Consideremos en detalle nuestro enfoque para evaluar el primer punto. El resto se trata de forma similar.
Para analizar la velocidad de las solicitudes, queremos obtener datos de todos los usuarios, sin dedicar mucho tiempo al desarrollo y sin interrumpir la producción. Hay varios enfoques para esto:
- RUM, o medición de solicitud pasiva. Medimos el tiempo de ejecución de las solicitudes actuales de los usuarios y garantizamos una cobertura total del usuario. La desventaja es que la señal no es muy estable debido a muchos factores, por ejemplo, debido a diferentes tamaños de solicitud, tiempo de procesamiento en el servidor y el cliente. Además, no se puede probar una nueva configuración sin efecto en producción.
- Pruebas de laboratorio. Servidores especiales e infraestructura que simulan clientes. Con su ayuda realizamos las pruebas necesarias. De esta manera obtenemos un control total sobre los resultados de la medición y una señal clara. Pero no existe una cobertura completa de los dispositivos y las ubicaciones de los usuarios (especialmente con un servicio mundial y soporte para miles de modelos de dispositivos).
¿Cómo se pueden combinar las ventajas de ambos métodos?
Nuestro equipo ha encontrado una solución. Escribimos un pequeño fragmento de código, una muestra, que integramos en nuestra aplicación. Las sondas nos permiten hacer pruebas de red totalmente controladas desde nuestros dispositivos. Funciona así:
- Poco después de cargar la aplicación y completar la actividad inicial, ejecutamos nuestras sondas.
- El cliente realiza una solicitud al servidor y recibe una "receta" para la prueba. La receta es una lista de URL a las que se debe realizar una solicitud HTTP. Además, la receta configura los parámetros de la solicitud: retrasos entre solicitudes, cantidad de datos solicitados, encabezados HTTP, etc. Al mismo tiempo, podemos probar varias recetas diferentes en paralelo: al solicitar una configuración, determinamos aleatoriamente qué receta emitir.
- La hora de inicio de la sonda se selecciona para no entrar en conflicto con el uso activo de los recursos de red en el cliente. Básicamente, se selecciona el momento en el que el cliente no está activo.
- Luego de recibir la receta, el cliente realiza solicitudes a cada una de las URL, en paralelo. La solicitud a cada una de las direcciones se puede repetir: la llamada. "pulsos". En el primer pulso, medimos cuánto tiempo llevó establecer una conexión y descargar datos. En el segundo pulso, medimos el tiempo que lleva cargar datos a través de una conexión ya establecida. Antes del tercero, podemos establecer un retraso y medir la velocidad de establecimiento de una reconexión, etc.
Durante la prueba medimos todos los parámetros que puede obtener el dispositivo:
- hora de solicitud de DNS;
- tiempo de configuración de la conexión TCP;
- tiempo de configuración de la conexión TLS;
- hora de recibir el primer byte de datos;
- tiempo total de carga;
- código de resultado de estado.
- Una vez que se hayan completado todos los pulsos, la muestra carga todas las mediciones para su análisis.
Los puntos clave son la mínima dependencia de la lógica del cliente, el procesamiento de datos en el servidor y la medición de solicitudes paralelas. De este modo, podemos aislar y probar la influencia de varios factores que afectan el rendimiento de las consultas, variarlos dentro de una única receta y obtener resultados de clientes reales.
Esta infraestructura ha demostrado ser útil para algo más que el análisis del rendimiento de consultas. Actualmente contamos con 14 recetas activas, más de 6000 muestras por segundo, recibiendo datos de todos los rincones de la tierra y cobertura total del dispositivo. Si Netflix comprara un servicio similar a un tercero, le costaría millones de dólares al año, con una cobertura mucho peor.
Teoría de pruebas en la práctica: prototipo
Con un sistema de este tipo, pudimos evaluar la efectividad de los servidores proxy CDN en función de la latencia de las solicitudes. Ahora necesitas:
- crear un prototipo de proxy;
- colocar el prototipo en una CDN;
- determinar cómo dirigir a los clientes a un proxy en un servidor CDN específico;
- Compare el rendimiento con las solicitudes en AWS sin un proxy.
La tarea es evaluar la eficacia de la solución propuesta lo más rápido posible. Elegimos Go para implementar el prototipo debido a la disponibilidad de buenas bibliotecas de redes. En cada servidor CDN, instalamos el prototipo de proxy como un binario estático para minimizar las dependencias y simplificar la integración. En la implementación inicial, utilizamos componentes estándar tanto como fue posible y modificaciones menores para la agrupación de conexiones HTTP/2 y la multiplexación de solicitudes.
Para equilibrar las regiones de AWS, utilizamos una base de datos DNS geográfica, la misma que se utiliza para equilibrar los clientes. Para seleccionar un servidor CDN para el cliente, utilizamos TCP Anycast para servidores en Internet Exchange (IX). En esta opción, utilizamos una dirección IP para todos los servidores CDN y el cliente será dirigido al servidor CDN con la menor cantidad de saltos de IP. En los servidores CDN instalados por proveedores de Internet (ISP), no tenemos control sobre el enrutador para configurar TCP Anycast, por lo que utilizamos , que dirige a los clientes a proveedores de Internet para la transmisión de vídeo.
Entonces, tenemos tres tipos de rutas de solicitud: a la nube a través de Internet abierto, a través de un servidor CDN en IX o a través de un servidor CDN ubicado en un proveedor de Internet. Nuestro objetivo es comprender cuál es mejor y cuál es el beneficio de un proxy, en comparación con cómo se envían las solicitudes a producción. Para ello utilizamos un sistema de muestreo de la siguiente manera:
Cada uno de los caminos se convierte en un objetivo separado y miramos el tiempo que llegamos. Para el análisis, combinamos los resultados del proxy en un grupo (seleccionamos el mejor momento entre los proxy IX e ISP) y los comparamos con el tiempo de las solicitudes a la nube sin un proxy:
Como puede ver, los resultados fueron mixtos: en la mayoría de los casos, el proxy proporciona una buena aceleración, pero también hay un número suficiente de clientes para quienes la situación empeorará significativamente.
Como resultado, hicimos varias cosas importantes:
- Evaluamos el rendimiento esperado de las solicitudes de los clientes a la nube a través de un proxy CDN.
- Recibimos datos de clientes reales, de todo tipo de dispositivos.
- Nos dimos cuenta de que la teoría no estaba 100% confirmada y que la oferta inicial con un proxy CDN no funcionaría para nosotros.
- No asumimos riesgos, no cambiamos las configuraciones de producción para los clientes.
- No se rompió nada.
Prototipo 2.0
Entonces, regrese a la mesa de dibujo y repita el proceso nuevamente.
La idea es que en lugar de utilizar un proxy 100%, determinaremos la ruta más rápida para cada cliente y enviaremos solicitudes allí, es decir, haremos lo que se llama dirección de cliente.
¿Cómo implementar esto? No podemos usar la lógica en el lado del servidor, porque... El objetivo es conectarse a este servidor. Tiene que haber alguna forma de hacer esto en el cliente. E idealmente, haga esto con una mínima cantidad de lógica compleja, para no resolver el problema de la integración con una gran cantidad de plataformas de clientes.
La respuesta es utilizar DNS. En nuestro caso, tenemos nuestra propia infraestructura DNS y podemos configurar una zona de dominio para la cual nuestros servidores serán autoritarios. Funciona así:
- El cliente realiza una solicitud al servidor DNS utilizando un host, por ejemplo api.netflix.xom.
- La solicitud llega a nuestro servidor DNS.
- El servidor DNS sabe qué ruta es la más rápida para este cliente y emite la dirección IP correspondiente.
La solución tiene una complejidad adicional: los proveedores de DNS autoritarios no ven la dirección IP del cliente y solo pueden leer la dirección IP del solucionador recursivo que utiliza el cliente.
Como resultado, nuestro solucionador autoritario debe tomar una decisión no para un cliente individual, sino para un grupo de clientes basándose en el solucionador recursivo.
Para resolverlo, usamos las mismas muestras, agregamos los resultados de las mediciones de los clientes para cada uno de los resolutores recursivos y decidimos dónde enviar este grupo de ellos: un proxy a través de IX usando TCP Anycast, a través de un proxy ISP o directamente a la nube.
Obtenemos el siguiente sistema:
El modelo de dirección de DNS resultante le permite dirigir a los clientes basándose en observaciones históricas de la velocidad de las conexiones de los clientes a la nube.
Una vez más, la pregunta es ¿con qué eficacia funcionará este enfoque? Para responder, volvemos a utilizar nuestro sistema de sonda. Por lo tanto, configuramos la configuración del presentador, donde uno de los objetivos sigue la dirección de la dirección DNS y el otro va directamente a la nube (producción actual).
Como resultado, comparamos los resultados y obtenemos una evaluación de la efectividad:
Como resultado, aprendimos varias cosas importantes:
- Evaluamos el rendimiento esperado de las solicitudes de los clientes a la nube mediante DNS Steering.
- Recibimos datos de clientes reales, de todo tipo de dispositivos.
- Se ha demostrado la eficacia de la idea propuesta.
- No asumimos riesgos, no cambiamos las configuraciones de producción para los clientes.
- No se rompió nada.
Ahora viene la parte difícil: lo lanzamos a producción.
La parte fácil ya ha terminado: hay un prototipo funcional. Ahora la parte difícil es lanzar una solución para todo el tráfico de Netflix, implementándola para 150 millones de usuarios, miles de dispositivos, cientos de microservicios y un producto e infraestructura en constante cambio. Los servidores de Netflix reciben millones de solicitudes por segundo y es fácil interrumpir el servicio con una acción descuidada. Al mismo tiempo, queremos enrutar dinámicamente el tráfico a través de miles de servidores CDN en Internet, donde algo cambia y se rompe constantemente y en el momento más inoportuno.
Y con todo ello, el equipo cuenta con 3 ingenieros responsables del desarrollo, despliegue y soporte total del sistema.
Por ello, seguiremos hablando de un sueño reparador y saludable.
¿Cómo continuar con el desarrollo y no perder todo el tiempo en soporte? Nuestro enfoque se basa en 3 principios:
- Reducimos la magnitud potencial de las averías (radio de explosión).
- Nos estamos preparando para las sorpresas: esperamos que algo se rompa, a pesar de las pruebas y la experiencia personal.
- Degradación elegante: si algo no funciona bien, debe solucionarse automáticamente, aunque no de la manera más eficiente.
Resultó que en nuestro caso, con este enfoque del problema, podemos encontrar una solución simple y efectiva y simplificar significativamente el soporte del sistema. Nos dimos cuenta de que podíamos agregar un pequeño fragmento de código al cliente y monitorear errores de solicitud de red causados por problemas de conexión. En caso de errores de red, regresamos directamente a la nube. Esta solución no requiere un esfuerzo significativo por parte de los equipos de los clientes, pero reduce en gran medida el riesgo de averías inesperadas y sorpresas para nosotros.
Por supuesto, a pesar de las desventajas, seguimos una disciplina clara durante el desarrollo:
- Prueba de muestra.
- Pruebas A/B o Canarias.
- Despliegue progresivo.
Con ejemplos se ha descrito el método: primero se prueban los cambios utilizando una receta personalizada.
Para las pruebas canary, necesitamos obtener pares comparables de servidores en los que podamos comparar cómo funciona el sistema antes y después de los cambios. Para hacer esto, de nuestros muchos sitios CDN, seleccionamos pares de servidores que reciben tráfico comparable:
Luego instalamos la compilación con los cambios en el servidor Canary. Para evaluar los resultados, ejecutamos un sistema que compara aproximadamente entre 100 y 150 métricas con una muestra de servidores de Control:
Si las pruebas de Canary tienen éxito, las lanzaremos gradualmente, en oleadas. No actualizamos los servidores en cada sitio al mismo tiempo: perder un sitio completo debido a problemas tiene un impacto más significativo en el servicio para los usuarios que perder la misma cantidad de servidores en diferentes ubicaciones.
En general, la eficacia y seguridad de este enfoque depende de la cantidad y calidad de las métricas recopiladas. Para nuestro sistema de aceleración de consultas, recopilamos métricas de todos los componentes posibles:
- de los clientes: número de sesiones y solicitudes, tasas de respaldo;
- proxy: estadísticas sobre el número y el tiempo de las solicitudes;
- DNS: número y resultados de las solicitudes;
- Borde de la nube: número y tiempo para procesar solicitudes en la nube.
Todo esto se recopila en un único canal y, según las necesidades, decidimos qué métricas enviar a análisis en tiempo real y cuáles a Elasticsearch o Big Data para diagnósticos más detallados.
monitoreamos
En nuestro caso, estamos realizando cambios en la ruta crítica de solicitudes entre el cliente y el servidor. Al mismo tiempo, la cantidad de componentes diferentes en el cliente, en el servidor y en Internet es enorme. Los cambios en el cliente y el servidor ocurren constantemente, durante el trabajo de docenas de equipos y cambios naturales en el ecosistema. Estamos en el medio: al diagnosticar problemas, hay muchas posibilidades de que participemos. Por lo tanto, debemos comprender claramente cómo definir, recopilar y analizar métricas para aislar rápidamente los problemas.
Lo ideal es acceso completo a todo tipo de métricas y filtros en tiempo real. Pero hay muchas métricas, por lo que surge la cuestión del costo. En nuestro caso, separamos métricas y herramientas de desarrollo de la siguiente manera:
Para detectar y clasificar problemas utilizamos nuestro propio sistema de código abierto en tiempo real. и - para visualización. Almacena métricas agregadas en la memoria, es confiable y se integra con el sistema de alertas. Para localización y diagnóstico, tenemos acceso a registros de Elasticsearch y Kibana. Para el análisis y modelado estadístico, utilizamos big data y visualización en Tableau.
Parece que es muy difícil trabajar con este enfoque. Sin embargo, al organizar las métricas y las herramientas de forma jerárquica, podemos analizar rápidamente un problema, determinar el tipo de problema y luego profundizar en métricas detalladas. En general, dedicamos entre 1 y 2 minutos a identificar el origen de la avería. Después de eso, trabajamos con un equipo específico en el diagnóstico, desde decenas de minutos hasta varias horas.
Incluso si el diagnóstico se realiza rápidamente, no queremos que esto suceda con frecuencia. Lo ideal es que solo recibamos una alerta crítica cuando haya un impacto significativo en el servicio. Para nuestro sistema de aceleración de consultas, tenemos solo 2 alertas que notificarán:
- Porcentaje de reserva del cliente: evaluación del comportamiento del cliente;
- porcentaje de errores de sonda: datos de estabilidad de los componentes de la red.
Estas alertas críticas monitorean si el sistema está funcionando para la mayoría de los usuarios. Analizamos cuántos clientes utilizaron el respaldo si no podían obtener la aceleración de la solicitud. Tenemos un promedio de menos de 1 alerta crítica por semana, a pesar de que se están produciendo muchos cambios en el sistema. ¿Por qué esto es suficiente para nosotros?
- Hay un respaldo del cliente si nuestro proxy no funciona.
- Hay un sistema de dirección automático que responde a los problemas.
Más detalles sobre este último. Nuestro sistema de prueba y el sistema para determinar automáticamente la ruta óptima para las solicitudes del cliente a la nube nos permiten hacer frente automáticamente a algunos problemas.
Volvamos a nuestra configuración de muestra y a 3 categorías de ruta. Además del tiempo de carga, podemos fijarnos en el hecho de la entrega en sí. Si no fue posible cargar los datos, al observar los resultados a lo largo de diferentes rutas podemos determinar dónde y qué se rompió, y si podemos solucionarlo automáticamente cambiando la ruta de la solicitud.
Ejemplos:
Este proceso se puede automatizar. Incluirlo en el sistema de dirección. Y enséñele a responder a problemas de rendimiento y confiabilidad. Si algo empieza a romperse, reacciona si hay una mejor opción. Al mismo tiempo, una reacción inmediata no es crítica, gracias al respaldo de los clientes.
Por tanto, los principios de soporte del sistema se pueden formular de la siguiente manera:
- reducir la magnitud de las averías;
- recopilar métricas;
- Reparamos automáticamente las averías si podemos;
- si no puede, te lo notificamos;
- Estamos trabajando en paneles y conjuntos de herramientas de clasificación para una respuesta rápida.
Lecciones aprendidas
No lleva mucho tiempo escribir un prototipo. En nuestro caso estuvo listo al cabo de 4 meses. Con él recibimos nuevas métricas y 10 meses después del inicio del desarrollo recibimos el primer tráfico de producción. Entonces comenzó el trabajo tedioso y muy difícil: producir y escalar gradualmente el sistema, migrar el tráfico principal y aprender de los errores. Sin embargo, este proceso eficaz no será lineal: a pesar de todos los esfuerzos, no todo se puede predecir. Es mucho más eficaz iterar y responder rápidamente a nuevos datos.
Según nuestra experiencia, podemos recomendar lo siguiente:
- No confíes en tu intuición.
Nuestra intuición nos fallaba constantemente, a pesar de la vasta experiencia de los miembros de nuestro equipo. Por ejemplo, predijimos incorrectamente la aceleración esperada al usar un proxy CDN o el comportamiento de TCP Anycast.
- Obtener datos de producción.
Es importante tener acceso al menos a una pequeña cantidad de datos de producción lo más rápido posible. Es casi imposible obtener el número de casos, configuraciones y entornos únicos en condiciones de laboratorio. El acceso rápido a los resultados le permitirá conocer rápidamente problemas potenciales y tenerlos en cuenta en la arquitectura del sistema.
- No siga los consejos y resultados de otras personas: recopile sus propios datos.
Siga los principios para recopilar y analizar datos, pero no acepte ciegamente los resultados y declaraciones de otras personas. Sólo usted puede saber exactamente qué funciona para sus usuarios. Sus sistemas y sus clientes pueden ser significativamente diferentes de los de otras empresas. Afortunadamente, ahora hay herramientas de análisis disponibles y fáciles de usar. Es posible que los resultados que obtenga no sean los que afirman Netflix, Facebook, Akamai y otras empresas. En nuestro caso, el rendimiento de TLS, HTTP2 o las estadísticas sobre solicitudes de DNS difiere de los resultados de Facebook, Uber, Akamai, porque tenemos diferentes dispositivos, clientes y flujos de datos.
- No sigas las tendencias de la moda innecesariamente y evalúa la efectividad.
Empiece de forma sencilla. Es mejor crear un sistema que funcione de forma sencilla en poco tiempo que dedicar una gran cantidad de tiempo a desarrollar componentes que no se necesitan. Resuelva tareas y problemas importantes en función de sus mediciones y resultados.
- Prepárese para nuevas aplicaciones.
Así como es difícil predecir todos los problemas, también lo es predecir los beneficios y aplicaciones de antemano. Siga el ejemplo de las startups: su capacidad para adaptarse a las condiciones de los clientes. En tu caso, es posible que descubras nuevos problemas y sus soluciones. En nuestro proyecto, nos fijamos el objetivo de reducir la latencia de las solicitudes. Sin embargo, durante el análisis y las discusiones, nos dimos cuenta de que también podemos utilizar servidores proxy:
- equilibrar el tráfico entre las regiones de AWS y reducir los costos;
- modelar la estabilidad de CDN;
- configurar DNS;
- para configurar TLS/TCP.
Conclusión
En el informe, describí cómo Netflix resuelve el problema de acelerar las solicitudes de Internet entre los clientes y la nube. Cómo recopilamos datos utilizando un sistema de muestreo de clientes y utilizamos los datos históricos recopilados para enrutar las solicitudes de producción de los clientes a través de la ruta más rápida de Internet. Cómo utilizamos los principios de los protocolos de red, nuestra infraestructura CDN, red troncal y servidores DNS para lograr esta tarea.
Sin embargo, nuestra solución es sólo un ejemplo de cómo en Netflix implementamos dicho sistema. Lo que funcionó para nosotros. La parte aplicada de mi informe para usted son los principios de desarrollo y apoyo que seguimos y logramos buenos resultados.
Es posible que nuestra solución al problema no le convenga. Sin embargo, la teoría y los principios de diseño se mantienen, incluso si no tienes tu propia infraestructura CDN o si difiere significativamente de la nuestra.
La importancia de la velocidad de las solicitudes comerciales también sigue siendo importante. E incluso para un servicio simple es necesario elegir: entre proveedores de nube, ubicación del servidor, proveedores de CDN y DNS. Su elección influirá en la eficacia de las consultas en Internet para sus clientes. Y es importante que usted mida y comprenda esta influencia.
Comience con soluciones simples, preocúpese por cómo cambia el producto. Aprenda sobre la marcha y mejore el sistema en función de los datos de sus clientes, su infraestructura y su negocio. Piense en la posibilidad de que se produzcan averías inesperadas durante el proceso de diseño. Y luego podrá acelerar su proceso de desarrollo, mejorar la eficiencia de la solución, evitar cargas de soporte innecesarias y dormir tranquilo.
este año en formato en línea. ¡Puedes hacerle preguntas a uno de los padres de DevOps, el propio John Willis!
Fuente: habr.com