Livre «Site Reliability Engineering. Fiabilité et fiabilité comme dans Google »

Depuis près de 20 ans, Google propose des systèmes à grande échelle d'une complexité inimaginable et sensibles aux demandes des utilisateurs. Le moteur de recherche Google trouve la réponse à toutes vos questions en une fraction de seconde, les cartes Google avec la plus grande précision reflètent le paysage terrestre, et la messagerie Google est disponible en mode 365/24/7 et, en substance, est devenue le premier stockage cloud public. Ces systèmes sont-ils parfaits? Non, ils échouent également, tombent en panne et deviennent obsolètes, comme tout équipement. Nous ne le remarquons tout simplement pas. Le fait est que depuis plus de dix ans, Google développe la technologie unique d'Ingénierie de la fiabilité du site, qui garantit un fonctionnement ininterrompu et un développement progressif de systèmes logiciels de toute complexité. Ce livre est un magasin d'expérience accumulé par Google au fil des ans, le travail collectif de nombreux spécialistes exceptionnels et une ressource indispensable pour tout ingénieur qui souhaite développer et entretenir des produits de la plus haute qualité et de la manière la plus efficace.

SRE de Google en termes de SRE

Les centres de données Google (centres de données) sont très différents des centres de données traditionnels et des "fermes" de petits serveurs. Ces différences introduisent à la fois des problèmes et des opportunités supplémentaires. Ce chapitre traite des défis et opportunités spécifiques aux centres de données Google et présente la terminologie qui sera utilisée tout au long du livre.

Équipement

La plupart des ressources informatiques de Google sont situées dans des centres de données conçus par l'entreprise, qui disposent de leur propre système d'alimentation, système de refroidissement, réseau interne et équipement informatique [Barroso et al., 2013]. Contrairement aux centres de données classiques fournis par les fournisseurs à leurs clients, tous les centres de données Google sont équipés du même1. Pour éviter toute confusion entre le matériel du serveur et le logiciel du serveur, dans ce livre, nous utilisons la terminologie suivante:

• machine (ordinateur) - une unité d'équipement (ou, éventuellement, une machine virtuelle);
• serveur - une unité de logiciel qui implémente un service.

Tout serveur peut être démarré sur des machines, par conséquent, nous n'allouons pas d'ordinateurs spécifiques à des programmes de serveur spécifiques. Par exemple, nous n'avons pas de machine spécifique sur laquelle le serveur de messagerie s'exécute. Au lieu de cela, les ressources sont allouées par notre système de gestion de cluster Borg.

Nous comprenons qu'une telle utilisation du terme «serveur» n'est pas standard. Il est plus habituel de désigner deux concepts à la fois: un programme qui sert des connexions réseau et en même temps une machine qui exécute de tels programmes, mais lorsque nous parlons de la puissance de calcul de Google, la différence entre les deux est significative. Dès que vous vous habituerez à notre interprétation du mot «serveur», vous comprendrez pourquoi il est important d'utiliser une terminologie spécialisée non seulement directement chez Google, mais tout au long de ce livre.

Dans la fig. 2.1 a démontré la configuration du centre de données Google.

• Des dizaines de voitures sont placées sur des supports.
• Les racks se tiennent en rangées.
• Une ou plusieurs lignes forment un cluster.
• Habituellement, dans la construction d'un centre de données (DPC) ou d'un centre de données, plusieurs clusters sont situés.
• Plusieurs bâtiments de centres de données proches les uns des autres composent le campus.

À l'intérieur de chaque centre de données, toutes les machines doivent pouvoir communiquer efficacement entre elles, nous avons donc créé un commutateur virtuel très rapide (commutateur) avec des dizaines de milliers de ports. Cela a été possible en connectant des centaines de commutateurs développés par Google dans une «usine» basée sur la topologie du réseau Clos [Clos, 1953], appelée Jupiter [Singh et al., 2015]. À sa configuration maximale, Jupiter prend en charge un débit de 1,3 Pb / s entre les serveurs.

Les centres de données sont connectés les uns aux autres à l'aide de notre réseau dorsal mondial B4 [Jain et al., 2013]. Le B4 possède une architecture réseau configurable par logiciel et utilise le protocole de communication ouvert OpenFlow. B4 fournit une large bande passante à un nombre limité de systèmes et utilise un contrôle de largeur de canal flexible pour maximiser sa valeur moyenne [Kumar et al., 2015].

Logiciel système qui «organise» l'équipement

Le logiciel qui assure la gestion et l'administration de nos équipements doit être capable de gérer d'énormes systèmes. Les pannes matérielles sont l'un des principaux problèmes résolus à l'aide de logiciels. Étant donné le grand nombre de composants matériels dans un cluster, ils se produisent assez souvent. Dans chaque cluster, des milliers de machines tombent généralement en panne en un an et des milliers de disques durs tombent en panne. Si vous multipliez ce nombre par le nombre de clusters opérant dans le monde, le résultat est stupéfiant. Par conséquent, nous voulons isoler les utilisateurs de ces problèmes, et les équipes impliquées dans nos services ne veulent pas non plus être distraites par des problèmes matériels. Chaque campus de centre de données dispose d'équipes chargées de prendre en charge l'équipement et l'infrastructure du centre de données.

Gestion des machines

Borg (figure 2.2) est un système de gestion de cluster distribué [Verma et al., 2015], similaire à Apache Mesos. Borg gère les travaux au niveau du cluster.
Borg est responsable du lancement des jobs utilisateurs. Ces tâches peuvent être soit des services exécutés en permanence, soit des processus par lots comme MapReduce [Dean et Ghemawat, 2004]. Ils peuvent consister en plusieurs (parfois des milliers) de tâches (tâches) identiques - à la fois pour des raisons de fiabilité et parce qu'un processus, en règle générale, n'est pas en mesure de traiter tout le trafic du cluster. Lorsque Borg démarre la tâche, il trouve les machines pour effectuer ses tâches et leur commande de démarrer le programme serveur. Borg surveille ensuite l'état de ces tâches. Si la tâche ne fonctionne pas correctement, elle est détruite et redémarre, éventuellement sur une autre machine.

Comme les tâches sont librement réparties entre les machines, nous ne pouvons pas utiliser les adresses IP et les numéros de port pour y accéder. Ce problème est résolu par un niveau d'abstraction supplémentaire: lors du démarrage d'une tâche, Borg attribue un nom à la tâche et un numéro (index) pour chaque tâche à l'aide du service de nommage Borg (BNS). Au lieu d'utiliser l'adresse IP et le numéro de port, d'autres processus s'associent aux tâches Borg par leur nom BNS, qui convertit ensuite le BNS en adresse IP et numéro de port. Par exemple, le chemin BNS peut être une chaîne comme / bns / <cluster> / <user> / <task_name> / <task_number>, qui est ensuite traduite (il est d'usage de dire "autorisé" sur les réseaux) au format <adresse IP>: <port> .

Borg est également responsable de l'allocation des ressources pour les missions. Chaque tâche doit indiquer les ressources nécessaires pour la terminer (par exemple, trois cœurs de processeur, 2 Go de RAM). En utilisant la liste des exigences pour toutes les tâches, Borg peut répartir de manière optimale les tâches entre les machines, en tenant également compte des considérations de tolérance aux pannes (par exemple, Borg ne démarrera pas toutes les tâches d'une tâche sur le même rack, car le basculement de ce rack sera un point critique en cas de panne) tâches).

Si une tâche essaie de récupérer plus de ressources que ce qui était demandé, Borg la détruit puis redémarre (car il est généralement préférable d'avoir une tâche qui se bloque et redémarre parfois que qui ne redémarre pas du tout).

Stockage

Pour un accès plus rapide aux données, les tâches peuvent utiliser le disque local des machines, mais nous avons plusieurs options pour organiser le stockage persistant dans le cluster (et même les données stockées localement seront finalement déplacées vers le stockage du cluster). Ils peuvent être comparés à Luster et aux systèmes de fichiers en cluster Hadoop Distributed File System (HDFS) avec une implémentation open source.

Le stockage offre aux utilisateurs la possibilité d'accéder facilement et de manière fiable aux données disponibles pour le cluster. Comme le montre la fig. 2.3, le référentiel comporte plusieurs couches.


1. La couche la plus basse est appelée D (à partir du disque, bien que le niveau D utilise à la fois des disques durs traditionnels et des lecteurs flash). D est un serveur de fichiers qui s'exécute sur pratiquement toutes les machines du cluster. Cependant, les utilisateurs qui souhaitent accéder à leurs données ne voudraient pas se souvenir sur quelle machine ils sont stockés, donc la couche suivante est connectée ici.

2. Au-dessus de la couche D se trouve la couche Colossus, qui crée un système de fichiers dans le cluster qui offre la sémantique habituelle du système de fichiers, ainsi que la réplication et le chiffrement. Colossus est le successeur de GFS, le système de fichiers Google (Ghemawat et al., 2003).

3. Ensuite, plusieurs services de type base de données sont créés au-dessus du niveau Colossus.

• Bigtable [Chang et al., 2006] est un système de base de données non relationnel (NoSQL) capable de travailler avec des bases de données d'un pétaoctet. Bigtable est une base de données ordonnée, distribuée, tolérante aux pannes, multidimensionnelle et indexée par des clés de ligne, de colonne et d'horodatage; chaque valeur de base de données est un tableau d'octets arbitraire non interprété. Bigtable prend également en charge la réplication entre les centres de données.
• Spanner [Corbett et al., 2012] propose une interface de type SQL pour les utilisateurs qui ont besoin d'intégrité et de cohérence des données lorsqu'ils accèdent depuis n'importe où dans le monde.
• Plusieurs autres systèmes de base de données sont disponibles, comme Blobstore. Ils ont tous leurs propres forces et faiblesses (voir chapitre 26).

Réseau

Google Networking est géré de plusieurs manières. Comme mentionné précédemment, nous utilisons un réseau configurable par logiciel basé sur OpenFlow. Au lieu de routeurs intelligents, nous utilisons des commutateurs idiots pas si chers en combinaison avec un contrôleur central (dupliqué), qui pré-calcule le meilleur itinéraire sur le réseau. Cela vous permet d'utiliser un équipement de commutation plus simple, le libérant de la recherche d'itinéraire fastidieuse.

La bande passante réseau doit être correctement allouée. Comme Borg limite les ressources informatiques qu'une tâche peut utiliser, Bandwidth Enforcer (BwE) gère également la bande passante disponible pour maximiser le débit moyen. L'optimisation de la bande passante n'est pas seulement liée au coût: la gestion centralisée du trafic résout un certain nombre de problèmes qui sont extrêmement difficiles à résoudre par une combinaison de routage distribué et de gestion classique du trafic (Kumar, 2015).

Certains services ont des emplois exécutés sur plusieurs clusters situés dans différentes parties du monde. Afin de réduire le temps de retard des systèmes distribués à l'échelle mondiale, nous souhaitons diriger les utilisateurs vers le centre de données le plus proche qui a la capacité appropriée pour cela. Notre Global Software Load Balancer (GSLB) effectue un équilibrage de charge à trois niveaux:

• l'équilibrage de la charge géographique pour les requêtes DNS (par exemple, sur www.google.com ), il est décrit au chapitre 19;
• équilibrage de la charge au niveau des services aux utilisateurs (par exemple, YouTube ou Google Maps);
• l'équilibrage de charge au niveau RPC (Remote Procedure Call), décrit au chapitre 20.

Les propriétaires de services leur spécifient des noms symboliques, une liste des adresses BNS du serveur et les performances disponibles sur chaque site (généralement, il est mesuré en requêtes par seconde - requêtes par seconde, QPS). Par la suite, le GSLB achemine le trafic vers les adresses BNS spécifiées.

Autres logiciels système

Le logiciel du centre de données comporte d'autres composants importants.

Service de verrouillage

Le service de verrouillage Chubby [Burrows, 2006] fournit une API similaire au système de fichiers pour servir les verrous. Chubby gère les verrous de tous les centres de données. Il utilise le protocole Paxos pour accéder de manière asynchrone au Consensus (voir chapitre 23).

Chubby joue également un rôle important dans le choix d'un assistant. Si, pour certains services, cinq répliques d'une tâche sont fournies dans le but d'augmenter la fiabilité, mais à un moment donné, une seule d'entre elles fait le vrai travail, Chubby est utilisé pour sélectionner cette réplique.
Chubby est idéal pour les données qui nécessitent une fiabilité de stockage. Pour cette raison, BNS utilise Chubby pour stocker le rapport des chemins BNS aux adresses IP: paires de ports.

Surveillance et alertes

Nous voulons être sûrs que tous les services fonctionnent correctement. Par conséquent, nous lançons de nombreuses instances du programme de surveillance Borgmon (voir chapitre 10). Borgmon reçoit régulièrement des valeurs de référence de services surveillés. Ces données peuvent être utilisées immédiatement pour la notification ou stockées pour un traitement et une analyse ultérieurs, par exemple, pour créer des graphiques. Cette surveillance peut être utilisée à des fins telles que:

• mettre en place des alertes pour les problèmes urgents;
• comparaison des comportements: la mise à jour du logiciel a-t-elle accéléré le serveur;
• évaluation de la nature des changements dans la consommation des ressources au fil du temps, ce qui est nécessaire pour la planification des capacités.

Notre infrastructure logicielle

L’architecture de notre logiciel est conçue de manière à pouvoir utiliser plus efficacement les ressources matérielles du système. Notre code entier est multi-thread, donc une tâche peut facilement utiliser plusieurs cœurs. Afin de prendre en charge les tableaux de bord, la surveillance et le débogage, chaque serveur comprend une implémentation de serveur HTTP en tant qu'interface via laquelle des informations de diagnostic et des statistiques pour une tâche spécifique sont fournies.

Tous les services Google «communiquent» à l'aide de l'infrastructure d'appel de procédure à distance (RPC) appelée Stubby. Il en existe une version open source, elle s'appelle gRPC (voir grpc.io ). Souvent, un appel RPC est effectué même pour les routines du programme local. Cela vous permet de réorienter le programme vers les appels d'un autre serveur pour obtenir une plus grande modularité ou à mesure que le code du serveur d'origine se développe. GSLB peut effectuer un équilibrage de charge RPC de la même manière que pour les interfaces de service externes.

Le serveur reçoit les demandes RPC de la partie frontale et envoie le RPC au backend. En utilisant des termes traditionnels, le frontend est appelé le client et le backend est appelé le serveur.
Les données sont transférées vers et depuis RPC en utilisant le protocole de sérialisation - les soi-disant tampons de protocole, ou, brièvement, les protobufs. Ce protocole est similaire à Apache's Thrift et présente plusieurs avantages par rapport à XML lorsqu'il s'agit de sérialiser des données structurées: il est plus simple, trois à dix fois plus compact, 20 à 100 fois plus rapide et plus unique.

Notre environnement de développement

La vitesse de développement des produits est très importante pour Google, nous avons donc créé un environnement spécial qui tire le meilleur parti de notre infrastructure [Morgenthaler et al., 2012].

À l'exception de quelques groupes dont les produits sont open source et utilisent donc leurs propres référentiels distincts (par exemple, Android et Chrome), les ingénieurs logiciels de Google travaillent dans un référentiel commun [Potvin, Levenberg, 2016]. Cette approche a plusieurs applications pratiques qui sont importantes pour notre processus de production.

• Si un ingénieur rencontre un problème dans un composant en dehors de son projet, il peut résoudre le problème, envoyer les modifications proposées («changelist» - changelist, CL) au propriétaire pour examen, puis implémenter les modifications apportées dans la branche principale du programme.
• Les modifications du code source dans le projet d'un ingénieur doivent être prises en compte - effectuer un audit (examen). Tous les logiciels passent cette étape avant leur adoption.

Lorsque le logiciel est en cours d'assemblage, la demande d'assemblage est envoyée à des serveurs de centre de données spécialisés. Même la construction de grands projets est rapide car vous pouvez utiliser plusieurs serveurs pour la compilation parallèle. Cette infrastructure est également utilisée pour les tests en continu. Chaque fois qu'une nouvelle liste de modifications (CL) apparaît, des tests sont exécutés sur tous les logiciels qui peuvent être affectés directement ou indirectement par ces modifications. Si le cadre détecte que les modifications ont perturbé le fonctionnement d'autres parties du système, il en avise le propriétaire. Certains projets utilisent le système push-on-green («envoyer avec succès»), selon lequel la nouvelle version est automatiquement envoyée en exploitation commerciale après avoir réussi les tests.

Shakespeare: exemple de service

Afin de démontrer comment Google développe un service dans un environnement industriel, considérons un exemple de service hypothétique qui interagit avec les technologies de Google. Supposons que nous voulons offrir un service qui vous permette de déterminer dans quelles œuvres de Shakespeare le mot que vous avez mentionné se produit.

Nous pouvons diviser le système en deux parties.

• Un composant de traitement par lots qui lit tous les textes de Shakespeare, crée un index et l'écrit dans Bigtable. Cette tâche (plus précisément, la tâche) est effectuée une fois ou, éventuellement, occasionnellement (après tout, un nouveau texte Shakespeare peut apparaître!).
• Une application frontale qui traite les demandes des utilisateurs finaux. Cette tâche est toujours en cours d'exécution, car à tout moment, un utilisateur de n'importe quel fuseau horaire peut vouloir rechercher dans les livres de Shakespeare.

Le composant de traitement par lots sera le service MapReduce, dont le travail est divisé en trois phases.

1. Dans la phase de cartographie, les textes de Shakespeare sont lus et divisés en mots séparés. Cette partie du travail sera terminée plus rapidement si plusieurs processus de travail (tâches) sont lancés en parallèle.

2. Dans la phase de lecture aléatoire, les entrées sont triées par mot.

3. Dans la phase Réduire, des tuples du formulaire (mot, list_products) sont créés.

Chaque tuple est écrit sous forme de chaîne dans Bigtable, la clé est le mot.

Cycle de vie de la demande

Dans la fig. 2.4 montre comment la demande de l'utilisateur est servie. Tout d'abord, l'utilisateur clique sur le lien shakespeare.google.com dans le navigateur. Pour obtenir l'adresse IP appropriée, l'appareil de l'utilisateur traduit ("résout") l'adresse à l'aide du serveur DNS (1). La requête DNS finit par se retrouver sur le serveur DNS de Google, qui interagit avec le GSLB. En suivant la charge de trafic de tous les serveurs frontaux par région, GSLB choisit quelle adresse IP de quel serveur renvoyer à l'utilisateur.

Le navigateur se connecte au serveur HTTP à l'adresse spécifiée. Ce serveur (appelé Google Frontend ou GFE) est un serveur proxy «inversé» situé à l'autre extrémité de la connexion TCP du client (2). GFE recherche le service requis (par exemple, il peut s'agir d'un service de recherche, de cartes ou, dans notre cas, du service Shakespeare). En accédant de manière répétée au GSLB, le serveur trouve un serveur frontal Shakespeare disponible et y accède via un appel de procédure à distance (RPC), transmettant une requête HTTP reçue de l'utilisateur (3).

Le serveur Shakespeare analyse la requête HTTP et crée un «tampon de protocole» (protobuf) contenant les mots à rechercher. Maintenant, le serveur frontal Shakespeare doit contacter le serveur principal Shakespeare: le premier contacte le GSLB pour obtenir l'adresse BNS d'une instance appropriée et déchargée de la seconde (4). Ensuite, le serveur backend de Shakespeare contacte le serveur Bigtable pour recevoir les données demandées (5).

Le résultat est écrit dans le protobuf de réponse et renvoyé au serveur principal de Shakespeare. Le backend transmet protobuf avec le résultat du service au serveur frontal Shakespeare, qui crée un document HTML et le renvoie en réponse à l'utilisateur.


Toute cette chaîne d'événements se déroule en un clin d'œil - en quelques centaines de millisecondes seulement! Étant donné que de nombreux composants sont impliqués, il existe de nombreux endroits où une erreur potentielle peut se produire; en particulier, une défaillance du GSLB peut désorganiser tout le travail et conduire à l'effondrement. Google, , ( ), , . , www.google.com , .

, - 100 (QPS). , 3470 QPS, 35 . , 37 , N + 2.

• , 36 .
• , - 35 — , .

: 1430 QPS , 290 — , 1400 — 350 — . - , : , , . N + 2 , 17 , 16 — — . , , ( ), — N + 2 N + 1. : GSLB - , 20 % , . 2–3 .

- Bigtable, . - Bigtable, , , Bigtable . , Bigtable , . Bigtable , , .

, . , , .

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur
» Contenu
» Extrait

Coupon de 20% pour Habrozavitel - Site Reliability Engineering