Minulý týden jsem byl na konferenci DUMP IT (https://dump-ekb.ru/) v Jekatěrinburgu a chci vám říct, o čem se mluvilo v sekcích Backend a Devops a zda regionální IT konference stojí za pozornost.
Nikolay Sverchkov z Evil Martians o Serverless
Co tam vůbec bylo?
Celkem měla konference 8 sekcí: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science a Management.
Největší sály jsou mimochodem ve Science and Management)) Každý pro ~350 lidí. Backend a Frontend nejsou o moc menší. Místnost Devops byla nejmenší, ale aktivní.
Poslouchal jsem reportáže v sekcích Devops a Backend a trochu jsem si popovídal s řečníky. Rád bych hovořil o probíraných tématech a zhodnotil tyto sekce na konferenci.
V sekcích Devops a Backend vystoupili zástupci SKB-Kontur, DataArt, Evil Martians, webového studia Jekatěrinburg Flag, Miro (RealTimeBoard). Témata pokrytá CI/CD, práce s frontovými službami, protokolování, témata bez serveru a práce s PostgreSQL v Go byla dobře pokryta.
Byly tam i reportáže Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, ale neměl jsem čas se jim fyzicky zúčastnit (videozáznamy a diapozitivy zpráv zatím nejsou k dispozici, slibují, že je zveřejní do 2 týdnů na dump-ekb.ru).
Sekce Devops
Překvapivé bylo, že sekce se konala v nejmenším sále, cca 50 míst. Lidé dokonce stáli v uličkách :) Řeknu vám o zprávách, které jsem si stihl poslechnout.
Elastické vážící petabajt
Sekce začala zprávou Vladimíra Lila (SKB-Kontur) o Elasticsearch v Konturu. Mají poměrně velký a nabitý Elastic (~800 TB dat, ~1.3 petabajtů s přihlédnutím k redundanci). Elasticsearch pro všechny služby Kontur je jediný, skládá se ze 2 clusterů (ze 7 a 9 serverů) a je tak důležitý, že Kontur má speciálního inženýra Elasticsearch (ve skutečnosti samotného Vladimíra).
Vladimir se také podělil o své myšlenky o výhodách Elasticsearch a problémech, které přináší.
Výhoda:
- Všechny protokoly jsou na jednom místě, snadný přístup k nim
- Ukládání protokolů po dobu jednoho roku a jejich snadná analýza
- Vysoká rychlost práce s logy
- Skvělá vizualizace dat ihned po vybalení
Problémy jsou:
- Zprostředkovatel zpráv je nutností (pro Kontur jeho roli hraje Kafka)
- funkce práce s Elasticsearch Curator (periodicky vytvářená vysoká zátěž z běžných úkolů v Curatoru)
- žádná vestavěná autorizace (pouze za samostatné, poměrně velké peníze, nebo jako open source pluginy různého stupně připravenosti k produkci)
Na Open Distro pro Elasticsearch byly jen kladné recenze :) Stejný problém s autorizací tam byl vyřešen.
Odkud pochází petabajt?Jejich uzly se skládají ze serverů s 12*8 Tb SATA + 2*2 Tb SSD. Studené úložiště na SATA, SSD pouze pro hot cache (horké úložiště).
7+9 serverů, (7 + 9) * 12 * 8 = 1536 Tb.
Část prostoru je v záloze, vyčleněná pro nadbytečnost atd.
Do Elasticsearch jsou zasílány protokoly z cca 90 aplikací, včetně všech reportovacích služeb Kontur, Elba atd.
Vlastnosti vývoje na Serverless
Další je zpráva Ruslana Serkina z DataArt o Serverless.
Ruslan hovořil o tom, co je obecně vývoj s přístupem Serverless a jaké jsou jeho vlastnosti.
Serverless je přístup k vývoji, při kterém se vývojáři žádným způsobem nedotýkají infrastruktury. Příklad – AWS Lambda Serverless, Kubeless.io (Serverless uvnitř Kubernetes), Google Cloud Functions.
Ideální bezserverová aplikace je jednoduše funkce, která odešle požadavek bezserverovému poskytovateli přes speciální API bránu. Ideální mikroslužba, přičemž AWS Lambda podporuje i velké množství moderních programovacích jazyků. Náklady na údržbu a nasazení infrastruktury se v případě cloudových poskytovatelů stávají nulovými, podpora malých aplikací bude také velmi levná (AWS Lambda – 0.2 $ / 1 milion jednoduchých požadavků).
Škálovatelnost takového systému je téměř ideální – o to se stará sám poskytovatel cloudu, Kubeless se škáluje automaticky v rámci clusteru Kubernetes.
Existují nevýhody:
- vývoj velkých aplikací je stále obtížnější
- jsou potíže s profilovacími aplikacemi (k dispozici máte pouze protokoly, ale ne profilování v obvyklém smyslu)
- žádné verzování
Abych byl upřímný, slyšel jsem o Serverless před několika lety, ale celé ty roky mi nebylo jasné, jak jej správně používat. Po Ruslanově hlášení se dostavilo porozumění a po hlášení Nikolaje Sverčkova (Zlí Marťané) ze sekce Backend došlo k jeho upevnění. Ne nadarmo jsem na konferenci vyrazil :)
CI je pro chudé, nebo se vyplatí psát vlastní CI pro webové studio?
Michail Radionov, vedoucí webového studia Flag z Jekatěrinburgu, hovořil o vlastnoručně napsaných CI/CD.
Jeho studio přešlo z „manuálního CI/CD“ (přihlaste se na server přes SSH, proveďte git pull, opakujte 100krát denně) na Jenkins a na samostatně psaný nástroj, který vám umožňuje monitorovat kód a provádět vydání s názvem Pullkins. .
Proč Jenkins nefungoval? Ve výchozím nastavení neposkytoval dostatečnou flexibilitu a bylo příliš obtížné jej přizpůsobit.
„Flag“ se vyvíjí v Laravelu (PHP framework). Při vývoji CI/CD serveru Michail a jeho kolegové použili Laravelovy vestavěné mechanismy zvané Telescope and Envoy. Výsledkem je server v PHP (všimněte si prosím), který zpracovává příchozí požadavky webhooku, dokáže vytvořit frontend a backend, nasadit na různé servery a podávat zprávy Slacku.
Poté, aby mohli provádět modro/zelené nasazení a mít jednotná nastavení v prostředí dev-stage-prod, přešli na Docker. Výhody zůstaly stejné, přibyly možnosti homogenizace prostředí a bezproblémového nasazení a nutnost naučit se s ním Docker správně pracovat.
Jak jsme snížili počet vrácení serverových verzí o 99 %
Poslední zpráva v sekci Devops byla od Viktora Eremčenka, vedoucího vývojového inženýra na Miro.com (dříve RealTimeBoard).
RealTimeBoard, vlajkový produkt týmu Miro, je založen na monolitické Java aplikaci. Shromažďování, testování a nasazení bez prostojů je obtížný úkol. V tomto případě je důležité nasadit takovou verzi kódu, aby se nemusela vracet zpět (je to těžký monolit).
Na cestě k vybudování systému, který vám to umožní, prošel Miro cestou, která zahrnovala práci na architektuře, používaných nástrojích (Atlassian Bamboo, Ansible atd.) a práci na struktuře týmů (nyní mají specializovaný tým Devops + mnoho samostatných týmů Scrum od vývojářů různých profilů).
Cesta se ukázala jako obtížná a trnitá a Victor sdílel nahromaděnou bolest a optimismus, který tím nekončil.
Vyhrál knihu za kladení otázek
Backend sekce
Podařilo se mi zúčastnit 2 reportáží - od Nikolaje Sverčkova (Evil Martians), také o Serverless, a od Grigorije Kosheleva (společnost Kontur) o telemetrii.
Bez serveru pro obyčejné smrtelníky
Pokud Ruslan Sirkin hovořil o tom, co je Serverless, Nikolay ukázal jednoduché aplikace využívající Serverless a hovořil o detailech, které ovlivňují cenu a rychlost aplikací v AWS Lambda.
Zajímavý detail: minimální placený prvek je 128 Mb paměti a 100 ms CPU, stojí 0,000000208 $. Navíc 1 milion takových žádostí měsíčně je zdarma.
Některé Nikolaiho funkce často překračovaly limit 100 ms (hlavní aplikace byla napsána v Ruby), takže jejich přepsání v Go poskytlo vynikající úspory.
Vostok Hercules — udělejte telemetrii opět skvělou!
Nejnovější zpráva sekce Backend od Grigorije Kosheleva (společnost Kontur) o telemetrii. Telemetrie znamená protokoly, metriky, aplikační stopy.
Pro tento účel používá Contour nástroje, které si sami napíší na Github. Nástroj ze zprávy - Hercules, , se používá k doručování telemetrických dat.
Zpráva Vladimíra Lily v sekci Devops pojednávala o ukládání a zpracování protokolů v Elasticsearch, ale stále je zde úkol doručovat protokoly z mnoha tisíc zařízení a aplikací a nástroje jako Vostok Hercules je řeší.
Okruh šel cestou známou mnoha - od RabbitMQ po Apache Kafku, ale ne všechno je tak jednoduché)) Do okruhu museli přidat Zookeeper, Cassandra a Graphite. Informace o této zprávě (nikoli můj profil) nebudu plně zveřejňovat, pokud budete mít zájem, můžete si počkat na snímky a videa na webu konference.
Jak si stojí v porovnání s jinými konferencemi?
Nemohu to srovnávat s konferencemi v Moskvě a Petrohradu, mohu to srovnat s jinými akcemi na Uralu a s 404festem v Samaře.
DAMP se koná v 8 sekcích, to je rekord pro Uralské konference. Velmi rozsáhlé sekce vědy a managementu, to je také neobvyklé. Publikum v Jekatěrinburgu je poměrně strukturované - město má velká vývojová oddělení pro Yandex, Kontur, Tinkoff, což zanechává stopy ve zprávách.
Další zajímavostí je, že mnoho společností má na konferenci 3-4 řečníky najednou (to byl případ Kontur, Evil Martians, Tinkoff). Mnozí z nich byli sponzoři, ale zprávy jsou docela na stejné úrovni jako ostatní, nejsou to reklamní zprávy.
Jít či nejít? Pokud bydlíte na Uralu nebo poblíž, máte možnost a témata vás zajímají – ano, samozřejmě. Pokud uvažujete o dlouhé cestě, podíval bych se na témata reportáží a videoreportáží z minulých let a učinil rozhodnutí.
Další výhodou konferencí v regionech zpravidla je, že se s řečníkem po referátech snadno domluví, zájemců o takovou komunikaci je prostě méně.
Díky Dump a Jekatěrinburgu! )
Zdroj: www.habr.com