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 sesioonides ning kas piirkondlikud IT-konverentsid on tähelepanu väärt.

Nikolai Sverchkov Evil Martiansilt Serverlessist

Mis seal üldse toimus?

Kokku oli konverentsil 8 sessiooni: Backend, Frontend, Mobile, Testimine ja QA, Devops, Disain, Science ja Juhtimine.

Suurem osa saale oli Science ja Juhtimisele pühendatud, igaühes umbes 350 kohta. Backend ja Frontend ei olnud oluliselt väiksemad. Devopsi saal oli kõige väiksem, kuid aktiivne.

Kuulasin ettekandeid Devopsi ja Backend sessioonides ning sujusin natuke ka ettekandjatega. Tahaksin rääkida käsitletud teemadest ja teha ülevaate konverentsi sessioonidest.

Devopsi ja Backend sessioonides esinesid SKB Kontur, DataArt, Evil Martians, Jekaterinburgi veebistuudio Flag, Miro (RealTimeBoard). Teemad puudutasid CI/CD, järjekorrateenuste kasutamist, logimist, Serverlessi teemasid ja PostgreSQL kasutamist Go-s.

Seal olid ettekanded ka Avitolt, Tinkoffilt, Yandexilt, Jetstyle'ilt, Megafonilt, Ak Bars pangalt, kuid ma ei jõudnud neid füüsiliselt kuulata (videod ja slaidid veel ei ole saadaval, lubatakse postitada 2 nädala jooksul dump-ekb.ru-le).

Devops sessioon

Mis üllatuslik — sessioon toimus kõige väiksemas saalis, umbes 50 kohta. Inimesed seisid isegi vahekäikudes. 🙂 Räägin ettekannetest, mida jõudsin kuulata.

Petabaidise Elastici

Sessioon algas Vladimir Lila (SKB Kontur) ettekandest Elasticsearchist Konturis. Neil on piisavalt suur ja koormatud Elastic (~800 TB andmeid, ~1.3 petabaiti arvestades üleliigset). Elasticsearch on Konturi kõigi teenuste jaoks ühtne, koosneb kahest klastrist (7 ja 9 serverit), ja on nii oluline, et Konturis on spetsiaalne Elasticsearchi insener (nimelt Vladimir ise).

Vladimir jagas ka mõtteid Elasticsearchi kasu ja probleemide kohta, mida see põhjustab.

Kasu:

• Kõik logid ühes kohas, lihtne ligipääs neile
• Logide säilitamine aasta jooksul ja nende lihtne analüüs
• Logidega töötamise kõrge kiirus
• Tohutu andmete visualiseerimine 'kastist välja'

Probleemid:

• sõnumite vahendaja — kohustuslik (Konturis täidab selle rolli Kafka)
• Elasticsearchi Curatori kasutamise eripärad (korrapärasest ülesandest tekib aeg-ajalt suur koormus)
• pole sisseehitatud autoriseerimist (ainult eraldi, üsna suurt raha, eest, või avatud lähtekoodiga pistikprogrammide kaudu erineva valmidusastmega tootmisversioonide jaoks)

Open Distro for Elasticsearchi kohta olid ainult positiivsed arvamused. 🙂 Seal on probleem autoriseerimise lahendatud.

Kust petabait?Nende sõlmed koosnevad 12 * 8 TB SATA + 2 * 2 TB SSD serveritest. Külm salvestus SATA-l, SSD ainult kuuma vahekrüpteerimise jaoks (hot storage).
7 + 9 serverit, (7 + 9) * 12 * 8 = 1536 TB.
Osa ruumi on reservis, asetatud üleliikusele jne.
Elasticsearchisse saadetakse logisid umbes 90 rakendusest, sealhulgas kõik Konturi aruandeteenused, Elba jne.

Serverless arendamise eripärad

Järgmine ettekande tegi Ruslan Serkin DataArtist Serverlessi teemal.

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

Serverless on lähenemine arendamisele, kus arendajad ei puutu mingil moel kokku infrastruktuuriga. Näide — AWS Lambda Serverless, Kubeless.io (Serverless Kubernetes'i sees), Google Cloud Functions.

Ideaalne Serverless rakendus on lihtsalt funktsioon, mis saadab päringu Serverless teenusepakkujale spetsiaalse API Gateway kaudu. Ideaalne mikroteenus, samas toetab AWS Lambda suurt arvu kaasaegseid programmeerimiskeeli. Infrastruktuuri toetamise ja juurutamise kulu on pilveteenuse pakkujate puhul null, väikeste rakenduste tugi on samuti väga odav (AWS Lambda — 0.2 $ / 1 miljon lihtsat päringut).

Selle süsteemi skaleeritavus on praktiliselt ideaalne — pilveteenuse pakkuja hoolitseb selle eest ise, Kubeless skaleerub automaatselt Kubernetes klastris.

On puudusi:

• suurte rakenduste loomine muutub keeruliseks
• rakenduste profiilimisega on keerukusi (teil on ligipääs ainult logidele, aga mitte profiilimistehnoloogia mõistes)
• versioonituse puudumine

Pean ütlema, et kuulsin Serverlessist juba mitu aastat tagasi, kuid kõik need aastad ei saanud üldse aru, kuidas seda õigesti rakendada. Pärast Ruslani ettekannet sai aru, ja pärast Nikolai Sverchkovi (Evil Martians) ettekannet Backend sessioonist sai see kinnitust. Ei olnud asjata konverentsile minek. 🙂

CI vaestele, või kas on mõtet kirjutada oma CI veebistuudiole

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

Tema stuudio on läbinud tee 'käed CI/CD' (sisenes serverisse SSH kaudu, tegi git pull, korda 100 päeva jooksul) Jenkinseni ja isikliku tööriistani, mis võimaldab kontrollida koodi ja teha väljalasked, mille nimi on Pullkins.

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

“Flag” arendab Laravelil (PHP raamistik). CI/CD serveri arendamise käigus kasutas Mihhail kolleegidega Laravel'i sisseehitatud mehhanisme nimega Telescope ja Envoy. Tulemuseks oli PHP server (pange tähele), mis töötleb sisendeid webhook päringutelt, suudab koostada frontend'i ja backend'i, teha erinevatele serveritele deployd ja raporteerida Slackis.

Edasi liikumiseks, et võimaldada blue/green deploy'd ning omada ühtseid seadeid dev-stage-prod keskkondades, läksid nad Dockerile üle. Plussid jäid samaks, lisandusid keskkonna homogeenimise ja sujuva deploy võimalused ning tekkis vajadus Dockerit õppida, et sellega õigesti töötada.

Projekt on saadaval Githubis

Kuidas me vähendasime serveri väljaannete tagasimaksete arvu 99% võrra

Viimane ettekande Devops sektsioonis oli Viktor Jeremčenkolt, juhtiv DevOps insener Miro.com'is (endine RealTimeBoard).

RealTimeBoard, Miro meeskonna peamine toode, põhineb monoliitsel rakendusel, mis on kirjutatud Java's. Selle kogumine, testimine ja deploy ilma seisakuteta on keeruline ülesanne. Oluline on teha selline koodiversion maintenance, et tagasiviimist ei oleks vaja (tülikas monoliit).

Teel süsteemi ülesehitamise suunas, mis võimaldab seda teha, läbisid Miro teekonna, mis hõlmas arhitektuuri, kasutatavaid tööriistu (Atlassian Bamboo, Ansible jne) ja meeskondade ülesehitust (nendel on hetkel eraldi DevOps meeskond + palju eraldi Scrum meeskondi erinevate arendajate profiilidega).

Teekond osutus raskeks ja tormiliseks ning Viktor jagas tekkinud muret ja jätkuvat optimistlikku suhtumist.

Võitis raamatu küsimuste eest

Backend sektsioon

Jõudsin kahe ettekande juurde — Nikolai Svertsškovi (Evil Martians) pajatus Serverless'i teemal ja Grigori Košelevi (Kontur) ettekande telemeetriast.

Serverless tavalistele surmatuetele

Kui Ruslan Sirkin rääkis Serverless'i olemusest, siis Nikolai näitas lihtsalt rakendusi Serverless'i kasutades ning selgitas detaile, mis mõjutavad rakenduste kulusid ja töökiirus AWS Lambda's.

Huvipakkuv detail: minimaalne tasustatav element — 128 Mb mälu ja 100 ms CPU, maksab 0,000000208$. Samas on 1 miljon sarnast päringut kuus tasuta.

Mõned funktsioonid ületasid Nikolail sageli 100 ms limiiti (põhirakendus oli kirjutatud Ruby's), seega nende ümberkirjutamine Go'sse tõi suurepärase kokkuhoiu.

Vostok Hercules — teeme telemeetriat taas suureks!

Viimane ettekande Backend sektsioonis Grigori Košelevi (Kontur) kohta telemeetriast. Telemeetria on logid, mõõdikud, rakenduste jälgimine.

Kontur kasutab selleks ise kirjutatud tööriistu, mis on saadaval Githubis. Ettekanne sisaldas tööriista nimega Hercules, github.com/vostok/hercules, mida kasutatakse telemeetriadatavade edastamiseks.

Vladimir Lilja ettekandes Devops sektsioonis käsitleti logide säilitamist ja töötlemist Elasticsearch'is, kuid on ka ülesanne edastada logisid paljude tuhandete seadmete ja rakenduste vahel ning seda lahendatakse tööriistadega nagu Vostok Hercules.

Kontur läbis paljudele tuntud teekonna — alates RabbitMQ-st Apache Kafka'sse, kuid asjad ei ole nii lihtsad)). Nende tuli lisada skeemile Zookeeper, Cassandra ja Graphite. Teavet selle ettekande kohta ma täielikult ei avalda (see ei ole minu profiil), kui on huvi — saate oodata slaide ja videot konverentsi veebilehelt.

Kuidas võrreldes teiste konverentsidega?

Ma ei oska võrrelda Moskva ja SPb konverentse, aga võin võrrelda Uuralite ja Samara 404festiga.

DAMP toimub 8 sektsioonis, mis on rekord Uuralite konverentside jaoks. Science ja Management sektsioonid on väga suured, mis on samuti ebatavaline. Auditoorium Jekaterinburgis on piisavalt struktureeritud — linnas on suured arendusosakonnad Yandexis, Konturis, Tinkoffis, mis mõjutab ka ettekandeid.

Veel üks huvitav punkt — paljudel ettevõtetel on konverentsil kohe 3–4 ettekandjat (nii oli Konturi, Evil Martiansi, Tinkoffi puhul). Paljud neist olid sponsorid, kuid ettekanded olid kindlasti samal tasemel teistega, need ei olnud reklaamettekanded.

Kas minna või mitte? Kui elate Uuralites või läheduses, teil on võimalus ja teemad on huvitavad — jah, muidugi. Kui mõtlete kaugemale reisile — vaataksin ettekanne teemasid ja varasemate aastate videod, www.youtube.com/user/videoitpeople/videos ja teeksin otsuse.
Veel üks pluss piirkondlikest konverentsidest on see, et pärast ettekandeid on lihtne esinejaga suhelda, kuna selliseid kontakte on lihtsalt vähem.

Aitäh DAMP-ile ja Jekaterinburgile! )

Allikas: habr.com