Habr-konferensen är ingen debuthistoria. Tidigare höll vi ganska stora Toaster-event för 300-400 personer, men nu bestämde vi att det skulle bli aktuellt med små temamöten, vars inriktning du kan sätta till exempel i kommentarerna. Den första konferensen av detta format hölls i juli och var tillägnad backend-utveckling. Deltagarna lyssnade på rapporter om funktionerna i övergången från backend till ML och om designen av Quadrupel-tjänsten på portalen för statliga tjänster, och deltog även i ett rundabordssamtal tillägnat Serverless. För dem som inte kunde delta i evenemanget personligen, i det här inlägget berättar vi de mest intressanta sakerna.
Från backend-utveckling till maskininlärning
Vad gör dataingenjörer i ML? Hur är uppgifterna för en backend-utvecklare och en ML-ingenjör lika och olika? Vilken väg behöver du ta för att byta ditt första yrke till ditt andra? Detta berättades av Alexander Parinov, som gick in i maskininlärning efter 10 års backend-arbete.
Alexander Parinov
Idag arbetar Alexander som systemarkitekt för datorseende på X5 Retail Group och bidrar till Open Source-projekt relaterade till datorseende och djupinlärning (github.com/creafz). Hans färdigheter bekräftas av hans deltagande i topp 100 på världsrankingen av Kaggle Master (kaggle.com/creafz), den mest populära plattformen för maskininlärningstävlingar.
Varför byta till maskininlärning
För ett och ett halvt år sedan beskrev Jeff Dean, chef för Google Brain, Googles djupinlärningsbaserade forskningsprojekt om artificiell intelligens, hur en halv miljon rader kod i Google Translate ersattes av ett Tensor Flow neuralt nätverk bestående av endast 500 linjer. Efter att ha tränat nätverket ökade kvaliteten på datan och infrastrukturen blev enklare. Det verkar som att detta är vår ljusa framtid: vi behöver inte längre skriva kod, det räcker med att göra neuroner och fylla dem med data. Men i praktiken är allt mycket mer komplicerat.
ML-infrastruktur hos Google
Neurala nätverk är bara en liten del av infrastrukturen (den lilla svarta fyrkanten på bilden ovan). Det krävs många fler hjälpsystem för att ta emot data, bearbeta den, lagra den, kontrollera kvalitet etc., vi behöver infrastruktur för utbildning, distribuera maskininlärningskod i produktionen och testa denna kod. Alla dessa uppgifter liknar exakt vad backend-utvecklare gör.
Maskininlärningsprocess
Vad är skillnaden mellan ML och backend?
I klassisk programmering skriver vi kod och detta dikterar programmets beteende. I ML har vi en liten modellkod och mycket data som vi kastar på modellen. Data i ML är mycket viktigt: samma modell tränad på olika data kan visa helt olika resultat. Problemet är att data nästan alltid är utspridda och lagrade i olika system (relationsdatabaser, NoSQL-databaser, loggar, filer).
Dataversionering
ML kräver versionering inte bara av koden, som i klassisk utveckling, utan också data: det är nödvändigt att tydligt förstå vad modellen tränades på. För att göra detta kan du använda det populära Data Science Version Control-biblioteket (dvc.org).
Datauppmärkning
Nästa uppgift är datamärkning. Markera till exempel alla objekt i bilden eller säg vilken klass den tillhör. Detta görs av speciella tjänster som Yandex.Toloka, vars arbete förenklas avsevärt genom närvaron av ett API. Svårigheter uppstår på grund av den "mänskliga faktorn": du kan förbättra kvaliteten på data och minska felen till ett minimum genom att anförtro samma uppgift till flera utförare.
Visualisering i Tensor Board
Loggning av experiment är nödvändig för att jämföra resultat och välja den bästa modellen baserat på vissa mätvärden. Det finns en stor uppsättning verktyg för visualisering - till exempel Tensor Board. Men det finns inga idealiska sätt att lagra experiment. Små företag nöjer sig ofta med ett Excel-kalkylblad medan stora använder speciella plattformar för att lagra resultat i en databas.
Det finns många plattformar för maskininlärning, men ingen av dem täcker 70 % av behoven
Det första problemet som man måste möta när man sätter en tränad modell i produktion är relaterat till dataforskarnas favoritverktyg - Jupyter Notebook. Det finns ingen modularitet i det, det vill säga utgången är en sådan "fotduk" av kod som inte är uppdelad i logiska delar - moduler. Allt är blandat: klasser, funktioner, konfigurationer etc. Denna kod är svår att versionera och testa.
Hur ska man hantera detta? Du kan säga upp dig själv, som Netflix, och skapa din egen plattform som låter dig lansera dessa bärbara datorer direkt i produktion, överföra data till dem som input och få resultat. Du kan tvinga utvecklarna som rullar modellen i produktion att skriva om koden normalt och dela upp den i moduler. Men med detta tillvägagångssätt är det lätt att göra ett misstag, och modellen kommer inte att fungera som avsett. Därför är det idealiska alternativet att förbjuda användningen av Jupyter Notebook för modellkod. Om naturligtvis dataforskarna går med på detta.
Modell som en svart låda
Det enklaste sättet att få en modell i produktion är att använda den som en svart låda. Du har någon typ av modellklass, du fick modellens vikter (parametrar för neuronerna i det tränade nätverket), och om du initierar den här klassen (kalla förutsägningsmetoden, mata den med en bild), kommer du att få en viss förutsägelse som en utgång. Vad som händer inuti spelar ingen roll.
Separat serverprocess med modell
Du kan också höja en viss separat process och skicka den genom en RPC-kö (med bilder eller annan källdata. Vid utgången kommer vi att få förutsägelser.
Ett exempel på att använda en modell 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 detta tillvägagångssätt är prestationsbegränsningen. Låt oss säga att vi har Phyton-kod skriven av dataforskare som är långsam, och vi vill pressa ut maximal prestanda. För att göra detta kan du använda verktyg som konverterar koden till native eller konverterar den till ett annat ramverk skräddarsytt för produktion. Det finns sådana verktyg för varje ramverk, men det finns inga idealiska; du måste lägga till dem själv.
Infrastrukturen i ML är densamma som i en vanlig backend. Det finns Docker och Kubernetes, bara för Docker behöver du installera runtime från NVIDIA, vilket tillåter processer inuti behållaren att komma åt grafikkort i värden. Kubernetes behöver en plugin så att den kan hantera servrar med grafikkort.
Till skillnad från klassisk programmering finns det i fallet med ML många olika rörliga element i infrastrukturen som behöver kontrolleras och testas – till exempel databehandlingskod, modellutbildningspipeline och produktion (se diagram ovan). Det är viktigt att testa koden som kopplar ihop olika delar av pipelines: det finns många bitar och problem uppstår väldigt ofta vid modulgränser.
Hur AutoML fungerar
AutoML-tjänster lovar att välja den optimala modellen för dina syften och träna den. Men du måste förstå: data är mycket viktigt i ML, resultatet beror på dess förberedelse. Märkning görs av människor, vilket är fyllt med fel. Utan strikt kontroll kan resultatet bli skräp, och det är ännu inte möjligt att automatisera processen; verifiering av specialister - datavetare - behövs. Det är här AutoML går sönder. Men det kan vara användbart för att välja en arkitektur – när du redan har förberett datan och vill köra en serie experiment för att hitta den bästa modellen.
Hur man kommer in i maskininlärning
Det enklaste sättet att komma in i ML är om du utvecklar i Python, som används i alla ramverk för djupinlärning (och vanliga ramverk). Detta språk är praktiskt taget obligatoriskt för detta verksamhetsområde. C++ används för vissa datorseende uppgifter, till exempel i styrsystem för självkörande bilar. JavaScript och Shell - för visualisering och så konstiga saker som att köra en neuron i webbläsaren. Java och Scala används vid arbete med Big Data och för maskininlärning. R och Julia är älskade av människor som studerar matematisk statistik.
Det bekvämaste sättet att få praktisk erfarenhet till att börja med är på Kaggle; deltagande i en av plattformens tävlingar ger mer än ett års teoristudier. På den här plattformen kan du ta någon annans postade och kommenterade kod och försöka förbättra den, optimera den för dina syften. Bonus - din Kaggle-ranking påverkar din lön.
Ett annat alternativ är att gå med i ML-teamet som backend-utvecklare. Det finns många startups för maskininlärning där du kan få erfarenhet genom att hjälpa dina kollegor att lösa deras problem. Slutligen kan du gå med i en av dataforskargemenskaperna - Open Data Science (ods.ai) och andra.
Talaren publicerade ytterligare information om ämnet på länken
"Quadrupel" - en tjänst med riktade meddelanden från portalen "State Services"
Evgeny Smirnov
Nästa talare var chefen för avdelningen för utveckling av e-förvaltningsinfrastruktur, Evgeny Smirnov, som talade om Quadruple. Detta är en riktad meddelandetjänst för Gosuslugi-portalen (gosuslugi.ru), den mest besökta statliga resursen på Runet. Den dagliga publiken är 2,6 miljoner, totalt finns det 90 miljoner registrerade användare på sajten, varav 60 miljoner är bekräftade. Belastningen på portalens API är 30 tusen RPS.
Teknik som används i backend av statliga tjänster
"Quadrupel" är en riktad aviseringstjänst, med hjälp av vilken användaren får ett erbjudande om en tjänst vid det för honom lämpligaste ögonblicket genom att sätta upp särskilda meddelanderegler. Huvudkraven vid utvecklingen av tjänsten var flexibla inställningar och tillräckligt med tid för utskick.
Hur fungerar Quadrupel?
Diagrammet ovan visar en av reglerna för Quadrupel med hjälp av exemplet på en situation med behov av att byta ut ett körkort. Först letar tjänsten efter användare vars utgångsdatum går ut om en månad. De visas en banner med ett erbjudande om att få lämplig tjänst och ett meddelande skickas via e-post. För de användare vars deadline redan har löpt ut ändras bannern och e-postmeddelandet. Efter ett framgångsrikt utbyte av rättigheter får användaren andra meddelanden - med ett förslag om att uppdatera uppgifterna i identiteten.
Ur teknisk synvinkel är det här groovy skript där koden är skriven. Indata är data, utdata är sant/falskt, matchat/matchade inte. Det finns mer än 50 regler totalt - från att bestämma användarens födelsedag (det nuvarande datumet är lika med användarens födelsedatum) till komplexa situationer. Varje dag identifierar dessa regler omkring en miljon matcher – personer som behöver meddelas.
Quadrupel aviseringskanaler
Under huven på Quadrupel finns en databas där användardata lagras, och tre applikationer:
- Arbetare avsedd för uppdatering av data.
- Rest API hämtar och levererar själva banners till portalen och mobilapplikationen.
- Scheduler запускает работы по пересчету баннеров или массовой рассылки.
För att uppdatera data är backend-enheten händelsestyrd. Två gränssnitt - vila eller JMS. Det finns många händelser, innan de sparas och bearbetas, aggregeras de för att inte göra onödiga förfrågningar. Själva databasen, tabellen i vilken data lagras, ser ut som ett nyckelvärdeslager - användarens nyckel och själva värdet: flaggor som indikerar närvaro eller frånvaro av relevanta dokument, deras giltighetstid, aggregerad statistik om tjänsternas beställning av denna användare och så vidare.
Efter att ha sparat data ställs en uppgift in i JMS så att banners omedelbart räknas om - detta måste omedelbart visas på webben. Systemet startar på natten: uppgifter kastas in i JMS med användarintervaller, enligt vilka reglerna måste räknas om. Detta plockas upp av de processorer som är involverade i omräkningen. Därefter går bearbetningsresultaten till nästa kö, som antingen sparar banners i databasen eller skickar användaraviseringsuppgifter till tjänsten. Processen tar 5-7 timmar, den är lätt skalbar på grund av att du alltid kan antingen lägga till hanterare eller höja instanser med nya hanterare.
Сервис работает достаточно хорошо. Но объем данных растет, поскольку пользователей становится больше. Это приводит к увеличению нагрузки на базу — даже с учетом того, что Rest API смотрит в реплику. Второй момент — JMS, который, как выяснилось, не очень подходит из-за большого потребления памяти. Высок риск переполнения очереди с падением JMS и остановкой обработки. Поднять JMS после этого без очистки логов невозможно.
Det är planerat att lösa problemen med sharding, vilket gör det möjligt att balansera belastningen på databasen. Det finns också planer på att ändra datalagringsschemat och ändra JMS till Kafka - en mer feltolerant lösning som kommer att lösa minnesproblem.
Backend-as-a-Service vs. Serverlös
Från vänster till höger: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend som tjänst eller serverlös lösning? Deltagare i diskussionen om denna angelägna fråga vid runda bordet var:
- Ara Israelyan, CTO CTO och grundare av Scorocode.
- Nikolay Markov, Senior Data Engineer på Aligned Research Group.
- Andrey Tomilenko, chef för RUVDS utvecklingsavdelning.
Samtalet modererades av seniorutvecklaren Alexander Borgart. Vi presenterar debatterna där även lyssnarna deltog i en förkortad version.
— Vad är Serverless i din förståelse?
Andrew: Detta är en beräkningsmodell - en lambdafunktion som måste bearbeta data så att resultatet enbart beror på datan. Termen kom antingen från Google eller från Amazon och dess AWS Lambda-tjänst. Det är lättare för en leverantör att hantera en sådan funktion genom att tilldela en pool av kapacitet för den. Olika användare kan redovisas oberoende av varandra på samma servrar.
Nicholas: Enkelt uttryckt överför vi en del av vår IT-infrastruktur och affärslogik till molnet, till outsourcing.
ara: Från utvecklarnas sida - ett bra försök att spara resurser, från marknadsförarnas sida - att tjäna mer pengar.
— Är Serverless detsamma som mikrotjänster?
Nicholas: Nej, Serverless är mer av en arkitekturorganisation. En mikrotjänst är en atomenhet av någon logik. Serverlöst är ett tillvägagångssätt, inte en "separat enhet".
ara: En serverlös funktion kan paketeras i en mikrotjänst, men denna kommer inte längre att vara serverlös, den kommer att sluta vara en lambdafunktion. I Serverless börjar en funktion fungera först när den efterfrågas.
Andrew: De skiljer sig åt i sin livstid. Vi lanserade Lambda-funktionen och glömde den. Det fungerade i ett par sekunder, och nästa klient kan behandla sin begäran på en annan fysisk maskin.
– Vilken våg är bättre?
ara: När man skalar horisontellt beter sig Lambda-funktioner exakt likadant som mikrotjänster.
Nicholas: Oavsett antal repliker du ställer in, kommer det att finnas lika många av dem; Serverless har inga problem med skalning. Jag gjorde en replikuppsättning i Kubernetes, lanserade 20 instanser "någonstans" och 20 anonyma länkar returnerades till dig. Fram!
— Är det möjligt att skriva en backend på Serverless?
Andrew: Teoretiskt, men det är ingen mening. Lambdafunktioner kommer att förlita sig på ett enda förråd – vi måste garantera garanti. Till exempel, om en användare har genomfört en viss transaktion, bör han nästa gång han kontaktar se: transaktionen har genomförts, medlen har krediterats. Alla lambdafunktioner blockeras på detta samtal. Faktum är att ett gäng serverlösa funktioner kommer att förvandlas till en enda tjänst med en flaskhalsåtkomstpunkt till databasen.
— I vilka situationer är det vettigt att använda en serverlös arkitektur?
Andrew: Uppgifter som inte kräver delad lagring - samma gruvdrift, blockchain. Där du behöver räkna mycket. Om du har mycket datorkraft så kan du definiera en funktion som "beräkna hash av något där..." Men du kan lösa problemet med datalagring genom att ta till exempel Lambda-funktioner från Amazon och deras distribuerade lagring . Och det visar sig att du skriver en vanlig tjänst. Lambdafunktioner kommer åt lagringen och ger någon form av svar till användaren.
Nicholas: Behållare som körs i Serverless är extremt begränsade i resurser. Det finns lite minne och allt annat. Men om hela din infrastruktur är utplacerad helt och hållet på något moln – Google, Amazon – och du har ett permanent kontrakt med dem så finns det en budget för allt detta, då kan du för vissa uppgifter använda serverlösa behållare. Det är nödvändigt att vara inne i den här infrastrukturen, eftersom allt är skräddarsytt för användning i en specifik miljö. Det vill säga, om du är redo att knyta allt till molninfrastrukturen kan du experimentera. Fördelen är att du inte behöver hantera den här infrastrukturen.
ara: Det faktum att Serverless inte kräver att du hanterar Kubernetes, Docker, installerar Kafka och så vidare är självbedrägeri. Samma Amazon och Google installerar detta. En annan sak är att du har en SLA. Du kan lika gärna lägga ut allt på entreprenad snarare än att koda det själv.
Andrew: Serverless i sig är billigt, men du måste betala mycket för andra Amazon-tjänster - till exempel databasen. Folk har redan stämt dem för att de debiterade galna summor pengar för API-porten.
ara: Om vi pratar om pengar, måste du ta hänsyn till denna punkt: du måste vända hela utvecklingsmetoden i företaget 180 grader för att överföra all kod till Serverless. Detta kommer att ta mycket tid och pengar.
— Finns det några värdiga alternativ till betald Serverless från Amazon och Google?
Nicholas: I Kubernetes startar du något slags jobb, det körs och dör - det här är ganska serverlöst ur en arkitektonisk synvinkel. Om du vill skapa riktigt intressant affärslogik med köer och databaser så måste du tänka lite mer på det. Allt detta kan lösas utan att lämna Kubernetes. Jag skulle inte bry mig om att dra ut på ytterligare implementering.
— Hur viktigt är det att övervaka vad som händer i Serverless?
ara: Beror på systemarkitektur och affärskrav. I huvudsak måste leverantören tillhandahålla rapportering som hjälper devops-teamet att förstå möjliga problem.
Nicholas: Amazon har CloudWatch, där alla loggar streamas, inklusive de från Lambda. Integrera loggvidarebefordran och använd ett separat verktyg för visning, varning och så vidare. Du kan stoppa in agenter i behållarna du startar.
- Låt oss sammanfatta det.
Andrew: Att tänka på Lambda-funktioner är användbart. Om du skapar en tjänst på egen hand – inte en mikrotjänst, utan en som skriver en förfrågan, kommer åt databasen och skickar ett svar – löser Lambda-funktionen ett antal problem: med multithreading, skalbarhet och så vidare. Om din logik är uppbyggd på detta sätt kommer du i framtiden att kunna överföra dessa Lambdas till mikrotjänster eller använda tredjepartstjänster som Amazon. Tekniken är användbar, idén är intressant. Hur motiverat det är för affärer är fortfarande en öppen fråga.
Nikolay: Serverlös används bättre för driftuppgifter än för att beräkna viss affärslogik. Jag tänker alltid på det som händelsebearbetning. Om du har det i Amazon, om du är i Kubernetes, ja. Annars måste du anstränga dig ganska mycket för att få igång Serverless på egen hand. Det är nödvändigt att titta på ett specifikt affärscase. Till exempel är en av mina uppgifter nu: när filer visas på disken i ett visst format måste jag ladda upp dem till Kafka. Jag kan använda WatchDog eller Lambda. Ur logisk synvinkel är båda alternativen lämpliga, men implementeringsmässigt är Serverless mer komplicerat, och jag föredrar det enklare sättet, utan Lambda.
ara: Serverlös är en intressant, användbar och mycket tekniskt vacker idé. Förr eller senare kommer tekniken att nå den punkt där vilken funktion som helst kommer att lanseras på mindre än 100 millisekunder. Då blir det i princip ingen fråga om väntetiden är kritisk för användaren. Samtidigt beror tillämpligheten av Serverless, som kollegor redan har sagt, helt på affärsproblemet.
Vi tackar våra sponsorer som hjälpt oss mycket:
- IT-konferensutrymme «» för konferenssidan.
- Kalender för IT-evenemang och publicering"» för informationsstöd och nyheter.
- «"för gåvor.
- för samskapande.
- "Föreningen för elektronisk kommunikation" för engagemang och erfarenhet.
- Huvudsponsor - för alla!
Källa: will.com