Prejšnji teden sem šel na konferenco DUMP IT (https://dump-ekb.ru/) v Jekaterinburgu in želim vam povedati, o čem se je razpravljalo v razdelkih Backend in Devops ter ali so regionalne IT konference vredne pozornosti.
Nikolay Sverchkov iz Evil Martians o Serverless
Kaj je sploh bilo tam?
Skupno je imela konferenca 8 sekcij: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science in Management.
Mimogrede, največje dvorane so pri znanosti in upravljanju)) Za ~350 ljudi vsaka. Backend in Frontend nista veliko manjša. Soba Devops je bila najmanjša, a aktivna.
Poslušal sem poročila v sekcijah Devops in Backend ter se malo pogovarjal z govorci. Na konferenci bi rad govoril o obravnavanih temah in pregledal te dele.
V sekcijah Devops in Backend so govorili predstavniki SKB-Kontur, DataArt, Evil Martians, Ekaterinburg spletni studio Flag, Miro (RealTimeBoard). Zajete teme CI/CD, delo s storitvami čakalne vrste, beleženje; teme brez strežnika in delo s PostgreSQL v Go so bile dobro pokrite.
Poročila so bila tudi Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, vendar nisem imel časa, da bi se jih fizično udeležil (videoposnetki in diapozitivi poročil še niso na voljo, obljubljajo, da jih bodo objavili v 2 tednih na dump-ekb.ru).
Oddelek Devops
Presenetljivo je bilo, da je sekcija potekala v najmanjši dvorani, približno 50 sedežev. Ljudje so celo stali na prehodih :) Povedal vam bom o poročilih, ki sem jih uspel poslušati.
Elastika, ki tehta petabajt
Rubrika se je začela s poročilom Vladimirja Lila (SKB-Kontur) o Elasticsearch v Konturju. Imajo dokaj velik in obremenjen Elastic (~800 TB podatkov, ~1.3 petabajta z upoštevanjem redundance). Elasticsearch za vse storitve Kontur je enoten, sestavljen iz 2 grozdov (7 in 9 strežnikov) in je tako pomemben, da ima Kontur posebnega inženirja Elasticsearch (pravzaprav sam Vladimir).
Vladimir je delil tudi svoje misli o prednostih Elasticsearch in težavah, ki jih prinaša.
Prednosti:
- Vsi dnevniki so na enem mestu, enostaven dostop do njih
- Shranjevanje dnevnikov za eno leto in njihova enostavna analiza
- Visoka hitrost dela z hlodi
- Kul vizualizacija podatkov takoj po izdelavi
Težave so:
- posrednik sporočil mora imeti (za Kontur njegovo vlogo igra Kafka)
- značilnosti dela z Elasticsearch Curator (občasno ustvarjena velika obremenitev zaradi rednih opravil v Curatorju)
- brez vgrajene avtorizacije (samo za ločen, precej velik denar ali kot odprtokodni vtičniki različnih stopenj pripravljenosti za proizvodnjo)
O Open Distro za Elasticsearch so bile samo pozitivne ocene :) Enako vprašanje avtorizacije je bilo tam rešeno.
Od kod prihaja petabajt?Njihova vozlišča sestavljajo strežniki z 12*8 Tb SATA + 2*2 Tb SSD. Hladno shranjevanje na SATA, SSD samo za vroče predpomnilnik (hot storage).
7+9 strežnikov, (7 + 9) * 12 * 8 = 1536 Tb.
Del prostorov je v rezervi, namenjen presežkom ipd.
Dnevniki približno 90 aplikacij se pošiljajo v Elasticsearch, vključno z vsemi storitvami poročanja Kontur, Elba itd.
Značilnosti razvoja brez strežnika
Sledi poročilo Ruslana Serkina iz DataArt o Serverless.
Ruslan je spregovoril o tem, kaj sploh je razvoj s pristopom Serverless in kakšne so njegove značilnosti.
Serverless je pristop k razvoju, pri katerem se razvijalci nikakor ne dotikajo infrastrukture. Primer – AWS Lambda brez strežnika, Kubeless.io (brez strežnika znotraj Kubernetesa), Google Cloud Functions.
Idealna aplikacija brez strežnika je preprosto funkcija, ki pošlje zahtevo ponudniku brez strežnika prek posebnega prehoda API. Idealna mikrostoritev, AWS Lambda pa podpira tudi veliko število sodobnih programskih jezikov. Stroški vzdrževanja in uvajanja infrastrukture v primeru ponudnikov v oblaku postanejo enaki nič, zelo poceni bo tudi podpora majhnim aplikacijam (AWS Lambda - 0.2 USD / 1 milijon preprostih zahtev).
Razširljivost takšnega sistema je skoraj idealna – za to poskrbi ponudnik oblaka sam, Kubeless se samodejno skalira znotraj gruče Kubernetes.
Obstajajo slabosti:
- razvijanje velikih aplikacij postaja težje
- obstajajo težave z aplikacijami za profiliranje (na voljo so vam samo dnevniki, ne pa tudi profiliranje v običajnem smislu)
- brez različic
Če sem iskren, sem za Serverless slišal že nekaj let nazaj, a mi vsa ta leta ni bilo jasno, kako ga pravilno uporabljati. Po Ruslanovem poročilu se je pojavilo razumevanje, po poročilu Nikolaja Sverčkova (Zli Marsovci) iz rubrike Backend pa se je utrdilo. Nisem bil zaman na konferenco :)
CI je za reveže ali se splača napisati svoj CI za spletni studio?
Mikhail Radionov, vodja spletnega studia Flag iz Jekaterinburga, je spregovoril o samonapisanem CI/CD.
Njegov studio je šel od »ročnega CI/CD« (prijavite se v strežnik prek SSH, naredite git pull, ponovite 100-krat na dan) do Jenkinsa in do samonapisanega orodja, ki vam omogoča spremljanje kode in izvajanje izdaj, imenovano Pullkins .
Zakaj Jenkins ni delal? Privzeto ni zagotavljal dovolj prilagodljivosti in ga je bilo pretežko prilagoditi.
»Zastava« se razvije v Laravelu (ogrodje PHP). Pri razvoju strežnika CI/CD so Mikhail in njegovi kolegi uporabili Laravelove vgrajene mehanizme, imenovane Telescope in Envoy. Rezultat je strežnik v PHP (upoštevajte), ki obdeluje dohodne zahteve webhook, lahko zgradi sprednji in zadnji del, uvede v različne strežnike in poroča Slacku.
Nato so prešli na Docker, da bi lahko izvajali modro/zeleno uvajanje in imeli enotne nastavitve v okoljih dev-stage-prod. Prednosti so ostale enake, dodane so bile možnosti homogenizacije okolja in brezhibne uvedbe, dodana pa je bila tudi potreba po učenju Dockerja za pravilno delo z njim.
Kako smo zmanjšali število povratnih izdaj strežnika za 99 %
Zadnje poročilo v razdelku Devops je poslal Viktor Eremchenko, vodilni inženir devops pri Miro.com (prej RealTimeBoard).
RealTimeBoard, vodilni izdelek ekipe Miro, temelji na monolitni aplikaciji Java. Zbiranje, testiranje in uvajanje brez izpadov je težka naloga. V tem primeru je pomembno razmestiti takšno različico kode, da je ni treba vrniti (je težak monolit).
Na poti do izgradnje sistema, ki vam to omogoča, je Miro šel skozi pot, ki je vključevala delo na arhitekturi, uporabljenih orodjih (Atlassian Bamboo, Ansible itd.) in delo na strukturi ekip (zdaj imajo namenska ekipa Devops + številne ločene ekipe Scrum razvijalcev različnih profilov).
Pot se je izkazala za težko in trnovo, Victor pa je delil nakopičeno bolečino in optimizem, ki se tu ni končal.
Dobil knjigo za postavljanje vprašanj
Zaledni razdelek
Uspelo mi je prisostvovati 2 poročilom - od Nikolaja Sverčkova (Zlobni Marsovci), prav tako o Serverless, in od Grigorija Košeleva (podjetje Kontur) o telemetriji.
Brez strežnika za navadne smrtnike
Če je Ruslan Sirkin govoril o tem, kaj je Serverless, je Nikolay pokazal preproste aplikacije, ki uporabljajo Serverless, in govoril o podrobnostih, ki vplivajo na stroške in hitrost aplikacij v AWS Lambda.
Zanimiva podrobnost: minimalni plačani element je 128 Mb pomnilnika in 100 ms CPU, stane 0,000000208 $. Poleg tega je 1 milijon takšnih zahtev na mesec brezplačnih.
Nekatere Nikolajeve funkcije so pogosto presegle omejitev 100 ms (glavna aplikacija je bila napisana v Rubyju), zato je njihovo prepisovanje v Go zagotovilo odlične prihranke.
Vostok Hercules — naredite telemetrijo znova odlično!
Zadnje poročilo odseka Backend Grigorija Kosheleva (podjetje Kontur) o telemetriji. Telemetrija pomeni dnevnike, metrike, sledi aplikacij.
V ta namen Contour uporablja samonapisana orodja, objavljena na Githubu. Orodje iz poročila - Hercules, , se uporablja za dostavo telemetričnih podatkov.
Poročilo Vladimirja Lile v razdelku Devops je razpravljalo o shranjevanju in obdelavi dnevnikov v Elasticsearch, vendar še vedno obstaja naloga dostave dnevnikov iz več tisoč naprav in aplikacij, orodja, kot je Vostok Hercules, pa jih rešujejo.
Vezje je šlo po poti, ki je znana mnogim - od RabbitMQ do Apache Kafke, vendar ni vse tako preprosto)) V vezje so morali dodati Zookeeper, Cassandra in Graphite. Ne bom v celoti razkril informacij o tem poročilu (ne moj profil), če vas zanima, lahko počakate na diapozitive in videe na spletni strani konference.
Kakšna je v primerjavi z drugimi konferencami?
Ne morem ga primerjati s konferencama v Moskvi in Sankt Peterburgu, lahko ga primerjam z drugimi dogodki na Uralu in s 404festom v Samari.
DAMP poteka v 8 sekcijah, kar je rekord za Uralske konference. Zelo velika razdelka Science in Management, tudi to je nenavadno. Občinstvo v Jekaterinburgu je precej strukturirano - mesto ima velike razvojne oddelke za Yandex, Kontur, Tinkoff, kar pusti pečat na poročilih.
Še ena zanimivost je, da imajo mnoga podjetja na konferenci 3-4 govornike hkrati (tako je bilo pri Konturju, Evil Martians, Tinkoff). Mnogi od njih so bili sponzorji, vendar so poročila povsem enaka drugim, to niso reklamna poročila.
Iti ali ne iti? Če živite na Uralu ali v bližini, imate možnost in vas zanimajo teme - ja, seveda. Če razmišljate o daljšem potovanju, bi pogledal teme poročil in video poročil iz prejšnjih let in sprejel odločitev.
Druga prednost konferenc v regijah je praviloma ta, da je po poročilih enostavno komunicirati z govornikom, preprosto je manj prosilcev za takšno komunikacijo.
Hvala Dump in Ekaterinburg! )
Vir: www.habr.com