{"id":84876,"date":"2020-06-11T13:43:18","date_gmt":"2020-06-11T11:43:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno"},"modified":"2020-06-11T13:43:18","modified_gmt":"2020-06-11T11:43:18","slug":"uskoryaem-internet-zaprosy-i-spim-spokojno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","title":{"rendered":"Aceleramos las solicitudes de internet y dormimos tranquilos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/07e2e32d406b8b5d6d6cb3f627a31c3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNetflix es el l\u00edder del mercado de televisi\u00f3n por internet, una empresa que ha creado y desarrollado activamente este segmento. Netflix es conocido no solo por su extenso cat\u00e1logo de pel\u00edculas y series, accesibles desde casi cualquier rinc\u00f3n del planeta y cualquier dispositivo con pantalla, sino tambi\u00e9n por su infraestructura s\u00f3lida y su cultura ingenieril \u00fanica. <\/p>\n<p>Un ejemplo claro del enfoque de Netflix en el desarrollo y mantenimiento de sistemas complejos fue presentado en DevOops 2019 <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Sergu\u00e9i Fedorov<\/a><\/noindex> \u2014 director de desarrollo en Netflix. Graduado de la Facultad de Matem\u00e1ticas y Ciencias de la Computaci\u00f3n de la Universidad Estatal Nizhni N\u00f3vgorod, Sergu\u00e9i es uno de los primeros ingenieros en Open Connect, el equipo de CDN de Netflix. Construy\u00f3 sistemas de monitoreo y an\u00e1lisis de datos de video, lanz\u00f3 el popular servicio de evaluaci\u00f3n de la velocidad de conexi\u00f3n a Internet FAST.com y en los \u00faltimos a\u00f1os ha trabajado en la optimizaci\u00f3n de las solicitudes de Internet para que la aplicaci\u00f3n de Netflix funcione lo m\u00e1s r\u00e1pido posible para los usuarios.<\/p>\n<p>La charla recibi\u00f3 las mejores cr\u00edticas de los participantes de la conferencia, y hemos preparado para ustedes una versi\u00f3n escrita.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"n7Te9WIz1ho\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/n7Te9WIz1ho\/hqdefault.jpg\" alt=\"Reproducir video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>En la presentaci\u00f3n, Sergu\u00e9i habl\u00f3 en detalle<\/h2>\n<p><\/p>\n<ul>\n<li>sobre lo que afecta la latencia de las solicitudes de internet entre el cliente y el servidor;<\/li>\n<li>c\u00f3mo reducir dicha latencia;<\/li>\n<li>c\u00f3mo dise\u00f1ar, mantener y monitorear sistemas resilientes;<\/li>\n<li>c\u00f3mo lograr resultados en plazos ajustados y con el m\u00ednimo riesgo para el negocio;<\/li>\n<li>c\u00f3mo analizar los resultados y aprender de los errores.<\/li>\n<\/ul>\n<p>\nLas respuestas a estas preguntas son necesarias no solo para quienes trabajan en grandes corporaciones. <\/p>\n<p>Los principios y t\u00e9cnicas presentados deben ser conocidos y practicados por cualquier persona que desarrolle y mantenga productos de internet.<\/p>\n<p><b>A continuaci\u00f3n, un relato desde la perspectiva del ponente.<\/b><\/p>\n<h2>La importancia de la velocidad de internet<\/h2>\n<p>\nLa velocidad de las solicitudes de internet est\u00e1 directamente relacionada con el negocio. Consideremos el \u00e1mbito de las compras: la empresa Amazon en 2009 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">declar\u00f3<\/a><\/noindex>, que un retraso de 100 ms provoca una p\u00e9rdida del 1% en ventas.<\/p>\n<p>Cada vez hay m\u00e1s dispositivos m\u00f3viles, seguidos de sitios y aplicaciones m\u00f3viles. Si tu p\u00e1gina tarda m\u00e1s de 3 segundos en cargar, est\u00e1s perdiendo alrededor de la mitad de los usuarios. Desde <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">julio de 2018,<\/a><\/noindex> Google tiene en cuenta la velocidad de carga de tu p\u00e1gina en los resultados de b\u00fasqueda: cuanto m\u00e1s r\u00e1pida sea la p\u00e1gina, mejor ser\u00e1 su posici\u00f3n en Google.<\/p>\n<p>La velocidad de conexi\u00f3n tambi\u00e9n es importante en las organizaciones financieras, donde el retraso es cr\u00edtico. En 2015, la empresa Hibernia Networks <noindex><a rel=\"nofollow\" href=\"https:\/\/www.submarinenetworks.com\/en\/systems\/trans-atlantic\/project-express\/hibernia-express-connects-new-york-to-london-in-under-58-95ms\">finaliz\u00f3<\/a><\/noindex> la instalaci\u00f3n de un cable entre Nueva York y Londres con un costo de 400 millones de d\u00f3lares para reducir la latencia entre las ciudades en 6 ms. \u00a1Imag\u00ednate, 66 millones de d\u00f3lares por cada 1 ms de reducci\u00f3n de latencia!<\/p>\n<p>Seg\u00fan <noindex><a rel=\"nofollow\" href=\"https:\/\/hpbn.co\/primer-on-web-performance\/\">un estudio<\/a><\/noindex>, la velocidad de conexi\u00f3n superior a 5 Mbit\/s deja de influir directamente en la velocidad de carga de un sitio web t\u00edpico. Sin embargo, existe una relaci\u00f3n lineal entre la latencia de conexi\u00f3n y la velocidad de carga de la p\u00e1gina:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/340ca1f2c5bdd6ca95a5caf02f67e3fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSin embargo, Netflix no es un producto t\u00edpico. El impacto de la latencia y la velocidad en el usuario es un \u00e1rea activa de an\u00e1lisis y desarrollo. Hay cargas de aplicaci\u00f3n y selecci\u00f3n de contenido que dependen de la latencia, pero la carga de elementos est\u00e1ticos y el streaming tambi\u00e9n dependen de la velocidad de conexi\u00f3n. El an\u00e1lisis y la optimizaci\u00f3n de los factores clave que afectan la calidad del servicio para el usuario es un \u00e1rea activa de desarrollo de varios equipos en Netflix. Una de las tareas es reducir la latencia de las solicitudes entre los dispositivos de Netflix y la infraestructura en la nube.<\/p>\n<p>En este informe, nos centraremos precisamente en la reducci\u00f3n de la latencia utilizando la infraestructura de Netflix como ejemplo. Consideraremos desde un punto de vista pr\u00e1ctico c\u00f3mo abordar los procesos de dise\u00f1o, desarrollo y operaci\u00f3n de sistemas distribuidos complejos, y dedicar tiempo a la innovaci\u00f3n y a los resultados, no al diagn\u00f3stico de problemas operativos y fallos.<\/p>\n<h2>Dentro de Netflix<\/h2>\n<p>\nMiles de dispositivos diferentes soportan las aplicaciones de Netflix. Su desarrollo est\u00e1 a cargo de cuatro equipos distintos, que crean versiones separadas del cliente para Android, iOS, TV y navegadores web. Y dedicamos muchos recursos a mejorar y personalizar la interfaz de usuario. Para ello, llevamos a cabo cientos de pruebas A\/B de manera paralela.<\/p>\n<p>La personalizaci\u00f3n se mantiene gracias a cientos de microservicios en la nube de AWS que proporcionan datos personalizados para el usuario, gesti\u00f3n de solicitudes, telemetr\u00eda, Big Data y codificaci\u00f3n. La visualizaci\u00f3n del tr\u00e1fico es la siguiente:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Enlace al video con demostraci\u00f3n (6:04-6:23)<\/a><\/noindex><\/p>\n<p>A la izquierda se encuentra el punto de entrada, y luego el tr\u00e1fico se distribuye entre varios cientos de microservicios, que son soportados por diferentes equipos de backend.<\/p>\n<p>Otro componente importante de nuestra infraestructura es Open Connect CDN, que entrega contenido est\u00e1tico al usuario final, como videos, im\u00e1genes y c\u00f3digo para clientes, entre otros. El CDN est\u00e1 ubicado en servidores personalizados (OCA \u2014 Open Connect Appliance). Dentro de estos, hay arreglos de discos SSD y HDD gestionados por un FreeBSD optimizado, con NGINX y un conjunto de servicios. Dise\u00f1amos y optimizamos los componentes de hardware y software para que este servidor CDN pueda enviar la mayor cantidad de datos posible a los usuarios. <\/p>\n<p>La 'pared' de estos servidores en el punto de intercambio de tr\u00e1fico de Internet (Internet eXchange \u2014 IX) se ve as\u00ed:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/8155601c344acb1eb05b925193af8f9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl Internet Exchange permite a los proveedores de Internet y a los proveedores de contenido 'conectarse' entre s\u00ed para un intercambio m\u00e1s directo de datos en Internet. En todo el mundo, hay aproximadamente 70-80 puntos de Internet Exchange donde se encuentran nuestros servidores, y nos encargamos por nuestra cuenta de su instalaci\u00f3n y mantenimiento:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/77a2465314e47c0b2c90dbf7a2fb5e6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAdem\u00e1s, tambi\u00e9n proporcionamos servidores directamente a los proveedores de Internet, que los instalan en su red, mejorando la localizaci\u00f3n del tr\u00e1fico de Netflix y la calidad de transmisi\u00f3n para los usuarios:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/63e077d2649bfafea5c7af43a0faaf85.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl conjunto de servicios de AWS es responsable de la gesti\u00f3n de las solicitudes de video de los clientes a los servidores CDN, as\u00ed como de la configuraci\u00f3n de los propios servidores \u2014 actualizaci\u00f3n de contenido, c\u00f3digo de software, configuraciones, etc. Para esto, tambi\u00e9n hemos construido una red backbone que conecta los servidores en los puntos de Internet Exchange con AWS. La red backbone consiste en una red global de cables de fibra \u00f3ptica y enrutadores que podemos dise\u00f1ar y configurar seg\u00fan nuestras necesidades.<\/p>\n<p>Por <noindex><a rel=\"nofollow\" href=\"https:\/\/www.sandvine.com\/hubfs\/Sandvine_Redesign_2019\/Downloads\/Internet%20Phenomena\/Internet%20Phenomena%20Report%20Q32019%2020190910.pdf\">evaluaciones de Sandvine<\/a><\/noindex>, nuestra infraestructura CDN entrega en horas pico aproximadamente \u215b parte del tr\u00e1fico de Internet mundial y \u2153 del tr\u00e1fico en Am\u00e9rica del Norte, donde Netflix ha estado presente durante m\u00e1s tiempo. Son cifras impresionantes, pero para m\u00ed, uno de los logros m\u00e1s sorprendentes es que todo el sistema CDN es desarrollado y mantenido por un equipo de menos de 150 personas.<\/p>\n<p>Inicialmente, la infraestructura CDN fue dise\u00f1ada para entregar datos de video. Sin embargo, con el tiempo, nos dimos cuenta de que tambi\u00e9n pod\u00edamos utilizarla para optimizar solicitudes din\u00e1micas de clientes en la nube de AWS.<\/p>\n<h2>Sobre la aceleraci\u00f3n de Internet<\/h2>\n<p>\nHoy Netflix tiene 3 regiones de AWS, y la latencia de las solicitudes en la nube depender\u00e1 de la distancia del cliente al \u00e1rea regional m\u00e1s cercana. Adem\u00e1s, contamos con numerosos servidores CDN que se utilizan para entregar contenido est\u00e1tico. \u00bfHay alguna manera de usar esta infraestructura para acelerar las solicitudes din\u00e1micas? Lamentablemente, no se pueden almacenar en cach\u00e9 estas solicitudes, ya que las API est\u00e1n personalizadas y cada resultado es \u00fanico.<\/p>\n<p>Hagamos un proxy en el servidor CDN y empecemos a dirigir el tr\u00e1fico a trav\u00e9s de \u00e9l. \u00bfSer\u00e1 m\u00e1s r\u00e1pido?<\/p>\n<h2>Material t\u00e9cnico<\/h2>\n<p>\nRecordemos c\u00f3mo funcionan los protocolos de red. Hoy en d\u00eda, la mayor parte del tr\u00e1fico en Internet utiliza HTTPs, que depende de los protocolos de nivel inferior TCP y TLS. Para que un cliente se conecte al servidor, realiza un handshake, y para establecer una conexi\u00f3n segura, el cliente debe intercambiar mensajes con el servidor tres veces y al menos una vez m\u00e1s para transmitir datos. Con una latencia en una interacci\u00f3n (RTT) de 100 ms, necesitaremos 400 ms para recibir el primer bit de datos:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/ab12024f5a9940ca470f27821ca3c631.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi ubicamos los certificados en el servidor CDN, podemos reducir dr\u00e1sticamente el tiempo de 'handshake' entre el cliente y el servidor, si el CDN est\u00e1 m\u00e1s cerca. Supongamos que la latencia al servidor CDN es de 30 ms. Entonces, para recibir el primer bit se requerir\u00e1n solo 220 ms:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/d63134bb51592aaa6a5e0c86f1a070e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPero las ventajas no terminan aqu\u00ed. Una vez que la conexi\u00f3n ya est\u00e1 establecida, TCP aumenta la ventana de congesti\u00f3n (la cantidad de informaci\u00f3n que puede enviar a trav\u00e9s de esta conexi\u00f3n en paralelo). Si se pierde un paquete de datos, las implementaciones cl\u00e1sicas del protocolo TCP (como TCP New Reno) reducen la 'ventana' abierta a la mitad. El crecimiento de la ventana de congesti\u00f3n y la velocidad de su recuperaci\u00f3n de p\u00e9rdidas dependen nuevamente de la latencia (RTT) al servidor. Si esta conexi\u00f3n va solo hasta el servidor CDN, esta recuperaci\u00f3n ser\u00e1 m\u00e1s r\u00e1pida. Adem\u00e1s, la p\u00e9rdida de paquetes es un fen\u00f3meno est\u00e1ndar, especialmente en redes inal\u00e1mbricas.<\/p>\n<p>La capacidad de Internet puede disminuir, especialmente en horas pico debido al tr\u00e1fico de usuarios, lo que puede provocar 'congestiones'. Sin embargo, no hay forma de priorizar unas solicitudes sobre otras en la red. Por ejemplo, dar prioridad a solicitudes peque\u00f1as y sensibles a la latencia sobre flujos de datos 'pesados' que sobrecargan la red. No obstante, en nuestro caso, contar con una red backbone propia permite hacerlo en parte del recorrido de la solicitud, entre el CDN y la nube, y podemos configurarla completamente. Se puede ajustar para priorizar paquetes peque\u00f1os y dependientes de la latencia, mientras que los flujos de datos grandes se procesan un poco m\u00e1s tarde. Cuanto m\u00e1s cerca est\u00e9 el CDN del cliente, mayor ser\u00e1 la eficiencia.<\/p>\n<p>Adem\u00e1s, los protocolos de nivel de aplicaci\u00f3n (Nivel OSI 7) tambi\u00e9n influyen en la latencia. Nuevos protocolos como HTTP\/2 permiten optimizar el rendimiento de solicitudes paralelas. Sin embargo, tenemos clientes de Netflix con dispositivos antiguos que no soportan nuevos protocolos. No todos los clientes se pueden actualizar o configurar de manera \u00f3ptima. Al mismo tiempo, entre el proxy CDN y la nube, tenemos control total y la capacidad de utilizar nuevos protocolos y configuraciones \u00f3ptimas. La parte ineficiente con protocolos antiguos solo actuar\u00e1 entre el cliente y el servidor CDN. Adem\u00e1s, podemos hacer multiplexi\u00f3n de solicitudes en una conexi\u00f3n ya establecida entre el CDN y la nube, mejorando la utilizaci\u00f3n de la conexi\u00f3n a nivel TCP.<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/a05b49680734670dcfce9111f3ba1919.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Medimos<\/h2>\n<p>\nA pesar de que la teor\u00eda promete mejoras, no nos apresuramos a implementar el sistema en producci\u00f3n de inmediato. En su lugar, primero debemos demostrar que la idea funcionar\u00e1 en la pr\u00e1ctica. Para ello, necesitamos responder a algunas preguntas:<\/p>\n<ul>\n<li><b>Velocidad<\/b>: \u00bfser\u00e1 el proxy m\u00e1s r\u00e1pido?<\/li>\n<li><b>Fiabilidad<\/b>: \u00bfse romper\u00e1 con m\u00e1s frecuencia?<\/li>\n<li><b>Complejidad<\/b>: \u00bfc\u00f3mo integrar con las aplicaciones?<\/li>\n<li><b>Costo<\/b>: \u00bfcu\u00e1nto costar\u00e1 desplegar infraestructura adicional?<\/li>\n<\/ul>\n<p>\nAnalicemos detenidamente nuestro enfoque para evaluar el primer punto. Los dem\u00e1s se abordan de manera similar.<\/p>\n<p>Para analizar la velocidad de las solicitudes, queremos obtener datos para todos los usuarios, sin gastar mucho tiempo en el desarrollo y sin romper la producci\u00f3n. Existen varios enfoques para esto:<\/p>\n<ol>\n<li>RUM, o medici\u00f3n pasiva de solicitudes. Medimos el tiempo de ejecuci\u00f3n de las solicitudes actuales de los usuarios y garantizamos una cobertura completa de los mismos. La desventaja es que la se\u00f1al no es muy estable debido a m\u00faltiples factores, como los diferentes tama\u00f1os de las solicitudes, el tiempo de procesamiento en el servidor y en el cliente. Adem\u00e1s, no se puede probar una nueva configuraci\u00f3n sin afectar la producci\u00f3n.<\/li>\n<li>Pruebas de laboratorio. Servidores e infraestructura especiales que simulan clientes. Con ellos realizamos las pruebas necesarias. As\u00ed obtenemos un control total sobre los resultados de las mediciones y una se\u00f1al clara. Sin embargo, no hay cobertura completa de dispositivos y ubicaciones de usuarios (especialmente con un servicio global que admite miles de modelos de dispositivos).<\/li>\n<\/ol>\n<p>\n\u00bfC\u00f3mo se pueden combinar las ventajas de ambos m\u00e9todos?<\/p>\n<p>Nuestro equipo encontr\u00f3 una soluci\u00f3n. Hemos escrito un peque\u00f1o fragmento de c\u00f3digo \u2014una prueba\u2014 que se integr\u00f3 en nuestra aplicaci\u00f3n. Las pruebas nos permiten realizar pruebas de red completamente controladas desde nuestros dispositivos. Funciona de la siguiente manera: <\/p>\n<ol>\n<li>Poco despu\u00e9s de cargar la aplicaci\u00f3n y completar la actividad inicial, lanzamos nuestras pruebas. <\/li>\n<li>El cliente solicita al servidor y recibe una \u00abreceta\u00bb de prueba. La receta es una lista de URL a las que se debe hacer una solicitud HTTP(s). Adem\u00e1s, la receta configura los par\u00e1metros de las solicitudes: retrasos entre solicitudes, volumen de datos solicitados, encabezados HTTP(s), etc. Al mismo tiempo, podemos probar varios diferentes recetas en paralelo: al solicitar la configuraci\u00f3n, se determina aleatoriamente qu\u00e9 receta se debe entregar. <\/li>\n<li>El momento de inicio de la prueba se elige de manera que no interfiera con el uso activo de los recursos de red por parte del cliente. B\u00e1sicamente, se elige un momento en que el cliente no est\u00e9 activo.<\/li>\n<li>Despu\u00e9s de recibir la receta, el cliente realiza solicitudes a cada una de las URL, en paralelo. La solicitud a cada direcci\u00f3n puede repetirse \u2014los llamados \u00abpulsos\u00bb\u2014. En el primer pulso medimos cu\u00e1nto tiempo se tard\u00f3 en establecer la conexi\u00f3n y descargar los datos. En el segundo pulso medimos el tiempo de carga de los datos a trav\u00e9s de la conexi\u00f3n ya establecida. Antes del tercer pulso, podemos introducir un retraso y medir la velocidad de re-conexi\u00f3n, etc.\n<p>Durante la prueba, medimos todos los par\u00e1metros que puede obtener el dispositivo:<\/p>\n<ul>\n<li>el tiempo de la solicitud DNS;<\/li>\n<li>el tiempo para establecer la conexi\u00f3n TCP;<\/li>\n<li>el tiempo para establecer la conexi\u00f3n TLS;<\/li>\n<li>el tiempo para recibir el primer byte de datos;<\/li>\n<li>el tiempo total de carga;<\/li>\n<li>el c\u00f3digo de estado del resultado.<\/li>\n<\/ul>\n<\/li>\n<li> Al finalizar todos los pulsos, la muestra carga los resultados de todas las mediciones para el an\u00e1lisis.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/fff11d487b7c7725707cdeeca0734296.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLos puntos clave son la m\u00ednima dependencia de la l\u00f3gica en el cliente, el procesamiento de datos en el servidor y la medici\u00f3n de solicitudes paralelas. De esta manera, tenemos la capacidad de aislar y probar el impacto de diversos factores que afectan el rendimiento de las solicitudes, vari\u00e1ndolos dentro de una misma receta, y obteniendo resultados de clientes reales.<\/p>\n<p>Esta infraestructura ha demostrado ser \u00fatil no solo para el an\u00e1lisis del rendimiento de las solicitudes. Actualmente tenemos 14 recetas activas, m\u00e1s de 6000 muestras por segundo, obteniendo datos de todos los rincones del mundo y con una cobertura completa de dispositivos. Si Netflix comprara un servicio similar a empresas externas, costar\u00eda millones de d\u00f3lares al a\u00f1o, con una cobertura mucho peor.<\/p>\n<h2>Verificamos la teor\u00eda en la pr\u00e1ctica: prototipo<\/h2>\n<p>\nCon este sistema, hemos podido evaluar la eficiencia del proxy CDN en la latencia de las solicitudes. Ahora necesitamos:<\/p>\n<ul>\n<li>crear un prototipo de proxy;<\/li>\n<li>desplegar el prototipo en el CDN;<\/li>\n<li>determinar c\u00f3mo dirigir a los clientes al proxy en un servidor CDN espec\u00edfico;<\/li>\n<li>comparar el rendimiento con las solicitudes en AWS sin proxy.<\/li>\n<\/ul>\n<p>\nLa tarea es evaluar lo m\u00e1s r\u00e1pido posible la eficacia de la soluci\u00f3n propuesta. Para implementar el prototipo elegimos Go, gracias a la disponibilidad de excelentes bibliotecas de red. En cada servidor CDN instalamos el prototipo del proxy como un binario est\u00e1tico, para minimizar las dependencias y simplificar la integraci\u00f3n. En la implementaci\u00f3n inicial, utilizamos al m\u00e1ximo los componentes est\u00e1ndar y peque\u00f1as modificaciones para el agrupamiento de conexiones HTTP\/2 y multiplexaci\u00f3n de solicitudes.<\/p>\n<p>Para equilibrar entre regiones de AWS, utilizamos una base de datos geogr\u00e1fica DNS, la misma que se usa para el balanceo de clientes. Para seleccionar el servidor CDN para el cliente, usamos TCP Anycast para los servidores en Internet Exchange (IX). En este caso, utilizamos una direcci\u00f3n IP para todos los servidores CDN, dirigiendo al cliente al servidor CDN con el menor n\u00famero de saltos IP. En los servidores CDN situados en los proveedores de internet (ISP), no tenemos control sobre el enrutador para configurar TCP Anycast, por lo que empleamos <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">la misma l\u00f3gica<\/a><\/noindex>, por la cual los clientes son dirigidos a los proveedores de internet para la transmisi\u00f3n de video.<\/p>\n<p>As\u00ed que tenemos tres tipos de rutas para la solicitud: a la nube a trav\u00e9s de Internet abierto, a trav\u00e9s de un servidor CDN en IX o a trav\u00e9s de un servidor CDN ubicado en el proveedor de internet. Nuestro objetivo es entender qu\u00e9 ruta es mejor y qu\u00e9 beneficios trae el proxy, en comparaci\u00f3n con c\u00f3mo se dirigen las solicitudes en producci\u00f3n. Para ello, usamos un sistema de pruebas de la siguiente manera:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/51b64d5be0aaf0f141484ee0fd373396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCada una de las rutas se convierte en un objetivo separado, y observamos el tiempo que hemos obtenido. Para el an\u00e1lisis, combinamos los resultados del proxy en un solo grupo (seleccionamos el mejor tiempo entre el proxy IX y ISP) y comparamos con el tiempo de las solicitudes a la nube sin proxy:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/ec01690f6a312e61649282b0e6208778.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo se puede ver, los resultados son ambiguos: en la mayor\u00eda de los casos, el proxy proporciona una buena aceleraci\u00f3n, pero tambi\u00e9n hay una cantidad suficiente de clientes para los cuales la situaci\u00f3n empeorar\u00e1 significativamente. <\/p>\n<p>En resumen, hicimos varias cosas importantes:<\/p>\n<ol>\n<li>Evaluamos el rendimiento esperado de las solicitudes de los clientes a la nube a trav\u00e9s del proxy CDN.<\/li>\n<li>Recopilamos datos de clientes reales, de todos los tipos de dispositivos.<\/li>\n<li>Entendimos que la teor\u00eda no se confirm\u00f3 al 100% y que la propuesta inicial de proxy CDN no funcionar\u00e1 para nosotros.<\/li>\n<li>No arriesgamos: no cambiamos la configuraci\u00f3n de producci\u00f3n de los clientes.<\/li>\n<li>No rompimos nada. <\/li>\n<\/ol>\n<p><\/p>\n<h2>Prototipo 2.0<\/h2>\n<p>\nAs\u00ed que regresamos a la mesa de dibujo y repetimos el proceso desde el principio.<\/p>\n<p>La idea es que en lugar de un 100% de proxy, para cada cliente determinaremos el camino m\u00e1s r\u00e1pido y dirigiremos las solicitudes all\u00ed; es decir, haremos lo que se llama 'client steering'.<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/780817f48a4d2b292d5545e0aa1ccc50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00bfC\u00f3mo se implementa esto? No podemos utilizar l\u00f3gica del lado del servidor, ya que el objetivo es conectarse a este servidor. Hay que hacerlo de alguna manera en el cliente. Idealmente, esto deber\u00eda hacerse con la m\u00ednima cantidad de l\u00f3gica compleja, para no enfrentar problemas de integraci\u00f3n con un amplio n\u00famero de plataformas clientes. <\/p>\n<p>La respuesta es el uso de DNS. En nuestro caso, tenemos nuestra propia infraestructura DNS, y podemos configurar una zona de dominio para la cual nuestros servidores ser\u00e1n autoritativos. Funciona as\u00ed:<\/p>\n<ol>\n<li>El cliente realiza una solicitud al servidor DNS utilizando un host, por ejemplo, api.netflix.xom.<\/li>\n<li>La solicitud llega a nuestro servidor DNS.<\/li>\n<li>El servidor DNS sabe cu\u00e1l es el camino m\u00e1s r\u00e1pido para este cliente y devuelve la direcci\u00f3n IP correspondiente. <\/li>\n<\/ol>\n<p>\nEn la soluci\u00f3n hay una complejidad adicional: los proveedores de DNS autoritativos no ven la direcci\u00f3n IP del cliente y solo pueden considerar la direcci\u00f3n IP del resolver recursivo que utiliza el cliente. <\/p>\n<p>Como resultado, nuestro resolver autoritativo debe tomar decisiones no para un cliente individual, sino para un grupo de clientes basado en el resolver recursivo. <\/p>\n<p>Para resolverlo, utilizamos las mismas pruebas, agregamos los resultados de las mediciones de los clientes desde cada uno de los resolvers recursivos y decidimos a d\u00f3nde dirigir a este grupo: a trav\u00e9s de un proxy por IX utilizando TCP Anycast, a trav\u00e9s de un proxy ISP o directamente a la nube.<\/p>\n<p>Obtenemos un sistema de este tipo:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/ad23219938d1cb7b6eef498671c3e151.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl modelo de DNS steering obtenido permite dirigir a los clientes basado en observaciones hist\u00f3ricas sobre la velocidad de las conexiones desde los clientes hacia la nube. <\/p>\n<p>De nuevo, la pregunta es: \u00bfqu\u00e9 tan efectivo ser\u00e1 funcionar de esta manera? Para responder, una vez m\u00e1s utilizamos nuestro sistema de pruebas. Por lo tanto, configuramos una evaluaci\u00f3n reciente, donde uno de los objetivos sigue la direcci\u00f3n del DNS steering, mientras que el otro va directamente a la nube (producci\u00f3n actual).<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/ceb2ded9367ebd0aa0ede46191a89a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl final, comparamos los resultados y obtenemos una evaluaci\u00f3n de la efectividad:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/ca0db88461d5f2cb0f3f7c07eae14f10.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl final, hemos aprendido varias cosas importantes:<\/p>\n<ol>\n<li>Hemos evaluado el rendimiento esperado de las solicitudes desde los clientes hacia la nube usando DNS Steering.<\/li>\n<li>Recopilamos datos de clientes reales, de todos los tipos de dispositivos.<\/li>\n<li>Hemos demostrado la efectividad de la idea propuesta.<\/li>\n<li>No arriesgamos: no cambiamos la configuraci\u00f3n de producci\u00f3n de los clientes.<\/li>\n<li>No rompimos nada.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Ahora, lo complicado: lanzamos en producci\u00f3n.<\/h2>\n<p>\nLo m\u00e1s f\u00e1cil ya ha pasado: hay un prototipo funcional. Ahora viene la parte complicada: implementar la soluci\u00f3n para todo el tr\u00e1fico de Netflix, desplegarla 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\u00e1cil romper el servicio con un error imprudente. Al mismo tiempo, queremos redirigir din\u00e1micamente el tr\u00e1fico a trav\u00e9s de miles de servidores CDN, en un entorno de Internet donde las cosas cambian y se rompen constantemente y en los peores momentos. <\/p>\n<p>Y a pesar de todo esto, en el equipo hay 3 ingenieros responsables del desarrollo, implementaci\u00f3n y completo soporte del sistema.<\/p>\n<p>As\u00ed que a partir de ahora hablaremos sobre un sue\u00f1o tranquilo y saludable.<\/p>\n<p>\u00bfC\u00f3mo continuar con el desarrollo y no perder todo el tiempo en el soporte? Nuestra estrategia se basa en 3 principios:<\/p>\n<ol>\n<li>Reducimos el posible alcance de las fallas (blast radius). <\/li>\n<li>Nos preparamos para sorpresas: esperamos que algo se rompa, a pesar de las pruebas y la experiencia personal.<\/li>\n<li>Degradaci\u00f3n gradual (graceful degradation): si algo no funciona correctamente, debe repararse autom\u00e1ticamente, aunque no de la manera m\u00e1s eficiente.<\/li>\n<\/ol>\n<p>\nResult\u00f3 que en nuestro caso, con este enfoque al problema, se puede encontrar una soluci\u00f3n simple y efectiva y simplificar considerablemente el soporte del sistema. Nos dimos cuenta de que pod\u00edamos agregar un peque\u00f1o fragmento de c\u00f3digo en el cliente y supervisar los errores de las solicitudes de red causados por problemas de conexi\u00f3n. Ante fallas de red, hacemos un fallback directo a la nube. Esta soluci\u00f3n no requiere grandes esfuerzos por parte de los equipos de cliente, pero reduce significativamente el riesgo de fallas inesperadas y sorpresas para nosotros.<\/p>\n<p>Por supuesto, a pesar del fallback, seguimos una disciplina clara durante el desarrollo:<\/p>\n<ol>\n<li>Prueba de muestras.<\/li>\n<li>Pruebas A\/B o Canaries.<\/li>\n<li>Lanzamiento progresivo (progressive rollout).<\/li>\n<\/ol>\n<p>\nCon las pruebas, el enfoque fue descrito: los cambios primero se prueban mediante una receta configurada.<\/p>\n<p>Para las pruebas canary, necesitamos obtener pares de servidores comparables en los que se pueda comparar c\u00f3mo funciona el sistema antes y despu\u00e9s de los cambios. Para esto, de nuestros numerosos sitios CDN, hacemos una selecci\u00f3n de pares de servidores que reciben tr\u00e1fico comparable:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/eef504f5c81aa985b78339fd5f913d14.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLuego, colocamos la versi\u00f3n con los cambios en los servidores Canary. Para evaluar los resultados, ejecutamos un sistema que compara alrededor de 100-150 m\u00e9tricas tomando como referencia los servidores Control:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/898edb0a5bd493d6ef228cd116c1a939.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi la prueba en Canary fue exitosa, lanzamos la versi\u00f3n de manera gradual, por oleadas. En cada uno de los sitios no actualizamos los servidores al mismo tiempo; la p\u00e9rdida de un sitio entero en caso de problemas tiene un impacto m\u00e1s significativo en el servicio para los usuarios que la p\u00e9rdida de la misma cantidad de servidores, pero en diferentes ubicaciones.<\/p>\n<p>En general, la efectividad y seguridad de este enfoque depende de la cantidad y calidad de las m\u00e9tricas recopiladas. Para nuestro sistema de aceleraci\u00f3n de solicitudes, recopilamos m\u00e9tricas de todos los componentes posibles: <\/p>\n<ul>\n<li>de los clientes: n\u00famero de sesiones y solicitudes, tasas de retroceso; <\/li>\n<li>proxy: estad\u00edsticas sobre el n\u00famero y la duraci\u00f3n de las solicitudes;<\/li>\n<li>DNS: cantidad y resultados de las solicitudes;<\/li>\n<li>nube perimetral: cantidad y tiempo de procesamiento de solicitudes en la nube.<\/li>\n<\/ul>\n<p>\nTodo esto se recopila en un pipeline \u00fanico, y, seg\u00fan las necesidades, decidimos qu\u00e9 m\u00e9tricas enviar a la anal\u00edtica en tiempo real y cu\u00e1les a Elasticsearch o Big Data para un diagn\u00f3stico m\u00e1s detallado.<\/p>\n<h2>Monitoreo<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/ff8b00b1239a20f85e96ce23c2d7c2d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn nuestro caso, realizamos cambios en la ruta cr\u00edtica de las solicitudes entre el cliente y el servidor. Al mismo tiempo, la cantidad de diversos componentes en el cliente, en el servidor y en el camino a trav\u00e9s de internet es enorme. Los cambios en el cliente y el servidor ocurren constantemente, a lo largo del trabajo de decenas de equipos y los cambios naturales en el ecosistema. Estamos en medio; al diagnosticar problemas hay una gran probabilidad de que estemos involucrados. Por lo tanto, necesitamos entender claramente c\u00f3mo determinar, recopilar y analizar m\u00e9tricas para identificar problemas r\u00e1pidamente. <\/p>\n<p>Lo ideal es tener acceso completo a todos los tipos de m\u00e9tricas y filtros en tiempo real. Pero hay muchas m\u00e9tricas, por lo que surge la cuesti\u00f3n del costo. En nuestro caso, separamos las m\u00e9tricas y las herramientas de desarrollo de la siguiente manera:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/0b4a15776f3b44331652adc14ea87390.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara detectar y clasificar problemas, utilizamos nuestro propio sistema de c\u00f3digo abierto en tiempo real <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Netflix\/atlas\">Atlas<\/a><\/noindex> y <noindex><a rel=\"nofollow\" href=\"https:\/\/netflixtechblog.com\/lumen-custom-self-service-dashboarding-for-netflix-8c56b541548c\">Lumen<\/a><\/noindex> \u2014 para visualizaci\u00f3n. Este sistema almacena m\u00e9tricas agregadas en memoria, es confiable e integra con el sistema de alertas. Para la localizaci\u00f3n y diagn\u00f3stico, tenemos acceso a los registros de Elasticsearch y Kibana. Para el an\u00e1lisis estad\u00edstico y modelado, utilizamos big data y visualizaci\u00f3n en Tableau.<\/p>\n<p>Parece que es muy dif\u00edcil trabajar con este enfoque. Sin embargo, con una organizaci\u00f3n jer\u00e1rquica de m\u00e9tricas y herramientas, podemos analizar r\u00e1pidamente el problema, identificar el tipo de problema y luego profundizar en m\u00e9tricas detalladas. Por lo general, tardamos alrededor de 1 a 2 minutos en identificar la fuente del fallo. Despu\u00e9s de eso, ya trabajamos con un equipo espec\u00edfico en el diagn\u00f3stico, que puede llevar desde decenas de minutos hasta varias horas.<\/p>\n<p>Incluso si el diagn\u00f3stico se realiza r\u00e1pidamente, no queremos que esto suceda con frecuencia. En un escenario ideal, recibiremos una alerta cr\u00edtica solo cuando haya un impacto significativo en el servicio. Para nuestro sistema de aceleraci\u00f3n de solicitudes, tenemos solo 2 alertas que nos notificar\u00e1n:<\/p>\n<ul>\n<li>porcentaje de Client Fallback \u2014 evaluaci\u00f3n del comportamiento de los clientes;<\/li>\n<li>porcentaje de Probe errors \u2014 datos de estabilidad de los componentes de red.<\/li>\n<\/ul>\n<p>\nEstas alertas cr\u00edticas monitorizan si el sistema est\u00e1 funcionando para la mayor\u00eda de los usuarios. Observamos cu\u00e1ntos clientes han utilizado el fallback si no pudieron obtener la aceleraci\u00f3n de solicitudes. En promedio, tenemos menos de 1 alerta cr\u00edtica a la semana, aunque se producen un gran n\u00famero de cambios en el sistema. \u00bfPor qu\u00e9 es suficiente para nosotros?<\/p>\n<ol>\n<li>Hay un client fallback en caso de que nuestro proxy no funcione.<\/li>\n<li>Hay un sistema de steering autom\u00e1tico que reacciona ante problemas.<\/li>\n<\/ol>\n<p>\nHablemos m\u00e1s sobre esto. Nuestro sistema de sondas y el sistema de determinaci\u00f3n autom\u00e1tica de la ruta \u00f3ptima para las solicitudes del cliente en la nube permiten lidiar autom\u00e1ticamente con algunos problemas. <\/p>\n<p>Regresando a nuestra configuraci\u00f3n de sondas y 3 categor\u00edas de rutas. Adem\u00e1s del tiempo de carga, podemos observar el hecho mismo de la entrega. Si no se pudieron cargar los datos, al observar los resultados de diferentes rutas, podemos determinar d\u00f3nde y qu\u00e9 fall\u00f3, y si podemos solucionarlo autom\u00e1ticamente cambiando la ruta de la solicitud.<\/p>\n<p>Ejemplos:<\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/7d935da82aaca53af87f05fbdf215c4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/f74ef9d3de953099921a68fbc65cb187.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/3c77cbd47813d3320efbf339a0690c53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste proceso se puede automatizar. Incluirlo en el sistema de steering. Y ense\u00f1arle a reaccionar ante problemas de rendimiento y fiabilidad. Si algo comienza a fallar, reacciona si hay una mejor opci\u00f3n. Sin embargo, la respuesta instant\u00e1nea no es cr\u00edtica, gracias al fallback en los clientes.<\/p>\n<p>Por lo tanto, los principios de mantenimiento del sistema se pueden formular as\u00ed:<\/p>\n<ul>\n<li>reducci\u00f3n de la magnitud de las fallas;<\/li>\n<li>recolecci\u00f3n de m\u00e9tricas;<\/li>\n<li>reparaci\u00f3n autom\u00e1tica de fallas, si es posible;<\/li>\n<li>si no es posible, notificamos;<\/li>\n<li>Estamos trabajando en dashboards y un conjunto de herramientas de triage para una respuesta r\u00e1pida.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Lecciones aprendidas.<\/h2>\n<p>\nCrear un prototipo no requiere mucho tiempo. En nuestro caso, estuvo listo en solo 4 meses. Con \u00e9l, obtuvimos nuevas m\u00e9tricas, y despu\u00e9s de 10 meses desde el inicio del desarrollo, recibimos el primer tr\u00e1fico de producci\u00f3n. Luego comenz\u00f3 el trabajo arduo y complicado: productizar y escalar gradualmente el sistema, migrar el tr\u00e1fico principal y aprender de los errores. Este proceso eficiente no ser\u00e1 lineal: a pesar de todos los esfuerzos, no se puede predecir todo. Es mucho m\u00e1s efectivo: iterar r\u00e1pidamente y reaccionar ante nuevas informaciones. <\/p>\n<p><img decoding=\"async\" alt=\"Aceleramos las solicitudes de internet y dormimos tranquilos\" src=\"\/wp-content\/uploads\/2020\/06\/c9c182a1a4fa048b1f1b2a82a4db65e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBas\u00e1ndonos en nuestra experiencia, podemos recomendar lo siguiente:<\/p>\n<ol>\n<li>No conf\u00edes en la intuici\u00f3n.\n<p>Nuestra intuici\u00f3n nos fallaba constantemente, a pesar de la gran experiencia de los miembros del equipo. Por ejemplo, predec\u00edamos incorrectamente la aceleraci\u00f3n esperada al usar proxies CDN, o el comportamiento de TCP Anycast.<\/li>\n<li>Obt\u00e9n datos de producci\u00f3n.\n<p>Es importante obtener acceso lo antes posible, aunque sea a una peque\u00f1a cantidad de datos de producci\u00f3n. Es pr\u00e1cticamente imposible obtener el n\u00famero \u00fanico de casos, configuraciones y ajustes en condiciones de laboratorio. Tener acceso r\u00e1pido a los resultados permitir\u00e1 conocer m\u00e1s r\u00e1pidamente sobre problemas potenciales y tenerlos en cuenta en la arquitectura del sistema.<\/li>\n<li>No sigas los consejos y resultados de otros; recopila tus propios datos.\n<p>Sigue los principios de recopilaci\u00f3n y an\u00e1lisis de datos, pero no tomes ciegamente los resultados y afirmaciones de otros. Solo t\u00fa puedes saber exactamente lo que funciona para tus usuarios. Tus sistemas y tus clientes pueden diferir significativamente de los de otras empresas. Afortunadamente, las herramientas de an\u00e1lisis son ahora accesibles y f\u00e1ciles de usar. Los resultados que obtengas pueden no coincidir con lo que afirman Netflix, Facebook, Akamai y otras empresas. En nuestro caso, el rendimiento de TLS, HTTP2 o estad\u00edsticas sobre consultas DNS difieren de los resultados de Facebook, Uber, Akamai, porque tenemos otros dispositivos, clientes y flujos de datos.<\/li>\n<li>No persigas modas sin necesidad y sin evaluar su eficacia.\n<p>Comienza con lo simple. Es mejor crear un sistema b\u00e1sico funcional en poco tiempo que gastar una gran cantidad de tiempo desarrollando componentes que no necesitas. Resuelve tareas y problemas que son importantes bas\u00e1ndote en tus mediciones y resultados. <\/li>\n<li>Prep\u00e1rese para nuevas aplicaciones.\n<p>Al igual que es dif\u00edcil prever todos los problemas, tambi\u00e9n lo es anticipar los beneficios y aplicaciones. Mire el ejemplo de las startups: su capacidad para adaptarse a las condiciones del cliente. En su caso, puede descubrir nuevos problemas y sus soluciones. En nuestro proyecto, nos propusimos reducir la latencia de las solicitudes. Sin embargo, durante el an\u00e1lisis y las discusiones, nos dimos cuenta de que tambi\u00e9n podemos aplicar servidores proxy:<\/p>\n<ul>\n<li>para equilibrar el tr\u00e1fico entre regiones de AWS y reducir costos;<\/li>\n<li>para modelar la estabilidad de la CDN;<\/li>\n<li>para configurar el DNS;<\/li>\n<li>para configurar TLS\/TCP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Conclusi\u00f3n<\/h2>\n<p>\nEn el informe, describ\u00ed c\u00f3mo Netflix aborda el desaf\u00edo de acelerar las solicitudes de internet entre clientes y la nube. C\u00f3mo recopilamos datos usando un sistema de muestreo en los clientes y utilizamos los datos hist\u00f3ricos recopilados para dirigir las solicitudes de producci\u00f3n desde los clientes a trav\u00e9s del camino m\u00e1s r\u00e1pido en internet. C\u00f3mo utilizamos los principios de los protocolos de red, nuestra infraestructura de CDN, la red backbone y los servidores DNS para lograr este objetivo.<\/p>\n<p>Sin embargo, nuestra soluci\u00f3n es tan solo un ejemplo de c\u00f3mo hemos implementado un sistema as\u00ed en Netflix. Lo que funcion\u00f3 para nosotros. La parte pr\u00e1ctica de mi informe para ustedes son los principios de desarrollo y soporte que seguimos para lograr buenos resultados.<\/p>\n<p>Nuestra soluci\u00f3n al problema puede no ser adecuada para ustedes. Sin embargo, la teor\u00eda y los principios de desarrollo permanecen, incluso si no tienen su propia infraestructura de CDN, o si es significativamente diferente de la nuestra. <\/p>\n<p>Tambi\u00e9n sigue siendo importante la velocidad de las solicitudes para el negocio. Y incluso para un servicio sencillo es necesario tomar decisiones: entre proveedores 'cloud', la ubicaci\u00f3n de los servidores, la CDN y los proveedores de DNS. Su elecci\u00f3n afectar\u00e1 la eficiencia de las solicitudes de internet para sus clientes. Y es importante medir y comprender esa influencia.<\/p>\n<p>Comience con soluciones simples, preoc\u00fapese por c\u00f3mo modifica el producto. Aprenda en el proceso y mejore el sistema basado en los datos de sus clientes, su infraestructura y su negocio. Piense en la posibilidad de fallos inesperados durante el dise\u00f1o. Y as\u00ed podr\u00e1 acelerar su proceso de desarrollo, mejorar la eficiencia de la soluci\u00f3n, evitar una carga excesiva en el soporte y dormir tranquilo.<\/p>\n<blockquote><p>Este a\u00f1o <noindex><a rel=\"nofollow\" href=\"http:\/\/devoops-moscow.ru\/?utm_source=habr&amp;utm_medium=506106\">la conferencia se llevar\u00e1 a cabo del 6 al 10 de julio<\/a><\/noindex> en formato online. \u00a1Podr\u00e1s hacer preguntas a uno de los padres de DevOps, el mismo John Willis!<\/p><\/blockquote>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/jugru\/blog\/506106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84877,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84876","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Aceleramos las solicitudes de internet y dormimos tranquilos | ProHoster","description":"Netflix es el l\u00edder del mercado de televisi\u00f3n por internet.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster","og:description":"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-11T11:43:18+00:00","article:modified_time":"2020-06-11T11:43:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84876","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:48:22","updated":"2022-09-27 23:34:06","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/84876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=84876"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/84876\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/84877"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=84876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=84876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=84876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}