Prošle nedelje sam bio na DUMP IT konferenciji (https://dump-ekb.ru/) u Jekaterinburgu i želim da vam kažem o čemu se govorilo u odeljcima Backend i Devops i da li su regionalne IT konferencije vredne pažnje.
Nikolay Sverchkov iz Evil Martians o Serverless
Šta je tu uopšte bilo?
Konferencija je imala ukupno 8 sekcija: Backend, Frontend, Mobile, Testing i QA, Devops, Dizajn, Nauka i Menadžment.
Najveće sale su, inače, u Nauci i Menadžmentu)) Po ~350 ljudi svaka. Backend i Frontend nisu mnogo manji. Devops soba je bila najmanja, ali aktivna.
Slušao sam izvještaje u sekcijama Devops i Backend i malo razgovarao sa govornicima. Želio bih govoriti o temama koje su obrađene i pregledati ove dijelove na konferenciji.
U sekcijama Devops i Backend govorili su predstavnici SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard). Teme koje su pokrivale CI/CD, rad sa servisima čekanja, evidentiranje; Teme bez servera i rad sa PostgreSQL-om u Go-u su bile dobro pokrivene.
Bilo je i izvještaja Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, ali nisam imao vremena da im fizički prisustvujem (video snimci i slajdovi izvještaja još nisu dostupni, obećavaju da će ih objaviti u roku od 2 sedmice na dump-ekb.ru).
Devops sekcija
Ono što je iznenadilo je da je sekcija održana u najmanjoj sali, oko 50 mjesta. Ljudi su čak stajali i u prolazima :) Reći ću vam o izvještajima koje sam uspio poslušati.
Elastična težina petabajta
Rubrika je započela izvještajem Vladimira Lila (SKB-Kontur) o Elasticsearch-u u Konturu. Imaju prilično veliki i opterećen Elastic (~800 TB podataka, ~1.3 petabajta uzimajući u obzir redundantnost). Elasticsearch za sve usluge Kontura je jedinstven, sastoji se od 2 klastera (od 7 i 9 servera) i toliko je važan da Kontur ima specijalnog Elasticsearch inženjera (u stvari, samog Vladimira).
Vladimir je također podijelio svoja razmišljanja o prednostima Elasticsearch-a i problemima koje donosi.
Prednosti:
- Svi dnevnici su na jednom mjestu, lak pristup do njih
- Pohranjivanje dnevnika godinu dana i laka analiza
- Velika brzina rada sa trupcima
- Cool vizualizacija podataka iz kutije
Problemi:
- broker poruka je must have (za Kontur njegovu ulogu igra Kafka)
- karakteristike rada sa Elasticsearch Curatorom (periodično kreirano veliko opterećenje od redovnih zadataka u Curatoru)
- bez ugrađene autorizacije (samo za odvojene, prilično velike novce, ili kao dodaci otvorenog koda različitog stepena spremnosti za proizvodnju)
O Open Distro za Elasticsearch su bile samo pozitivne kritike :) Isti problem autorizacije je riješen tamo.
Odakle dolazi petabajt?Njihovi čvorovi se sastoje od servera sa 12*8 Tb SATA + 2*2 Tb SSD. Hladna memorija na SATA, SSD samo za vruću keš memoriju (vruća pohrana).
7+9 servera, (7 + 9) * 12 * 8 = 1536 Tb.
Dio prostora je rezervisan, izdvojen za višak itd.
Elasticsearch-u se šalju zapisi iz oko 90 aplikacija, uključujući sve izvještajne servise Kontura, Elbe itd.
Karakteristike razvoja bez servera
Slijedi izvještaj Ruslana Serkina iz DataArt-a o Serverless-u.
Ruslan je govorio o tome šta je razvoj sa pristupom bez servera uopšte i koje su njegove karakteristike.
Serverless je pristup razvoju u kojem programeri ni na koji način ne diraju infrastrukturu. Primjer - AWS Lambda bez servera, Kubeless.io (bez servera unutar Kubernetesa), Google Cloud funkcije.
Idealna aplikacija bez servera je jednostavno funkcija koja šalje zahtjev provajderu bez servera kroz poseban API Gateway. Idealan mikroservis, dok AWS Lambda podržava i veliki broj modernih programskih jezika. Troškovi održavanja i implementacije infrastrukture postaju nula u slučaju provajdera u oblaku, podrška malih aplikacija će također biti vrlo jeftina (AWS Lambda - 0.2 USD / 1 milion jednostavnih zahtjeva).
Skalabilnost ovakvog sistema je gotovo idealna - provajder u oblaku se brine za to sam, Kubeless se automatski skalira unutar Kubernetes klastera.
Postoje nedostaci:
- razvoj velikih aplikacija postaje sve teži
- postoji poteškoća s profiliranjem aplikacija (imate pristup samo zapisnicima, ali ne i profiliranje u uobičajenom smislu)
- bez verzije
Da budem iskren, čuo sam za Serverless prije nekoliko godina, ali svih ovih godina mi nije bilo jasno kako ga pravilno koristiti. Nakon Ruslanovog izvještaja pojavilo se razumijevanje, a nakon izvještaja Nikolaja Sverčkova (Zli Marsovci) iz Backend sekcije, ono je konsolidirano. Nisam uzalud otišao na konferenciju :)
CI je za siromašne, ili se isplati napisati vlastiti CI za web studio?
Mikhail Radionov, šef web studija Flag iz Jekaterinburga, govorio je o samostalno pisanom CI/CD-u.
Njegov studio je prešao od “ručnog CI/CD-a” (prijavite se na server preko SSH-a, izvršite git pull, ponovite 100 puta dnevno) do Jenkinsa i do samopisnog alata koji vam omogućava da nadgledate kod i izvodite izdanja pod nazivom Pullkins .
Zašto Dženkins nije radio? Nije pružao dovoljno fleksibilnosti prema zadanim postavkama i bio je previše težak za prilagođavanje.
“Flag” se razvija u Laravel-u (PHP framework). Prilikom razvoja CI/CD servera, Mikhail i njegove kolege koristili su Laravelove ugrađene mehanizme pod nazivom Telescope and Envoy. Rezultat je server u PHP-u (imajte na umu) koji obrađuje dolazne webhook zahtjeve, može izgraditi frontend i backend, postaviti na različite servere i izvještavati Slack.
Zatim, da bi mogli da izvedu plavo/zelenu implementaciju i da imaju uniformna podešavanja u dev-stage-prod okruženjima, prešli su na Docker. Prednosti su ostale iste, dodane su mogućnosti homogenizacije okruženja i besprekorne implementacije, a dodata je i potreba da se nauči Docker za ispravan rad s njim.
Kako smo smanjili broj poništavanja izdanja servera za 99%
Poslednji izveštaj u odeljku Devops bio je od Viktora Eremčenka, vodećeg devops inženjera na Miro.com (ranije RealTimeBoard).
RealTimeBoard, vodeći proizvod Miro tima, baziran je na monolitnoj Java aplikaciji. Prikupljanje, testiranje i implementacija bez zastoja je težak zadatak. U ovom slučaju, važno je implementirati takvu verziju koda kako se ne bi morao vraćati (to je težak monolit).
Na putu do izgradnje sistema koji vam to omogućava, Miro je prošao put koji je uključivao rad na arhitekturi, korištenim alatima (Atlassian Bamboo, Ansible, itd.) i rad na strukturi timova (sada imaju namjenski Devops tim + mnogo zasebnih Scrum timova od programera različitih profila).
Ispostavilo se da je put težak i trnovit, a Viktor je podijelio nagomilani bol i optimizam koji tu nije završio.
Osvojio sam knjigu za postavljanje pitanja
Backend odjeljak
Uspeo sam da prisustvujem 2 izveštaja - od Nikolaja Sverčkova (Zli Marsovci), takođe o Serverless-u, i od Grigorija Košeljeva (kompanija Kontur) o telemetriji.
Bez servera za obične smrtnike
Ako je Ruslan Sirkin govorio o tome šta je Serverless, Nikolaj je pokazao jednostavne aplikacije koje koriste Serverless, i govorio o detaljima koji utiču na cenu i brzinu aplikacija u AWS Lambda.
Zanimljiv detalj: minimalno plaćeni element je 128 Mb memorije i 100 ms CPU, košta 0,000000208 dolara. Štaviše, milion takvih zahtjeva mjesečno je besplatno.
Neke od Nikolajevih funkcija često su prelazile granicu od 100 ms (glavna aplikacija je napisana u Ruby-u), pa je njihovo ponovno pisanje u Go-u pružilo odlične uštede.
Vostok Hercules — učinite telemetriju ponovo sjajnom!
Najnoviji izvještaj Backend sekcije Grigorija Košeleva (kompanija Kontur) o telemetriji. Telemetrija znači evidencije, metrike, tragove aplikacija.
U tu svrhu, Contour koristi samostalno pisane alate objavljene na Githubu. Alat iz izvještaja - Herkul, , koristi se za isporuku telemetrijskih podataka.
Izvještaj Vladimira Lile u odjeljku Devops raspravljao je o pohranjivanju i obradi dnevnika u Elasticsearch-u, ali još uvijek postoji zadatak isporučivanja dnevnika s mnogo hiljada uređaja i aplikacija, a alati poput Vostok Herculesa ih rješavaju.
Krug je pratio put poznat mnogima - od RabbitMQ do Apache Kafke, ali nije sve tako jednostavno)) Morali su dodati Zookeeper, Cassandru i Graphite u kolo. Neću u potpunosti otkrivati informacije o ovom izvještaju (nije moj profil), ako ste zainteresovani, sačekajte slajdove i video zapise na web stranici konferencije.
Kako se može usporediti s drugim konferencijama?
Ne mogu ga porediti sa konferencijama u Moskvi i Sankt Peterburgu, mogu ga porediti sa drugim događajima na Uralu i sa 404festom u Samari.
DAMP se održava u 8 sekcija, ovo je rekord za Uralske konferencije. Veoma velike sekcije nauke i menadžmenta, to je takođe neobično. Publika u Jekaterinburgu je prilično strukturirana - grad ima velike razvojne odjele za Yandex, Kontur, Tinkoff, i to ostavlja traga na izvještajima.
Još jedna interesantna stvar je da mnoge kompanije imaju 3-4 govornika na konferenciji odjednom (to je bio slučaj sa Konturom, Evil Martians, Tinkoff). Mnogi od njih su bili sponzori, ali izvještaji su sasvim jednaki ostalima, ovo nisu reklamni izvještaji.
Ići ili ne ići? Ako živite na Uralu ili u blizini, imate priliku i zainteresovani ste za teme - da, naravno. Ako razmišljate o dugom putovanju, osvrnuo bih se na teme reportaža i video reportaža iz prethodnih godina i doneo odluku.
Još jedna prednost konferencija u regijama, po pravilu, je to što je lako komunicirati sa govornikom nakon izvještaja, jednostavno je manje prijavljenih za takvu komunikaciju.
Hvala Dumpu i Ekaterinburgu! )
izvor: www.habr.com