En été, l'activité d'achat et l'intensité des changements dans l'infrastructure des projets Web diminuent traditionnellement, nous explique Captain Obvious. Tout simplement parce que même les informaticiens partent parfois en vacances. Et le CTO aussi. C’est d’autant plus difficile pour ceux qui restent au pouvoir, mais là n’est pas la question maintenant : c’est peut-être pour cela que l’été est la meilleure période pour réfléchir lentement au système de réservation existant et élaborer un plan pour l’améliorer. Et l'expérience de Yegor Andreev de , dont il a parlé lors de la conférence .
Vous pouvez tomber dans plusieurs pièges lors de la création de sites de sauvegarde. Et il est absolument impossible de s’y laisser prendre. Et ce qui nous ruine dans tout ça, comme dans bien d’autres choses, c’est le perfectionnisme et… la paresse. Nous essayons de tout faire, tout, tout parfaitement, mais nous n’avons pas besoin de le faire parfaitement ! Il vous suffit de faire certaines choses, mais faites-les correctement, complétez-les pour qu'elles fonctionnent correctement.
Le basculement n’est pas une sorte de chose amusante et amusante ; c'est une chose qui devrait faire exactement une chose : réduire les temps d'arrêt afin que le service, l'entreprise, perde moins d'argent. Et dans toutes les méthodes de réservation, je propose de réfléchir dans le contexte suivant : où est l’argent ?
Premier piège: lorsque nous construisons de grands systèmes fiables et que nous pratiquons la redondance, nous réduisons le nombre d'accidents. C’est une terrible idée fausse. Lorsque nous procédons à des licenciements, nous risquons d’augmenter le nombre d’accidents. Et si nous faisons tout correctement, nous réduirons collectivement les temps d’arrêt. Il y aura davantage d’accidents, mais ils se produiront à moindre coût. Qu'est-ce qu'une réservation ? - c'est une complication du système. Toute complication est mauvaise : nous avons plus de rouages, plus d'engrenages, en un mot, plus d'éléments - et donc plus de risques de panne. Et ils vont vraiment casser. Et ils se briseront plus souvent. Un exemple simple : disons que nous avons un site Web avec PHP et MySQL. Et il faut le réserver de toute urgence.
Shtosh (c) Nous prenons le deuxième site, construisons un système identique... La complexité devient deux fois plus grande - nous avons deux entités. Nous déployons également une certaine logique pour transférer des données d'un site à un autre, c'est-à-dire la réplication des données, la copie de données statiques, etc. Ainsi, la logique de réplication est généralement très complexe et, par conséquent, la complexité totale du système peut être non pas 2, mais 3, 5, 10 fois supérieure.
Deuxième piège: lorsque nous construisons de très grands systèmes complexes, nous fantasmons sur ce que nous voulons obtenir au final. Voila : nous voulons obtenir un système ultra fiable qui fonctionne sans aucun temps d'arrêt, commute en une demi-seconde (ou mieux encore, instantanément), et nous commençons à réaliser nos rêves. Mais il y a aussi une nuance ici : plus le temps de commutation souhaité est court, plus la logique du système devient complexe. Plus nous devons rendre cette logique complexe, plus le système tombera souvent en panne. Et vous pouvez vous retrouver dans une situation très désagréable : nous essayons de toutes nos forces de réduire les temps d'arrêt, mais en fait nous compliquons tout, et quand quelque chose ne va pas, les temps d'arrêt finissent par être plus longs. Ici, on se surprend souvent à penser : eh bien... il vaudrait mieux ne pas réserver. Ce serait mieux s'il fonctionnait seul et avec des temps d'arrêt compréhensibles.
Comment pouvez-vous lutter contre cela ? Nous devons arrêter de nous mentir, cesser de nous flatter de vouloir construire un vaisseau spatial ici maintenant, mais bien comprendre combien de temps le projet peut durer. Et pendant ce temps maximum, nous choisirons quelles méthodes nous utiliserons réellement pour augmenter la fiabilité de notre système.
C'est l'heure des « histoires de w »... de la vie, bien sûr.
Exemple numéro un
Imaginez un site Web de carte de visite pour l'usine de laminage de tuyaux n° 1 dans la ville de N. Il est écrit en lettres énormes - USINE DE LAMINAGE DE TUYAUX n° 1. Juste en dessous se trouve le slogan : « Nos canalisations sont les canalisations les plus rondes de N. » Et ci-dessous se trouve le numéro de téléphone du PDG et son nom. Nous comprenons que vous devez faire une réservation - c'est une chose très importante ! Commençons par comprendre en quoi cela consiste. HTML-statique - c'est-à-dire quelques images où le directeur général, en fait, discute d'une sorte de prochain accord à la table des bains publics avec son partenaire. Nous commençons à penser aux temps d'arrêt. Cela me vient à l'esprit : il faut rester allongé là pendant cinq minutes, pas plus. Et puis la question se pose : combien de ventes y a-t-il eu sur notre site en général ? Combien-combien ? Que signifie « zéro » ? Et cela signifie : parce que le général a effectué les quatre transactions l'année dernière à la même table, avec les mêmes personnes avec qui ils vont aux bains et s'assoient à table. Et nous comprenons que même si le site reste inactif pendant une journée, rien de grave ne se produira.
Sur la base des informations introductives, il y a une journée pour raconter cette histoire. Commençons par réfléchir à un plan social. Et nous choisissons le schéma de redondance le plus idéal pour cet exemple : nous n'utilisons pas de redondance. Tout cela peut être soulevé par n'importe quel administrateur en une demi-heure avec des pauses cigarette. Installez un serveur Web, ajoutez des fichiers, c'est tout. Ça va marcher. Vous n’avez pas besoin de surveiller quoi que ce soit, vous n’avez pas besoin de prêter une attention particulière à quoi que ce soit. Autrement dit, la conclusion de l'exemple numéro un est assez évidente : les services qui n'ont pas besoin d'être réservés n'ont pas besoin d'être réservés.
Exemple numéro deux
Blog d'entreprise : des personnes spécialement formées y écrivent des nouvelles, nous avons participé à telle ou telle exposition, mais nous avons sorti un autre nouveau produit, et ainsi de suite. Disons que c'est du PHP standard avec WordPress, une petite base de données et un peu de statique. Bien sûr, je pense encore une fois qu'il ne faut en aucun cas s'allonger - « pas plus de cinq minutes ! » C'est tout. Mais réfléchissons plus loin. A quoi sert ce blog ? Les gens y viennent de Yandex, de Google sur la base de certaines requêtes, de manière organique. Super. Les ventes ont-elles quelque chose à voir là-dedans ? Epiphanie : pas vraiment. Le trafic publicitaire est dirigé vers le site principal, qui se trouve sur une autre machine. Commençons par réfléchir à un système de réservation. Dans le bon sens, il faut le lever en quelques heures, et ce serait bien de s'y préparer. Il serait raisonnable de prendre une machine d'un autre centre de données, d'y installer l'environnement, c'est-à-dire un serveur Web, PHP, WordPress, MySQL, et de le laisser là. Au moment où nous comprenons que tout est cassé, nous devons faire deux choses : déployer le dump mysql sur 50 mètres, il y volera dans une minute, et y déployer un certain nombre d'images de la sauvegarde. Cela ne durera pas non plus Dieu sait combien de temps. Ainsi, en une demi-heure, tout monte. Pas de réplication, ou Dieu me pardonne, basculement automatique. Conclusion : ce que nous pouvons déployer rapidement à partir d'une sauvegarde n'a pas besoin d'être sauvegardé.
Exemple numéro trois, plus compliqué
Boutique en ligne. PhP à cœur ouvert est un peu peaufiné, mysql avec une base solide. Beaucoup de statique (après tout, la boutique en ligne a de belles images HD et tout ça), Redis pour la session et Elasticsearch pour la recherche. Nous commençons à penser aux temps d'arrêt. Et ici, bien sûr, il est évident qu'une boutique en ligne ne peut pas rester indolore pendant une journée. Après tout, plus cela dure longtemps, plus nous perdons d’argent. Cela vaut la peine d'accélérer. Combien? Je pense que si on s'allonge pendant une heure, personne ne deviendra fou. Oui, nous allons perdre quelque chose, mais si nous commençons à travailler dur, la situation ne fera qu’empirer. Nous définissons un schéma de temps d'arrêt autorisé par heure.
Comment réserver tout cela ? De toute façon, il faut une voiture : une heure, c'est peu. Mysql : ici nous avons déjà besoin d'une réplication, d'une réplication en direct, car dans une heure, 100 Go ne seront probablement pas ajoutés au dump. Statique, images : encore une fois, dans une heure, 500 Go n'auront peut-être pas le temps d'être ajoutés. Il est donc préférable de copier les images immédiatement. Redis : c'est là que les choses deviennent intéressantes. Dans Redis, les sessions sont stockées - nous ne pouvons pas simplement les prendre et les enterrer. Car ce ne sera pas très bien : tous les utilisateurs seront déconnectés, leurs paniers seront vidés, etc. Les gens seront obligés de ressaisir leur nom d'utilisateur et leur mot de passe, et de nombreuses personnes pourraient s'en séparer et ne pas finaliser l'achat. Encore une fois, les conversions chuteront. D'un autre côté, Redis est directement à jour, les derniers utilisateurs connectés n'étant probablement pas non plus nécessaires. Et un bon compromis consiste à prendre Redis et à le restaurer à partir d'une sauvegarde d'hier ou, si vous le faites toutes les heures, d'il y a une heure. Heureusement, le restaurer à partir d'une sauvegarde signifie copier un fichier. Et l’histoire la plus intéressante est celle d’Elasticsearch. Qui a déjà opté pour la réplication MySQL ? Qui a déjà opté pour la réplication Elasticsearch ? Et pour qui est-ce que ça a fonctionné normalement après ? Ce que je veux dire, c'est que nous voyons une certaine entité dans notre système. Cela semble utile, mais c'est complexe.
Complexe dans le sens où nos collègues ingénieurs n’ont aucune expérience de travail avec cela. Ou il y a une expérience négative. Ou bien on comprend qu’il s’agit encore d’une technologie assez nouvelle avec des nuances ou de la crudité. Nous pensons... Bon sang, elastic est aussi sain, ça prend aussi beaucoup de temps pour le restaurer à partir d'une sauvegarde, que dois-je faire ? Nous comprenons qu'élastique dans notre cas est utilisé pour la recherche. Comment vend notre boutique en ligne ? Nous allons voir les spécialistes du marketing et leur demandons d'où viennent les gens. Ils répondent : « 90 % de Yandex Market viennent directement sur la fiche produit. » Et soit ils l’achètent, soit ils ne l’achètent pas. Par conséquent, la recherche est nécessaire pour 10 % des utilisateurs. Et conserver une réplication élastique, notamment entre différents centres de données dans différentes zones, comporte vraiment de nombreuses nuances. Quelle sortie ? Nous prenons l'élastique sur un site réservé et n'en faisons rien. Si l’affaire s’éternise, on en parlera peut-être un jour, mais ce n’est pas sûr. En fait, la conclusion est la même, plus ou moins : nous, encore une fois, ne réservons pas les services qui n'affectent pas l'argent. Pour garder le diagramme plus simple.
Exemple numéro quatre, encore plus difficile
Intégrateur : vendre des fleurs, appeler un taxi, vendre des marchandises, en général, n'importe quoi. Une chose sérieuse qui fonctionne 24h/7 et 5j/XNUMX pour un grand nombre d'utilisateurs. Avec une pile intéressante à part entière, où il y a des bases intéressantes, des solutions, une charge élevée et, surtout, ça fait mal de s'allonger pendant plus de XNUMX minutes. Non seulement et pas tant parce que les gens n’achèteront pas, mais parce que les gens verront que cette chose ne fonctionne pas, ils seront contrariés et ne reviendront peut-être pas du tout.
D'ACCORD. Cinq minutes. Qu'allons-nous faire à ce sujet ? Dans ce cas, nous, comme les adultes, utilisons tout l'argent pour construire un véritable site de sauvegarde, avec réplication de tout, et peut-être même automatiser au maximum le basculement vers ce site. Et en plus de cela, vous devez vous rappeler de faire une chose importante : rédiger les règles de commutation. La réglementation, même si tout est automatisé, peut être très simple. De la série "exécuter tel ou tel script ansible", "cliquez sur telle ou telle case dans la route 53" et ainsi de suite - mais cela doit être une sorte de liste exacte d'actions.
Et tout semble clair. Changer de réplication est une tâche triviale, sinon elle changera d'elle-même. La réécriture d'un nom de domaine en DNS est de la même série. Le problème est que lorsqu’un tel projet échoue, la panique commence, et même les administrateurs barbus les plus forts peuvent y être sensibles. Sans instruction claire « ouvrez le terminal, venez ici, l’adresse de notre serveur est toujours comme ça », difficile de respecter le délai de 5 minutes imparti pour la réanimation. De plus, lorsque nous utilisons ces réglementations, il est facile d'enregistrer certains changements dans l'infrastructure, par exemple, et de modifier les réglementations en conséquence.
Eh bien, si le système de réservation est très complexe et qu'à un moment donné nous avons commis une erreur, nous pouvons alors détruire notre site de sauvegarde, et en plus transformer les données en citrouille sur les deux sites - ce sera complètement triste.
Exemple numéro cinq, hardcore complet
Un service international avec des centaines de millions d'utilisateurs à travers le monde. Tous les fuseaux horaires, charge élevée à vitesse maximale, on ne peut pas du tout s'allonger. Une minute - et ce sera triste. Ce qu'il faut faire? Réservez, encore une fois, selon le programme complet. Nous avons fait tout ce dont j'ai parlé dans l'exemple précédent, et un peu plus. Un monde idéal, et notre infrastructure est conforme à tous les concepts des développeurs IaaC. Autrement dit, tout est dans git et il vous suffit d'appuyer sur le bouton.
Que manque-t-il? Un - les exercices. C'est impossible sans eux. Il semble que tout soit parfait chez nous, nous avons généralement tout sous contrôle. On appuie sur le bouton, tout se passe. Même si tel est le cas - et nous comprenons que cela ne se produit pas ainsi - notre système interagit avec d'autres systèmes. Par exemple, il s'agit du DNS de la route 53, du stockage s3, de l'intégration avec certaines API. Nous ne pourrons pas tout prévoir dans cette expérience spéculative. Et tant que nous n’aurons pas actionné l’interrupteur, nous ne saurons pas si cela fonctionnera ou non.
C'est probablement tout. Ne soyez pas paresseux et n'en faites pas trop. Et que la disponibilité soit avec vous !
Source: habr.com