{"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\/fr\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","title":{"rendered":"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/07e2e32d406b8b5d6d6cb3f627a31c3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNetflix \u2014 leader du march\u00e9 de la t\u00e9l\u00e9vision par Internet \u2014 est une entreprise qui a cr\u00e9\u00e9 et qui d\u00e9veloppe activement ce segment. Netflix est connu non seulement pour son vaste catalogue de films et de s\u00e9ries, accessible presque de n'importe quel coin du globe et sur tout appareil avec un \u00e9cran, mais aussi pour son infrastructure fiable et sa culture d'ing\u00e9nierie unique. <\/p>\n<p>Un exemple concret de l'approche de Netflix en mati\u00e8re de d\u00e9veloppement et de maintenance de syst\u00e8mes complexes a \u00e9t\u00e9 pr\u00e9sent\u00e9 lors de DevOops 2019 par <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Sergue\u00ef Fedorov<\/a><\/noindex> \u2014 directeur du d\u00e9veloppement chez Netflix. Dipl\u00f4m\u00e9 de la facult\u00e9 de VMI de l'Universit\u00e9 d'\u00c9tat de Nijni Novgorod, Sergue\u00ef est l'un des premiers ing\u00e9nieurs d'Open Connect \u2014 l'\u00e9quipe CDN de Netflix. Il a construit des syst\u00e8mes de surveillance et d'analyse des donn\u00e9es vid\u00e9o, a lanc\u00e9 le service populaire d'\u00e9valuation de la vitesse de connexion Internet FAST.com et, ces derni\u00e8res ann\u00e9es, a travaill\u00e9 \u00e0 l'optimisation des requ\u00eates Internet afin que l'application Netflix fonctionne aussi rapidement que possible pour les utilisateurs.<\/p>\n<p>La pr\u00e9sentation a re\u00e7u les meilleurs avis des participants \u00e0 la conf\u00e9rence et nous avons pr\u00e9par\u00e9 pour vous une version \u00e9crite.<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=\"Lire la vid\u00e9o\" 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>Dans cette pr\u00e9sentation, Sergue\u00ef a expliqu\u00e9 en d\u00e9tail<\/h2>\n<p><\/p>\n<ul>\n<li>ce qui influence la latence des requ\u00eates Internet entre le client et le serveur;<\/li>\n<li>comment r\u00e9duire cette latence;<\/li>\n<li>comment concevoir, maintenir et surveiller des syst\u00e8mes r\u00e9silients aux pannes;<\/li>\n<li>comment atteindre des r\u00e9sultats dans des d\u00e9lais serr\u00e9s et avec un risque minimal pour l'entreprise;<\/li>\n<li>comment analyser les r\u00e9sultats et apprendre de ses erreurs.<\/li>\n<\/ul>\n<p>\nLes r\u00e9ponses \u00e0 ces questions sont n\u00e9cessaires non seulement \u00e0 ceux qui travaillent dans de grandes entreprises. <\/p>\n<p>Les principes et techniques pr\u00e9sent\u00e9s doivent \u00eatre connus et pratiqu\u00e9s par quiconque d\u00e9veloppe et maintient des produits Internet.<\/p>\n<p><b>Ensuite \u2014 le r\u00e9cit du speaker.<\/b><\/p>\n<h2>L'importance de la vitesse de l'Internet<\/h2>\n<p>\nLa vitesse des requ\u00eates Internet est directement li\u00e9e aux affaires. Consid\u00e9rons le secteur du shopping : l'entreprise Amazon en 2009 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">a d\u00e9clar\u00e9<\/a><\/noindex>, qu'un retard de 100 ms entra\u00eene une perte de 1 % des ventes.<\/p>\n<p>Il y a de plus en plus d'appareils mobiles, et par cons\u00e9quent de sites et d'applications mobiles. Si votre page met plus de 3 secondes \u00e0 se charger, vous perdez environ la moiti\u00e9 de vos utilisateurs. Depuis <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">juillet 2018<\/a><\/noindex> , Google prend en compte la vitesse de chargement de votre page dans les r\u00e9sultats de recherche : plus la page est rapide, plus sa position dans Google est \u00e9lev\u00e9e.<\/p>\n<p>La vitesse de connexion est \u00e9galement importante dans les organisations financi\u00e8res, o\u00f9 le retard est critique. En 2015, l'entreprise 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\">a termin\u00e9<\/a><\/noindex> un c\u00e2ble entre New York et Londres co\u00fbtant 400 millions de dollars, afin de r\u00e9duire le temps de latence entre les villes de 6 ms. Imaginez, 66 millions de dollars pour 1 ms de r\u00e9duction de latence !<\/p>\n<p>Selon <noindex><a rel=\"nofollow\" href=\"https:\/\/hpbn.co\/primer-on-web-performance\/\">une \u00e9tude<\/a><\/noindex>, une connexion sup\u00e9rieure \u00e0 5 Mbit\/s n'affecte plus directement la vitesse de chargement d'un site web standard. Cependant, il existe une d\u00e9pendance lin\u00e9aire entre la latence de connexion et la vitesse de chargement des pages :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/340ca1f2c5bdd6ca95a5caf02f67e3fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCependant, Netflix n'est pas un produit standard. L'impact de la latence et de la vitesse sur l'utilisateur est un domaine d'analyse et de d\u00e9veloppement actif. Il y a le chargement de l'application et le choix du contenu, qui d\u00e9pendent de la latence, mais le chargement des \u00e9l\u00e9ments statiques et le streaming d\u00e9pendent \u00e9galement de la vitesse de connexion. L'analyse et l'optimisation des facteurs cl\u00e9s influen\u00e7ant la qualit\u00e9 du service pour l'utilisateur est un domaine actif de d\u00e9veloppement pour plusieurs \u00e9quipes chez Netflix. L'un des objectifs est de r\u00e9duire la latence des requ\u00eates entre les appareils Netflix et l'infrastructure cloud.<\/p>\n<p>Dans ce rapport, nous allons nous concentrer sur la r\u00e9duction de la latence (latency) en prenant l'exemple de l'infrastructure de Netflix. Nous examinerons de mani\u00e8re pratique comment aborder les processus de conception, de d\u00e9veloppement et d'exploitation de syst\u00e8mes distribu\u00e9s complexes tout en passant du temps sur l'innovation et les r\u00e9sultats, et non sur le diagnostic des probl\u00e8mes op\u00e9rationnels et des pannes.<\/p>\n<h2>\u00c0 l'int\u00e9rieur de Netflix<\/h2>\n<p>\nDes milliers de dispositifs diff\u00e9rents prennent en charge les applications Netflix. Leur d\u00e9veloppement est entrepris par quatre \u00e9quipes diff\u00e9rentes, qui cr\u00e9ent des versions distinctes du client pour Android, iOS, TV et navigateurs web. Nous consacrons \u00e9galement beaucoup d'efforts \u00e0 am\u00e9liorer et \u00e0 personnaliser l'interface utilisateur. Pour cela, nous ex\u00e9cutons des centaines de tests A\/B en parall\u00e8le.<\/p>\n<p>La personnalisation est soutenue par des centaines de microservices dans le cloud AWS, fournissant des donn\u00e9es personnalis\u00e9es pour l'utilisateur, la gestion des requ\u00eates, la t\u00e9l\u00e9m\u00e9trie, le Big Data et l'encodage. La visualisation du trafic est la suivante :<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Lien vers la vid\u00e9o de d\u00e9monstration (6:04-6:23)<\/a><\/noindex><\/p>\n<p>\u00c0 gauche se trouve le point d'entr\u00e9e, puis le trafic est r\u00e9parti entre plusieurs centaines de microservices, soutenus par diff\u00e9rentes \u00e9quipes backend.<\/p>\n<p>Un autre composant important de notre infrastructure est le CDN Open Connect, qui livre du contenu statique\u2014vid\u00e9os, images, code pour les clients, etc.\u2014jusqu'\u00e0 l'utilisateur final. Le CDN est situ\u00e9 sur des serveurs personnalis\u00e9s (OCA - Open Connect Appliance). \u00c0 l'int\u00e9rieur, se trouvent des ensembles de disques SSD et HDD fonctionnant sous un FreeBSD optimis\u00e9, avec NGINX et un ensemble de services. Nous concevons et optimisons les composants mat\u00e9riels et logiciels afin que ce serveur CDN puisse envoyer le plus de donn\u00e9es possible aux utilisateurs. <\/p>\n<p>Le \u00ab mur \u00bb de ces serveurs au point d'\u00e9change de trafic Internet (Internet eXchange - IX) se pr\u00e9sente comme suit :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/8155601c344acb1eb05b925193af8f9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'Internet Exchange permet aux fournisseurs d'acc\u00e8s Internet et aux fournisseurs de contenu de se \u00ab connecter \u00bb les uns aux autres pour un \u00e9change de donn\u00e9es plus direct sur Internet. Il existe environ 70 \u00e0 80 points Internet Exchange dans le monde, o\u00f9 nos serveurs sont install\u00e9s, et nous nous occupons nous-m\u00eames de leur installation et de leur maintenance :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/77a2465314e47c0b2c90dbf7a2fb5e6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe plus, nous fournissons \u00e9galement des serveurs directement aux fournisseurs d'acc\u00e8s Internet, qui les installent dans leur r\u00e9seau, am\u00e9liorant ainsi la localisation du trafic Netflix et la qualit\u00e9 du streaming pour les utilisateurs :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/63e077d2649bfafea5c7af43a0faaf85.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'ensemble des services AWS est responsable de l'acheminement des requ\u00eates vid\u00e9o des clients vers les serveurs CDN, ainsi que de la configuration m\u00eame de ces serveurs\u2014mise \u00e0 jour du contenu, du code logiciel, des param\u00e8tres, etc. Pour cela, nous avons \u00e9galement construit un backbone network qui relie les serveurs des points Internet Exchange \u00e0 AWS. Le backbone network est un r\u00e9seau mondial de c\u00e2bles en fibre optique et de routeurs, que nous pouvons concevoir et configurer en fonction de nos besoins.<\/p>\n<p>Selon <noindex><a rel=\"nofollow\" href=\"https:\/\/www.sandvine.com\/hubfs\/Sandvine_Redesign_2019\/Downloads\/Internet%20Phenomena\/Internet%20Phenomena%20Report%20Q32019%2020190910.pdf\">estimations de Sandvine<\/a><\/noindex>, notre infrastructure CDN livre aux heures de pointe environ \u215b du trafic Internet mondial et \u2153 du trafic en Am\u00e9rique du Nord, o\u00f9 Netflix existe depuis le plus longtemps. Ce sont des chiffres impressionnants, mais pour moi, l'un des accomplissements les plus \u00e9tonnants est que l'ensemble du syst\u00e8me CDN est d\u00e9velopp\u00e9 et maintenu par une \u00e9quipe de moins de 150 personnes.<\/p>\n<p>\u00c0 l'origine, l'infrastructure CDN \u00e9tait con\u00e7ue pour la livraison de donn\u00e9es vid\u00e9o. Cependant, avec le temps, nous avons r\u00e9alis\u00e9 que nous pouvions \u00e9galement l'utiliser pour optimiser les requ\u00eates dynamiques des clients vers le cloud AWS.<\/p>\n<h2>Sur l'acc\u00e9l\u00e9ration de l'Internet<\/h2>\n<p>\nAujourd'hui, Netflix compte 3 r\u00e9gions AWS, et la latence des requ\u00eates vers le cloud d\u00e9pendra de la distance entre le client et la r\u00e9gion la plus proche. Nous avons aussi de nombreux serveurs CDN qui sont utilis\u00e9s pour la livraison de contenu statique. Existe-t-il un moyen d'utiliser cette infrastructure pour acc\u00e9l\u00e9rer les requ\u00eates dynamiques ? Malheureusement, ces requ\u00eates ne peuvent pas \u00eatre mises en cache, car les API sont personnalis\u00e9es et chaque r\u00e9sultat est unique.<\/p>\n<p>Cr\u00e9ons un proxy sur le serveur CDN et commen\u00e7ons \u00e0 acheminer le trafic \u00e0 travers lui. Cela sera-t-il plus rapide ?<\/p>\n<h2>Mat\u00e9riel<\/h2>\n<p>\nRappelons-nous comment fonctionnent les protocoles r\u00e9seau. Aujourd'hui, la majorit\u00e9 du trafic sur Internet utilise HTTPS, qui d\u00e9pend des protocoles de bas niveau TCP et TLS. Pour que le client se connecte au serveur, il effectue un handshake, et pour \u00e9tablir une connexion s\u00e9curis\u00e9e, le client doit \u00e9changer des messages avec le serveur trois fois, plus au moins une fois de plus pour transmettre des donn\u00e9es. Avec une latence d'un \u00e9change (RTT) de 100 ms, nous aurons besoin de 400 ms pour obtenir le premier bit de donn\u00e9es :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/ab12024f5a9940ca470f27821ca3c631.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi nous pla\u00e7ons les certificats sur le serveur CDN, nous pouvons consid\u00e9rablement r\u00e9duire le temps de \u00ab handshake \u00bb entre le client et le serveur, \u00e0 condition que le CDN soit plus proche. Supposons que la latence vers le serveur CDN soit de 30 ms. Alors, pour obtenir le premier bit, il faudra d\u00e9j\u00e0 220 ms :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/d63134bb51592aaa6a5e0c86f1a070e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMais les avantages ne s'arr\u00eatent pas l\u00e0. Une fois la connexion \u00e9tablie, TCP augmente la congestion de la fen\u00eatre (la quantit\u00e9 d'informations qu'il peut transmettre sur cette connexion en parall\u00e8le). Si un paquet de donn\u00e9es est perdu, les impl\u00e9mentations classiques du protocole TCP (comme TCP New Reno) r\u00e9duisent la \u00ab fen\u00eatre \u00bb ouverte de moiti\u00e9. L'augmentation de la congestion de la fen\u00eatre, et la vitesse de sa r\u00e9cup\u00e9ration apr\u00e8s une perte d\u00e9pendront \u00e0 nouveau de la latence (RTT) vers le serveur. Si cette connexion ne passe que par le serveur CDN, cette r\u00e9cup\u00e9ration sera plus rapide. De plus, la perte de paquets est un ph\u00e9nom\u00e8ne standard, surtout pour les r\u00e9seaux sans fil.<\/p>\n<p>La bande passante Internet peut diminuer, surtout pendant les heures de pointe \u00e0 cause du trafic des utilisateurs, ce qui peut entra\u00eener des \u00ab embouteillages \u00bb. Il n'existe cependant pas de moyen sur Internet pour donner la priorit\u00e9 \u00e0 certaines requ\u00eates par rapport \u00e0 d'autres. Par exemple, donner la priorit\u00e9 aux requ\u00eates l\u00e9g\u00e8res et sensibles \u00e0 la latence par rapport aux \u00ab lourds \u00bb flux de donn\u00e9es qui saturent le r\u00e9seau. Toutefois, dans notre cas, la pr\u00e9sence d'un r\u00e9seau backbone propre nous permet de le faire sur une partie du chemin de la requ\u00eate - entre le CDN et le cloud, et nous pouvons le configurer enti\u00e8rement. Nous pouvons faire en sorte que de petits paquets sensibles \u00e0 la latence soient prioritaires, tandis que les gros flux de donn\u00e9es passent un peu plus tard. Plus le CDN est proche du client, plus l'efficacit\u00e9 est grande.<\/p>\n<p>De plus, les protocoles de niveau application (niveau 7 du mod\u00e8le OSI) influencent \u00e9galement la latence. De nouveaux protocoles, comme HTTP\/2, permettent d'optimiser la performance des requ\u00eates parall\u00e8les. Cependant, nos clients de Netflix poss\u00e8dent des appareils anciens ne supportant pas ces nouveaux protocoles. Tous les clients ne peuvent pas \u00eatre mis \u00e0 jour ou configur\u00e9s de mani\u00e8re optimale. Entre le proxy du CDN et le cloud, nous avons un contr\u00f4le total et la possibilit\u00e9 d'utiliser des protocoles et des configurations nouveaux et optimaux. La partie inefficace avec les anciens protocoles n'agira que entre le client et le serveur CDN. De plus, nous pouvons r\u00e9aliser le multiplexage des requ\u00eates sur une connexion d\u00e9j\u00e0 \u00e9tablie entre le CDN et le cloud, am\u00e9liorant ainsi l'utilisation de la connexion au niveau TCP.<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/a05b49680734670dcfce9111f3ba1919.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Mesurons<\/h2>\n<p>\nBien que la th\u00e9orie promette des am\u00e9liorations, nous ne nous pr\u00e9cipitons pas pour lancer le syst\u00e8me en production. Au lieu de cela, nous devons d'abord prouver que l'id\u00e9e fonctionnera dans la pratique. Pour cela, il est n\u00e9cessaire de r\u00e9pondre \u00e0 plusieurs questions :<\/p>\n<ul>\n<li><b>Vitesse<\/b>: le proxy sera-t-il plus rapide ?<\/li>\n<li><b>Fiabilit\u00e9<\/b>: sera-t-il plus sujet aux pannes ?<\/li>\n<li><b>Complexit\u00e9<\/b>: comment s'int\u00e9grer aux applications ?<\/li>\n<li><b>Co\u00fbt<\/b>: quel est le co\u00fbt de d\u00e9ploiement d'une infrastructure suppl\u00e9mentaire ?<\/li>\n<\/ul>\n<p>\nExaminons en d\u00e9tail notre approche pour \u00e9valuer le premier point. Les autres se traitent de mani\u00e8re similaire.<\/p>\n<p>Pour analyser la vitesse des requ\u00eates, nous souhaitons obtenir des donn\u00e9es pour tous les utilisateurs, ne pas passer trop de temps en d\u00e9veloppement et ne pas casser la production. Pour cela, plusieurs approches existent :<\/p>\n<ol>\n<li>RUM, ou mesure passive des requ\u00eates. Nous mesurons le temps d'ex\u00e9cution des requ\u00eates actuelles des utilisateurs et assurons une couverture compl\u00e8te des utilisateurs. Le d\u00e9savantage est un signal pas tr\u00e8s stable en raison de nombreux facteurs, comme la taille variable des requ\u00eates, le temps de traitement sur le serveur et le client. De plus, il n'est pas possible de tester une nouvelle configuration sans impact sur la production.<\/li>\n<li>Tests en laboratoire. Serveurs et infrastructure sp\u00e9ciaux imitant des clients. Gr\u00e2ce \u00e0 eux, nous effectuons les tests n\u00e9cessaires. Cela nous permet d'avoir un contr\u00f4le total sur les r\u00e9sultats des mesures et un signal clair. Cependant, il n'y a pas de couverture compl\u00e8te des dispositifs et des emplacements des utilisateurs (surtout avec un service \u00e0 l'\u00e9chelle mondiale et prenant en charge des milliers de mod\u00e8les de dispositifs).<\/li>\n<\/ol>\n<p>\nComment combiner les avantages des deux m\u00e9thodes ?<\/p>\n<p>Notre \u00e9quipe a trouv\u00e9 une solution. Nous avons \u00e9crit un petit morceau de code \u2014 un essai \u2014 que nous avons int\u00e9gr\u00e9 dans notre application. Les essais nous permettent d'effectuer des tests r\u00e9seau enti\u00e8rement contr\u00f4l\u00e9s depuis nos dispositifs. Cela fonctionne comme suit : <\/p>\n<ol>\n<li>Peu apr\u00e8s le chargement de l'application et l'ach\u00e8vement des activit\u00e9s initiales, nous lan\u00e7ons nos essais. <\/li>\n<li>Le client fait une demande au serveur et re\u00e7oit une \"recette\" de test. La recette est une liste d'URL auxquelles il faut faire une requ\u00eate HTTP(s). En outre, la recette configure les param\u00e8tres des requ\u00eates : d\u00e9lais entre les requ\u00eates, volume de donn\u00e9es demand\u00e9es, en-t\u00eates HTTP(s), etc. Par ailleurs, nous pouvons tester plusieurs recettes diff\u00e9rentes en parall\u00e8le \u2014 lors de la demande de configuration, nous d\u00e9terminons al\u00e9atoirement quelle recette d\u00e9livrer. <\/li>\n<li>Le temps de d\u00e9marrage de l'essai est choisi pour ne pas entrer en conflit avec l'utilisation active des ressources r\u00e9seau par le client. En substance, un moment est s\u00e9lectionn\u00e9 o\u00f9 le client n'est pas actif.<\/li>\n<li>Apr\u00e8s avoir re\u00e7u la recette, le client effectue des requ\u00eates sur chacune des URL, en parall\u00e8le. La requ\u00eate pour chaque adresse peut \u00eatre r\u00e9p\u00e9t\u00e9e \u2014 les fameux \"pulses\". Lors du premier pulse, nous mesurons le temps n\u00e9cessaire pour \u00e9tablir la connexion et t\u00e9l\u00e9charger les donn\u00e9es. Lors du second pulse, nous mesurons le temps de chargement des donn\u00e9es via la connexion d\u00e9j\u00e0 \u00e9tablie. Avant le troisi\u00e8me, nous pouvons imposer un d\u00e9lai et mesurer la vitesse d'\u00e9tablissement d'une reconnexion, etc.\n<p>Lors du test, nous mesurons tous les param\u00e8tres que le dispositif peut obtenir :<\/p>\n<ul>\n<li>le temps de requ\u00eate DNS ;<\/li>\n<li>le temps d'\u00e9tablissement de la connexion TCP ;<\/li>\n<li>le temps d'\u00e9tablissement de la connexion TLS ;<\/li>\n<li>le temps de r\u00e9ception du premier octet de donn\u00e9es ;<\/li>\n<li>le temps total de chargement ;<\/li>\n<li>le code d'\u00e9tat du r\u00e9sultat.<\/li>\n<\/ul>\n<\/li>\n<li> \u00c0 la fin de chaque pulse, l'\u00e9chantillon t\u00e9l\u00e9charge les r\u00e9sultats de toutes les mesures pour l'analyse.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/fff11d487b7c7725707cdeeca0734296.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLes points cl\u00e9s sont la d\u00e9pendance minimale \u00e0 la logique c\u00f4t\u00e9 client, le traitement des donn\u00e9es c\u00f4t\u00e9 serveur et la mesure des requ\u00eates parall\u00e8les. Ainsi, nous avons la possibilit\u00e9 d'isoler et de tester l'influence de divers facteurs sur la performance des requ\u00eates, de les varier dans un m\u00eame sc\u00e9nario et d'obtenir des r\u00e9sultats venant de clients r\u00e9els.<\/p>\n<p>Cette infrastructure s'est r\u00e9v\u00e9l\u00e9e utile non seulement pour analyser la performance des requ\u00eates. Actuellement, nous avons 14 sc\u00e9narios actifs, plus de 6000 \u00e9chantillons par seconde, recueillant des donn\u00e9es du monde entier et couvrant tous les dispositifs. Si Netflix devait acheter un service similaire \u00e0 des entreprises tierces, cela co\u00fbterait des millions de dollars par an, avec une couverture bien inf\u00e9rieure.<\/p>\n<h2>Nous testons la th\u00e9orie en pratique : prototype<\/h2>\n<p>\nAvec un tel syst\u00e8me, nous avons pu \u00e9valuer l'efficacit\u00e9 d'un proxy CDN sur la latence des requ\u00eates. Maintenant, nous devons :<\/p>\n<ul>\n<li>cr\u00e9er un prototype de proxy ;<\/li>\n<li>d\u00e9ployer le prototype sur un CDN ;<\/li>\n<li>d\u00e9terminer comment diriger les clients vers le proxy sur un serveur CDN sp\u00e9cifique ;<\/li>\n<li>comparer les performances avec les requ\u00eates AWS sans proxy.<\/li>\n<\/ul>\n<p>\nL'objectif est d'\u00e9valuer aussi rapidement que possible l'efficacit\u00e9 de la solution propos\u00e9e. Pour mettre en \u0153uvre le prototype, nous avons choisi Go, gr\u00e2ce \u00e0 la disponibilit\u00e9 de bonnes biblioth\u00e8ques r\u00e9seau. Sur chaque serveur CDN, nous avons install\u00e9 le prototype de proxy sous forme de binaire statique, afin de minimiser les d\u00e9pendances et de simplifier l'int\u00e9gration. Dans la mise en \u0153uvre initiale, nous avons utilis\u00e9 au maximum les composants standards et quelques petites modifications pour le pooling de connexions HTTP\/2 et le multiplexage de requ\u00eates.<\/p>\n<p>Pour \u00e9quilibrer entre les r\u00e9gions AWS, nous avons utilis\u00e9 une base de donn\u00e9es g\u00e9ographique DNS, la m\u00eame que celle utilis\u00e9e pour \u00e9quilibrer les clients. Pour choisir le serveur CDN pour le client, nous utilisons TCP Anycast pour les serveurs dans Internet Exchange (IX). Dans cette configuration, nous utilisons une adresse IP pour tous les serveurs CDN, tandis que le client sera dirig\u00e9 vers le serveur CDN avec le plus petit nombre de sauts IP. Sur les serveurs CDN install\u00e9s chez les fournisseurs d'acc\u00e8s Internet (FAI), nous n'avons pas le contr\u00f4le sur le routeur pour configurer TCP Anycast, donc nous appliquons <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">la m\u00eame logique<\/a><\/noindex>, selon laquelle les clients sont dirig\u00e9s vers les fournisseurs d'acc\u00e8s Internet pour le streaming vid\u00e9o.<\/p>\n<p>Ainsi, nous avons trois types de chemins pour la requ\u00eate : dans le cloud via Internet ouvert, via un serveur CDN dans l'IX ou via un serveur CDN situ\u00e9 chez le fournisseur d'acc\u00e8s Internet. Notre objectif est de comprendre quel chemin est le meilleur, et quel est l'avantage du proxy, par rapport \u00e0 la mani\u00e8re dont les requ\u00eates sont dirig\u00e9es en production. Pour cela, nous utilisons un syst\u00e8me de tests comme suit :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/51b64d5be0aaf0f141484ee0fd373396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nChacun des chemins devient une cible distincte, et nous regardons le temps que nous avons obtenu. Pour l'analyse, nous regroupons les r\u00e9sultats des proxies en un seul groupe (en choisissant le meilleur temps entre le proxy IX et le proxy ISP) et les comparons avec le temps des requ\u00eates dans le cloud sans proxy :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/ec01690f6a312e61649282b0e6208778.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComme on peut le voir, les r\u00e9sultats sont ambigus \u2014 dans la plupart des cas, le proxy offre une bonne acc\u00e9l\u00e9ration, mais il y a aussi un nombre suffisant de clients pour lesquels la situation se d\u00e9t\u00e9riorerait consid\u00e9rablement. <\/p>\n<p>En fin de compte, nous avons fait plusieurs choses importantes :<\/p>\n<ol>\n<li>Nous avons \u00e9valu\u00e9 la performance attendue des requ\u00eates des clients dans le cloud via le proxy CDN.<\/li>\n<li>Nous avons obtenu des donn\u00e9es de v\u00e9ritables clients, de tous types d'appareils.<\/li>\n<li>Nous avons compris que la th\u00e9orie ne s'est pas confirm\u00e9e \u00e0 100 % et que la proposition initiale de proxy CDN ne fonctionnera pas pour nous.<\/li>\n<li>Nous n'avons pas pris de risques \u2014 nous n'avons pas modifi\u00e9 les configurations de production pour les clients.<\/li>\n<li>Nous n'avons rien cass\u00e9. <\/li>\n<\/ol>\n<p><\/p>\n<h2>Prototype 2.0<\/h2>\n<p>\nAinsi, nous retournons au tableau noir et recommen\u00e7ons le processus.<\/p>\n<p>L'id\u00e9e est que, au lieu de 100 % de proxy, pour chaque client, nous d\u00e9finissons le chemin le plus rapide et dirigeons les requ\u00eates vers celui-ci \u2014 c'est ce qu'on appelle le client steering.<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/780817f48a4d2b292d5545e0aa1ccc50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComment la mettre en \u0153uvre ? Nous ne pouvons pas utiliser la logique c\u00f4t\u00e9 serveur, car l'objectif est de se connecter \u00e0 ce serveur. Il faut donc le faire d'une mani\u00e8re ou d'une autre c\u00f4t\u00e9 client. L'id\u00e9al serait de le r\u00e9aliser avec un minimum de logique complexe pour \u00e9viter de devoir r\u00e9soudre des probl\u00e8mes d'int\u00e9gration avec de nombreuses plateformes client. <\/p>\n<p>La r\u00e9ponse est l'utilisation de DNS. Dans notre cas, nous avons notre propre infrastructure DNS, et nous pouvons configurer une zone de domaine pour laquelle nos serveurs seront autoritatifs. Cela fonctionne comme suit :<\/p>\n<ol>\n<li>Le client effectue une requ\u00eate au serveur DNS en utilisant l'h\u00f4te, par exemple api.netflix.com.<\/li>\n<li>La requ\u00eate arrive sur notre serveur DNS<\/li>\n<li>Le serveur DNS conna\u00eet le chemin le plus rapide pour ce client et fournit l'adresse IP correspondante. <\/li>\n<\/ol>\n<p>\nIl y a une complexit\u00e9 suppl\u00e9mentaire dans la solution : les fournisseurs DNS autoritatifs ne voient pas l'adresse IP du client et ne peuvent consid\u00e9rer que l'adresse IP du r\u00e9solveur r\u00e9cursif utilis\u00e9 par le client. <\/p>\n<p>En fin de compte, notre r\u00e9solveur autoritatif doit prendre des d\u00e9cisions non pas pour un client individuel, mais pour un groupe de clients en fonction du r\u00e9solveur r\u00e9cursif. <\/p>\n<p>Pour r\u00e9soudre ce probl\u00e8me, nous utilisons les m\u00eames \u00e9chantillons, nous agr\u00e9geons les r\u00e9sultats de mesure des clients pour chaque r\u00e9solveur r\u00e9cursif et d\u00e9cidons o\u00f9 diriger ce groupe - \u00e0 travers un proxy via IX en utilisant TCP Anycast, \u00e0 travers un proxy ISP ou directement dans le cloud.<\/p>\n<p>Nous obtenons ainsi un syst\u00e8me :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/ad23219938d1cb7b6eef498671c3e151.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe mod\u00e8le de DNS steering obtenu permet de diriger les clients sur la base des observations historiques de la vitesse des connexions des clients au cloud. <\/p>\n<p>Encore une fois, la question est de savoir dans quelle mesure cette approche sera efficace ? Pour r\u00e9pondre, nous utilisons \u00e0 nouveau notre syst\u00e8me d'\u00e9chantillonnage. Ainsi, nous configurons une configuration de mise \u00e0 jour, o\u00f9 une des cibles suit la direction du DNS steering, l'autre se dirige directement vers le cloud (production actuelle).<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/ceb2ded9367ebd0aa0ede46191a89a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn d\u00e9finitive, nous comparons les r\u00e9sultats et obtenons une \u00e9valuation de l'efficacit\u00e9 :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/ca0db88461d5f2cb0f3f7c07eae14f10.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFinalement, nous avons appris plusieurs choses importantes :<\/p>\n<ol>\n<li>Nous avons \u00e9valu\u00e9 la performance attendue des requ\u00eates des clients vers le cloud en utilisant DNS Steering.<\/li>\n<li>Nous avons obtenu des donn\u00e9es de v\u00e9ritables clients, de tous types d'appareils.<\/li>\n<li>Nous avons prouv\u00e9 l'efficacit\u00e9 de l'id\u00e9e propos\u00e9e.<\/li>\n<li>Nous n'avons pas pris de risques \u2014 nous n'avons pas modifi\u00e9 les configurations de production pour les clients.<\/li>\n<li>Nous n'avons rien cass\u00e9.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Maintenant, sur la partie complexe - nous lan\u00e7ons en production.<\/h2>\n<p>\nLe plus facile est maintenant derri\u00e8re nous : nous avons un prototype fonctionnel. La partie difficile consiste d\u00e9sormais \u00e0 d\u00e9ployer la solution pour tout le trafic de Netflix, \u00e0 la rendre op\u00e9rationnelle pour 150 millions d'utilisateurs, des milliers d'appareils, des centaines de microservices et des produits et infrastructures en constante \u00e9volution. Les serveurs de Netflix re\u00e7oivent des millions de requ\u00eates par seconde, et il est facile de casser le service par une action inattentive. Parall\u00e8lement, nous souhaitons rediriger dynamiquement le trafic \u00e0 travers des milliers de serveurs CDN, sur Internet, o\u00f9 tout change et se casse constamment au pire moment. <\/p>\n<p>Et avec tout cela, l'\u00e9quipe compte 3 ing\u00e9nieurs responsables du d\u00e9veloppement, du d\u00e9ploiement et de la maintenance compl\u00e8te du syst\u00e8me.<\/p>\n<p>C'est pourquoi nous allons maintenant parler d'un sommeil calme et sain.<\/p>\n<p>Comment poursuivre le d\u00e9veloppement sans passer tout son temps \u00e0 maintenir ? Notre approche repose sur 3 principes :<\/p>\n<ol>\n<li>Nous r\u00e9duisons le potentiel d'ampleur des pannes (blast radius). <\/li>\n<li>Nous nous pr\u00e9parons aux surprises - nous nous attendons \u00e0 ce que quelque chose casse, malgr\u00e9 les tests et l'exp\u00e9rience personnelle.<\/li>\n<li>D\u00e9gradation progressive (graceful degradation) - si quelque chose ne fonctionne pas, cela doit \u00eatre r\u00e9par\u00e9 automatiquement, m\u00eame de mani\u00e8re moins efficace.<\/li>\n<\/ol>\n<p>\nIl s'est av\u00e9r\u00e9 que, dans notre cas, avec cette approche du probl\u00e8me, nous pouvons trouver une solution simple et efficace et simplifier consid\u00e9rablement la maintenance du syst\u00e8me. Nous avons compris que nous pouvions ajouter un petit morceau de code dans le client et surveiller les erreurs des requ\u00eates r\u00e9seau caus\u00e9es par des probl\u00e8mes de connexion. En cas d'erreurs r\u00e9seau, nous effectuons un fallback directement dans le cloud. Cette solution n'exige pas d'efforts significatifs de la part des \u00e9quipes clientes, mais r\u00e9duit consid\u00e9rablement les risques de pannes inattendues et de surprises pour nous.<\/p>\n<p>\u00c9videmment, malgr\u00e9 le fallback, nous suivons tout de m\u00eame une discipline stricte durant le d\u00e9veloppement :<\/p>\n<ol>\n<li>Test des \u00e9chantillons.<\/li>\n<li>Tests A\/B ou Canaries.<\/li>\n<li>D\u00e9ploiement progressif (progressive rollout).<\/li>\n<\/ol>\n<p>\nPour les \u00e9chantillons, l'approche a \u00e9t\u00e9 d\u00e9crite - les changements sont d'abord test\u00e9s \u00e0 l'aide d'une recette configur\u00e9e.<\/p>\n<p>Pour les tests canary, nous avons besoin de paires de serveurs comparables, sur lesquelles nous pouvons comparer le fonctionnement du syst\u00e8me avant et apr\u00e8s les modifications. Pour ce faire, \u00e0 partir de nos nombreux sites CDN, nous faisons un \u00e9chantillon de paires de serveurs qui re\u00e7oivent un trafic comparable :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/eef504f5c81aa985b78339fd5f913d14.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEnsuite, nous d\u00e9ployons la version modifi\u00e9e sur les serveurs Canary. Pour \u00e9valuer les r\u00e9sultats, nous ex\u00e9cutons un syst\u00e8me qui compare environ 100 \u00e0 150 m\u00e9triques \u00e0 partir d'un \u00e9chantillon de serveurs de contr\u00f4le :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/898edb0a5bd493d6ef228cd116c1a939.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi le test Canary est r\u00e9ussi, nous proc\u00e9dons au d\u00e9ploiement de mani\u00e8re progressive, par vagues. Sur chaque site, nous ne mettons pas \u00e0 jour les serveurs simultan\u00e9ment \u2014 la perte d'un site entier en cas de probl\u00e8me a un impact plus significatif sur le service pour les utilisateurs que la perte d'une quantit\u00e9 \u00e9quivalente de serveurs, mais \u00e0 diff\u00e9rents endroits.<\/p>\n<p>Dans l'ensemble, l'efficacit\u00e9 et la s\u00e9curit\u00e9 de cette approche d\u00e9pendent de la quantit\u00e9 et de la qualit\u00e9 des m\u00e9triques recueillies. Pour notre syst\u00e8me d'acc\u00e9l\u00e9ration des requ\u00eates, nous collectons des m\u00e9triques provenant de tous les composants possibles : <\/p>\n<ul>\n<li>des clients \u2014 le nombre de sessions et de requ\u00eates, les taux de secours ; <\/li>\n<li>proxy \u2014 les statistiques concernant le nombre et le temps des requ\u00eates ;<\/li>\n<li>DNS \u2014 le nombre et les r\u00e9sultats des requ\u00eates ;<\/li>\n<li>cloud edge \u2014 le nombre et le temps de traitement des requ\u00eates dans le cloud.<\/li>\n<\/ul>\n<p>\nTout cela est int\u00e9gr\u00e9 dans un pipeline unique, et, selon les besoins, nous d\u00e9cidons quelles m\u00e9triques envoyer pour l'analyse en temps r\u00e9el, et lesquelles vers Elasticsearch ou Big Data pour un diagnostic plus d\u00e9taill\u00e9.<\/p>\n<h2>Surveillance<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/ff8b00b1239a20f85e96ce23c2d7c2d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDans notre cas, nous apportons des modifications sur le chemin critique des requ\u00eates entre le client et le serveur. L'ensemble des diff\u00e9rents composants sur le client, le serveur et le chemin \u00e0 travers Internet est immense. Les modifications sur le client et le serveur se produisent en permanence \u2014 en raison du travail de dizaines d'\u00e9quipes et des changements naturels dans l'\u00e9cosyst\u00e8me. Nous sommes au milieu \u2014 lors du diagnostic des probl\u00e8mes, il y a une forte probabilit\u00e9 que nous y soyons impliqu\u00e9s. Par cons\u00e9quent, nous devons comprendre clairement comment d\u00e9finir, collecter et analyser les m\u00e9triques pour une localisation rapide des probl\u00e8mes. <\/p>\n<p>Id\u00e9alement \u2014 un acc\u00e8s complet \u00e0 tous les types de m\u00e9triques et filtres en temps r\u00e9el. Mais il y a beaucoup de m\u00e9triques, donc le co\u00fbt devient une question. Dans notre cas, nous segmentons les m\u00e9triques et les outils de d\u00e9veloppement de la mani\u00e8re suivante :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/0b4a15776f3b44331652adc14ea87390.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour la d\u00e9tection et le triage des probl\u00e8mes, nous utilisons notre propre syst\u00e8me en temps r\u00e9el \u00e0 code source ouvert <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Netflix\/atlas\">Atlas<\/a><\/noindex> et <noindex><a rel=\"nofollow\" href=\"https:\/\/netflixtechblog.com\/lumen-custom-self-service-dashboarding-for-netflix-8c56b541548c\">Lumen<\/a><\/noindex> \u2014 pour la visualisation. Il stocke des m\u00e9triques agr\u00e9g\u00e9es en m\u00e9moire, est fiable et s'int\u00e8gre \u00e0 un syst\u00e8me d'alerte. Pour la localisation et le diagnostic, nous avons acc\u00e8s aux journaux d'Elasticsearch et Kibana. Pour l'analyse statistique et la mod\u00e9lisation, nous utilisons les big data et la visualisation dans Tableau.<\/p>\n<p>Il semble qu'il soit tr\u00e8s difficile de travailler avec une telle approche. Cependant, gr\u00e2ce \u00e0 une organisation hi\u00e9rarchique des m\u00e9triques et des outils, nous pouvons rapidement analyser le probl\u00e8me, d\u00e9terminer le type de probl\u00e8me, puis approfondir les m\u00e9triques d\u00e9taill\u00e9es. En moyenne, nous mettons environ 1 \u00e0 2 minutes pour identifier la source de la panne. Ensuite, nous travaillons d\u00e9j\u00e0 avec une \u00e9quipe sp\u00e9cifique sur le diagnostic \u2014 cela peut prendre de dizaines de minutes \u00e0 plusieurs heures.<\/p>\n<p>M\u00eame si le diagnostic est rapide, nous ne voulons pas que cela se produise souvent. Id\u00e9alement, nous ne devrions recevoir des alertes critiques que lorsque cela a un impact significatif sur le service. Pour notre syst\u00e8me d'acc\u00e9l\u00e9ration des requ\u00eates, nous n'avons que 2 alertes qui nous notifieront :<\/p>\n<ul>\n<li>pourcentage de Client Fallback \u2014 \u00e9valuation du comportement des clients;<\/li>\n<li>pourcentage d'erreurs Probe \u2014 donn\u00e9es de stabilit\u00e9 des composants r\u00e9seau.<\/li>\n<\/ul>\n<p>\nCes alertes critiques surveillent si le syst\u00e8me fonctionne pour la majorit\u00e9 des utilisateurs. Nous regardons combien de clients ont utilis\u00e9 le fallback s'ils n'ont pas pu b\u00e9n\u00e9ficier de l'acc\u00e9l\u00e9ration des requ\u00eates. En moyenne, nous avons moins d'une alerte critique par semaine, bien que de nombreux changements surviennent dans le syst\u00e8me. Pourquoi cela nous suffit-il ?<\/p>\n<ol>\n<li>Il existe un fallback client si notre proxy ne fonctionne pas.<\/li>\n<li>Il y a un syst\u00e8me de steering automatique qui r\u00e9agit aux probl\u00e8mes.<\/li>\n<\/ol>\n<p>\nParlons davantage de ce dernier. Notre syst\u00e8me de probes et notre syst\u00e8me de d\u00e9tection automatique du chemin optimal pour les requ\u00eates clients vers le cloud permettent de g\u00e9rer automatiquement certains probl\u00e8mes. <\/p>\n<p>Revenons \u00e0 notre configuration des probes et aux 3 cat\u00e9gories de chemins. Au-del\u00e0 du temps de chargement, nous pouvons aussi observer la simple livraison. Si les donn\u00e9es ne peuvent pas \u00eatre charg\u00e9es, en examinant les r\u00e9sultats sur diff\u00e9rents chemins, nous pouvons d\u00e9terminer o\u00f9 et quoi s'est cass\u00e9, et si nous pouvons le r\u00e9parer automatiquement en changeant le chemin de la requ\u00eate.<\/p>\n<p>Exemples :<\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/7d935da82aaca53af87f05fbdf215c4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/f74ef9d3de953099921a68fbc65cb187.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/3c77cbd47813d3320efbf339a0690c53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCe processus peut \u00eatre automatis\u00e9. L'int\u00e9grer dans le syst\u00e8me de steering. Et l'apprendre \u00e0 r\u00e9agir aux probl\u00e8mes de performance et de fiabilit\u00e9. Si quelque chose commence \u00e0 se casser \u2014 r\u00e9agir, s'il existe une meilleure option. Dans ce cas, la r\u00e9action instantan\u00e9e n'est pas critique, gr\u00e2ce au fallback sur les clients.<\/p>\n<p>Ainsi, les principes de support du syst\u00e8me peuvent \u00eatre formul\u00e9s de la mani\u00e8re suivante :<\/p>\n<ul>\n<li>nous r\u00e9duisons l'ampleur des pannes;<\/li>\n<li>nous collectons des m\u00e9triques;<\/li>\n<li>nous r\u00e9parons automatiquement les pannes, si nous le pouvons;<\/li>\n<li>si nous ne le pouvons pas \u2014 nous notifions;<\/li>\n<li>Nous travaillons sur des tableaux de bord et un ensemble d'outils de triage pour une r\u00e9action rapide.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Le\u00e7ons tir\u00e9es<\/h2>\n<p>\nIl ne faut pas beaucoup de temps pour \u00e9crire un prototype. Dans notre cas, il \u00e9tait pr\u00eat en seulement 4 mois. Avec celui-ci, nous avons obtenu de nouvelles m\u00e9triques, et 10 mois apr\u00e8s le d\u00e9but du d\u00e9veloppement, nous avons re\u00e7u notre premier trafic de production. Ensuite, un travail p\u00e9nible et tr\u00e8s complexe a commenc\u00e9 : il a fallu progressivement industrialiser et mettre \u00e0 l'\u00e9chelle le syst\u00e8me, migrer le trafic principal et apprendre de nos erreurs. Ce processus efficace ne sera pas lin\u00e9aire \u2014 malgr\u00e9 tous les efforts, tout ne peut pas \u00eatre pr\u00e9vu. Une it\u00e9ration rapide et une r\u00e9action aux nouvelles donn\u00e9es sont beaucoup plus efficaces. <\/p>\n<p><img decoding=\"async\" alt=\"Acc\u00e9l\u00e9rons les requ\u00eates Internet et dormons en paix\" src=\"\/wp-content\/uploads\/2020\/06\/c9c182a1a4fa048b1f1b2a82a4db65e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nD'apr\u00e8s notre exp\u00e9rience, nous pouvons conseiller ce qui suit :<\/p>\n<ol>\n<li>Ne faites pas confiance \u00e0 votre intuition.\n<p>Notre intuition nous a souvent induits en erreur, malgr\u00e9 l'immense exp\u00e9rience des membres de l'\u00e9quipe. Par exemple, nous avons mal pr\u00e9dit l'acc\u00e9l\u00e9ration attendue avec l'utilisation de proxys CDN, ou le comportement de TCP Anycast.<\/li>\n<li>Obtenez des donn\u00e9es de production.\n<p>Il est important d'acc\u00e9der le plus rapidement possible \u00e0 au moins une petite quantit\u00e9 de donn\u00e9es de production. Il est pratiquement impossible d'obtenir le nombre de cas uniques, de configurations et de r\u00e9glages dans des conditions de laboratoire. Un acc\u00e8s rapide aux r\u00e9sultats permettra d'\u00eatre inform\u00e9 plus rapidement des probl\u00e8mes potentiels, pour les prendre en compte dans l'architecture du syst\u00e8me.<\/li>\n<li>Ne suivez pas les conseils et les r\u00e9sultats des autres \u2014 collectez vos propres donn\u00e9es.\n<p>Suivez les principes de collecte et d'analyse des donn\u00e9es, mais ne prenez pas aveugl\u00e9ment les r\u00e9sultats et les affirmations des autres. Vous seul pouvez savoir ce qui fonctionne pour vos utilisateurs. Vos syst\u00e8mes et vos clients peuvent \u00eatre tr\u00e8s diff\u00e9rents de ceux d'autres entreprises. Heureusement, les outils d'analyse sont maintenant facilement accessibles et faciles \u00e0 utiliser. Les r\u00e9sultats que vous obtenez peuvent ne pas correspondre \u00e0 ce que des entreprises comme Netflix, Facebook, Akamai et d'autres affirment. Dans notre cas, les performances TLS, HTTP2 ou les statistiques sur les requ\u00eates DNS diff\u00e8rent des r\u00e9sultats de Facebook, Uber, Akamai \u2014 car nous avons d'autres appareils, clients et flux de donn\u00e9es.<\/li>\n<li>Ne courez pas apr\u00e8s des tendances \u00e0 la mode sans n\u00e9cessit\u00e9 et \u00e9valuation de l'efficacit\u00e9.\n<p>Commencez par le simple. Il est pr\u00e9f\u00e9rable de cr\u00e9er un syst\u00e8me de travail simple dans un court laps de temps que de passer \u00e9norm\u00e9ment de temps \u00e0 d\u00e9velopper des composants inutiles. R\u00e9solvez des t\u00e2ches et des probl\u00e8mes qui sont importants sur la base de vos mesures et r\u00e9sultats. <\/li>\n<li>Pr\u00e9parez-vous aux nouvelles applications.\n<p>Tout comme il est difficile de pr\u00e9voir tous les probl\u00e8mes, il est tout aussi difficile d'anticiper les avantages et les applications. Prenez exemple sur les startups : leur capacit\u00e9 \u00e0 s'adapter aux besoins des clients. Dans votre cas, vous pouvez d\u00e9couvrir de nouveaux probl\u00e8mes et leurs solutions. Dans notre projet, nous avons vis\u00e9 \u00e0 r\u00e9duire la latence des requ\u00eates. Cependant, au cours de notre analyse et de nos discussions, nous avons compris que nous pouvions \u00e9galement utiliser des serveurs proxy :<\/p>\n<ul>\n<li>pour \u00e9quilibrer le trafic \u00e0 travers les r\u00e9gions AWS et r\u00e9duire les co\u00fbts ;<\/li>\n<li>pour mod\u00e9liser la stabilit\u00e9 du CDN ;<\/li>\n<li>pour configurer le DNS ;<\/li>\n<li>pour configurer le TLS\/TCP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Conclusion<\/h2>\n<p>\nDans ma pr\u00e9sentation, j'ai d\u00e9crit comment Netflix aborde le probl\u00e8me d'acc\u00e9l\u00e9ration des requ\u00eates Internet entre les clients et le cloud. Comment nous collectons des donn\u00e9es \u00e0 l'aide d'un syst\u00e8me de sondes sur les clients, et utilisons les donn\u00e9es historiques recueillies pour diriger les requ\u00eates de production des clients par le chemin le plus rapide sur Internet. Comment nous utilisons les principes de fonctionnement des protocoles r\u00e9seau, notre infrastructure CDN, notre r\u00e9seau backbone, et nos serveurs DNS pour atteindre cet objectif.<\/p>\n<p>Cependant, notre solution n'est qu'un exemple de la fa\u00e7on dont nous avons mis en \u0153uvre un tel syst\u00e8me chez Netflix. Ce qui a fonctionn\u00e9 pour nous. La partie pratique de mon expos\u00e9 pour vous concerne les principes de d\u00e9veloppement et de support que nous suivons et qui nous permettent d'obtenir de bons r\u00e9sultats.<\/p>\n<p>Notre solution \u00e0 ce probl\u00e8me peut ne pas convenir \u00e0 votre cas. Cependant, les th\u00e9ories et les principes de d\u00e9veloppement restent valables, m\u00eame si vous n'avez pas votre propre infrastructure CDN, ou si elle diff\u00e8re consid\u00e9rablement de la n\u00f4tre. <\/p>\n<p>L'importance de la vitesse des requ\u00eates pour l'entreprise demeure. M\u00eame pour un service simple, il faut faire des choix : entre les fournisseurs \u00ab cloud \u00bb, l'emplacement des serveurs, les fournisseurs de CDN et de DNS. Votre choix influencera l'efficacit\u00e9 des requ\u00eates Internet pour vos clients. Il est important que vous mesuriez et compreniez cette influence.<\/p>\n<p>Commencez par des solutions simples, prenez soin de mani\u00e8re dont vous modifiez le produit. Apprenez en cours de route et am\u00e9liorez le syst\u00e8me sur la base des donn\u00e9es de vos clients, de votre infrastructure et de votre entreprise. Pensez \u00e0 la possibilit\u00e9 de pannes inattendues lors de la conception. Ainsi, vous pourrez acc\u00e9l\u00e9rer votre processus de d\u00e9veloppement, am\u00e9liorer l'efficacit\u00e9 de la solution, \u00e9viter une surcharge de support et dormir sur vos deux oreilles.<\/p>\n<blockquote><p>Cette ann\u00e9e <noindex><a rel=\"nofollow\" href=\"http:\/\/devoops-moscow.ru\/?utm_source=habr&amp;utm_medium=506106\">la conf\u00e9rence aura lieu du 6 au 10 juillet<\/a><\/noindex> en format en ligne. Vous pourrez poser des questions \u00e0 l'un des p\u00e8res de DevOps, le m\u00eame John Willis !<\/p><\/blockquote>\n<p>Source : <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\/fr\/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=\"fr_FR\" \/>\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\/fr\/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\udd47Nous acc\u00e9l\u00e9rons vos requ\u00eates Internet et vous dormez tranquille | ProHoster","description":"Netflix est le leader du march\u00e9 de la t\u00e9l\u00e9vision sur Internet.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/84876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=84876"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/84876\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/84877"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=84876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=84876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=84876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}