De konferinsje fan Habr is gjin debútferhaal. Earder, wy holden frij grutte Toaster eveneminten foar 300-400 minsken, mar no wy besletten dat lytse tematyske gearkomsten soe wêze relevant, de rjochting wêrfan jo kinne ynstelle, bygelyks, yn 'e kommentaren. De earste konferinsje fan dit formaat waard hâlden yn july en wie wijd oan backend ûntwikkeling. Dielnimmers harken nei rapporten oer de funksjes fan 'e oergong fan' e backend nei ML en oer it ûntwerp fan 'e Quadrupel-tsjinst op' e State Services portal, en namen ek diel oan in rûne tafel wijd oan Serverless. Foar dyjingen dy't it evenemint net persoanlik koene bywenje, fertelle wy jo yn dit post de meast nijsgjirrige dingen.
Fan backendûntwikkeling oant masine learen
Wat dogge data-yngenieurs yn ML? Hoe binne de taken fan in backend-ûntwikkelder en in ML-yngenieur gelyk en oars? Hokker paad moatte jo nimme om jo earste berop te feroarjen nei jo twadde? Dit waard ferteld troch Alexander Parinov, dy't gie yn masine learen nei 10 jier fan backend wurk.
Alexander Parinov
Tsjintwurdich wurket Alexander as arsjitekt foar kompjûterfisysystemen by X5 Retail Group en draacht by oan Open Source-projekten yn ferbân mei kompjûterfisy en djip learen (github.com/creafz). Syn feardichheden wurde befêstige troch syn dielname oan 'e top 100 fan' e wrâldranglist fan Kaggle Master (kaggle.com/creafz), it populêrste platfoarm foar kompetysjes foar masine-learen.
Wêrom oerskeakelje nei masine learen
In jier en in heal lyn beskreau Jeff Dean, haad fan Google Brain, Google's ûndersyksprojekt foar djippe learen basearre op keunstmjittige yntelliginsje, hoe't in heal miljoen rigels koade yn Google Translate ferfongen waarden troch in Tensor Flow-neuraal netwurk besteande út mar 500 rigels. Nei it oplieden fan it netwurk gie de kwaliteit fan de gegevens ta en waard de ynfrastruktuer ienfâldiger. It liket derop dat dit ús ljochte takomst is: wy moatte net langer koade skriuwe, it is genôch om neuroanen te meitsjen en se te foljen mei gegevens. Mar yn 'e praktyk is alles folle yngewikkelder.
ML-ynfrastruktuer by Google
Neurale netwurken binne mar in lyts part fan 'e ynfrastruktuer (it lytse swarte fjouwerkant yn' e foto hjirboppe). In protte mear helpsystemen binne ferplicht om gegevens te ûntfangen, te ferwurkjen, op te slaan, kwaliteit te kontrolearjen, ensfh., Wy hawwe ynfrastruktuer nedich foar training, ynset fan masine-learkoade yn produksje, en testen fan dizze koade. Al dizze taken binne krekt gelyk oan wat backend-ûntwikkelders dogge.
Masine learproses
Wat is it ferskil tusken ML en backend?
Yn klassike programmearring skriuwe wy koade en dit diktearret it gedrach fan it programma. Yn ML hawwe wy in lyts modelkoade en in protte gegevens dy't wy nei it model smite. Gegevens yn ML binne heul wichtich: itselde model oplaat op ferskate gegevens kin folslein oare resultaten sjen litte. It probleem is dat de gegevens hast altyd ferspraat en opslein binne yn ferskate systemen (relasjonele databases, NoSQL-databases, logs, bestannen).
Data ferzje
ML fereasket ferzje fan net allinich de koade, lykas yn klassike ûntwikkeling, mar ek de gegevens: it is needsaaklik om dúdlik te begripen wêrop it model is oplaat. Om dit te dwaan, kinne jo gebrûk meitsje fan de populêre Data Science Version Control bibleteek (dvc.org).
Data markup
De folgjende taak is gegevenslabeling. Markearje bygelyks alle objekten yn 'e foto of sis by hokker klasse it heart. Dit wurdt dien troch spesjale tsjinsten lykas Yandex.Toloka, wêrmei't it wurk sterk ferienfâldige wurdt troch de oanwêzigens fan in API. Swierrichheden ûntsteane troch de "minsklike faktor": jo kinne de kwaliteit fan gegevens ferbetterje en flaters oant in minimum ferminderje troch deselde taak oan ferskate artysten te fertrouwen.
Fisualisaasje yn Tensor Board
Logging fan eksperiminten is nedich om resultaten te fergelykjen en it bêste model te selektearjen basearre op guon metriken. D'r is in grutte set ark foar fisualisaasje - bygelyks Tensor Board. Mar d'r binne gjin ideale manieren om eksperiminten op te slaan. Lytse bedriuwen dogge it faaks mei in Excel-spreadsheet, wylst grutte bedriuwen spesjale platfoarms brûke foar it bewarjen fan resultaten yn in databank.
D'r binne in protte platfoarms foar masine learen, mar gjinien fan har dekt 70% fan 'e behoeften
It earste probleem dat men te krijen hat by it ynstellen fan in oplaat model yn produksje is relatearre oan it favorite ark fan gegevenswittenskippers - Jupyter Notebook. D'r is gjin modulariteit yn, dat is, de útfier is sa'n "fuotdoek" fan koade dy't net ferdield is yn logyske stikken - modules. Alles wurdt trochinoar mingd: klassen, funksjes, konfiguraasjes, ensfh Dizze koade is dreech om te ferzje en te testen.
Hoe om te gean mei dit? Jo kinne josels ûntslach, lykas Netflix, en jo eigen platfoarm meitsje wêrmei jo dizze laptops direkt yn produksje kinne lansearje, gegevens nei har oerdrage as ynfier en resultaten krije. Jo kinne de ûntwikkelders twinge dy't it model yn produksje rôlje om de koade normaal te herskriuwen, it yn modules te brekken. Mar mei dizze oanpak is it maklik om in flater te meitsjen, en it model sil net wurkje as bedoeld. Dêrom is de ideale opsje om it gebrûk fan Jupyter Notebook foar modelkoade te ferbieden. As, fansels, de gegevens wittenskippers akkoard mei dit.
Model as in swarte doaze
De maklikste manier om in model yn produksje te krijen is it te brûken as in swarte doaze. Jo hawwe in soarte fan modelklasse, jo krigen de gewichten fan it model (parameters fan 'e neuroanen fan it trained netwurk), en as jo dizze klasse inisjalisearje (neam de foarsizzingsmetoade, fiede it in foto), krije jo in bepaalde foarsizzing as útfier. Wat der binnen bart makket neat út.
Separate tsjinner proses mei model
Jo kinne ek in bepaald apart proses ferheegje en it fia in RPC-wachtrige stjoere (mei foto's of oare boarnegegevens. By de útfier krije wy foarsizzingen.
In foarbyld fan it brûken fan in model yn Flask:
@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)
It probleem mei dizze oanpak is de beheining fan prestaasjes. Litte wy sizze dat wy Phyton-koade hawwe skreaun troch gegevenswittenskippers dy't stadich is, en wy wolle maksimale prestaasjes útdrukke. Om dit te dwaan, kinne jo ark brûke dy't de koade konvertearje yn native of omsette yn in oar ramt oanpast foar produksje. D'r binne sokke ark foar elk ramt, mar d'r binne gjin ideale; jo moatte se sels tafoegje.
De ynfrastruktuer yn ML is itselde as yn in gewoane backend. D'r binne Docker en Kubernetes, allinich foar Docker moatte jo runtime fan NVIDIA ynstallearje, wêrtroch prosessen binnen de kontener tagong krije ta fideokaarten yn 'e host. Kubernetes hat in plugin nedich sadat it servers mei fideokaarten beheare kin.
Oars as klassike programmearring, binne d'r yn it gefal fan ML in protte ferskillende bewegende eleminten yn 'e ynfrastruktuer dy't moatte wurde kontrolearre en hifke - bygelyks gegevensferwurkingskoade, modeltrainingpipeline en produksje (sjoch diagram hjirboppe). It is wichtich om de koade te testen dy't ferskate stikken pipelines ferbynt: d'r binne in protte stikken, en problemen ûntsteane faak by modulegrinzen.
Hoe AutoML wurket
AutoML-tsjinsten tasizze it optimale model foar jo doelen te selektearjen en it te trenen. Mar jo moatte begripe: gegevens binne heul wichtich yn ML, it resultaat hinget ôf fan har tarieding. Markup wurdt dien troch minsken, dat is fol mei flaters. Sûnder strikte kontrôle kin it resultaat jiskefet wêze, en it is noch net mooglik om it proses te automatisearjen; ferifikaasje troch spesjalisten - gegevenswittenskippers - is nedich. Dit is wêr't AutoML brekt. Mar it kin nuttich wêze foar it selektearjen fan in arsjitektuer - as jo de gegevens al taret hawwe en in searje eksperiminten wolle útfiere om it bêste model te finen.
Hoe kinne jo yn masine learen komme
De maklikste manier om yn ML te kommen is as jo ûntwikkelje yn Python, dat wurdt brûkt yn alle djippe learkaders (en reguliere kaders). Dizze taal is praktysk ferplicht foar dit aktiviteitsfjild. C ++ wurdt brûkt foar guon kompjûter fyzje taken, Bygelyks, yn kontrôle systemen foar selsridende auto. JavaScript en Shell - foar fisualisaasje en sokke frjemde dingen as it útfieren fan in neuron yn 'e browser. Java en Scala wurde brûkt by it wurkjen mei Big Data en foar masine learen. R en Julia wurde leafst troch minsken dy't wiskundige statistiken studearje.
De maklikste manier om praktyske ûnderfining te krijen om te begjinnen is op Kaggle; dielname oan ien fan 'e kompetysjes fan it platfoarm jout mear as in jier teory te studearjen. Op dit platfoarm kinne jo de pleatste en kommentearre koade fan in oar nimme en besykje it te ferbetterjen, te optimalisearjen foar jo doelen. Bonus - jo Kaggle-rang hat ynfloed op jo salaris.
In oare opsje is om mei te dwaan oan it ML-team as in backend-ûntwikkelder. D'r binne in protte startups foar masine-learen wêr't jo ûnderfining kinne ophelje troch jo kollega's te helpen har problemen op te lossen. Uteinlik kinne jo meidwaan oan ien fan 'e mienskippen foar gegevenswittenskippers - Open Data Science (ods.ai) en oaren.
De sprekker pleatste oanfoljende ynformaasje oer it ûnderwerp op 'e keppeling
"Quadrupel" - in tsjinst fan doelbewuste notifikaasjes fan it portaal "State Services"
Evgeny Smirnov
De folgjende sprekker wie it haad fan 'e ôfdieling foar ûntwikkeling fan e-regearing ynfrastruktuer, Evgeny Smirnov, dy't spruts oer Quadruple. Dit is in rjochte notifikaasjetsjinst foar it Gosuslugi-portaal (gosuslugi.ru), de meast besochte regearingsboarne op 'e Runet. It deistige publyk is 2,6 miljoen, yn totaal binne d'r 90 miljoen registrearre brûkers op 'e side, wêrfan 60 miljoen binne befêstige. De lading op de portal API is 30 tûzen RPS.
Technologies brûkt yn 'e efterkant fan State Services
"Quadrupel" is in rjochte notifikaasjetsjinst, wêrmei't de brûker op it foar him geskikte momint in oanbod foar in tsjinst krijt troch spesjale notifikaasjeregels op te stellen. De wichtichste easken by it ûntwikkeljen fan de tsjinst wiene fleksibele ynstellings en genôch tiid foar mailings.
Hoe wurket Quadrupel?
It diagram hjirboppe toant ien fan 'e regels fan' e operaasje fan 'e Quadrupel mei it foarbyld fan in situaasje mei de needsaak om in rydbewiis te ferfangen. Earst siket de tsjinst brûkers wêrfan de ferfaldatum oer in moanne ferrint. Se krije in banner te sjen mei in oanbod om de passende tsjinst te ûntfangen en in berjocht wurdt per e-post ferstjoerd. Foar dy brûkers waans deadline al ferrûn is, feroarje de banner en e-post. Nei in suksesfolle útwikseling fan rjochten krijt de brûker oare notifikaasjes - mei in foarstel om de gegevens yn 'e identiteit te aktualisearjen.
Ut in technysk eachpunt, dit binne groovy skripts dêr't de koade is skreaun. De ynfier is gegevens, de útfier is wier / falsk, matched / kaam net oerien. D'r binne yn totaal mear dan 50 regels - fan it bepalen fan 'e jierdei fan' e brûker (de hjoeddeistige datum is lyk oan de bertedatum fan 'e brûker) oant komplekse situaasjes. Elke dei identifisearje dizze regels sawat in miljoen wedstriden - minsken dy't op 'e hichte moatte wurde.
Quadrupel notifikaasje kanalen
Under de motorkap fan Quadrupel is d'r in databank wêryn brûkersgegevens wurde opslein, en trije applikaasjes:
- Wurkster bedoeld foar it bywurkjen fan gegevens.
- Rest API pakt en leveret de banners sels oan it portaal en de mobile applikaasje.
- Planner lansearret wurk oan it opnij berekkenjen fan banners as massamailings.
Om gegevens te aktualisearjen, is de backend evenemint-oandreaune. Twa ynterfaces - rest of JMS. D'r binne in protte eveneminten; foardat se opslaan en ferwurkje, wurde se aggregearre om gjin unnedige oanfragen te meitsjen. De databank sels, de tabel wêryn de gegevens wurde opslein, liket op in kaaiweardewinkel - de kaai fan 'e brûker en de wearde sels: flaggen dy't de oanwêzigens of ôfwêzigens fan relevante dokuminten oanjaan, har jildigensperioade, aggregearre statistiken oer de folchoarder fan tsjinsten troch dizze brûker, ensafuorthinne.
Nei it bewarjen fan de gegevens wurdt in taak yn JMS ynsteld, sadat de banners daliks opnij berekkene wurde - dit moat fuortendaliks op it web werjûn wurde. It systeem begjint nachts: taken wurde yn JMS smiten mei brûkersyntervallen, wêrnei't de regels opnij berekkene wurde moatte. Dit wurdt oppakt troch de ferwurkers dy't belutsen binne by de werberekkening. Folgjende geane de ferwurkingsresultaten nei de folgjende wachtrige, dy't de banners yn 'e databank bewarret of brûkersnotifikaasjetaken nei de tsjinst stjoert. It proses duorret 5-7 oeren, it is maklik scalable fanwege it feit dat jo kinne altyd of foegjen handlers of raise eksimplaren mei nije handlers.
De tsjinst wurket frij goed. Mar it folume fan gegevens groeit as d'r mear brûkers binne. Dit liedt ta in ferheging fan 'e lading op' e database - sels mei rekkening mei it feit dat de Rest API nei de replika sjocht. It twadde punt is JMS, dat, sa die bliken, is net hiel geskikt fanwege syn hege ûnthâld konsumpsje. D'r is in heech risiko fan wachtrige oerstreaming wêrtroch JMS crasht en ferwurking stopet. It is ûnmooglik om JMS nei dit te ferheegjen sûnder de logs te wiskjen.
It is pland om de problemen op te lossen mei help fan sharding, wêrtroch de lading op 'e databank balansearje sil. D'r binne ek plannen om it gegevensopslachskema te feroarjen, en JMS te feroarjen nei Kafka - in mear fouttolerante oplossing dy't ûnthâldproblemen sil oplosse.
Backend-as-a-Service vs. Tsjinnerleas
Fan lofts nei rjochts: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend as in tsjinst as Serverless oplossing? Dielnimmers oan de diskusje oer dit driuwende probleem oan de rûne tafel wiene:
- Ara Israelyan, CTO CTO en oprjochter fan Scorocode.
- Nikolay Markov, Senior Data Engineer by Aligned Research Group.
- Andrey Tomilenko, haad fan 'e RUVDS-ûntwikkelingsôfdieling.
It petear waard moderearre troch senior ûntwikkelder Alexander Borgart. Wy presintearje de debatten dêr't de harkers ek oan meidien hawwe yn in ôfkoarte ferzje.
- Wat is Serverless yn jo begryp?
Andrei: Dit is in kompjûtermodel - in Lambda-funksje dy't gegevens ferwurkje moat sadat it resultaat allinich hinget fan 'e gegevens. De term kaam of fan Google as fan Amazon en har AWS Lambda-tsjinst. It is makliker foar in oanbieder om sa'n funksje te behanneljen troch dêr in poel oan kapasiteit foar te takennen. Ferskillende brûkers kinne ûnôfhinklik wurde rekkene op deselde servers.
Nikolai: Om it gewoan te sizzen, drage wy in diel fan ús IT-ynfrastruktuer en bedriuwslogika oer nei de wolk, nei útbesteging.
Ara: Fan 'e kant fan ûntwikkelders - in goede besykjen om boarnen te besparjen, fan' e kant fan marketeers - om mear jild te fertsjinjen.
- Is Serverless itselde as mikrotsjinsten?
Nikolai: Nee, Serverless is mear in arsjitektuerorganisaasje. In mikrotsjinst is in atoomienheid fan guon logika. Serverless is in oanpak, net in "aparte entiteit."
Ara: In Serverless funksje kin wurde ferpakt yn in mikroservice, mar dit sil net langer wêze Serverless, it sil ophâlde te wêzen in Lambda funksje. Yn Serverless begjint in funksje pas te wurkjen op it momint dat it wurdt oanfrege.
Andrei: Se ferskille yn har libben. Wy lansearre de Lambda funksje en fergeat it. It wurke in pear sekonden, en de folgjende klant kin syn fersyk ferwurkje op in oare fysike masine.
- Hokker skaal better?
Ara: By it skaaljen fan horizontaal gedrage Lambda-funksjes krekt itselde as mikrotsjinsten.
Nikolai: Wat it oantal replika's jo ek ynstelle, d'r sille safolle wêze; Serverless hat gjin problemen mei skaalfergrutting. Ik makke in replika-set yn Kubernetes, lansearre 20 eksimplaren "ergens", en 20 anonime keppelings waarden weromjûn oan jo. Foarút!
- Is it mooglik om in backend te skriuwen op Serverless?
Andrei: Teoretysk, mar it makket gjin sin. Lambda-funksjes sille fertrouwe op ien inkeld repository - wy moatte garânsje garandearje. Bygelyks, as in brûker in bepaalde transaksje hat útfierd, dan moat hy de folgjende kear kontakt opnimme: de transaksje is útfierd, de fûnsen binne byskreaun. Alle Lambda funksjes sille blokkearje op dizze oprop. Yn feite sil in boskje Serverless-funksjes yn ien tsjinst feroarje mei ien knyppunt tagongspunt foar de databank.
- Yn hokker situaasjes hat it sin om serverless arsjitektuer te brûken?
Andrei: Taken dy't gjin dielde opslach nedich binne - deselde mining, blockchain. Wêr't jo in protte telle moatte dwaan. As jo in protte kompjûterkrêft hawwe, dan kinne jo in funksje definiearje lykas "berekkenje de hash fan wat dêr ..." Mar jo kinne it probleem oplosse mei gegevensopslach troch bygelyks Lambda-funksjes fan Amazon te nimmen en har ferdielde opslach . En it docht bliken dat jo in reguliere tsjinst skriuwe. Lambda-funksjes sille tagong krije ta de opslach en in soarte fan antwurd jaan oan de brûker.
Nikolai: Containers dy't rinne yn Serverless binne ekstreem beheind yn boarnen. Der is min ûnthâld en al it oare. Mar as jo heule ynfrastruktuer folslein is ynset op ien of oare wolk - Google, Amazon - en jo hawwe in permanint kontrakt mei har, is d'r in budzjet foar dit alles, dan kinne jo foar guon taken Serverless-konteners brûke. It is nedich om binnen dizze ynfrastruktuer te wêzen, om't alles is ôfstimd foar gebrûk yn in spesifike omjouwing. Dat is, as jo ree binne om alles te binen oan 'e wolkynfrastruktuer, kinne jo eksperimintearje. It foardiel is dat jo dizze ynfrastruktuer net hoege te behearjen.
Ara: It feit dat Serverless net fereasket dat jo Kubernetes, Docker beheare, Kafka ynstallearje, ensafuorthinne is selsbedrog. Deselde Amazon en Google ynstallearje dit. In oar ding is dat jo in SLA hawwe. Jo kinne likegoed alles útbesteegje ynstee fan it sels te kodearjen.
Andrei: Serverless sels is goedkeap, mar jo moatte in protte betelje foar oare Amazon-tsjinsten - bygelyks de databank. Minsken hawwe har al oanklage om't se gekke bedragen oanrekkene foar de API-poarte.
Ara: As wy oer jild prate, dan moatte jo dit punt rekkenje: jo moatte de folsleine ûntwikkelingsmetoadyk yn it bedriuw 180 graden draaie om alle koade oer te setten nei Serverless. Dit sil in protte tiid en jild nimme.
- Binne d'r weardige alternativen foar betelle Serverless fan Amazon en Google?
Nikolai: Yn Kubernetes lansearje jo in soarte fan baan, it rint en stjert - dit is frij Serverless út in arsjitektoanysk eachpunt. As jo echt ynteressante saaklike logika wolle meitsje mei wachtrigen en databases, dan moatte jo der wat mear oer tinke. Dit kin allegear wurde oplost sûnder Kubernetes te ferlitten. Ik soe net de muoite dwaan om ekstra ymplemintaasje út te slepen.
- Hoe wichtich is it om te kontrolearjen wat der bart yn Serverless?
Ara: Hinget ôf fan systeemarsjitektuer en saaklike easken. Yn essinsje moat de provider rapportaazje leverje dy't it devops-team sil helpe mooglike problemen te begripen.
Nikolai: Amazon hat CloudWatch, wêr't alle logs wurde streamd, ynklusyf dy fan Lambda. Yntegrearje trochstjoere fan logboeken en brûk in apart ark foar besjen, warskôgje, ensfh. Jo kinne aginten ynfolje yn 'e konteners dy't jo begjinne.
- Litte wy it gearfetsje.
Andrei: Tinken oer Lambda funksjes is nuttich. As jo sels in tsjinst meitsje - gjin mikrotsjinst, mar ien dy't in fersyk skriuwt, tagong ta de databank en in antwurd stjoert - lost de Lambda-funksje in oantal problemen op: mei multithreading, skalberens, ensfh. As jo logika op dizze manier boud is, dan sille jo yn 'e takomst dizze Lambda's kinne oerdrage nei mikrotsjinsten of tsjinsten fan tredden brûke lykas Amazon. De technology is nuttich, it idee is ynteressant. Hoe rjochtfeardich it is foar bedriuw is noch in iepen fraach.
Nikolay: Serverless wurdt better brûkt foar operaasjetaken dan foar it berekkenjen fan wat saaklike logika. Ik tink it altyd as evenemintferwurking. As jo it hawwe yn Amazon, as jo yn Kubernetes binne, ja. Oars moatte jo nochal wat muoite dwaan om Serverless op jo eigen en rinnend te krijen. It is needsaaklik om te sjen nei in spesifike saaklike saak. Bygelyks, ien fan myn taken is no: as bestannen yn in bepaald formaat op skiif ferskine, moat ik se uploade nei Kafka. Ik kin WatchDog of Lambda brûke. Fanút in logysk eachpunt binne beide opsjes geskikt, mar yn termen fan ymplemintaasje is Serverless komplisearre, en ik leaver de ienfâldiger manier, sûnder Lambda.
Ara: Serverless is in nijsgjirrich, tapaslik, en hiel technysk moai idee. Ier of letter sil technology it punt berikke wêr't elke funksje yn minder dan 100 millisekonden sil wurde lansearre. Dan is der yn prinsipe gjin sprake fan oft de wachttiid kritysk is foar de brûker. Tagelyk hinget de tapasberens fan Serverless, lykas kollega's al sein hawwe, folslein ôf fan it saaklike probleem.
Wy tankje ús sponsors dy't ús in protte holpen hawwe:
- IT konferinsjeromte «» foar de konferinsjeside.
- Kalinder fan IT eveneminten en publikaasje"» foar ynformaasjestipe en nijs.
- «"foar kado's.
- foar ko-skepping.
- "Feriening foar elektroanyske kommunikaasje" foar belutsenens en ûnderfining.
- Haadsponsor - foar alle!
Boarne: www.habr.com