Praėjusią savaitę lankiausi DUMP IT konferencijoje (https://dump-ekb.ru/) Jekaterinburge ir noriu papasakoti, kas buvo aptarta Backend ir Devops skyriuose ir ar verta dėmesio regioninėms IT konferencijoms.
Nikolajus Sverčkovas iš „Piktieji marsiečiai apie be serverių“.
Kas ten vis dėlto buvo?
Iš viso konferencijoje buvo 8 sekcijos: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Didžiausios salės, beje, yra prie Mokslo ir vadybos)) Po ~350 žmonių. Backend ir Frontend nėra daug mažesni. Devops kambarys buvo mažiausias, bet aktyvus.
Klausiausi pranešimų Devops ir Backend skyriuose ir šiek tiek kalbėjausi su pranešėjais. Konferencijoje norėčiau pakalbėti nagrinėjamomis temomis ir apžvelgti šias sekcijas.
Devops ir Backend skyriuose kalbėjo SKB-Kontur, DataArt, Evil Martians, Jekaterinburgo interneto studijos Flag, Miro (RealTimeBoard) atstovai. Temos, susijusios su CI / CD, darbas su eilių paslaugomis, temos be serverių ir darbas su „PostgreSQL“ programoje „Go“ buvo gerai aptartos.
Taip pat buvo „Avito“, „Tinkoff“, „Yandex“, „Jetstyle“, „Megafon“, „Ak Bars Bank“ pranešimų, bet aš nespėjau fiziškai juose dalyvauti (vaizdo įrašų ir ataskaitų skaidrių kol kas nėra, žada paskelbti per 2 savaites svetainėje dump-ekb.ru).
Devops skyrius
Stebino tai, kad sekcija vyko mažiausioje, apie 50 vietų, salėje. Žmonės net praėjimuose stovėjo :) Papasakosiu apie reportažus, kurių pavyko išklausyti.
Petabaitą sveriantis elastingas
Skyrius prasidėjo Vladimiro Lilo (SKB-Kontur) pranešimu apie Elasticsearch in Kontur. Jie turi gana didelį ir apkrautą Elastic (~800 TB duomenų, ~1.3 petabaitų, atsižvelgiant į dubliavimą). „Elasticsearch“ visoms „Kontur“ paslaugoms yra viena, susideda iš 2 klasterių (iš 7 ir 9 serverių) ir yra tokia svarbi, kad „Kontur“ turi specialų „Elasticsearch“ inžinierių (tiesą sakant, patį Vladimirą).
Vladimiras taip pat pasidalijo mintimis apie Elasticsearch naudą ir jo keliamas problemas.
Privalumai:
- Visi rąstai vienoje vietoje, prie jų lengva prieiti
- Saugoti rąstus metus ir lengvai juos analizuoti
- Didelis darbo su rąstais greitis
- Šauni duomenų vizualizacija iš dėžutės
Problemos:
- žinučių tarpininkas yra privalomas (Konturui jo vaidmenį atlieka Kafka)
- darbo su Elasticsearch Curator ypatybės (periodiškai sukuriama didelė apkrova iš įprastų užduočių kuratoriuje)
- nėra integruoto leidimo (tik už atskirus, gana didelius pinigus arba kaip įvairaus pasirengimo gamybai atvirojo kodo įskiepiai)
Atsiliepimai apie Open Distro for Elasticsearch buvo tik teigiami :) Ten buvo išspręsta ta pati autorizacijos problema.
Iš kur atsiranda petabaitas?Jų mazgus sudaro serveriai su 12*8 Tb SATA + 2*2 Tb SSD. Šaltasis saugykla SATA, SSD tik karštai talpyklai (karšta saugykla).
7+9 serveriai, (7 + 9) * 12 * 8 = 1536 Tb.
Dalis erdvės rezervuota, skirta atleidimui ir pan.
Į Elasticsearch siunčiami maždaug 90 paraiškų žurnalai, įskaitant visas Kontur, Elba ir kt. ataskaitų teikimo paslaugas.
Be serverio kūrimo ypatybės
Kitas yra Ruslano Serkino iš DataArt pranešimas apie serverius.
Ruslanas kalbėjo apie tai, kas apskritai yra plėtra naudojant „Serverless“ metodą ir kokios yra jo savybės.
Be serverio yra požiūris į plėtrą, kai kūrėjai jokiu būdu neliečia infrastruktūros. Pavyzdys – AWS Lambda Serverless, Kubeless.io (be serverio Kubernetes viduje), Google Cloud Functions.
Ideali programa be serverio yra tiesiog funkcija, kuri siunčia užklausą be serverio teikėjui per specialų API šliuzą. Ideali mikro paslauga, o AWS Lambda taip pat palaiko daugybę šiuolaikinių programavimo kalbų. Debesijos paslaugų teikėjų infrastruktūros priežiūros ir diegimo išlaidos tampa nulinės, mažų programų palaikymas taip pat bus labai pigus (AWS Lambda – 0.2 USD / 1 mln. paprastų užklausų).
Tokios sistemos mastelio keitimas yra beveik idealus – debesų tiekėjas tuo pasirūpina pats, Kubeless automatiškai keičiasi Kubernetes klasteryje.
Yra trūkumų:
- kurti dideles programas darosi vis sunkiau
- yra sunkumų su profiliavimo programomis (turite prieigą tik prie žurnalų, bet ne profiliavimo įprasta prasme)
- jokios versijos
Tiesą sakant, apie Serverless girdėjau prieš keletą metų, tačiau visus šiuos metus man nebuvo aišku, kaip jį teisingai naudoti. Po Ruslano pranešimo atsirado supratimas, o po Nikolajaus Sverčkovo (Piktų marsiečių) pranešimo iš Backend skyriaus jis buvo konsoliduotas. Ne veltui važiavau į konferenciją :)
CI skirta vargšams, ar verta rašyti savo CI interneto studijai?
Michailas Radionovas, „Flag“ žiniatinklio studijos vadovas iš Jekaterinburgo, kalbėjo apie paties parašytą CI/CD.
Jo studija perėjo nuo „rankinio CI / CD“ (prisijunkite prie serverio per SSH, atlikite „git pull“, kartokite 100 kartų per dieną) iki „Jenkins“ ir prie paties sukurto įrankio, leidžiančio stebėti kodą ir atlikti leidimus, vadinamus Pullkins. .
Kodėl Jenkinsas neveikė? Pagal numatytuosius nustatymus jis nesuteikė pakankamai lankstumo ir buvo per sunku pritaikyti.
„Vėliava“ sukurta Laravel (PHP sistema). Kurdami CI / CD serverį, Michailas ir jo kolegos naudojo Laravel integruotus mechanizmus, vadinamus Telescope ir Envoy. Rezultatas yra PHP serveris (atkreipkite dėmesį), kuris apdoroja gaunamas „webhook“ užklausas, gali sukurti sąsają ir užpakalinę sistemą, diegti skirtinguose serveriuose ir pranešti „Slack“.
Tada, kad būtų galima atlikti mėlyną / žalią diegimą ir turėti vienodus nustatymus dev-stage-prod aplinkoje, jie perėjo į Docker. Privalumai išliko tie patys, buvo pridėtos aplinkos homogenizavimo ir sklandaus diegimo galimybės bei poreikis išmokti „Docker“ teisingai su juo dirbti.
Kaip sumažinome serverio leidimų atšaukimų skaičių 99 %
Paskutinis pranešimas Devops skiltyje buvo Viktoro Eremčenkos, Miro.com (anksčiau RealTimeBoard) vadovo devops inžinieriaus.
„RealTimeBoard“, pagrindinis Miro komandos produktas, yra pagrįstas monolitine „Java“ programa. Surinkti, išbandyti ir įdiegti be prastovų yra sudėtinga užduotis. Tokiu atveju svarbu įdiegti tokią kodo versiją, kad jos nereikėtų atsukti atgal (tai sunkus monolitas).
Kurdamas sistemą, leidžiančią tai padaryti, Miro perėjo kelią, apimantį darbą su architektūra, naudojamais įrankiais (Atlassian Bamboo, Ansible ir kt.) ir kūrė komandų struktūrą (dabar jos turi skirta Devops komanda + daug atskirų Scrum komandų iš skirtingų profilių kūrėjų).
Kelias pasirodė sunkus ir spygliuotas, o Viktoras dalijosi sukauptu skausmu ir optimizmu, kuris tuo nesibaigė.
Laimėjo knygą už klausimus
Backend skyrius
Man pavyko dalyvauti 2 reportažuose - iš Nikolajaus Sverčkovo (Piktieji marsiečiai), taip pat apie be serverių, ir iš Grigorijaus Košelevo (kompanija „Kontur“) apie telemetriją.
Paprastiems mirtingiesiems be serverio
Jei Ruslanas Sirkinas kalbėjo apie tai, kas yra „Serverless“, Nikolajus parodė paprastas programas naudojant „Serverless“ ir kalbėjo apie detales, turinčias įtakos AWS Lambda programų kainai ir greičiui.
Įdomi detalė: minimalus mokamas elementas yra 128 Mb atminties ir 100 ms CPU, kainuoja 0,000000208 USD. Be to, 1 milijonas tokių užklausų per mėnesį yra nemokamos.
Kai kurios Nikolajaus funkcijos dažnai viršydavo 100 ms ribą (pagrindinė programa buvo parašyta Ruby), todėl perrašant jas į Go buvo sutaupyta puikiai.
Vostok Hercules – paverskite telemetriją vėl puikia!
Naujausia „Backend“ sekcijos ataskaita iš Grigorijaus Košelevo („Kontur“ įmonė) apie telemetriją. Telemetrija reiškia žurnalus, metriką, taikomųjų programų pėdsakus.
Šiuo tikslu „Contour“ naudoja savarankiškai parašytus įrankius, paskelbtus „Github“. Įrankis iš pranešimo – Hercules, , naudojamas telemetrijos duomenims pateikti.
Vladimiro Lilos ataskaitoje Devops skiltyje buvo aptartas žurnalų saugojimas ir apdorojimas Elasticsearch, tačiau vis dar yra užduotis pateikti žurnalus iš daugelio tūkstančių įrenginių ir programų, o įrankiai, tokie kaip Vostok Hercules, juos išsprendžia.
Trasa ėjo daugeliui žinomu keliu - nuo RabbitMQ iki Apache Kafka, bet ne viskas taip paprasta)) Jie turėjo įtraukti į grandinę Zookeeper, Cassandra ir Graphite. Visiškai neatskleisiu informacijos apie šį pranešimą (ne mano profilį), jei susidomėjote, galite palaukti skaidrių ir vaizdo įrašų konferencijos svetainėje.
Kuo jis lyginamas su kitomis konferencijomis?
Negaliu lyginti su konferencijomis Maskvoje ir Sankt Peterburge, galiu palyginti su kitais renginiais Urale ir su 404fest Samaroje.
DAMP vyksta 8 sekcijose, tai yra Uralo konferencijų rekordas. Labai dideli mokslo ir vadybos skyriai, tai irgi neįprasta. Jekaterinburgo auditorija yra gana struktūrizuota - mieste yra dideli „Yandex“, „Kontur“, „Tinkoff“ plėtros skyriai, ir tai palieka pėdsaką ataskaitose.
Dar vienas įdomus momentas, kad daugelis kompanijų konferencijoje vienu metu turi 3-4 pranešėjus (taip buvo su Kontur, Evil Martians, Tinkoff). Daugelis jų buvo rėmėjai, bet ataskaitos visai prilygsta kitiems, tai nėra reklaminiai pranešimai.
Eiti ar neiti? Jei gyvenate Urale ar netoliese, turite galimybę ir domitės temomis – taip, žinoma. Jei galvojate apie tolimą kelionę, pasižiūrėčiau ankstesnių metų reportažų ir video reportažų temas ir priėmė sprendimą.
Kitas konferencijų regionuose privalumas, kaip taisyklė, yra tai, kad po pranešimų lengva bendrauti su pranešėju, norinčiųjų tokiai komunikacijai tiesiog mažiau.
Ačiū Dumpui ir Jekaterinburgui! )
Šaltinis: www.habr.com
