Ce printemps nous nous sommes retrouvés dans des conditions très joyeuses. En raison de la pandémie, il est devenu évident que nos conférences d’été devaient être déplacées en ligne. Et pour les réaliser efficacement en ligne, les solutions logicielles toutes faites ne nous convenaient pas : nous devions écrire les nôtres. Et nous avons eu trois mois pour le faire.
Il est clair que ces trois mois ont été passionnants. Mais vu de l’extérieur, ce n’est pas tout à fait évident : qu’est-ce qu’une plateforme de conférence en ligne ? De quelles parties se compose-t-il ? C'est pourquoi, lors de la dernière des conférences DevOops d'été, j'ai demandé à ceux qui étaient responsables de cette tâche :
- Nikolay Molchanov - directeur technique du groupe JUG Ru ;
- Vladimir Krasilshchik est un programmeur Java pragmatique travaillant sur le backend (vous pourrez également voir ses rapports lors de nos conférences Java) ;
- Artyom Nikonov est responsable de tous nos streaming vidéo.
À propos, lors des conférences automne-hiver, nous utiliserons une version améliorée de la même plateforme - de nombreux lecteurs Habra en seront donc toujours les utilisateurs.
La grande image
— Quelle était la composition de l'équipe ?
Nikolaï Molchanov : Nous avons un analyste, un concepteur, un testeur, trois front-end et un back-end. Et bien sûr, un spécialiste du T !
— À quoi ressemblait le processus en général ?
Nikolai: Jusqu’à la mi-mars, nous n’avions rien de prêt à mettre en ligne. Et le 15 mars, tout le carrousel en ligne a commencé à tourner. Nous avons mis en place plusieurs référentiels, planifié, discuté de l'architecture de base et tout fait en trois mois.
Ceci, bien sûr, est passé par les étapes classiques de planification, d'architecture, de sélection des fonctionnalités, de vote pour ces fonctionnalités, de politique relative à ces fonctionnalités, de leur conception, de leur développement et de leurs tests. En conséquence, le 6 juin, nous avons tout mis en production. . Il y avait 90 jours pour tout.
— Avons-nous réussi à accomplir ce à quoi nous nous étions engagés ?
Nikolai: Puisque nous participons désormais à la conférence DevOops en ligne, cela signifie que cela a fonctionné. Je me suis personnellement engagé sur l'essentiel : j'apporterai aux clients un outil avec lequel ils pourront organiser une conférence en ligne.
Le défi était le suivant : nous fournir un outil avec lequel nous pourrions diffuser nos conférences aux détenteurs de billets.
Toute la planification a été divisée en plusieurs étapes, et toutes les fonctionnalités (environ 30 globales) ont été divisées en 4 catégories :
- ce que nous ferons certainement (nous ne pouvons pas vivre sans eux),
- ce que nous ferons en second lieu,
- ce que nous ne ferons jamais,
- et ce que nous ne ferons jamais, jamais.
Nous avons réalisé toutes les fonctionnalités des deux premières catégories.
— Je sais qu'un total de 600 tickets JIRA ont été créés. En trois mois, vous avez créé 13 microservices, et je soupçonne qu'ils n'ont pas été écrits uniquement en Java. Vous avez utilisé différentes technologies, vous disposez de deux clusters Kubernetes dans trois zones de disponibilité et de 5 flux RTMP sur Amazon.
Examinons maintenant chaque composant du système séparément.
Diffusion
— Commençons par le cas où nous disposons déjà d'une image vidéo et qu'elle est transmise à certains services. Artyom, dis-nous comment se passe ce streaming ?
Artem Nikonov : Notre schéma général ressemble à ceci : image de la caméra -> notre salle de contrôle -> serveur RTMP local -> Amazon -> lecteur vidéo. Plus de détails sur Habré en juin.
En général, il existe deux manières globales de procéder : soit sur le matériel, soit sur la base de solutions logicielles. Nous avons choisi la voie logicielle car elle est plus simple dans le cas d'enceintes déportées. Il n'est pas toujours possible d'apporter du matériel à un locuteur dans un autre pays, mais la fourniture de logiciels à l'orateur semble plus facile et plus fiable.
D'un point de vue matériel, nous disposons d'un certain nombre de caméras (dans nos studios et sur les enceintes déportées), d'un certain nombre de télécommandes en studio, qu'il faut parfois réparer juste sous la table pendant la diffusion.
Les signaux de ces appareils pénètrent dans les ordinateurs équipés de cartes de capture, de cartes d'entrée/sortie et de cartes son. Là, les signaux sont mélangés et assemblés en layouts :
Exemple d'agencement pour 4 enceintes
Exemple d'agencement pour 4 enceintes
De plus, la diffusion continue est assurée à l'aide de trois ordinateurs : il y a une machine principale et deux machines qui fonctionnent à tour de rôle. Le premier ordinateur collecte le premier rapport, le second - la pause, le premier - le rapport suivant, le second - la pause suivante, et ainsi de suite. Et la machine principale mélange le premier avec le second.
Cela crée une sorte de triangle, et si l'un de ces nœuds tombe en panne, nous pouvons continuer à fournir du contenu aux clients rapidement et sans perte de qualité. Nous avons eu une telle situation. Au cours de la première semaine de conférences, nous avons réparé une machine, l'avons allumée/éteinte. Les gens semblent satisfaits de notre résilience.
Ensuite, les flux provenant des ordinateurs sont dirigés vers un serveur local, qui a deux tâches : acheminer les flux RTMP et enregistrer les sauvegardes. Nous avons donc plusieurs points d'enregistrement. Les flux vidéo sont ensuite envoyés vers la partie de notre système construite sur les services Amazon SaaS. Nous utilisons ,S3,CloudFront.
Nikolai: Que se passe-t-il avant que la vidéo n’atteigne le public ? Vous devez le couper d'une manière ou d'une autre, n'est-ce pas ?
Artem : Nous compressons la vidéo de notre côté et l'envoyons à MediaLive. Nous y lançons des transcodeurs. Ils transcodent les vidéos en temps réel dans plusieurs résolutions afin que les gens puissent les regarder sur leur téléphone, via un Internet médiocre dans le pays, etc. Ces flux sont ensuite découpés en , voici comment fonctionne le protocole . Nous envoyons une playlist au frontend qui contient des pointeurs vers ces morceaux.
— Utilisons-nous une résolution 1080p ?
Artem : La largeur de notre vidéo est la même que celle de 1080p - 1920 pixels, et la hauteur est un peu inférieure, l'image est plus allongée - il y a des raisons à cela.
Joueur
— Artyom a décrit comment la vidéo entre dans les flux, comment elle est distribuée dans différentes listes de lecture pour différentes résolutions d'écran, coupée en morceaux et introduite dans le lecteur. Kolya, maintenant dis-moi de quel genre de lecteur il s'agit, comment il consomme le flux, pourquoi HLS ?
Nikolai: Nous avons un lecteur que tous les téléspectateurs de la conférence peuvent regarder.
Essentiellement, il s'agit d'un wrapper autour de la bibliothèque , sur lequel de nombreux autres joueurs sont écrits. Mais nous avions besoin de fonctionnalités très spécifiques : rembobiner et marquer l'endroit où se trouve la personne, quel reportage elle regarde en ce moment. Nous avions également besoin de nos propres mises en page, de toutes sortes de logos et de tout ce qui était intégré chez nous. Par conséquent, nous avons décidé d'écrire notre propre bibliothèque (un wrapper sur HLS) et de l'intégrer sur le site.
Il s’agit de la fonctionnalité racine, elle a donc été implémentée presque en premier. Et puis tout s’est développé autour de lui.
En fait, grâce à l'autorisation, le joueur reçoit du backend une liste de lecture avec des liens vers des morceaux corrélés au temps et à la qualité, télécharge ceux nécessaires et les montre à l'utilisateur, effectuant ainsi une certaine « magie » en cours de route.
Exemple de chronologie
— Un bouton est intégré directement au lecteur pour afficher une chronologie de tous les rapports...
Nikolai: Oui, nous avons immédiatement résolu le problème de la navigation des utilisateurs. À la mi-avril, nous avons décidé de ne pas diffuser chacune de nos conférences sur un site Web distinct, mais de tout regrouper sur un seul. Pour que les utilisateurs du billet Full Pass puissent basculer librement entre les différentes conférences : aussi bien les diffusions en direct que les enregistrements des conférences passées.
Et pour permettre aux utilisateurs de naviguer plus facilement dans le flux actuel et de basculer entre les pistes, nous avons décidé de créer un bouton « Diffusion complète » et des bulletins horizontaux pour basculer entre les pistes et les rapports. Il y a un contrôle par clavier.
— Y a-t-il eu des difficultés techniques avec cela ?
Nikolai: Ils avaient une barre de défilement sur laquelle étaient marqués les points de départ des différents rapports.
— Au final, avez-vous implémenté ces marques sur la barre de défilement avant que YouTube ne fasse quelque chose de similaire ?
Artem : Ils l'avaient alors en version bêta. Il semble qu'il s'agisse d'une fonctionnalité assez complexe car ils l'ont partiellement testée auprès des utilisateurs au cours de l'année écoulée. Et maintenant, il est en vente.
Nikolai: Mais nous l’avons en fait mis en vente plus rapidement. Honnêtement, derrière cette fonctionnalité simple, il y a une énorme quantité de backend, de frontend, de calculs et de mathématiques à l'intérieur du lecteur.
L'extrémité avant
— Voyons comment le contenu que nous montrons (carte vocale, conférenciers, site Web, calendrier) parvient au front-end ?
Vladimir Krasilschik : Nous disposons de plusieurs systèmes informatiques internes. Il existe un système dans lequel tous les rapports et tous les intervenants sont enregistrés. Il existe un processus par lequel un orateur participe à une conférence. L'orateur soumet une candidature, le système la capture, puis il existe un certain pipeline selon lequel le rapport est créé.
C'est ainsi que l'orateur voit le pipeline
Ce système est notre développement interne.
Ensuite, vous devez créer un calendrier à partir de rapports individuels. Comme vous le savez, il s'agit d'un problème NP-difficile, mais nous le résolvons d'une manière ou d'une autre. Pour ce faire, nous lançons un autre composant qui génère un planning et le télécharge sur le service cloud tiers Contentful. Là, tout ressemble à un tableau dans lequel il y a des jours de conférence, dans les jours il y a des plages horaires, et dans les plages il y a des reportages, des pauses ou des activités de sponsoring. Le contenu que nous voyons se trouve donc dans un service tiers. Et la tâche est de le transmettre au site.
Il semblerait que le site ne soit qu'une page avec un lecteur, et il n'y a rien de compliqué ici. Sauf que ce n'est pas le cas. Le backend derrière cette page accède à Contentful, récupère le planning à partir de là, génère des objets et l'envoie au frontend. À l'aide d'une connexion websocket, établie par chaque client de notre plateforme, nous lui envoyons une mise à jour du planning du backend au frontend.
Cas réel : l'orateur a changé de poste juste pendant la conférence. Nous devons changer son badge d'entreprise employeur. Comment cela se produit-il depuis le backend ? Une mise à jour est envoyée à tous les clients via le websocket, puis le frontend lui-même redessine la chronologie. Tout cela se passe de manière transparente. La combinaison du service cloud et de plusieurs de nos composants nous donne la possibilité de générer tout ce contenu et de le mettre à disposition.
Nikolai: Il est important de préciser ici que notre site n'est pas une application SPA classique. Il s’agit à la fois d’un site Web rendu basé sur une mise en page et d’un SPA. Google considère en fait ce site comme du HTML rendu. C'est bon pour le référencement et pour fournir du contenu à l'utilisateur. Il n'attend pas le chargement de 1,5 Mo de JavaScript avant de voir la page, il voit immédiatement la page déjà rendue et vous le ressentez à chaque fois que vous changez de rapport. Tout se passe en une demi-seconde, puisque le contenu est déjà prêt et posté au bon endroit.
— Tirons un trait sur tout ce qui précède en listant les technologies. Tyoma a déclaré que nous disposions de 5 flux Amazon et que nous y diffusions de la vidéo et du son. Nous y avons des scripts bash, nous les utilisons pour lancer et configurer...
Artem : Cela se produit via l'API AWS, il existe de nombreux autres services techniques supplémentaires. Nous avons divisé nos responsabilités afin que je livre à , et les développeurs front-end et back-end partent de là. Nous disposons d'un certain nombre de nos propres liaisons pour simplifier la mise en page du contenu, que nous réalisons ensuite en 4K, etc. Les délais étant très serrés, nous l'avons fait presque entièrement sur AWS.
— Ensuite, tout cela va dans le lecteur en utilisant le système backend. Nous avons TypeScript, React, Next.JS dans notre lecteur. Et sur le backend, nous avons plusieurs services en C#, Java, Spring Boot et Node.js. Tout cela est déployé à l'aide de Kubernetes en utilisant l'infrastructure Yandex.Cloud.
Je tiens aussi à souligner que lorsque j'ai eu besoin de me familiariser avec la plateforme, cela s'est avéré simple : tous les référentiels sont sur GitLab, tout est bien nommé, les tests sont écrits, il y a de la documentation. Autrement dit, même en mode d'urgence, ils se sont occupés de telles choses.
Contraintes commerciales et analyses
— Nous avons ciblé 10 000 utilisateurs en fonction des besoins métier. Il est temps de parler des restrictions commerciales que nous avions. Il fallait assurer une charge de travail élevée, veiller au respect de la loi sur la conservation des données personnelles. Et quoi d'autre?
Nikolai: Au départ, nous sommes partis des exigences vidéo. Le plus important est un stockage vidéo distribué dans le monde entier pour une livraison rapide au client. D'autres incluent une résolution de 1080p, ainsi que le rembobinage, que beaucoup d'autres n'implémentent pas en mode direct. Plus tard, nous avons ajouté la possibilité d'activer la vitesse 2x, avec son aide, vous pouvez « rattraper » le direct et continuer à regarder la conférence en temps réel. Et en cours de route, une fonctionnalité de marquage chronologique est apparue. De plus, nous devions être insensibles aux pannes et supporter la charge de 10 000 connexions. D'un point de vue backend, cela représente environ 10 000 connexions multipliées par 8 requêtes pour chaque rafraîchissement de page. Et cela représente déjà 80 000 RPS/sec. Un peu.
— Y avait-il d'autres exigences pour une « exposition virtuelle » avec des stands en ligne de partenaires ?
Nikolai: Oui, il fallait le faire assez rapidement et universellement. Nous avions jusqu'à 10 entreprises partenaires pour chaque conférence, et toutes devaient être terminées en une semaine ou deux. Cependant, leur contenu diffère légèrement par leur format. Mais un certain moteur de modèles a été créé pour assembler ces pages à la volée, sans pratiquement aucune participation ultérieure au développement.
— Il y avait également des exigences en matière d'analyse des vues et des statistiques en temps réel. Je sais que nous utilisons Prometheus pour cela, mais dites-nous plus en détail : à quelles exigences répondons-nous en matière d'analyse et comment cela est-il mis en œuvre ?
Nikolai: Initialement, nous avons des exigences marketing pour la collecte de tests A/B et la collecte d'informations afin de comprendre comment fournir correctement le meilleur contenu au client à l'avenir. Il existe également des exigences pour certaines analyses sur les activités des partenaires et les analyses que vous voyez (compteur de visites). Toutes les informations sont collectées en temps réel.
Nous pouvons même fournir ces informations sous forme agrégée aux intervenants : combien de personnes vous regardaient à un moment donné. Dans le même temps, afin de respecter la loi fédérale 152, votre compte personnel et vos données personnelles ne sont en aucun cas suivis.
La plateforme dispose déjà d'outils marketing et de nos métriques pour mesurer l'activité des utilisateurs en temps réel (qui a regardé quelle seconde du rapport) afin de construire des graphiques de fréquentation des rapports. Sur la base de ces données, des recherches sont en cours pour améliorer les prochaines conférences.
Fraude
— Avons-nous des mécanismes anti-fraude ?
Nikolai: En raison des délais serrés d'un point de vue commercial, la tâche n'était pas initialement fixée de bloquer immédiatement les connexions inutiles. Si deux utilisateurs se connectaient sous le même compte, ils pouvaient voir le contenu. Mais nous savons combien de vues simultanées il y a eu à partir d'un même compte. Et nous avons banni plusieurs contrevenants particulièrement malveillants.
Vladimir: Il faut reconnaître que l’un des utilisateurs bannis a compris pourquoi cela s’est produit. Il est venu, s'est excusé et a promis d'acheter un billet.
— Pour que tout cela se produise, vous devez suivre complètement tous les utilisateurs de l'entrée à la sortie, toujours savoir ce qu'ils font. Comment fonctionne ce système ?
Vladimir: Je voudrais parler d'analyses et de statistiques, que nous analysons ensuite pour le succès du rapport ou que nous pouvons ensuite fournir aux partenaires. Tous les clients sont connectés via une connexion Websocket à un cluster backend spécifique. Il est là . Chaque client, à chaque période, envoie ce qu'il fait et quelle piste il regarde. Ensuite, ces informations sont regroupées à l'aide de tâches Hazelcast rapides et renvoyées à tous ceux qui regardent ces pistes. Nous voyons dans le coin combien de personnes sont désormais avec nous.
Les mêmes informations sont stockées dans et va à notre lac de données, à partir duquel nous avons la possibilité de construire un graphique plus intéressant. La question se pose : combien d’utilisateurs uniques ont consulté ce rapport ? Nous allons à , il y a des pings de toutes les personnes qui sont venues avec l'identifiant de ce rapport. Nous avons collecté, regroupé des éléments uniques et maintenant nous pouvons comprendre.
Nikolai: Mais en même temps, nous recevons également des données en temps réel de Prometheus. Il est comparé à tous les services Kubernetes, à Kubernetes lui-même. Il collecte absolument tout et avec Grafana nous pouvons créer n'importe quel graphique en temps réel.
Vladimir: D'une part, nous le téléchargeons pour un traitement OLAP ultérieur. Et pour OLTP, l'application télécharge le tout vers Prometheus, Grafana et les graphiques convergent même !
- C'est le cas lorsque les graphiques convergent.
Changements dynamiques
— Dites-nous comment se déroulent les changements dynamiques : si le rapport a été annulé 6 minutes avant le début, quelle est la chaîne d'actions ? Quel pipeline fonctionne ?
Vladimir: Le pipeline est très conditionnel. Il existe plusieurs possibilités. La première est que le programme de génération d'horaires a fonctionné et a modifié l'horaire. Le planning modifié est téléchargé sur Contentful. Après quoi le backend comprend qu'il y a des changements pour cette conférence dans Contentful, la prend et la reconstruit. Tout est collecté et envoyé via websocket.
Deuxième possibilité, quand tout se passe à un rythme effréné : l’éditeur modifie manuellement les informations dans Contentful (lien vers Telegram, présentation de l’intervenant, etc.) et la même logique fonctionne que la première fois.
Nikolai: Tout se passe sans actualiser la page. Tous les changements se déroulent de manière absolument transparente pour le client. Il en va de même pour changer de rapport. Le moment venu, le rapport et l'interface changent.
Vladimir: En outre, il existe des heures limites pour le début des rapports dans la chronologie. Au tout début, il n'y a rien. Et si vous passez votre souris sur la bande rouge, à un moment donné, grâce au directeur de la diffusion, des coupures apparaîtront. Le réalisateur définit le début correct de la diffusion, le backend récupère ce changement, calcule les heures de début et de fin des présentations de l'ensemble du morceau conformément au programme de la conférence, l'envoie à nos clients et le joueur fixe les coupures. L'utilisateur peut désormais facilement naviguer jusqu'au début et à la fin du rapport. C’était une exigence commerciale stricte, très pratique et utile. Vous ne perdez pas de temps à trouver l'heure de début réelle du rapport. Et quand nous ferons une avant-première, ce sera absolument merveilleux.
Déploiement
— Je voudrais poser une question sur le déploiement. Kolya et l'équipe ont passé beaucoup de temps au début à mettre en place toute l'infrastructure dans laquelle tout se déroule pour nous. Dis-moi, de quoi est-il fait ?
Nikolai: D'un point de vue technique, nous avions initialement pour exigence que le produit soit aussi abstrait que possible de n'importe quel fournisseur. Venez sur AWS pour créer des scripts Terraform spécifiquement depuis AWS, ou spécifiquement depuis Yandex, ou depuis Azure, etc. ne convenait pas vraiment. Nous avons dû déménager quelque part à un moment donné.
Pendant les trois premières semaines, nous avons constamment cherché un moyen de mieux faire les choses. En conséquence, nous sommes arrivés à la conclusion que Kubernetes dans ce cas est notre tout, car il nous permet de créer des services à mise à l'échelle automatique, de déploiement automatique et d'obtenir presque tous les services prêts à l'emploi. Naturellement, tous les services devaient être formés pour travailler avec Kubernetes, Docker, et l'équipe devait également apprendre.
Nous avons deux clusters. Tests et fabrication. Ils sont absolument identiques en termes de matériel et de paramètres. Nous implémentons l'infrastructure sous forme de code. Tous les services sont automatiquement déployés dans trois environnements à partir des branches de fonctionnalités, des branches principales, des branches de test et de GitLab à l'aide d'un pipeline automatique. Ceci est intégré au maximum dans GitLab, intégré au maximum avec Elastic, Prometheus.
Nous avons la possibilité de déployer rapidement (pour le backend en 10 minutes, pour le frontend en 5 minutes) les modifications dans n'importe quel environnement avec tous les tests, intégrations, exécution de tests fonctionnels, tests d'intégration sur l'environnement, et également tester avec des tests de charge sur un environnement de test à peu près la même chose que celui que nous souhaitons obtenir en production.
À propos des tests
— Vous testez presque tout, c'est difficile de croire comment vous avez tout écrit. Pouvez-vous nous parler des tests backend : dans quelle mesure tout est couvert, quels tests ?
Vladimir: Deux types de tests ont été rédigés. Les premiers sont les tests de composants. Tests de niveau de levage de l'ensemble de l'application du ressort et de la base . Il s'agit d'un test des scénarios commerciaux du plus haut niveau. Je ne teste pas les fonctions. Nous testons seulement quelques grandes choses. Par exemple, dès le test, le processus de connexion d'un utilisateur est émulé, la demande de billets de l'utilisateur pour l'endroit où il peut se rendre et une demande d'accès pour regarder le flux. Scénarios utilisateur très clairs.
À peu près la même chose est implémentée dans les tests dits d'intégration, qui s'exécutent réellement sur l'environnement. En fait, lors du prochain déploiement en production, de véritables scénarios de base s'exécutent également en production. Le même login, demander des tickets, demander l'accès à CloudFront, vérifier que le flux se connecte bien avec mes autorisations, vérifier l'interface du réalisateur.
À l'heure actuelle, j'ai à bord environ 70 tests de composants et environ 40 tests d'intégration. La couverture est très proche de 95 %. C'est pour les composants, moins pour ceux d'intégration, il n'y a tout simplement pas grand chose à faire. Considérant que le projet implique toutes sortes de générations de code, c'est un très bon indicateur. Il n’y avait pas d’autre moyen de faire ce que nous avons fait en trois mois. Parce que si nous testions manuellement, en donnant des fonctionnalités à notre testeur, et qu'elle trouvait des bugs et nous les renvoyait pour des correctifs, alors cet aller-retour pour déboguer le code serait très long et nous ne respecterions aucun délai.
Nikolai: Classiquement, pour effectuer une régression sur l'ensemble de la plateforme lors d'un changement de fonction, il faut s'asseoir et fouiller partout pendant deux jours.
Vladimir: C'est donc un grand succès que lorsque j'estime une fonctionnalité, je dise qu'il me faut 4 jours pour deux stylos simples et 1 websocket, Kolya le permet. Il est déjà habitué au fait que ces 4 jours comprennent 2 types de tests, et alors, très probablement, cela fonctionnera.
Nikolai: J'ai aussi 140 tests écrits : composant + fonctionnel, qui font la même chose. Tous les mêmes scénarios sont testés en production, en test et en production. Nous avons également récemment ajouté des tests fonctionnels de base de l’interface utilisateur. De cette façon, nous couvrons les fonctionnalités les plus élémentaires qui peuvent s’effondrer.
Vladimir: Bien sûr, cela vaut la peine de parler de tests de charge. Il a fallu tester la plateforme sous une charge proche de la vraie afin de comprendre comment tout se passe, ce qui se passe avec Rabbit, ce qui se passe avec les JVM, quelle quantité de mémoire est réellement nécessaire.
— Je ne sais pas avec certitude si nous testons quelque chose du côté du flux, mais je me souviens qu'il y avait des problèmes avec les transcodeurs lorsque nous faisions des rencontres. Avons-nous testé les flux ?
Artem : Testé de manière itérative. Organisation de rencontres. Lors de l'organisation des rencontres, il y a eu environ 2300 XNUMX tickets JIRA. Ce ne sont que des choses génériques que les gens font pour organiser des rencontres. Nous avons regroupé certaines parties de la plate-forme sur une page séparée pour les rencontres, gérée par Kirill Tolkachev ().
Pour être honnête, il n’y a pas eu de gros problèmes. À quelques reprises, nous avons détecté des bugs de mise en cache sur CloudFront, nous les avons résolus assez rapidement - nous avons simplement reconfiguré les politiques. Il y avait beaucoup plus de bugs chez les gens, dans les systèmes de streaming du site.
Pendant les conférences, j'ai dû écrire à plusieurs autres exportateurs afin de couvrir plus d'équipements et de services. Dans certains endroits, j'ai dû fabriquer mes propres vélos juste pour des raisons de mesure. Le monde du matériel AV (audio-vidéo) n'est pas très rose - vous disposez d'une sorte d'« API » d'équipement sur laquelle vous ne pouvez tout simplement pas influencer. Et il est loin d’être certain que vous pourrez obtenir les informations dont vous avez besoin. Les fournisseurs de matériel sont très lents et il est presque impossible d’obtenir ce que vous attendez d’eux. Au total, il y a plus de 100 éléments matériels, ils ne restituent pas ce dont vous avez besoin et vous écrivez des exportateurs étranges et redondants, grâce auxquels vous pouvez au moins déboguer le système d'une manière ou d'une autre.
équipement
— Je me souviens qu'avant le début des conférences, nous avions partiellement acheté du matériel supplémentaire.
Artem : Nous avons acheté des ordinateurs, des ordinateurs portables et des batteries. À l’heure actuelle, nous pouvons vivre sans électricité pendant 40 minutes. En juin, il y a eu de violents orages à Saint-Pétersbourg - nous avons donc eu une telle panne d'électricité. Parallèlement, plusieurs fournisseurs nous parviennent avec des liaisons optiques depuis différents points. Il s'agit en réalité de 40 minutes d'arrêt du bâtiment, pendant lesquelles nous aurons les lumières allumées, le son, les caméras, etc.
— Nous avons une histoire similaire avec Internet. Dans le bureau où se trouvent nos studios, nous avons tendu un filet féroce entre les étages.
Artem : Nous disposons de 20 Gbits de fibre entre les étages. Plus loin dans les étages, quelque part il y a des optiques, quelque part il n'y a pas d'optique, mais il y a quand même moins de canaux que ceux en gigabit - nous diffusons de la vidéo dessus entre les pistes de la conférence. En général, il est très pratique de travailler sur votre propre infrastructure, cela est rarement possible lors de conférences hors ligne sur des sites.
— Avant de travailler chez JUG Ru Group, j'ai vu comment des salles matérielles lors de conférences hors ligne étaient aménagées du jour au lendemain, où se trouvaient un grand moniteur avec toutes les métriques que vous construisez dans Grafana. Il existe désormais également une salle du siège dans laquelle siège l'équipe de développement qui, pendant la conférence, corrige certains bugs et développe des fonctionnalités. Parallèlement, il existe un système de surveillance affiché sur un grand écran. Artyom, Kolya et d'autres gars s'assoient et s'assurent que tout ne tombe pas et fonctionne à merveille.
Curiosités et problèmes
— Vous avez bien parlé du fait que nous avons du streaming avec Amazon, qu'il y a un acteur avec le Web, que tout est écrit dans différents langages de programmation, que la tolérance aux pannes et d'autres exigences commerciales sont fournies, y compris un compte personnel pris en charge pour les personnes morales et individus, et nous pouvons intégrer quelqu'un en utilisant OAuth 2.0, il existe un système anti-fraude et un blocage des utilisateurs. Nous pouvons déployer des changements de manière dynamique parce que nous l’avons bien fait et que tout est testé.
Je suis curieux de savoir quelles bizarreries ont été impliquées dans le démarrage de quelque chose. Y a-t-il eu des situations étranges lorsque vous développiez un backend, un frontend, quelque chose de fou s'est produit et vous ne compreniez pas quoi en faire ?
Vladimir: Il me semble que cela ne se produit que depuis trois mois. Tous les jours. Comme vous pouvez le constater, tous mes cheveux ont été arrachés.
Vladimir Krasilshchik après 3 mois, quand une sorte de jeu s'est avéré et que personne n'a compris quoi en faire
Chaque jour, il y avait quelque chose comme ça, quand il y avait un tel moment où vous le prenez et vous arrachez les cheveux, ou réalisez qu'il n'y a personne d'autre et que vous seul pouvez le faire. Notre premier grand événement était TechTrain. Le 6 juin à 2 heures du matin, nous n'avions pas encore déployé l'environnement de production, Kolya le déployait. Et le compte personnel ne fonctionnait pas comme serveur d'autorisation utilisant OAuth2.0. Nous l'avons transformé en fournisseur OAuth2.0 pour y connecter la plateforme. J'ai travaillé probablement 18 heures d'affilée, j'ai regardé l'ordinateur et je n'ai rien vu, je n'ai pas compris pourquoi il ne fonctionnait pas, et Kolya a regardé mon code à distance, a cherché un bug dans la configuration Spring , je l'ai trouvé, et le LC a fonctionné, et en production aussi .
Nikolai: Et une heure avant TechTrain, la sortie a eu lieu.
De nombreuses étoiles étaient alignées ici. Nous avons eu énormément de chance car nous avions une super équipe, et tout le monde était inspiré par l’idée de le faire en ligne. Pendant tous ces trois mois, nous avons été motivés par le fait que nous avions « créé YouTube ». Je ne me suis pas permis de m'arracher les cheveux, mais j'ai dit à tout le monde que tout s'arrangerait, car en fait, tout avait été calculé depuis longtemps.
À propos des performances
— Pouvez-vous me dire combien de personnes étaient sur le site sur une piste ? Y a-t-il eu des problèmes de performances ?
Nikolai: Il n'y a eu aucun problème de performances, comme nous l'avons déjà dit. Le nombre maximum de personnes ayant assisté à un rapport était de 1300 XNUMX personnes, c'est sur Heisenbug.
— Y a-t-il eu des problèmes avec le visionnage local ? Et est-il possible d'avoir une description technique avec des schémas de comment tout cela fonctionne ?
Nikolai: Nous ferons un article à ce sujet plus tard.
Vous pouvez même déboguer les flux localement. Une fois les conférences lancées, c'est devenu encore plus facile, car des flux de production sont apparus que l'on peut regarder à tout moment.
Vladimir: Si je comprends bien, les développeurs front-end ont travaillé localement avec des simulations, puis, comme le temps de déploiement vers les développeurs front-end est également court (5 minutes), il n'y a aucun problème pour vérifier ce qui se passe avec les certificats.
— Tout est testé et débogué, même localement. Cela signifie que nous allons écrire un article avec toutes les caractéristiques techniques, vous montrer, tout vous raconter avec des schémas, comment c'était.
Vladimir: Vous pouvez le prendre et le répéter.
- Dans 3 mois.
Total
— Tout ce qui est décrit ensemble semble cool, étant donné que cela a été réalisé par une petite équipe en trois mois.
Nikolai: Une grande équipe ne ferait pas ça. Mais un petit groupe de personnes qui communiquent assez étroitement et bien entre elles et peuvent parvenir à un accord pourrait le faire. Ils ne présentent aucune contradiction, l'architecture a été inventée en deux jours, a été finalisée et n'a réellement pas changé. Il existe une facilitation très stricte des exigences commerciales entrantes en termes d'accumulation de demandes de fonctionnalités et de modifications.
— Quelles étaient vos autres tâches sur la liste lorsque les conférences d'été avaient déjà eu lieu ?
Nikolai: Par exemple, les crédits. Lignes rampantes sur la vidéo, pop-ups à certains endroits de la vidéo en fonction du contenu affiché. Par exemple, l'orateur souhaite poser une question au public et un vote apparaît à l'écran, qui revient en arrière-plan en fonction des résultats du vote à l'orateur lui-même. Une sorte d'activité sociale sous forme de likes, de cœurs, d'évaluations du rapport pendant la présentation elle-même, afin que vous puissiez remplir des commentaires au bon moment sans être distrait plus tard par les formulaires de commentaires. Au départ comme ça.
Et en ajoutant également à l'ensemble de la plateforme, à l'exception du streaming et de la conférence, également un état post-conférence. Il s'agit de playlists (y compris celles compilées par les utilisateurs), éventuellement du contenu d'autres conférences passées, intégrées, labellisées, accessibles à l'utilisateur, et également consultables sur notre site Internet ().
— Les gars, merci beaucoup pour vos réponses !
Si parmi les lecteurs il y a ceux qui ont assisté à nos conférences d'été, merci de partager vos impressions sur le player et la diffusion. Qu'est-ce qui vous a semblé pratique, qu'est-ce qui vous a irrité, qu'aimeriez-vous voir à l'avenir ?
Si la plateforme vous intéresse et que vous souhaitez la voir « en bataille », nous l'utilisons à nouveau sur notre . Il en existe toute une gamme, il y en a donc certainement un qui vous convient.
Source: habr.com