Vorige week ging ik naar de DUMP IT-conferentie (https://dump-ekb.ru/) in Jekaterinenburg en ik wil je vertellen wat er werd besproken in de Backend- en Devops-secties, en of regionale IT-conferenties de aandacht waard zijn.
Nikolay Sverchkov van Evil Martians over Serverless
Wat was er eigenlijk?
In totaal bestond de conferentie uit 8 secties: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science en Management.
De grootste zalen bevinden zich trouwens bij Science and Management)) Voor ongeveer 350 personen elk. Backend en Frontend zijn niet veel kleiner. De Devops-kamer was de kleinste, maar actief.
Ik luisterde naar de rapporten in de secties Devops en Backend en sprak een beetje met de sprekers. Ik zou graag willen praten over de behandelde onderwerpen en deze secties op de conferentie willen bespreken.
Vertegenwoordigers van SKB-Kontur, DataArt, Evil Martians, Ekaterinburg webstudio Flag, Miro (RealTimeBoard) spraken in de Devops- en Backend-secties. Onderwerpen die aan bod kwamen, waren CI/CD, werken met wachtrijservices, loggen; Serverloze onderwerpen en werken met PostgreSQL in Go kwamen goed aan bod.
Er waren ook rapporten van Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, maar ik had geen tijd om ze fysiek bij te wonen (video-opnamen en dia's van de rapporten zijn nog niet beschikbaar, ze beloven ze binnen 2 weken te plaatsen op dump-ekb.ru).
Devops-sectie
Wat verrassend was, was dat de sectie in de kleinste zaal werd gehouden, ongeveer 50 zitplaatsen. Er stonden zelfs mensen in de gangpaden :) Ik zal je vertellen over de rapporten waar ik naar heb kunnen luisteren.
Elastiek met een gewicht van een petabyte
De sectie begon met een rapport van Vladimir Lil (SKB-Kontur) over Elasticsearch in Kontur. Ze hebben een vrij grote en geladen Elastic (~800 TB aan gegevens, ~1.3 petabytes rekening houdend met redundantie). Elasticsearch voor alle Kontur-services is single, bestaat uit 2 clusters (van 7 en 9 servers) en is zo belangrijk dat Kontur een speciale Elasticsearch-engineer heeft (in feite Vladimir zelf).
Vladimir deelde ook zijn gedachten over de voordelen van Elasticsearch en de problemen die het met zich meebrengt.
voordelen:
- Alle logboeken bevinden zich op één plek, zodat u er gemakkelijk toegang toe heeft
- Logboeken een jaar lang bewaren en eenvoudig analyseren
- Hoge snelheid van werken met boomstammen
- Coole datavisualisatie out-of-the-box
Eigenschappen:
- message broker is een must-have (voor Kontur wordt de rol gespeeld door Kafka)
- kenmerken van het werken met Elasticsearch Curator (periodiek hoge belasting veroorzaakt door reguliere taken in Curator)
- geen ingebouwde autorisatie (alleen voor afzonderlijk, vrij groot geld, of als open source plug-ins met verschillende mate van gereedheid voor productie)
Er waren alleen positieve recensies over Open Distro voor Elasticsearch :) Hetzelfde autorisatieprobleem is daar opgelost.
Waar komt de petabyte vandaan?Hun knooppunten bestaan uit servers met 12*8 Tb SATA + 2*2 Tb SSD. Koude opslag op SATA, SSD alleen voor hot cache (hot storage).
7+9 servers, (7 + 9) * 12 * 8 = 1536 Tb.
Een deel van de ruimte is gereserveerd, gereserveerd voor overtolligheid, enz.
Logs van ongeveer 90 applicaties worden naar Elasticsearch verzonden, inclusief alle rapportagediensten van Kontur, Elba, etc.
Kenmerken van ontwikkeling op Serverless
Hierna volgt een rapport van Ruslan Serkin van DataArt over Serverless.
Ruslan vertelde over wat ontwikkeling met de Serverless-aanpak in het algemeen is, en wat de kenmerken ervan zijn.
Serverless is een ontwikkelingsbenadering waarbij ontwikkelaars op geen enkele manier de infrastructuur aanraken. Voorbeeld - AWS Lambda Serverless, Kubeless.io (Serverless binnen Kubernetes), Google Cloud Functions.
Een ideale Serverless applicatie is simpelweg een functie die via een speciale API Gateway een verzoek naar een Serverless provider stuurt. Een ideale microservice, terwijl AWS Lambda ook een groot aantal moderne programmeertalen ondersteunt. De kosten voor het onderhouden en inzetten van infrastructuur worden nul in het geval van cloudproviders, het ondersteunen van kleine applicaties zal ook erg goedkoop zijn (AWS Lambda - $0.2 / 1 miljoen eenvoudige verzoeken).
De schaalbaarheid van zo’n systeem is bijna ideaal: de cloudprovider regelt dit zelf, Kubeless schaalt automatisch binnen het Kubernetes-cluster.
Er zijn nadelen:
- Het ontwikkelen van grote applicaties wordt steeds lastiger
- er zijn problemen met profileringsapplicaties (je hebt alleen toegang tot logs, maar niet tot profilering in de gebruikelijke zin)
- geen versiebeheer
Eerlijk gezegd hoorde ik een paar jaar geleden over Serverless, maar al die jaren was het mij niet duidelijk hoe ik het correct moest gebruiken. Na het rapport van Ruslan verscheen er begrip, en na het rapport van Nikolai Sverchkov (Evil Martians) uit de Backend-sectie werd het geconsolideerd. Het was niet voor niets dat ik naar de conferentie ging :)
CI is voor de armen, of is het de moeite waard om je eigen CI voor een webstudio te schrijven?
Mikhail Radionov, hoofd van de Flag-webstudio uit Jekaterinenburg, sprak over zelfgeschreven CI/CD.
Zijn studio is overgegaan van “manual CI/CD” (log in op de server via SSH, doe een git pull, herhaal 100 keer per dag) naar Jenkins en naar een zelfgeschreven tool waarmee je code kunt monitoren en releases kunt uitvoeren genaamd Pullkins .
Waarom werkte Jenkins niet? Het bood standaard niet voldoende flexibiliteit en was te moeilijk om aan te passen.
“Flag” ontwikkelt in Laravel (PHP-framework). Bij het ontwikkelen van een CI/CD-server gebruikten Mikhail en zijn collega's de ingebouwde mechanismen van Laravel, genaamd Telescope en Envoy. Het resultaat was een server in PHP (let op) die inkomende webhookverzoeken verwerkt, frontend en backend kan bouwen, op verschillende servers kan implementeren en kan rapporteren aan Slack.
Om vervolgens blauw/groen te kunnen implementeren en uniforme instellingen te hebben in dev-stage-prod-omgevingen, zijn ze overgestapt op Docker. De voordelen bleven hetzelfde, de mogelijkheden van homogenisering van de omgeving en naadloze implementatie werden toegevoegd, en de noodzaak om Docker er correct mee te leren werken werd toegevoegd.
Hoe we het aantal terugdraaiingen van serverreleases met 99% hebben verminderd
Het laatste rapport in de Devops-sectie was van Viktor Eremchenko, Lead devops-ingenieur bij Miro.com (voorheen RealTimeBoard).
RealTimeBoard, het vlaggenschipproduct van het Miro-team, is gebaseerd op een monolithische Java-applicatie. Het verzamelen, testen en inzetten ervan zonder downtime is een lastige opgave. In dit geval is het belangrijk om een dergelijke versie van de code in te zetten, zodat deze niet teruggedraaid hoeft te worden (het is een zware monoliet).
Op weg naar het bouwen van een systeem waarmee je dit kunt doen, heeft Miro een traject doorlopen waarbij onder meer werd gewerkt aan de architectuur, de gebruikte tools (Atlassian Bamboo, Ansible, enz.) en aan de structuur van de teams (ze hebben nu een toegewijd Devops-team + veel afzonderlijke Scrum-teams van ontwikkelaars met verschillende profielen).
Het pad bleek moeilijk en netelig, en Victor deelde de opgebouwde pijn en het optimisme dat daar niet ophield.
Boek gewonnen waarin je vragen kunt stellen
Backend-sectie
Ik heb twee rapporten kunnen bijwonen - van Nikolay Sverchkov (Evil Martians), ook over Serverless, en van Grigory Koshelev (Kontur-bedrijf) over telemetrie.
Serverloos voor gewone stervelingen
Als Ruslan Sirkin sprak over wat Serverless is, liet Nikolay eenvoudige applicaties zien die Serverless gebruiken, en vertelde hij over de details die van invloed zijn op de kosten en snelheid van applicaties in AWS Lambda.
Een interessant detail: het minimaal betaalde element is 128 Mb geheugen en 100 ms CPU, het kost $ 0,000000208. Bovendien zijn 1 miljoen van dergelijke verzoeken per maand gratis.
Sommige functies van Nikolai overschreden vaak de limiet van 100 ms (de hoofdapplicatie was geschreven in Ruby), dus het herschrijven ervan in Go leverde uitstekende besparingen op.
Vostok Hercules – maak telemetrie weer geweldig!
Het laatste rapport van de Backend-sectie van Grigory Koshelev (Kontur-bedrijf) over telemetrie. Telemetrie betekent logboeken, statistieken en applicatiesporen.
Hiervoor gebruikt Contour zelfgeschreven tools die op Github zijn geplaatst. Hulpmiddel uit het rapport - Hercules, , wordt gebruikt om telemetriegegevens te leveren.
Vladimir Lila's rapport in de Devops-sectie besprak het opslaan en verwerken van logs in Elasticsearch, maar het is nog steeds de taak om logs van vele duizenden apparaten en applicaties aan te leveren, en tools zoals Vostok Hercules lossen deze op.
Het circuit volgde een pad dat bij velen bekend is - van RabbitMQ tot Apache Kafka, maar niet alles is zo eenvoudig)) Ze moesten Zookeeper, Cassandra en Graphite aan het circuit toevoegen. Ik zal de informatie in dit rapport (niet mijn profiel) niet volledig openbaar maken. Als u geïnteresseerd bent, kunt u wachten op de dia's en video's op de conferentiewebsite.
Hoe verhoudt het zich tot andere conferenties?
Ik kan het niet vergelijken met conferenties in Moskou en Sint-Petersburg, ik kan het vergelijken met andere evenementen in de Oeral en met 404fest in Samara.
DAMP wordt gehouden in 8 secties, dit is een record voor Ural-conferenties. Zeer grote secties Wetenschap en Management, ook dit is ongebruikelijk. Het publiek in Jekaterinenburg is behoorlijk gestructureerd - de stad heeft grote ontwikkelingsafdelingen voor Yandex, Kontur, Tinkoff, en dit drukt zijn stempel op de rapporten.
Een ander interessant punt is dat veel bedrijven 3-4 sprekers tegelijk op de conferentie hebben (dit was het geval bij Kontur, Evil Martians, Tinkoff). Velen van hen waren sponsors, maar de rapporten zijn redelijk vergelijkbaar met die van anderen, dit zijn geen reclamerapporten.
Wel of niet gaan? Als je in de Oeral of in de buurt woont, heb je de mogelijkheid en ben je geïnteresseerd in de onderwerpen - ja, natuurlijk. Als je aan een lange reis denkt, zou ik kijken naar de onderwerpen van reportages en videoreportages van voorgaande jaren en nam een besluit.
Een ander voordeel van conferenties in de regio's is in de regel dat het gemakkelijk is om na de rapporten met de spreker te communiceren; er zijn simpelweg minder aanvragers voor dergelijke communicatie.
Met dank aan Dump en Jekaterinenburg! )
Bron: www.habr.com
