Dit voorjaar bevonden we ons in zeer vrolijke omstandigheden. Door de pandemie werd het duidelijk dat onze zomerconferenties online moesten worden verplaatst. En om ze efficiënt online uit te voeren, waren kant-en-klare softwareoplossingen niet geschikt voor ons; we moesten onze eigen oplossingen schrijven. En daar hadden we drie maanden de tijd voor.
Het is duidelijk dat het drie spannende maanden zijn geweest. Maar van buitenaf is het niet helemaal duidelijk: wat is een online conferentieplatform? Uit welke onderdelen bestaat het? Daarom vroeg ik tijdens de laatste zomerconferentie van DevOops aan degenen die verantwoordelijk waren voor deze taak:
- Nikolay Molchanov - technisch directeur van JUG Ru Group;
- Vladimir Krasilshchik is een pragmatische Java-programmeur die aan de backend werkt (je kon zijn rapporten ook zien op onze Java-conferenties);
- Artyom Nikonov is verantwoordelijk voor al onze videostreaming.
Trouwens, op de herfst-winterconferenties zullen we een verbeterde versie van hetzelfde platform gebruiken - zoveel habra-lezers zullen nog steeds gebruikers ervan zijn.
De grote afbeelding
— Wat was de samenstelling van het team?
Nikolaj Molchanov: We hebben een analist, een ontwerper, een tester, drie front-enders en een back-end. En natuurlijk een T-vormige specialist!
– Hoe zag het proces er in het algemeen uit?
Nikolay: Tot half maart hadden we helemaal niets klaar voor online. En op 15 maart begon de hele online carrousel te draaien. We hebben verschillende repositories opgezet, gepland, de basisarchitectuur besproken en alles in drie maanden gedaan.
Dit doorliep uiteraard de klassieke stadia van planning, architectuur, selectie van functies, stemmen op die functies, beleid voor die functies, hun ontwerp, ontwikkeling en testen. Als gevolg hiervan hebben we op 6 juni alles uitgerold naar productie. . Voor alles waren er 90 dagen.
– Zijn we erin geslaagd te bereiken waar we ons voor hebben geëngageerd?
Nikolay: Omdat we nu online deelnemen aan de DevOops-conferentie, betekent dit dat het werkte. Persoonlijk heb ik mij ingezet voor het belangrijkste: ik ga klanten een tool bieden waarmee ze een online conferentie kunnen maken.
De uitdaging was deze: geef ons een tool waarmee we onze conferenties kunnen uitzenden naar tickethouders.
Alle planning was verdeeld in verschillende fasen en alle functies (ongeveer 30 wereldwijd) waren onderverdeeld in 4 categorieën:
- wat we zeker zullen doen (we kunnen niet zonder hen leven),
- wat we in de tweede plaats zullen doen,
- wat we nooit zullen doen,
- en wat we nooit zullen doen.
We hebben alle functies uit de eerste twee categorieën gemaakt.
— Ik weet dat er in totaal 600 JIRA-uitgaves zijn gemaakt. In drie maanden tijd heb je dertien microservices gemaakt, en ik vermoed dat deze niet alleen in Java zijn geschreven. Je hebt verschillende technologieën gebruikt, je hebt twee Kubernetes-clusters in drie beschikbaarheidszones en vijf RTMP-streams in Amazon.
Laten we nu elk onderdeel van het systeem afzonderlijk bekijken.
Streamen
— Laten we beginnen als we al een videobeeld hebben en dit naar sommige diensten wordt verzonden. Artyom, vertel ons hoe deze streaming gebeurt?
Artjom Nikonov: Ons algemene schema ziet er als volgt uit: beeld van de camera -> onze controlekamer -> lokale RTMP-server -> Amazon -> videospeler. Meer details op Habré in juni.
Over het algemeen zijn er wereldwijd twee manieren om dit te doen: op hardware of op basis van softwareoplossingen. We hebben voor de softwareroute gekozen omdat deze gemakkelijker is in het geval van externe luidsprekers. Het is niet altijd mogelijk om hardware naar een speaker in een ander land te brengen, maar het leveren van software aan de speaker lijkt makkelijker en betrouwbaarder.
Hardwarematig gezien hebben we een bepaald aantal camera's (in onze studio's en bij luidsprekers op afstand), een bepaald aantal afstandsbedieningen in de studio, die soms tijdens de uitzending direct onder de tafel moeten worden gerepareerd.
Signalen van deze apparaten komen computers binnen met capture-kaarten, invoer-/uitvoerkaarten en geluidskaarten. Daar worden de signalen gemengd en samengevoegd tot lay-outs:
Voorbeeld van een opstelling voor 4 luidsprekers
Voorbeeld van een opstelling voor 4 luidsprekers
Verder wordt continu uitgezonden met behulp van drie computers: er is één hoofdmachine en een paar werkende machines. De eerste computer verzamelt het eerste rapport, de tweede - de pauze, de eerste - het volgende rapport, de tweede - de volgende pauze, enzovoort. En de hoofdmachine mengt de eerste met de tweede.
Hierdoor ontstaat er een soort driehoek, en als een van deze knooppunten uitvalt, kunnen we snel en zonder kwaliteitsverlies content blijven leveren aan klanten. Wij hadden zo'n situatie. Tijdens de eerste week van de conferenties hebben we één machine gerepareerd en aan/uitgezet. Mensen lijken blij te zijn met onze veerkracht.
Vervolgens gaan de streams van de computers naar een lokale server, die twee taken heeft: RTMP-streams routeren en back-ups maken. We hebben dus meerdere opnamepunten. De videostreams worden vervolgens verzonden naar het deel van ons systeem dat is gebouwd op Amazon SaaS-services. We gebruiken ,S3,CloudFront.
Nikolay: Wat gebeurt daar voordat de video het publiek bereikt? Je moet het op de een of andere manier knippen, toch?
Artjom: Wij comprimeren de video van onze kant en sturen deze naar MediaLive. We lanceren daar transcoders. Ze transcoderen video's in realtime naar verschillende resoluties, zodat mensen ze op hun telefoon kunnen bekijken, via het slechte internet in het land, enzovoort. Vervolgens worden deze stromen ingesneden , zo werkt het protocol . We sturen een afspeellijst naar de frontend die verwijzingen naar deze chunks bevat.
— Gebruiken we een resolutie van 1080p?
Artjom: De breedte van onze video is hetzelfde als 1080p - 1920 pixels, en de hoogte is iets minder, de afbeelding is langwerpiger - daar zijn redenen voor.
Speler
— Artyom beschreef hoe de video in streams terechtkomt, hoe deze wordt verdeeld in verschillende afspeellijsten voor verschillende schermresoluties, in stukjes wordt geknipt en in de speler terechtkomt. Kolya, vertel me nu wat voor soort speler dit is, hoe hij de stream verbruikt, waarom HLS?
Nikolay: We hebben een speler waar alle conferentiekijkers naar kunnen kijken.
In wezen is dit een omhulsel rond de bibliotheek , waarop veel andere spelers zijn geschreven. Maar we hadden heel specifieke functionaliteit nodig: terugspoelen en markeren van de plaats waar de persoon zich bevindt, welk rapport hij momenteel bekijkt. We hadden ook behoefte aan eigen layouts, allerlei logo's en al het andere dat bij ons ingebouwd was. Daarom hebben we besloten om onze eigen bibliotheek (een wrapper over HLS) te schrijven en deze op de site in te sluiten.
Dit is de rootfunctionaliteit, dus deze werd bijna als eerste geïmplementeerd. En toen groeide alles eromheen.
In feite ontvangt de speler, door middel van autorisatie, van de backend een afspeellijst met links naar fragmenten die verband houden met tijd en kwaliteit, downloadt de benodigde fragmenten en laat deze aan de gebruiker zien, terwijl hij gaandeweg wat “magie” uitvoert.
Tijdlijn voorbeeld
— Er is rechtstreeks in de speler een knop ingebouwd om een tijdlijn van alle rapporten weer te geven...
Nikolay: Ja, we hebben het probleem van de gebruikersnavigatie onmiddellijk opgelost. Half april besloten we dat we niet al onze conferenties op een aparte website zouden uitzenden, maar alles op één website zouden bundelen. Zodat gebruikers van Full Pass-tickets vrij kunnen schakelen tussen verschillende conferenties: zowel live-uitzendingen als opnames van eerdere conferenties.
En om het voor gebruikers gemakkelijker te maken om door de huidige stream te navigeren en tussen tracks te schakelen, hebben we besloten een knop 'Hele uitzending' en horizontale rapportkaarten te maken voor het schakelen tussen tracks en rapporten. Er is toetsenbordbediening.
— Waren er technische problemen mee?
Nikolay: Ze hadden een schuifbalk waarop de uitgangspunten van verschillende rapporten waren gemarkeerd.
— Heb je uiteindelijk deze markeringen op de schuifbalk geïmplementeerd voordat YouTube iets soortgelijks deed?
Artjom: Toen hadden ze het nog in beta. Het lijkt erop dat dit een behoorlijk complexe functie is, omdat ze deze het afgelopen jaar gedeeltelijk met gebruikers hebben getest. En nu is het in de uitverkoop.
Nikolay: Maar we kregen het eigenlijk sneller in de verkoop. Eerlijk gezegd schuilt er achter deze eenvoudige functie een enorme hoeveelheid backend, frontend, berekeningen en wiskunde in de speler.
Voorkant
— Laten we eens kijken hoe de inhoud die we laten zien (toespraakkaart, sprekers, website, schema) op de voorkant komt?
Vladimir Krasilsjtsjik: We hebben verschillende interne IT-systemen. Er is een systeem waarin alle meldingen en alle sprekers worden ingevoerd. Er is een proces waarbij een spreker deelneemt aan een conferentie. De spreker dient een aanvraag in, het systeem registreert deze en er is een bepaalde pijplijn op basis waarvan het rapport wordt gemaakt.
Dit is hoe de spreker de pijplijn ziet
Dit systeem is onze interne ontwikkeling.
Vervolgens moet u een schema samenstellen op basis van individuele rapporten. Zoals u weet is dit een NP-moeilijk probleem, maar we lossen het op de een of andere manier op. Om dit te doen, lanceren we een ander onderdeel dat een planning genereert en deze uploadt naar de externe cloudservice Contentful. Daar ziet alles eruit als een tabel waarin er dagen van de conferentie zijn, in de dagen zijn er tijdslots en in de slots staan verslagen, pauzes of sponsoractiviteiten. De inhoud die we zien, bevindt zich dus in een service van derden. En de taak is om het naar de site over te brengen.
Het lijkt erop dat de site slechts een pagina is met een speler, en er is hier niets ingewikkelds. Maar dat is het niet. De backend achter deze pagina gaat naar Contentful, haalt daar de planning op, genereert enkele objecten en stuurt deze naar de frontend. Via een websocket-verbinding, die iedere klant van ons platform maakt, sturen we hem een update van de planning van de backend naar de frontend.
Real case: de spreker veranderde tijdens de conferentie van baan. We moeten zijn werkgeversbedrijfsbadge wijzigen. Hoe gebeurt dit vanuit de backend? Er wordt via de websocket een update naar alle clients verzonden, waarna de frontend zelf de tijdlijn opnieuw tekent. Dit alles gebeurt naadloos. De combinatie van de clouddienst en een aantal van onze componenten geeft ons de mogelijkheid om al deze content te genereren en aan de voorkant aan te bieden.
Nikolay: Het is belangrijk om hier duidelijk te maken dat onze site geen klassieke SPA-applicatie is. Dit is zowel een op lay-out gebaseerde, weergegeven website als een SPA. Google beschouwt deze site eigenlijk als weergegeven HTML. Dit is goed voor SEO en voor het leveren van inhoud aan de gebruiker. Het wacht niet tot 1,5 megabyte JavaScript is geladen voordat het de pagina ziet; het ziet onmiddellijk de reeds weergegeven pagina, en u voelt het elke keer dat u van rapport wisselt. Alles gebeurt in een halve seconde, omdat de content al klaar is en op de juiste plek wordt geplaatst.
— Laten we een grens trekken onder al het bovenstaande door de technologieën op te sommen. Tyoma zei dat we vijf Amazon-streams hebben en daar video en geluid leveren. We hebben daar bash-scripts, we gebruiken ze om te starten en te configureren...
Artjom: Dit gebeurt via de AWS API, daar zijn nog veel meer technische nevendiensten. We hebben onze verantwoordelijkheden verdeeld, zodat ik aan mijn verwachtingen kan voldoen , en front-end- en back-end-ontwikkelaars nemen het vanaf daar over. We hebben een aantal eigen bindingen om de opmaak van content te vereenvoudigen, die we vervolgens in 4K etc. maken. Omdat de deadlines erg krap waren, hebben we het vrijwel volledig op AWS gedaan.
— Vervolgens gaat dit allemaal naar de speler via het backend-systeem. We hebben TypeScript, React, Next.JS in onze speler. En op de backend hebben we verschillende services in C#, Java, Spring Boot en Node.js. Dit wordt allemaal geïmplementeerd met behulp van Kubernetes met behulp van de Yandex.Cloud-infrastructuur.
Ik wil ook opmerken dat toen ik kennis moest maken met het platform, het gemakkelijk bleek te zijn: alle repositories staan op GitLab, alles heeft een goede naam, tests zijn geschreven, er is documentatie. Dat wil zeggen, zelfs in de noodmodus zorgden ze voor zulke dingen.
Zakelijke beperkingen en analyses
— We targetten 10 gebruikers op basis van zakelijke vereisten. Het is tijd om te praten over de zakelijke beperkingen die we hadden. We moesten zorgen voor een hoge werkdruk en zorgen voor naleving van de wet op de bewaring van persoonsgegevens. En wat nog meer?
Nikolay: In eerste instantie zijn we uitgegaan van videovereisten. Het allerbelangrijkste is de gedistribueerde video-opslag over de hele wereld voor een snelle levering aan de klant. Anderen hebben een resolutie van 1080p en terugspoelen, wat veel anderen niet in de live-modus implementeren. Later hebben we de mogelijkheid toegevoegd om 2x snelheid in te schakelen, met behulp hiervan kunt u de live-conferentie volgen en de conferentie in realtime blijven bekijken. En gaandeweg verscheen de functionaliteit voor tijdlijnmarkering. Bovendien moesten we fouttolerant zijn en bestand zijn tegen de belasting van 10 verbindingen. Vanuit backend-oogpunt zijn dit ongeveer 000 verbindingen, vermenigvuldigd met 10 verzoeken voor elke paginavernieuwing. En dit is al 000 RPS/sec. Nogal wat.
— Waren er nog andere vereisten voor een “virtuele tentoonstelling” met online stands van partners?
Nikolay: Ja, dit moest vrij snel en universeel gebeuren. We hadden voor elke conferentie wel tien partnerbedrijven, en die moesten allemaal binnen een week of twee worden afgerond. Hun inhoud verschilt echter enigszins qua formaat. Maar er is een bepaalde sjabloon-engine gemaakt die deze pagina's in een handomdraai samenstelt, zonder verdere ontwikkelingsdeelname.
— Er waren ook vereisten voor analyse van realtime weergaven en statistieken. Ik weet dat we Prometheus hiervoor gebruiken, maar vertel ons eens wat gedetailleerder: aan welke eisen voldoen we aan analytics, en hoe wordt dit geïmplementeerd?
Nikolay: In eerste instantie hebben we marketingvereisten voor het verzamelen voor A/B-testen en het verzamelen van informatie om te begrijpen hoe we in de toekomst de beste inhoud aan de klant kunnen leveren. Er zijn ook vereisten voor bepaalde analyses van partneractiviteiten en de analyses die u ziet (bezoekteller). Alle informatie wordt in realtime verzameld.
We kunnen deze informatie zelfs in geaggregeerde vorm aan sprekers verstrekken: hoeveel mensen keken op een bepaald moment naar u. Tegelijkertijd worden, om te voldoen aan Federale Wet 152, uw persoonlijke account en persoonlijke gegevens op geen enkele manier gevolgd.
Het platform beschikt al over marketingtools en onze statistieken voor het in realtime meten van gebruikersactiviteit (wie heeft welke seconde van het rapport bekeken) om grafieken te maken van de deelname aan de rapporten. Op basis van deze gegevens wordt onderzoek gedaan dat de volgende conferenties beter zal maken.
Fraude
— Hebben we antifraudemechanismen?
Nikolay: Vanwege het krappe tijdsbestek vanuit zakelijk oogpunt was het aanvankelijk niet de taak om onnodige verbindingen onmiddellijk te blokkeren. Als twee gebruikers zich onder hetzelfde account hadden aangemeld, konden ze de inhoud bekijken. Maar we weten hoeveel gelijktijdige weergaven er vanuit één account waren. En we hebben een aantal bijzonder kwaadaardige overtreders verboden.
Vladimir: Het strekt tot eer dat een van de verboden gebruikers begreep waarom dit gebeurde. Hij kwam, verontschuldigde zich en beloofde een kaartje te kopen.
— Om dit allemaal te laten gebeuren, moet u alle gebruikers volledig traceren van binnenkomst tot vertrek, en altijd weten wat ze doen. Hoe werkt dit systeem?
Vladimir: Ik zou het graag willen hebben over analyses en statistieken, die we vervolgens analyseren voor het succes van het rapport of die we vervolgens aan partners kunnen verstrekken. Alle clients zijn via een websocket-verbinding verbonden met een specifiek backend-cluster. Het staat daar . Elke klant stuurt in elke tijdsperiode wat hij aan het doen is en naar welk nummer hij kijkt. Vervolgens wordt deze informatie verzameld met behulp van snelle Hazelcast-taken en teruggestuurd naar iedereen die deze nummers bekijkt. In de hoek zien we hoeveel mensen er nu bij ons zijn.
Dezelfde informatie wordt opgeslagen in en gaat naar ons datameer, van waaruit we een interessantere grafiek kunnen bouwen. De vraag rijst: hoeveel unieke gebruikers hebben dit rapport bekeken? We gaan naar , er zijn pings van alle mensen die langs de id van dit rapport kwamen. We hebben unieke verzameld en samengevoegd, en nu kunnen we het begrijpen.
Nikolay: Maar tegelijkertijd ontvangen we ook realtime data van Prometheus. Het is gericht tegen alle Kubernetes-services, tegen Kubernetes zelf. Het verzamelt absoluut alles, en met Grafana kunnen we alle grafieken in realtime maken.
Vladimir: Enerzijds downloaden we dit voor verdere OLAP-verwerking. En voor OLTP downloadt de applicatie het hele ding naar Prometheus, Grafana en de grafieken komen zelfs samen!
- Dit is het geval wanneer de grafieken convergeren.
Dynamische veranderingen
— Vertel ons hoe dynamische veranderingen worden uitgerold: als het rapport zes minuten voor aanvang wordt geannuleerd, wat is dan de keten van acties? Welke pijpleiding werkt?
Vladimir: De pijplijn is zeer voorwaardelijk. Er zijn verschillende mogelijkheden. De eerste is dat het schemageneratieprogramma werkte en het schema veranderde. Het aangepaste rooster wordt geüpload naar Contentful. Waarna de backend begrijpt dat er wijzigingen zijn voor deze conferentie in Contentful, deze opneemt en opnieuw opbouwt. Alles wordt verzameld en verzonden via websocket.
De tweede mogelijkheid, wanneer alles in een razend tempo gebeurt: de editor wijzigt handmatig de informatie in Contentful (link naar Telegram, sprekerspresentatie, etc.) en dezelfde logica werkt als de eerste keer.
Nikolay: Alles gebeurt zonder de pagina te vernieuwen. Alle wijzigingen gebeuren absoluut naadloos voor de klant. Hetzelfde geldt voor het wisselen van rapporten. Als het zover is, veranderen het rapport en de interface.
Vladimir: Er zijn ook tijdslimieten voor het starten van rapporten in de tijdlijn. Helemaal aan het begin is er niets. En als u met uw muis over de rode streep beweegt, verschijnen er op een gegeven moment, dankzij de uitzendregisseur, onderbrekingen. De regisseur stelt de juiste start van de uitzending in, de backend pikt deze wijziging op, berekent de begin- en eindtijden van de presentaties van de hele track volgens het conferentieschema, stuurt deze naar onze klanten en de speler trekt cutoffs. Nu kan de gebruiker eenvoudig naar het begin en einde van het rapport navigeren. Het was een strikte zakelijke vereiste, erg handig en nuttig. U verspilt geen tijd met het zoeken naar de werkelijke starttijd van het rapport. En als we een preview doen, zal het absoluut geweldig zijn.
Inzet
— Ik zou graag iets willen vragen over de inzet. Kolya en het team hebben in het begin veel tijd besteed aan het opzetten van de gehele infrastructuur waarin alles zich voor ons ontvouwt. Vertel me eens, waar is het allemaal van gemaakt?
Nikolay: Vanuit technisch oogpunt hadden we aanvankelijk de eis dat het product van welke leverancier dan ook zo abstract mogelijk moest zijn. Kom naar AWS om Terraform-scripts specifiek vanuit AWS te maken, of specifiek vanuit Yandex, of vanuit Azure, enz. paste niet echt. Op een gegeven moment moesten we ergens heen verhuizen.
De eerste drie weken waren we voortdurend op zoek naar een manier om dit beter te doen. Als gevolg hiervan kwamen we tot de conclusie dat Kubernetes in dit geval ons alles is, omdat het ons in staat stelt automatisch opschalende services te creëren, automatisch uit te rollen en bijna alle services out-of-the-box te krijgen. Uiteraard moesten alle diensten getraind worden om met Kubernetes en Docker te kunnen werken, en dat moest het team ook leren.
We hebben twee clusters. Testen en productie. Ze zijn absoluut identiek qua hardware en instellingen. Wij implementeren infrastructuur als code. Alle services worden automatisch uitgerold naar drie omgevingen, van feature branches, master branches, test branches en GitLab met behulp van een automatische pijplijn. Dit is maximaal geïntegreerd in GitLab, maximaal geïntegreerd met Elastic, Prometheus.
Wij krijgen de mogelijkheid om snel (voor de backend binnen 10 minuten, voor de frontend binnen 5 minuten) wijzigingen uit te rollen in iedere omgeving met alle testen, integraties, functionele testen draaien, integratietesten op de omgeving, en ook testen met loadtesten op een testomgeving die ongeveer hetzelfde is als wat we in productie willen krijgen.
Over testen
— Je test bijna alles, het is moeilijk te geloven hoe je alles hebt geschreven. Kunt u ons iets vertellen over de backend-tests: hoeveel alles wordt gedekt, welke tests?
Vladimir: Er zijn twee soorten tests geschreven. De eerste zijn componenttests. Hefniveautests van de gehele veertoepassing en basis . Dit is een test van bedrijfsscenario's op het hoogste niveau. Ik test geen functies. We testen alleen enkele grote dingen. Zo wordt tijdens de test bijvoorbeeld het inlogproces van een gebruiker nagebootst, het verzoek van de gebruiker om kaartjes voor waar hij heen kan en een verzoek om toegang om de stream te bekijken. Zeer duidelijke gebruikersscenario's.
Ongeveer hetzelfde wordt geïmplementeerd in de zogenaamde integratietesten, die feitelijk op de omgeving draaien. Sterker nog, wanneer de volgende implementatie in productie wordt uitgerold, draaien echte basisscenario’s ook in productie. Dezelfde login, tickets aanvragen, toegang tot CloudFront aanvragen, controleren of de stream echt verbinding maakt met mijn rechten, de interface van de regisseur controleren.
Op dit moment heb ik zo’n 70 componenttesten en zo’n 40 integratietesten aan boord. De dekking bedraagt zeer dicht bij 95%. Dit geldt voor de componenten, en minder voor de integraties; er is simpelweg niet zo veel nodig. Gezien het feit dat het project allerlei soorten codegeneratie omvat, is dit een zeer goede indicator. Er was geen andere manier om te doen wat we in drie maanden tijd hebben gedaan. Want als we handmatig zouden testen, functies aan onze tester zouden geven, en zij zou bugs vinden en deze naar ons terugsturen voor reparaties, dan zou deze heen- en terugreis om de code te debuggen erg lang duren en zouden we geen enkele deadline halen.
Nikolay: Om een regressie op het hele platform uit te voeren bij het veranderen van een functie, moet je normaal gesproken twee dagen overal zitten en porren.
Vladimir: Het is dan ook een groot succes dat als ik een feature inschat, ik zeg dat ik 4 dagen nodig heb voor twee simpele pennen en 1 websocket, Kolya staat het toe. Hij is er al aan gewend dat deze 4 dagen 2 soorten tests omvatten, en dan zal het hoogstwaarschijnlijk werken.
Nikolay: Ik heb ook 140 tests geschreven: component + functioneel, die hetzelfde doen. Alle dezelfde scenario's worden getest in productie, in test en in productie. We hebben onlangs ook functionele basis-UI-tests toegevoegd. Op deze manier behandelen we de meest elementaire functionaliteit die uit elkaar kan vallen.
Vladimir: Natuurlijk is het de moeite waard om over belastingstests te praten. Het was nodig om het platform te testen onder een belasting die dicht bij de echte lag om te begrijpen hoe alles is, wat er gebeurt met Rabbit, wat er gebeurt met de JVM's, hoeveel geheugen er eigenlijk nodig is.
— Ik weet niet zeker of we iets aan de streamkant testen, maar ik herinner me dat er problemen waren met transcoders tijdens onze bijeenkomsten. Hebben we de streams getest?
Artjom: Iteratief getest. Het organiseren van meetups. Tijdens het organiseren van meetups waren er ongeveer 2300 JIRA-tickets. Dit zijn slechts algemene dingen die mensen deden om bijeenkomsten te organiseren. We hebben delen van het platform naar een aparte pagina voor bijeenkomsten gebracht, die werd beheerd door Kirill Tolkachev ().
Eerlijk gezegd waren er geen grote problemen. Letterlijk een paar keer hebben we caching-bugs op CloudFront ontdekt, we hebben het vrij snel opgelost - we hebben eenvoudigweg het beleid opnieuw geconfigureerd. Er zaten aanzienlijk meer bugs bij mensen in de streamingsystemen op de site.
Tijdens de conferenties moest ik nog een aantal exporteurs aanschrijven om meer apparatuur en diensten te kunnen bestrijken. Op sommige plaatsen moest ik alleen vanwege de meetgegevens mijn eigen fietsen maken. De wereld van AV-hardware (audio-video) is niet erg rooskleurig: je hebt een soort “API” van apparatuur waar je simpelweg geen invloed op hebt. En het is verre van een feit dat u de informatie kunt krijgen die u nodig heeft. Hardwareleveranciers zijn erg traag en het is bijna onmogelijk om van hen te krijgen wat je wilt. In totaal zijn er meer dan 100 hardwarestukken, ze geven niet terug wat je nodig hebt, en je schrijft vreemde en overbodige exporteurs, waardoor je op de een of andere manier het systeem kunt debuggen.
Uitrusting
— Ik herinner me hoe we vóór het begin van de conferenties gedeeltelijk extra apparatuur kochten.
Artjom: We kochten computers, laptops en batterijpakketten. Momenteel kunnen we 40 minuten zonder elektriciteit leven. In juni waren er zware onweersbuien in Sint-Petersburg, dus we hadden zo'n black-out. Tegelijkertijd komen verschillende aanbieders vanuit verschillende punten naar ons toe met optische links. Dit is in werkelijkheid 40 minuten stilstand van het gebouw, waarin we het licht aan hebben, het geluid, de camera's etc. aan hebben.
— We hebben een soortgelijk verhaal met internet. In het kantoor waar onze studio’s zich bevinden, hebben we een fel net tussen de verdiepingen gesleept.
Artjom: We hebben 20 Gbit glasvezel tussen de verdiepingen. Verderop op de verdiepingen is er ergens optica, ergens is er geen optica, maar er zijn nog steeds minder kanalen dan gigabitkanalen - we draaien video erop tussen de nummers van de conferentie. Over het algemeen is het erg handig om aan uw eigen infrastructuur te werken; dit kunt u zelden doen tijdens offline conferenties op locaties.
— Voordat ik bij JUG Ru Group werkte, zag ik hoe hardwareruimtes op offline conferenties van de ene op de andere dag werden opgezet, waar een grote monitor stond met alle statistieken die je in Grafana bouwt. Nu is er ook een hoofdkantoorruimte waar het ontwikkelteam zit, dat tijdens de conferentie enkele bugs oplost en features ontwikkelt. Tegelijkertijd is er een monitoringsysteem dat op een groot scherm wordt weergegeven. Artyom, Kolya en andere jongens gaan zitten en zorgen ervoor dat alles niet valt en mooi werkt.
Curiosa en problemen
— Je hebt goed gesproken over het feit dat we streaming hebben met Amazon, er is een speler met internet, alles is geschreven in verschillende programmeertalen, er is voorzien in fouttolerantie en andere zakelijke vereisten, inclusief een persoonlijk account dat wordt ondersteund voor rechtspersonen en individuen, en we kunnen integreren met iemand die OAuth 2.0 gebruikt, er is fraudebestrijding en gebruikersblokkering. We kunnen veranderingen dynamisch uitrollen omdat we het goed hebben gedaan en het allemaal is getest.
Ik ben benieuwd welke eigenaardigheden er bij betrokken waren om iets op gang te brengen. Zijn er vreemde situaties geweest toen je een backend, frontend aan het ontwikkelen was, er iets geks uitkwam en je niet begreep wat je ermee moest doen?
Vladimir: Het lijkt mij dat dit pas de afgelopen drie maanden is gebeurd. Elke dag. Zoals je kunt zien, is al mijn haar uitgetrokken.
Vladimir Krasilshchik na 3 maanden, toen er een soort spel bleek te zijn en niemand begreep wat hij ermee moest doen
Elke dag was er zoiets als dit, toen er zo'n moment was waarop je het pakte en je haar eruit trok, of besefte dat er niemand anders is en alleen jij het kunt doen. Ons eerste grote evenement was TechTrain. Op 6 juni om 2 uur hadden we de productieomgeving nog niet uitgerold, Kolya was deze aan het uitrollen. En het persoonlijke account werkte niet als autorisatieserver met OAuth2.0. We hebben er een OAuth2.0-provider van gemaakt om het platform ermee te verbinden. Ik had waarschijnlijk 18 uur achter elkaar gewerkt, ik keek naar de computer en zag niets, ik begreep niet waarom het niet werkte, en Kolya bekeek mijn code op afstand, zocht naar een bug in de Spring-configuratie , vond het, en de LC werkte, en ook in productie.
Nikolay: En een uur voor TechTrain vond de release plaats.
Hier stonden veel sterren op één lijn. We hadden enorm veel geluk omdat we een superteam hadden en iedereen geïnspireerd was door het idee om het online te doen. Al deze drie maanden werden we gedreven door het feit dat we ‘YouTube hebben gemaakt’. Ik stond mezelf niet toe mijn haar uit te trekken, maar vertelde iedereen dat alles goed zou komen, omdat alles in feite al lang geleden was berekend.
Over prestaties
— Kun je mij vertellen hoeveel mensen er op één track op de site waren? Waren er prestatieproblemen?
Nikolay: Er waren geen prestatieproblemen, zoals we al zeiden. Het maximale aantal mensen dat één melding bijwoonde was 1300 personen, dit staat op Heisenbug.
— Waren er problemen met de lokale weergave? En is het mogelijk om een technische beschrijving met diagrammen te krijgen van hoe het allemaal werkt?
Nikolay: We zullen hier later een artikel over maken.
Je kunt streams zelfs lokaal debuggen. Toen de conferenties eenmaal begonnen, werd het nog eenvoudiger, omdat er productiestromen verschenen waar we de hele tijd naar kunnen kijken.
Vladimir: Zoals ik het begrijp, werkten front-end-ontwikkelaars lokaal met mocks, en aangezien de tijd om uit te rollen naar de ontwikkelaars aan de voorkant ook kort is (5 minuten), zijn er geen problemen met het controleren van wat er met de certificaten aan de hand is.
— Alles wordt getest en opgespoord, zelfs lokaal. Dit betekent dat we een artikel schrijven met alle technische kenmerken, je laten zien, alles vertellen met diagrammen, hoe het was.
Vladimir: Je kunt het nemen en herhalen.
- Over 3 maanden.
Totaal
— Alles wat samen wordt beschreven klinkt cool, gezien het feit dat het in drie maanden tijd door een klein team is gedaan.
Nikolay: Een groot team zou dit niet doen. Maar een kleine groep mensen die heel nauw en goed met elkaar communiceren en tot overeenstemming kunnen komen, kunnen dat wel. Ze kennen geen tegenstrijdigheden, de architectuur is in twee dagen uitgevonden, voltooid en eigenlijk niet veranderd. Er is een zeer strikte facilitering van inkomende zakelijke vereisten in termen van het opstapelen van functieverzoeken en wijzigingen.
— Wat stond er op uw lijst met verdere taken toen de zomerconferenties al hadden plaatsgevonden?
Nikolay: Bijvoorbeeld kredieten. Kruipende lijnen in de video, pop-ups op sommige plaatsen in de video, afhankelijk van de inhoud die wordt getoond. De spreker wil bijvoorbeeld een vraag stellen aan het publiek en er verschijnt een stem op het scherm, die op basis van de stemresultaten naar de spreker zelf teruggaat naar achteren. Een soort sociale activiteit in de vorm van likes, hartjes, beoordelingen van het rapport tijdens de presentatie zelf, zodat je op het juiste moment feedback kunt invullen zonder later afgeleid te worden door feedbackformulieren. In eerste instantie zo.
En ook om aan het hele platform, behalve streaming en conferentie, ook een post-conferentiestatus toe te voegen. Dit zijn afspeellijsten (inclusief die samengesteld door gebruikers), mogelijk inhoud van andere eerdere conferenties, geïntegreerd, gelabeld, toegankelijk voor de gebruiker en ook beschikbaar om te bekijken op onze website ().
— Jongens, hartelijk dank voor jullie antwoorden!
Als er onder de lezers mensen zijn die onze zomerconferenties hebben bijgewoond, deel dan uw indrukken van de speler en uitzending. Wat was handig, wat irriteerde je, wat zou je graag willen zien in de toekomst?
Als je geïnteresseerd bent in het platform en het “in de strijd” wilt zien, gebruiken we het opnieuw op onze . Er is een hele reeks, dus er is vrijwel zeker één die bij je past.
Bron: www.habr.com