Conférence DUMP | grep 'backend \ | devops'

La semaine dernière, je suis allé à la conférence informatique DUMP (https://dump-ekb.ru/) à Iekaterinbourg et je veux parler de ce qui a été discuté dans les sections Backend et Devops et si les conférences informatiques régionales méritent une attention particulière.


Nikolay Sverchkov de Evil Martians à propos de Serverless

Qu'y avait-il du tout?

Au total, la conférence comprenait 8 sections: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.

Soit dit en passant, les plus grandes salles sont la science et la gestion)) ~ 350 personnes chacune. Backend et Frontend ne sont pas beaucoup moins. Devops Hall était le plus petit mais le plus actif.

J'ai écouté les rapports dans les sections Devops et Backend et parlé un peu avec les intervenants. Je veux parler des sujets traités et donner un aperçu de ces sections lors de la conférence.

Des représentants de SKB-Kontur, DataArt, Evil Martians, du studio web Flag of Yekaterinburg, Miro (RealTimeBoard) ont pris la parole dans les sections Devops et Backend. Les sujets liés au CI / CD, au travail avec les services de file d'attente, à la journalisation, aux sujets sans serveur et au travail avec PostgreSQL in Go ont été bien divulgués.

Des rapports ont également été publiés par Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, mais je n'ai pas eu le temps de les visiter physiquement (les enregistrements vidéo et les diapositives des rapports ne sont pas encore disponibles, ils promettent de les publier sur dump-ekb.ru dans un délai de 2 semaines).

Section Devops

Ce qui a surpris - la section a eu lieu dans la plus petite salle, environ 50 sièges. Les gens se tenaient même dans les allées :) Je vais vous parler des reportages que j'ai réussi à écouter.

Poids élastique en pétaoctets

La section a commencé par un rapport de Vladimir Lil (SKB-Kontur) sur Elasticsearch à Kontur. Ils disposent d'un Elastic suffisamment volumineux et chargé (~ 800 To de données, ~ 1,3 pétaoctets, compte tenu de la redondance). Elasticsearch pour tous les services du circuit est unique, se compose de 2 clusters (de 7 et 9 serveurs), et est si important qu'il y ait un ingénieur Elasticsearch spécial dans le circuit (en fait, Vladimir lui-même).

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

Avantage:

• Tous les journaux en un seul endroit, un accès facile à eux
• Stockage des journaux pendant un an et leur analyse facile
• Haute vitesse avec journaux
• Visualisation des données cool «prête à l'emploi»

Les problèmes:

• courtier de messages - doit avoir (Kafka joue le rôle de Kontur)
• 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é, assez important, ou en tant que plug-ins open source de différents degrés de préparation à la production)

À propos d'Open Distro pour Elasticsearch, les critiques n'étaient que positives :) Le même problème d'autorisation y a été résolu.

Fonctionnalités de développement sans serveur

Un autre rapport de Ruslan Serkin de DataArt sur Serverless.

Ruslan a parlé de ce qu'est le développement avec l'approche sans serveur en général, et quelles sont ses fonctionnalités.

Serverless est une approche de développement où les développeurs n'ont rien à voir avec l'infrastructure. Un exemple est AWS Lambda Serverless, Kubeless.io (Serverless inside Kubernetes), Google Cloud Functions.

Une application sans serveur idéale n'est qu'une fonctionnalité qui envoie une demande à un fournisseur sans serveur via une API de passerelle dédiée. Un microservice idéal, tandis que dans le même AWS Lambda, un grand nombre de langages de programmation modernes sont pris en charge. Le coût de la prise en charge et du 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 demandes simples).

L'évolutivité d'un tel système est presque parfaite - le fournisseur de cloud s'en charge tout seul, Kubeless est automatiquement mis à l'échelle dans le cluster Kubernetes.

Il y a des inconvénients:

• développer de grandes applications devient plus difficile
• il y a une difficulté avec les applications de profilage (seuls les journaux sont à votre disposition, mais pas le profilage au sens habituel)
• pas de version

Franchement, 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, la compréhension est apparue, et après le rapport de Nikolai Sverchkov (Evil Martians) de la section Backend, il a consolidé. Pas étonnant que je sois allé à la conférence :)

CI pour les pauvres, ou vaut-il la peine d'écrire votre propre CI pour web studio

Mikhail Radionov, le chef du studio web Flag d'Ekaterinbourg, a parlé du CI / CD auto-écrit.

Son studio est passé d'un «CI / CD manuel» (connecté au serveur via SSH, a git pull, répété 100 fois par jour) à Jenkins et à un outil auto-écrit qui vous permet de contrôler le code et d'exécuter des versions appelées Pullkins.

Pourquoi Jenkins n’a-t-il pas fonctionné? Il ne donnait pas suffisamment de flexibilité par défaut et était trop compliqué pour la personnalisation.

Le «drapeau» est en cours de développement dans Laravel (framework PHP). Lors du développement du serveur CI / CD, Michael et ses collègues ont utilisé les mécanismes Laravel intégrés appelés Télescope et Envoy. Le résultat est un serveur php (attention) qui traite les demandes entrantes de webhook, capable d'assembler le frontend, le backend, de le déployer sur différents serveurs et de faire rapport à Slack.

En outre, pour pouvoir effectuer un déploiement bleu / vert, pour avoir des paramètres uniformes dans les environnements de développement-prod-prod, ils sont passés à Docker. Les avantages sont restés les mêmes, les possibilités d'homogénéisation de l'environnement et d'un déploiement transparent ont été ajoutées, et la nécessité d'apprendre Docker à fonctionner correctement avec lui a été ajoutée.

Le projet est sur Github

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

Le dernier rapport dans la section Devops était de Victor Eremchenko, ingénieur Lead Devops chez Miro.com (anciennement RealTimeBoard).

RealTimeBoard, le produit de base de l'équipe Miro, est basé sur une application Java monolithique. La collecte, le test et le déploiement sans temps d'arrêt est une tâche difficile. Dans le même temps, il est important de déployer une telle version du code afin qu'elle ne doive pas être annulée (un lourd monolithe).

Sur le chemin de la construction d'un système qui le permet, Miro a fait beaucoup de chemin, y compris le travail sur l'architecture, les outils utilisés (Atlassian Bamboo, Ansible, etc.) et le travail sur les équipes de construction (ils ont maintenant une commande Devops dédiée + de nombreuses commandes Scrum distinctes de développeurs de profils différents).

Le chemin s'est avéré difficile et épineux, et Victor a partagé ses décisions, la douleur accumulée et l'optimisme qui ne s'est pas arrêté là.


A remporté un livre pour des questions

Section backend

J'ai eu 2 rapports - de Nikolai 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 parlé de ce qu'est Serverless, Nikolai 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'article minimum payé est de 128 Mo de mémoire et 100 ms CPU, il en coûte 0,00000000208 $. De plus, 1 million de ces demandes par mois est gratuit.

Certaines fonctions de Nikolai dépassaient souvent la limite de 100 ms (l’application principale était écrite en Ruby), donc les réécrire sur Go a permis d’excellentes économies.

Vostok Hercules - rendez la télémétrie géniale à nouveau!

Le dernier rapport de la section Backend de Grigory Koshelev (société Kontur) sur la télémétrie. La télémétrie est des journaux, des métriques, des traces d'application.

Contour utilise pour cela ses propres outils écrits publiés sur Github. L'outil de rapport, Hercules, github.com/vostok/hercules , est utilisé pour fournir des données de télémétrie.

Un rapport de Vladimir Lila dans la section Devops a examiné le stockage et le traitement des journaux dans Elasticsearch, mais il reste la tâche de fournir des journaux à partir de plusieurs milliers d'appareils et d'applications, et des outils comme Vostok Hercules les résolvent.

Le circuit a suivi le chemin connu de beaucoup - de RabbitMQ à Apache Kafka, mais pas si simple)) Ils ont dû ajouter Zookeeper, Cassandra et Graphite au programme. Je ne divulguerai pas entièrement les informations sur ce rapport (pas mon profil), si vous êtes intéressé, vous pouvez attendre les diapositives et la vidéo sur le site Web de la conférence.

Comment par rapport à d'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.

DUMP se déroule en 8 sections, c'est un record pour les conférences de l'Oural. De très grandes sections de la science et de la gestion, cela est également inhabituel. Le public à Ekaterinbourg est assez structuré - la ville dispose de grands départements de développement Yandex, Kontur, Tinkoff, cela laisse sa marque sur les rapports.

Un autre point intéressant est que de nombreuses entreprises ont immédiatement 3-4 intervenants à la conférence (ce fut le cas avec Kontur, Evil Martians, Tinkoff). Beaucoup d'entre eux étaient des sponsors, mais les rapports sont tout à fait comparables à d'autres, ce ne sont pas des rapports publicitaires.

Aller ou ne pas aller? Si vous vivez dans ou près de l'Oural, vous avez la possibilité et des sujets intéressants - oui, bien sûr. Si vous songez à un long voyage, je voudrais regarder les sujets des rapports et des reportages vidéo des années précédentes www.youtube.com/user/videoitpeople/videos et prendre une décision.
Un autre avantage des conférences dans les régions, en règle générale, est facile de communiquer avec l'orateur après les rapports, il y a moins de candidats pour une telle communication.



Merci à Dump et à Iekaterinbourg! )