Artem Denissov ( , )
Badoo est le plus grand site de rencontres au monde. Nous comptons actuellement environ 330 millions d'utilisateurs enregistrés dans le monde. Mais ce qui est bien plus important dans le contexte de notre conversation d’aujourd’hui, c’est que nous stockons environ 3 pétaoctets de photos d’utilisateurs. Chaque jour, nos utilisateurs téléchargent environ 3,5 millions de nouvelles photos, et la charge de lecture est d'environ 80 XNUMX requêtes par seconde. C'est beaucoup pour notre backend, et cela pose parfois des difficultés.
Je parlerai de la conception de ce système, qui stocke et envoie des photos en général, et je le regarderai du point de vue d'un développeur. Il y aura une brève rétrospective sur son évolution, où j'exposerai les principales étapes, mais je ne parlerai plus en détail des solutions que nous utilisons actuellement.
Maintenant, commençons.
Comme je l'ai dit, il s'agira d'une rétrospective, et pour commencer quelque part, prenons l'exemple le plus courant.
Nous avons une tâche commune, nous devons accepter, stocker et envoyer les photos des utilisateurs. Sous cette forme, la tâche est générale, on peut utiliser n'importe quoi :
- stockage cloud moderne,
- une solution en boîte, dont il existe également beaucoup maintenant ;
- Nous pouvons installer plusieurs machines dans notre centre de données, y installer de gros disques durs et y stocker des photos.
Historiquement, Badoo - de temps en temps (à l'époque où il n'en était qu'à ses balbutiements) - vit sur ses propres serveurs, à l'intérieur de nos propres DC. Cette option était donc optimale pour nous.
Nous avons juste pris plusieurs machines, appelées « photos », et nous avons obtenu un cluster qui stocke les photos. Mais il semble que quelque chose manque. Pour que tout cela fonctionne, nous devons déterminer d'une manière ou d'une autre sur quelle machine nous allons stocker quelles photos. Et ici aussi, il n’est pas nécessaire d’ouvrir l’Amérique.
Nous ajoutons un champ à notre stockage avec des informations sur les utilisateurs. Ce sera la clé de partitionnement. Dans notre cas, nous l'avons appelé place_id, et cet identifiant de lieu pointe vers l'endroit où les photos des utilisateurs sont stockées. Nous faisons des cartes.
Dans un premier temps, cela peut même être fait manuellement - on dit qu'une photo de cet utilisateur avec tel endroit atterrira sur tel serveur. Grâce à cette carte, nous savons toujours quand un utilisateur télécharge une photo, où la sauvegarder et où la donner.
Il s’agit d’un système absolument trivial, mais qui présente des avantages assez importants. La première est que c'est simple, comme je l'ai dit, et la seconde est qu'avec cette approche, nous pouvons facilement évoluer horizontalement en livrant simplement de nouvelles voitures et en les ajoutant à la carte. Vous n'avez rien d'autre à faire.
C'est comme ça pour nous pendant un certain temps.
C'était vers 2009. Ils ont livré des voitures, livré...
Et à un moment donné, nous avons commencé à remarquer que ce système présentait certains inconvénients. Quels sont les inconvénients ?
Tout d’abord, la capacité est limitée. Nous ne pouvons pas stocker autant de disques durs sur un seul serveur physique que nous le souhaiterions. Et c’est devenu un certain problème au fil du temps et avec la croissance de l’ensemble de données.
Et deuxieme. Il s'agit d'une configuration de machines atypique, car ces machines sont difficiles à réutiliser dans certains autres clusters ; elles sont assez spécifiques, c'est-à-dire ils devraient avoir des performances faibles, mais en même temps avec un gros disque dur.
C'était tout pour 2009, mais, en principe, ces exigences sont toujours d'actualité aujourd'hui. Nous avons une rétrospective, donc en 2009, tout allait complètement mal avec ça.
Et le dernier point est le prix.
Le prix était très élevé à l’époque et nous devions chercher des alternatives. Ceux. nous devions d'une manière ou d'une autre mieux utiliser à la fois l'espace dans les centres de données et les serveurs physiques sur lesquels tout cela se trouve. Et nos ingénieurs système ont lancé une vaste étude dans laquelle ils ont examiné un certain nombre d’options différentes. Ils ont également examiné les systèmes de fichiers en cluster tels que PolyCeph et Lustre. Il y avait des problèmes de performances et un fonctionnement assez difficile. Ils ont refusé. Nous avons essayé de monter l'intégralité de l'ensemble de données via NFS sur chaque voiture afin de l'augmenter d'une manière ou d'une autre. La lecture s'est également mal déroulée, nous avons essayé différentes solutions de différents fournisseurs.
Et finalement, nous avons opté pour l’utilisation de ce que l’on appelle le Storage Area Network.
Il s'agit de grands SHD spécialement conçus pour stocker de grandes quantités de données. Ce sont des étagères avec des disques qui sont montés sur les machines de sortie optique finales. Que. nous avons une sorte de pool de machines, assez petit, et ces SHD, qui sont transparents à notre logique d'envoi, c'est-à-dire pour que notre nginx ou toute autre personne réponde aux demandes de ces photos.
Cette décision présentait des avantages évidents. C'est SHD. Il vise à stocker des photos. Cela revient moins cher que de simplement équiper les machines de disques durs.
Deuxième plus.
C'est que la capacité est devenue beaucoup plus grande, c'est-à-dire nous pouvons accueillir beaucoup plus de stockage dans un volume beaucoup plus petit.
Mais il y a aussi eu des inconvénients qui sont apparus assez rapidement. À mesure que le nombre d'utilisateurs et la charge sur ce système augmentaient, des problèmes de performances ont commencé à survenir. Et le problème ici est assez évident : tout SHD conçu pour stocker de nombreuses photos dans un petit volume souffre généralement d'une lecture intensive. Cela est en fait vrai pour tout stockage cloud ou autre. Nous n’avons pas de stockage idéal qui serait évolutif à l’infini, vous pourriez y insérer n’importe quoi et il tolérerait très bien les lectures. Des lectures particulièrement informelles.
Comme c'est le cas de nos photos, car les photos sont demandées de manière incohérente, ce qui affectera grandement leurs performances.
Même selon les chiffres d’aujourd’hui, si nous obtenons plus de 500 RPS pour les photos sur une machine à laquelle le stockage est connecté, les problèmes commencent déjà. Et c'était déjà assez grave pour nous, car le nombre d'utilisateurs augmente et les choses ne font qu'empirer. Cela doit être optimisé d’une manière ou d’une autre.
Afin d'optimiser, nous avons évidemment décidé à ce moment-là d'examiner le profil de charge - ce qui se passe en général, ce qui doit être optimisé.
Et ici, tout joue entre nos mains.
Je l'ai déjà dit dans la première diapositive : nous avons 80 3,5 demandes de lecture par seconde avec seulement XNUMX millions de téléchargements par jour. Autrement dit, il s'agit d'une différence de trois ordres de grandeur. Il est évident que la lecture doit être optimisée et comment le faire est pratiquement clair.
Il y a encore un petit point. Les spécificités du service sont telles qu'une personne s'inscrit, télécharge une photo, puis commence à regarder activement d'autres personnes, comme elles, et est activement montrée à d'autres personnes. Ensuite, il trouve un partenaire ou ne trouve pas de partenaire, cela dépend du résultat, et arrête d'utiliser le service pendant un certain temps. En ce moment, quand il l'utilise, ses photos sont très chaudes - elles sont très demandées, beaucoup de gens les regardent. Dès qu’il arrête de faire cela, il perd assez rapidement toute exposition aux autres personnes comme auparavant, et ses photos ne sont presque jamais demandées.
Ceux. Nous avons un très petit ensemble de données chaudes. Mais en même temps, il y a beaucoup de demandes à son égard. Et une solution tout à fait évidente ici consiste à ajouter un cache.
Un cache avec LRU résoudra tous nos problèmes. Qu'est-ce que nous faisons?
Nous en ajoutons un autre relativement petit devant notre grand cluster avec stockage, appelé photocaches. Il s'agit essentiellement d'un proxy de mise en cache.
Comment ça marche de l’intérieur ? Voici notre utilisateur, voici le stockage. Tout est comme avant. Qu'ajoutons-nous entre les deux ?
C'est juste une machine avec un disque local physique, ce qui est rapide. C'est avec un SSD, par exemple. Et une sorte de cache local est stockée sur ce disque.
À quoi cela ressemble-t-il? L'utilisateur envoie une demande de photo. NGINX le recherche d'abord dans le cache local. Sinon, passez simplement proxy_pass à notre stockage, téléchargez la photo à partir de là et donnez-la à l'utilisateur.
Mais celui-ci est très banal et on ne sait pas ce qui se passe à l’intérieur. Cela fonctionne quelque chose comme ça.
Le cache est logiquement divisé en trois couches. Quand je dis « trois niveaux », cela ne veut pas dire qu’il existe une sorte de système complexe. Non, il ne s'agit que de trois répertoires dans le système de fichiers :
- Il s'agit d'un tampon dans lequel vont les photos qui viennent d'être téléchargées à partir d'un proxy.
- Il s'agit d'un cache actif qui stocke les photos actuellement activement demandées.
- Et un cache froid, où les photos sont progressivement supprimées du cache chaud lorsque moins de demandes leur parviennent.
Pour que cela fonctionne, nous devons gérer ce cache d'une manière ou d'une autre, nous devons réorganiser les photos qu'il contient, etc. C'est aussi un processus très primitif.
Nginx écrit simplement sur le RAMDisk access.log pour chaque requête, dans lequel il indique le chemin d'accès à la photo qu'il a actuellement servie (chemin relatif, bien sûr), et quelle partition elle a été servie. Ceux. il peut indiquer « photo 1 » puis soit un tampon, soit un cache chaud, soit un cache froid, soit un proxy.
En fonction de cela, nous devons décider d'une manière ou d'une autre quoi faire de la photo.
Nous avons un petit démon exécuté sur chaque machine qui lit en permanence ce journal et stocke dans sa mémoire des statistiques sur l'utilisation de certaines photographies.
Il y collecte simplement, conserve les compteurs et effectue périodiquement les opérations suivantes. Il déplace les photos activement demandées, pour lesquelles il existe de nombreuses demandes, vers le cache chaud, où qu'elles se trouvent.
Les photos qui sont rarement demandées et qui le sont devenus moins fréquemment sont progressivement poussées du cache chaud vers le cache froid.
Et lorsque nous manquons d'espace dans le cache, nous commençons simplement à tout supprimer du cache froid sans discernement. Et d'ailleurs, cela fonctionne bien.
Pour que la photo soit enregistrée immédiatement lors de son proxy vers le tampon, nous utilisons la directive proxy_store et le tampon est également un RAMDisk, c'est-à-dire pour l'utilisateur, cela fonctionne très rapidement. Cela concerne les composants internes du serveur de mise en cache lui-même.
La question restante est de savoir comment répartir les requêtes sur ces serveurs.
Disons qu'il existe un cluster de vingt machines de stockage et trois serveurs de mise en cache (c'est ainsi que cela s'est passé).
Nous devons d’une manière ou d’une autre déterminer quelles demandes concernent quelles photos et où les déposer.
L'option la plus courante est le Round Robin. Ou le faire par accident ?
Cela présente évidemment un certain nombre d'inconvénients, car nous utiliserions le cache de manière très inefficace dans une telle situation. Les requêtes atterriront sur certaines machines aléatoires : ici elles étaient mises en cache, mais sur la suivante elles n'y sont plus. Et si tout cela fonctionne, ce sera très mauvais. Même avec un petit nombre de machines dans le cluster.
Nous devons d’une manière ou d’une autre déterminer sans ambiguïté quel serveur doit envoyer quelle demande.
Il existe une manière banale. Nous prenons le hachage de l'URL ou le hachage de notre clé de partitionnement, qui se trouve dans l'URL, et le divisons par le nombre de serveurs. Marchera? Volonté.
Ceux. Nous avons une requête à 2 %, par exemple, pour certains « exemple_url », elle atterrira toujours sur le serveur avec l'index « XNUMX », et le cache sera constamment éliminé au mieux.
Mais le repartitionnement dans un tel schéma pose un problème. Reharding - je veux dire changer le nombre de serveurs.
Supposons que notre cluster de mise en cache ne puisse plus faire face et que nous décidions d'ajouter une autre machine.
Ajoutons.
Désormais, tout n'est pas divisible par trois, mais par quatre. Ainsi, presque toutes les clés que nous avions, presque toutes les URL résident désormais sur d’autres serveurs. L'intégralité du cache a été invalidée simplement pendant un instant. Toutes les demandes sont tombées sur notre cluster de stockage, il est devenu malade, panne de service et utilisateurs insatisfaits. Je ne veux pas faire ça.
Cette option ne nous convient pas non plus.
Que. Que devrions nous faire? Nous devons d’une manière ou d’une autre utiliser efficacement le cache, envoyer la même requête encore et encore sur le même serveur, mais être résistants au reharding. Et il existe une telle solution, ce n’est pas si compliqué. C'est ce qu'on appelle un hachage cohérent.
À quoi ressemble-t-il?
Nous prenons une fonction de la clé de partitionnement et répartissons toutes ses valeurs sur le cercle. Ceux. au point 0, ses valeurs minimales et maximales convergent. Ensuite, nous plaçons tous nos serveurs sur le même cercle à peu près de cette manière :
Chaque serveur est défini par un point et le secteur qui y va dans le sens des aiguilles d'une montre est donc desservi par cet hôte. Lorsque des demandes nous parviennent, nous voyons immédiatement que, par exemple, la demande A - elle contient un hachage - et elle est servie par le serveur 2. La demande B - par le serveur 3. Et ainsi de suite.
Que se passe-t-il dans cette situation lors du reharding ?
Nous n'invalidons pas tout le cache, comme auparavant, et ne décalons pas toutes les clés, mais nous décalons chaque secteur sur une courte distance pour que, relativement parlant, notre sixième serveur, que nous souhaitons ajouter, rentre dans l'espace libre, et nous l'ajoutons ici.
Bien entendu, dans une telle situation, les clés sortent également. Mais ils repartent beaucoup plus faibles qu’avant. Et nous voyons que nos deux premières clés sont restées sur leurs serveurs, et le serveur de mise en cache n'a changé que pour la dernière clé. Cela fonctionne assez efficacement, et si vous ajoutez de nouveaux hôtes progressivement, il n'y a pas de gros problème ici. Vous ajoutez et ajoutez petit à petit, attendez que le cache soit à nouveau plein et tout fonctionne bien.
La seule question reste celle des refus. Supposons qu'une sorte de voiture soit en panne.
Et nous ne voudrions pas vraiment régénérer cette carte pour le moment, invalider une partie du cache, etc., si, par exemple, la machine était redémarrée et que nous devions répondre d'une manière ou d'une autre aux demandes. Nous conservons simplement un cache de photos de sauvegarde sur chaque site, qui remplace toute machine actuellement en panne. Et si soudainement l'un de nos serveurs devient indisponible, le trafic y va. Naturellement, nous n’avons aucun cache là-bas, c’est-à-dire il fait froid, mais au moins les demandes des utilisateurs sont traitées. S’il s’agit d’un court intervalle, nous le vivons en toute sérénité. Il y a juste plus de charge sur le stockage. Si cet intervalle est long, alors nous pouvons déjà prendre une décision : supprimer ou non ce serveur de la carte, ou peut-être le remplacer par un autre.
Il s'agit du système de mise en cache. Regardons les résultats.
Il semblerait qu'il n'y ait rien de compliqué ici. Mais cette méthode de gestion du cache nous a donné un taux de tromperie d'environ 98 %. Ceux. sur ces 80 1600 requêtes par seconde, seulement XNUMX XNUMX atteignent le stockage, et c'est une charge tout à fait normale, ils la supportent sereinement, nous avons toujours une réserve.
Nous avons placé ces serveurs dans trois de nos DC et avons reçu trois points de présence : Prague, Miami et Hong Kong.
Que. ils sont plus ou moins localisés localement sur chacun de nos marchés cibles.
Et en prime, nous avons ce proxy de mise en cache, sur lequel le processeur est en fait inactif, car il n'est pas si nécessaire pour servir du contenu. Et là, en utilisant NGINX+ Lua, nous avons implémenté beaucoup de logique utilitaire.
Par exemple, nous pouvons expérimenter avec webp ou progressif jpeg (ce sont des formats modernes et efficaces), voir comment cela affecte le trafic, prendre certaines décisions, l'activer pour certains pays, etc. effectuez un redimensionnement dynamique ou recadrez des photos à la volée.
C'est un bon cas d'utilisation lorsque, par exemple, vous disposez d'une application mobile qui affiche des photos et que l'application mobile ne veut pas gaspiller le processeur du client en demandant une grande photo, puis en la redimensionnant à une certaine taille afin de la pousser dans la vue. Nous pouvons simplement spécifier dynamiquement certains paramètres dans l'URL conditionnelle UPort, et le cache photo redimensionnera la photo elle-même. En règle générale, il sélectionnera la taille que nous avons physiquement sur le disque, aussi proche que possible de celle demandée, et la vendra à des coordonnées spécifiques.
À propos, nous avons rendu publics les enregistrements vidéo des cinq dernières années de la conférence des développeurs de systèmes à forte charge. . Regardez, apprenez, partagez et abonnez-vous à .
Nous pouvons également y ajouter beaucoup de logique produit. Par exemple, nous pouvons ajouter différents filigranes en utilisant les paramètres d'URL, nous pouvons flouter, flouter ou pixeliser les photos. C’est quand on veut montrer une photo d’une personne, mais on ne veut pas montrer son visage, ça marche bien, tout est implémenté ici.
Qu'avons-nous obtenu ? Nous avons trois points de présence, un bon taux de tricks, et en même temps nous n’avons pas de CPU inutilisé sur ces machines. Bien entendu, il est désormais devenu plus important qu’auparavant. Nous devons nous doter de voitures plus solides, mais cela en vaut la peine.
Cela concerne le retour des photographies. Tout ici est assez clair et évident. Je pense que je n'ai pas découvert l'Amérique, presque tous les CDN fonctionnent de cette façon.
Et, très probablement, un auditeur averti pourrait se poser une question : pourquoi ne pas simplement tout changer en CDN ? Ce serait à peu près la même chose : tous les CDN modernes peuvent le faire. Et il y a plusieurs raisons.
Le premier concerne les photographies.
C’est l’un des points clés de notre infrastructure et nous devons le contrôler autant que possible. S'il s'agit d'une solution provenant d'un fournisseur tiers et que vous n'avez aucun pouvoir sur celle-ci, il vous sera assez difficile de vivre avec lorsque vous disposez d'un grand ensemble de données et d'un très grand flux. des demandes des utilisateurs.
Laisse moi te donner un exemple. Maintenant, avec nos infrastructures, nous pouvons, par exemple, en cas de problème ou de choc sous terre, aller à la machine et y déconner, relativement parlant. Nous pouvons ajouter la collection de certaines métriques dont nous avons uniquement besoin, nous pouvons expérimenter d'une manière ou d'une autre, voir comment cela affecte les graphiques, etc. De nombreuses statistiques sont désormais collectées sur ce cluster de mise en cache. Et nous l'examinons périodiquement et passons beaucoup de temps à explorer certaines anomalies. Si c’était du côté du CDN, ce serait beaucoup plus difficile à contrôler. Ou, par exemple, si un accident survient, nous savons ce qui s’est passé, nous savons comment vivre avec et comment le surmonter. C'est la première conclusion.
La deuxième conclusion est également plutôt historique, car le système s'est développé depuis longtemps et il y avait de nombreuses exigences commerciales différentes à différentes étapes, et elles ne correspondent pas toujours au concept CDN.
Et le point qui découle du précédent est
En effet, sur les caches de photos, nous avons beaucoup de logiques spécifiques, qui ne peuvent pas toujours être ajoutées sur demande. Il est peu probable qu'un CDN vous ajoute des éléments personnalisés à votre demande. Par exemple, chiffrer les URL si vous ne souhaitez pas que le client puisse modifier quelque chose. Voulez-vous modifier l'URL sur le serveur et la crypter, puis envoyer des paramètres dynamiques ici.
Quelle conclusion cela suggère-t-il ? Dans notre cas, le CDN n’est pas une très bonne alternative.
Et dans votre cas, si vous avez des exigences commerciales spécifiques, vous pouvez alors mettre en œuvre assez facilement ce que je vous ai montré vous-même. Et cela fonctionnera parfaitement avec un profil de charge similaire.
Mais si vous avez une sorte de solution générale et que la tâche n'est pas très spécifique, vous pouvez utiliser un CDN en toute sécurité. Ou si le temps et les ressources sont plus importants pour vous que le contrôle.
Et les CDN modernes ont presque tout ce dont je vous ai parlé maintenant. À l’exception de plus ou moins certaines fonctionnalités.
Il s'agit de donner des photos.
Avançons maintenant un peu dans notre rétrospective et parlons du stockage.
2013 passait.
Des serveurs de mise en cache ont été ajoutés, les problèmes de performances ont disparu. Tout va bien. L’ensemble de données s’agrandit. En 2013, nous avions environ 80 serveurs connectés au stockage et environ 40 serveurs en cache dans chaque DC. Cela représente 560 téraoctets de données sur chaque DC, soit environ un pétaoctet au total.
Et avec la croissance de l’ensemble de données, les coûts d’exploitation ont commencé à augmenter considérablement. Qu'est-ce que cela signifiait ?
Dans ce schéma dessiné - avec un SAN, avec des machines et des caches qui y sont connectés - il y a de nombreux points de défaillance. Si nous avions déjà fait face à la panne des serveurs de mise en cache auparavant, tout était plus ou moins prévisible et compréhensible, mais du côté du stockage, tout était bien pire.
Premièrement, le réseau de stockage (SAN) lui-même, qui peut échouer.
Deuxièmement, il est connecté via des optiques aux machines finales. Il peut y avoir des problèmes avec les cartes optiques et les bougies d'allumage.
Bien sûr, il n'y en a pas autant qu'avec le SAN lui-même, mais ce sont néanmoins aussi des points de défaillance.
Vient ensuite la machine elle-même, qui est connectée au stockage. Cela peut aussi échouer.
Au total, nous avons trois points d'échec.
De plus, en plus des points de défaillance, le stockage lui-même nécessite une maintenance lourde.
Il s’agit d’un système complexe à plusieurs composants et les ingénieurs système peuvent avoir du mal à travailler avec.
Et le dernier point, le plus important. Si une panne se produit à l'un de ces trois points, nous avons une chance non nulle de perdre des données utilisateur car le système de fichiers peut planter.
Disons que notre système de fichiers est cassé. Premièrement, sa récupération prend beaucoup de temps - cela peut prendre une semaine avec une grande quantité de données. Et deuxièmement, à la fin, nous nous retrouverons très probablement avec un tas de fichiers incompréhensibles qui devront être combinés d'une manière ou d'une autre dans les photos des utilisateurs. Et nous risquons de perdre des données. Le risque est assez élevé. Et plus de telles situations se produisent et plus il y a de problèmes dans toute cette chaîne, plus ce risque est élevé.
Il fallait faire quelque chose à ce sujet. Et nous avons décidé qu'il nous suffisait de sauvegarder les données. C’est en fait une solution évidente et bonne. Qu'avons-nous fait?
Voici à quoi ressemblait notre serveur lorsqu’il était auparavant connecté au stockage. Il s’agit d’une section principale, c’est juste un périphérique bloc qui représente en fait un support pour le stockage à distance via l’optique.
Nous venons d'ajouter une deuxième section.
Nous avons placé un deuxième stockage à côté (heureusement, ce n’est pas si cher en termes d’argent), et l’avons appelé partition de sauvegarde. Il est également connecté via optique et se trouve sur la même machine. Mais nous devons d’une manière ou d’une autre synchroniser les données entre eux.
Ici, nous créons simplement une file d'attente asynchrone à proximité.
Elle n'est pas très occupée. Nous savons que nous n'avons pas assez de dossiers. Une file d'attente n'est qu'un tableau dans MySQL dans lequel sont écrites des lignes telles que « vous devez sauvegarder cette photo ». Avec toute modification ou téléchargement, nous copions de la partition principale vers la sauvegarde à l'aide d'un outil asynchrone ou simplement d'une sorte de travailleur d'arrière-plan.
Et ainsi nous avons toujours deux sections cohérentes. Même si une partie de ce système tombe en panne, nous pouvons toujours modifier la partition principale avec une sauvegarde et tout continuera à fonctionner.
Mais à cause de cela, la charge de lecture augmente considérablement, car... en plus des clients qui lisent dans la section principale, car ils y regardent d'abord la photo (elle y est plus récente), puis la recherchent sur la sauvegarde, s'ils ne l'ont pas trouvée (mais NGINX fait juste ça), notre système est également une sauvegarde plus lit maintenant à partir de la partition principale. Ce n’était pas un goulot d’étranglement, mais je ne voulais pas augmenter la charge, essentiellement, comme ça.
Et nous avons ajouté un troisième disque, qui est un petit SSD, et nous l'avons appelé tampon.
Comment ça marche maintenant.
L'utilisateur télécharge une photo dans le tampon, puis un événement est placé dans la file d'attente indiquant qu'elle doit être copiée en deux sections. Elle est copiée et la photo reste dans le tampon pendant un certain temps (disons un jour), puis est ensuite purgée de là. Cela améliore considérablement l'expérience utilisateur, car l'utilisateur télécharge une photo, en règle générale, les demandes commencent immédiatement à suivre, ou il a lui-même mis à jour la page et l'a actualisée. Mais tout dépend de l’application qui effectue le téléchargement.
Ou, par exemple, d'autres personnes à qui il a commencé à se montrer envoient immédiatement des demandes après cette photo. Il n'est pas encore dans le cache, la première requête arrive très rapidement. Essentiellement la même chose qu'à partir d'un cache de photos. Le stockage lent n’est pas du tout impliqué dans cela. Et lorsqu'un jour plus tard, il est purgé, soit il est déjà mis en cache sur notre couche de mise en cache, soit, très probablement, personne n'en a plus besoin. Ceux. L'expérience utilisateur ici s'est très bien développée grâce à des manipulations aussi simples.
Eh bien, et surtout : nous avons arrêté de perdre des données.
Disons simplement que nous nous sommes arrêtés potentiellement perdre des données, parce que nous ne les avons pas vraiment perdues. Mais il y avait un danger. Nous voyons que cette solution est certes bonne, mais elle revient un peu à atténuer les symptômes du problème, au lieu de le résoudre complètement. Et certains problèmes subsistent ici.
Premièrement, il s’agit d’un point de défaillance dans la forme de l’hôte physique lui-même sur lequel fonctionne toute cette machinerie ; il n’a pas disparu.
Deuxièmement, il y a encore des problèmes avec les SAN, leur lourde maintenance, etc. Ce n’était pas un facteur critique, mais je voulais essayer de vivre sans.
Et nous avons réalisé la troisième version (en fait, la deuxième en fait) - la version de réservation. À quoi cela ressemblait-il?
Voilà ce que c'était -
Nos principaux problèmes résident dans le fait qu’il s’agit d’un hôte physique.
Premièrement, nous supprimons les SAN parce que nous voulons expérimenter, nous voulons essayer uniquement les disques durs locaux.
Nous sommes déjà en 2014-2015, et à cette époque, la situation des disques et de leur capacité sur un hôte s'est bien améliorée. Nous avons décidé pourquoi ne pas l'essayer.
Et puis nous prenons simplement notre partition de sauvegarde et la transférons physiquement sur une machine distincte.
Ainsi, nous obtenons ce diagramme. Nous avons deux voitures qui stockent les mêmes ensembles de données. Ils se sauvegardent complètement et synchronisent les données sur le réseau via une file d'attente asynchrone dans le même MySQL.
La raison pour laquelle cela fonctionne bien est que nous avons peu d'enregistrements. Ceux. si l'écriture était comparable à la lecture, nous aurions peut-être une sorte de surcharge et de problèmes de réseau. Il y a peu d'écriture, beaucoup de lecture - cette méthode fonctionne bien, c'est-à-dire Nous copions rarement des photos entre ces deux serveurs.
Comment cela fonctionne-t-il, si vous regardez un peu plus en détail.
Télécharger. L'équilibreur sélectionne simplement des hôtes aléatoires avec une paire et les télécharge. En parallèle, il fait naturellement des contrôles de santé et s’assure que la voiture ne tombe pas. Ceux. il télécharge des photos uniquement sur un serveur en direct, puis via une file d'attente asynchrone, tout est copié sur son voisin. Avec le téléchargement, tout est extrêmement simple.
La tâche est un peu plus difficile.
Lua nous a aidé ici, car il peut être difficile de faire une telle logique sur Vanilla NGINX. Nous faisons d'abord une requête au premier serveur, pour voir si la photo est là, car potentiellement elle pourrait être téléchargée, par exemple, sur un voisin, mais n'est pas encore arrivée ici. Si la photo est là, c'est bien. Nous le donnons immédiatement au client et, éventuellement, le mettons en cache.
S'il n'y est pas, nous en faisons simplement la demande à notre voisin et sommes assurés de le recevoir de là.
Que. encore une fois, nous pouvons dire : il peut y avoir des problèmes de performances, car il y a des allers-retours constants - la photo a été téléchargée, elle n'est pas ici, nous faisons deux demandes au lieu d'une, cela devrait fonctionner lentement.
Dans notre situation, cela ne fonctionne pas lentement.
Nous collectons un tas de métriques sur ce système, et le taux d'intelligence conditionnelle d'un tel mécanisme est d'environ 95 %. Ceux. Le décalage de cette sauvegarde est faible, et grâce à cela, nous sommes presque assurés qu'une fois la photo téléchargée, nous la prendrons pour la première fois et n'aurons pas à aller nulle part deux fois.
Alors qu'avons-nous d'autre de vraiment cool ?
Auparavant, nous avions la partition de sauvegarde principale et nous la lisions de manière séquentielle. Ceux. Nous avons toujours cherché d'abord sur le principal, puis sur la sauvegarde. C'était un mouvement.
Nous utilisons désormais la lecture sur deux machines à la fois. Nous distribuons les demandes via Round Robin. Dans un petit pourcentage de cas, nous faisons deux demandes. Mais dans l’ensemble, nous disposons désormais de deux fois plus de fonds de lecture qu’auparavant. Et la charge a été considérablement réduite tant sur les machines d'envoi que directement sur les machines de stockage, que nous avions également à cette époque.
Quant à la tolérance aux pannes. En fait, c’est pour cela que nous nous sommes principalement battus. Avec la tolérance aux pannes, tout s'est bien passé ici.
Une voiture tombe en panne.
Aucun problème! Un ingénieur système peut même ne pas se réveiller la nuit, il attendra le matin et rien de grave ne se produira.
Si même si cette machine tombe en panne, la file d'attente est en panne, il n'y a pas de problèmes non plus, le journal sera simplement accumulé d'abord sur la machine vivante, puis il sera ajouté à la file d'attente, puis sur la voiture qui sera entrera en service après un certain temps.
Même chose avec l'entretien. Nous éteignons simplement l'une des machines, la retirons manuellement de tous les pools, elle cesse de recevoir du trafic, nous effectuons une sorte de maintenance, nous modifions quelque chose, puis nous la remettons en service, et cette sauvegarde rattrape son retard assez rapidement. Ceux. par jour, le temps d'arrêt d'une voiture rattrape en quelques minutes. C'est vraiment très peu. Avec la tolérance aux pannes, je le répète, tout est cool ici.
Quelles conclusions tirer de ce plan social ?
Nous avons une tolérance aux pannes.
Facile à utiliser. Étant donné que les machines disposent de disques durs locaux, cela est beaucoup plus pratique d'un point de vue opérationnel pour les ingénieurs qui travaillent avec.
Nous avons reçu une double allocation de lecture.
C'est un très bon bonus en plus de la tolérance aux pannes.
Mais il y a aussi des problèmes. Nous avons maintenant un développement beaucoup plus complexe de certaines fonctionnalités liées à cela, car le système est finalement devenu cohérent à 100 %.
Nous devons, par exemple, lors d'un travail en arrière-plan, penser constamment : « Sur quel serveur fonctionnons-nous actuellement ? », « Y a-t-il vraiment une photo actuelle ici ? » etc. Bien entendu, tout cela est terminé et, pour le programmeur qui écrit la logique métier, tout cela est transparent. Mais néanmoins, cette grande couche complexe est apparue. Mais nous sommes prêts à supporter cela en échange des cadeaux que nous en avons reçus.
Et là encore, un conflit surgit.
J'ai dit au début que tout stocker sur des disques durs locaux était une mauvaise chose. Et maintenant je dis que nous avons aimé.
Oui, en effet, au fil du temps, la situation a beaucoup changé, et cette approche présente désormais de nombreux avantages. Premièrement, nous obtenons un fonctionnement beaucoup plus simple.
Deuxièmement, c’est plus productif, car nous n’avons pas de contrôleurs automatiques ni de connexions aux étagères de disques.
Il y a une énorme quantité de machines là-bas, et ce ne sont que quelques disques qui sont assemblés ici sur la machine dans le cadre d'un raid.
Mais il y a aussi des inconvénients.
C'est environ 1,5 fois plus cher que l'utilisation de SAN, même aux prix actuels. Par conséquent, nous avons décidé de ne pas convertir hardiment l'ensemble de notre grand cluster en voitures équipées de disques durs locaux et avons décidé de laisser une solution hybride.
La moitié de nos machines fonctionnent avec des disques durs (enfin, pas la moitié – probablement 30 %). Et le reste sont de vieilles voitures qui bénéficiaient du premier système de réservation. Nous les avons simplement remontés, puisque nous n'avions pas besoin de nouvelles données ou quoi que ce soit d'autre, nous avons simplement déplacé les supports d'un hôte physique à deux.
Et nous disposons désormais d’un stock important de lectures, et nous l’avons élargi. Si auparavant nous montions un stockage sur une machine, nous en montons maintenant quatre, par exemple, sur une paire. Et ça marche bien.
Faisons un bref résumé de ce que nous avons accompli, de ce pour quoi nous nous sommes battus et si nous avons réussi.
Les résultats de
Nous avons des utilisateurs – jusqu'à 33 millions.
Nous avons trois points de présence : Prague, Miami, Hong Kong.
Ils contiennent une couche de mise en cache, composée de voitures équipées de disques locaux rapides (SSD), sur lesquelles s'exécutent des machines simples de NGINX, ses démons access.log et Python, qui traitent tout cela et gèrent le cache.
Si vous le souhaitez, vous êtes dans votre projet, si les photos ne sont pas aussi critiques pour vous qu'elles le sont pour nous, ou si le compromis contrôle/vitesse de développement et coûts des ressources est dans l'autre sens pour vous, alors vous pouvez les remplacer en toute sécurité. avec un CDN, les CDN modernes fonctionnent bien.
Vient ensuite la couche de stockage, sur laquelle nous avons des clusters de paires de machines qui se sauvegardent mutuellement, les fichiers sont copiés de manière asynchrone de l'une à l'autre à chaque fois qu'ils changent.
De plus, certaines de ces machines fonctionnent avec des disques durs locaux.
Certaines de ces machines sont connectées à des SAN.
Et, d'une part, il est plus pratique à utiliser et un peu plus productif, d'autre part, il est pratique en termes de densité de placement et de prix au gigaoctet.
Ceci est un bref aperçu de l’architecture de ce que nous avons obtenu et de la manière dont tout cela s’est développé.
Encore quelques conseils du capitaine, très simples.
Premièrement, si vous décidez soudainement que vous avez un besoin urgent d'améliorer tout ce qui concerne votre infrastructure photo, mesurez d'abord, car peut-être que rien n'a besoin d'être amélioré.
Laisse moi te donner un exemple. Nous avons un groupe de machines qui envoient des photos à partir de pièces jointes dans les chats, et le système fonctionne là-bas depuis 2009, et personne n'en souffre. Tout le monde va bien, tout le monde aime tout.
Afin de mesurer, commencez par analyser un ensemble de mesures, examinez-les, puis décidez de ce qui vous insatisfait et de ce qui doit être amélioré. Afin de mesurer cela, nous disposons d’un outil intéressant appelé Pinba.
Il vous permet de collecter des statistiques très détaillées de NGINX pour chaque code de demande et de réponse, ainsi que la répartition des temps - comme vous le souhaitez. Il est lié à toutes sortes de systèmes d'analyse différents, et vous pouvez ensuite tout examiner magnifiquement.
Nous l’avons d’abord mesuré, puis nous l’avons amélioré.
Plus loin. On optimise la lecture avec le cache, l'écriture avec le sharding, mais c'est un point évident.
Plus loin. Si vous commencez tout juste à construire votre système, il est préférable de créer des photos sous forme de fichiers immuables. Parce que vous perdez immédiatement toute une classe de problèmes d'invalidation du cache, de façon dont la logique doit trouver la bonne version de la photo, etc.
Disons que vous en avez téléchargé une centaine, puis que vous l'avez fait pivoter, faites en sorte qu'il s'agisse d'un fichier physiquement différent. Ceux. pas besoin de réfléchir : maintenant je vais gagner un peu d'espace, l'écrire dans le même fichier, changer la version. Cela ne fonctionne toujours pas bien et provoque beaucoup de maux de tête par la suite.
Point suivant. À propos du redimensionnement à la volée.
Auparavant, lorsque les utilisateurs téléchargeaient une photo, nous découpions immédiatement toute une série de tailles pour toutes les occasions, pour différents clients, et elles étaient toutes sur le disque. Maintenant, nous avons abandonné cela.
Nous n'avons laissé que trois tailles principales : petite, moyenne et grande. Nous réduisons simplement tout le reste à partir de la taille qui se trouve derrière celle qui nous a été demandée à Uport, nous faisons simplement la réduction et la donnons à l'utilisateur.
Le CPU de la couche de cache s'avère ici bien moins cher que si l'on régénérait constamment ces tailles sur chaque stockage. Disons que nous voulons en ajouter un nouveau, cela prendra un mois - exécutez partout un script qui ferait tout cela proprement, sans détruire le cluster. Ceux. Si vous avez la possibilité de choisir maintenant, il est préférable de faire le moins de tailles physiques possible, mais de manière à ce qu'au moins une certaine distribution soit, disons, de trois. Et tout le reste peut être simplement redimensionné à la volée à l'aide de modules prêts à l'emploi. Tout est très simple et accessible maintenant.
Et la sauvegarde asynchrone incrémentielle est une bonne chose.
Comme notre pratique l'a montré, ce schéma fonctionne très bien avec la copie retardée des fichiers modifiés.
Le dernier point est également évident. Si votre infrastructure n'a pas de tels problèmes actuellement, mais qu'il y a quelque chose qui peut se briser, elle se brisera certainement lorsqu'elle deviendra un peu plus grande. Par conséquent, il est préférable d’y réfléchir à l’avance et de ne pas rencontrer de problèmes. C'est tout ce que je voulais dire.
Contacts
»
»
Ce rapport est une transcription de l'un des meilleurs discours de la conférence des développeurs de systèmes à forte charge . Il reste moins d'un mois avant la conférence HighLoad++ 2017.
Nous l'avons déjà prêt , le calendrier est actuellement en train de se former activement.
Cette année, nous continuons à explorer le thème des architectures et de la mise à l'échelle :
- / Igor Vassiliev
- / Dmitri Egorov
- /Anatoli Plaskovsky
- / Roman Shekhovtsov, Alexeï Gromatchikov
- / Philippe Delgado
Nous utilisons également certains de ces matériaux dans notre formation en ligne sur le développement de systèmes à forte charge. est une chaîne de lettres, d'articles, de documents et de vidéos spécialement sélectionnés. Notre manuel contient déjà plus de 30 matériaux uniques. Connecter!
Source: habr.com