La semaine dernière, je suis allé à la conférence DUMP IT (https://dump-ekb.ru/) à Ekaterinbourg et je veux vous dire ce qui a été discuté dans les sections Backend et Devops, et si les conférences informatiques régionales méritent votre attention.
Nikolay Sverchkov de Evil Martians à propos du sans serveur
Qu’y avait-il d’ailleurs ?
Au total, la conférence comportait 8 sections : Backend, Frontend, Mobile, Tests et QA, Devops, Design, Science et Management.
Les plus grandes salles, d'ailleurs, se trouvent à Science et Gestion)) Pour environ 350 personnes chacune. Backend et Frontend ne sont pas beaucoup plus petits. La salle Devops était la plus petite, mais active.
J'ai écouté les rapports dans les sections Devops et Backend et j'ai discuté un peu avec les intervenants. J'aimerais parler des sujets abordés et revoir ces sections lors de la conférence.
Des représentants de SKB-Kontur, DataArt, Evil Martians, du studio Web d'Ekaterinbourg Flag, Miro (RealTimeBoard) ont pris la parole dans les sections Devops et Backend. Les sujets abordés CI/CD, l'utilisation des services de file d'attente, la journalisation ; les sujets sans serveur et l'utilisation de PostgreSQL dans Go ont été bien abordés.
Il y avait aussi des rapports d'Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, mais je n'ai pas eu le temps d'y assister physiquement (les enregistrements vidéo et les diapositives des rapports ne sont pas encore disponibles, ils promettent de les publier dans les 2 semaines sur dump-ekb.ru).
Section Devops
Ce qui était surprenant, c'est que la section se tenait dans la plus petite salle, d'environ 50 places. Il y avait même du monde dans les allées :) Je vais vous parler des reportages que j'ai réussi à écouter.
Élastique pesant un pétaoctet
La section a commencé par un rapport de Vladimir Lil (SKB-Kontur) sur Elasticsearch dans Kontur. Ils disposent d'un Elastic assez volumineux et chargé (~800 To de données, ~1.3 pétaoctets en tenant compte de la redondance). Elasticsearch pour tous les services Kontur est unique, se compose de 2 clusters (de 7 et 9 serveurs) et est si important que Kontur dispose d'un ingénieur Elasticsearch spécial (en fait, Vladimir lui-même).
Vladimir a également partagé ses réflexions sur les avantages d'Elasticsearch et les problèmes qu'il entraîne.
Le Bon:
- Tous les journaux sont au même endroit, accès facile
- Stocker les journaux pendant un an et les analyser facilement
- Grande vitesse de travail avec les journaux
- Visualisation de données cool et prête à l'emploi
Problèmes:
- le courtier de messages est un incontournable (pour Kontur, son rôle est joué par Kafka)
- fonctionnalités de travail avec Elasticsearch Curator (charge élevée créée périodiquement à partir de tâches régulières dans Curator)
- pas d'autorisation intégrée (uniquement pour de l'argent séparé et assez important, ou en tant que plugins open source de différents degrés de préparation à la production)
Il n'y a eu que des critiques positives sur Open Distro pour Elasticsearch :) Le même problème d'autorisation y a été résolu.
D'où vient le pétaoctet ?Leurs nœuds sont constitués de serveurs avec 12*8 To SATA + 2*2 To SSD. Stockage froid sur SATA, SSD uniquement pour le cache chaud (stockage chaud).
7+9 serveurs, (7 + 9) * 12 * 8 = 1536 To.
Une partie de l'espace est en réserve, réservée à la redondance, etc.
Les journaux d'environ 90 applications sont envoyés à Elasticsearch, y compris tous les services de reporting de Kontur, Elba, etc.
Caractéristiques du développement sur Serverless
Voici ensuite un rapport de Ruslan Serkin de DataArt sur le sans serveur.
Ruslan a expliqué ce qu'est le développement avec l'approche sans serveur en général et quelles sont ses fonctionnalités.
Le sans serveur est une approche de développement dans laquelle les développeurs ne touchent en aucun cas à l'infrastructure. Exemple : AWS Lambda Serverless, Kubeless.io (sans serveur dans Kubernetes), Google Cloud Functions.
Une application sans serveur idéale est simplement une fonction qui envoie une requête à un fournisseur sans serveur via une passerelle API spéciale. Un microservice idéal, tandis qu'AWS Lambda prend également en charge un grand nombre de langages de programmation modernes. Le coût de maintenance et de déploiement de l'infrastructure devient nul dans le cas des fournisseurs de cloud, la prise en charge de petites applications sera également très bon marché (AWS Lambda - 0.2 $ / 1 million de requêtes simples).
L'évolutivité d'un tel système est presque idéale - le fournisseur de cloud s'en charge lui-même, Kubeless évolue automatiquement au sein du cluster Kubernetes.
Il y a des inconvénients :
- développer de grandes applications devient de plus en plus difficile
- il y a des difficultés avec les applications de profilage (seuls les journaux sont disponibles, mais pas le profilage au sens habituel)
- pas de versionnage
Pour être honnête, j'ai entendu parler de Serverless il y a quelques années, mais pendant toutes ces années, je ne savais pas comment l'utiliser correctement. Après le rapport de Ruslan, une compréhension est apparue, et après le rapport de Nikolai Sverchkov (Evil Martians) de la section Backend, elle a été consolidée. Ce n'est pas en vain que je suis allé à la conférence :)
CI est pour les pauvres, ou vaut-il la peine d'écrire votre propre CI pour un studio Web ?
Mikhaïl Radionov, directeur du studio Web Flag d'Ekaterinbourg, a parlé du CI/CD auto-écrit.
Son studio est passé du « CI/CD manuel » (connectez-vous au serveur via SSH, faites un git pull, répétez 100 fois par jour) à Jenkins et à un outil auto-écrit qui vous permet de surveiller le code et d'effectuer des versions appelé Pullkins. .
Pourquoi Jenkins n'a-t-il pas travaillé ? Il n'offrait pas suffisamment de flexibilité par défaut et était trop difficile à personnaliser.
« Flag » se développe en Laravel (framework PHP). Lors du développement d'un serveur CI/CD, Mikhail et ses collègues ont utilisé les mécanismes intégrés de Laravel appelés Telescope et Envoy. Le résultat est un serveur en PHP (veuillez noter) qui traite les demandes de webhook entrantes, peut créer le frontend et le backend, se déployer sur différents serveurs et rendre compte à Slack.
Ensuite, pour pouvoir effectuer un déploiement bleu/vert et disposer de paramètres uniformes dans les environnements de développement et de production, ils sont passés à Docker. Les avantages sont restés les mêmes, les possibilités d'homogénéisation de l'environnement et de déploiement transparent ont été ajoutées, et la nécessité d'apprendre Docker pour l'utiliser correctement a été ajoutée.
Comment nous avons réduit le nombre de restaurations de versions de serveur de 99 %
Le dernier rapport de la section Devops provenait de Viktor Eremchenko, ingénieur principal Devops chez Miro.com (anciennement RealTimeBoard).
RealTimeBoard, produit phare de l'équipe Miro, repose sur une application Java monolithique. Le collecter, le tester et le déployer sans temps d’arrêt est une tâche difficile. Dans ce cas, il est important de déployer une telle version du code afin qu’il n’ait pas besoin d’être rollback (c’est un monolithe lourd).
Pour construire un système permettant de faire cela, Miro a parcouru un chemin qui comprenait un travail sur l'architecture, les outils utilisés (Atlassian Bamboo, Ansible, etc.), et un travail sur la structure des équipes (elles ont maintenant une équipe Devops dédiée + de nombreuses équipes Scrum distinctes composées de développeurs de profils différents).
Le chemin s'est avéré difficile et épineux, et Victor a partagé la douleur et l'optimisme accumulés qui ne s'arrêtent pas là.
A gagné un livre pour poser des questions
Section back-end
J'ai réussi à assister à 2 rapports - de Nikolay Sverchkov (Evil Martians), également sur Serverless, et de Grigory Koshelev (société Kontur) sur la télémétrie.
Sans serveur pour les simples mortels
Si Ruslan Sirkin a expliqué ce qu'est Serverless, Nikolay a montré des applications simples utilisant Serverless et a parlé des détails qui affectent le coût et la vitesse des applications dans AWS Lambda.
Un détail intéressant : l'élément payant minimum est de 128 Mo de mémoire et 100 ms de CPU, il coûte 0,000000208 $. De plus, 1 million de demandes de ce type par mois sont gratuites.
Certaines fonctions de Nikolai dépassaient souvent la limite de 100 ms (l'application principale était écrite en Ruby), donc les réécrire dans Go permettait d'excellentes économies.
Vostok Hercules : rendez la télémétrie à nouveau géniale !
Le dernier rapport de la section Backend de Grigory Koshelev (société Kontur) sur la télémétrie. La télémétrie signifie les journaux, les métriques et les traces d'application.
À cette fin, Contour utilise des outils auto-écrits publiés sur Github. Outil du rapport - Hercules, , est utilisé pour fournir des données de télémétrie.
Le rapport de Vladimir Lila dans la section Devops traitait du stockage et du traitement des journaux dans Elasticsearch, mais il reste toujours la tâche de fournir les journaux de plusieurs milliers d'appareils et d'applications, et des outils comme Vostok Hercules les résolvent.
Le circuit a suivi un chemin connu de beaucoup - de RabbitMQ à Apache Kafka, mais tout n'est pas si simple)) Ils ont dû ajouter Zookeeper, Cassandra et Graphite au circuit. Je ne divulguerai pas l'intégralité des informations sur ce rapport (pas mon profil), si vous êtes intéressé, vous pouvez attendre les slides et vidéos sur le site de la conférence.
Comment se compare-t-elle aux autres conférences ?
Je ne peux pas le comparer avec des conférences à Moscou et à Saint-Pétersbourg, je peux le comparer avec d'autres événements dans l'Oural et avec le 404fest à Samara.
DAMP se déroule en 8 sections, c'est un record pour les conférences de l'Oural. De très grandes sections Sciences et Gestion, c'est aussi inhabituel. L'audience à Ekaterinbourg est assez structurée - la ville dispose de grands départements de développement de Yandex, Kontur, Tinkoff, ce qui laisse sa marque sur les reportages.
Un autre point intéressant est que de nombreuses entreprises ont 3 à 4 intervenants à la conférence à la fois (ce fut le cas de Kontur, Evil Martians, Tinkoff). Beaucoup d'entre eux étaient des sponsors, mais les rapports sont tout à fait comparables aux autres, ce ne sont pas des rapports publicitaires.
Y aller ou ne pas y aller ? Si vous habitez dans l'Oural ou à proximité, vous en avez l'opportunité et êtes intéressé par ces sujets - oui, bien sûr. Si vous envisagez un long voyage, je regarderais les sujets des reportages et reportages vidéo des années précédentes et pris une décision.
En règle générale, un autre avantage des conférences dans les régions est qu'il est facile de communiquer avec l'orateur après les rapports ; il y a tout simplement moins de candidats pour une telle communication.
Merci à Dump et Ekaterinbourg ! )
Source: habr.com