URUS a essayé Kubernetes sous différentes formes: un déploiement autonome de métal nu dans Google Cloud, puis a déplacé sa plate-forme vers Mail.ru Cloud Solutions (MCS). Igor Shishkin (
t3ran ), administrateur système senior d'URUS, explique comment choisir un nouveau fournisseur de cloud et comment y migrer en un temps record de deux heures.
Que fait Urus
Il existe de nombreuses façons d'améliorer la qualité de l'environnement urbain, et l'une d'elles est de le rendre respectueux de l'environnement. C'est exactement ce sur quoi travaille la société URUS - Smart Digital Services. Il met en œuvre des solutions qui aident les entreprises à surveiller les indicateurs environnementaux importants et à réduire les impacts environnementaux négatifs. Les capteurs collectent des données sur la composition de l'air, le niveau de bruit et d'autres paramètres, puis les envoient à une plate-forme unique "Urus - Ekomon" pour analyse et recommandations.
Comment est le travail de "Urus" à l'intérieur
Un client typique d'URUS est une entreprise située dans ou à proximité d'un quartier résidentiel. Il peut s'agir d'une usine, d'un port, d'un dépôt ferroviaire ou de toute autre installation. Si notre client a déjà reçu un avertissement, a été condamné à une amende pour pollution de l'environnement, ou souhaite faire moins de bruit, réduire la quantité d'émissions nocives, il vient à nous, et nous lui proposons déjà une solution clé en main pour la surveillance environnementale.
Un graphique de la surveillance de la concentration de H 2 S montre les émissions nocturnes régulières d'une installation voisineLes appareils que nous utilisons chez URUS contiennent plusieurs capteurs qui collectent des informations sur le contenu de certains gaz, les niveaux de bruit et d'autres données pour évaluer la situation environnementale. Le nombre exact de capteurs est toujours déterminé par une tâche spécifique.
En fonction de la mesure spécifique, des appareils avec capteurs peuvent être placés sur les murs des bâtiments, des poteaux et d'autres endroits arbitraires. Chacun de ces appareils collecte des informations, les agrège et les envoie à la passerelle de réception des données. Là, nous enregistrons les données pour un stockage à long terme et un prétraitement pour une analyse ultérieure. L'exemple le plus simple de ce que nous obtenons après l'analyse est un indice de qualité de l'air, également appelé AQI.
Dans le même temps, de nombreux autres services fonctionnent sur notre plate-forme, mais ils sont essentiellement de nature de service. Par exemple, le service de notification envoie des notifications aux clients si l'un des paramètres surveillés (par exemple, le contenu de CO
2 ) a dépassé la valeur autorisée.
Comment stockons-nous les données. L'histoire de Kubernetes sur du métal nu
Le projet d'écosurveillance URUS comprend plusieurs entrepôts de données. Dans l'un, nous détenons les données "brutes" - ce que nous avons reçu directement des appareils eux-mêmes. Ce stockage est une bande «magnétique», comme sur les anciennes cassettes, avec un historique de tous les indicateurs. Le deuxième type de stockage est utilisé pour les données prétraitées - données provenant d'appareils enrichis de métadonnées sur les connexions des capteurs et les lectures des appareils eux-mêmes, affiliation avec les organisations, les emplacements, etc. Ces informations vous permettent d'évaluer dynamiquement comment un indicateur particulier a changé au cours d'une certaine période de temps . Nous utilisons le stockage de données brutes, y compris comme sauvegarde et pour restaurer les données prétraitées, si un tel besoin se présente.
Il y a plusieurs années, lorsque nous cherchions des moyens de résoudre le problème de stockage, nous avions deux options pour choisir une plate-forme: Kubernetes et OpenStack. Mais puisque ce dernier a l'air assez monstrueux (il suffit de regarder son architecture pour le voir), alors nous nous sommes installés sur Kubernetes. Un autre argument en sa faveur était le contrôle logiciel relativement simple, la capacité de couper de manière plus flexible même les nœuds de fer en ressources.
Parallèlement au développement de Kubernetes lui-même, nous avons également étudié les moyens de stocker des données, alors que nous conservions tous nos stockages dans Kubernetes sur notre matériel, nous avons reçu une excellente expertise. Tout ce que nous avions alors vécu sur Kubernetes: stockage d'état, système de surveillance, CI / CD. Kubernetes est devenu notre plateforme tout-en-un.
Mais nous voulions travailler avec Kubernetes en tant que service, et ne pas nous engager dans son support et son développement. De plus, nous n’aimions pas combien son contenu sur le métal nu nous coûtait, et le développement était toujours nécessaire pour nous! Par exemple, l'une des premières tâches a été d'intégrer les contrôleurs Kubernetes Ingress dans l'infrastructure réseau de notre organisation. C'est une tâche lourde, surtout si vous imaginez qu'à ce moment-là rien n'était prêt pour la gestion des ressources programmatiques comme les enregistrements DNS ou l'allocation IP. Plus tard, nous avons commencé à expérimenter avec un entrepôt de données externe. Nous n’avons pas abordé la mise en œuvre du contrôleur PVC, mais même alors, il est devenu clair qu’il s’agissait d’un vaste domaine de travail, pour lequel il était nécessaire de distinguer des spécialistes individuels.
Migration vers la solution temporaire Google Cloud Platform
Nous avons réalisé que cela ne pouvait pas continuer et avons transféré nos données du bare metal vers Google Cloud Platform. En fait, pour la société russe, il n'y avait pas beaucoup d'options intéressantes: en plus de Google Cloud Platform, seul Amazon offrait un service similaire, mais nous avons quand même opté pour une solution de Google. Ensuite, il nous a semblé économiquement plus rentable, plus proche de l'amont, sans parler du fait que Google lui-même est une sorte de Kubernetes PoC en production.
Le premier problème grave est apparu à l'horizon parallèlement à la croissance de notre clientèle. Lorsqu'il nous est devenu nécessaire de stocker des données personnelles, nous avons dû faire un choix: soit nous travaillons avec Google et violons les lois russes, soit nous recherchons une alternative en Fédération de Russie. Le choix, en général, était prévisible. :)
Comment nous avons vu le service cloud parfait
Au début de la recherche, nous savions déjà ce que nous voulions obtenir du futur fournisseur de cloud. Quel service nous recherchions:
- Rapide et flexible . Afin que nous puissions ajouter rapidement un nouveau nœud ou déployer quelque chose à tout moment.
- Bon marché . Nous étions très inquiets de la question financière, car nous étions limités en ressources. Nous savions déjà que nous voulions travailler avec Kubernetes, et maintenant la tâche était de minimiser son coût afin d'augmenter ou au moins de maintenir l'efficacité de l'utilisation 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ù vous devez lever manuellement plusieurs dizaines de nœuds en mode d'urgence. Comme la plupart de nos processus sont automatisés, nous nous attendions à la même chose d'un service cloud.
- Avec des serveurs dans la Fédération de Russie . Bien sûr, nous avions prévu de respecter la loi russe et ce même 152-FZ.
À cette époque, les fournisseurs Kubernetes aaS étaient peu nombreux en Russie, tout en choisissant un fournisseur, il était important pour nous de ne pas compromettre nos priorités. L'équipe Mail.ru Cloud Solutions, avec laquelle nous avons commencé à travailler et travaillons toujours, nous a fourni un service entièrement automatisé avec prise en charge d'API et un panneau de contrôle pratique dans lequel se trouve Horizon - avec lui, nous pourrions rapidement augmenter un nombre arbitraire de nœuds.
Comment nous avons réussi à migrer vers MCS en deux heures
Dans de telles délocalisations, de nombreuses entreprises sont confrontées à des difficultés et des échecs, mais dans notre cas, elles ne l'ont pas été. Nous avons eu de la chance: comme nous travaillions déjà sur Kubernetes avant le début de la migration, nous venons de corriger trois fichiers et de lancer nos services sur une nouvelle plateforme cloud, dans MCS. Permettez-moi de vous rappeler qu'à ce moment-là, nous avions finalement laissé le métal nu et vivions sur la plateforme Google Cloud. Parce que le déménagement lui-même n'a pas pris plus de deux heures, plus un peu plus de temps (environ une heure) pour copier les données de nos appareils. Ensuite, nous avons déjà utilisé Spinnaker (un service de CD multi-cloud pour fournir une livraison continue). Nous l'avons également rapidement ajouté au nouveau cluster et avons continué à travailler comme d'habitude.
Grâce à l'automatisation des processus de développement et CI / CD Kubernetes dans URUS est occupé par un spécialiste (et c'est moi). À un moment donné, un autre administrateur système a travaillé avec moi, mais il s'est avéré que nous avions déjà automatisé l'ensemble de la routine principale, et il y avait de plus en plus de tâches de la part de notre produit principal et il était logique d'y affecter des ressources.
Nous avons reçu du fournisseur de cloud ce que nous attendions, car nous avons commencé la coopération sans illusions. S'il y a eu des incidents, alors surtout des incidents techniques, qui s'expliquent facilement par la relative fraîcheur du service. L'essentiel est que l'équipe MCS élimine rapidement les failles et réponde rapidement aux questions des messageries instantanées.
Si nous comparons l'expérience avec Google Cloud Platform, alors dans leur cas, je ne savais même pas où se trouve le bouton de rétroaction, car cela n'était tout simplement pas nécessaire. Et en cas de problème, Google lui-même a envoyé des notifications unilatéralement. Mais dans le cas de MCS, un gros plus, je pense qu'ils sont aussi proches que possible des clients russes - à la fois géographiquement et mentalement.
Comme nous le voyons travailler avec les nuages à l'avenir
Maintenant, notre travail est étroitement lié à Kubernetes, et il nous convient parfaitement en termes de tâches d'infrastructure. Par conséquent, nous ne prévoyons pas de migrer quelque part, bien que nous introduisions constamment de nouvelles pratiques et services pour simplifier les tâches de routine et automatiser de nouvelles, augmenter la stabilité et la fiabilité des services ... Maintenant, nous lançons le service Chaos Monkey (en particulier, nous utilisons chaoskube, mais cela ne change pas le concept: ), qui a été créé à l'origine dans Netflix. Chaos Monkey fait une chose simple: à un moment arbitraire, il supprime un arbitraire sous dans Kubernetes. Ceci est nécessaire pour que notre service puisse vivre normalement avec le nombre d'instances n - 1, nous nous habituons donc à être prêts à tout dysfonctionnement.
Maintenant, je vois l'utilisation de solutions tierces - les mêmes plates-formes cloud - comme la seule bonne pour les jeunes entreprises. Habituellement, au début du voyage, les ressources sont limitées, tant humaines que financières, et la construction et la maintenance de votre propre cloud ou centre de données sont trop coûteuses et prennent du temps. Les fournisseurs de cloud peuvent minimiser ces coûts, ils peuvent rapidement obtenir les ressources nécessaires pour que les services fonctionnent ici et maintenant, et payer ces ressources en fait. Quant à la société Urus, nous resterons pour l'instant fidèles à Kubernetes dans le cloud. Mais qui sait, nous devrons peut-être nous étendre géographiquement ou mettre en œuvre des solutions basées sur certains équipements spécifiques. Ou peut-être que la quantité de ressources consommées justifiera ses propres Kubernetes sur du métal nu, comme au bon vieux temps. :)
Ce que nous avons appris de notre expérience avec les services cloud
Nous avons commencé à utiliser Kubernetes sur du métal nu, et même là, c'était bien à sa manière. Mais ses forces ont été révélées précisément comme un composant aaS dans le cloud. Si vous définissez un objectif et automatisez tout autant que possible, vous serez en mesure d'éviter le verrouillage des fournisseurs et le déplacement entre les fournisseurs de cloud prendra quelques heures, et les cellules nerveuses resteront avec nous. Nous pouvons conseiller d'autres entreprises: si vous souhaitez démarrer votre service (cloud), avec des ressources limitées et une vitesse de développement maximale, commencez dès maintenant avec la location de ressources cloud et construisez votre centre de données après que Forbes ait écrit à votre sujet.