DUMP conference | grep ‘backend|devops’

La semaine dernière, j'ai assisté à la conférence IT DUMP (https://dump-ekb.ru/) à Ekaterinbourg et je souhaite partager les sujets abordés dans les sections Backend et Devops, et si les conférences IT régionales en valent la peine.

Nikolai Svertchkov d'Evil Martians sur Serverless

Qu'est-ce qui s'est passé là-bas ?

Au total, la conférence comptait 8 sections : Backend, Frontend, Mobile, Test et QA, Devops, Design, Science et Management.

Les plus grandes salles étaient, en fait, celles de Science et Management, avec environ 350 places chacune. Backend et Frontend étaient à peine plus petites. La salle de Devops était la plus petite, mais très active.

J'ai écouté des présentations dans les sections Devops et Backend et j'ai eu quelques échanges avec les présentateurs. Je souhaite raconter les sujets abordés et faire un aperçu de ces sections lors de la conférence.

Dans les sections Devops et Backend, des représentants de SKB-Kontur, DataArt, Evil Martians, du studio web d'Ekaterinbourg Flag, Miro (RealTimeBoard) ont pris la parole. Les sujets concernaient CI/CD, le travail avec des services de file d'attente, la journalisation ; les thèmes de Serverless et du travail avec PostgreSQL en Go ont été particulièrement bien développés.

Il y a également eu des présentations d'Avito, Tinkoff, Yandex, Jetstyle, Megafon, de la banque Ak Bars, mais je n'ai pas eu le temps de les visiter physiquement (les enregistrements vidéo et les diapositives des présentations ne sont pas encore disponibles, ils promettent de les publier dans les deux semaines sur dump-ekb.ru).

Section Devops

Ce qui m'a surpris, c'est que la section se tenait dans la plus petite salle, d'environ 50 places. Les gens se tenaient même dans les allées 🙂 Je vais vous parler des présentations que j'ai pu écouter.

Elastic pesant un pétaoctet

La section a commencé par une présentation de Vladimir Lila (SKB-Kontur) sur Elasticsearch dans Kontur. Ils ont un Elastic assez grand et chargé (~800 To de données, ~1,3 pétaoctet en tenant compte de la redondance). Elasticsearch pour tous les services de Kontur est unique et constitué de 2 clusters (de 7 et 9 serveurs), et il est si important qu'il existe chez Kontur un ingénieur Elasticsearch (en fait, Vladimir lui-même).

Vladimir a également partagé ses réflexions sur les avantages d'Elasticsearch et sur les problèmes qu'il pose.

Avantages :

• Tous les journaux au même endroit, accès facile à ceux-ci
• Stockage des journaux pendant un an et analyse facile
• Haute vitesse de traitement des journaux
• Excellente visualisation des données “prête à l'emploi”

Problèmes :

• Le courtier de messages - must have (chez Kontur, son rôle est joué par Kafka)
• Caractéristiques du fonctionnement d'Elasticsearch Curator (charge élevée créée périodiquement par des tâches régulières dans Curator)
• Pas d'autorisation intégrée (seulement pour un coût supplémentaire assez élevé, ou comme des plugins open source de différents niveaux de préparation à la production)

Les avis sur Open Distro for Elasticsearch étaient tous positifs 🙂 La même question d'authentification y est résolue.

D'où proviennent les pétaoctets ?Leurs nœuds sont constitués de serveurs avec 12*8 To SATA + 2*2 To SSD. Le stockage froid est sur SATA, le SSD est seulement utilisé pour le cache chaud.
7+9 serveurs, (7 + 9) * 12 * 8 = 1536 To.
Une partie de l'espace est réservée, prévue pour la redondance et autres.
Des journaux d'environ 90 applications sont envoyés à Elasticsearch, y compris tous les services de reporting de Kontur, Elba, etc.

Particularités du développement sur Serverless

Ensuite, la présentation de Ruslan Serkin de DataArt sur Serverless.

Ruslan a expliqué ce qu'est le développement avec l'approche Serverless en général et quelles sont ses particularités.

Serverless est une approche de développement où les développeurs ne touchent en aucune façon à l'infrastructure. Exemple — AWS Lambda Serverless, Kubeless.io (Serverless dans Kubernetes), Google Cloud Functions.

Une application Serverless idéale est tout simplement une fonction qui envoie une requête au fournisseur Serverless via une passerelle API spéciale. C'est un microservice idéal, et dans AWS Lambda, un grand nombre de langages de programmation modernes sont pris en charge. Le coût de support et de déploiement de l'infrastructure devient nul en ce qui concerne les fournisseurs cloud, et le soutien des petites applications sera également très peu cher (AWS Lambda — 0,2 $ / 1 million de requêtes simples).

La scalabilité de ce système est pratiquement idéale — le fournisseur cloud s'en occupe lui-même, Kubeless se redimensionne automatiquement à l'intérieur du cluster Kubernetes.

Il y a des inconvénients :

• le développement d'applications volumineuses devient plus compliqué
• il y a des difficultés avec le profilage des applications (vous n'avez accès qu'aux journaux, mais pas au profilage au sens habituel)
• pas de versionnage

Je le dirai honnêtement, j'ai entendu parler de Serverless il y a quelques années, mais toutes ces années, je n'ai pas compris comment l'appliquer correctement. Après la présentation de Ruslan, la compréhension est apparue, et après la présentation de Nikolay Svirchkov (Evil Martians) dans la section Backend, elle s'est consolidée. Ce n'était pas en vain que je suis allé à la conférence 🙂

CI pour les pauvres, ou vaut-il la peine d'écrire son propre CI pour une agence web

Mikhail Radionov, directeur de l'agence web Flag de Yekaterinburg, a parlé de son CI/CD fait maison.

Son agence a fait le chemin du « CI/CD manuel » (se connecter au serveur par SSH, faire un git pull, répéter 100 fois par jour) à Jenkins et à un outil fait maison permettant de contrôler le code et de réaliser des publications appelé Pullkins.

Pourquoi Jenkins ne convenait-il pas ? Il ne fournissait pas suffisamment de flexibilité par défaut et était trop complexe à personnaliser.

Le "drapeau" est développé sur Laravel (framework PHP). Lors de la création du serveur CI/CD, Mikhaïl 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 (notez bien) qui gère les requêtes webhook entrantes, capable de construire le frontend, le backend, de déployer sur différents serveurs et de faire des rapports sur Slack.

Ensuite, pour permettre des déploiements blue/green, et avoir des configurations uniformes dans les environnements dev-stage-prod, ils sont passés à Docker. Les avantages sont restés les mêmes, avec l'ajout de la possibilité d'homogénéiser l'environnement et d'effectuer des déploiements sans couture, ainsi que la nécessité d'apprendre Docker pour bien travailler avec.

Le projet est disponible sur Github

Comment nous avons réduit le nombre de rollbacks de versions serveur de 99%

La dernière présentation dans la section DevOps a été faite par Viktor Yaremchenko, Lead DevOps engineer chez Miro.com (anciennement RealTimeBoard).

À la base de RealTimeBoard, le produit principal de l'équipe Miro, se trouve une application monolithique en Java. Compiler, tester et déployer sans temps d'arrêt est une tâche complexe. Il est crucial de déployer une version du code de sorte qu'elle n'ait pas besoin d'être annulée (c'est un lourd monolithe).

Dans le chemin vers la mise en place d'un système qui permet cela, Miro a parcouru un chemin incluant le travail sur l'architecture, les outils utilisés (Atlassian Bamboo, Ansible, etc.), et la formation des équipes (ils ont actuellement une équipe DevOps dédiée + de nombreuses équipes Scrum séparées de développeurs de différents profils).

Le chemin s'est avéré difficile et ardent, et Viktor a partagé sa douleur accumulée tout en conservant un optimisme non terminé.

J'ai gagné un livre pour les questions

Section Backend

J'ai assisté à deux présentations — celle de Nikolai Sverchkov (Evil Martians), également sur le Serverless, et celle de Grigory Koshelev (entreprise Kontur) sur la télémétrie.

Serverless pour les simples mortels

Alors que Ruslan Sirkin parlait de ce qu'est le Serverless, Nikolai a montré de simples applications utilisant Serverless et expliqué les détails qui influencent le coût et la rapidité des applications sur AWS Lambda.

Un détail intéressant : l'élément tarifé minimum est de 128 Mo de mémoire et 100 ms de CPU, il coûte 0,000000208 $. De plus, 1 million de telles requêtes par mois est gratuit.

Certain features in Nikolai's work frequently exceeded the 100 ms limit (the main application was written in Ruby), so rewriting them in Go resulted in significant savings.

Vostok Hercules — make telemetry great again!

The latest report from the Backend section by Grigori Koshelev (Kontur) on telemetry. Telemetry includes logs, metrics, and application traces.

Kontur uses custom-built tools released on Github for this purpose. The tool from the report — Hercules, github.com/vostok/hercules, is used for delivering telemetry data.

In Vladimir Lila's report in the Devops section, the storage and processing of logs in Elasticsearch were discussed, but there's also the challenge of delivering logs from thousands of devices and applications, and tools like Vostok Hercules address this.

Kontur followed a well-known path — from RabbitMQ to Apache Kafka, but it's not that simple. They had to add Zookeeper, Cassandra, and Graphite to the architecture. I won’t fully reveal the information from this report (it's not my area), but if you're interested, you can wait for the slides and video on the conference website.

How does it compare with other conferences?

I can't compare it with conferences in Moscow and St. Petersburg, but I can compare it to other events in the Ural region and the 404fest in Samara.

DAMP hosts 8 sections, which is a record for Ural conferences. The Science and Management sections are also very large, which is unusual. The audience in Yekaterinburg is quite structured — the city has large development departments of Yandex, Kontur, and Tinkoff, which influences the talks.

Another interesting point is that many companies have 3–4 speakers at the conference (as was the case with Kontur, Evil Martians, Tinkoff). Many of them were sponsors, but the talks were on par with others, not promotional.

To go or not to go? If you live in the Ural region or nearby, and you're interested in the topics — yes, of course. If you're considering a long trip — I'd take a look at the talk topics and videos from previous years. www.youtube.com/user/videoitpeople/videos and make a decision.
Another plus of regional conferences is that it’s generally easier to chat with the speaker after the talks, simply because there are fewer candidates for such conversations.

Thanks to DAMP and Yekaterinburg! )

Source : habr.com