Í síðustu viku fór ég á DUMP IT ráðstefnuna (https://dump-ekb.ru/) í Yekaterinburg og ég vil segja ykkur hvað var rætt í Backend og Devops hlutanum og hvort svæðisbundnar upplýsingatækniráðstefnur séu athyglisverðar.
Nikolay Sverchkov úr Evil Martians um Serverless
Hvað var þarna samt?
Alls voru 8 hlutar á ráðstefnunni: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Stærstu salirnir, við the vegur, eru hjá Science and Management)) Fyrir ~350 manns hver. Backend og Frontend eru ekki mikið minni. Devops herbergið var minnst, en virkt.
Ég hlustaði á skýrslurnar í Devops og Backend köflum og talaði aðeins við hátalarana. Mig langar að tala um þau efni sem fjallað er um og rifja upp þessa þætti á ráðstefnunni.
Fulltrúar SKB-Kontur, DataArt, Evil Martians, Ekaterinburg vefstofu Flag, Miro (RealTimeBoard) töluðu í Devops og Backend hlutanum. Farið var yfir efni sem fjallað var um CI/CD, vinna með biðröðþjónustu, skráningu; Þjónustulaust efni og vinna með PostgreSQL í Go var farið vel yfir.
Það voru líka skýrslur frá Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, en ég hafði ekki tíma til að mæta líkamlega (myndbandsupptökur og glærur af skýrslunum eru ekki enn tiltækar, þeir lofa að birta þær innan 2 vikna á dump-ekb.ru).
Devops hluti
Það sem kom á óvart var að deildin var haldin í minnsta salnum, um 50 sæti. Fólk stóð meira að segja í göngunum :) Ég skal segja þér frá skýrslunum sem ég náði að hlusta á.
Teygja sem vegur petabæti
Kaflinn hófst á skýrslu Vladimir Lil (SKB-Kontur) um Elasticsearch í Kontur. Þeir eru með nokkuð stóra og hlaðna teygju (~ 800 TB af gögnum, ~ 1.3 petabæt að teknu tilliti til offramboðs). Elasticsearch fyrir alla Kontur þjónustu er einn, samanstendur af 2 klösum (af 7 og 9 netþjónum) og er svo mikilvægt að Kontur hefur sérstakan Elasticsearch verkfræðing (reyndar Vladimir sjálfur).
Vladimir deildi einnig hugsunum sínum um kosti Elasticsearch og vandamálin sem það hefur í för með sér.
Hagur:
- Allir logs eru á einum stað, auðvelt aðgengi að þeim
- Geymir logs í eitt ár og greinir þá auðveldlega
- Mikill hraði að vinna með logs
- Flott gagnasýn úr kassanum
Vandamál:
- skilaboðamiðlari er nauðsynlegur (fyrir Kontur er hlutverk hans gegnt af Kafka)
- eiginleikar þess að vinna með Elasticsearch Curator (bjó reglulega til mikið álag frá venjulegum verkefnum í Curator)
- engin innbyggð heimild (aðeins fyrir sérstakan, frekar stóran pening eða sem opinn uppspretta viðbætur sem eru misjafnlega reiðubúin til framleiðslu)
Það voru bara jákvæðar umsagnir um Open Distro fyrir Elasticsearch :) Sama heimildarmál hefur verið leyst þar.
Hvaðan kemur petabætið?Hnútar þeirra samanstanda af netþjónum með 12*8 Tb SATA + 2*2 Tb SSD. Kald geymsla á SATA, SSD aðeins fyrir heitt skyndiminni (heitt geymsla).
7+9 netþjónar, (7 + 9) * 12 * 8 = 1536 Tb.
Hluti rýmisins er í varasjóði, varið til uppsagnar o.fl.
Logar úr um 90 umsóknum eru sendir til Elasticsearch, þar á meðal öll skýrsluþjónusta Kontur, Elba o.fl.
Eiginleikar þróunar á Serverless
Næst er skýrsla Ruslan Serkin frá DataArt um Serverless.
Ruslan talaði um hvað þróun með Serverless nálguninni er almennt og hverjir eiginleikar hennar eru.
Serverless er nálgun við þróun þar sem verktaki snertir ekki innviðina á nokkurn hátt. Dæmi - AWS Lambda Serverless, Kubeless.io (Serverless in Kubernetes), Google Cloud Functions.
Tilvalið netþjónalaust forrit er einfaldlega aðgerð sem sendir beiðni til netþjónslauss veitanda í gegnum sérstaka API hlið. Tilvalin örþjónusta en AWS Lambda styður einnig fjölda nútíma forritunarmála. Kostnaðurinn við að viðhalda og dreifa innviðum verður enginn þegar um skýjaveitur er að ræða, stuðningur við lítil forrit verður líka mjög ódýr (AWS Lambda - $ 0.2 / 1 milljón einfaldar beiðnir).
Sveigjanleiki slíks kerfis er nánast tilvalinn - skýjaveitan sér um þetta sjálf, Kubeless skalast sjálfkrafa innan Kubernetes klasans.
Það eru ókostir:
- að þróa stór forrit er að verða erfiðara
- það eru erfiðleikar með prófílforrit (aðeins annálar eru í boði fyrir þig, en ekki prófílgreining í venjulegum skilningi)
- engin útgáfugerð
Satt að segja heyrði ég um Serverless fyrir nokkrum árum, en öll þessi ár var mér ekki ljóst hvernig ætti að nota það rétt. Eftir skýrslu Ruslan kom skilningur í ljós og eftir skýrslu Nikolai Sverchkov (Evil Martians) frá Backend hlutanum, var það sameinað. Það var ekki til einskis að ég fór á ráðstefnuna :)
CI er fyrir fátæka, eða er það þess virði að skrifa þitt eigið CI fyrir vefstofu?
Mikhail Radionov, yfirmaður Flag vefversins frá Yekaterinburg, talaði um sjálfskrifaða CI/CD.
Vinnustofan hans hefur farið úr „handvirku CI/CD“ (skráðu þig inn á netþjóninn í gegnum SSH, gerðu git pull, endurtaktu 100 sinnum á dag) í Jenkins og í sjálfskrifað tól sem gerir þér kleift að fylgjast með kóða og framkvæma útgáfur sem kallast Pullkins .
Af hverju vann Jenkins ekki? Það gaf ekki nægan sveigjanleika sjálfgefið og var of erfitt að sérsníða.
„Fáni“ þróast í Laravel (PHP ramma). Þegar þeir þróaðu CI/CD miðlara notuðu Mikhail og samstarfsmenn hans innbyggðu kerfi Laravels sem kallast Telescope and Envoy. Niðurstaðan er þjónn í PHP (vinsamlega athugið) sem vinnur úr komandi vefhookbeiðnum, getur smíðað framenda og bakenda, dreift á mismunandi netþjóna og tilkynnt til Slack.
Síðan, til að geta framkvæmt bláa/græna uppsetningu og haft samræmdar stillingar í dev-stage-prod umhverfi, skiptu þeir yfir í Docker. Kostirnir héldust þeir sömu, möguleikunum á að gera umhverfið einsleitt og óaðfinnanlega uppsetningu var bætt við og þörfinni á að læra Docker til að vinna með það rétt bættist við.
Hvernig við fækkuðum fjölda endurgerða netþjónaútgáfu um 99%
Síðasta skýrslan í Devops hlutanum var frá Viktor Eremchenko, Lead devops verkfræðingi hjá Miro.com (áður RealTimeBoard).
RealTimeBoard, flaggskip vara Miro liðsins, er byggt á einhæfu Java forriti. Að safna, prófa og dreifa því án niður í miðbæ er erfitt verkefni. Í þessu tilfelli er mikilvægt að dreifa slíkri útgáfu af kóðanum þannig að það þurfi ekki að snúa honum til baka (það er þungur einlitur).
Á leiðinni að því að byggja upp kerfi sem gerir þér kleift að gera þetta fór Miro í gegnum slóð sem innihélt að vinna að arkitektúrnum, verkfærunum sem notuð eru (Atlassian Bamboo, Ansible, osfrv.), og vinna að uppbyggingu teymanna (þau hafa nú sérstakt Devops teymi + mörg aðskilin Scrum teymi frá hönnuðum með mismunandi snið).
Leiðin reyndist erfið og þyrnum stráð og Victor deildi uppsöfnuðum sársauka og bjartsýni sem ekki endaði þar.
Vann bók fyrir að spyrja spurninga
Bakendahluti
Mér tókst að mæta á 2 skýrslur - frá Nikolay Sverchkov (Evil Martians), einnig um Serverless, og frá Grigory Koshelev (Kontur fyrirtæki) um fjarmælingar.
Serverlaus fyrir dauðlega menn
Ef Ruslan Sirkin talaði um hvað Serverless er, sýndi Nikolay einföld forrit sem notuðu Serverless og talaði um smáatriðin sem hafa áhrif á kostnað og hraða forrita í AWS Lambda.
Áhugavert smáatriði: lágmarks greiddur þáttur er 128 Mb af minni og 100 ms CPU, það kostar $0,000000208. Þar að auki eru 1 milljón slíkra beiðna á mánuði ókeypis.
Sumar aðgerðir Nikolai fóru oft yfir 100 ms mörkin (aðalforritið var skrifað í Ruby), svo að endurskrifa þær í Go gaf frábæran sparnað.
Vostok Hercules — gerðu fjarmælingar frábærar aftur!
Nýjasta skýrslan af Backend hlutanum frá Grigory Koshelev (Kontur fyrirtæki) um fjarmælingar. Fjarmæling þýðir logs, mæligildi, umsóknarspor.
Í þessu skyni notar Contour sjálfskrifuð verkfæri sem birt eru á Github. Verkfæri úr skýrslunni - Hercules, , er notað til að afhenda fjarmælingagögn.
Skýrsla Vladimir Lila í Devops hlutanum fjallaði um geymslu og vinnslu annála í Elasticsearch, en enn er verkefnið að afhenda annála frá mörg þúsund tækjum og forritum og verkfæri eins og Vostok Hercules leysa þau.
Hringrásin fylgdi leið sem margir þekkja - frá RabbitMQ til Apache Kafka, en ekki er allt svo einfalt)) Þeir þurftu að bæta Zookeeper, Cassandra og Graphite við hringrásina. Ég mun ekki birta upplýsingarnar um þessa skýrslu að fullu (ekki prófílinn minn), ef þú hefur áhuga geturðu beðið eftir glærum og myndböndum á ráðstefnuvefsíðunni.
Hvernig er það í samanburði við aðrar ráðstefnur?
Ég get ekki borið það saman við ráðstefnur í Moskvu og Sankti Pétursborg, ég get borið það saman við aðra viðburði í Úralfjöllum og við 404fest í Samara.
DAMP er haldið í 8 hlutum, þetta er met fyrir Ural ráðstefnur. Mjög stórir vísinda- og stjórnunarhlutar, þetta er líka óvenjulegt. Áhorfendur í Yekaterinburg eru nokkuð skipulagðir - borgin hefur stórar þróunardeildir fyrir Yandex, Kontur, Tinkoff og þetta setur mark sitt á skýrslurnar.
Annar athyglisverður punktur er að mörg fyrirtæki eru með 3-4 fyrirlesara á ráðstefnunni í einu (þetta var tilfellið með Kontur, Evil Martians, Tinkoff). Margir þeirra voru styrktaraðilar, en skýrslurnar eru nokkuð á pari við aðrar, þetta eru ekki auglýsingaskýrslur.
Að fara eða ekki að fara? Ef þú býrð í Úralfjöllum eða í nágrenninu hefurðu tækifæri og hefur áhuga á efninu - já, auðvitað. Ef þú ert að hugsa um langt ferðalag myndi ég skoða efni skýrslna og myndbandsskýrslna frá fyrri árum og tók ákvörðun.
Annar kostur við ráðstefnur á landsbyggðinni er að jafnaði að auðvelt er að eiga samskipti við fyrirlesara eftir skýrslurnar, það eru einfaldlega færri umsækjendur um slík samskipti.
Þökk sé Dump og Ekaterinburg! )
Heimild: www.habr.com
