Habr-konferencen er ikke en debuthistorie. Tidligere afholdt vi ret store Toaster-arrangementer for 300-400 personer, men nu besluttede vi, at det ville være relevant med små temamøder, hvis retning du fx kan sætte i kommentarerne. Den første konference i dette format blev afholdt i juli og var dedikeret til backend-udvikling. Deltagerne lyttede til rapporter om funktionerne i overgangen fra backend til ML og om designet af Quadrupel-tjenesten på State Services-portalen og deltog også i en rundbordssamtale dedikeret til Serverless. For dem, der ikke var i stand til at deltage i begivenheden personligt, fortæller vi dig i dette indlæg de mest interessante ting.
Fra backend-udvikling til maskinlæring
Hvad laver dataingeniører i ML? Hvordan er opgaverne for en backend-udvikler og en ML-ingeniør ens og forskellige? Hvilken vej skal du gå for at ændre dit første erhverv til dit andet? Det fortalte Alexander Parinov, der gik ind i maskinlæring efter 10 års backend-arbejde.
Alexander Parinov
I dag arbejder Alexander som computer vision system arkitekt hos X5 Retail Group og bidrager til Open Source projekter relateret til computer vision og deep learning (github.com/creafz). Hans færdigheder bekræftes af hans deltagelse i top 100 på verdensranglisten af Kaggle Master (kaggle.com/creafz), den mest populære platform til maskinlæringskonkurrencer.
Hvorfor skifte til maskinlæring
For halvandet år siden beskrev Jeff Dean, leder af Google Brain, Googles deep learning-baserede kunstige intelligens-forskningsprojekt, hvordan en halv million linjer kode i Google Translate blev erstattet af et Tensor Flow neuralt netværk bestående af kun 500 linjer. Efter træning af netværket steg kvaliteten af dataene, og infrastrukturen blev enklere. Det ser ud til, at dette er vores lyse fremtid: vi behøver ikke længere at skrive kode, det er nok at lave neuroner og fylde dem med data. Men i praksis er alt meget mere kompliceret.
ML-infrastruktur hos Google
Neurale netværk er kun en lille del af infrastrukturen (den lille sorte firkant på billedet ovenfor). Der kræves mange flere hjælpesystemer til at modtage data, behandle dem, gemme dem, kontrollere kvalitet osv., vi har brug for infrastruktur til træning, implementering af maskinlæringskode i produktionen og test af denne kode. Alle disse opgaver ligner nøjagtigt, hvad backend-udviklere gør.
Maskinlæringsproces
Hvad er forskellen mellem ML og backend?
I klassisk programmering skriver vi kode, og dette dikterer programmets opførsel. I ML har vi en lille modelkode og en masse data, som vi smider på modellen. Data i ML er meget vigtigt: den samme model trænet på forskellige data kan vise helt forskellige resultater. Problemet er, at dataene næsten altid er spredt og lagret i forskellige systemer (relationelle databaser, NoSQL-databaser, logfiler, filer).
Dataversionering
ML kræver versionering ikke kun af koden, som i klassisk udvikling, men også dataene: det er nødvendigt klart at forstå, hvad modellen blev trænet på. For at gøre dette kan du bruge det populære Data Science Version Control-bibliotek (dvc.org).
Datamarkering
Den næste opgave er datamærkning. Marker f.eks. alle objekterne på billedet eller sig, hvilken klasse det tilhører. Dette gøres af specielle tjenester som Yandex.Toloka, arbejdet med hvilket er meget forenklet ved tilstedeværelsen af en API. Vanskeligheder opstår på grund af den "menneskelige faktor": du kan forbedre kvaliteten af data og reducere fejl til et minimum ved at overlade den samme opgave til flere udførende.
Visualisering i Tensor Board
Logning af eksperimenter er nødvendig for at sammenligne resultater og vælge den bedste model baseret på nogle målinger. Der er et stort sæt værktøjer til visualisering - for eksempel Tensor Board. Men der er ingen ideelle måder at opbevare eksperimenter på. Små virksomheder nøjes ofte med et Excel-regneark, mens store bruger specielle platforme til lagring af resultater i en database.
Der er mange platforme til maskinlæring, men ingen af dem dækker 70 % af behovene
Det første problem, man står over for, når man sætter en trænet model i produktion, er relateret til dataforskernes foretrukne værktøj - Jupyter Notebook. Der er ingen modularitet i det, det vil sige, at outputtet er sådan en "fodklud" af kode, der ikke er opdelt i logiske stykker - moduler. Alt er blandet sammen: klasser, funktioner, konfigurationer osv. Denne kode er svær at versionere og teste.
Hvordan skal man håndtere dette? Du kan selv sige op, ligesom Netflix, og oprette din egen platform, der giver dig mulighed for at starte disse bærbare computere direkte i produktion, overføre data til dem som input og få resultater. Du kan tvinge udviklerne, der ruller modellen i produktion, til at omskrive koden normalt, opdele den i moduler. Men med denne tilgang er det nemt at lave en fejl, og modellen vil ikke fungere efter hensigten. Derfor er den ideelle mulighed at forbyde brugen af Jupyter Notebook til modelkode. Hvis dataforskerne selvfølgelig er enige i dette.
Model som sort boks
Den nemmeste måde at få en model i produktion på er at bruge den som en sort boks. Du har en form for modelklasse, du fik vægten af modellen (parametre for neuronerne i det trænede netværk), og hvis du initialiserer denne klasse (kald forudsigelsesmetoden, foder den med et billede), vil du få en vis forudsigelse som output. Hvad der sker indeni er ligegyldigt.
Separat serverproces med model
Du kan også hæve en bestemt separat proces og sende den gennem en RPC-kø (med billeder eller andre kildedata. Ved udgangen vil vi modtage forudsigelser.
Et eksempel på brug af en model i 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)
Problemet med denne tilgang er præstationsbegrænsningen. Lad os sige, at vi har Phyton-kode skrevet af dataforskere, der er langsom, og vi ønsker at presse den maksimale ydeevne ud. For at gøre dette kan du bruge værktøjer, der konverterer koden til native eller konverterer den til en anden ramme, der er skræddersyet til produktion. Der er sådanne værktøjer til alle rammer, men der er ingen ideelle; du bliver nødt til at tilføje dem selv.
Infrastrukturen i ML er den samme som i en almindelig backend. Der er Docker og Kubernetes, kun for Docker skal du installere runtime fra NVIDIA, som tillader processer inde i containeren at få adgang til videokort i værten. Kubernetes har brug for et plugin, så det kan administrere servere med videokort.
I modsætning til klassisk programmering er der i tilfældet med ML mange forskellige bevægelige elementer i infrastrukturen, som skal kontrolleres og testes - for eksempel databehandlingskode, modeltræningspipeline og produktion (se diagrammet ovenfor). Det er vigtigt at teste koden, der forbinder forskellige stykker rørledninger: der er mange stykker, og der opstår ofte problemer ved modulgrænser.
Sådan fungerer AutoML
AutoML-tjenester lover at vælge den optimale model til dine formål og træne den. Men du skal forstå: data er meget vigtigt i ML, resultatet afhænger af dets forberedelse. Markup udføres af mennesker, hvilket er fyldt med fejl. Uden streng kontrol kan resultatet blive skrald, og det er endnu ikke muligt at automatisere processen; verifikation af specialister - dataforskere - er nødvendig. Det er her, AutoML bryder sammen. Men det kan være nyttigt til at vælge en arkitektur – når du allerede har forberedt dataene og vil køre en række eksperimenter for at finde den bedste model.
Sådan kommer du ind i maskinlæring
Den nemmeste måde at komme ind i ML er, hvis du udvikler i Python, som bruges i alle deep learning frameworks (og almindelige frameworks). Dette sprog er praktisk talt obligatorisk for dette aktivitetsområde. C++ bruges til nogle computer vision opgaver, for eksempel i styresystemer til selvkørende biler. JavaScript og Shell - til visualisering og sådanne mærkelige ting som at køre en neuron i browseren. Java og Scala bruges, når man arbejder med Big Data og til maskinlæring. R og Julia er elsket af folk, der studerer matematisk statistik.
Den mest bekvemme måde at få praktisk erfaring til at begynde med er på Kaggle; deltagelse i en af platformens konkurrencer giver mere end et års teoristudium. På denne platform kan du tage en andens postede og kommenterede kode og prøve at forbedre den, optimere den til dine formål. Bonus - din Kaggle-rangering påvirker din løn.
En anden mulighed er at slutte sig til ML-teamet som backend-udvikler. Der er mange maskinlæringsstartups, hvor du kan få erfaring ved at hjælpe dine kollegaer med at løse deres problemer. Endelig kan du tilslutte dig et af dataforsker-fællesskaberne - Open Data Science (ods.ai) og andre.
Taleren postede yderligere information om emnet på linket
"Quadrupel" - en tjeneste med målrettede meddelelser om portalen "Statstjenester"
Evgeny Smirnov
Den næste taler var lederen af afdelingen for udvikling af e-forvaltningsinfrastruktur, Evgeny Smirnov, som talte om Quadruple. Dette er en målrettet underretningstjeneste til Gosuslugi-portalen (gosuslugi.ru), den mest besøgte regeringsressource på Runet. Det daglige publikum er 2,6 millioner, i alt er der 90 millioner registrerede brugere på siden, hvoraf 60 millioner er bekræftet. Belastningen på portal-API'en er 30 tusind RPS.
Teknologier, der bruges i backend af statslige tjenester
"Quadrupel" er en målrettet notifikationstjeneste, ved hjælp af hvilken brugeren modtager et tilbud på en tjeneste på det for ham bedst egnede tidspunkt ved at opsætte særlige notifikationsregler. De vigtigste krav ved udviklingen af tjenesten var fleksible indstillinger og tilstrækkelig tid til udsendelser.
Hvordan virker Quadrupel?
Diagrammet ovenfor viser en af reglerne for driften af Quadrupel ved hjælp af eksemplet på en situation med behov for at udskifte et kørekort. For det første leder tjenesten efter brugere, hvis udløbsdato udløber om en måned. De får vist et banner med et tilbud om at modtage den relevante service, og en besked sendes via e-mail. For de brugere, hvis frist allerede er udløbet, ændres banneret og e-mailen. Efter en vellykket udveksling af rettigheder modtager brugeren andre meddelelser - med et forslag om at opdatere dataene i identiteten.
Fra et teknisk synspunkt er det groovy scripts, hvori koden er skrevet. Inputtet er data, outputtet er sandt/falsk, matchet/matchede ikke. Der er mere end 50 regler i alt - fra at bestemme brugerens fødselsdag (den aktuelle dato er lig med brugerens fødselsdato) til komplekse situationer. Hver dag identificerer disse regler omkring en million kampe – personer, der skal underrettes.
Quadrupel notifikationskanaler
Under hætten på Quadrupel er der en database, hvori brugerdata er gemt, og tre applikationer:
- Worker beregnet til opdatering af data.
- Rest API henter og leverer selv bannerne til portalen og mobilapplikationen.
- Scheduler lancerer arbejde med genberegning af bannere eller masseudsendelser.
For at opdatere data er backend'en hændelsesdrevet. To grænseflader - hvile eller JMS. Der er mange begivenheder; før de gemmes og behandles, er de aggregeret for ikke at fremsætte unødvendige anmodninger. Selve databasen, tabellen som dataene er lagret i, ligner et nøgleværdilager - brugerens nøgle og selve værdien: flag, der angiver tilstedeværelsen eller fraværet af relevante dokumenter, deres gyldighedsperiode, aggregeret statistik over rækkefølgen af tjenester pr. denne bruger og så videre.
Efter lagring af data sættes en opgave i JMS, så bannerne straks genberegnes - dette skal straks vises på nettet. Systemet starter om natten: opgaver smides ind i JMS med brugerintervaller, hvorefter reglerne skal genberegnes. Dette opfanges af de processorer, der er involveret i genberegningen. Derefter går behandlingsresultaterne til den næste kø, som enten gemmer bannerne i databasen eller sender brugernotifikationsopgaver til tjenesten. Processen tager 5-7 timer, den er let skalerbar på grund af det faktum, at du altid enten kan tilføje handlere eller rejse instanser med nye handlere.
Tjenesten fungerer ganske godt. Men mængden af data vokser i takt med, at der er flere brugere. Dette fører til en stigning i belastningen på databasen - også når man tager højde for, at Rest API'en ser på replikaen. Det andet punkt er JMS, som, som det viste sig, ikke er særlig velegnet på grund af dets høje hukommelsesforbrug. Der er en høj risiko for køoverløb, der får JMS til at gå ned, og behandlingen stopper. Det er umuligt at rejse JMS efter dette uden at rydde logfilerne.
Det er planlagt at løse problemerne ved hjælp af sharding, som gør det muligt at balancere belastningen på databasen. Der er også planer om at ændre datalagringsskemaet og ændre JMS til Kafka - en mere fejltolerant løsning, der vil løse hukommelsesproblemer.
Backend-as-a-Service vs. Serverløs
Fra venstre mod højre: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend as a service eller serverløs løsning? Deltagere i diskussionen af dette presserende spørgsmål ved rundbordsbordet var:
- Ara Israelyan, CTO CTO og grundlægger af Scorocode.
- Nikolay Markov, Senior Data Engineer hos Aligned Research Group.
- Andrey Tomilenko, leder af RUVDS udviklingsafdeling.
Samtalen blev modereret af seniorudvikler Alexander Borgart. Vi præsenterer debatterne, som lytterne også deltog i, i en forkortet version.
— Hvad er Serverless i din forståelse?
Andrew: Dette er en computermodel - en Lambda-funktion, der skal behandle data, så resultatet kun afhænger af dataene. Udtrykket kom enten fra Google eller fra Amazon og dets AWS Lambda-tjeneste. Det er lettere for en udbyder at håndtere en sådan funktion ved at allokere en pulje af kapacitet til den. Forskellige brugere kan stå uafhængigt af hinanden på de samme servere.
Nicholas: For at sige det enkelt, så overfører vi en del af vores it-infrastruktur og forretningslogik til skyen, til outsourcing.
ara: Fra udviklernes side - et godt forsøg på at spare ressourcer, fra marketingfolks side - for at tjene flere penge.
— Er serverløs det samme som mikrotjenester?
Nicholas: Nej, Serverless er mere en arkitekturorganisation. En mikrotjeneste er en atomare enhed af en vis logik. Serverløs er en tilgang, ikke en "separat enhed."
ara: En serverløs funktion kan pakkes ind i en mikrotjeneste, men denne vil ikke længere være serverløs, den vil ophøre med at være en Lambda-funktion. I Serverless begynder en funktion først at virke i det øjeblik, den bliver bedt om.
Andrew: De adskiller sig i deres levetid. Vi lancerede Lambda-funktionen og glemte den. Det virkede i et par sekunder, og den næste klient kan behandle sin anmodning på en anden fysisk maskine.
- Hvilken vægt er bedre?
ara: Ved vandret skalering opfører Lambda-funktioner sig nøjagtigt det samme som mikrotjenester.
Nicholas: Uanset antallet af replikaer du indstiller, vil der være lige så mange af dem; Serverless har ingen problemer med skalering. Jeg lavede et replikasæt i Kubernetes, lancerede 20 forekomster "et eller andet sted", og 20 anonyme links blev returneret til dig. Frem!
— Er det muligt at skrive en backend på Serverless?
Andrew: Teoretisk, men det giver ingen mening. Lambda-funktioner vil være afhængige af et enkelt lager - vi skal sikre garanti. For eksempel, hvis en bruger har udført en bestemt transaktion, så skal næste gang han kontakter han se: transaktionen er blevet gennemført, midlerne er blevet krediteret. Alle Lambda-funktioner blokerer for dette opkald. Faktisk vil en masse serverløse funktioner blive til en enkelt tjeneste med et flaskehalsadgangspunkt til databasen.
— I hvilke situationer giver det mening at bruge serverløs arkitektur?
Andrew: Opgaver, der ikke kræver delt opbevaring - samme minedrift, blockchain. Hvor du skal tælle meget. Hvis du har meget computerkraft, så kan du definere en funktion som "beregn hashen af noget der..." Men du kan løse problemet med datalagring ved at tage for eksempel Lambda-funktioner fra Amazon og deres distribuerede lagring . Og det viser sig, at du skriver en almindelig tjeneste. Lambda-funktioner vil få adgang til lageret og give en form for respons til brugeren.
Nicholas: Containere, der kører i Serverless, er ekstremt begrænsede i ressourcer. Der er lidt hukommelse og alt muligt andet. Men hvis hele din infrastruktur er implementeret udelukkende på en eller anden sky – Google, Amazon – og du har en permanent kontrakt med dem, er der et budget til alt dette, så til nogle opgaver kan du bruge serverløse containere. Det er nødvendigt at være inde i denne infrastruktur, for alt er skræddersyet til brug i et specifikt miljø. Det vil sige, at hvis du er klar til at binde alt til cloud-infrastrukturen, kan du eksperimentere. Fordelen er, at du ikke behøver at administrere denne infrastruktur.
ara: Det faktum, at Serverless ikke kræver, at du administrerer Kubernetes, Docker, installerer Kafka og så videre, er selvbedrag. Den samme Amazon og Google installerer dette. En anden ting er, at du har en SLA. Du kan lige så godt outsource alt i stedet for at kode det selv.
Andrew: Serverløs i sig selv er billig, men du skal betale meget for andre Amazon-tjenester - for eksempel databasen. Folk har allerede sagsøgt dem, fordi de opkrævede vanvittige beløb for API-porten.
ara: Hvis vi taler om penge, så skal du tage højde for dette punkt: du bliver nødt til at vende hele udviklingsmetoden i virksomheden 180 grader for at overføre al koden til Serverless. Dette vil tage meget tid og penge.
— Er der nogen værdige alternativer til betalt Serverless fra Amazon og Google?
Nicholas: I Kubernetes starter du en slags job, det kører og dør - det er ret serverløst set fra et arkitektonisk synspunkt. Hvis du vil skabe rigtig interessant forretningslogik med køer og databaser, så skal du tænke lidt mere over det. Dette kan alt sammen løses uden at forlade Kubernetes. Jeg ville ikke gide at trække yderligere implementering ud.
— Hvor vigtigt er det at overvåge, hvad der sker i Serverless?
ara: Afhænger af systemarkitektur og forretningskrav. Grundlæggende skal udbyderen levere rapportering, der hjælper devops-teamet med at forstå mulige problemer.
Nicholas: Amazon har CloudWatch, hvor alle logs streames, også dem fra Lambda. Integrer logvideresendelse og brug et separat værktøj til visning, advarsler og så videre. Du kan proppe agenter i de beholdere, du starter.
- Lad os opsummere det.
Andrew: Det er nyttigt at tænke på Lambda-funktioner. Hvis du opretter en tjeneste på egen hånd - ikke en mikrotjeneste, men en, der skriver en anmodning, tilgår databasen og sender et svar - løser Lambda-funktionen en række problemer: med multithreading, skalerbarhed og så videre. Hvis din logik er bygget på denne måde, så vil du i fremtiden være i stand til at overføre disse Lambdaer til mikrotjenester eller bruge tredjepartstjenester som Amazon. Teknologien er nyttig, ideen er interessant. Hvor berettiget det er for erhvervslivet er stadig et åbent spørgsmål.
Nikolay: Serverløs bruges bedre til driftsopgaver end til at beregne noget forretningslogik. Jeg tænker altid på det som begivenhedsbehandling. Hvis du har det i Amazon, hvis du er i Kubernetes, ja. Ellers skal du lægge en hel del kræfter i at få Serverless op at køre på egen hånd. Det er nødvendigt at se på en konkret business case. For eksempel er en af mine opgaver nu: Når filer vises på disken i et bestemt format, skal jeg uploade dem til Kafka. Jeg kan bruge WatchDog eller Lambda. Fra et logisk synspunkt er begge muligheder velegnede, men med hensyn til implementering er Serverless mere kompliceret, og jeg foretrækker den mere simple måde, uden Lambda.
ara: Serverløs er en interessant, anvendelig og meget teknisk smuk idé. Før eller siden vil teknologien nå det punkt, hvor enhver funktion vil blive lanceret på mindre end 100 millisekunder. Så vil der i princippet ikke være tale om, hvorvidt ventetiden er kritisk for brugeren. Samtidig afhænger anvendeligheden af Serverless, som kolleger allerede har sagt, fuldstændigt af forretningsproblemet.
Vi takker vores sponsorer, som har hjulpet os meget:
- IT-konferencerum «» til konferencesiden.
- Kalender over IT-arrangementer og udgivelse"» for informationssupport og nyheder.
- «"for gaver.
- til samskabelse.
- "Foreningen for Elektronisk Kommunikation" for involvering og erfaring.
- Hovedsponsor - for alle!
Kilde: www.habr.com