Konference Habr není debutem. Dříve jsme pořádali docela velké akce Toaster pro 300-400 lidí, ale teď jsme se rozhodli, že budou relevantní malá tematická setkání, jejichž směr si můžete nastavit třeba v komentářích. První konference tohoto formátu se konala v červenci a byla věnována vývoji backendu. Účastníci si vyslechli zprávy o vlastnostech přechodu z backendu na ML a o designu služby Quadrupel na portálu Státní služby a také se zúčastnili kulatého stolu věnovaného Serverless. Pro ty, kteří se nemohli akce zúčastnit osobně, v tomto příspěvku prozradíme to nejzajímavější.
Od vývoje backendu po strojové učení
Co dělají datoví inženýři v ML? V čem jsou úkoly backendového vývojáře a ML inženýra podobné a odlišné? Jakou cestou se musíte vydat, abyste změnili své první povolání na druhé? To řekl Alexander Parinov, který se po 10 letech práce na backendu dal na strojové učení.
Alexandr Parinov
Dnes Alexander pracuje jako architekt systémů počítačového vidění ve společnosti X5 Retail Group a přispívá do projektů Open Source souvisejících s počítačovým viděním a hlubokým učením (github.com/creafz). Jeho dovednosti potvrzuje i jeho účast v top 100 světového žebříčku Kaggle Master (kaggle.com/creafz), nejpopulárnější platformy pro soutěže ve strojovém učení.
Proč přejít na strojové učení
Před rokem a půl Jeff Dean, šéf Google Brain, výzkumného projektu umělé inteligence založeného na hlubokém učení od Googlu, popsal, jak bylo půl milionu řádků kódu v Google Translate nahrazeno neuronovou sítí Tensor Flow skládající se pouze z 500 řádků. Po natrénování sítě se zvýšila kvalita dat a zjednodušila se infrastruktura. Zdálo by se, že toto je naše světlá budoucnost: už nemusíme psát kód, stačí vytvořit neurony a naplnit je daty. V praxi je ale vše mnohem složitější.
Infrastruktura ML ve společnosti Google
Neuronové sítě jsou jen malou částí infrastruktury (malý černý čtverec na obrázku výše). Pro příjem dat, jejich zpracování, ukládání, kontrolu kvality atd. je potřeba mnohem více pomocných systémů, potřebujeme infrastrukturu pro školení, nasazení kódu strojového učení do výroby a testování tohoto kódu. Všechny tyto úkoly jsou přesně podobné tomu, co dělají vývojáři backendu.
Proces strojového učení
Jaký je rozdíl mezi ML a backendem?
V klasickém programování píšeme kód a ten určuje chování programu. V ML máme malý kód modelu a spoustu dat, která na model hodíme. Data v ML jsou velmi důležitá: stejný model trénovaný na různých datech může ukázat zcela odlišné výsledky. Problém je, že data jsou téměř vždy roztroušena a uložena v různých systémech (relační databáze, NoSQL databáze, logy, soubory).
Verze dat
ML vyžaduje verzování nejen kódu jako v klasickém vývoji, ale také dat: je nutné jasně pochopit, na čem byl model trénován. K tomu můžete použít oblíbenou knihovnu Data Science Version Control (dvc.org).
Označení dat
Dalším úkolem je označování dat. Označte například všechny objekty na obrázku nebo řekněte, do které třídy patří. To se provádí speciálními službami, jako je Yandex.Toloka, práce s nimiž je výrazně zjednodušena přítomností API. Potíže vznikají kvůli „lidskému faktoru“: můžete zlepšit kvalitu dat a omezit chyby na minimum tím, že svěříte stejný úkol několika pracovníkům.
Vizualizace v Tensor Board
Protokolování experimentů je nezbytné pro porovnání výsledků a výběr nejlepšího modelu na základě některých metrik. Pro vizualizaci existuje velká sada nástrojů – například Tensor Board. Neexistují však žádné ideální způsoby ukládání experimentů. Malé firmy si často vystačí s excelovou tabulkou, velké zase používají speciální platformy pro ukládání výsledků do databáze.
Existuje mnoho platforem pro strojové učení, ale žádná z nich nepokrývá 70 % potřeb
První problém, se kterým se člověk musí potýkat při uvádění natrénovaného modelu do výroby, souvisí s oblíbeným nástrojem datových vědců – Jupyter Notebookem. Není v tom žádná modularita, to znamená, že výstupem je taková „nožka“ kódu, který není rozdělen na logické části – moduly. Všechno je pomíchané: třídy, funkce, konfigurace atd. Tento kód je obtížné verzovat a testovat.
Jak se s tím vypořádat? Můžete rezignovat sami jako Netflix a vytvořit si vlastní platformu, která vám umožní spouštět tyto notebooky přímo ve výrobě, přenášet do nich data jako vstup a získávat výsledky. Můžete donutit vývojáře, kteří zavádějí model do výroby, aby kód normálně přepsali, rozdělili na moduly. Ale s tímto přístupem je snadné udělat chybu a model nebude fungovat tak, jak bylo zamýšleno. Ideální možností je proto zakázat používání Jupyter Notebooku pro kód modelu. Pokud s tím ovšem datoví vědci souhlasí.
Model jako černá skříňka
Nejjednodušší způsob, jak dostat model do výroby, je použít jej jako černou skříňku. Máte nějakou třídu modelu, byly vám přiděleny váhy modelu (parametry neuronů trénované sítě) a pokud tuto třídu inicializujete (zavoláte metodu predikce, dáte jí obrázek), dostanete určitou predikce jako výstup. Co se děje uvnitř, není důležité.
Oddělte serverový proces s modelem
Můžete také vyvolat určitý samostatný proces a odeslat jej přes frontu RPC (s obrázky nebo jinými zdrojovými daty. Na výstupu obdržíme předpovědi.
Příklad použití modelu ve Flasku:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Problémem tohoto přístupu je omezení výkonu. Řekněme, že máme kód Phyton napsaný datovými vědci, který je pomalý, a chceme vymáčknout maximální výkon. K tomu můžete použít nástroje, které kód převedou na nativní nebo jej převedou do jiného frameworku přizpůsobeného pro produkci. Pro každý rámec existují takové nástroje, ale neexistují žádné ideální; budete je muset přidat sami.
Infrastruktura v ML je stejná jako v běžném backendu. Existují Docker a Kubernetes, pouze pro Docker musíte nainstalovat runtime od NVIDIA, což umožňuje procesům uvnitř kontejneru přistupovat k videokartám v hostiteli. Kubernetes potřebuje plugin, aby mohl spravovat servery s grafickými kartami.
Na rozdíl od klasického programování je v případě ML v infrastruktuře mnoho různých pohyblivých prvků, které je třeba kontrolovat a testovat – například kód pro zpracování dat, modelovací potrubí a produkci (viz schéma výše). Je důležité otestovat kód, který spojuje různé části potrubí: existuje mnoho částí a problémy se velmi často objevují na hranicích modulů.
Jak funguje AutoML
Služby AutoML slibují vybrat optimální model pro vaše účely a vycvičit jej. Ale musíte pochopit: data jsou v ML velmi důležitá, výsledek závisí na jejich přípravě. Značení provádějí lidé, což je plné chyb. Bez přísné kontroly může být výsledkem smetí a proces zatím není možné automatizovat, je potřeba ověření specialisty – datovými vědci. Tady se AutoML hroutí. Ale může to být užitečné pro výběr architektury – když už máte připravená data a chcete spustit sérii experimentů, abyste našli nejlepší model.
Jak se dostat do strojového učení
Nejjednodušší způsob, jak se dostat do ML, je vyvíjet v Pythonu, který se používá ve všech rámcích hlubokého učení (a běžných rámcích). Tento jazyk je pro tuto oblast činnosti prakticky povinný. C++ se používá pro některé úlohy počítačového vidění, například v řídicích systémech pro samořídící automobily. JavaScript a Shell – pro vizualizaci a takové divné věci, jako je spuštění neuronu v prohlížeči. Java a Scala se používají při práci s Big Data a pro strojové učení. R a Julii milují lidé, kteří studují matematické statistiky.
Nejpohodlnější způsob, jak získat praktické zkušenosti, je na Kaggle; účast v jedné ze soutěží platformy poskytuje více než rok studia teorie. Na této platformě můžete vzít něčí zveřejněný a okomentovaný kód a pokusit se jej vylepšit, optimalizovat pro své účely. Bonus – vaše hodnost Kaggle ovlivňuje váš plat.
Další možností je připojit se k týmu ML jako backendový vývojář. Existuje mnoho startupů se strojovým učením, kde můžete získat zkušenosti tím, že pomůžete svým kolegům vyřešit jejich problémy. Konečně se můžete připojit k jedné z komunit datových vědců – Open Data Science (ods.ai) a dalším.
Přednášející zveřejnil další informace k tématu na odkazu
"Quadrupel" - služba cílených upozornění portálu "Služby státu"
Evgeny Smirnov
Dalším řečníkem byl vedoucí oddělení rozvoje infrastruktury e-governmentu Evgeny Smirnov, který hovořil o Quadruple. Toto je cílená oznamovací služba pro portál Gosuslugi (gosuslugi.ru), nejnavštěvovanější vládní zdroj na Runetu. Denní sledovanost je 2,6 milionu, celkem je na stránce 90 milionů registrovaných uživatelů, z toho 60 milionů potvrzených. Zatížení API portálu je 30 tisíc RPS.
Technologie používané v backendu State Services
„Quadrupel“ je cílená notifikační služba, pomocí které uživatel obdrží nabídku na službu v pro něj nejvhodnějším okamžiku nastavením speciálních pravidel notifikace. Hlavními požadavky při vývoji služby bylo flexibilní nastavení a adekvátní čas na rozesílání.
Jak Quadrupel působí?
Výše uvedené schéma ukazuje jedno z pravidel provozu Quadrupelu na příkladu situace s nutností výměny řidičského průkazu. Nejprve služba vyhledá uživatele, jejichž platnost vyprší za měsíc. Zobrazí se jim banner s nabídkou přijetí příslušné služby a zpráva je odeslána e-mailem. U uživatelů, kterým již vypršel termín, se banner a email změní. Po úspěšné výměně práv dostává uživatel další upozornění – s návrhem na aktualizaci údajů v identitě.
Z technického hlediska se jedná o groovy skripty, ve kterých je napsán kód. Vstupem jsou data, výstupem je pravda/nepravda, shoduje se/neodpovídá. Existuje celkem více než 50 pravidel – od určení narozenin uživatele (aktuální datum se rovná datu narození uživatele) až po složité situace. Každý den tato pravidla identifikují asi milion shod – lidí, kteří potřebují být upozorněni.
Quadrupelové oznamovací kanály
Pod kapotou Quadrupel je databáze, ve které jsou uložena uživatelská data, a tři aplikace:
- Pracovník určené k aktualizaci dat.
- Rest API sám si bannery vyzvedne a doručí do portálu a mobilní aplikace.
- Plánovač zahajuje práce na přepočítávání bannerů nebo hromadné pošty.
Pro aktualizaci dat je backend řízen událostmi. Dvě rozhraní - rest nebo JMS. Událostí je spousta, před uložením a zpracováním se agregují, aby nevznikaly zbytečné požadavky. Samotná databáze, tabulka, ve které jsou data uložena, vypadá jako úložiště klíčových hodnot - klíč uživatele a samotná hodnota: příznaky indikující přítomnost či nepřítomnost relevantních dokumentů, dobu jejich platnosti, agregované statistiky o pořadí služeb podle tohoto uživatele a tak dále.
Po uložení dat se v JMS nastaví úkol, aby se bannery okamžitě přepočítaly - to se musí ihned zobrazit na webu. Systém se spouští v noci: do JMS se v uživatelských intervalech hází úkoly, podle kterých je potřeba přepočítat pravidla. Tu zachytí zpracovatelé, kteří se na přepočtu podílejí. Poté výsledky zpracování přejdou do další fronty, která buď uloží bannery do databáze, nebo službě odešle úlohy upozornění uživatele. Proces trvá 5-7 hodin, je snadno škálovatelný díky tomu, že vždy můžete buď přidat handlery, nebo vytvořit instance s novými handlery.
Služba funguje docela dobře. Objem dat ale roste s tím, jak přibývá uživatelů. To vede ke zvýšení zátěže databáze – i s přihlédnutím k tomu, že Rest API se dívá na repliku. Druhým bodem je JMS, který, jak se ukázalo, není příliš vhodný kvůli velké spotřebě paměti. Existuje vysoké riziko přetečení fronty, které způsobí selhání JMS a zastavení zpracování. Poté je nemožné vyvolat JMS bez vymazání protokolů.
Počítá se s řešením problémů pomocí shardingu, který umožní vyrovnat zatížení databáze. Plánuje se také změna schématu ukládání dat a změna JMS na Kafka – řešení odolnější vůči chybám, které vyřeší problémy s pamětí.
Backend-as-a-Service vs. Bez serveru
Zleva doprava: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend jako služba nebo bezserverové řešení? Účastníci diskuse o tomto naléhavém problému u kulatého stolu byli:
- Ara Israelyan, CTO CTO a zakladatel Scorocode.
- Nikolay Markov, senior datový inženýr ve společnosti Aligned Research Group.
- Andrey Tomilenko, vedoucí vývojového oddělení RUVDS.
Rozhovor moderoval senior vývojář Alexander Borgart. Debaty, kterých se zúčastnili i posluchači, uvádíme ve zkrácené verzi.
— Co je ve vašem chápání Serverless?
Andrew: Jedná se o výpočetní model - Lambda funkce, která musí zpracovat data tak, aby výsledek závisel pouze na datech. Termín přišel buď od Googlu, nebo od Amazonu a jeho služby AWS Lambda. Pro poskytovatele je snazší zvládnout takovou funkci tím, že pro ni přidělí fond kapacity. Různí uživatelé mohou být nezávisle účtováni na stejných serverech.
Nicholas: Jednoduše řečeno, převádíme část naší IT infrastruktury a obchodní logiky do cloudu, na outsourcing.
Ara: Na straně vývojářů - dobrý pokus o úsporu zdrojů, na straně obchodníků - vydělat více peněz.
— Je Serverless to samé jako mikroslužby?
Nicholas: Ne, Serverless je spíše architektonická organizace. Mikroslužba je atomová jednotka nějaké logiky. Serverless je přístup, nikoli „samostatná entita“.
Ara: Funkce bez serveru může být zabalena do mikroslužby, ale tato již nebude bez serveru, přestane být funkcí Lambda. V Serverless začne funkce fungovat pouze v okamžiku, kdy je požadována.
Andrew: Liší se životností. Spustili jsme funkci Lambda a zapomněli jsme ji. Fungovalo to několik sekund a další klient může zpracovat svůj požadavek na jiném fyzickém počítači.
— Které měří lépe?
Ara: Při horizontálním škálování se funkce Lambda chovají úplně stejně jako mikroslužby.
Nicholas: Ať nastavíte jakýkoli počet replik, bude jich tolik, Serverless nemá problémy se škálováním. Vytvořil jsem sadu replik v Kubernetes, spustil „někde“ 20 instancí a vrátilo se vám 20 anonymních odkazů. Vpřed!
— Je možné napsat backend na Serverless?
Andrew: Teoreticky, ale nedává to smysl. Funkce lambda se budou spoléhat na jediné úložiště – musíme zajistit záruku. Pokud například uživatel provedl určitou transakci, při příštím kontaktu by měl vidět: transakce byla provedena, prostředky byly připsány. Všechny funkce Lambda budou při tomto hovoru blokovány. Ve skutečnosti se řada funkcí bez serveru promění v jedinou službu s jedním úzkým místem přístupu k databázi.
— V jakých situacích má smysl používat architekturu bez serveru?
Andrew: Úkoly, které nevyžadují sdílené úložiště – stejná těžba, blockchain. Kde musíte hodně počítat. Pokud máte velký výpočetní výkon, pak můžete definovat funkci jako „vypočítejte tam hash něčeho...“ Ale problém s ukládáním dat můžete vyřešit tím, že vezmete například funkce Lambda od Amazonu a jejich distribuované úložiště . A ukazuje se, že píšete běžnou službu. Funkce lambda budou přistupovat k úložišti a poskytovat uživateli určitou odpověď.
Nicholas: Kontejnery, které běží v Serverless, mají extrémně omezené zdroje. Je málo paměti a všeho ostatního. Pokud je ale celá vaše infrastruktura nasazena výhradně na nějakém cloudu – Google, Amazon – a máte s nimi trvalou smlouvu, je na to všechno rozpočet, pak pro některé úkoly můžete použít Serverless kontejnery. Je nutné být uvnitř této infrastruktury, protože vše je přizpůsobeno pro použití v konkrétním prostředí. To znamená, že pokud jste připraveni spojit vše s cloudovou infrastrukturou, můžete experimentovat. Výhodou je, že tuto infrastrukturu nemusíte spravovat.
Ara: Skutečnost, že Serverless nevyžaduje, abyste spravovali Kubernetes, Docker, instalovali Kafka a tak dále, je sebeklam. Instalují to stejný Amazon a Google. Další věc je, že máte SLA. Můžete také vše zadávat externě, než to kódovat sami.
Andrew: Serverless sám o sobě je levný, ale za jiné služby Amazonu – například za databázi, musíte hodně platit. Lidé je už zažalovali, protože si účtovali šílené peníze za API bránu.
Ara: Pokud mluvíme o penězích, pak musíte vzít v úvahu tento bod: budete muset otočit celou metodiku vývoje ve společnosti o 180 stupňů, abyste přenesli veškerý kód na Serverless. To bude vyžadovat spoustu času a peněz.
— Existují nějaké důstojné alternativy k placeným Serverless od Amazonu a Google?
Nicholas: V Kubernetes spustíte nějakou úlohu, spustí se a zanikne – to je z architektonického hlediska docela bez serveru. Pokud chcete vytvořit opravdu zajímavou obchodní logiku s frontami a databázemi, musíte se nad tím trochu více zamyslet. To vše lze vyřešit, aniž byste opustili Kubernetes. Neobtěžoval bych se protahovat další implementaci.
— Jak důležité je sledovat, co se děje v Serverless?
Ara: Závisí na architektuře systému a obchodních požadavcích. Poskytovatel musí v zásadě poskytovat hlášení, které týmu devops pomůže pochopit možné problémy.
Nicholas: Amazon má CloudWatch, kde jsou streamovány všechny logy, včetně těch z Lambda. Integrujte předávání protokolů a používejte samostatný nástroj pro prohlížení, upozornění a tak dále. Agenty můžete nacpat do kontejnerů, které začnete.
- Pojďme si to shrnout.
Andrew: Přemýšlení o funkcích Lambda je užitečné. Pokud si sami vytvoříte službu – ne mikroslužbu, ale takovou, která zapíše požadavek, přistoupí k databázi a odešle odpověď – funkce Lambda řeší řadu problémů: s multithreadingem, škálovatelností a tak dále. Pokud je vaše logika postavena tímto způsobem, pak v budoucnu budete moci přenést tyto Lambdy do mikroslužeb nebo používat služby třetích stran, jako je Amazon. Technologie je užitečná, nápad je zajímavý. Jak je to oprávněné pro podnikání, je stále otevřenou otázkou.
Nikolay: Serverless se lépe používá pro provozní úlohy než pro výpočet nějaké obchodní logiky. Vždy to považuji za zpracování událostí. Pokud to máte v Amazonu, pokud jste v Kubernetes, ano. V opačném případě budete muset vynaložit poměrně velké úsilí, abyste Serverless uvedli do provozu sami. Je potřeba se podívat na konkrétní obchodní případ. Jeden z mých úkolů teď například zní: když se na disku objeví soubory v určitém formátu, musím je nahrát do Kafky. Mohu použít WatchDog nebo Lambda. Z logického hlediska jsou vhodné obě možnosti, ale z hlediska implementace je Serverless složitější a já preferuji ten jednodušší způsob, bez Lambdy.
Ara: Serverless je zajímavý, použitelný a technicky velmi krásný nápad. Dříve nebo později technologie dosáhne bodu, kdy bude jakákoli funkce spuštěna za méně než 100 milisekund. Pak v zásadě nebude sporu o tom, zda je čekací doba pro uživatele kritická. Použitelnost Serverless, jak již řekli kolegové, přitom zcela závisí na obchodním problému.
Děkujeme našim sponzorům, kteří nám velmi pomohli:
- IT konferenční prostor «» pro web konference.
- Kalendář IT akcí a zveřejnění"» pro informační podporu a novinky.
- «„za dárky.
- pro spolutvoření.
- "Asociace pro elektronické komunikace" za vaši účast a zkušenosti.
- Hlavní sponzor - pro všechny!
Zdroj: www.habr.com