Konferencja Habr nie jest historią debiutu. Wcześniej organizowaliśmy dość duże eventy Toaster na 300-400 osób, jednak teraz uznaliśmy, że trafne będą małe spotkania tematyczne, których kierunek możecie nadawać np. w komentarzach. Pierwsza konferencja w tym formacie odbyła się w lipcu i była poświęcona rozwojowi backendu. Uczestnicy wysłuchali raportów na temat cech przejścia z backendu na ML oraz projektu usługi Quadrupel na portalu State Services, a także wzięli udział w okrągłym stole poświęconym Serverless. Dla tych, którzy nie mogli być na wydarzeniu osobiście, w tym poście przedstawiamy najciekawsze rzeczy.
Od backendu po uczenie maszynowe
Co inżynierowie danych robią w ML? W jaki sposób zadania programisty backendowego i inżyniera ML są podobne, a jakie różne? Jaką drogę musisz obrać, aby zmienić swój pierwszy zawód na drugi? Opowiedział to Alexander Parinov, który po 10 latach pracy w backendzie zajął się uczeniem maszynowym.
Aleksander Parinow
Dziś Alexander pracuje jako architekt systemów wizyjnych w X5 Retail Group i uczestniczy w projektach Open Source związanych z wizją komputerową i głębokim uczeniem się (github.com/creafz). Potwierdzeniem jego umiejętności jest udział w pierwszej setce światowego rankingu Kaggle Master (kaggle.com/creafz), najpopularniejszej platformy do konkursów uczenia maszynowego.
Po co przechodzić na uczenie maszynowe
Półtora roku temu Jeff Dean, szef Google Brain, projektu badawczego Google opartego na sztucznej inteligencji opartego na głębokim uczeniu, opisał, jak pół miliona linii kodu w Tłumaczu Google zostało zastąpionych siecią neuronową Tensor Flow składającą się tylko z 500 linii. Po przeszkoleniu sieci jakość danych wzrosła, a infrastruktura stała się prostsza. Wydawać by się mogło, że to jest nasza świetlana przyszłość: nie musimy już pisać kodu, wystarczy zrobić neurony i wypełnić je danymi. Ale w praktyce wszystko jest znacznie bardziej skomplikowane.
Infrastruktura uczenia maszynowego w Google
Sieci neuronowe to tylko niewielka część infrastruktury (mały czarny kwadrat na obrazku powyżej). Do odbioru danych, ich przetwarzania, przechowywania, sprawdzania jakości itp. potrzebnych jest znacznie więcej systemów pomocniczych, potrzebujemy infrastruktury do szkoleń, wdrażania kodu uczenia maszynowego na produkcji i testowania tego kodu. Wszystkie te zadania są dokładnie podobne do tego, co robią programiści backendowi.
Proces uczenia maszynowego
Jaka jest różnica między ML a backendem?
W programowaniu klasycznym piszemy kod i to dyktuje zachowanie programu. W ML mamy mały kod modelu i mnóstwo danych, które rzucamy na model. Dane w ML są bardzo ważne: ten sam model wyszkolony na różnych danych może pokazać zupełnie inne wyniki. Problem w tym, że dane prawie zawsze są rozproszone i przechowywane w różnych systemach (relacyjne bazy danych, bazy NoSQL, logi, pliki).
Wersjonowanie danych
ML wymaga wersjonowania nie tylko kodu, jak w przypadku klasycznego programowania, ale także danych: konieczne jest jasne zrozumienie, na czym model był szkolony. Można w tym celu skorzystać z popularnej biblioteki Data Science Version Control (dvc.org).
Znaczniki danych
Kolejnym zadaniem jest etykietowanie danych. Na przykład zaznacz wszystkie obiekty na obrazku lub powiedz, do której klasy on należy. Robią to specjalne usługi, takie jak Yandex.Toloka, z którymi praca jest znacznie uproszczona dzięki obecności API. Trudności pojawiają się ze względu na „czynnik ludzki”: można poprawić jakość danych i zredukować błędy do minimum, powierzając to samo zadanie kilku wykonawcom.
Wizualizacja w Tensor Board
Rejestrowanie eksperymentów jest konieczne, aby porównać wyniki i wybrać najlepszy model na podstawie niektórych metryk. Dostępny jest duży zestaw narzędzi do wizualizacji – np. Tensor Board. Nie ma jednak idealnych sposobów przechowywania eksperymentów. Małe firmy często korzystają z arkusza kalkulacyjnego Excel, natomiast duże korzystają ze specjalnych platform do przechowywania wyników w bazie danych.
Istnieje wiele platform do uczenia maszynowego, ale żadna z nich nie pokrywa 70% potrzeb
Pierwszy problem, z jakim trzeba się zmierzyć, wdrażając wytrenowany model do produkcji, wiąże się z ulubionym narzędziem analityków danych – Jupyter Notebook. Nie ma w nim modułowości, to znaczy wynik jest takim „obrusem” kodu, który nie jest podzielony na logiczne części - moduły. Wszystko jest pomieszane: klasy, funkcje, konfiguracje itp. Ten kod jest trudny do wersjonowania i testowania.
Jak sobie z tym poradzić? Możesz sam zrezygnować, tak jak Netflix, i stworzyć własną platformę, która pozwoli Ci uruchomić te laptopy bezpośrednio w produkcji, przesyłać do nich dane jako dane wejściowe i uzyskiwać wyniki. Możesz zmusić programistów wdrażających model do środowiska produkcyjnego, aby normalnie przepisali kod, dzieląc go na moduły. Ale przy takim podejściu łatwo popełnić błąd, a model nie będzie działał zgodnie z zamierzeniami. Dlatego idealną opcją jest zakazanie używania Jupyter Notebook do kodowania modelu. Jeśli oczywiście analitycy danych się na to zgodzą.
Model jako czarna skrzynka
Najłatwiejszym sposobem wprowadzenia modelu do produkcji jest użycie go jako czarnej skrzynki. Masz jakąś klasę modelu, otrzymałeś wagi modelu (parametry neuronów wytrenowanej sieci) i jeśli zainicjujesz tę klasę (wywołasz metodę przewidywania, podasz jej obraz), otrzymasz pewien przewidywanie jako wynik. To, co dzieje się w środku, nie ma znaczenia.
Oddziel proces serwera z modelem
Można też wywołać pewien osobny proces i wysłać go przez kolejkę RPC (ze zdjęciami lub innymi danymi źródłowymi. Na wyjściu otrzymamy predykcje).
Przykład użycia modelu w Flasku:
@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)
Problemem tego podejścia jest ograniczenie wydajności. Załóżmy, że mamy powolny kod Phyton napisany przez analityków danych i chcemy wycisnąć maksymalną wydajność. Można w tym celu skorzystać z narzędzi, które konwertują kod na natywny lub konwertują go na inny framework dostosowany do produkcji. Istnieją takie narzędzia dla każdego frameworka, ale nie ma idealnych, musisz je dodać sam.
Infrastruktura w ML jest taka sama jak w zwykłym backendie. Istnieją Docker i Kubernetes, tylko w przypadku Dockera należy zainstalować środowisko uruchomieniowe firmy NVIDIA, które umożliwia procesom wewnątrz kontenera dostęp do kart graficznych w hoście. Kubernetes potrzebuje wtyczki, aby móc zarządzać serwerami z kartami graficznymi.
W przeciwieństwie do programowania klasycznego, w przypadku ML istnieje wiele różnych ruchomych elementów infrastruktury, które należy sprawdzić i przetestować – na przykład kod przetwarzania danych, potok uczenia modelu i produkcja (patrz diagram powyżej). Ważne jest, aby przetestować kod łączący różne fragmenty potoków: jest ich wiele, a problemy bardzo często pojawiają się na granicach modułów.
Jak działa AutoML
Usługi AutoML obiecują wybrać optymalny model do Twoich celów i go przeszkolić. Ale musisz zrozumieć: dane są bardzo ważne w ML, wynik zależy od ich przygotowania. Znaczniki dokonują ludzie, co jest obarczone błędami. Bez ścisłej kontroli wynik może być tandetny, a automatyzacja procesu nie jest jeszcze możliwa, konieczna jest weryfikacja przez specjalistów - analityków danych. W tym miejscu AutoML się psuje. Może się jednak przydać przy wyborze architektury – gdy masz już przygotowane dane i chcesz przeprowadzić serię eksperymentów, aby znaleźć najlepszy model.
Jak zacząć przygodę z uczeniem maszynowym
Najłatwiejszym sposobem na rozpoczęcie nauki ML jest programowanie w Pythonie, który jest używany we wszystkich frameworkach głębokiego uczenia się (i zwykłych frameworkach). Język ten jest praktycznie obowiązkowy w tej dziedzinie działalności. C++ jest używany do niektórych zadań związanych z wizją komputerową, na przykład w systemach sterowania samochodami autonomicznymi. JavaScript i Shell - do wizualizacji i takich dziwnych rzeczy jak uruchamianie neuronu w przeglądarce. Java i Scala są wykorzystywane podczas pracy z Big Data i do uczenia maszynowego. R i Julia są uwielbiane przez ludzi studiujących statystykę matematyczną.
Praktyczną wiedzę najwygodniej zdobyć na początek na platformie Kaggle, udział w jednym z konkursów platformy daje ponad rok nauki teorii. Na tej platformie możesz wykorzystać opublikowany i skomentowany przez kogoś kod i spróbować go ulepszyć, zoptymalizować do swoich celów. Bonus - Twoja ranga Kaggle wpływa na Twoją pensję.
Inną opcją jest dołączenie do zespołu ML jako backend developer. Istnieje wiele startupów zajmujących się uczeniem maszynowym, w których możesz zdobyć doświadczenie, pomagając swoim współpracownikom w rozwiązywaniu ich problemów. Wreszcie możesz dołączyć do jednej ze społeczności analityków danych - Open Data Science (ods.ai) i innych.
Prelegent zamieścił dodatkowe informacje na ten temat pod linkiem
„Quadrupel” – usługa ukierunkowanych powiadomień portalu „Służby Państwowe”
Jewgienij Smirnow
Kolejnym mówcą był szef wydziału rozwoju infrastruktury e-administracji, Jewgienij Smirnow, który mówił o Quadruple. Jest to ukierunkowana usługa powiadomień dla portalu Gosuslugi (gosuslugi.ru), najczęściej odwiedzanego zasobu rządowego w Runecie. Dzienna oglądalność wynosi 2,6 miliona, łącznie w serwisie zarejestrowanych jest 90 milionów użytkowników, z czego 60 milionów jest potwierdzonych. Obciążenie API portalu wynosi 30 tys. RPS.
Technologie stosowane w zapleczu usług stanowych
„Quadrupel” to ukierunkowana usługa powiadamiania, za pomocą której użytkownik otrzymuje ofertę usługi w najbardziej dogodnym dla niego momencie, ustalając specjalne zasady powiadamiania. Głównymi wymaganiami przy opracowywaniu usługi były elastyczne ustawienia i odpowiedni czas na wysyłki.
Jak działa Quadrupel?
Powyższy schemat przedstawia jedną z zasad działania Quadrupela na przykładzie sytuacji konieczności wymiany prawa jazdy. W pierwszej kolejności usługa wyszukuje użytkowników, których data ważności upływa za miesiąc. Wyświetlany jest im baner z ofertą otrzymania odpowiedniej usługi, po czym zostaje wysłana wiadomość e-mailem. Dla użytkowników, których termin już minął, baner i adres e-mail ulegają zmianie. Po udanej wymianie uprawnień użytkownik otrzymuje kolejne powiadomienia – z propozycją aktualizacji danych w tożsamości.
Z technicznego punktu widzenia są to świetne skrypty, w których napisany jest kod. Dane wejściowe to dane, dane wyjściowe to prawda/fałsz, dopasowanie/nie dopasowanie. Reguł jest w sumie ponad 50 – od ustalenia daty urodzenia użytkownika (aktualna data jest równa dacie urodzenia użytkownika) po skomplikowane sytuacje. Każdego dnia zasady te identyfikują około miliona dopasowań – osób, które należy powiadomić.
Poczwórne kanały powiadomień
Pod maską Quadrupela kryje się baza danych, w której przechowywane są dane użytkowników oraz trzy aplikacje:
- Pracownik przeznaczone do aktualizacji danych.
- Reszta API samodzielnie odbiera i dostarcza banery do portalu i aplikacji mobilnej.
- Scheduler rozpoczyna pracę nad przeliczaniem banerów czy masowych wysyłek.
Aby zaktualizować dane, backend jest sterowany zdarzeniami. Dwa interfejsy - rest lub JMS. Zdarzeń jest bardzo dużo, przed zapisaniem i przetworzeniem są one agregowane, aby nie tworzyć niepotrzebnych żądań. Sama baza danych, tabela, w której przechowywane są dane, wygląda jak magazyn kluczowych wartości – klucz użytkownika i sama wartość: flagi informujące o obecności lub braku odpowiednich dokumentów, okresie ich ważności, zagregowane statystyki dotyczące zamówień usług wg. tego użytkownika i tak dalej.
Po zapisaniu danych w JMS ustawiane jest zadanie, aby banery zostały natychmiast przeliczone - to musi być natychmiast wyświetlone w sieci. System uruchamia się w nocy: zadania są wrzucane do JMS w odstępach czasu użytkownika, zgodnie z którymi należy przeliczyć reguły. Jest to odbierane przez procesory biorące udział w ponownym obliczeniu. Następnie wyniki przetwarzania trafiają do kolejnej kolejki, która albo zapisuje banery w bazie danych, albo wysyła do serwisu zadania powiadamiania użytkowników. Proces trwa 5-7 godzin, jest łatwo skalowalny ze względu na fakt, że zawsze możesz dodać procedury obsługi lub podnieść instancje za pomocą nowych procedur obsługi.
Usługa działa całkiem nieźle. Jednak ilość danych rośnie wraz ze wzrostem liczby użytkowników. Prowadzi to do wzrostu obciążenia bazy danych – nawet biorąc pod uwagę fakt, że Rest API przegląda replikę. Drugi punkt to JMS, który, jak się okazało, nie jest zbyt odpowiedni ze względu na duże zużycie pamięci. Istnieje duże ryzyko przepełnienia kolejki, które może spowodować awarię JMS i zatrzymanie przetwarzania. Niemożliwe jest późniejsze uruchomienie JMS bez wyczyszczenia dzienników.
Planowane jest rozwiązanie problemów za pomocą shardingu, co pozwoli na zrównoważenie obciążenia bazy danych. W planach jest także zmiana schematu przechowywania danych i zmiana JMS na Kafkę - rozwiązanie bardziej odporne na błędy, które rozwiąże problemy z pamięcią.
Backend jako usługa vs. Bezserwerowy
Od lewej do prawej: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend jako usługa czy rozwiązanie bezserwerowe? W dyskusji nad tą palącą kwestią przy okrągłym stole uczestniczyli:
- Ara Israelyan, CTO, CTO i założycielka Scorocode.
- Nikolay Markov, starszy inżynier danych w Aligned Research Group.
- Andrey Tomilenko, szef działu rozwoju RUVDS.
Rozmowę moderował starszy programista Alexander Borgart. Przedstawiamy debaty, w których uczestniczyli także słuchacze, w wersji skróconej.
— Czym jest w twoim rozumieniu Serverless?
Andrew: To jest model obliczeniowy - funkcja Lambda, która musi przetwarzać dane, aby wynik zależał tylko od danych. Termin pochodzi albo od Google, albo od Amazona i jego usługi AWS Lambda. Dostawcaowi łatwiej jest obsłużyć taką funkcję, przydzielając jej pulę przepustowości. Różni użytkownicy mogą być niezależnie rozliczani na tych samych serwerach.
Nicholas: Krótko mówiąc, przenosimy część naszej infrastruktury IT i logiki biznesowej do chmury, do outsourcingu.
Ara: Ze strony programistów - dobra próba zaoszczędzenia zasobów, ze strony marketerów - zarobienia więcej pieniędzy.
— Czy Serverless to to samo, co mikrousługi?
Nicholas: Nie, Serverless to bardziej organizacja oparta na architekturze. Mikrousługa jest atomową jednostką pewnej logiki. Bezserwerowy to podejście, a nie „oddzielny byt”.
Ara: Funkcja bezserwerowa może zostać spakowana w mikrousługę, ale nie będzie to już funkcja bezserwerowa, przestanie być funkcją Lambda. W wersji Serverless funkcja zaczyna działać dopiero w momencie żądania.
Andrew: Różnią się czasem życia. Uruchomiliśmy funkcję Lambda i zapomnieliśmy o niej. Działało przez kilka sekund, a następny klient może przetworzyć swoje żądanie na innej maszynie fizycznej.
— Które skaluje się lepiej?
Ara: Podczas skalowania poziomego funkcje Lambda zachowują się dokładnie tak samo jak mikrousługi.
Nicholas: Niezależnie od ustawionej liczby replik będzie ich tyle; Serverless nie ma problemów ze skalowaniem. Zrobiłem zestaw replik w Kubernetesie, uruchomiłem „gdzieś” 20 instancji i wróciło do Ciebie 20 anonimowych linków. Do przodu!
— Czy można napisać backend na Serverless?
Andrew: Teoretycznie, ale to nie ma sensu. Funkcje Lambda będą opierać się na jednym repozytorium - musimy zapewnić gwarancję. Przykładowo, jeśli użytkownik przeprowadził określoną transakcję, to przy następnym kontakcie powinien zobaczyć: transakcja została przeprowadzona, środki zostały zaksięgowane. Wszystkie funkcje Lambda zostaną zablokowane w tym wywołaniu. W rzeczywistości kilka funkcji bezserwerowych zamieni się w jedną usługę z jednym punktem dostępu do bazy danych stanowiącym wąskie gardło.
— W jakich sytuacjach warto zastosować architekturę bezserwerową?
Andrew: Zadania, które nie wymagają współdzielonej pamięci - to samo wydobycie, blockchain. Gdzie trzeba dużo liczyć. Jeśli masz dużą moc obliczeniową, możesz zdefiniować funkcję typu „oblicz skrót czegoś tam…”. Ale możesz rozwiązać problem z przechowywaniem danych, biorąc na przykład funkcje Lambda z Amazon i ich rozproszoną pamięć masową . I okazuje się, że piszesz usługę regularną. Funkcje Lambda uzyskają dostęp do pamięci i zapewnią użytkownikowi jakąś odpowiedź.
Nicholas: Kontenery działające w trybie bezserwerowym mają bardzo ograniczone zasoby. Jest mało pamięci i wszystkiego innego. Jeśli jednak cała Twoja infrastruktura jest wdrożona w całości na jakiejś chmurze - Google, Amazon - i masz z nimi stałą umowę, jest na to wszystko budżet, to do niektórych zadań możesz wykorzystać kontenery Serverless. Trzeba być wewnątrz tej infrastruktury, bo wszystko jest dostosowane do użycia w konkretnym środowisku. Oznacza to, że jeśli jesteś gotowy powiązać wszystko z infrastrukturą chmurową, możesz eksperymentować. Zaletą jest to, że nie musisz zarządzać tą infrastrukturą.
Ara: Fakt, że Serverless nie wymaga zarządzania Kubernetesem, Dockerem, instalowania Kafki itd., jest oszukiwaniem samego siebie. Instalują to te same Amazon i Google. Kolejną rzeczą jest to, że masz umowę SLA. Równie dobrze możesz zlecić wszystko podmiotowi zewnętrznemu, zamiast kodować samodzielnie.
Andrew: Serverless sam w sobie jest niedrogi, ale za inne usługi Amazona - na przykład bazę danych, trzeba dużo zapłacić. Ludzie już ich pozwali, ponieważ pobrali szalone kwoty za bramkę API.
Ara: Jeśli mówimy o pieniądzach, musisz wziąć pod uwagę ten punkt: będziesz musiał obrócić całą metodologię rozwoju w firmie o 180 stopni, aby przenieść cały kod na Serverless. To zajmie dużo czasu i pieniędzy.
— Czy są jakieś godne uwagi alternatywy dla płatnego rozwiązania bezserwerowego od Amazon i Google?
Nicholas: W Kubernetesie uruchamiasz jakieś zadanie, ono działa i umiera - z architektonicznego punktu widzenia jest to całkowicie bezserwerowe. Jeśli chcesz stworzyć naprawdę ciekawą logikę biznesową z kolejkami i bazami danych, to musisz pomyśleć o tym trochę więcej. Wszystko to można rozwiązać bez opuszczania Kubernetes. Nie zawracałbym sobie głowy przeciąganiem dodatkowej implementacji.
— Jak ważne jest monitorowanie tego, co dzieje się w Serverless?
Ara: Zależy od architektury systemu i wymagań biznesowych. Zasadniczo dostawca musi zapewnić raporty, które pomogą zespołowi devops zrozumieć możliwe problemy.
Nicholas: Amazon ma CloudWatch, do którego przesyłane są strumieniowo wszystkie dzienniki, w tym te z Lambda. Zintegruj przekazywanie dzienników i użyj osobnego narzędzia do przeglądania, powiadamiania i tak dalej. Możesz wrzucać agentów do uruchamianych przez siebie kontenerów.
- Podsumujmy to.
Andrew: Myślenie o funkcjach Lambda jest przydatne. Jeśli sam tworzysz usługę - nie mikroserwis, ale taką, która pisze żądanie, uzyskuje dostęp do bazy danych i wysyła odpowiedź - funkcja Lambda rozwiązuje szereg problemów: z wielowątkowością, skalowalnością i tak dalej. Jeśli Twoja logika jest zbudowana w ten sposób, to w przyszłości będziesz mógł przenieść te Lambdy do mikroserwisów lub skorzystać z usług stron trzecich, takich jak Amazon. Technologia jest przydatna, pomysł jest ciekawy. Pytaniem otwartym pozostaje, na ile jest to uzasadnione z punktu widzenia biznesu.
Nikolay: Serverless lepiej nadaje się do zadań operacyjnych niż do obliczania logiki biznesowej. Zawsze myślę o tym jako o przetwarzaniu zdarzeń. Jeśli masz to w Amazonie, jeśli jesteś w Kubernetes, tak. W przeciwnym razie będziesz musiał włożyć sporo wysiłku, aby samodzielnie uruchomić Serverless. Konieczne jest rozważenie konkretnego przypadku biznesowego. Przykładowo jedno z moich zadań teraz brzmi: gdy na dysku pojawią się pliki w określonym formacie, muszę je wgrać do Kafki. Mogę używać WatchDoga lub Lambdy. Z logicznego punktu widzenia obie opcje są odpowiednie, ale pod względem wdrożenia Serverless jest bardziej skomplikowane i wolę prostszy sposób, bez Lambdy.
Ara: Bezserwerowy to ciekawy, możliwy do zastosowania i bardzo piękny technicznie pomysł. Wcześniej czy później technologia osiągnie punkt, w którym jakakolwiek funkcja zostanie uruchomiona w czasie krótszym niż 100 milisekund. Wtedy w zasadzie nie będzie już mowy o tym, czy czas oczekiwania jest dla użytkownika krytyczny. Jednocześnie możliwość zastosowania Serverless, jak już powiedzieli koledzy, zależy całkowicie od problemu biznesowego.
Dziękujemy naszym sponsorom, którzy bardzo nam pomogli:
- Przestrzeń konferencyjna IT «» na stronie konferencji.
- Kalendarz wydarzeń IT i publikacja”» w celu uzyskania wsparcia informacyjnego i aktualności.
- «„na prezenty.
- do współtworzenia.
- „Stowarzyszenie Komunikacji Elektronicznej” za zaangażowanie i doświadczenie.
- Główny sponsor - dla wszystkich!
Źródło: www.habr.com