DUMP konverents | grep ‘backend|devops’

Eelmisel nädalal käisin IT-konverentsil DUMP (https://dump-ekb.ru/) Jekaterinburgis ja tahan rääkida, millest räägiti Backend ja Devops sektsioonides ning kas piirkondlikud IT-konverentsid on tähelepanu väärt.

Nikolai Sverchkov Evil Martiansilt Serverlessist

Mis seal üldse toimus?

Konverentsil oli kokku 8 sektsiooni: Backend, Frontend, Mobile, Testimine ja QA, Devops, Disain, Teadus ja Juhtimine.

Kõige suuremad saalid olid muide Teaduse ja Juhtimise omad, mahutades igaüks umbes 350 inimest. Backend ja Frontend olid veidi väiksemad. Devops saal oli kõige väiksem, kuid aktiivne.

Kuulasin ettekandeid Devops ja Backend sektsioonides ning suheldes mõne ettekandjaga. Tahan rääkida kajastatud teemadest ja teha ülevaate nende sektsioonide kohta konverentsil.

Devops ja Backend sektsioonides esinesid SKB-Kontur, DataArt, Evil Martians, Jekaterinburgi veebistuudio Flag, Miro (RealTimeBoard). Teemad käsitlesid CI/CD, töö queue teenustega, logimist ning Serverless ja PostgreSQL töötlust Go-s toodi hästi esile.

Teised ettekanded olid Avito, Tinkoff, Yandex, Jetstyle, Megafon ja Ak Bars pank, kuid neist ei õnnestunud füüsiliselt osa võtta (videomaterjalid ja ettekanded pole veel saadaval, lubatakse üles laadida kahe nädala jooksul dump-ekb.ru-le).

Devops sektsioon

Mis üllatas - sektsioon toimus kõige väiksemas saalis, umbes 50 kohta. Inimesed seisid isegi käikudes 🙂 Räägin ettekannetest, mida õnnestus kuulata.

Petabaidi Elastik

Sektsioon algas Vladimir Lila (SKB-Kontur) ettekandega Elasticsearchist Konturis. Nendel on piisavalt suur ja koormatud Elastik (~800 TB andmeid, ~1.3 petabaiti koos üleujutusega). Elasticsearch on kõikide Konturi teenuste jaoks üks, koosneb kahest klastrist (7 ja 9 serverit) ja on nii oluline, et Konturis on spetsiaalne Elasticsearch insener (tegelikult Vladimir ise).

Vladimir jagas ka mõtteid Elasticsearchi kasust ja probleemidest, mida see toob.

Kasu:

• Kõik logid ühes kohas, kerge neile ligi pääseda
• Logide säilitamine aasta jooksul ja nende lihtne analüüs
• Logidega töötamise kõrge kiirus
• Äge andmete visualiseerimine "karbist välja"

Probleemid:

• sõnumite vahendaja — peab olema (Konturis täidab selle rolli Kafka)
• Elasticsearch Curatoriga töötamise eripära (perioodiliselt tekib kõrge koormus regulaarsest Curatori ülesannetest)
• pole sisseehitatud autoriseerimist (ainult eraldi, üsna suurte summade eest, või avatud lähtekoodiga pluginad erineva valmisolekuga tootmisüksuse jaoks)

Open Distro for Elasticsearchi kohta on olnud ainult positiivseid arvamusi 🙂 Sama autoriseerimise küsimus on seal lahendatud.

Kust petabait?Nende nodid koosnevad serveritest, millel on 12*8 Tb SATA + 2*2 Tb SSD. Külm salvestus on SATA-l, SSD-d on ainult kuumal vahemälul.
7+9 serverit, (7 + 9) * 12 * 8 = 1536 Tb.
Osa ruumist on reserveeritud, et tagada üleliigsus jne.
Elasticsearchi saadetakse logisid ligikaudu 90 rakenduselt, sealhulgas kõik Kontu aruandeteenused, Elba ja teised.

Serverless arendamise eripära

Edasi tuleb Ruslan Serkini ettekande DataArt'ist Serverlessi kohta.

Ruslan rääkis, mis on Serverless lähenemine ja millised on selle eripärad.

Serverless on lähenemine arendusele, kus arendajad ei puutu infrastruktuuri üldse. Näide - AWS Lambda Serverless, Kubeless.io (Serverless Kubernetes'e sees), Google Cloud Functions.

Ideaalne Serverless rakendus on lihtsalt funktsioon, mis saadab päringu Serverless teenusepakkujale spetsiaalse API Gateway kaudu. Ideaalne mikroteenus, samal ajal toetab AWS Lambda suurt hulka kaasaegseid programmeerimiskeeli. Infrastruktuuri säilitamise ja juurutamise kulud muutuvad nulliks pilveteenuse pakkujate puhul, samuti on väikeste rakenduste tugi väga odav (AWS Lambda - 0.2$ / 1 miljon lihtsat päringut).

Sellise süsteemi skaleeritavus on praktiliselt ideaalne - pilveteenuse pakkuja hoolitseb selle eest ise, Kubeless skaleerub automaatselt Kubernetes'e klastris.

On puudusi:

• suurte rakenduste arendamine muutub keerulisemaks.
• rakenduste profiilimisega on keerukusi (teil on juurdepääs ainult logidele, kuid mitte profiilimisele tavapärases mõttes).
• versioonikontroll puudub.

Pean ausalt ütlema, et kuulsin Serverlessist juba paar aastat tagasi, kuid kõik need aastad ei saanud ma aru, kuidas seda õigesti rakendada. Pärast Ruslani ettekannet sain arusaamise ja pärast Nikolai Sverchkovi (Evil Martians) ettekannet Backendi sektsioonis kinnistus see. Pole olnud asjata konverentsil 🙂

CI vaestele, või kas tasub kirjutada oma CI veebistuudio jaoks?

Mikhail Radionov, veebistuudio Flag juht Jekaterinburgist, rääkis oma kirjutatud CI/CD-st.

Tema stuudio läbis tee 'manuaalsest CI/CD-st' (sisse logimine serverisse SSH kaudu, git pull, korrata 100 korda päevas) Jenkinsini ja isekirjutatud tööriistani Pullkins, mis võimaldab kontrollida koodi ja teha väljalaskeid.

Miks Jenkins ei sobinud? Ta ei pakkunud vaikimisi piisavat paindlikkust ja oli kohandamisel liiga keeruline.

„Lipp” arendab Laravelil (PHP raamistik). CI/CD serveri arendamisel kasutas Mihhail koos kolleegidega Laravel'i sisseehitatud mehhanisme, mida nimetatakse Telescope ja Envoy. Tulemuseks oli PHP server, mis töötleb sissetulevaid webhooki päringuid, suudab koostada frontend'i ja backend'i, teha erinevatele serveritele juurutusi ja raporteerida Slackis.

Edasi, et võimaldada blue/green juurutust, omada ühtseid seadistusi dev-stage-prod keskkondades, läksid nad Dockerile üle. Plussid jäid samaks, lisandusid keskkonna homogeniseerimise ja sujuva juurutamise võimalused, ning tekkis vajadus õppida Dockerit selle tõhusaks kasutamiseks.

Projekt on Githubis.

Kuidas me vähendasime serveri väljalaske tagasivõtmiste arvu 99%.

Viimane ettekande Devops sektsioonis oli Viktor Jeremchenkolt, Miro.com'i juhtiv devops insener (endine RealTimeBoard).

RealTimeBoardi, Miro meeskonna põhitoote, aluseks on monoliitne Java rakendus. Selle koostamine, testimine ja juurutamine ilma seisakuta on keeruline ülesanne. Oluline on juurutada selline koodiversioon, mida ei pea tagasiviima (sest see on raske monoliit).

Teel süsteemi väljatöötamise poole, mis võimaldab seda teha, läbis Miro teekonna, mis hõlmas tööd arhitektuuri, kasutatavate tööriistadega (Atlassian Bamboo, Ansible jne) ja meeskondade ülesehitamisega (neil on praegu eraldatud Devops meeskond ja palju eraldi Scrum meeskondi erinevate profiilide arendajatest).

Teekond osutus raskeks ja tormiliseks ning Viktor jagas akumuleerunud valu ja samas ka jätkuvat optimismi.

Võitsin raamatu küsimuste eest.

Backend sektsioon.

Sain osa kahest ettekandest — Nikolai Sverkshkovi (Evil Martians) ettekandest Serverless teemal ja Grigori Kosheleva ettekandest (Kontur) telemeetriast.

Serverless lihtsatele surelikele.

Kui Ruslan Sirkin rääkis Serverless'ist kui sellisest, siis Nikolai näitas lihtsaid rakendusi Serverless'i kasutamisega ja rääkis detailidest, mis mõjutavad rakenduste maksumust ja kiirusest AWS Lambdas.

Huvitav detail: minimaalne tasustatud elemendi suurus on 128 MB mälu ja 100 ms CPU, millega on kaasas hind 0,000000208$. Samuti on 1 miljon sarnast päringut kuus tasuta.

Mõned Nikolai funktsioonid ületasid sageli 100 ms piiri (peamine rakendus oli kirjutatud Ruby keeles), seega selle ümberkirjutamine Go-s tõi kaasa suure kulu kokkuhoiu.

Vostok Hercules — teeme telemeetriat taas suurepäraseks!

Viimane ettekande Backend sektsioonist Grigori Kosholevi (ettevõtte Kontur) poolt telemeetriast. Telemeetria — need on logid, mõõdikud, rakenduste jälgimisjada.

Kontur kasutab selleks isetehtud tööriistu, mis on saadaval Githubis. Ettekanne sisaldas tööriista — Hercules, github.com/vostok/hercules, mida kasutatakse telemeetriandmete edastamiseks.

Vladimir Lila ettekandes Devops sektsioonis käsitleti logide salvestamist ja töötlemist Elasticsearchis, kuid on veel ülesanne toimetada logid paljude tuhandete seadmete ja rakenduste kaudu, millega tegelevad tööriistad nagu Vostok Hercules.

Kontur on läbinud paljudele tuntud tee — RabbitMQ-st Apache Kafka-le, kuid asi ei ole nii lihtne )) Neile tuli lisada skeemi Zookeeper, Cassandra ja Graphite. Ma ei saa täpset teavet selle ettekande kohta jagada (see ei ole minu ala), kuid kui huvitab — võib oodata slaide ja videot konverentsi veebilehelt.

Kuidas võrreldes teiste konverentsidega?

Ma ei saa Moskva ja SPb konverentse võrrelda, kuid võin võrrelda Uurali teiste üritustega ja 404festiga Samaras.

DUMP toimub 8 sektsioonis, see on rekord Uurali konverentside jaoks. Väga suured sektsioonid on Science ja Juhtimine, see on samuti ebatavaline. Publik Jekaterinburgis on piisavalt struktureeritud — linnas on suured arendusosakonnad nagu Yandex, Kontur, Tinkoff, see mõjutab ka ettekandeid.

Veel üks huvitav punkt — paljudes ettevõtetes on konverentsil kohe 3–4 ettekandjat (nagu oli Konturi, Evil Martians, Tinkoff puhul). Paljud neist olid sponsorid, kuid ettekanded olid tõeliselt tasemel võrreldes teistega, need ei olnud reklaamiettekanded.

Kas minna või mitte minna? Kui elate Uuralis või läheduses, on teil võimalus ja teemad huvitavad — jah, muidugi. Kui kaalute kaugemat reisi — vaataksin ettepanekute teemasid ja varasemate aastate videot. www.youtube.com/user/videoitpeople/videos ja teeksin otsuse.
Veel üks pluss konverentside korraldamisel regioonides on tavaliselt kergem suhelda esinejaga pärast ettekandeid, kuna sellise suhtlemise kandidaate on vähem.

Aitäh DAMP-ile ja Jekaterinburgile! )

Allikas: habr.com