La conferenza Habr non è una storia d’esordio. In precedenza, organizzavamo eventi Toaster abbastanza grandi per 300-400 persone, ma ora abbiamo deciso che sarebbero stati rilevanti piccoli incontri tematici, la cui direzione puoi impostare, ad esempio, nei commenti. La prima conferenza di questo formato si è tenuta a luglio ed era dedicata allo sviluppo del backend. I partecipanti hanno ascoltato relazioni sulle funzionalità del passaggio dal backend al ML e sulla progettazione del servizio Quadrupel sul portale dei Servizi di Stato, oltre ad aver preso parte ad una tavola rotonda dedicata al Serverless. Per chi non ha potuto partecipare di persona all'evento, in questo post vi raccontiamo le cose più interessanti.
Dallo sviluppo backend al machine learning
Cosa fanno gli ingegneri dei dati in ML? In che modo i compiti di uno sviluppatore backend e di un ingegnere ML sono simili e diversi? Quale percorso devi intraprendere per cambiare la tua prima professione nella seconda? Lo ha detto Alexander Parinov, che è entrato nel machine learning dopo 10 anni di lavoro di backend.
Aleksandr Parinov
Oggi Alexander lavora come architetto di sistemi di visione artificiale presso X5 Retail Group e contribuisce a progetti Open Source relativi alla visione artificiale e al deep learning (github.com/creafz). Le sue capacità sono confermate dalla sua partecipazione nella top 100 della classifica mondiale di Kaggle Master (kaggle.com/creafz), la piattaforma più popolare per le gare di machine learning.
Perché passare al machine learning
Un anno e mezzo fa, Jeff Dean, capo di Google Brain, il progetto di ricerca sull’intelligenza artificiale basato sul deep learning di Google, descrisse come mezzo milione di righe di codice in Google Translate furono sostituite da una rete neurale Tensor Flow composta da sole 500 righe. Dopo aver addestrato la rete, la qualità dei dati è aumentata e l'infrastruttura è diventata più semplice. Sembrerebbe che questo sia il nostro futuro luminoso: non dobbiamo più scrivere codici, basta creare neuroni e riempirli di dati. Ma in pratica tutto è molto più complicato.
Infrastruttura ML presso Google
Le reti neurali sono solo una piccola parte dell'infrastruttura (il quadratino nero nella foto sopra). Sono necessari molti più sistemi ausiliari per ricevere dati, elaborarli, archiviarli, verificare la qualità, ecc., Abbiamo bisogno di infrastrutture per la formazione, l'implementazione del codice di apprendimento automatico in produzione e il test di questo codice. Tutte queste attività sono esattamente simili a quelle svolte dagli sviluppatori backend.
Processo di apprendimento automatico
Qual è la differenza tra ML e backend?
Nella programmazione classica, scriviamo codice e questo determina il comportamento del programma. In ML, abbiamo un piccolo codice modello e molti dati che inseriamo nel modello. I dati in ML sono molto importanti: lo stesso modello addestrato su dati diversi può mostrare risultati completamente diversi. Il problema è che i dati sono quasi sempre sparsi e archiviati in sistemi diversi (database relazionali, database NoSQL, log, file).
Versionamento dei dati
Il ML richiede il controllo delle versioni non solo del codice, come nello sviluppo classico, ma anche dei dati: è necessario capire chiaramente su cosa è stato addestrato il modello. Per fare ciò, puoi utilizzare la popolare libreria Data Science Version Control (dvc.org).
Markup dei dati
Il compito successivo è l'etichettatura dei dati. Ad esempio, contrassegna tutti gli oggetti nell'immagine o dì a quale classe appartiene. Ciò viene fatto da servizi speciali come Yandex.Toloka, il cui lavoro è notevolmente semplificato dalla presenza di un'API. Le difficoltà nascono dal “fattore umano”: è possibile migliorare la qualità dei dati e ridurre al minimo gli errori affidando lo stesso compito a più esecutori.
Visualizzazione in Tensor Board
La registrazione degli esperimenti è necessaria per confrontare i risultati e selezionare il modello migliore in base ad alcune metriche. Esiste un ampio set di strumenti per la visualizzazione, ad esempio Tensor Board. Ma non esistono modi ideali per archiviare gli esperimenti. Le piccole aziende spesso si accontentano di un foglio di calcolo Excel, mentre quelle grandi utilizzano piattaforme speciali per archiviare i risultati in un database.
Esistono molte piattaforme per il machine learning, ma nessuna copre il 70% delle esigenze
Il primo problema che si deve affrontare quando si mette in produzione un modello addestrato è legato allo strumento preferito dai data scientist: Jupyter Notebook. Non c'è modularità in esso, cioè l'output è una tale "copertura" di codice che non è divisa in pezzi logici: moduli. Tutto è confuso: classi, funzioni, configurazioni, ecc. Questo codice è difficile da controllare e testare.
Come affrontare questo problema? Puoi rassegnarti, come Netflix, e creare la tua piattaforma che ti permetta di lanciare questi laptop direttamente in produzione, trasferire loro i dati come input e ottenere risultati. Puoi forzare gli sviluppatori che stanno mettendo in produzione il modello a riscrivere il codice normalmente, suddividendolo in moduli. Ma con questo approccio è facile commettere un errore e il modello non funzionerà come previsto. Pertanto, l'opzione ideale è vietare l'uso di Jupyter Notebook per il codice modello. Se, ovviamente, i data scientist sono d’accordo.
Modello come scatola nera
Il modo più semplice per mettere in produzione un modello è usarlo come una scatola nera. Hai una sorta di classe del modello, ti sono stati dati i pesi del modello (parametri dei neuroni della rete addestrata) e se inizializzi questa classe (chiama il metodo predittivo, inserisci un'immagine), otterrai un certo previsione come output. Quello che succede dentro non ha importanza.
Processo server separato con il modello
Puoi anche avviare un determinato processo separato e inviarlo tramite una coda RPC (con immagini o altri dati di origine. All'output riceveremo previsioni.
Un esempio di utilizzo di un modello 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)
Il problema con questo approccio è la limitazione delle prestazioni. Diciamo che abbiamo un codice Phyton scritto da data scientist che è lento e vogliamo ottenere le massime prestazioni. Per fare ciò, puoi utilizzare strumenti che convertono il codice in nativo o lo convertono in un altro framework su misura per la produzione. Esistono strumenti di questo tipo per ogni framework, ma non esistono quelli ideali; dovrai aggiungerli tu stesso.
L'infrastruttura in ML è la stessa di un normale backend. Esistono Docker e Kubernetes, solo per Docker è necessario installare il runtime da NVIDIA, che consente ai processi all'interno del contenitore di accedere alle schede video nell'host. Kubernetes necessita di un plugin per poter gestire i server con schede video.
A differenza della programmazione classica, nel caso del ML ci sono molti diversi elementi mobili nell'infrastruttura che devono essere controllati e testati, ad esempio il codice di elaborazione dei dati, la pipeline di addestramento del modello e la produzione (vedi diagramma sopra). È importante testare il codice che collega diversi pezzi di pipeline: ci sono molti pezzi e molto spesso sorgono problemi ai confini dei moduli.
Come funziona AutoML
I servizi AutoML promettono di selezionare il modello ottimale per i tuoi scopi e di addestrarlo. Ma devi capire: i dati sono molto importanti nel ML, il risultato dipende dalla loro preparazione. Il markup viene eseguito da persone, il che è pieno di errori. Senza un controllo rigoroso, il risultato potrebbe essere spazzatura e non è ancora possibile automatizzare il processo; è necessaria la verifica da parte di specialisti, i data scientist. È qui che AutoML non funziona più. Ma può essere utile per selezionare un'architettura, quando hai già preparato i dati e desideri eseguire una serie di esperimenti per trovare il modello migliore.
Come entrare nel machine learning
Il modo più semplice per entrare nel ML è sviluppare in Python, che viene utilizzato in tutti i framework di deep learning (e framework normali). Questa lingua è praticamente obbligatoria per questo campo di attività. Il C++ viene utilizzato per alcune attività di visione artificiale, ad esempio nei sistemi di controllo per le auto a guida autonoma. JavaScript e Shell: per la visualizzazione e cose strane come l'esecuzione di un neurone nel browser. Java e Scala vengono utilizzati quando si lavora con Big Data e per l'apprendimento automatico. R e Julia sono amati dalle persone che studiano statistica matematica.
Il modo più conveniente per iniziare a fare esperienza pratica è su Kaggle; la partecipazione a uno dei concorsi della piattaforma dà più di un anno di studio della teoria. Su questa piattaforma puoi prendere il codice pubblicato e commentato da qualcun altro e provare a migliorarlo, ottimizzarlo per i tuoi scopi. Bonus: il tuo grado Kaggle influisce sul tuo stipendio.
Un'altra opzione è unirsi al team ML come sviluppatore backend. Esistono molte startup di machine learning in cui puoi acquisire esperienza aiutando i tuoi colleghi a risolvere i loro problemi. Infine, puoi unirti a una delle comunità di data scientist: Open Data Science (ods.ai) e altre.
Il relatore ha pubblicato ulteriori informazioni sull'argomento al collegamento
"Quadrupel" - un servizio di notifiche mirate del portale "Servizi statali"
Evgeny Smirnov
Il relatore successivo è stato il capo del dipartimento per lo sviluppo delle infrastrutture dell'e-government, Evgeny Smirnov, che ha parlato di Quadruple. Questo è un servizio di notifica mirato per il portale Gosuslugi (gosuslugi.ru), la risorsa governativa più visitata sulla Runet. L'audience giornaliera è di 2,6 milioni, in totale sono 90 milioni gli utenti registrati al sito, di cui 60 milioni confermati. Il carico sull'API del portale è di 30mila RPS.
Tecnologie utilizzate nel backend dei servizi statali
"Quadrupel" è un servizio di notifica mirato, con l'aiuto del quale l'utente riceve un'offerta di servizio nel momento a lui più adatto impostando speciali regole di notifica. I requisiti principali nello sviluppo del servizio erano impostazioni flessibili e tempo adeguato per gli invii.
Come funziona Quadrupel?
Il diagramma sopra mostra una delle regole di funzionamento del Quadrupel utilizzando l'esempio di una situazione con la necessità di sostituire la patente di guida. Innanzitutto, il servizio cerca gli utenti la cui data di scadenza scade tra un mese. Viene mostrato loro un banner con un'offerta per ricevere il servizio appropriato e viene inviato un messaggio via email. Per gli utenti la cui scadenza è già scaduta, cambiano il banner e la mail. Dopo uno scambio di diritti riuscito, l'utente riceve altre notifiche - con una proposta per aggiornare i dati nell'identità.
Da un punto di vista tecnico si tratta di script fantastici in cui è scritto il codice. L'input sono dati, l'output è vero/falso, corrispondente/non corrispondente. Esistono più di 50 regole in totale: dalla determinazione del compleanno dell'utente (la data corrente è uguale alla data di nascita dell'utente) a situazioni complesse. Ogni giorno, queste regole identificano circa un milione di corrispondenze, persone che necessitano di essere avvisate.
Canali di notifica quadrupli
Sotto il cofano di Quadrupel c'è un database in cui sono archiviati i dati dell'utente e tre applicazioni:
- Lavoratore destinato all'aggiornamento dei dati.
- API REST ritira e consegna i banner stessi al portale e all'applicazione mobile.
- Scheduler avvia i lavori di ricalcolo dei banner o degli invii di massa.
Per aggiornare i dati, il backend è guidato dagli eventi. Due interfacce: resto o JMS. Gli eventi sono moltissimi e prima di essere salvati ed elaborati vengono aggregati in modo da non fare richieste inutili. Il database stesso, la tabella in cui sono archiviati i dati, si presenta come un archivio di valori chiave: la chiave dell'utente e il valore stesso: flag che indicano la presenza o l'assenza di documenti rilevanti, il loro periodo di validità, statistiche aggregate sull'ordine dei servizi per questo utente e così via.
Dopo aver salvato i dati, in JMS viene impostata un'attività in modo che i banner vengano immediatamente ricalcolati: questi devono essere immediatamente visualizzati sul web. Il sistema si avvia di notte: le attività vengono inserite in JMS a intervalli utente, in base ai quali è necessario ricalcolare le regole. Questo viene rilevato dai processori coinvolti nel ricalcolo. Successivamente, i risultati dell'elaborazione passano alla coda successiva, che salva i banner nel database o invia attività di notifica all'utente al servizio. Il processo richiede 5-7 ore ed è facilmente scalabile poiché puoi sempre aggiungere gestori o generare istanze con nuovi gestori.
Il servizio funziona abbastanza bene. Ma il volume dei dati cresce poiché ci sono più utenti. Ciò porta ad un aumento del carico sul database, anche tenendo conto del fatto che l'API Rest esamina la replica. Il secondo punto è JMS, che, come si è scoperto, non è molto adatto a causa dell'elevato consumo di memoria. Esiste un rischio elevato di overflow della coda che causa l'arresto anomalo di JMS e l'interruzione dell'elaborazione. Successivamente è impossibile ripristinare JMS senza cancellare i log.
Si prevede di risolvere i problemi utilizzando lo sharding, che consentirà di bilanciare il carico sul database. Ci sono anche piani per cambiare lo schema di archiviazione dei dati e cambiare JMS in Kafka, una soluzione più tollerante agli errori che risolverà i problemi di memoria.
Backend-as-a-Service vs. Senza server
Da sinistra a destra: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend come servizio o soluzione serverless? I partecipanti alla discussione su questa questione urgente durante la tavola rotonda sono stati:
- Ara Israelyan, CTO CTO e fondatore di Scorocode.
- Nikolay Markov, Senior Data Engineer presso Aligned Research Group.
- Andrey Tomilenko, capo del dipartimento di sviluppo RUVDS.
La conversazione è stata moderata dallo sviluppatore senior Alexander Borgart. Presentiamo in versione abbreviata i dibattiti ai quali hanno partecipato anche gli ascoltatori.
— Cos'è Serverless secondo te?
Andrew: Questo è un modello di calcolo, una funzione Lambda che deve elaborare i dati in modo che il risultato dipenda solo dai dati. Il termine deriva da Google o da Amazon e dal suo servizio AWS Lambda. È più semplice per un fornitore gestire tale funzione assegnandole un pool di capacità. È possibile contabilizzare diversi utenti in modo indipendente sugli stessi server.
Nicholas: Per dirla semplicemente, stiamo trasferendo parte della nostra infrastruttura IT e della nostra logica aziendale nel cloud, in outsourcing.
ara: Da parte degli sviluppatori - un buon tentativo di risparmiare risorse, da parte degli esperti di marketing - di guadagnare di più.
— Serverless è uguale ai microservizi?
Nicholas: No, Serverless è più un'organizzazione basata su un'architettura. Un microservizio è un'unità atomica con una certa logica. Serverless è un approccio, non una “entità separata”.
ara: una funzione Serverless può essere inserita in un microservizio, ma questo non sarà più Serverless e cesserà di essere una funzione Lambda. In Serverless una funzione inizia a funzionare solo nel momento in cui viene richiesta.
Andrew: Differiscono nella loro vita. Abbiamo lanciato la funzione Lambda e l'abbiamo dimenticata. Ha funzionato per un paio di secondi e il client successivo può elaborare la sua richiesta su un'altra macchina fisica.
— Quale scala è migliore?
ara: Quando si ridimensionano orizzontalmente, le funzioni Lambda si comportano esattamente come i microservizi.
Nicholas: Qualunque sia il numero di repliche impostate, ce ne saranno altrettante; Serverless non ha problemi con il ridimensionamento. Ho creato un set di repliche in Kubernetes, ho lanciato 20 istanze "da qualche parte" e ti sono stati restituiti 20 collegamenti anonimi. Inoltrare!
— È possibile scrivere un backend su Serverless?
Andrew: In teoria, ma non ha senso. Le funzioni Lambda faranno affidamento su un unico repository: dobbiamo garantire la garanzia. Ad esempio, se un utente ha effettuato una determinata transazione, la prossima volta che contatterà dovrebbe vedere: la transazione è stata eseguita, i fondi sono stati accreditati. Tutte le funzioni Lambda si bloccheranno su questa chiamata. In effetti, un insieme di funzioni Serverless si trasformerà in un unico servizio con un punto di accesso collo di bottiglia al database.
— In quali situazioni ha senso utilizzare l'architettura serverless?
Andrew: Attività che non richiedono archiviazione condivisa: lo stesso mining, blockchain. Dove devi contare molto. Se disponi di molta potenza di calcolo, puoi definire una funzione come "calcola l'hash di qualcosa lì...". Ma puoi risolvere il problema con l'archiviazione dei dati prendendo, ad esempio, le funzioni Lambda di Amazon e il loro storage distribuito . E si scopre che stai scrivendo un servizio regolare. Le funzioni Lambda accederanno allo spazio di archiviazione e forniranno un qualche tipo di risposta all'utente.
Nicholas: i contenitori eseguiti in Serverless hanno risorse estremamente limitate. C'è poca memoria e tutto il resto. Ma se la tua intera infrastruttura è distribuita interamente su qualche cloud - Google, Amazon - e hai un contratto permanente con loro, c'è un budget per tutto questo, quindi per alcune attività puoi utilizzare contenitori Serverless. È necessario essere all'interno di questa infrastruttura, perché tutto è adattato per l'uso in un ambiente specifico. Cioè, se sei pronto a collegare tutto all'infrastruttura cloud, puoi sperimentare. Il vantaggio è che non devi gestire questa infrastruttura.
ara: Il fatto che Serverless non richieda la gestione di Kubernetes, Docker, l'installazione di Kafka e così via è un autoinganno. Gli stessi Amazon e Google lo stanno installando. Un'altra cosa è che hai uno SLA. Potresti anche esternalizzare tutto piuttosto che codificarlo tu stesso.
Andrew: Serverless in sé è poco costoso, ma devi pagare molto per altri servizi Amazon, ad esempio il database. Le persone li hanno già denunciati perché hanno addebitato cifre assurde per il gate API.
ara: Se parliamo di soldi, allora devi tenere conto di questo punto: dovrai trasformare di 180 gradi l'intera metodologia di sviluppo dell'azienda per trasferire tutto il codice su Serverless. Ciò richiederà molto tempo e denaro.
— Esistono valide alternative al Serverless a pagamento di Amazon e Google?
Nicholas: In Kubernetes, avvii una sorta di lavoro, questo viene eseguito e muore: questo è abbastanza Serverless dal punto di vista architettonico. Se vuoi creare una logica aziendale davvero interessante con code e database, devi pensarci un po' di più. Tutto questo può essere risolto senza lasciare Kubernetes. Non mi preoccuperei di trascinare ulteriori implementazioni.
— Quanto è importante monitorare ciò che accade in Serverless?
ara: dipende dall'architettura del sistema e dai requisiti aziendali. In sostanza, il fornitore deve fornire report che aiutino il team devops a comprendere i possibili problemi.
Nicholas: Amazon dispone di CloudWatch, dove vengono trasmessi in streaming tutti i log, inclusi quelli di Lambda. Integra l'inoltro dei log e utilizza uno strumento separato per la visualizzazione, gli avvisi e così via. Puoi inserire gli agenti nei contenitori che avvii.
- Riassumiamo.
Andrew: Pensare alle funzioni Lambda è utile. Se crei un servizio da solo - non un microservizio, ma uno che scrive una richiesta, accede al database e invia una risposta - la funzione Lambda risolve una serie di problemi: con multithreading, scalabilità e così via. Se la tua logica è costruita in questo modo, in futuro sarai in grado di trasferire questi Lambda a microservizi o utilizzare servizi di terze parti come Amazon. La tecnologia è utile, l’idea è interessante. Quanto sia giustificato per le imprese è ancora una questione aperta.
Nikolay: Serverless è meglio utilizzato per le attività operative che per il calcolo di una logica aziendale. Lo considero sempre come un'elaborazione di eventi. Se lo hai su Amazon, se sei su Kubernetes, sì. Altrimenti, dovrai impegnarti parecchio per far funzionare Serverless da solo. È necessario esaminare un caso aziendale specifico. Ad esempio, uno dei miei compiti ora è: quando i file appaiono sul disco in un determinato formato, devo caricarli su Kafka. Posso usare WatchDog o Lambda. Da un punto di vista logico entrambe le opzioni sono adatte, ma in termini di implementazione Serverless è più complicato e preferisco il modo più semplice, senza Lambda.
ara: Serverless è un'idea interessante, applicabile e molto bella dal punto di vista tecnico. Prima o poi la tecnologia arriverà al punto in cui qualsiasi funzione verrà avviata in meno di 100 millisecondi. Quindi, in linea di principio, non ci sarà alcuna questione se il tempo di attesa sia critico per l'utente. Allo stesso tempo, l'applicabilità di Serverless, come hanno già detto i colleghi, dipende completamente dal problema aziendale.
Ringraziamo i nostri sponsor che ci hanno aiutato molto:
- Spazio conferenze IT «» per il sito della conferenza.
- Calendario degli eventi informatici e pubblicazione"» per supporto informativo e novità.
- «"per i regali.
- per la co-creazione.
- "Associazione per le Comunicazioni Elettroniche" per il tuo coinvolgimento e la tua esperienza.
- Sponsor principale - per tutti!
Fonte: habr.com