Nous fabriquons le meilleur système de détection d'emprunt en Russie et dans les pays voisins. Dans un monde idéal, nous ne traiterions que de la conception et du développement du système. Mais, hélas, l'anti-plagiat ne fonctionne pas dans le vide, et pour que nos utilisateurs puissent utiliser nos développements de manière pratique et confortable, nous devons également développer l'environnement entourant notre service. Notre logiciel ne fonctionne pas encore sans fer, les utilisateurs doivent fournir un support technique, il est nécessaire de recevoir le paiement des utilisateurs sans enfreindre la loi, etc. Bref, la routine suffit.

Cet article est le premier d'une série de drames de production sur la façon dont nous avons amélioré notre service grâce à l'externalisation. Nous partageons de vrais problèmes et conclusions.

Nuages, chevaux blonds ...

^{(de quelque part sur Internet, je l'ai vu pour la première fois ici .)}

La charge sur notre système est très inégale: tout d'abord, pendant la journée, la charge change 5 fois. Deuxièmement, il y a une saisonnalité prononcée. Le maximum quotidien de contrôles après la fin de la session d'été est réduit de 10 fois! La session d'hiver n'est pas si brillante, mais pas non plus un cadeau. De plus, chaque session d'été suivante est plus lourde (en termes de nombre de contrôles) et plus difficile (nouvelles technologies de recherche et fonctionnalités) que la précédente. Par conséquent, d'une part, je veux avoir un bon approvisionnement en ressources, d'autre part, ne payez pas trop lors d'une baisse d'activité. Dans une session, vous pouvez déployer plus de serveurs et, en été, réduire la quantité de ressources consommées. Évidemment, c'est juste le cas avec les fournisseurs de cloud. Dans cet article, je parlerai de divers aspects de l'interaction avec plusieurs fournisseurs de cloud (AWS, IT Grad, MCS, YC). S'il semble à quelqu'un qu'il s'agit d'un cri de l'âme, il ne se trompera pas beaucoup. Alors allons-y!

Aws

Nous avons commencé à utiliser les ressources cloud en février 2013 lorsque nous avons loué notre premier serveur dans AWS. En fait, Amazon est la première et la plus longue expérience d'Anti-Plagiat avec les nuages. Ensuite, nous avons commencé avec une seule machine, et maintenant notre budget dans AWS est un ordre de grandeur supérieur à celui de tous les clouds russes. Le premier amour, comme vous le savez, n'est jamais oublié. J'ai considéré tous les problèmes et opportunités avec d'autres clouds dans cet article en fonction de mon expérience avec AWS.

Certes, il y avait aussi une mouche dans la pommade dans les relations avec Amazon. Voici les fonctionnalités ou les inconvénients que nous avons avec Amazon:

1. Vous ne pouvez pas accéder à la console d'une machine virtuelle via un navigateur. Et parfois, c'est vraiment nécessaire ici! Une fois que nous avons supprimé par erreur l'interface réseau, et l'accès a été perdu sur l'une des machines. Heureusement que quelqu'un avait déjà rencontré un tel problème, en une demi-heure nous avons trouvé et appliqué avec succès la solution. Grâce à la console, une telle opération pourrait se faire en une minute.
2. Les coûts sont en dollars et nous gagnons en roubles. Par conséquent, la rentabilité dépend du dollar.
3. Il n'y a pas de centre de données en Russie, le plus proche lorsque nous avons commencé était en Irlande. Cela signifie un grand ping et certaines restrictions sur le stockage des données qui surviennent en raison des exigences de la loi russe.
4. Roskomnadzor bloque régulièrement les adresses AWS. Actuellement, il existe différentes disponibilités de serveur dans AWS à partir de différents sites. Pour des raisons inconnues, la connexion à la machine peut tomber. Habituellement, la modification de l'adresse IP, du VPN et du proxy aide.
5. Amazon est nettement plus cher que les nuages ​​russes. Certes, vous pouvez réduire les coûts grâce à un programme de sauvegarde flexible et à l'utilisation d' instances ponctuelles . Et nous utilisons activement les deux. Hélas, nous n'avons pas encore vu une telle fonctionnalité dans les clouds domestiques (upd: YC a annoncé "VMs interrompues" dans la newsletter du 18 février, nous attendons les détails).
6. Le problème des messages insuffisamment informatifs. Lors du passage de la 3e génération de machines à la 4e ou à la 5e, le matériel virtuel a sérieusement changé, notamment la méthode de connexion des disques, et les machines n'ont tout simplement pas démarré après le changement de type. L'interface de gestion d'instance a renvoyé un message concis: capacité insuffisante. Il y avait suffisamment de limites pour créer les types de machines nécessaires avec une marge, et pendant environ six mois, nous avons essayé sans succès le support technique gratuit pour modifier les limites. Ça n'a pas aidé. En conséquence, ils ont googlé la solution eux-mêmes - une récréation banale des machines aide.
7. À quelques reprises, nous avons effacé les SSD dans les trous: les disques ont simplement disparu du système avec toutes les données. Étant donné qu'il s'agissait de disques éphémères , c'est-à-dire les données sont perdues lorsque la machine s'arrête, nous n'y avons pas stocké quelque chose d'irremplaçable.

En principe, il était possible de vivre avec ces lacunes. Cependant, exactement au moment où Amazon a finalement remarqué le marché russe, notre compte n'est pas devenu très pratique pour le paiement à partir d'une carte. Heureusement, Amazon a rapidement corrigé la situation et nous a fourni un gestionnaire de compte qui nous a aidés à passer du paiement par carte à un contrat direct, à payer une facture et à rédiger divers types d'accords. En général, il vient régulièrement en Russie, et lorsqu'il vient chez nous, il parle des opportunités d'optimisation des infrastructures et des paiements. Parfois, il apporte avec lui un architecte de solution, avec qui il peut discuter de l'architecture actuelle de notre solution, parler de «liste de souhaits» et des problèmes, et obtenir plusieurs solutions, non seulement via les services AWS. Les employés d'Amazon déclarent que leur objectif n'est pas de fournir plus de services, mais de faire en sorte que les services achetés profitent à l'entreprise. Il semble que ce soit vraiment vrai. Le nombre de services, la rapidité de leur développement et la profondeur de l'intégration mutuelle sont impressionnants. AWS a tout pour organiser à la fois le processus de développement et le fonctionnement de systèmes hautement chargés de toutes tailles. Jusqu'à présent, un seul problème mondial coûte cher!

IT Grad 2016

En 2015, nous avons décidé qu'il était temps pour nous d'abandonner complètement notre propre fer. Je voulais poser les problèmes de fiabilité des équipements spécifiquement sur les autres et me concentrer davantage sur l'amélioration des processus de notre propre développement. Selon nos prévisions, en 2016, nous aurions eu assez de matériel que nous avions en ce moment, et nous aimerions avoir une réserve pour chaque incendie. Nous avons soigneusement abordé le choix du fournisseur: nous avons préparé pour nous un test de charge et un questionnaire avec des questions importantes et avons méticuleusement choisi parmi cinq fournisseurs: ActiveCloud, Cloud4Y, CloudOne, IT Grad, Softline.

En conséquence, nous avons opté pour les nuages ​​IT Grad. Leurs avantages:

1. Position de vie active, les réponses à nos questions ont été données rapidement, il était facile de communiquer.
2. La présence de disques SSD rapides, jusqu'à 30 IOPS par Go. Le nombre d'opérations de lecture aléatoire est un indicateur très important pour nous, car des valeurs élevées nous permettent de placer nos modules de scan dans le cloud.
3. Plateforme VCloud avec la possibilité de contrôler les machines et la présence d'une console pour chaque machine.
4. La possibilité d'augmenter les ressources d'une machine virtuelle sans redémarrer.
5. Facturation flexible - le paiement est effectué pour les ressources qui étaient utilisées le jour au milieu de la période de rapport (le 14-15e jour de chaque mois). De plus, il existe une option «Pay-As-You-Go», mais elle est plus chère et le calcul de la quantité de ressources consommées est effectué par la charge moyenne du CPU et de la RAM toutes les 2 heures.

En 2016, nous avons déménagé à IT Grad. Voici ce qui s'est passé au cours des trois années incomplètes de notre vie commune:

1. Une fois, nous avons eu un problème. Exactement à 21h00, un étrange recul des performances a commencé. Le nombre de contrôles que le système pouvait effectuer est passé de 150 à 20-30 par minute, alors qu'au bout de quelques heures, tout a été restauré et résolu à une vitesse de 600 contrôles par minute. Nous avons cherché pendant une semaine à la maison, vérifié les utilisateurs, attrapé des bots et des DDoS, mais nous n'avons rien trouvé. Nous nous sommes tournés vers le support de IT-Grad, avons découvert que "oh, et nous faisons des sauvegardes ici." En conséquence, ils nous ont écrasés avec une source de problèmes sur différents systèmes de disques et ont mis en place le travail.
2. Habituellement (caractéristiques de l'utilisation du produit), pendant une session, notre trafic dépasse 100 mégabits par seconde. Soit dit en passant, cette valeur est souvent définie par défaut pour le canal non réservé dans de nombreux fournisseurs de cloud. Lorsque nous avons franchi cette frontière pour la première fois, un certain nombre de problèmes sont survenus: l'Edge intégré ne pouvait pas faire face au VPN entre le point d'entrée situé sur notre équipement et la machine virtuelle du serveur Web située dans le cloud. Comme prévu, ils se sont tournés vers le support, où on nous a proposé d'augmenter les ressources sur Edge. Ok, pas de doute, nous avons remplacé sa configuration de petite à grande, et avons également étendu le canal à la taille de notre trafic de pointe avec une marge. Ça n'a pas aidé. En général, nous n'avons pas pu trouver la solution optimale, j'ai dû réduire le volume de trafic en déplaçant une partie de la production vers d'autres sites.
3. La connexion VPN au site IT Grad est parfois interrompue pendant 1 à 2 minutes. À la question de savoir pourquoi cela se produit, ni nous ni le support technique ne pouvons trouver la réponse. Jusqu'à présent, je dois vivre avec ce problème.
4. Le mécanisme de redimensionnement des ressources fonctionne mal, à la fois à la volée et hors tension. Il me semble cependant que c'est plutôt un problème avec le fournisseur de la plateforme (VMware). Néanmoins, nous avons déjà rencontré le fait que pour appliquer de manière fiable toutes les extensions, il était nécessaire de redémarrer la machine invitée (Windows Server 2012 R2). Après le redimensionnement, la machine elle-même n'a pas démarré plusieurs fois. Le support a résolu ce problème de 2 à 4 heures du matin pendant la session - notre saison même. Il faisait chaud même la nuit!
5. En 2016, nous avions un énorme monolithe, comme l'Everest, qui nécessitait beaucoup de ressources. Tellement que nous devions parfois dépasser la taille maximale des machines invitées recommandées pour un hôte donné. Le support nous a constamment demandé de réduire la taille des machines virtuelles à au moins la moitié de la taille de l'hôte. Nous devons rendre hommage à IT Grad - on nous a proposé d’utiliser un matériel distinct avec la possibilité de l’utiliser entièrement pour quelques autres gros investissements, et la flexibilité du cloud a été perdue.
6. Facturer une fois par mois pour mesurer la quantité de ressources consommées nous a joué deux fois un tour. Au tout début, nous avons directement posé la question de l'opportunité de réduire les ressources le 14-15 du mois afin de payer moins. On nous a répondu directement que c'est ainsi que cela fonctionne. La première fois, cela nous a frappé douloureusement lors du transfert d'une partie de la vente vers notre cloud. Le facteur humain a fonctionné - ils ont essayé de tout finir rapidement avant le 14, puis ils l'ont ratissé notamment. La deuxième fois, nous avons saisi cette opportunité après près de 3 ans de coopération, après quoi nous avons été facturés en moyenne le 5, 15, 20. Ensuite, le facteur humain a fonctionné pour eux - après l'appel, il s'est avéré qu'ils ont fait une erreur en leur faveur (le recalcul a été fait manuellement), s'est excusé et a accordé une remise.
7. Les performances des disques et des machines dans leur ensemble ont répondu aux caractéristiques déclarées. Néanmoins, plusieurs fois, nous ne pouvions pas comprendre pourquoi tout fonctionnait si lentement, même l'interface ralentissait sans pitié. Le support a assuré que tout était en ordre et ils n'ont eu aucun problème avec l'équipement. Ce qui s'est passé là-bas - notre serveur à ce moment-là a migré vers un hôte voisin ou quelqu'un a fait une sauvegarde du sous-système de disque - cela reste un mystère pour nous.
8. Les disques peuvent être commutés entre les machines indépendamment uniquement via le support. Au début de l'utilisation, il était impossible d'avoir des disques de types différents dans la machine, il fallait en sortir (iSCSI, Samba et NFS). Après un certain temps, l'utilisation de différents types de disques sur une machine est devenue possible d'abord via le support, puis de manière autonome (apparemment fait dans vCloudDirector). Soit dit en passant, la mise à jour du système de gestion de la virtualisation a lieu régulièrement. Nous recevons une lettre 1 à 2 fois par mois indiquant que pendant une heure ou deux, le système de contrôle des machines virtuelles prend des tâches techniques et ne sera pas disponible pendant un certain temps, les machines elles-mêmes continuent de fonctionner à ce moment.
9. Le 16 février 2018, une partie de nos ventes situées à IT Grad était due à des problèmes d'alimentation électrique du centre de données dans lequel se trouvait l'équipement. Nous avons eu connaissance de l'incident de facto; nous n'avons pas pu contacter le support technique. J'ai dû appeler notre gestionnaire de compte, il a immédiatement dit dans une minute quoi et comment, et s'est éteint, apparemment en disant au reste. De l'agréable - nous étions allongés à côté de VKontakte.

Après avoir passé quelque temps dans une maison louée et confronté à tout ce qui précède, en 2017, nous avons décidé qu'il était bon de visiter, mais mieux à la maison, et nous avons commencé à créer un cloud avec des disques NVMe rapides et la possibilité de tout contrôler complètement. Aussitôt dit, aussitôt fait: ils ont déplacé les ventes vers leur cloud de clients d'entreprise et de modules de recherche (au total plus de 90% de la charge), laissant la surveillance, les statistiques et les clients privés dans IT Grad. En 2018, tout le monde a de nouveau tout calculé et il s'est avéré qu'il était plus rentable de diviser la production: garder une partie dans le cloud loué, et une partie dans la leur. Qu'est-il advenu de cela?

Solutions cloud de messagerie

Honnêtement, je voulais, comme dans AWS, mais en Russie. Par conséquent, nous avons commencé à regarder vers les nuages ​​avec des ensembles de services similaires (que je trompe, au moins avec l'analogue de EC2 et S3). La recherche a été de courte durée - nous avons trouvé "l'Amazonie russe" en la personne de MCS . Une grande entreprise avec une large gamme de services divers, selon toutes les indications, ils devraient être en mesure de préparer les nuages!

Le début de la rencontre a été merveilleux. Un gestionnaire de compte est venu à notre bureau, a tout expliqué en détail, a décrit les opportunités et les plans actuels pour un avenir proche. La sortie était une image merveilleuse: des prix bas pour les ressources informatiques, il y a un stockage d'objets et une sortie précoce de la production de bases de données (similaire à RDS). Nous avons également reçu une limite de trésorerie solide pour les tests (encore plus que ce qu'Azure donne).

À ce moment-là, nous avions déjà la partie IaC prête à déployer toutes les machines via terraform. MCS avait openstack et il était bien supporté! Soit dit en passant, le support technique est assuré par un canal de télégramme - communication «en direct» et il est clair qu'ils veulent aider. Il existe un système de ticket, mais nous ne l'avons pas encore utilisé. Le SLA du support technique fait référence aux demandes créées dans le système de ticket.

En décembre 2018, nous avions écrit des scripts de déploiement d'infrastructure via terraform. Il est temps de bouger. Pour commencer, nous avons décidé de transférer le système avec des clients privés, qui vivaient tout ce temps sur des équipements en IT Grad. Alors tout est comme dans un film:

7 (), 18:00 . , .
10 (), 10:00 – .
12 () – .
10:00 terraform. , , .
12:00 ansible'. . !
15:30 . 30 , 16:30.
15:45 . .
15:55 . : , .
16:20 , . , . , - .
17:30 , , .
18:00 . 1,5 .


Le problème identifié avec différents formats avec une nouvelle tentative n'aurait pas dû apparaître, mais nous l'avons trouvé et juste au cas où corrigé.

17 (), .
15:30 . , .
16:00 . .
16:30 , 100%. -? !
17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. .
21:45 , , , 2000 .
22:00 , .


L'ancien prod sur IT Grad a facilement satisfait la demande différée de contrôles utilisateur, pas de problème.

Le lendemain (18 décembre), nous avons réalisé ce qui suit:

1. Nous ne savions pas ce qui ralentissait spécifiquement le système. Avant la frise, il n'y avait pratiquement aucune charge nulle part. Oui, nous avons toujours des appels de blocage profonds à l'intérieur du système et très probablement il y a un blocage quelque part, mais où exactement, nous n'avons pas pu trouver, il était nécessaire de poursuivre l'enquête.
2. Notre test de charge actuel ne correspond pas au profil de charge de la prod. C'était incroyable parce que grâce à ce test, nous avons préparé la dernière session, identifié et éliminé un grand nombre de goulots d'étranglement. Mais telle est la réalité - il faut refaire le test en tenant compte de l'expérience acquise.
3. Produite sur IT Grade avec des ressources CPU et RAM comparables, elle peut facilement supporter deux fois la charge.

Ainsi, nous avons rapidement construit un test qui atteint le même résultat que nous avons vu de première main. Nous sommes allés au support MCS pour savoir si nous mangeons une limite de CPU, mais en général, c'est la nôtre complètement ou pas, et tout va bien avec le réseau. Ils n'ont toujours pas répondu à la deuxième question, ils ont trouvé quelque chose sur la troisième et nous ont recommandé de faire des changements pour les systèmes multicœurs. En général, nous avons développé une activité dynamique, la fin de l'année approche et tout le monde veut partir en vacances avec un sentiment d'accomplissement.

Voici ce que nous avons fini par travailler avec MCS:

1. Même au stade de la sélection, on nous a envoyé un tableau avec les caractéristiques du matériel virtuel et du SLA par disque. L'un des avantages était qu'ils avaient promis 50 IOPS / Go (IT Grad: 30 IOPS / GB) pour le SSD. Le contrat s'est avéré différent: «lecture: 5000 IOPS, écriture: 2000 IOPS», et nous l'avons raté, nous ne nous y attendions pas. Les tableaux sont identiques, la différence n'est qu'à un seul endroit! Soit dit en passant, nous n'avons pas vu les dépendances des performances sur la taille du disque. Lorsque nous avons testé, il s'est même avéré qu'avec un disque plus gros, la vitesse chute. Le secret de ces petits indicateurs est que MCS a un céph géo-distribué, ce qui signifie que jusqu'à ce que le nœud distant dise que les données ont été écrites, le client ne sera pas informé que l'enregistrement est terminé. Soit dit en passant, personne ne semble avoir une telle fiabilité «prête à l'emploi» parmi les fournisseurs avec lesquels nous avons parlé. Mais pour nous, une telle fiabilité ne fait que mettre des bâtons dans les roues! Si quelque chose se produit, nous devons rapidement passer à un autre contrôleur de domaine lorsque des problèmes surviennent et, par conséquent, nous avons notre propre réplication asynchrone. Nous avons DRP et nous sommes prêts à perdre une petite quantité de données en cas d'accident. Il faut rendre hommage à MCS, ils ont accéléré la mise en service d'une baie SSD locale, dont les performances étaient bien supérieures.
2. Quant aux paramètres des machines, ils ne sont pas arbitraires. Il existe un certain ensemble de CPU-RAM- {SSD / HDD} (presque comme dans AWS), et d'autres types de machines ne peuvent être créés que via le support. L'ensemble du processus prend environ 2 heures, il n'y a pas de limite sur le nombre de types, l'essentiel est que le nombre de cœurs ne représente pas plus de la moitié de l'hyperviseur ~ 40-48 processeurs. Lors de la création de la machine, vous pouvez ajouter des disques vous-même et les basculer entre les machines.
3. Après avoir allumé le SSD local, la modification des paramètres de la machine a rendu impossible le démarrage. Ils ne pouvaient être lancés que grâce au support. Quelque part en un mois, ils ont résolu le problème.
4. Pour la première fois face à un support technique par télégramme. En général, c'est pratique, surtout au début, quand il y a beaucoup de questions et qu'il y a du broyage dans le service. Mais plus loin, plus les questions s'avéraient difficiles et la vitesse de réponse et le contenu de l'information diminuaient lentement. À la fin de l'année, alors que, bien sûr, les délais étaient respectés, la lenteur des réponses me mettait terriblement en colère. À un moment donné, ils ont même posé des questions sur les accords de niveau de service. C'est là que la compréhension est venue que SLA est dans le système de ticket, et non dans le télégramme! Au moment du 19 février, plusieurs de nos questions sans réponse posées le 24 décembre se bloquaient dans cette chaîne ...
5. Le support technique via le système de ticket ne prend pas en compte que nous sommes connectés et nécessite une notification supplémentaire du numéro de contrat. En réponse, il envoie une lettre «nous vous contacterons», mais n'indique pas le numéro ou le statut du billet.

En travaillant avec MCS, un autre cloud a commencé à regarder en parallèle.

Encore un autre cloud (Yandex Cloud)

Le premier des autres était Yandex. Fin 2018, ils ne disposaient que de machines virtuelles et de stockage d'objets, de leur propre shell de système de virtualisation, d'une API ouverte. Le plugin terraform était en alpha et approuvé par HashiCorp. Le support, comme d'habitude, se fait par télégramme, mais il est moins actif que dans MCS. La limite d'argent pour les tests est suffisamment petite et ne nous a pas permis d'effectuer des tests normaux. J'ai dû conclure à la hâte un accord (3 jours ouvrables) et payer les tests. Selon les résultats des tests, nous avons obtenu la même chose que sur le MCS. Il nous a semblé qu'il y avait deux problèmes: tout le monde a des lecteurs trop lents et nous avons un test trop sévère.

IT Grad 2019

En général, nous avons fixé une date limite pour le déménagement déjà le 22 décembre, afin qu'il y ait une autre semaine pour identifier et résoudre les problèmes cachés d'une nouvelle résidence. Ayant perdu espoir de passer à la date limite et un peu fatigués de l'abondance de nouvelles informations en la personne de MCS et YC, nous avons décidé que IT Grad n'était pas si mal dans leur contexte. Nous nous sommes même sentis un peu nostalgiques et avons pensé que tout ce qui est nouveau est bien ancien. Déjà chez IT Grad, nous allons certainement bien travailler - il y a un précédent. De plus, IT-Grad a augmenté: il y avait un centre de données à Moscou, Tier III, temps de disponibilité au moment où il a toujours 100% (jamais échoué), et l'équipement à l'intérieur - Intel Xeon évolutif à 4 sockets (jusqu'à 42 cœurs x 3 GHz Xeon Gold 6154). Que diable ne plaisante pas, nous donnerons une seconde chance!

28 (), 18:10 - vDC , , .
29 ( ), 17:04 , . .iso , . , . , . , .
30 (), 22:00 , .iso, . , - .
31 (), 3:15 Edge vDC vDC. , . .

, .

2 (), 15:30 .
2 (), 21:50 , Guest OS Customization .
3 (), 18:05 !

1. Maintenant, lors de la préparation de l'article, ils ont constaté que l'heure exacte des demandes et des réponses ne se reflétait pas dans le système de tickets. Au lieu de cela, il est écrit "il y a environ 2 mois", l'heure exacte n'est affichée que dans une info-bulle. Par courrier, il est également difficile de restaurer la séquence des événements. Les messages envoyés à la messagerie sont logiques de manière non évidente et ne contiennent pas de description de l'action. Les tickets sont créés dans le système après un certain temps au nom d'un employé du support technique IT Grad.
2. Après un examen plus attentif de l'équipement après les vacances, nous y avons vu Xeon v2. Ce n'est pas ce que nous avons convenu. D'accord, nous avons décidé de cette question avec le gestionnaire de compte. Il y a eu quelques difficultés en raison du fait que dans la nouvelle année 2019, IT Grad a été inclus dans le MTS , et juste après les vacances, il y a eu un léger gâchis. De vDC sur de nouveaux équipements dans le DC de Moscou n'était pas visible vDC créé avant la nouvelle année. Ce n'est que grâce à l'Internet ouvert que le support technique nous a «fait plaisir» que la vitesse de déplacement ne dépasse pas 1 To / jour. Et nous avons déjà téléchargé 7 To de données! En conséquence, ils ont créé une application pour déménager jeudi soir. Un jour plus tard, vendredi soir, j'ai demandé comment allez-vous et quand ont-ils l'intention de commencer (attendez près d'une semaine!)? Un jour plus tard, samedi soir, on nous a dit que toutes les voitures avaient bougé. Je n'aimais pas que 2,5 jours il n'y avait aucune information sur l'avancement des travaux et que les estimations sur le déménagement étaient trop pessimistes.
3. En septembre 2018, lorsque nous avons commencé à implémenter l'IaC, nous avons réalisé que terraform fonctionnait très mal avec vCloudDirector (upd: au moment de la rédaction, nous avons appris que VMware vCloud Director Provider 2.0 est apparu , mais ne l'avons pas encore essayé). Au début, nous n'avons même pas été en mesure de créer une machine car vCloud nous a signalé une erreur dans l'esprit de "quelque chose s'est mal passé, vous avez une erreur de 512 caractères 136 lignes (la ligne était plus courte!) Xml de la configuration de la machine". Nous avons demandé de l'aide. La question a été redirigée vers les ingénieurs, à la fin on nous a dit que la terraform n'était pas prise en charge - triez-la vous-même. Quoi qu'il en soit, nous avons compris que le packer était à blâmer, avec lequel nous avons collecté l'image de la machine, il ne pouvait pas faire face au format de configuration propriétaire VMware. Terraform est très mauvais avec vCloudDirector, tout est fileté lentement et le connecteur a été abandonné depuis longtemps et ne se développe pas. Personne ne nous donnerait accès à vSphere. Si vous restez sur VMware, vous devez voir votre automatisation à travers leur API.

Nous avons organisé un banc d'essai dans un nouvel emplacement. Le résultat a été incroyable - le test a échoué, les symptômes sont les mêmes que sur le MCS. Probablement, dans la prod actuelle dans le feu de la bataille pour la session, certains paramètres du système d'exploitation ont été modifiés pour empêcher le système de geler, mais qui ne peuvent plus être restaurés. Pour éviter que cela ne se reproduise, nous introduisons l'IaC. Nous avons effectué 2 tests supplémentaires: création de nouvelles machines à partir d'images propres des systèmes d'exploitation de la vente actuelle - échec; sur les machines de production existantes - succès. Ainsi, il a été confirmé que nous avons effectué quelques réglages dans le système d'exploitation ou la base de données, mais nous ne nous souvenons pas lequel. À ce stade, la solution de notre développement est arrivée à temps: les frises s'arrêtent lorsque les sessions fiables sont désactivées dans WCF.

Nous avons effectué un test de charge avec les paramètres recommandés par les développeurs en parallèle sur MCS (2 GHz, Xeon v4) et IT Grad (3 GHz, Xeon v2) - le nombre de cœurs et de mémoire est le même. Sur MCS, le test est passé plus vite (d'un quart) et plus lisse (sur IT Grad, le test est devenu saccadé, puis plus rapide, puis plus lent).

Comparaison des performances du disque

Nous étions très préoccupés par les performances des disques pour les bases de données et les index, c'est pourquoi nous avons testé principalement les SSD. Ne jugez pas strictement pour les tests, quand nous avions besoin de comprendre les performances des clouds, sur habr.com, il n'y avait pas encore plusieurs tests de disques, processeurs, ( une , deux ) fournisseurs de cloud. Nous étions limités dans le temps et nous devions comparer rapidement les performances afin d'avoir une idée de la différence de performances. Par conséquent, l'exigence pour le test était une - elle peut être répétée rapidement sur n'importe quel site. Nous avons utilisé les machines au plus près des paramètres que nous avions déjà déployés, fio - pour tester les performances des disques, et pgbench - pour évaluer les performances de la base de données sur ce disque. En standard, nous avons pris des mesures de la production actuelle - MARS (parce que notre équipement porte le nom des héros de la série animée sur les souris de roche de Mars ).

En règle générale, les performances du disque dépendent de leur taille. Nous avons observé ce comportement dans IT City et dans AWS, mais dans MCS, nous n'avons pas vu une telle dépendance, elle n'existe pas non plus dans SLA, et les tests ont donné un résultat paradoxal (et peut-être inexact) - les performances diminuent avec l'augmentation du disque.

Nous avons compté les iops pour les disques durs et SSD, ainsi que les tps (transactions par seconde) pour la base de données postgres sur les disques SSD. Il existe deux types de disques dans MCS: les SSD et HDD ceph géo-distribués et les SSD locaux (dans un seul DC) (leurs performances sont indiquées entre parenthèses). Toujours en janvier 2019, dans le mailing de MCS, nous avons lu qu'ils avaient augmenté les performances du disque de 20%, le résultat du test est également dans le tableau (MCS 2019). En février, une nouvelle accélération a été signalée, mais nous n'avons pas effectué de tests ici.

Résultats:

Méthodologie de test

iops a été calculé comme la moyenne de 4 courses fio:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps , en moyenne sur 3 séries de pgbench:
pgbench -c 10 -j 2 -t 10000 example

Description des stands

Mars

Xeon v4, 2 GHz ; Disque dur: ceph, 3 nœuds de 9x 2 To ST2000NX0253, réplique 2; SSD: ceph, 3 nœuds sur 2 To NVMe Intel DC P4600, réplique 2

CPU : 4, RAM : 8 Go, disque dur : 32 Go, SSD : 150 Go; La production parallèle tourne.

IT Grad

Xeon v4 / v2, 2 GHz ; Disque dur : 0,1 IOPS / Go ; SSD: 30 IOPS / Go

Processeur : 4, RAM : 4 Go, disque dur : 250 Go, SSD : 200 Go

Mcs

Xeon v4; Disque dur: r / w: 1500/1000 IOPS; SSD: r / w: 5000/2000 IOPS

Pour tester le disque dur: CPU : 2, RAM : 4 Go, disque dur : 50 Go

Pour tester SSD, TPS : CPU : 8, RAM : 16 Go, SSD : 600 Go

Y

Xeon v4, 2 GHz

Processeur : 8, RAM : 8 Go, disque dur : 20 Go, SSD : 50 Go

Comparaison des estimations du TCO pour l'année

Nous avons compté le TCO pour quatre options. Les valeurs relatives sont indiquées dans le tableau ci-dessous. Je dois dire que c'est un calcul pour notre cas spécifique et que tout peut se passer différemment pour vous.

Nous avons fait le calcul comme suit. L'année a été divisée en deux parties: les sessions (avec une charge de travail accrue) et le reste du temps. Pour chaque partie, la quantité requise de ressources CPU et RAM a été calculée. Le volume de disque requis, en raison de la croissance constante du service, ne croît qu'avec le temps, nous avons donc pris la moyenne entre le début et la fin de l'année pour l'évaluation.

L’évaluation avec AWS n’a guère posé de problème, car il n'y a pas de coût direct pour le noyau et les gigaoctets de mémoire. Nous avons pris 3 machines minimales c5.large, r5.large et m5.large et calculé leur coût aux prix MCS (en changeant proportionnellement le coût du cœur du processeur, puisque MCS a une fréquence de 2 GHz). Cela s'est avéré comme ceci: en moyenne, le coût des instances AWS simples est 2,5 à 2,8 fois plus élevé que le coût de MCS. AWS publie des prix sans TVA. Par conséquent, pour le coût d'AWS, nous ajoutons 20%, le taux annuel moyen en dollars est de 70 roubles. Les disques sont considérés tout simplement aux prix EBS (nous utilisons différents types de gp2, sc1, st1). Dans certains endroits, nous avons besoin de disques NVMe des instances de la famille i3. Leur prix par gigaoctet est calculé très simplement: la différence de coût entre i3 et un processeur analogue et une instance de mémoire de la famille r4, divisée par la quantité de NVMe. Il s'avère que 3,1 roubles par gigaoctet en 30 jours.

Même dans la conversation sur les budgets, je voudrais noter la différence de coût d'une licence Windows pour un cœur par mois pour tous les fournisseurs de cloud. Sur AWS, la différence entre le coût des instances Linux OnDemand et Windows OnDemand divisé par le nombre de cœurs est une constante d'environ 2 800 roubles par mois. En YC, la licence Windows pour le noyau est 3 fois moins chère, environ 900 roubles par mois, et en MCS, presque 9 (!) Fois moins cher, environ 300 roubles par mois. Nous sommes encore très dépendants de Windows: désormais, grâce au .net core, nous commençons à faire de l'anti-plagiat multi-plateforme, notamment pour réduire les coûts de maintenance.

Le coût global de YC comprend également le coût du trafic.

Conclusions

À travers les nuages

AWS Ils disent qu'en Russie, il existe 4 bons fournisseurs de cloud: AWS, GCP, Azure et DO, et tous ne sont pas en Russie.
Avantages: excellent service, équipements modernes de haute qualité, bonnes configurations dans EC2, un grand nombre de services.
Inconvénients: cher (plus les risques de change) et pas en Russie (ILV, le grand pare-feu russe à l'horizon). Je veux vraiment que nos nuages ​​suivent cet exemple.
Caractéristiques: Le support technique gratuit peut résoudre un minimum de problèmes, mais, pour être honnête, nous l'avons contacté uniquement pour étendre les limites d'utilisation. Soit dit en passant, coûte environ 10% du compte.

IT Grad . Bon service pour le cloud d'entreprise. Il existe des analogues de EC2 et S3 basés sur Swift.
Avantages: bonnes performances (CPU 1-2-3 GHz, SSD, HDD), équipement frais (dans l'un des DC) parmi les clouds domestiques, configurations de machines arbitraires.
Inconvénients: facturation incompréhensible, VMware (mal automatisé, interface flash), un peu de chaos et de gouging dans le support technique.
Caractéristiques: aiguisé davantage sous une utilisation en entreprise (une fois configuré, puis changements rares) que sous un système public très chargé (mises à jour fréquentes, changements constants). Depuis 2019, l'activité IaaS a été vendue avec les personnes et l'équipement de MTS, maintenant tout peut changer dans n'importe quelle direction. Communication via la billetterie et le téléphone, je souhaiterais une réaction plus rapide et un message des délais attendus.

MCS . Il existe des analogues des services EC2 (il existe des GPU), S3, ECS, RDS, EMR, leurs propres services: Machine Learning, Cloud Disaster Recovery, Cloud Backup
Avantages: peu coûteux, en développement actif, il existe des GPU (Tesla V100 et Grid K2).
Inconvénients: disques lents, humides, mauvais karma de la société mère.
Fonctionnalités: le support technique au début est utile, un grand nombre d'employés se mettent en marche, l'aide se fait sentir, mais il y a ensuite une baisse d'activité notable (ils n'ont rien répondu depuis le 24 décembre, même inquiet pour les gars).

YC . Nous avons très peu d'expérience avec ce fournisseur, il est difficile de dire quoi que ce soit de spécifique. Il existe des analogues de EC2, S3, RDS, DS, SQS (alfa), ELB (alfa), leurs services uniques: SpeechKit, Translate.
Avantages: Les disques sont plus rapides que MCS.
Inconvénients: le fournisseur de terraform est humide; le logiciel du shell de virtualisation avec api ouverte n'est pas très important pour la communauté, ce qui signifie que jusqu'à présent, vous ne pouvez compter que sur les forces de l'équipe YC dans le développement du fournisseur de terraform.
Caractéristiques: payer pour le trafic.

Leçons apprises

1. Nous avons réalisé que les tests de résistance sont moralement obsolètes. Ils ont mis à jour le test, trouvé de nouveaux goulots d'étranglement, les ont corrigés, ont amélioré le produit. Nous nous sommes souvenus que le test de charge devrait être adéquat et qu'il devrait y avoir des configurations sur lesquelles il ne passe définitivement pas afin que vous puissiez voir la limite de son applicabilité.
2. Malgré la croyance répandue que les logiciels ne sont pas optimisés en ce moment et que tous les goulots d'étranglement sont inondés de ressources, nous avons dû trouver et optimiser notre système. Il s'est avéré meilleur qu'il ne l'était, la nouvelle version d'Anti-Plagiat nécessite moins de ressources et fonctionne plus rapidement. Déjà décrit plusieurs autres endroits où vous pouvez réduire la consommation de ressources.
3. Nous avons fait l'IaC, le déploiement et la mise à jour via ansible, avons appris à passer d'un cloud à l'autre (avec réplication préliminaire des données) en près de 10 à 15 minutes. Si les données sont copiées et qu'une réplication régulière est configurée, alors voici le plan de reprise après sinistre: déplacement en une demi-heure avec perte de données au cours des 15 dernières minutes.

Ce que nous voulons des nuages

1. Des réponses rapides du support technique. Malheureusement, nous ne pouvons pas l'utiliser jusqu'à présent dans AWS - il y a trop peu d'informations disponibles.
2. Aide à l'automatisation du déploiement des infrastructures par le biais de fonds gratuits (terraform).
3. Prévisibilité des performances. Cela s'applique à la facturation, aux performances du processeur, à la RAM, aux disques.
4. La présence d'analogues fonctionnels EC2, S3, RDS maintenant. Dans un avenir proche, nous avons besoin de la prise en charge des k8 et des calculs GPU (nous l'utilisons déjà sur AWS).

En plus de passer aux nuages, au cours des derniers mois, nous avons réussi à toucher le râteau dans d'autres domaines. Comment c'était - nous le dirons un peu plus tard.