La société «УРУС» a essayé Kubernetes sous différentes formes : déploiement autonome sur bare metal, dans Google Cloud, puis a transféré sa plateforme vers le cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin raconte comment ils ont choisi leur nouveau fournisseur de cloud et comment ils ont réussi à migrer en un temps record de deux heures., administrateur système senior chez «УРУС».
Que fait «УРУС»
Il existe de nombreuses façons d'améliorer la qualité de l'environnement urbain, et l'une d'elles consiste à le rendre écologiquement sûr. C'est exactement sur quoi travaille la société «УРУС — Services numériques intelligents». Ici, ils mettent en œuvre des solutions qui aident les entreprises à contrôler des indicateurs environnementaux essentiels et à réduire leur impact négatif sur l'environnement. Des capteurs collectent des données sur la composition de l'air, le niveau de bruit et d'autres paramètres, puis les envoient sur une plateforme unique «УРУС — Экомон» pour analyse et formulation de recommandations.
Comment fonctionne «УРУС» de l'intérieur
Le client typique de «УРУС» est une entreprise située dans une zone résidentielle ou à proximité. Cela peut être une usine, un port, un dépôt ferroviaire ou tout autre site. Si notre client a déjà reçu un avertissement, a été sanctionné pour pollution de l'environnement ou souhaite lui-même émettre moins de bruit et réduire ses émissions nuisibles, il se tourne vers nous, et nous lui proposons déjà une solution prête pour le suivi environnemental.
Sur le graphique de surveillance de la concentration de H2S, on peut voir des émissions nocturnes régulières de l'entreprise voisine.
Les dispositifs que nous utilisons chez «УРУС» contiennent plusieurs capteurs qui collectent des informations sur la concentration de certains gaz, le niveau de bruit et d'autres données pour évaluer la situation environnementale. Le nombre exact de capteurs est toujours déterminé par la tâche spécifique.
Selon la spécificité des mesures, les dispositifs avec capteurs peuvent être placés sur les murs des bâtiments, sur des poteaux et à d'autres endroits arbitraires. Chaque dispositif collecte des informations, les agrège et les envoie à la passerelle de réception des données. Là, nous conservons les données pour un stockage à long terme et les prétraitons pour une analyse ultérieure. Un exemple simple de ce que nous obtenons en sortie après analyse est l'indice de qualité de l'air, également appelé AQI.
Parallèlement, notre plateforme fonctionne avec de nombreux autres services, mais ils sont principalement de nature de soutien. Par exemple, le service de notification envoie aux clients des alertes si l'un des paramètres suivis (par exemple, le contenu en CO2) dépasse la valeur acceptable.
Comment nous stockons les données. Une histoire avec Kubernetes sur bare metal
Dans le projet d'écomonitoring « URUS », il existe plusieurs magasins de données. Dans l'un, nous conservons des données « brutes » - celles que nous avons reçues directement des appareils. Ce stockage fonctionnait comme une bande magnétique, comme sur les anciennes cassettes, avec l'historique de toutes les mesures. Le deuxième type de stockage est utilisé pour les données prétraitées - des données des appareils enrichies de métadonnées sur les relations entre capteurs et les lectures des appareils eux-mêmes, leur appartenance à des organisations, leurs emplacements, etc. Cette information permet d'évaluer dynamiquement comment un indicateur a évolué sur une période donnée. Nous utilisons le stockage des données « brutes » aussi comme sauvegarde et pour restaurer les données prétraitées, si nécessaire.
Lorsque nous cherchions il y a quelques années comment résoudre le problème du stockage, nous avions deux options de plateforme: Kubernetes et OpenStack. Mais étant donné que ce dernier semble assez monstrueux (il suffit de regarder son architecture pour s'en rendre compte), nous avons opté pour Kubernetes. Un autre argument en sa faveur était une gestion logicielle relativement simple, permettant de découper plus facilement même les nœuds physiques selon les ressources.
Parallèlement à la maîtrise de Kubernetes lui-même, nous avons étudié les méthodes de stockage des données. Tant que tous nos stockages étaient maintenus sur Kubernetes sur notre propre matériel, nous avons acquis une excellente expertise. Tout ce que nous avions alors vivait sur Kubernetes : stockage stateful, système de surveillance, CI/CD. Kubernetes est devenu pour nous une plateforme tout-en-un.
Mais nous souhaitions travailler avec Kubernetes comme un service, sans avoir à nous occuper de sa maintenance ou de son développement. De plus, le coût de son hébergement sur du bare metal nous semblait élevé, surtout que nous avions constamment besoin de développements ! Par exemple, l'une des premières tâches a été d'intégrer les contrôleurs Ingress de Kubernetes dans l'infrastructure réseau de notre organisation. C'est une tâche complexe, surtout si l'on considère qu'à l'époque, rien n'était prêt pour la gestion logicielle des ressources comme les enregistrements DNS ou l'allocation. adresses IP. Plus tard, nous avons commencé à expérimenter avec un stockage de données externe. Nous n'avons jamais réussi à implémenter le contrôleur PVC, mais il était déjà clair que c'était un travail considérable qui nécessitait des spécialistes dédiés.
La transition vers Google Cloud Platform - une solution temporaire.
Nous avons réalisé qu'il n'était pas possible de continuer ainsi, et nous avons migré nos données du bare metal vers Google Cloud Platform. En réalité, à l'époque, les options intéressantes pour une entreprise russe n'étaient pas si nombreuses : à part Google Cloud Platform, Amazon proposait un service similaire, mais nous avons tout de même choisi la solution de Google. Elle nous semblait économiquement plus avantageuse, plus proche d'Upstream, sans parler du fait que Google est, en soi, un PoC Kubernetes en production.
Le premier véritable problème est apparu en parallèle à la croissance de notre base clients. Lorsque nous avons eu besoin de stocker des données personnelles, nous avons été confrontés à un choix : travailler avec Google et enfreindre les lois russes, ou chercher une alternative en Russie. Le choix était, dans l'ensemble, prévisible. 🙂
À quoi nous visions pour un service cloud idéal
Au début de nos recherches, nous savions déjà ce que nous voulions attendre de notre futur fournisseur cloud. Quel service recherchions-nous :
- Rapide et flexible. Un service qui nous permettrait d'ajouter rapidement un nouveau nœud ou de déployer quelque chose à tout moment.
- À moindre coût. La question financière nous préoccupait beaucoup, car nous étions limités en ressources. Nous savions déjà que nous voulions travailler avec Kubernetes, et la tâche consistait maintenant à minimiser son coût pour augmenter ou au moins maintenir l'efficacité de cette solution.
- Automatisé. Nous avions prévu de travailler avec le service via l'API, sans gestionnaires ni appels téléphoniques, ni situations où nous devions lever manuellement plusieurs dizaines de nœuds en cas d'urgence. Étant donné que la plupart de nos processus sont automatisés, nous attendions la même chose du service cloud.
- Avec des serveurs en RF. Bien sûr, nous avions l'intention de respecter la législation russe et la fameuse loi 152-FZ.
À l'époque, il y avait peu de fournisseurs de Kubernetes sous le modèle aaS en Russie, et lorsque nous avons choisi un fournisseur, il était important pour nous de ne pas compromettre nos priorités. L'équipe de Mail.ru Cloud Solutions, avec laquelle nous avons commencé à travailler et collaborons toujours, nous a fourni un service entièrement automatisé, avec support API et un tableau de bord convivial, qui inclut Horizon — grâce à cela, nous avons pu rapidement déployer un nombre arbitraire de nœuds.
Comment nous avons réussi à migrer vers MCS en deux heures
Dans de tels déménagements, de nombreuses entreprises rencontrent des difficultés et des échecs, mais dans notre cas, il n'y en a pas eu. Nous avons eu de la chance : comme nous travaillions déjà sur Kubernetes avant le début de la migration, nous avons simplement ajusté trois fichiers et lancé nos services sur la nouvelle plateforme cloud, dans MCS. Je rappelle qu'à ce moment-là, nous étions complètement sortis du bare metal et étions sur Google Cloud Platform. Donc, le déménagement lui-même n'a pas pris plus de deux heures, plus un peu de temps (environ une heure) pour copier les données de nos appareils. À ce moment-là, nous utilisions déjà Spinnaker (un service CD multi-cloud pour assurer la livraison continue). Nous l'avons également rapidement ajouté au nouveau cluster et avons continué à travailler normalement.
Grâce à l'automatisation des processus de développement et CI/CD avec Kubernetes, chez « УРУС », un seul spécialiste s'en occupe (et c'est moi). À un moment donné, je travaillais avec un autre administrateur système, mais il s'est avéré que toute la routine principale était déjà automatisée, et du côté de notre produit principal, les tâches augmentaient, ce qui justifiait de diriger des ressources vers cela.
Nous avons reçu de notre fournisseur cloud ce que nous attendions, car nous avons commencé la collaboration sans illusions. S'il y a eu quelques incidents, ils étaient principalement techniques et facilement explicables par la relative nouveauté du service. L'essentiel est que l'équipe de MCS corrige rapidement les erreurs et réagit promptement aux questions dans les messageries.
Comparé à mon expérience avec Google Cloud Platform, je ne savais même pas où se trouvait le bouton de feedback, car il n'y avait tout simplement pas besoin. En cas de problème, Google envoyait lui-même des notifications de manière unidirectionnelle. Cependant, dans le cas de MCS, un grand avantage est qu'ils sont très proches de leurs clients russes, tant sur le plan géographique que mental.
Comment nous voyons l'avenir des services cloud
Actuellement, notre travail est étroitement lié à Kubernetes, qui nous satisfait pleinement en termes de tâches d'infrastructure. Par conséquent, nous n'avons pas l'intention de migrer ailleurs, même si nous introduisons constamment de nouvelles pratiques et services pour simplifier les tâches routinières, automatiser de nouvelles, et améliorer la stabilité et la fiabilité des services… Nous lançons actuellement le service Chaos Monkey (plus précisément, nous utilisons chaoskube, mais cela ne change rien au concept :), qui a été initialement créé chez Netflix. Chaos Monkey fait une chose simple : à tout moment, il supprime un pod aléatoire dans Kubernetes. Cela est nécessaire pour que notre service fonctionne correctement avec un nombre d'instances de n–1, cela nous habitue à être prêts à toute éventualité.
Aujourd'hui, je considère l'utilisation de solutions tierces – comme les plateformes cloud – comme la seule option viable pour les jeunes entreprises. Au début, elles sont souvent limitées en ressources, tant humaines que financières, et construire et entretenir son propre cloud ou centre de données est trop coûteux et laborieux. Les fournisseurs de cloud permettent de minimiser ces coûts, car ils offrent rapidement les ressources nécessaires pour faire fonctionner les services ici et maintenant, en ne payant que pour ce qui est utilisé. Quant à l'entreprise « УРУС », nous restons pour l'instant fidèles à Kubernetes dans le cloud. Mais qui sait, il se peut que nous devions nous étendre géographiquement ou mettre en œuvre des solutions basées sur du matériel spécifique. Ou peut-être que la quantité de ressources consommées justifiera un Kubernetes sur bare-metal, comme dans le bon vieux temps. 🙂
Ce que nous avons appris de notre expérience avec les services cloud
Nous avons commencé à utiliser Kubernetes sur des serveurs bare metal, et même là, il était bon à sa manière. Mais ses véritables atouts se révèlent lorsqu'il est utilisé en tant que composant aaS dans le cloud. Si vous fixez des objectifs et automatisez autant que possible, vous éviterez le vendor lock-in et le déménagement entre fournisseurs cloud ne prendra que quelques heures, tout en préservant nos neurones. Nous conseillons aux autres entreprises : si vous souhaitez lancer votre service (cloud) avec des ressources limitées et une vitesse de développement maximale, commencez dès maintenant à louer des ressources cloud, et construisez votre datacenter après que Forbes ait écrit sur vous.
Source : habr.com
