Aujourd'hui, le service Bitrix24 ne dispose pas de centaines de gigabits de trafic ni d'une énorme flotte de serveurs (même si, bien sûr, il en existe un certain nombre). Mais pour de nombreux clients, c'est l'outil principal de travail dans l'entreprise, c'est une véritable application critique pour l'entreprise. Il n’y a donc aucun moyen de tomber. Et si le crash se produisait, mais que le service « récupérait » si rapidement que personne ne remarquait rien ? Et comment mettre en œuvre le basculement sans perdre en qualité de travail et en nombre de clients ? Alexander Demidov, directeur des services cloud chez Bitrix24, a expliqué pour notre blog comment le système de réservation a évolué au cours des 7 années d'existence du produit.
« Nous avons lancé Bitrix24 en tant que SaaS il y a 7 ans. La principale difficulté était probablement la suivante : avant d’être lancé publiquement en SaaS, ce produit existait simplement sous le format d’une solution box. Les clients nous l'ont acheté, l'ont hébergé sur leurs serveurs, ont mis en place un portail d'entreprise - une solution générale pour la communication avec les employés, le stockage de fichiers, la gestion des tâches, le CRM, c'est tout. Et en 2012, nous avons décidé de le lancer en mode SaaS, en l'administrant nous-mêmes, en garantissant la tolérance aux pannes et la fiabilité. Nous avons acquis de l'expérience en cours de route, car jusqu'alors nous ne l'avions tout simplement pas : nous n'étions que des fabricants de logiciels, pas des prestataires de services.
Lors du lancement du service, nous avons compris que le plus important est d'assurer la tolérance aux pannes, la fiabilité et la disponibilité constante du service, car si vous avez un simple site Web ordinaire, un magasin par exemple, et qu'il vous incombe et reste là pendant une heure, seulement vous souffrez, vous perdez des commandes, vous perdez des clients, mais pour votre client lui-même, ce n'est pas très critique pour lui. Bien sûr, il était contrarié, mais il est allé l'acheter sur un autre site. Et s'il s'agit d'une application sur laquelle sont liés tout le travail au sein de l'entreprise, les communications, les décisions, alors le plus important est de gagner la confiance des utilisateurs, c'est-à-dire de ne pas les décevoir et de ne pas tomber. Parce que tout travail peut s’arrêter si quelque chose à l’intérieur ne fonctionne pas.
Bitrix.24 en SaaS
Nous avons assemblé le premier prototype un an avant le lancement public, en 2011. Nous l'avons assemblé en une semaine environ, l'avons examiné, fait tourner - il fonctionnait même. Autrement dit, vous pourriez accéder au formulaire, y entrer le nom du portail, un nouveau portail s'ouvrirait et une base d'utilisateurs serait créée. Nous l'avons examiné, évalué le produit en principe, l'avons mis au rebut et avons continué à le perfectionner pendant une année entière. Parce que nous avions une tâche importante : nous ne voulions pas créer deux bases de code différentes, nous ne voulions pas prendre en charge un produit packagé distinct, des solutions cloud distinctes - nous voulions tout faire dans un seul code.
Une application Web typique à cette époque était un serveur sur lequel du code PHP s'exécute, une base de données MySQL, des fichiers sont téléchargés, des documents, des images sont placés dans le dossier de téléchargement - eh bien, tout fonctionne. Hélas, il est impossible de lancer un service Web d'une stabilité critique en utilisant cela. Là, le cache distribué n'est pas pris en charge, ni la réplication de la base de données.
Nous avons formulé les exigences : il s'agit de la capacité d'être localisé dans différents endroits, de prendre en charge la réplication et, idéalement, d'être situé dans différents centres de données géographiquement répartis. Séparez la logique du produit et, en fait, le stockage des données. Être capable d'évoluer dynamiquement en fonction de la charge et de tolérer complètement la statique. De ces considérations sont en effet nés les exigences du produit, que nous avons affinées au cours de l’année. Pendant ce temps, dans la plate-forme, qui s'est avérée unifiée - pour les solutions en boîte, pour notre propre service - nous avons pris en charge les choses dont nous avions besoin. Prise en charge de la réplication mysql au niveau du produit lui-même : c'est-à-dire que le développeur qui écrit le code ne pense pas à la façon dont ses requêtes seront distribuées, il utilise notre API, et nous savons comment répartir correctement les requêtes d'écriture et de lecture entre maîtres et des esclaves.
Nous avons pris en charge au niveau du produit divers stockages d'objets cloud : stockage Google, Amazon S3, ainsi que la prise en charge d'Open Stack Swift. Par conséquent, cela était pratique à la fois pour nous en tant que service et pour les développeurs qui travaillent avec une solution packagée : s'ils utilisent simplement notre API pour travailler, ils ne pensent pas à l'endroit où le fichier sera finalement enregistré, localement sur le système de fichiers ou dans le stockage du fichier objet.
De ce fait, nous avons immédiatement décidé de réserver au niveau de l’ensemble du data center. En 2012, nous nous sommes entièrement lancés sur Amazon AWS car nous avions déjà de l'expérience avec cette plateforme : notre propre site Web y était hébergé. Nous avons été attirés par le fait que dans chaque région Amazon dispose de plusieurs zones de disponibilité - en fait, (dans leur terminologie) plusieurs centres de données plus ou moins indépendants les uns des autres et nous permettent de réserver à l'échelle d'un centre de données entier : en cas de panne soudaine, les bases de données sont répliquées maître-maître, les serveurs d'applications Web sont sauvegardés et les données statiques sont déplacées vers le stockage d'objets s3. La charge est équilibrée - à l'époque par Amazon elb, mais un peu plus tard, nous sommes arrivés à nos propres équilibreurs de charge, car nous avions besoin d'une logique plus complexe.
Ce qu'ils voulaient, c'est ce qu'ils ont obtenu...
Toutes les choses de base que nous voulions garantir - la tolérance aux pannes des serveurs eux-mêmes, des applications Web, des bases de données - tout a bien fonctionné. Le scénario le plus simple : si l'une de nos applications Web tombe en panne, alors tout est simple : elles sont désactivées de l'équilibrage.
L'équilibreur (à l'époque il s'agissait de l'elb d'Amazon) marquait les machines en panne comme malsaines et désactivait la répartition de la charge sur celles-ci. L'autoscaling d'Amazon a fonctionné : lorsque la charge a augmenté, de nouvelles machines ont été ajoutées au groupe d'autoscaling, la charge a été répartie sur de nouvelles machines - tout allait bien. Avec nos équilibreurs, la logique est à peu près la même : si quelque chose arrive au serveur d'applications, nous en supprimons les requêtes, jetons ces machines, en démarrons de nouvelles et continuons à travailler. Le système a un peu changé au fil des années, mais continue de fonctionner : il est simple, compréhensible et ne pose aucune difficulté.
Nous travaillons partout dans le monde, les pics de charge des clients sont complètement différents et, à l'amiable, nous devrions pouvoir effectuer certains travaux de maintenance sur n'importe quel composant de notre système à tout moment - sans que les clients ne s'en aperçoivent. Par conséquent, nous avons la possibilité de désactiver la base de données, redistribuant ainsi la charge vers un deuxième centre de données.
Comment ça fonctionne? — Nous basculons le trafic vers un centre de données fonctionnel - s'il y a un accident au centre de données, alors complètement, s'il s'agit de notre travail prévu avec une base de données, nous transférons une partie du trafic desservant ces clients vers un deuxième centre de données, en suspendant c'est la réplication. Si de nouvelles machines sont nécessaires pour les applications Web parce que la charge sur le deuxième centre de données a augmenté, elles démarreront automatiquement. Nous terminons le travail, la réplication est restaurée et nous renvoyons la totalité de la charge. Si nous devons refléter certains travaux dans le deuxième contrôleur de domaine, par exemple installer des mises à jour du système ou modifier les paramètres de la deuxième base de données, alors, en général, nous répétons la même chose, juste dans l'autre sens. Et s'il s'agit d'un accident, alors nous faisons tout de manière triviale : nous utilisons le mécanisme de gestion d'événements dans le système de surveillance. Si plusieurs vérifications sont déclenchées et que le statut passe à critique, alors nous exécutons ce gestionnaire, un gestionnaire qui peut exécuter telle ou telle logique. Pour chaque base de données, nous spécifions quel serveur assure le basculement et où le trafic doit être commuté s'il n'est pas disponible. Historiquement, nous utilisons nagios ou certaines de ses fourchettes sous une forme ou une autre. En principe, des mécanismes similaires existent dans presque tous les systèmes de surveillance ; nous n’utilisons pas encore quelque chose de plus complexe, mais peut-être que nous le ferons un jour. Désormais, la surveillance est déclenchée en cas d'indisponibilité et a la capacité de changer quelque chose.
Avons-nous tout réservé ?
Nous avons de nombreux clients des États-Unis, de nombreux clients d’Europe, de nombreux clients plus proches de l’Est – Japon, Singapour, etc. Bien entendu, une grande partie des clients se trouvent en Russie. Autrement dit, le travail ne se fait pas dans une seule région. Les utilisateurs veulent une réponse rapide, il existe des exigences pour se conformer à diverses lois locales et, dans chaque région, nous réservons deux centres de données, ainsi que des services supplémentaires qui, encore une fois, sont pratiques à placer dans une région - pour les clients qui se trouvent dans cette région fonctionne. Gestionnaires REST, serveurs d'autorisation, ils sont moins critiques pour le fonctionnement du client dans son ensemble, vous pouvez les parcourir avec un petit délai acceptable, mais vous ne voulez pas réinventer la roue sur la façon de les surveiller et quoi faire avec eux. Par conséquent, nous essayons d'utiliser au maximum les solutions existantes, plutôt que de développer une sorte de compétence dans des produits supplémentaires. Et quelque part, nous utilisons trivialement la commutation au niveau DNS, et nous déterminons la vivacité du service par le même DNS. Amazon propose un service Route 53, mais ce n'est pas seulement un DNS dans lequel vous pouvez effectuer des entrées et c'est tout : c'est beaucoup plus flexible et pratique. Grâce à lui, vous pouvez créer des services géodistribués avec géolocalisation, lorsque vous l'utilisez pour déterminer d'où vient le client et lui fournir certains enregistrements - avec son aide, vous pouvez créer des architectures de basculement. Les mêmes contrôles de santé sont configurés dans Route 53 lui-même, vous définissez les points de terminaison qui sont surveillés, définissez les métriques, définissez les protocoles pour déterminer la « vivacité » du service - TCP, http, https ; définir la fréquence des contrôles qui déterminent si le service est actif ou non. Et dans le DNS lui-même, vous spécifiez ce qui sera principal, ce qui sera secondaire, où basculer si le contrôle de santé est déclenché à l'intérieur de la route 53. Tout cela peut être fait avec d'autres outils, mais pourquoi est-ce pratique - nous le définissons levez-vous une fois et ne réfléchissez pas du tout à la façon dont nous effectuons les contrôles, à la façon dont nous changeons : tout fonctionne tout seul.
Le premier "mais": comment et avec quoi réserver la route 53 elle-même ? Qui sait, et s'il lui arrivait quelque chose ? Heureusement, nous n'avons jamais marché sur ce râteau, mais encore une fois, je vais vous raconter une histoire expliquant pourquoi nous pensions que nous devions encore faire une réservation. Ici, nous nous sommes préparés des pailles à l'avance. Plusieurs fois par jour, nous effectuons un déchargement complet de toutes les zones que nous avons sur la route 53. L'API d'Amazon vous permet de les envoyer facilement en JSON, et nous disposons de plusieurs serveurs de sauvegarde sur lesquels nous les convertissons, les téléchargeons sous forme de configurations et disposons, en gros, d'une configuration de sauvegarde. Si quelque chose se produit, nous pouvons le déployer rapidement manuellement sans perdre les données des paramètres DNS.
Deuxième "mais": Qu'est-ce qui dans cette photo n'a pas encore été réservé ? L'équilibreur lui-même ! Notre répartition des clients par région est rendue très simple. Nous avons les domaines bitrix24.ru, bitrix24.com, .de - il en existe désormais 13 différents, qui opèrent dans diverses zones. Nous sommes arrivés au résultat suivant : chaque région a ses propres équilibreurs. Cela rend plus pratique la répartition entre les régions, en fonction de l'endroit où se situe la charge de pointe sur le réseau. S'il s'agit d'une panne au niveau d'un seul équilibreur, alors il est simplement mis hors service et supprimé du DNS. S'il y a un problème avec un groupe d'équilibreurs, ils sont alors sauvegardés sur d'autres sites et la commutation entre eux s'effectue en utilisant la même route53, car en raison du TTL court, la commutation se produit dans un délai maximum de 2, 3, 5 minutes. .
Troisième "mais": Qu'est-ce qui n'est pas encore réservé ? S3, c'est exact. Lorsque nous avons placé les fichiers que nous stockons pour les utilisateurs dans s3, nous pensions sincèrement que c'était perforant et qu'il n'était pas nécessaire d'y réserver quoi que ce soit. Mais l’histoire montre que les choses se passent différemment. En général, Amazon décrit S3 comme un service fondamental, car Amazon lui-même utilise S3 pour stocker des images machine, des configurations, des images AMI, des instantanés... Et si s3 plante, comme cela s'est produit une fois au cours de ces 7 années, aussi longtemps que nous utilisons bitrix24, il le suit comme un fan. Il y a tout un tas de choses qui arrivent – impossibilité de démarrer les machines virtuelles, panne d'API, etc.
Et S3 peut tomber - c'est arrivé une fois. Par conséquent, nous sommes arrivés au schéma suivant : il y a quelques années, il n'y avait pas d'installations sérieuses de stockage d'objets publics en Russie, et nous avons envisagé la possibilité de faire quelque chose par nous-mêmes... Heureusement, nous n'avons pas commencé à le faire, car nous le ferions Nous avons puisé dans une expertise que nous n'avons pas et nous ferions probablement des erreurs. Désormais, Mail.ru dispose d'un stockage compatible s3, Yandex l'a et un certain nombre d'autres fournisseurs l'ont. Nous sommes finalement arrivés à l'idée que nous souhaitions avoir, d'une part, une sauvegarde et, d'autre part, la possibilité de travailler avec des copies locales. Pour la région russe spécifiquement, nous utilisons le service Mail.ru Hotbox, qui est compatible API avec s3. Nous n'avons pas eu besoin de modifications majeures du code à l'intérieur de l'application et nous avons créé le mécanisme suivant : dans s3, il y a des déclencheurs qui déclenchent la création/suppression d'objets, Amazon a un service appelé Lambda - il s'agit d'un lancement de code sans serveur qui sera exécuté juste au moment où certains déclencheurs sont déclenchés.
Nous l'avons fait très simplement : si notre déclencheur se déclenche, nous exécutons le code qui copiera l'objet dans le stockage Mail.ru. Pour lancer pleinement le travail avec des copies locales de données, nous avons également besoin d'une synchronisation inverse afin que les clients du segment russe puissent travailler avec un stockage plus proche d'eux. Mail est sur le point de terminer les déclencheurs dans son stockage - il sera possible d'effectuer une synchronisation inverse au niveau de l'infrastructure, mais pour l'instant nous le faisons au niveau de notre propre code. Si nous voyons qu'un client a publié un fichier, alors au niveau du code, nous plaçons l'événement dans une file d'attente, le traitons et effectuons une réplication inverse. Pourquoi c'est mauvais : si nous effectuons une sorte de travail avec nos objets en dehors de notre produit, c'est-à-dire par des moyens externes, nous n'en tiendrons pas compte. Par conséquent, nous attendons la fin, lorsque les déclencheurs apparaissent au niveau du stockage, afin que peu importe d'où nous exécutons le code, l'objet qui nous est parvenu soit copié dans l'autre sens.
Au niveau du code, nous enregistrons les deux stockages pour chaque client : l'un est considéré comme le principal, l'autre est considéré comme celui de sauvegarde. Si tout va bien, nous travaillons avec le stockage le plus proche de nous : c'est-à-dire que nos clients qui sont sur Amazon travaillent avec S3, et ceux qui travaillent en Russie, ils travaillent avec Hotbox. Si l'indicateur est déclenché, le basculement doit être connecté et nous basculons les clients vers un autre stockage. Nous pouvons cocher cette case indépendamment par région et les alterner. Nous ne l'avons pas encore utilisé dans la pratique, mais nous avons prévu ce mécanisme et nous pensons qu'un jour nous aurons besoin de ce même commutateur et que cela nous sera utile. Cela est déjà arrivé une fois.
Oh, et Amazon s'est enfui...
Ce mois d'avril marque l'anniversaire du début du blocage de Telegram en Russie. Le fournisseur le plus concerné est Amazon. Et malheureusement, les entreprises russes qui travaillaient pour le monde entier ont souffert davantage.
Si l'entreprise est mondiale et que la Russie ne représente qu'un très petit segment, 3 à 5 % - eh bien, d'une manière ou d'une autre, vous pouvez les sacrifier.
S'il s'agit d'une entreprise purement russe - je suis sûr qu'elle doit être implantée localement - eh bien, ce sera simplement pratique pour les utilisateurs eux-mêmes, confortable et il y aura moins de risques.
Et s’il s’agissait d’une entreprise opérant à l’échelle mondiale et comptant un nombre à peu près égal de clients en Russie et ailleurs dans le monde ? La connectivité des segments est importante et ils doivent fonctionner les uns avec les autres d’une manière ou d’une autre.
Fin mars 2018, Roskomnadzor a envoyé une lettre aux plus grands opérateurs indiquant qu'ils prévoyaient de bloquer plusieurs millions d'IP Amazon afin de bloquer... le messager Zello. Grâce à ces mêmes fournisseurs, ils ont réussi à divulguer la lettre à tout le monde et il était entendu que la connexion avec Amazon pourrait s'effondrer. C'était vendredi, nous avons couru en panique vers nos collègues de serveurs.ru, avec les mots : « Mes amis, nous avons besoin de plusieurs serveurs qui ne seront pas situés en Russie, ni sur Amazon, mais, par exemple, quelque part à Amsterdam. » afin de pouvoir y installer au moins d'une manière ou d'une autre notre propre VPN et proxy pour certains points de terminaison sur lesquels nous ne pouvons en aucun cas influencer, par exemple les points de terminaison du même s3 - nous ne pouvons pas essayer de créer un nouveau service et d'obtenir un autre IP, tu dois encore y arriver. En quelques jours seulement, nous avons installé ces serveurs, les avons mis en service et, de manière générale, préparé le moment où le blocage commençait. Il est curieux que RKN, face à l’agitation et à la panique, ait déclaré : « Non, nous ne bloquerons rien maintenant. » (Mais c'est exactement jusqu'au moment où Telegram a commencé à être bloqué.) Après avoir mis en place les capacités de contournement et réalisé que le blocage n'avait pas été introduit, nous n'avons cependant pas commencé à régler toute l'affaire. Oui, juste au cas où.
Et en 2019, nous vivons toujours dans des conditions de blocage. J'ai regardé hier soir : environ un million d'IP continuent d'être bloquées. Il est vrai qu'Amazon a été presque entièrement débloqué, à son apogée il a atteint 20 millions d'adresses... En général, la réalité est qu'il n'y a peut-être pas de cohérence, de bonne cohérence. Soudainement. Cela n’existe peut-être pas pour des raisons techniques – incendies, excavatrices, tout ça. Ou, comme nous l’avons vu, pas entièrement technique. Par conséquent, quelqu'un de grand et de grand, avec ses propres AS, peut probablement gérer cela d'autres manières - la connexion directe et d'autres choses sont déjà au niveau l2. Mais dans une version simple, comme la nôtre ou encore plus petite, vous pouvez, au cas où, avoir une redondance au niveau des serveurs élevés ailleurs, configurés à l'avance vpn, proxy, avec la possibilité de basculer rapidement la configuration vers eux dans ces segments qui sont essentiels à votre connectivité. Cela nous a été utile plus d’une fois lorsque le blocage d’Amazon a commencé : dans le pire des cas, nous n’autorisions que le trafic S3 à travers eux, mais peu à peu tout cela a été résolu.
Comment réserver... un prestataire entier ?
À l’heure actuelle, nous n’avons pas de scénario au cas où l’ensemble de l’Amazonie s’effondrerait. Nous avons un scénario similaire pour la Russie. En Russie, nous étions hébergés chez un seul fournisseur, chez qui nous avons choisi d'avoir plusieurs sites. Et il y a un an, nous avons été confrontés à un problème : même s’il s’agit de deux centres de données, il peut déjà y avoir des problèmes au niveau de la configuration du réseau du fournisseur qui affecteront toujours les deux centres de données. Et nous pourrions finir par être indisponibles sur les deux sites. Bien sûr, c'est ce qui s'est passé. Nous avons fini par reconsidérer l'architecture intérieure. Cela n’a pas beaucoup changé, mais pour la Russie, nous avons désormais deux sites, qui ne proviennent pas du même fournisseur, mais de deux fournisseurs différents. Si l’un échoue, nous pouvons passer à l’autre.
Hypothétiquement, pour Amazon nous envisageons la possibilité de réservation au niveau d'un autre fournisseur ; peut-être Google, peut-être quelqu'un d'autre... Mais jusqu'à présent, nous avons observé dans la pratique que si Amazon connaît des accidents au niveau d'une zone de disponibilité, les accidents au niveau d'une région entière sont assez rares. Nous avons donc théoriquement l’idée de faire une réserve « Amazon n’est pas Amazon », mais en pratique ce n’est pas encore le cas.
Quelques mots sur l'automatisation
L’automatisation est-elle toujours nécessaire ? Il convient ici de rappeler l’effet Dunning-Kruger. Sur l’axe « x » se trouvent nos connaissances et l’expérience que nous acquérons, et sur l’axe « y » se trouve la confiance dans nos actions. Au début, nous ne savons rien et n’en sommes pas du tout sûrs. Ensuite, nous en savons un peu plus et devenons méga-confiants - c'est ce qu'on appelle le « pic de la stupidité », bien illustré par l'image « démence et courage ». Ensuite, nous avons appris un peu et sommes prêts à aller au combat. Ensuite, nous commettons des erreurs très graves et nous nous retrouvons dans une vallée de désespoir, lorsque nous semblons savoir quelque chose, mais en fait nous ne savons pas grand-chose. Puis, à mesure que nous acquérons de l’expérience, nous devenons plus confiants.
Notre logique concernant les différents passages automatiques à certains accidents est très bien décrite par ce graphique. Nous avons commencé - nous ne savions rien faire, presque tout le travail était fait à la main. Ensuite, nous avons réalisé que nous pouvions associer l’automatisation à tout et dormir paisiblement. Et soudain, nous marchons sur un méga-rake : un faux positif est déclenché, et nous changeons de trafic alors que, dans le bon sens, nous n’aurions pas dû le faire. Par conséquent, la réplication échoue ou autre chose – c’est la véritable vallée du désespoir. Et puis nous comprenons que nous devons aborder tout avec sagesse. Autrement dit, il est logique de s'appuyer sur l'automatisation, en prévoyant la possibilité de fausses alarmes. Mais! si les conséquences peuvent être dévastatrices, il vaut mieux s'en remettre à l'équipe de service, aux ingénieurs de service, qui s'assureront et surveilleront qu'il y a bien un accident, et effectueront manuellement les actions nécessaires...
Conclusion
En 7 ans, nous sommes passés du fait que quand quelque chose tombait, c'était la panique, à la compréhension que les problèmes n'existent pas, il n'y a que des tâches, elles doivent - et peuvent - être résolues. Lorsque vous créez un service, regardez-le d'en haut, évaluez tous les risques qui peuvent survenir. Si vous les voyez tout de suite, prévoyez à l'avance la redondance et la possibilité de construire une infrastructure tolérante aux pannes, car tout point pouvant échouer et conduire à l'inopérabilité du service le fera certainement. Et même s'il vous semble que certains éléments de l'infrastructure ne tomberont certainement pas en panne - comme le même s3, gardez toujours à l'esprit qu'ils le peuvent. Et au moins en théorie, ayez une idée de ce que vous en ferez si quelque chose arrive. Ayez un plan de gestion des risques. Lorsque vous envisagez de tout faire automatiquement ou manuellement, évaluez les risques : que se passera-t-il si l'automatisation commence à tout commuter - cela ne conduira-t-il pas à une situation encore pire qu'un accident ? Peut-être est-il nécessaire quelque part de trouver un compromis raisonnable entre l'utilisation de l'automatisation et la réaction de l'ingénieur de service, qui évaluera la situation réelle et comprendra si quelque chose doit être commuté sur place ou « oui, mais pas maintenant ».
Un compromis raisonnable entre le perfectionnisme et les efforts réels, le temps et l'argent que vous pouvez consacrer au projet que vous finirez par avoir.
Ce texte est une version mise à jour et élargie du rapport d'Alexandre Demidov lors de la conférence .
Source: habr.com