Netflix est le leader du marché de la télévision sur Internet - la société qui a créé et développe activement ce segment. Netflix est connu non seulement pour son vaste catalogue de films et de séries télévisées disponibles dans presque tous les coins de la planète et sur tout appareil doté d'un écran, mais également pour son infrastructure fiable et sa culture d'ingénierie unique.
Un exemple clair de l'approche de Netflix en matière de développement et de prise en charge de systèmes complexes a été présenté lors de DevOops 2019. - Directeur du développement chez Netflix. Diplômé de la Faculté de mathématiques computationnelles et de mathématiques de l'Université d'État de Nijni Novgorod. Lobatchevski, Sergey, l'un des premiers ingénieurs de l'équipe Open Connect - CDN de Netflix. Il a construit des systèmes de surveillance et d'analyse des données vidéo, lancé un service populaire d'évaluation de la vitesse de connexion Internet FAST.com et a travaillé ces dernières années sur l'optimisation des requêtes Internet afin que l'application Netflix fonctionne le plus rapidement possible pour les utilisateurs.
Le rapport a reçu les meilleures critiques de la part des participants à la conférence et nous avons préparé une version texte pour vous.
Dans son rapport, Sergei a parlé en détail
- sur ce qui affecte le délai des requêtes Internet entre le client et le serveur ;
- comment réduire ce délai ;
- comment concevoir, maintenir et surveiller des systèmes tolérants aux erreurs ;
- comment obtenir des résultats en peu de temps et avec un risque minimal pour l'entreprise ;
- comment analyser les résultats et apprendre de ses erreurs.
Les réponses à ces questions ne sont pas seulement nécessaires à ceux qui travaillent dans les grandes entreprises.
Les principes et techniques présentés doivent être connus et mis en pratique par tous ceux qui développent et prennent en charge des produits Internet.
Vient ensuite la narration du point de vue de l’orateur.
L’importance de la vitesse Internet
La vitesse des requêtes Internet est directement liée aux affaires. Considérez le secteur du shopping : Amazon en 2009 qu'un retard de 100 ms entraîne une perte de 1% des ventes.
Il existe de plus en plus d’appareils mobiles, suivis par les sites et applications mobiles. Si le chargement de votre page prend plus de 3 secondes, vous perdez environ la moitié de vos utilisateurs. AVEC Google prend en compte la vitesse de chargement de votre page dans les résultats de recherche : plus la page est rapide, plus sa position est élevée dans Google.
La vitesse de connexion est également importante dans les institutions financières où la latence est critique. En 2015, Réseaux Hibernia un câble de 400 millions de dollars entre New York et Londres pour réduire la latence entre les villes de 6 ms. Imaginez 66 millions de dollars pour 1 ms de réduction de latence !
selon , les vitesses de connexion supérieures à 5 Mbit/s n’affectent plus directement la vitesse de chargement d’un site Web classique. Cependant, il existe une relation linéaire entre la latence de connexion et la vitesse de chargement des pages :
Cependant, Netflix n’est pas un produit typique. L'impact de la latence et de la vitesse sur l'utilisateur est un domaine actif d'analyse et de développement. Le chargement des applications et la sélection du contenu dépendent de la latence, mais le chargement des éléments statiques et le streaming dépendent également de la vitesse de connexion. L'analyse et l'optimisation des facteurs clés qui influencent l'expérience utilisateur sont un domaine de développement actif pour plusieurs équipes de Netflix. L'un des objectifs est de réduire la latence des requêtes entre les appareils Netflix et l'infrastructure cloud.
Dans le rapport, nous nous concentrerons spécifiquement sur la réduction de la latence en utilisant l'exemple de l'infrastructure Netflix. Considérons d'un point de vue pratique comment aborder les processus de conception, de développement et d'exploitation de systèmes distribués complexes et consacrer du temps à l'innovation et aux résultats, plutôt que de diagnostiquer les problèmes opérationnels et les pannes.
À l'intérieur de Netflix
Des milliers d'appareils différents prennent en charge les applications Netflix. Ils sont développés par quatre équipes différentes, qui créent des versions distinctes du client pour Android, iOS, TV et navigateurs Web. Et nous consacrons beaucoup d’efforts à l’amélioration et à la personnalisation de l’expérience utilisateur. Pour ce faire, nous effectuons des centaines de tests A/B en parallèle.
La personnalisation est prise en charge par des centaines de microservices dans le cloud AWS, fournissant des données utilisateur personnalisées, l'envoi de requêtes, la télémétrie, le Big Data et l'encodage. La visualisation du trafic ressemble à ceci :
Sur la gauche se trouve le point d'entrée, puis le trafic est réparti entre plusieurs centaines de microservices pris en charge par différentes équipes backend.
Un autre composant important de notre infrastructure est le CDN Open Connect, qui fournit du contenu statique à l'utilisateur final - vidéos, images, code client, etc. Le CDN est localisé sur des serveurs personnalisés (OCA - Open Connect Appliance). À l’intérieur se trouvent des baies de disques SSD et HDD exécutant FreeBSD optimisé, avec NGINX et un ensemble de services. Nous concevons et optimisons les composants matériels et logiciels afin qu'un tel serveur CDN puisse envoyer autant de données que possible aux utilisateurs.
Le « mur » de ces serveurs au point d'échange de trafic Internet (Internet eXchange - IX) ressemble à ceci :
Internet Exchange offre la possibilité aux fournisseurs de services Internet et aux fournisseurs de contenu de se « connecter » les uns aux autres pour échanger plus directement des données sur Internet. Il existe environ 70 à 80 points d'échange Internet dans le monde où nos serveurs sont installés, et nous les installons et les entretenons de manière indépendante :
De plus, nous fournissons également des serveurs directement aux fournisseurs Internet, qu'ils installent dans leur réseau, améliorant ainsi la localisation du trafic Netflix et la qualité du streaming pour les utilisateurs :
Un ensemble de services AWS est chargé de distribuer les demandes vidéo des clients vers les serveurs CDN, ainsi que de configurer les serveurs eux-mêmes - mise à jour du contenu, du code du programme, des paramètres, etc. Pour ces derniers, nous avons également construit un réseau fédérateur qui connecte les serveurs des points d'échange Internet avec AWS. Le réseau fédérateur est un réseau mondial de câbles et de routeurs à fibre optique que nous pouvons concevoir et configurer en fonction de nos besoins.
Sur , notre infrastructure CDN fournit environ ⅛ du trafic Internet mondial aux heures de pointe et ⅓ du trafic en Amérique du Nord, où Netflix est présent le plus longtemps. Des chiffres impressionnants, mais pour moi l’une des réalisations les plus étonnantes est que l’ensemble du système CDN est développé et maintenu par une équipe de moins de 150 personnes.
Initialement, l'infrastructure CDN a été conçue pour fournir des données vidéo. Cependant, au fil du temps, nous avons réalisé que nous pouvions également l'utiliser pour optimiser les demandes dynamiques des clients dans le cloud AWS.
À propos de l'accélération Internet
Aujourd'hui, Netflix dispose de 3 régions AWS, et la latence des requêtes vers le cloud dépendra de la distance entre le client et la région la plus proche. Dans le même temps, nous disposons de nombreux serveurs CDN utilisés pour diffuser du contenu statique. Existe-t-il un moyen d'utiliser ce framework pour accélérer les requêtes dynamiques ? Malheureusement, il est impossible de mettre en cache ces requêtes : les API sont personnalisées et chaque résultat est unique.
Créons un proxy sur le serveur CDN et commençons à envoyer du trafic via celui-ci. Est-ce que ce sera plus rapide ?
Matériel
Rappelons comment fonctionnent les protocoles réseau. Aujourd'hui, la plupart du trafic sur Internet utilise HTTP, qui dépend des protocoles de couche inférieure TCP et TLS. Pour qu'un client se connecte au serveur, il effectue une poignée de main et pour établir une connexion sécurisée, le client doit échanger des messages avec le serveur trois fois et au moins une fois de plus pour transférer des données. Avec une latence par aller-retour (RTT) de 100 ms, il nous faudrait 400 ms pour recevoir le premier bit de données :
Si nous plaçons les certificats sur le serveur CDN, le temps de négociation entre le client et le serveur peut être considérablement réduit si le CDN est plus proche. Supposons que la latence du serveur CDN soit de 30 ms. Il faudra ensuite 220 ms pour recevoir le premier bit :
Mais les avantages ne s'arrêtent pas là. Une fois la connexion établie, TCP augmente la fenêtre de congestion (la quantité d'informations qu'il peut transmettre en parallèle sur cette connexion). Si un paquet de données est perdu, les implémentations classiques du protocole TCP (comme TCP New Reno) réduisent de moitié la « fenêtre » ouverte. La croissance de la fenêtre de congestion et la vitesse de sa récupération après une perte dépendent à nouveau du délai (RTT) vers le serveur. Si cette connexion ne va que jusqu'au serveur CDN, cette récupération sera plus rapide. Dans le même temps, la perte de paquets est un phénomène courant, notamment pour les réseaux sans fil.
La bande passante Internet peut être réduite, notamment aux heures de pointe, en raison du trafic des utilisateurs, ce qui peut entraîner des embouteillages. Cependant, il n’existe aucun moyen sur Internet de donner la priorité à certaines demandes par rapport à d’autres. Par exemple, donnez la priorité aux petites requêtes sensibles à la latence par rapport aux flux de données « lourds » qui chargent le réseau. Cependant, dans notre cas, disposer de notre propre réseau fédérateur nous permet de le faire sur une partie du chemin de requête - entre le CDN et le cloud, et nous pouvons le configurer entièrement. Vous pouvez vous assurer que les petits paquets sensibles à la latence sont prioritaires et que les flux de données volumineux sont envoyés un peu plus tard. Plus le CDN est proche du client, plus l’efficacité est grande.
Les protocoles au niveau application (OSI niveau 7) ont également un impact sur la latence. De nouveaux protocoles tels que HTTP/2 optimisent les performances des requêtes parallèles. Cependant, nous avons des clients Netflix avec des appareils plus anciens qui ne prennent pas en charge les nouveaux protocoles. Tous les clients ne peuvent pas être mis à jour ou configurés de manière optimale. Dans le même temps, entre le proxy CDN et le cloud, il existe un contrôle complet et la possibilité d'utiliser de nouveaux protocoles et paramètres optimaux. La partie inefficace avec les anciens protocoles ne fonctionnera qu'entre le client et le serveur CDN. De plus, nous pouvons effectuer des requêtes multiplex sur une connexion déjà établie entre le CDN et le cloud, améliorant ainsi l'utilisation de la connexion au niveau TCP :
Nous mesurons
Malgré le fait que la théorie promet des améliorations, nous ne nous précipitons pas immédiatement pour lancer le système en production. Au lieu de cela, nous devons d’abord prouver que l’idée fonctionnera dans la pratique. Pour ce faire, vous devez répondre à plusieurs questions :
- vitesse: un proxy sera-t-il plus rapide ?
- Fiabilité: Est-ce que ça va casser plus souvent ?
- Complexité: comment intégrer les applications ?
- coût de: Combien coûte le déploiement d’une infrastructure supplémentaire ?
Examinons en détail notre approche pour évaluer le premier point. Le reste est traité de la même manière.
Pour analyser la vitesse des requêtes, nous souhaitons obtenir des données pour tous les utilisateurs, sans passer beaucoup de temps en développement et sans interrompre la production. Il existe plusieurs approches pour cela :
- RUM, ou mesure de requête passive. Nous mesurons le temps d’exécution des demandes en cours des utilisateurs et garantissons une couverture complète des utilisateurs. L'inconvénient est que le signal n'est pas très stable en raison de nombreux facteurs, par exemple en raison des différentes tailles de requêtes et du temps de traitement sur le serveur et le client. De plus, vous ne pouvez pas tester une nouvelle configuration sans effet en production.
- Tests de laboratoire. Serveurs spéciaux et infrastructure qui simulent les clients. Avec leur aide, nous effectuons les tests nécessaires. De cette façon, nous obtenons un contrôle total sur les résultats de mesure et un signal clair. Mais il n’existe pas de couverture complète des appareils et des emplacements des utilisateurs (en particulier avec un service mondial et une prise en charge de milliers de modèles d’appareils).
Comment combiner les avantages des deux méthodes ?
Notre équipe a trouvé une solution. Nous avons écrit un petit morceau de code - un exemple - que nous avons intégré à notre application. Les sondes nous permettent d'effectuer des tests réseau entièrement contrôlés à partir de nos appareils. Cela fonctionne comme ceci :
- Peu de temps après avoir chargé l'application et terminé l'activité initiale, nous exécutons nos sondes.
- Le client fait une requête au serveur et reçoit une « recette » pour le test. La recette est une liste d'URL auxquelles une requête HTTP(s) doit être effectuée. De plus, la recette configure les paramètres de la requête : délais entre les requêtes, quantité de données demandées, en-têtes HTTP(s), etc. Dans le même temps, nous pouvons tester plusieurs recettes différentes en parallèle - lors d'une demande de configuration, nous déterminons au hasard quelle recette émettre.
- L'heure de lancement de la sonde est choisie de manière à ne pas entrer en conflit avec l'utilisation active des ressources réseau sur le client. Essentiellement, l'heure est sélectionnée lorsque le client n'est pas actif.
- Après avoir reçu la recette, le client fait des requêtes à chacune des URL, en parallèle. La demande à chacune des adresses peut être répétée - ce qu'on appelle. "impulsions". À la première impulsion, nous mesurons le temps nécessaire pour établir une connexion et télécharger les données. Lors de la deuxième impulsion, nous mesurons le temps nécessaire pour charger les données via une connexion déjà établie. Avant le troisième, on peut fixer un délai et mesurer la vitesse d'établissement d'une reconnexion, etc.
Lors du test, nous mesurons tous les paramètres que l'appareil peut obtenir :
- Temps de requête DNS ;
- Temps d'établissement de la connexion TCP ;
- Temps de configuration de la connexion TLS ;
- heure de réception du premier octet de données ;
- temps de chargement total ;
- code de résultat d’état.
- Une fois toutes les impulsions terminées, l'échantillon charge toutes les mesures pour analyse.
Les points clés sont une dépendance minimale à la logique du client, le traitement des données sur le serveur et la mesure des requêtes parallèles. Ainsi, nous sommes en mesure d'isoler et de tester l'influence de divers facteurs affectant les performances des requêtes, de les faire varier au sein d'une seule recette et d'obtenir des résultats auprès de clients réels.
Cette infrastructure s'est avérée utile pour bien plus que la simple analyse des performances des requêtes. Actuellement, nous avons 14 recettes actives, plus de 6000 XNUMX échantillons par seconde, recevant des données de tous les coins du monde et une couverture complète des appareils. Si Netflix achetait un service similaire auprès d’un tiers, cela coûterait des millions de dollars par an, avec une couverture bien pire.
Théorie des tests en pratique : prototype
Avec un tel système, nous avons pu évaluer l’efficacité des proxys CDN sur la latence des requêtes. Il vous faut maintenant :
- créer un prototype de proxy ;
- placer le prototype sur un CDN ;
- déterminer comment diriger les clients vers un proxy sur un serveur CDN spécifique ;
- Comparez les performances aux requêtes dans AWS sans proxy.
La tâche consiste à évaluer le plus rapidement possible l'efficacité de la solution proposée. Nous avons choisi Go pour implémenter le prototype en raison de la disponibilité de bonnes bibliothèques réseau. Sur chaque serveur CDN, nous avons installé le prototype de proxy sous forme de binaire statique pour minimiser les dépendances et simplifier l'intégration. Dans la mise en œuvre initiale, nous avons utilisé autant que possible des composants standard et des modifications mineures pour le pooling de connexions HTTP/2 et le multiplexage des requêtes.
Pour équilibrer entre les régions AWS, nous avons utilisé une base de données DNS géographique, la même que celle utilisée pour équilibrer les clients. Pour sélectionner un serveur CDN pour le client, nous utilisons TCP Anycast pour les serveurs Internet Exchange (IX). Dans cette option, nous utilisons une adresse IP pour tous les serveurs CDN et le client sera dirigé vers le serveur CDN avec le moins de sauts IP. Dans les serveurs CDN installés par les fournisseurs Internet (FAI), nous n'avons aucun contrôle sur le routeur pour configurer TCP Anycast, nous utilisons donc , qui oriente les clients vers les fournisseurs Internet pour le streaming vidéo.
Nous avons donc trois types de chemins de requête : vers le cloud via l'Internet ouvert, via un serveur CDN dans IX, ou via un serveur CDN situé chez un fournisseur Internet. Notre objectif est de comprendre quelle est la meilleure méthode et quel est l'avantage d'un proxy par rapport à la manière dont les demandes sont envoyées en production. Pour ce faire, nous utilisons un système d'échantillonnage comme suit :
Chacun des chemins devient une cible distincte et nous regardons le temps que nous avons obtenu. Pour l'analyse, nous combinons les résultats du proxy en un seul groupe (sélectionnons le meilleur moment entre les proxys IX et FAI) et les comparons avec le temps des requêtes vers le cloud sans proxy :
Comme vous pouvez le constater, les résultats ont été mitigés - dans la plupart des cas, le proxy donne une bonne accélération, mais il existe également un nombre suffisant de clients pour lesquels la situation va considérablement se détériorer.
En conséquence, nous avons fait plusieurs choses importantes :
- Nous avons évalué les performances attendues des requêtes des clients vers le cloud via un proxy CDN.
- Nous avons reçu des données de clients réels, provenant de tous types d'appareils.
- Nous avons réalisé que la théorie n'était pas confirmée à 100 % et que l'offre initiale avec un proxy CDN ne fonctionnerait pas pour nous.
- Nous n'avons pas pris de risques, nous n'avons pas modifié les configurations de production pour les clients.
- Rien n'était cassé.
Prototype 2.0
Alors, revenons à la planche à dessin et répétez le processus à nouveau.
L'idée est qu'au lieu d'utiliser un proxy à 100 %, nous déterminerons le chemin le plus rapide pour chaque client et nous y enverrons des requêtes - c'est-à-dire que nous ferons ce qu'on appelle le pilotage client.
Comment mettre en œuvre cela ? Nous ne pouvons pas utiliser la logique côté serveur, car... Le but est de se connecter à ce serveur. Il doit y avoir un moyen de faire cela sur le client. Et idéalement, faites-le avec un minimum de logique complexe, afin de ne pas résoudre le problème de l'intégration avec un grand nombre de plateformes clientes.
La réponse est d'utiliser le DNS. Dans notre cas, nous disposons de notre propre infrastructure DNS, et nous pouvons mettre en place une zone de domaine pour laquelle nos serveurs seront autoritaires. Cela fonctionne comme ceci :
- Le client fait une requête au serveur DNS à l'aide d'un hôte, par exemple api.netflix.xom.
- La requête arrive sur notre serveur DNS
- Le serveur DNS sait quel chemin est le plus rapide pour ce client et attribue l'adresse IP correspondante.
La solution présente une complexité supplémentaire : les fournisseurs DNS autoritaires ne voient pas l'adresse IP du client et ne peuvent lire que l'adresse IP du résolveur récursif utilisé par le client.
En conséquence, notre résolveur autoritaire doit prendre une décision non pas pour un client individuel, mais pour un groupe de clients basé sur le résolveur récursif.
Pour résoudre, nous utilisons les mêmes échantillons, regroupons les résultats de mesure des clients pour chacun des résolveurs récursifs et décidons où envoyer ce groupe d'entre eux - un proxy via IX en utilisant TCP Anycast, via un proxy FAI ou directement vers le cloud.
On obtient le système suivant :
Le modèle de pilotage DNS qui en résulte vous permet de diriger les clients sur la base d'observations historiques de la vitesse des connexions des clients au cloud.
Encore une fois, la question est de savoir dans quelle mesure cette approche fonctionnera efficacement ? Pour répondre, nous utilisons à nouveau notre système de sonde. Par conséquent, nous configurons la configuration du présentateur, où l'une des cibles suit la direction du pilotage DNS, l'autre va directement vers le cloud (production actuelle).
En conséquence, nous comparons les résultats et obtenons une évaluation de l'efficacité :
En conséquence, nous avons appris plusieurs choses importantes :
- Nous avons évalué les performances attendues des requêtes des clients vers le cloud à l'aide de DNS Steering.
- Nous avons reçu des données de clients réels, provenant de tous types d'appareils.
- L'efficacité de l'idée proposée a été prouvée.
- Nous n'avons pas pris de risques, nous n'avons pas modifié les configurations de production pour les clients.
- Rien n'était cassé.
Parlons maintenant de la partie difficile : nous la lançons en production
La partie la plus facile est maintenant terminée : il existe un prototype fonctionnel. Le plus difficile est désormais de lancer une solution pour tout le trafic de Netflix, en la déployant auprès de 150 millions d'utilisateurs, de milliers d'appareils, de centaines de microservices et d'un produit et d'une infrastructure en constante évolution. Les serveurs Netflix reçoivent des millions de requêtes par seconde et il est facile de rompre le service par une action imprudente. Dans le même temps, nous souhaitons acheminer dynamiquement le trafic via des milliers de serveurs CDN sur Internet, où quelque chose change et se brise constamment et au moment le plus inopportun.
Et avec tout cela, l'équipe compte 3 ingénieurs responsables du développement, du déploiement et du support complet du système.
Nous continuerons donc à parler de sommeil réparateur et sain.
Comment continuer le développement et ne pas passer tout son temps sur le support ? Notre approche repose sur 3 principes :
- Nous réduisons l'ampleur potentielle des pannes (rayon de souffle).
- Nous nous préparons à des surprises - nous nous attendons à ce que quelque chose se brise, malgré les tests et l'expérience personnelle.
- Dégradation progressive : si quelque chose ne fonctionne pas correctement, il doit être corrigé automatiquement, même si ce n'est pas de la manière la plus efficace.
Il s'est avéré que dans notre cas, avec cette approche du problème, nous pouvons trouver une solution simple et efficace et simplifier considérablement la prise en charge du système. Nous avons réalisé que nous pouvions ajouter un petit morceau de code au client et surveiller les erreurs de requête réseau causées par des problèmes de connexion. En cas d'erreurs réseau, nous effectuons un repli directement vers le cloud. Cette solution ne nécessite pas d’efforts importants pour les équipes clients, mais réduit considérablement les risques de pannes inattendues et de surprises pour nous.
Bien entendu, malgré le repli, nous suivons néanmoins une discipline claire lors du développement :
- Échantillon test.
- Tests A/B ou Canaries.
- Déploiement progressif.
L'approche a été décrite à l'aide d'échantillons : les modifications sont d'abord testées à l'aide d'une recette personnalisée.
Pour les tests Canary, nous devons obtenir des paires de serveurs comparables sur lesquelles nous pouvons comparer le fonctionnement du système avant et après les modifications. Pour ce faire, parmi nos nombreux sites CDN, nous sélectionnons des paires de serveurs qui reçoivent un trafic comparable :
Ensuite, nous installons la build avec les modifications sur le serveur Canary. Pour évaluer les résultats, nous exécutons un système qui compare environ 100 à 150 métriques avec un échantillon de serveurs de contrôle :
Si les tests Canary réussissent, nous les publions progressivement, par vagues. Nous ne mettons pas à jour les serveurs de chaque site en même temps : la perte d'un site entier en raison de problèmes a un impact plus important sur le service pour les utilisateurs que la perte du même nombre de serveurs dans différents emplacements.
En général, l'efficacité et la sécurité de cette approche dépendent de la quantité et de la qualité des métriques collectées. Pour notre système d'accélération des requêtes, nous collectons des métriques à partir de tous les composants possibles :
- des clients - nombre de sessions et de demandes, taux de repli ;
- proxy - statistiques sur le nombre et l'heure des demandes ;
- DNS - nombre et résultats des requêtes ;
- cloud edge - nombre et heure de traitement des demandes dans le cloud.
Tout cela est collecté dans un seul pipeline et, en fonction des besoins, nous décidons quelles métriques envoyer aux analyses en temps réel et lesquelles à Elasticsearch ou Big Data pour des diagnostics plus détaillés.
Nous surveillons
Dans notre cas, nous apportons des modifications sur le chemin critique des requêtes entre le client et le serveur. Dans le même temps, le nombre de composants différents sur le client, sur le serveur et sur Internet est énorme. Des changements sur le client et le serveur se produisent constamment - au cours du travail de dizaines d'équipes et des changements naturels de l'écosystème. Nous sommes au milieu : lors du diagnostic des problèmes, il y a de fortes chances que nous soyons impliqués. Par conséquent, nous devons clairement comprendre comment définir, collecter et analyser des métriques pour isoler rapidement les problèmes.
Idéalement, un accès complet à tous les types de métriques et de filtres en temps réel. Mais il existe de nombreux paramètres, donc la question du coût se pose. Dans notre cas, nous séparons les métriques et les outils de développement comme suit :
Pour détecter et trier les problèmes, nous utilisons notre propre système temps réel open source и - pour la visualisation. Il stocke les métriques agrégées en mémoire, est fiable et s'intègre au système d'alerte. Pour la localisation et les diagnostics, nous avons accès aux journaux d'Elasticsearch et de Kibana. Pour l'analyse statistique et la modélisation, nous utilisons le Big Data et la visualisation dans Tableau.
Il semble que cette approche soit très difficile à appliquer. Cependant, en organisant les métriques et les outils de manière hiérarchique, nous pouvons rapidement analyser un problème, déterminer le type de problème, puis explorer des métriques détaillées. En général, nous passons environ 1 à 2 minutes pour identifier la source de la panne. Ensuite, nous travaillons avec une équipe spécifique sur le diagnostic - de quelques dizaines de minutes à plusieurs heures.
Même si le diagnostic est posé rapidement, nous ne voulons pas que cela arrive souvent. Idéalement, nous ne recevrons une alerte critique qu’en cas d’impact significatif sur le service. Pour notre système d'accélération des requêtes, nous n'avons que 2 alertes qui notifieront :
- Pourcentage de repli client - évaluation du comportement du client ;
- pourcentage d'erreurs de sonde - données de stabilité des composants du réseau.
Ces alertes critiques vérifient si le système fonctionne pour la majorité des utilisateurs. Nous examinons combien de clients ont utilisé la solution de repli s'ils ne parvenaient pas à obtenir une accélération des requêtes. Nous recevons en moyenne moins d’une alerte critique par semaine, même si de nombreux changements sont en cours dans le système. Pourquoi est-ce suffisant pour nous ?
- Il existe une solution de secours pour le client si notre proxy ne fonctionne pas.
- Il existe un système de direction automatique qui répond aux problèmes.
Plus de détails sur ce dernier. Notre système d'essai et le système de détermination automatique du chemin optimal pour les requêtes du client vers le cloud nous permettent de résoudre automatiquement certains problèmes.
Revenons à notre exemple de configuration et à nos 3 catégories de chemins. En plus du temps de chargement, nous pouvons examiner le fait de la livraison elle-même. S'il n'a pas été possible de charger les données, en examinant les résultats selon différents chemins, nous pouvons déterminer où et ce qui s'est cassé, et si nous pouvons le réparer automatiquement en modifiant le chemin de la requête.
Exemples:
Ce processus peut être automatisé. Incluez-le dans le système de direction. Et apprenez-lui à répondre aux problèmes de performances et de fiabilité. Si quelque chose commence à se briser, réagissez s'il existe une meilleure option. Dans le même temps, une réaction immédiate n’est pas critique, grâce au recours aux clients.
Ainsi, les principes du support système peuvent être formulés comme suit :
- réduire l'ampleur des pannes ;
- collecter des mesures ;
- Nous réparons automatiquement les pannes si nous le pouvons ;
- si ce n’est pas le cas, nous vous en informons ;
- Nous travaillons sur des tableaux de bord et un ensemble d'outils de triage pour une réponse rapide.
Leçons apprises
Il ne faut pas beaucoup de temps pour écrire un prototype. Dans notre cas, c'était prêt au bout de 4 mois. Grâce à cela, nous avons reçu de nouvelles mesures et 10 mois après le début du développement, nous avons reçu le premier trafic de production. Puis le travail fastidieux et très difficile a commencé : produire et faire évoluer progressivement le système, migrer le trafic principal et apprendre de ses erreurs. Cependant, ce processus efficace ne sera pas linéaire : malgré tous les efforts, tout ne peut pas être prédit. Il est beaucoup plus efficace d’itérer et de répondre rapidement aux nouvelles données.
Sur la base de notre expérience, nous pouvons recommander ce qui suit :
- Ne faites pas confiance à votre intuition.
Notre intuition nous a constamment fait défaut, malgré la vaste expérience des membres de notre équipe. Par exemple, nous avons prédit de manière incorrecte l'accélération attendue grâce à l'utilisation d'un proxy CDN ou le comportement de TCP Anycast.
- Obtenez des données de production.
Il est important d’avoir accès le plus rapidement possible à au moins une petite quantité de données de production. Il est presque impossible d’obtenir le nombre de cas, de configurations et de réglages uniques dans des conditions de laboratoire. Un accès rapide aux résultats vous permettra de connaître rapidement les problèmes potentiels et de les prendre en compte dans l'architecture du système.
- Ne suivez pas les conseils et les résultats des autres – collectez vos propres données.
Suivez les principes de collecte et d'analyse des données, mais n'acceptez pas aveuglément les résultats et les déclarations des autres. Vous seul pouvez savoir exactement ce qui fonctionne pour vos utilisateurs. Vos systèmes et vos clients peuvent être très différents de ceux d’autres entreprises. Heureusement, des outils d’analyse sont désormais disponibles et faciles à utiliser. Les résultats que vous obtenez ne correspondent peut-être pas à ceux que prétendent Netflix, Facebook, Akamai et d’autres sociétés. Dans notre cas, les performances de TLS, HTTP2 ou les statistiques sur les requêtes DNS diffèrent des résultats de Facebook, Uber, Akamai - car nous avons des appareils, des clients et des flux de données différents.
- Ne suivez pas inutilement les tendances de la mode et évaluez l'efficacité.
Commencez simplement. Il est préférable de créer un système fonctionnel simple en peu de temps plutôt que de passer énormément de temps à développer des composants dont vous n'avez pas besoin. Résolvez les tâches et les problèmes importants en fonction de vos mesures et de vos résultats.
- Préparez-vous à de nouvelles applications.
Tout comme il est difficile de prévoir tous les problèmes, il est difficile de prédire à l’avance les avantages et les applications. Inspirez-vous des startups : leur capacité à s’adapter aux conditions des clients. Dans votre cas, vous découvrirez peut-être de nouveaux problèmes et leurs solutions. Dans notre projet, nous nous sommes fixés pour objectif de réduire la latence des requêtes. Cependant, au cours de l’analyse et des discussions, nous nous sommes rendu compte que nous pouvions également utiliser des serveurs proxy :
- pour équilibrer le trafic entre les régions AWS et réduire les coûts ;
- pour modéliser la stabilité du CDN ;
- pour configurer DNS ;
- pour configurer TLS/TCP.
Conclusion
Dans le rapport, j'ai décrit comment Netflix résout le problème de l'accélération des requêtes Internet entre les clients et le cloud. Comment nous collectons des données à l'aide d'un système d'échantillonnage sur les clients et utilisons les données historiques collectées pour acheminer les demandes de production des clients via le chemin le plus rapide sur Internet. Comment nous utilisons les principes des protocoles réseau, notre infrastructure CDN, notre réseau fédérateur et nos serveurs DNS pour accomplir cette tâche.
Cependant, notre solution n’est qu’un exemple de la manière dont Netflix a mis en œuvre un tel système. Ce qui a fonctionné pour nous. La partie appliquée de mon rapport pour vous concerne les principes de développement et de soutien que nous suivons et obtenons de bons résultats.
Notre solution au problème peut ne pas vous convenir. Cependant, la théorie et les principes de conception demeurent, même si vous ne disposez pas de votre propre infrastructure CDN, ou si celle-ci diffère sensiblement de la nôtre.
L’importance de la rapidité des demandes commerciales reste également importante. Et même pour un service simple, vous devez faire un choix : entre les fournisseurs de cloud, l'emplacement du serveur, les fournisseurs CDN et DNS. Votre choix influencera l’efficacité des requêtes Internet pour vos clients. Et il est important que vous mesuriez et compreniez cette influence.
Commencez par des solutions simples, faites attention à la façon dont vous modifiez le produit. Apprenez au fur et à mesure et améliorez le système en fonction des données de vos clients, de votre infrastructure et de votre entreprise. Pensez à la possibilité de pannes inattendues pendant le processus de conception. Vous pourrez alors accélérer votre processus de développement, améliorer l’efficacité de votre solution, éviter une charge de support inutile et dormir paisiblement.
Cette année, au format en ligne. Vous pouvez poser des questions à l’un des pères du DevOps, John Willis lui-même !
Source: habr.com