Prejšnji teden sem se udeležil IT konference DUMP (https://dump-ekb.ru/) v Jekaterinburgu in želim spregovoriti o tem, o čem se je govorilo v sekcijah Backend in Devops, in ali so regionalne IT konference res vredne obiska.
Nikolaj Sverčkov iz Evil Martians o Serverless
Kaj se je sploh dogajalo?
Na konferenci je bilo skupaj 8 sekcij: Backend, Frontend, Mobile, Testiranje in QA, Devops, Design, Science in Management.
Največje dvorane sta bili Science in Management, vsaka za ~350 ljudi. Backend in Frontend sta bili nekoliko manjši. Dvorana Devops je bila najmanjša, a zelo aktivna.
Poslušal sem predavanja v sekcijah Devops in Backend ter se malo pogovarjal z govorniki. Želim spregovoriti o obravnavanih temah in narediti pregled teh sekcij na konferenci.
V sekcijah Devops in Backend so nastopili predstavniki SKB-Kontur, DataArt, Evil Martians, jekaterinburške spletne agencije Flag, Miro (RealTimeBoard). Teme so obravnavale CI/CD, delo s storitvami čakalnih vrst, beleženje, močno so bile obravnavane teme Serverless in delo s PostgreSQL v Go.
Obstajala so tudi predavanja Avita, Tinkoffa, Yandexa, Jetstyle, MegaFona in banke Ak Bars, vendar jih fizično nisem mogel obiskati (video posnetki in slajdi predavanj še niso na voljo, obljubljajo, da jih bodo objavili v naslednjih 2 tednih na dump-ekb.ru).
Sekcija Devops
Kar je presenetilo, je to, da je sekcija potekala v najmanjši dvorani, ki ima okoli 50 mest. Ljudje so stali tudi v prehodih 🙂 Spregovoril bom o predavanjih, ki sem jih uspel poslušati.
Elastična pesa petabajt
Sekcija se je začela s predavanjem Vladimirja Lile (SKB-Kontur) o Elasticsearchu v Konturu. Imajo dovolj velik in obremenjen Elastic (~800 TB podatkov, ~1.3 petabajta ob upoštevanju redundance). Elasticsearch za vse storitve Kontura je enoten, sestoji iz 2 klasterjev (s 7 in 9 strežniki), in je tako pomemben, da ima Kontur posebnega inženirja za Elasticsearch (v bistvu, sam Vladimir).
Vladimir je prav tako delil misli o koristih Elasticsearcha in težavah, ki jih prinaša.
Koristi:
- Vsi logi na enem mestu, enostaven dostop do njih
- Shranjevanje logov za eno leto in njihova enostavna analiza
- Visoka hitrost dela z logi
- Odlična vizualizacija podatkov “iz škatle”
Težave:
- posrednik sporočil — nuja (v Konturu to vlogo opravlja Kafka)
- posebnosti dela z Elasticsearch Curator (občasno visoka obremenitev od rednih nalog v Curatorju)
- ni vgrajene avtentikacije (samo za ločeno, dokaj veliko plačilo, ali kot odprtokodni vtičniki različne stopnje pripravljenosti za produkcijo)
Mnenja o Open Distro for Elasticsearch so bila le pozitivna 🙂 Tudi vprašanje avtentikacije je tam rešeno.
Od kje petabajt?Njihove vozlišča so sestavljena iz strežnikov s 12*8 Tb SATA + 2*2 Tb SSD. Hladno shranjevanje na SATA, SSD le za vročo predpomnilnik (hot storage).
7+9 strežnikov, (7 + 9) * 12 * 8 = 1536 Tb.
Del prostora je v rezervi, načrtovan je presežek in podobno.
V Elasticsearch se pošiljajo dnevniki približno 90 aplikacij, vključno z vsemi storitvami poročanja Kontra, Elba in drugimi.
Značilnosti razvoja na Serverless
Nato bo predavanje Ruslana Serkina iz DataArt o Serverless.
Ruslan je povedal, kaj pravzaprav pomeni razvoj s pristopom Serverless in kakšne so njegove značilnosti.
Serverless je pristop k razvoju, pri katerem razvijalci ne prizadenejo infrastrukture na noben način. Primeri: AWS Lambda Serverless, Kubeless.io (Serverless znotraj Kubernetes), Google Cloud Functions.
Idealna Serverless aplikacija je preprosto funkcija, ki pošlje zahtevo Serverless ponudniku preko posebnega API Gatewaya. Idealna mikrostoritev, pri čemer v AWS Lambda podpiramo veliko sodobnih programskih jezikov. Stroški vzdrževanja in postavitve infrastrukture postanejo ničelni, stroški vzdrževanja manjših aplikacij pa so prav tako zelo nizki (AWS Lambda — 0,2 $ / 1 milijon preprostih zahtev).
Širljivost takšne sisteme je praktično idealna — oblačni ponudnik se o tem skrbi sam, Kubeless se avtomatsko prilagaja znotraj Kubernetes grozda.
Obstajajo slabosti:
- razvoj velikih aplikacij postaja težji
- obstajajo težave s profiliranjem aplikacij (dostopni so le dnevniki, ne pa profiliranje v običajnem smislu)
- ni različic
Priznam, o Serverless sem slišal že pred nekaj leti, a vseh teh letih mi ni bilo jasno, kako ga pravilno uporabiti. Po predavanju Ruslana sem dobil razumevanje, po predavanju Nikolaja Sverchkovskega (Evil Martians) iz Backend sekcije pa se je to tudi utrdilo. Ni bilo zaman, da sem šel na konferenco 🙂
CI za revne, ali se splača napisati svoj CI za spletno agencijo
Mihail Radionov, vodja spletne agencije Flag iz Jekaterinburga, je spregovoril o lastnem CI/CD.
Njihova agencija je prešla od ‘ročnega CI/CD’ (prijava na strežnik po SSH, izvedba git pull, ponovitev 100-krat na dan) do Jenkins in lastnega orodja, ki omogoča nadzor kode in izvajanje izdaj, imenovanega Pullkins.
Zakaj Jenkins ni bil zadosten? Ni zagotavljal dovolj prilagodljivosti privzeto in je bil preveč zapleten za prilagajanje.
“Flag” razvija na Laravellu (PHP okvir). Pri razvoju CI/CD strežnika sta Mihail in njegovi kolegi izkoristili vgrajena mehanizma Laravela, znana kot Telescope in Envoy. Rezultat je strežnik na php (opazite), ki obdeluje prihajajoče webhook zahteve, izvaja gradnje frontend-a, backend-a, izvaja implementacijo na različne strežnike in poroča v Slack.
Nato so za možnost izvajanja blue/green deploya in enotnih nastavitev v dev-stage-prod okoljih prešli na Docker. Prednosti so ostale enake, dodale so se možnosti homogenizacije okolja in brezšivnega implementiranja, ter potreba po učenju Dockerja za pravilno delo z njim.
Kako smo zmanjšali število vračanj strežniških izdaj za 99%
Zadnje poročilo v Devops sekciji je bilo od Viktorja Jeremčenka, glavnega devops inženirja v Miro.com (bivši RealTimeBoard).
Osnova RealTimeBoard, glavnega izdelka ekipe Miro, je monolitna aplikacija v Javi. Zbiranje, testiranje in implementacija brez izpadov je zapletena naloga. Pri tem je pomembno izvajati implementacijo take različice kode, da je ni treba vračati nazaj (težek monolit).
Na poti k postavitvi sistema, ki to omogoča, je Miro prehodil pot, ki je vključevala delo na arhitekturi, uporabljenih orodjih (Atlassian Bamboo, Ansible, itd.), in delo na oblikovanju ekip (zdaj imajo namensko Devops ekipo + mnoge posamezne Scrum ekipe razvijalcev različnih profilov).
Pot se je izkazala za težavno in trnovo, Viktor pa je delil nabran bol in neizčrpni optimizem.
Zmagal knjigo za vprašanja
Backend sekcija
Ujel sem se na 2 poročila - od Nikolaja Sverčkova (Evil Martians), prav tako o Serverless, in od Grigorija Košelevа (podjetje Kontur) o telemetriji.
Serverless za navadne smrtnike
Če je Ruslan Sirkin govoril o tem, kaj je Serverless, je Nikolaj pokazal preproste aplikacije z uporabo Serverless in razložil podrobnosti, ki vplivajo na stroške in hitrost delovanja aplikacij v AWS Lambda.
Zanimiv podatek: najmanjši plačljiv element je 128 Mb pomnilnika in 100 ms CPU, stane 0,000000208$. Pri tem je 1 milijon takšnih zahtevkov na mesec brezplačen.
Nekatere funkcije pri Nikolaju so pogosto presegle mejo 100 ms (glavna aplikacija je bila napisana v Ruby), zato je ponovna programska oprema v Go privedla do odlične ekonomije.
Vostok Hercules — ponovno naredite telemetrijo veliko!
Zadnje poročilo Backend sekcije od Grigorija Košelev v podjetju Kontur o telemetriji. Telemetrija so logi, metrike, sledi aplikacij.
Kontur uporablja za to lastne orodja, objavljene na Githubu. Orodje iz poročila — Hercules, , se uporablja za dostavo podatkov telemetrije.
V poročilu Vladimira Lile v sekciji Devops je bilo obravnavano shranjevanje in obdelava logov v Elasticsearch, vendar je še ena naloga dostaviti loge iz več tisoč naprav in aplikacij, kar rešujejo orodja kot Vostok Hercules.
Kontur je prešel znano pot — od RabbitMQ do Apache Kafka, vendar ni bilo vse tako preprosto. Morali so dodati Zookeeper, Cassandra in Graphite v shemo. O tej predstavitvi ne morem povsem razkriti informacij (ni moj profil), če vas zanima — lahko počakate na diapozitive in video na spletni strani konference.
Kako se primerja z drugimi konferencami?
Ne morem primerjati s konferencami v Moskvi in SPb, lahko pa primerjam z drugimi dogodki v Uralu in 404festom v Samari.
DAMP poteka v 8 sekcijah, to je rekord za uralske konference. Zelo velike sekcije Science in Management, kar je tudi nenavadno. Publika v Jekaterinburgu je dovolj strukturirana — v mestu so veliki razvoji Yandex, Kontur, Tinkoff, kar vpliva tudi na poročila.
Še en zanimiv trenutek — mnoge podjetja imajo hkrati 3–4 predavatelje na konferenci (tako je bilo pri Konturu, Evil Martians, Tinkoff). Mnogi od njih so bili sponzorji, toda poročila so bila povsem na ravni drugih, niso to bili oglasni nastopi.
Oditi ali ne oditi? Če živite v Uralu ali blizu, imate priložnost in vas zanimajo teme — da, seveda. Če razmišljate o daljni poti — ogledal bi si teme predavanj in videov preteklih let. in sprejel odločitev.
Še ena prednost konferenc v regijah je, da je običajno enostavno spregovoriti z govoricem po predavanjih, preprosto je manj kandidatov za to komunikacijo.
Hvala DAMP-u in Jekaterinburgu!
Izvor: habr.com
