De Habr-conferentie is geen debuutverhaal. Voorheen hielden we vrij grote Toaster-evenementen voor 300-400 personen, maar nu hebben we besloten dat kleine thematische bijeenkomsten relevant zouden zijn, waarvan je de richting bijvoorbeeld in de reacties kunt bepalen. De eerste conferentie van dit formaat werd in juli gehouden en was gewijd aan backend-ontwikkeling. Deelnemers luisterden naar rapporten over de kenmerken van de transitie van de backend naar ML en over het ontwerp van de Quadrupel-service op het portaal van de Rijksdiensten, en namen ook deel aan een rondetafelconferentie gewijd aan Serverless. Voor degenen die het evenement niet persoonlijk konden bijwonen, vertellen we in dit bericht de meest interessante dingen.
Van backend-ontwikkeling tot machine learning
Wat doen data-ingenieurs in ML? Hoe zijn de taken van een backend-ontwikkelaar en een ML-ingenieur vergelijkbaar en verschillend? Welke weg moet u volgen om uw eerste beroep te veranderen in uw tweede? Dit werd verteld door Alexander Parinov, die na tien jaar backend-werk met machine learning begon.
Alexander Parinov
Tegenwoordig werkt Alexander als computer vision-systeemarchitect bij X5 Retail Group en draagt hij bij aan Open Source-projecten gerelateerd aan computer vision en deep learning (github.com/creafz). Zijn vaardigheden worden bevestigd door zijn deelname aan de top 100 van de wereldranglijst van Kaggle Master (kaggle.com/creafz), het populairste platform voor machine learning-wedstrijden.
Waarom overstappen op machinaal leren?
Anderhalf jaar geleden beschreef Jeff Dean, hoofd van Google Brain, het op deep learning gebaseerde onderzoeksproject voor kunstmatige intelligentie van Google, hoe een half miljoen regels code in Google Translate werden vervangen door een Tensor Flow neuraal netwerk dat uit slechts 500 regels bestond. Na het trainen van het netwerk nam de kwaliteit van de data toe en werd de infrastructuur eenvoudiger. Het lijkt erop dat dit onze mooie toekomst is: we hoeven niet langer code te schrijven, het is voldoende om neuronen te maken en ze met gegevens te vullen. Maar in de praktijk is alles veel ingewikkelder.
ML-infrastructuur bij Google
Neurale netwerken vormen slechts een klein onderdeel van de infrastructuur (het kleine zwarte vierkantje in de afbeelding hierboven). Er zijn veel meer hulpsystemen nodig om gegevens te ontvangen, te verwerken, op te slaan, de kwaliteit te controleren, enz. We hebben infrastructuur nodig voor training, het inzetten van machine learning-code in de productie en het testen van deze code. Al deze taken zijn precies vergelijkbaar met wat backend-ontwikkelaars doen.
Machine-leerproces
Wat is het verschil tussen ML en backend?
Bij klassiek programmeren schrijven we code en dit dicteert het gedrag van het programma. In ML hebben we een kleine modelcode en veel gegevens die we naar het model gooien. Gegevens in ML zijn erg belangrijk: hetzelfde model dat op verschillende gegevens is getraind, kan totaal verschillende resultaten opleveren. Het probleem is dat de gegevens bijna altijd verspreid zijn en opgeslagen in verschillende systemen (relationele databases, NoSQL-databases, logs, bestanden).
Versiebeheer van gegevens
ML vereist niet alleen versiebeheer van de code, zoals bij klassieke ontwikkeling, maar ook van de gegevens: het is noodzakelijk om duidelijk te begrijpen waarop het model is getraind. Om dit te doen, kunt u de populaire Data Science Version Control-bibliotheek (dvc.org) gebruiken.
Gegevensopmaak
De volgende taak is het labelen van gegevens. Markeer bijvoorbeeld alle objecten in de afbeelding of zeg tot welke klasse het behoort. Dit wordt gedaan door speciale diensten zoals Yandex.Toloka, waarvan het werk aanzienlijk wordt vereenvoudigd door de aanwezigheid van een API. Moeilijkheden ontstaan door de "menselijke factor": u kunt de kwaliteit van de gegevens verbeteren en fouten tot een minimum beperken door dezelfde taak aan meerdere artiesten toe te vertrouwen.
Visualisatie in Tensor Board
Het loggen van experimenten is nodig om de resultaten te vergelijken en het beste model te selecteren op basis van bepaalde statistieken. Er is een groot aantal tools voor visualisatie, bijvoorbeeld Tensor Board. Maar er zijn geen ideale manieren om experimenten op te slaan. Kleine bedrijven doen het vaak met een Excel-spreadsheet, terwijl grote bedrijven speciale platforms gebruiken om resultaten in een database op te slaan.
Er zijn veel platforms voor machine learning, maar geen enkele dekt 70% van de behoeften
Het eerste probleem waarmee men te maken krijgt bij het in productie nemen van een getraind model heeft te maken met de favoriete tool van datawetenschappers: Jupyter Notebook. Er zit geen modulariteit in, dat wil zeggen, de uitvoer is zo'n "voetdoek" van code die niet in logische stukken is verdeeld: modules. Alles is door elkaar gehaald: klassen, functies, configuraties, enz. Deze code is moeilijk te versieleren en te testen.
Hoe hiermee om te gaan? Je kunt jezelf neerleggen, zoals Netflix, en je eigen platform creëren waarmee je deze laptops direct in productie kunt nemen, er gegevens als input naar kunt overbrengen en resultaten kunt boeken. Je kunt de ontwikkelaars die het model in productie brengen, dwingen de code normaal te herschrijven en in modules op te delen. Maar met deze aanpak is het gemakkelijk om een fout te maken, en het model zal niet werken zoals bedoeld. Daarom is de ideale optie om het gebruik van Jupyter Notebook voor modelcode te verbieden. Als de datawetenschappers het daar uiteraard mee eens zijn.
Gemodelleerd als een zwarte doos
De eenvoudigste manier om een model in productie te krijgen, is door het als black box te gebruiken. Je hebt een soort modelklasse, je hebt de gewichten van het model gekregen (parameters van de neuronen van het getrainde netwerk), en als je deze klasse initialiseert (roep de voorspellingsmethode op, geef er een afbeelding aan), dan krijg je een bepaalde voorspelling als output. Wat er binnen gebeurt, doet er niet toe.
Apart serverproces met model
Je kunt ook een bepaald afzonderlijk proces opwekken en door een RPC-wachtrij sturen (met afbeeldingen of andere brongegevens. Bij de uitvoer ontvangen we voorspellingen.
Een voorbeeld van het gebruik van een model in 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)
Het probleem met deze aanpak is de prestatiebeperking. Laten we zeggen dat we Phyton-code hebben geschreven door datawetenschappers die langzaam is, en we willen maximale prestaties eruit halen. Om dit te doen, kunt u tools gebruiken die de code naar native converteren of naar een ander raamwerk dat op maat is gemaakt voor productie. Er zijn dergelijke tools voor elk raamwerk, maar er zijn geen ideale; je zult ze zelf moeten toevoegen.
De infrastructuur in ML is hetzelfde als in een reguliere backend. Er zijn Docker en Kubernetes, alleen voor Docker moet je runtime van NVIDIA installeren, waardoor processen in de container toegang krijgen tot videokaarten in de host. Kubernetes heeft een plug-in nodig zodat het servers met videokaarten kan beheren.
In tegenstelling tot klassiek programmeren zijn er in het geval van ML veel verschillende bewegende elementen in de infrastructuur die moeten worden gecontroleerd en getest, bijvoorbeeld gegevensverwerkingscode, modeltrainingspijplijn en productie (zie diagram hierboven). Het is belangrijk om de code te testen die verschillende delen van pijpleidingen met elkaar verbindt: er zijn veel delen, en problemen doen zich vaak voor bij modulegrenzen.
Hoe AutoML werkt
AutoML-services beloven het optimale model voor uw doeleinden te selecteren en te trainen. Maar je moet begrijpen: gegevens zijn erg belangrijk in ML, het resultaat hangt af van de voorbereiding ervan. Opmaak wordt door mensen gedaan, wat vol fouten zit. Zonder strikte controle kan het resultaat rotzooi zijn, en het is nog niet mogelijk om het proces te automatiseren; verificatie door specialisten – datawetenschappers – is nodig. Dit is waar AutoML kapot gaat. Maar het kan handig zijn bij het selecteren van een architectuur - wanneer u de gegevens al heeft voorbereid en een reeks experimenten wilt uitvoeren om het beste model te vinden.
Hoe u aan machine learning kunt beginnen
De gemakkelijkste manier om met ML aan de slag te gaan, is door te ontwikkelen in Python, dat wordt gebruikt in alle deep learning-frameworks (en reguliere frameworks). Deze taal is praktisch verplicht voor dit werkgebied. C++ wordt gebruikt voor sommige computervisietaken, bijvoorbeeld in besturingssystemen voor zelfrijdende auto's. JavaScript en Shell - voor visualisatie en vreemde dingen zoals het runnen van een neuron in de browser. Java en Scala worden gebruikt bij het werken met Big Data en voor machine learning. R en Julia zijn geliefd bij mensen die wiskundige statistiek studeren.
De handigste manier om praktijkervaring op te doen is op Kaggle; deelname aan een van de competities van het platform levert meer dan een jaar theoriestudie op. Op dit platform kunt u de geposte en becommentarieerde code van iemand anders gebruiken en proberen deze te verbeteren en voor uw doeleinden te optimaliseren. Bonus - uw Kaggle-rang heeft invloed op uw salaris.
Een andere optie is om als backend-ontwikkelaar deel uit te maken van het ML-team. Er zijn veel machine learning startups waar je ervaring kunt opdoen door je collega’s te helpen hun problemen op te lossen. Ten slotte kunt u lid worden van een van de datawetenschappergemeenschappen - Open Data Science (ods.ai) en anderen.
De spreker plaatste aanvullende informatie over het onderwerp op de link
"Quadrupel" - een dienst voor gerichte meldingen van het portaal "State Services"
Jevgeni Smirnov
De volgende spreker was het hoofd van de afdeling voor de ontwikkeling van e-overheidsinfrastructuur, Evgeny Smirnov, die sprak over Quadruple. Dit is een gerichte meldingsdienst voor het Gosuslugi-portaal (gosuslugi.ru), de meest bezochte overheidsbron op Runet. Het dagelijkse publiek bedraagt 2,6 miljoen, in totaal zijn er 90 miljoen geregistreerde gebruikers op de site, waarvan 60 miljoen bevestigd. De belasting van de portal-API is 30 RPS.
Technologieën die worden gebruikt in de backend van staatsdiensten
“Quadrupel” is een gerichte notificatiedienst, met behulp waarvan de gebruiker op het voor hem meest geschikte moment een aanbod voor een dienst ontvangt door het instellen van speciale notificatieregels. De belangrijkste vereisten bij het ontwikkelen van de dienst waren flexibele instellingen en voldoende tijd voor mailings.
Hoe werkt Quadrupel?
Het bovenstaande diagram toont een van de werkingsregels van de Quadrupel aan de hand van het voorbeeld van een situatie waarin het rijbewijs moet worden vervangen. Eerst zoekt de service naar gebruikers waarvan de vervaldatum over een maand afloopt. Ze krijgen een banner te zien met het aanbod om de juiste service te ontvangen en er wordt een bericht per e-mail verzonden. Voor gebruikers van wie de deadline al is verstreken, veranderen de banner en de e-mail. Na een succesvolle uitwisseling van rechten ontvangt de gebruiker andere meldingen - met een voorstel om de gegevens in de identiteit bij te werken.
Technisch gezien zijn dit groovy scripts waarin de code is geschreven. De invoer is data, de uitvoer is waar/onwaar, komt overeen/komt niet overeen. Er zijn in totaal meer dan 50 regels - van het bepalen van de verjaardag van de gebruiker (de huidige datum is gelijk aan de geboortedatum van de gebruiker) tot complexe situaties. Elke dag identificeren deze regels ongeveer een miljoen matches: mensen die op de hoogte moeten worden gesteld.
Viervoudige meldingskanalen
Onder de motorkap van Quadrupel bevinden zich een database waarin gebruikersgegevens worden opgeslagen, en drie applicaties:
- Arbeider bedoeld voor het bijwerken van gegevens.
- Rest API haalt de banners zelf op en levert deze af in de portal en mobiele applicatie.
- Scheduler lanceert werkzaamheden voor het herberekenen van banners of massamailings.
Om gegevens bij te werken, is de backend gebeurtenisgestuurd. Twee interfaces - rust of JMS. Er zijn veel gebeurtenissen; voordat ze worden opgeslagen en verwerkt, worden ze samengevoegd om geen onnodige verzoeken te doen. De database zelf, de tabel waarin de gegevens zijn opgeslagen, ziet eruit als een sleutelwaardeopslag - de sleutel van de gebruiker en de waarde zelf: vlaggen die de aanwezigheid of afwezigheid van relevante documenten aangeven, hun geldigheidsduur, geaggregeerde statistieken over de volgorde van services door deze gebruiker, enzovoort.
Na het opslaan van de gegevens wordt er een taak ingesteld in JMS zodat de banners direct opnieuw worden berekend - dit moet direct op internet worden weergegeven. Het systeem start 's nachts: taken worden met gebruikersintervallen in JMS gegooid, op basis waarvan de regels opnieuw moeten worden berekend. Dit wordt opgevangen door de bij de herberekening betrokken verwerkers. Vervolgens gaan de verwerkingsresultaten naar de volgende wachtrij, die de banners in de database opslaat of gebruikersmeldingstaken naar de service stuurt. Het proces duurt 5-7 uur en is gemakkelijk schaalbaar omdat u altijd handlers kunt toevoegen of instances kunt verhogen met nieuwe handlers.
De dienst werkt redelijk goed. Maar het datavolume groeit naarmate er meer gebruikers zijn. Dit leidt tot een toename van de belasting van de database – zelfs als je rekening houdt met het feit dat de Rest API naar de replica kijkt. Het tweede punt is JMS, dat, zo bleek, niet erg geschikt is vanwege het hoge geheugenverbruik. Er is een groot risico op overloop in de wachtrij, waardoor JMS crasht en de verwerking stopt. Het is hierna onmogelijk om JMS op te halen zonder de logbestanden te wissen.
Het is de bedoeling om de problemen op te lossen met behulp van sharding, waardoor de belasting van de database kan worden verdeeld. Er zijn ook plannen om het gegevensopslagschema te wijzigen en JMS te veranderen in Kafka - een meer fouttolerante oplossing die geheugenproblemen oplost.
Backend-as-a-Service vs. Serverloos
Van links naar rechts: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend as a service of serverloze oplossing? Deelnemers aan de discussie over dit urgente onderwerp aan de ronde tafel waren:
- Ara Israelyan, CTO CTO en oprichter van Scorocode.
- Nikolay Markov, senior data-ingenieur bij Aligned Research Group.
- Andrey Tomilenko, hoofd van de ontwikkelingsafdeling van RUVDS.
Het gesprek werd gemodereerd door senior ontwikkelaar Alexander Borgart. We presenteren de debatten waaraan de luisteraars ook deelnamen in een verkorte versie.
— Wat is serverloos volgens jou?
Andrew: Dit is een rekenmodel - een Lambda-functie die gegevens moet verwerken zodat het resultaat alleen van de gegevens afhangt. De term kwam van Google of van Amazon en zijn AWS Lambda-service. Het is voor een aanbieder gemakkelijker om een dergelijke functie uit te voeren door er een capaciteitspool voor toe te wijzen. Op dezelfde servers kunnen verschillende gebruikers onafhankelijk worden geregistreerd.
Nicholas: Simpel gezegd: we brengen een deel van onze IT-infrastructuur en bedrijfslogica over naar de cloud, naar outsourcing.
ara: Van de kant van ontwikkelaars - een goede poging om middelen te besparen, van de kant van marketeers - om meer geld te verdienen.
— Is serverloos hetzelfde als microservices?
Nicholas: Nee, Serverless is meer een architectuurorganisatie. Een microservice is een atomaire eenheid van een bepaalde logica. Serverloos is een aanpak, geen ‘afzonderlijke entiteit’.
ara: Een serverloze functie kan worden verpakt in een microservice, maar deze zal niet langer serverloos zijn, het zal niet langer een Lambda-functie zijn. Bij Serverless gaat een functie pas werken op het moment dat deze wordt opgevraagd.
Andrew: Ze verschillen tijdens hun leven. We lanceerden de Lambda-functie en vergaten deze. Het werkte een paar seconden en de volgende klant kan zijn verzoek op een andere fysieke machine verwerken.
– Welke schaal is beter?
ara: Bij horizontaal schalen gedragen Lambda-functies zich precies hetzelfde als microservices.
Nicholas: Welk aantal replica's u ook instelt, er zullen er evenveel zijn; Serverless heeft geen problemen met schalen. Ik heb een replicaset gemaakt in Kubernetes, twintig instances ‘ergens’ gelanceerd en twintig anonieme links zijn naar je teruggestuurd. Vooruit!
— Is het mogelijk om een backend op Serverless te schrijven?
Andrew: Theoretisch, maar het slaat nergens op. Lambda-functies zullen afhankelijk zijn van één enkele repository - we moeten garantie garanderen. Als een gebruiker bijvoorbeeld een bepaalde transactie heeft uitgevoerd, zou hij de volgende keer dat hij contact opneemt, moeten zien: de transactie is uitgevoerd, het geld is bijgeschreven. Bij deze oproep worden alle Lambda-functies geblokkeerd. In feite zullen een aantal serverloze functies veranderen in één enkele service met één knelpunttoegangspunt tot de database.
— In welke situaties is het zinvol om serverloze architectuur te gebruiken?
Andrew: Taken waarvoor geen gedeelde opslag vereist is - dezelfde mining, blockchain. Waar je veel moet tellen. Als je veel rekenkracht hebt, kun je een functie definiëren als "bereken daar de hash van iets..." Maar je kunt het probleem met gegevensopslag oplossen door bijvoorbeeld Lambda-functies van Amazon en hun gedistribueerde opslag te gebruiken. . En het blijkt dat u een reguliere dienst schrijft. Lambda-functies hebben toegang tot de opslag en geven een antwoord aan de gebruiker.
Nicholas: Containers die in Serverless draaien, zijn uiterst beperkt in bronnen. Er is weinig geheugen en al het andere. Maar als je hele infrastructuur volledig op een of andere cloud wordt ingezet - Google, Amazon - en je hebt een vast contract bij hen, is daar een budget voor, dan kun je voor sommige taken Serverless containers gebruiken. Het is noodzakelijk om binnen deze infrastructuur te zijn, omdat alles is afgestemd op gebruik in een specifieke omgeving. Dat wil zeggen: als u er klaar voor bent om alles aan de cloudinfrastructuur te koppelen, kunt u experimenteren. Het voordeel is dat u deze infrastructuur niet hoeft te beheren.
ara: Het feit dat Serverless niet vereist dat u Kubernetes, Docker beheert, Kafka installeert, enzovoort, is zelfbedrog. Dezelfde Amazon en Google installeren dit. Een ander ding is dat je een SLA hebt. Je kunt net zo goed alles uitbesteden in plaats van het zelf te coderen.
Andrew: Serverless op zichzelf is goedkoop, maar voor andere Amazon-diensten (bijvoorbeeld de database) moet je veel betalen. Mensen hebben ze al aangeklaagd omdat ze waanzinnige bedragen in rekening brachten voor de API-poort.
ara: Als we het over geld hebben, moet je rekening houden met dit punt: je zult de hele ontwikkelingsmethodologie in het bedrijf 180 graden moeten draaien om alle code naar Serverless over te zetten. Dit zal veel tijd en geld kosten.
— Zijn er waardige alternatieven voor het betaalde Serverless van Amazon en Google?
Nicholas: In Kubernetes lanceer je een soort taak, deze loopt en sterft - dit is vanuit architectonisch oogpunt behoorlijk serverloos. Als je echt interessante bedrijfslogica wilt creëren met wachtrijen en databases, dan moet je er wat meer over nadenken. Dit kan allemaal worden opgelost zonder Kubernetes te verlaten. Ik zou niet de moeite nemen om extra implementatie uit te slepen.
— Hoe belangrijk is het om te monitoren wat er gebeurt in Serverless?
ara: Afhankelijk van de systeemarchitectuur en zakelijke vereisten. In wezen moet de provider rapportage leveren die het devops-team helpt mogelijke problemen te begrijpen.
Nicholas: Amazon heeft CloudWatch, waar alle logs worden gestreamd, ook die van Lambda. Integreer het doorsturen van logboeken en gebruik een aparte tool voor bekijken, waarschuwen, enzovoort. Je kunt agenten in de containers stoppen die je start.
- Laten we het samenvatten.
Andrew: Nadenken over Lambda-functies is nuttig. Als u zelf een service maakt - geen microservice, maar een die een verzoek schrijft, toegang krijgt tot de database en een antwoord verzendt - lost de Lambda-functie een aantal problemen op: met multithreading, schaalbaarheid, enzovoort. Als uw logica op deze manier is gebouwd, kunt u in de toekomst deze Lambda's overbrengen naar microservices of diensten van derden zoals Amazon gebruiken. De technologie is nuttig, het idee is interessant. Hoe gerechtvaardigd dit is voor het bedrijfsleven is nog steeds een open vraag.
Nikolay: Serverloos wordt beter gebruikt voor operationele taken dan voor het berekenen van bepaalde bedrijfslogica. Ik beschouw het altijd als gebeurtenisverwerking. Als je het in Amazon hebt, als je in Kubernetes zit, ja. Anders zul je behoorlijk wat moeite moeten doen om Serverless zelf aan de slag te krijgen. Het is noodzakelijk om naar een specifieke business case te kijken. Een van mijn taken is nu bijvoorbeeld: wanneer bestanden in een bepaald formaat op schijf verschijnen, moet ik ze naar Kafka uploaden. Ik kan WatchDog of Lambda gebruiken. Vanuit logisch oogpunt zijn beide opties geschikt, maar qua implementatie is Serverless ingewikkelder, en ik geef de voorkeur aan de eenvoudigere manier, zonder Lambda.
ara: Serverless is een interessant, toepasbaar en technisch zeer mooi idee. Vroeg of laat zal de technologie het punt bereiken waarop elke functie in minder dan 100 milliseconden wordt gelanceerd. Dan is er in principe geen sprake van of de wachttijd kritisch is voor de gebruiker. Tegelijkertijd hangt de toepasbaarheid van Serverless, zoals collega’s al zeiden, volledig af van het bedrijfsprobleem.
Wij danken onze sponsors die ons enorm geholpen hebben:
- IT-conferentieruimte «» voor de conferentiesite.
- Kalender met IT-evenementen en publicatie"» voor informatieondersteuning en nieuws.
- «"voor cadeaus.
- voor co-creatie.
- "Vereniging voor elektronische communicatie" voor betrokkenheid en ervaring.
- Hoofdsponsor - voor iedereen!
Bron: www.habr.com