Prošlog sam tjedna bio na DUMP IT konferenciji (https://dump-ekb.ru/) u Jekaterinburgu i želim vam reći o čemu se raspravljalo u odjeljcima Backend i Devops te jesu li regionalne IT konferencije vrijedne pažnje.
Nikolay Sverchkov iz Evil Marsovaca o Serverless
Što je uopće bilo tamo?
Sveukupno je konferencija imala 8 sekcija: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Usput, najveće dvorane su na Science and Management)) Za ~350 ljudi svaka. Backend i Frontend nisu mnogo manji. Devopsova soba bila je najmanja, ali aktivna.
Slušao sam izvještaje u sekcijama Devops i Backend te malo popričao sa govornicima. Želio bih govoriti o obrađenim temama 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). Obrađene teme CI/CD, rad s uslugama čekanja, bilježenje; teme bez poslužitelja i rad s PostgreSQL u Gou bile su dobro pokrivene.
Bilo je i izvješća Avita, Tinkoffa, Yandexa, Jetstylea, Megafona, Ak Bars banke, ali nisam imao vremena fizički im prisustvovati (video snimke i slajdovi izvješća još nisu dostupni, obećavaju da će ih objaviti u roku od 2 tjedna na dump-ekb.ru).
Devops odjeljak
Ono što je iznenadilo je da se dionica održavala u najmanjoj dvorani, oko 50 mjesta. Ljudi su čak stajali u prolazima :) Reći ću vam o izvještajima koje sam uspio poslušati.
Elastika težine petabajta
Rubrika je započela izvješćem Vladimira Lila (SKB-Kontur) o Elasticsearchu u Konturu. Imaju prilično velik i opterećen Elastic (~800 TB podataka, ~1.3 petabajta uzimajući u obzir redundanciju). Elasticsearch za sve Kontur servise je jedinstven, sastoji se od 2 klastera (od 7 i 9 servera), a toliko je važan da Kontur ima posebnog Elasticsearch inženjera (zapravo samog Vladimira).
Vladimir je također podijelio svoje mišljenje o prednostima Elasticsearcha i problemima koje donosi.
prednosti:
- Svi zapisnici su na jednom mjestu, lak pristup do njih
- Pohranjivanje zapisa na godinu dana i njihova jednostavna analiza
- Velika brzina rada s trupcima
- Cool vizualizacija podataka odmah po izlasku
Problemi:
- message broker je must have (za Kontur njegovu ulogu igra Kafka)
- značajke rada s Elasticsearch Curatorom (povremeno stvarano veliko opterećenje od redovnih zadataka u Curatoru)
- nema ugrađene autorizacije (samo za zasebne, prilično velike novce ili kao open source dodaci različitih stupnjeva spremnosti za proizvodnju)
Bilo je samo pozitivnih recenzija o Open Distrou za Elasticsearch :) Isti problem autorizacije je riješen tamo.
Odakle dolazi petabajt?Njihovi čvorovi sastoje se od poslužitelja s 12*8 Tb SATA + 2*2 Tb SSD. Hladna pohrana na SATA, SSD samo za vruću predmemoriju (vruća pohrana).
7+9 poslužitelja, (7 + 9) * 12 * 8 = 1536 Tb.
Dio prostora je u rezervi, odvojen za radni odnos i sl.
Na Elasticsearch se šalju zapisi iz oko 90 aplikacija, uključujući sve servise za izvješćivanje Kontura, Elbe itd.
Značajke razvoja bez poslužitelja
Slijedi izvješće Ruslana Serkina iz DataArta o Serverless.
Ruslan je pričao o tome što je uopće razvoj s Serverless pristupom i koje su njegove karakteristike.
Serverless je pristup razvoju u kojem programeri ni na koji način ne diraju infrastrukturu. Primjer - AWS Lambda Serverless, Kubeless.io (Serverless unutar Kubernetesa), Google Cloud Functions.
Idealna aplikacija bez poslužitelja jednostavno je funkcija koja šalje zahtjev pružatelju usluga bez poslužitelja putem posebnog API pristupnika. Idealan mikroservis, a AWS Lambda podržava i veliki broj modernih programskih jezika. Trošak održavanja i implementacije infrastrukture postaje nula u slučaju pružatelja usluga oblaka, podrška malim aplikacijama također će biti vrlo jeftina (AWS Lambda - 0.2 USD / 1 milijun jednostavnih zahtjeva).
Skalabilnost takvog sustava je gotovo idealna – cloud provider se sam brine o tome, Kubeless se automatski skalira unutar Kubernetes klastera.
Postoje nedostaci:
- razvoj velikih aplikacija postaje sve teži
- postoje poteškoće s aplikacijama za profiliranje (dostupni su vam samo zapisnici, ali ne i profiliranje u uobičajenom smislu)
- nema verzije
Da budem iskren, čuo sam za Serverless prije nekoliko godina, ali sve ove godine nije mi bilo jasno kako ga ispravno koristiti. Nakon Ruslanove prijave pojavilo se razumijevanje, a nakon prijave Nikolaja Sverčkova (Zli Marsovci) iz rubrike Backend se konsolidiralo. Nisam uzalud otišao na konferenciju :)
CI je za siromašne ili se isplati napisati vlastiti CI za web studio?
Mikhail Radionov, voditelj web studija Flag iz Yekaterinburga, govorio je o CI/CD-u koji sam napisao.
Njegov studio je prešao put od "ručnog CI/CD-a" (prijavite se na poslužitelj putem SSH-a, napravite git pull, ponovite 100 puta dnevno) do Jenkinsa i do alata koji je sam napisao koji vam omogućuje praćenje koda i izvođenje izdanja zvanog Pullkins .
Zašto Jenkins nije radio? Prema zadanim postavkama nije pružao dovoljno fleksibilnosti i bilo ga je preteško prilagoditi.
“Zastava” se razvija u Laravelu (PHP okvir). Prilikom razvoja CI/CD poslužitelja, Mikhail i njegovi kolege koristili su Laravelove ugrađene mehanizme pod nazivom Telescope i Envoy. Rezultat je poslužitelj u PHP-u (imajte na umu) koji obrađuje dolazne webhook zahtjeve, može izgraditi sučelje i pozadinu, implementirati na različite poslužitelje i izvještavati Slack.
Zatim su se prebacili na Docker kako bi mogli izvršiti plavo/zelenu implementaciju i imati jedinstvene postavke u dev-stage-prod okruženjima. Prednosti su ostale iste, dodane su mogućnosti homogeniziranja okruženja i besprijekorne implementacije, a dodana je i potreba da se Docker nauči pravilno raditi s njim.
Kako smo smanjili broj vraćanja izdanja poslužitelja za 99%
Posljednje izvješće u odjeljku Devops bilo je od Viktora Eremchenka, vodećeg devops inženjera na Miro.com (bivši RealTimeBoard).
RealTimeBoard, vodeći proizvod tima Miro, temelji se na monolitnoj Java aplikaciji. Prikupiti, testirati i implementirati ga bez zastoja je težak zadatak. U ovom slučaju, važno je implementirati takvu verziju koda tako da se ne mora vraćati (to je težak monolit).
Na putu do izgradnje sustava koji vam to omogućuje, 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 programera različitih profila).
Put se pokazao teškim i trnovitim, a Victor je dijelio nagomilanu bol i optimizam kojem tu nije bio kraj.
Osvojio knjigu za postavljanje pitanja
Pozadinski odjeljak
Uspio sam prisustvovati 2 izvještaja - od Nikolaya Sverchkova (Evil Martians), također o Serverless, i od Grigorija Kosheleva (Kontur company) o telemetriji.
Bez poslužitelja za obične smrtnike
Ako je Ruslan Sirkin govorio o tome što je Serverless, Nikolay je pokazao jednostavne aplikacije koje koriste Serverless, te govorio o detaljima koji utječu na cijenu i brzinu aplikacija u AWS Lambda.
Zanimljiv detalj: minimalno plaćeni element je 128 Mb memorije i 100 ms CPU-a, košta 0,000000208 dolara. Štoviše, milijun takvih zahtjeva mjesečno je besplatan.
Neke od Nikolajevih funkcija često su prelazile ograničenje od 100 ms (glavna aplikacija bila je napisana u Rubyju), pa je njihovo prepisivanje u Go omogućilo izvrsnu uštedu.
Vostok Hercules — učinite telemetriju ponovno sjajnom!
Najnovije izvješće odjeljka Backend od Grigorija Kosheleva (tvrtka Kontur) o telemetriji. Telemetrija znači zapise, metriku, tragove aplikacija.
U tu svrhu Contour koristi samostalno napisane alate objavljene na Githubu. Alat iz izvješća - Hercules, , koristi se za isporuku telemetrijskih podataka.
Izvješće Vladimira Lile u odjeljku Devops raspravljalo je o pohranjivanju i obradi zapisa u Elasticsearchu, ali još uvijek postoji zadatak isporuke zapisa s mnogo tisuća uređaja i aplikacija, a alati poput Vostok Herculesa to rješavaju.
Krug je išao putem koji je poznat mnogima - od RabbitMQ do Apache Kafke, ali nije sve tako jednostavno)) Morali su dodati Zookeeper, Cassandra i Graphite u krug. Neću u potpunosti otkriti informacije o ovom izvješću (ne moj profil), ako ste zainteresirani, možete pričekati slajdove i video na web stranici konferencije.
Kakva je u usporedbi s drugim konferencijama?
Ne mogu to usporediti s konferencijama u Moskvi i St. Petersburgu, mogu to usporediti s drugim događanjima na Uralu i s 404festom u Samari.
DAMP se održava u 8 sekcija, što je rekord za Uralske konferencije. Vrlo veliki odjeljci za znanost i upravljanje, to je također neobično. Publika u Jekaterinburgu prilično je strukturirana - grad ima velike razvojne odjele za Yandex, Kontur, Tinkoff, a to ostavlja traga na izvješćima.
Još jedna zanimljivost je da mnoge tvrtke imaju 3-4 govornika na konferenciji odjednom (to je bio slučaj s Konturom, Evil Martians, Tinkoff). Mnogi od njih bili su sponzori, ali izvješća su sasvim jednaka drugima, to nisu reklamna izvješća.
Ići ili ne ići? Ako živite na Uralu ili u blizini, imate priliku i zanimaju vas teme - da, naravno. Ako razmišljate o dugom putovanju, pogledao bih teme reportaža i video reportaža iz prethodnih godina i donio odluku.
Još jedna prednost konferencija u regijama, u pravilu, je da je lako komunicirati s govornikom nakon izvješća; jednostavno je manje podnositelja zahtjeva za takvu komunikaciju.
Hvala Dumpu i Ekaterinburgu! )
Izvor: www.habr.com