Konferencia Habr nie je debutový príbeh. Predtým sme robili dosť veľké Toaster eventy pre 300-400 ľudí, no teraz sme sa rozhodli, že relevantné budú malé tematické stretnutia, ktorých smer si môžete nastaviť napríklad v komentároch. Prvá konferencia tohto formátu sa konala v júli a bola venovaná vývoju backendu. Účastníci si vypočuli správy o vlastnostiach prechodu z backendu na ML a o dizajne služby Quadrupel na portáli Štátnych služieb a zúčastnili sa aj okrúhleho stola venovaného Serverless. Pre tých, ktorí sa podujatia nemohli zúčastniť osobne, v tomto príspevku prezradíme to najzaujímavejšie.
Od vývoja backendu po strojové učenie
Čo robia dátoví inžinieri v ML? V čom sú úlohy backend developera a ML inžiniera podobné a odlišné? Akou cestou sa musíte vydať, aby ste zmenili svoje prvé povolanie na druhé? Povedal to Alexander Parinov, ktorý sa po 10 rokoch práce na backende dal na strojové učenie.
Alexander Parinov
Dnes Alexander pracuje ako architekt systémov počítačového videnia v X5 Retail Group a prispieva do Open Source projektov týkajúcich sa počítačového videnia a hlbokého učenia (github.com/creafz). Jeho schopnosti potvrdzuje aj jeho účasť v prvej stovke svetového rebríčka Kaggle Master (kaggle.com/creafz), najpopulárnejšej platformy pre súťaže strojového učenia.
Prečo prejsť na strojové učenie
Pred rokom a pol Jeff Dean, vedúci Google Brain, výskumného projektu umelej inteligencie založeného na hlbokom učení od Googlu, opísal, ako pol milióna riadkov kódu v Google Translate nahradila neurónová sieť Tensor Flow pozostávajúca len z 500 riadkov. Po natrénovaní siete sa zvýšila kvalita dát a zjednodušila sa infraštruktúra. Zdalo by sa, že toto je naša svetlá budúcnosť: už nemusíme písať kód, stačí vytvoriť neuróny a naplniť ich údajmi. Ale v praxi je všetko oveľa komplikovanejšie.
Infraštruktúra ML v spoločnosti Google
Neurónové siete sú len malou časťou infraštruktúry (malý čierny štvorec na obrázku vyššie). Na príjem údajov, ich spracovanie, ukladanie, kontrolu kvality atď. je potrebných oveľa viac pomocných systémov, potrebujeme infraštruktúru na školenie, nasadenie kódu strojového učenia vo výrobe a testovanie tohto kódu. Všetky tieto úlohy sú presne podobné tým, čo robia vývojári backendu.
Proces strojového učenia
Aký je rozdiel medzi ML a backendom?
V klasickom programovaní píšeme kód a ten určuje správanie programu. V ML máme malý kód modelu a veľa údajov, ktoré hodíme na model. Údaje v ML sú veľmi dôležité: ten istý model natrénovaný na rôznych údajoch môže ukázať úplne odlišné výsledky. Problémom je, že dáta sú takmer vždy roztrúsené a uložené v rôznych systémoch (relačné databázy, NoSQL databázy, protokoly, súbory).
Verzia údajov
ML vyžaduje verzovanie nielen kódu, ako pri klasickom vývoji, ale aj údajov: je potrebné jasne pochopiť, na čo bol model trénovaný. Na tento účel môžete použiť populárnu knižnicu Data Science Version Control (dvc.org).
Označenie údajov
Ďalšou úlohou je označovanie údajov. Označte napríklad všetky predmety na obrázku alebo povedzte, do ktorej triedy patrí. Robia to špeciálne služby ako Yandex.Toloka, práca s ktorou je výrazne zjednodušená prítomnosťou API. Ťažkosti vznikajú v dôsledku „ľudského faktora“: môžete zlepšiť kvalitu údajov a znížiť chyby na minimum tým, že tú istú úlohu zveríte niekoľkým účinkujúcim.
Vizualizácia v Tensor Board
Protokolovanie experimentov je potrebné na porovnanie výsledkov a výber najlepšieho modelu na základe niektorých metrík. Existuje veľká sada nástrojov na vizualizáciu – napríklad Tensor Board. Neexistujú však žiadne ideálne spôsoby ukladania experimentov. Malé spoločnosti si často vystačia s tabuľkou Excel, zatiaľ čo veľké spoločnosti využívajú špeciálne platformy na ukladanie výsledkov do databázy.
Existuje mnoho platforiem pre strojové učenie, no žiadna nepokrýva 70 % potrieb
Prvý problém, s ktorým sa človek musí stretnúť pri uvádzaní natrénovaného modelu do výroby, súvisí s obľúbeným nástrojom dátových vedcov – Jupyter Notebookom. Nie je v tom žiadna modularita, to znamená, že výstupom je taká „podrážka“ kódu, ktorá nie je rozdelená na logické časti - moduly. Všetko je pomiešané: triedy, funkcie, konfigurácie atď. Tento kód sa ťažko verzuje a testuje.
Ako sa s tým vysporiadať? Môžete dať výpoveď ako Netflix a vytvoriť si vlastnú platformu, ktorá vám umožní spustiť tieto notebooky priamo vo výrobe, preniesť do nich dáta ako vstup a získať výsledky. Môžete prinútiť vývojárov, ktorí zavádzajú model do výroby, aby normálne prepísali kód, rozdelili ho na moduly. Ale s týmto prístupom je ľahké urobiť chybu a model nebude fungovať podľa plánu. Ideálnou možnosťou je preto zakázať používanie notebooku Jupyter pre kód modelu. Ak s tým, samozrejme, dátoví vedci súhlasia.
Model ako čierna skrinka
Najjednoduchší spôsob, ako dostať model do výroby, je použiť ho ako čiernu skrinku. Máte nejakú triedu modelu, dostali ste váhy modelu (parametre neurónov trénovanej siete) a ak túto triedu inicializujete (zavoláte metódu predikcie, nakreslíte jej obrázok), dostanete určitú predikcia ako výstup. Čo sa deje vo vnútri, nie je dôležité.
Oddeľte proces servera od modelu
Môžete tiež vyvolať určitý samostatný proces a odoslať ho cez front RPC (s obrázkami alebo inými zdrojovými údajmi. Na výstupe dostaneme predpovede.
Príklad použitia modelu vo 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émom tohto prístupu je obmedzenie výkonu. Povedzme, že máme kód Phyton napísaný dátovými vedcami, ktorý je pomalý a chceme vytlačiť maximálny výkon. Na tento účel môžete použiť nástroje, ktoré konvertujú kód na natívny alebo ho prevedú do iného rámca prispôsobeného na výrobu. Takéto nástroje existujú pre každý rámec, ale neexistujú žiadne ideálne; budete ich musieť pridať sami.
Infraštruktúra v ML je rovnaká ako v bežnom backende. Existujú Docker a Kubernetes, iba pre Docker musíte nainštalovať runtime od NVIDIA, čo umožňuje procesom vo vnútri kontajnera pristupovať k grafickým kartám v hostiteľovi. Kubernetes potrebuje doplnok, aby mohol spravovať servery s grafickými kartami.
Na rozdiel od klasického programovania je v prípade ML v infraštruktúre veľa rôznych pohyblivých prvkov, ktoré je potrebné kontrolovať a testovať – napríklad kód na spracovanie dát, modelový tréningový kanál a produkciu (pozri diagram vyššie). Je dôležité otestovať kód, ktorý spája rôzne časti potrubí: existuje veľa častí a problémy sa veľmi často vyskytujú na hraniciach modulov.
Ako funguje AutoML
Služby AutoML sľubujú vybrať optimálny model pre vaše účely a trénovať ho. Musíte však pochopiť: údaje sú v ML veľmi dôležité, výsledok závisí od ich prípravy. Značenie robia ľudia, čo je plné chýb. Bez prísnej kontroly môže byť výsledkom odpad a proces zatiaľ nie je možné automatizovať, je potrebné overenie odborníkmi – dátovými vedcami. Tu sa AutoML rozpadá. Ale môže to byť užitočné pri výbere architektúry – keď už máte pripravené dáta a chcete spustiť sériu experimentov, aby ste našli najlepší model.
Ako sa dostať do strojového učenia
Najjednoduchší spôsob, ako sa dostať do ML, je vyvíjať v Pythone, ktorý sa používa vo všetkých rámcoch hlbokého učenia (a bežných rámcoch). Tento jazyk je pre túto oblasť činnosti prakticky povinný. C++ sa používa pre niektoré úlohy počítačového videnia, napríklad v riadiacich systémoch pre samoriadiace autá. JavaScript a Shell – na vizualizáciu a také zvláštne veci, ako je spustenie neurónu v prehliadači. Java a Scala sa používajú pri práci s veľkými dátami a na strojové učenie. R a Juliu milujú ľudia, ktorí študujú matematické štatistiky.
Najpohodlnejší spôsob, ako získať praktické skúsenosti na začiatok, je na Kaggle; účasť v jednej zo súťaží platformy poskytuje viac ako rok štúdia teórie. Na tejto platforme môžete vziať niekoho iného uverejnený a komentovaný kód a pokúsiť sa ho vylepšiť, optimalizovať pre vaše účely. Bonus – vaša hodnosť Kaggle ovplyvňuje váš plat.
Ďalšou možnosťou je pripojiť sa k tímu ML ako backend developer. Existuje mnoho startupov so strojovým učením, kde môžete získať skúsenosti tým, že pomôžete svojim kolegom vyriešiť ich problémy. Nakoniec sa môžete pripojiť k jednej z komunít dátových vedcov – Open Data Science (ods.ai) a ďalším.
Rečník zverejnil ďalšie informácie k téme na odkaze
"Quadrupel" - služba cielených upozornení portálu "Služby štátu"
Jevgenij Smirnov
Ďalším rečníkom bol vedúci oddelenia rozvoja infraštruktúry elektronickej verejnej správy Evgeny Smirnov, ktorý hovoril o Quadruple. Toto je cielená oznamovacia služba pre portál Gosuslugi (gosuslugi.ru), najnavštevovanejší vládny zdroj na Runete. Denná návštevnosť je 2,6 milióna, celkovo je na stránke 90 miliónov registrovaných používateľov, z toho 60 miliónov je potvrdených. Zaťaženie API portálu je 30 tisíc RPS.
Technológie používané v backende štátnych služieb
„Quadrupel“ je cielená notifikačná služba, pomocou ktorej užívateľ dostane ponuku na službu v pre neho najvhodnejšom momente nastavením špeciálnych pravidiel notifikácie. Hlavnými požiadavkami pri vývoji služby boli flexibilné nastavenia a dostatočný čas na rozosielanie.
Akým spôsobom Quadrupel účinkuje?
Vyššie uvedený diagram ukazuje jedno z pravidiel prevádzky štvorkolky na príklade situácie s potrebou výmeny vodičského preukazu. Po prvé, služba hľadá používateľov, ktorých dátum vypršania platnosti vyprší o mesiac. Zobrazí sa im banner s ponukou na získanie príslušnej služby a správa sa odošle e-mailom. Pre tých používateľov, ktorým termín už vypršal, sa banner a email zmenia. Po úspešnej výmene práv dostáva používateľ ďalšie upozornenia – s návrhom na aktualizáciu údajov v identite.
Z technického hľadiska ide o groovy skripty, v ktorých je napísaný kód. Vstup sú údaje, výstup je pravda/nepravda, zhoduje sa/nezhoduje sa. Celkovo existuje viac ako 50 pravidiel - od určenia dátumu narodenia používateľa (aktuálny dátum sa rovná dátumu narodenia používateľa) až po zložité situácie. Každý deň tieto pravidlá identifikujú asi milión zhôd – ľudí, ktorí musia byť upozornení.
Štvornásobné oznamovacie kanály
Pod kapotou Quadrupel sa nachádza databáza, v ktorej sú uložené používateľské dáta, a tri aplikácie:
- Pracovník určené na aktualizáciu údajov.
- Rest API vyzdvihne a doručí samotné bannery na portál a mobilnú aplikáciu.
- Scheduler spúšťa práce na prepočítavaní bannerov či hromadnej korešpondencie.
Na aktualizáciu údajov je backend riadený udalosťami. Dve rozhrania – rest alebo JMS. Udalostí je veľa, pred uložením a spracovaním sú agregované, aby nevznikali zbytočné požiadavky. Samotná databáza, tabuľka, v ktorej sú dáta uložené, vyzerá ako úložisko kľúčových hodnôt – kľúč používateľa a samotná hodnota: príznaky označujúce prítomnosť alebo absenciu relevantných dokumentov, dobu ich platnosti, agregované štatistiky o poradí služieb podľa tohto používateľa atď.
Po uložení údajov sa v JMS nastaví úloha, aby sa bannery okamžite prepočítali - to je potrebné okamžite zobraziť na webe. Systém sa spustí v noci: úlohy sa do JMS hádžu v používateľských intervaloch, podľa ktorých je potrebné prepočítať pravidlá. Tú vyzdvihnú spracovatelia zapojení do prepočtu. Potom výsledky spracovania prejdú do ďalšieho frontu, ktorý buď uloží bannery do databázy, alebo odošle do služby úlohy upozornení používateľov. Proces trvá 5-7 hodín, je ľahko škálovateľný vďaka tomu, že vždy môžete buď pridať obslužné nástroje, alebo vytvoriť inštancie s novými obslužnými nástrojmi.
Služba funguje celkom dobre. Objem dát však rastie, keďže pribúda používateľov. To vedie k zvýšeniu zaťaženia databázy – aj keď vezmeme do úvahy skutočnosť, že Rest API sa pozerá na repliku. Druhým bodom je JMS, ktorý, ako sa ukázalo, nie je príliš vhodný kvôli veľkej spotrebe pamäte. Existuje vysoké riziko pretečenia frontu, ktoré spôsobí zlyhanie JMS a zastavenie spracovania. Potom nie je možné vyvolať JMS bez vymazania protokolov.
Problémy sa plánuje riešiť pomocou shardingu, ktorý umožní vyrovnávať zaťaženie databázy. Plánuje sa aj zmena schémy ukladania údajov a zmena JMS na Kafka – riešenie odolnejšie voči chybám, ktoré vyrieši problémy s pamäťou.
Backend-as-a-Service vs. Bez servera
Zľava doprava: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend ako služba alebo bezserverové riešenie? Účastníkmi diskusie o tejto naliehavej otázke pri okrúhlom stole boli:
- Ara Israelyan, CTO CTO a zakladateľ spoločnosti Scorocode.
- Nikolay Markov, hlavný dátový inžinier v Aligned Research Group.
- Andrey Tomilenko, vedúci oddelenia vývoja RUVDS.
Rozhovor moderoval senior developer Alexander Borgart. Debaty, do ktorých sa zapojili aj poslucháči, uvádzame v skrátenej verzii.
— Čo je podľa vás Serverless?
Andrew: Ide o výpočtový model – Lambda funkcia, ktorá musí spracovať dáta tak, aby výsledok závisel len od dát. Termín prišiel buď od Google, alebo od Amazonu a jeho služby AWS Lambda. Pre poskytovateľa je jednoduchšie zvládnuť takúto funkciu tak, že jej pridelí skupinu kapacity. Rôzni používatelia môžu byť nezávisle účtovaní na rovnakých serveroch.
Nicholas: Zjednodušene povedané, časť našej IT infraštruktúry a obchodnej logiky presúvame do cloudu, na outsourcing.
Macaw: Na strane vývojárov - dobrý pokus o šetrenie zdrojov, na strane obchodníkov - zarobiť viac peňazí.
— Je Serverless to isté ako mikroslužby?
Nicholas: Nie, Serverless je skôr architektonickou organizáciou. Mikroslužba je atómová jednotka nejakej logiky. Serverless je prístup, nie „samostatná entita“.
Macaw: Funkcia bez servera môže byť zabalená do mikroslužby, ale táto už nebude bez servera, prestane byť funkciou Lambda. V Serverless funkcia začne fungovať až v momente, keď je o ňu požiadaná.
Andrew: Líšia sa životnosťou. Spustili sme funkciu Lambda a zabudli sme na ňu. Fungovalo to niekoľko sekúnd a ďalší klient môže spracovať svoju požiadavku na inom fyzickom počítači.
— Ktorá váha lepšie?
Macaw: Pri horizontálnom škálovaní sa funkcie Lambda správajú úplne rovnako ako mikroslužby.
Nicholas: Bez ohľadu na počet replík, ktoré nastavíte, bude ich toľko; Serverless nemá problémy so škálovaním. Vytvoril som sadu replík v Kubernetes, spustil „niekde“ 20 inštancií a vrátilo sa vám 20 anonymných odkazov. Vpred!
— Je možné napísať backend na Serverless?
Andrew: Teoreticky, ale nedáva to zmysel. Funkcie lambda sa budú spoliehať na jediné úložisko – musíme zabezpečiť záruku. Napríklad, ak používateľ vykonal určitú transakciu, pri ďalšom kontakte by mal vidieť: transakcia bola vykonaná, prostriedky boli pripísané. Pri tomto hovore sa zablokujú všetky funkcie Lambda. V skutočnosti sa množstvo funkcií bez servera zmení na jednu službu s jedným úzkym prístupovým bodom k databáze.
— V akých situáciách má zmysel používať bezserverovú architektúru?
Andrew: Úlohy, ktoré nevyžadujú zdieľané úložisko – rovnaká ťažba, blockchain. Kde musíte veľa počítať. Ak máš veľký výpočtový výkon, tak si môžeš definovať funkciu ako “vypočítaj tam hash niečoho...” Ale problém s ukladaním dát môžeš vyriešiť tak, že vezmeš napríklad Lambda funkcie od Amazonu a ich distribuované úložisko . A ukazuje sa, že píšete bežnú službu. Funkcie Lambda budú pristupovať k úložisku a poskytnú používateľovi určitú odpoveď.
Nicholas: Kontajnery, ktoré bežia v režime Serverless, majú extrémne obmedzené zdroje. Je málo pamäte a všetkého ostatného. Ak je však celá vaša infraštruktúra nasadená výlučne v nejakom cloude – Google, Amazon – a máte s nimi trvalú zmluvu, na to všetko máte rozpočet, potom na niektoré úlohy môžete použiť kontajnery bez serverov. Je potrebné byť vo vnútri tejto infraštruktúry, pretože všetko je prispôsobené na použitie v konkrétnom prostredí. To znamená, že ak ste pripravení spojiť všetko s cloudovou infraštruktúrou, môžete experimentovať. Výhodou je, že túto infraštruktúru nemusíte spravovať.
Macaw: Skutočnosť, že Serverless nevyžaduje, aby ste spravovali Kubernetes, Docker, inštalovali Kafka a tak ďalej, je sebaklam. Inštaluje to ten istý Amazon a Google. Ďalšia vec je, že máte SLA. Môžete tiež všetko outsourcovať namiesto toho, aby ste to sami kódovali.
Andrew: Serverless je sám o sebe lacný, ale za iné služby Amazonu – napríklad za databázu, musíte veľa zaplatiť. Ľudia ich už zažalovali, pretože si za API bránu účtovali šialené peniaze.
Macaw: Ak hovoríme o peniazoch, potom musíte vziať do úvahy tento bod: budete musieť otočiť celú metodiku vývoja vo firme o 180 stupňov, aby ste preniesli celý kód do Serverless. To si vyžiada veľa času a peňazí.
— Existujú nejaké hodnotné alternatívy k plateným serverom od Amazonu a Google?
Nicholas: V Kubernetes spustíte nejaký druh úlohy, spustí sa a zanikne – z architektonického hľadiska je to celkom bez serverov. Ak chcete vytvoriť naozaj zaujímavú obchodnú logiku s frontami a databázami, musíte sa nad tým trochu viac zamyslieť. To všetko sa dá vyriešiť bez opustenia Kubernetes. Netrápil by som sa naťahovaním dodatočnej implementácie.
— Aké dôležité je sledovať, čo sa deje v Serverless?
Macaw: Závisí od architektúry systému a obchodných požiadaviek. Poskytovateľ musí v podstate poskytovať správy, ktoré pomôžu tímu vývojárov pochopiť možné problémy.
Nicholas: Amazon má CloudWatch, kde sa streamujú všetky záznamy, vrátane tých z Lambda. Integrujte preposielanie protokolov a použite samostatný nástroj na prezeranie, upozorňovanie atď. Agentov môžete napchať do nádob, ktoré začnete.
- Poďme si to zhrnúť.
Andrew: Premýšľanie o funkciách Lambda je užitočné. Ak si vytvoríte službu sami – nie mikroslužbu, ale takú, ktorá zapíše požiadavku, pristúpi k databáze a odošle odpoveď – funkcia Lambda rieši množstvo problémov: s multithreadingom, škálovateľnosťou atď. Ak je vaša logika postavená týmto spôsobom, potom v budúcnosti budete môcť preniesť tieto Lambdy do mikroslužieb alebo použiť služby tretích strán, ako je Amazon. Technológia je užitočná, nápad je zaujímavý. Nakoľko je to opodstatnené pre podnikanie, je stále otvorenou otázkou.
Nikolay: Serverless sa lepšie používa na prevádzkové úlohy ako na výpočet nejakej obchodnej logiky. Vždy to považujem za spracovanie udalostí. Ak to máte v Amazone, ak ste v Kubernetes, áno. V opačnom prípade budete musieť vynaložiť veľké úsilie na to, aby ste Serverless rozbehli sami. Je potrebné pozrieť sa na konkrétny obchodný prípad. Napríklad jedna z mojich úloh teraz je: keď sa na disku objavia súbory v určitom formáte, musím ich nahrať do Kafky. Môžem použiť WatchDog alebo Lambda. Z logického hľadiska sú vhodné obe možnosti, ale z hľadiska implementácie je Serverless komplikovanejší a ja preferujem jednoduchší spôsob, bez Lambdy.
Macaw: Serverless je zaujímavý, použiteľný a technicky veľmi krásny nápad. Skôr či neskôr sa technológia dostane do bodu, kedy bude akákoľvek funkcia spustená za menej ako 100 milisekúnd. Potom v zásade nebude otázka, či je čakacia doba pre používateľa kritická. Zároveň, ako už kolegovia povedali, použiteľnosť Serverless úplne závisí od obchodného problému.
Ďakujeme našim sponzorom, ktorí nám veľmi pomohli:
- IT konferenčný priestor «» pre stránku konferencie.
- Kalendár IT podujatí a zverejnenie"» pre informačnú podporu a novinky.
- «„za darčeky.
- pre spolutvorbu.
- "Asociácia pre elektronické komunikácie" za angažovanosť a skúsenosti.
- Hlavný sponzor - pre všetkých!
Zdroj: hab.com