Machine Learning Hackathon v Brně

Oficiální hlavička Hackathonu, staženo z oficiálních stránek.

V sobotu 25. května 2019 proběhl v Brně v Impact Hub hackathon se zaměřením na cloudové služby a machine learning. Hackathon připravila firma Oriflame ve spolupráci s firmou Microsoft.

Akce začala v sobotu v 11 hodin přivítáním týmů, které se nahlásily na 24 hodinový hackathon v programování. V poledne potom skončila registrace těchto týmů a proběhlo uvítání účastníků hackatonu a představení zadání jejich práce.

Konferenční část (které jsem se účastnil já) začínala v 1 odpoledne s tím, že samotné přednášky začínaly ve dvou proudech buď ve 2 odpoledne nebo od půl 4 podle následujícího rozvrhu:

Oficiální program Hackathonu, staženo z oficiálních stránek.

Já jsem navštívil následující přednášky:

• Keynote — Oriflame way to cloud,
• Azure inside,
• Vision API,
• Messaging platform,
• Jak na machine learning v Azure,
• Azure notebooks,
• AI možnosti v Azure,
• Application Insights.

Nyní bych rád popsal jednotlivé přednášky, jejich hlavní myšlenkua co jsem si z nich odnesl.

Přednáška č.1: Keynote — Oriflame way to cloud

Přednášku vedl Jakub Orság, který nám příjemně přivítal na konferenci a poskytl nám stručné informace, jak bude celá konference probíhat a co na ní můžeme vidět. Dále se potom plynule přesunul ke společnosti Oriflame a krátce nám ji představil, čím se zabývá a co dělá.

Pár dat a čísel:

• firma funguje na principu sharing economy,
• Oriflame Software funguje 19 let, má 300 zaměstnanců a zajišťuje si vlastní technický background,
• V Brně existuje “research & inovation center”, které řeší otázky machine learning, blockchain, IoT a VR,
• úzce spolupracují s firmou Microsoft a všechny služby jim běží v Microsoft cloudu,

A proč vlastně Oriflame přesunul svá data do cloudu?

Cloudové služby nabízejí firmě Oriflame lepší geografickou distribuci (díky rozložení data center po světě). Další výhodou je to, že cloudové služby se lépe přizpůsobují změnám trafficu, stejně jako jde nastavit automatické škálování pro lepší výkon v závislosti na trafficu (Oriflame používá 2 až 18 virtuálních strojů v závislosti na denní špičce).

A co se Oriflame chystá dělat dál?

Migrace do cloudu byl první krok směrem dál. Oriflame se v dalších letech bude snažit přejít od aktuálního stavu IaaS až k PaaS. Chtějí vytvořit další 2 datová centra a plně využít potenciál automatizace Azure, který by dovolil zavádět všechny další jejich služby jako platformní řešení, které by se dalo nasadit jen pomocí nastavení konfigurace. Doba nasazení takové služby by pak nebyla několik týdnů/měsíců, ale otázka několika dní (včetně ladění a testování).

Přednáška č. 2: Azure Inside

Architekt cloudových řešení, Valdemar Zavadský, ve svém příspěvku popisoval minulost Microsoftu při budování datových center a rychlost, s jakou se datová centra mění nejen po softwarové stránce, ale i po stránce hardwarové a strukturální.

První vybudovaná centra měla podobu jedné pevné budovy s několika místnostmi pro servery. Dnes se však už jen staví základní betonové desky, na které se nažene jednoduchá kovová a plechová konstrukce (samozřejmě včetně všech forem izolačních prvků) a budova je postavena ne za několik let, ale během několika týdnů!

Obdobná je politika pro výměnu hardwaru. Podle dostupných informací je aktuálně vnitřní politika nastavená tak, že pokud se nějaký server rozbije, je jednoduché ho nahradit (server zde chápejte jako jakousi kazetu/šuplík v obrovské skříni, která je propojená s dalšími několika tisíci podobnými zařízeními. Každá informace je navíc uložena duplicitně na třech různých místech, takže hrozí minimální ztráta dat i při poruchách softwaru, hardwaru či jiným závadám, např. ztráta el. energie a podobně). Náhrada pak probíhá tak, že příslušný pracovník se pokusí daný server restartovat (pomocí tlačítka) a pokud po druhém pokusu daný stroj pořád nefunguje, kazeta se vyndá a nahradí jinou (která je okamžitě sesynchronizována tak, aby na ní byly stejné informace, jako byly na té původní kazetě/serveru).

Další zvláštní informací pro mě byl fakt, že hardware v datových centrech společnosti Microsoft má tříletý cyklus fungování a každá kazeta je tak po 3 letech činnosti vyndána, nevratně sešrotována (nikdo ji dál nevyužívá) a nahrazena kompletně novou.

Pokud bych pak měl zmínit další zajímavost z této přednášky, tak jím bude jistě fakt, že od roku 2018 je v Microsoft cloudu (na virtuálních serverech) majoritním operačním systémem Linux!

Přednáška č. 3: Vision API

Zástupce firmy Microsoft, Michal Marušan, si v jedné ze svých přednášek připravil zajímavé téma — možnosti AI v rámci Microsoft cloud služeb (prostředí Azure).

Celý koncept AI se v dnešní době dá rozdělit do 3 hlavních kategorií:

• AI applikace a agenti,
• Knowledge (data) mining,
• Machine learning.

Prostředí Azure nabízí spoustu možností jak s těmito kategoriemi pracovat. První možností je pomocí tzv. “community services”, které se v prostředí Azure vyskytují převážně jako různí AI pomocníci. Hlavními skupinami jsou:

• vision
• speech
• language
• web search
• labs

Tyto aplikace jsou přímou součástí Microsoft Azure a jsou většinou bezplatné, zároveň fungují i přes webové rozhraní (API), takže je lze implementovat do různých dalších systémů.

Azure Vision potom v sobě zahrnuje rozpoznávání obrázků, rozpoznávání obličejů a emocí, krátké shrnutí videa. V rámci Azure Vision je k dispozici i funkcionalita “Custom Vision”, kde uživatel dostane k dispozici předprogramovanou neuronovou síť, kterou si může “doučit” tak, jak potřebuje. Funguje to tak, že neuronová síť je naučená na rozpoznávání např. obrázků (učící vzorek cca několik desítek miliónů obrázků z vyhledávače Bing!) a uživatelovi stačí nahrát jen několik desítek svých vlastních specifických obrázků s předmětem, který se má rozeznat (např. druh auta — Škoda Fabia nebo Felicia) a během pár minut má sofistikovaný systém (umělou inteligenci), který je schopen toto udělat za něj.

Stejně tak jde tuto předtrénovanou neuronovou síť naučit i daleko sofistikovanější úkoly, jako zařadit obrázky do specifických kategorií (tzv. labeling), zjistit jaký text se na obrázcích objevuje (včetně pozice a použitého jazyka) a další funkce, které toto prostředí nabízí.

Custom Vision navíc funguje ve dvou režimech. Prvních z nich je “kategorizace” (dříve zmíněný labeling) a “detekce” (dříve zmíněná detekce textu). Jediné omezení, který tento model aktuálně má je to, že objekt, který se rozpoznává musí v rámci kategorizace, musí vyplňovat alespoň polovinu obrázku, zároveň objekt, který je detekován v druhém módu fungování, má řádově nižší pravděpodobnost nalezení (např. nalezení a rozpoznání log výrobců na produktech).

Tyto nedostatky jdou ale odstranit rozšířením učícího vzorku na stovky/tisíce nových obrázků. Díky tomu se přeprogramuje více vrstev (od konce) neuronové sítě a celý systém je tak přesnější.

Custom Vision je aktuálně nejsilnější položkou v celém Azure community services — možnost vytvoření vlastní sofistikované neuronové sítě (AI).

Podle zákulisních informací (Microsoft nesmí o tomto tématu otevřeně hovořit) a osobním pocitu přednášejícího je navíc Azure Custom Vision srovnatelné s AI od Googlu. Minimálně po technické a výkonové stránce se nedá říct, který z nich by byl lepší nebo horší.

A pár dat ze závěrečné diskuze:

• neuronová síť byla trénovaná na několika milionech obrázků z vyhledávače Bing!,
• uvnitř obsahuje základní rozdělení do 60 kategorií,
• při trénování vlastního rozpoznávání se “odkrajují” poslední vrstvy neuronové sítě, které se nahrazují novým modelem,
• labeling obrázků na začátku probíhal ručně (wow!),
• celé řešení AI je postavené na principech ethical & transparent AI.

Přednáška č. 4: Messeging platform

Ondřej Pajgrt svůj příspěvek zahájil rozdílem mezi synchronními a asynchronními službami pro zpracování zpráv uvnitř aplikace. Hlavně poukazoval na fakt, že synchronní systémy jsou náchylnější na defekty a sekání se právě kvůli závislosti na doručení a zpracování předávané zprávy.

Asynchronní systémy tuto chybovost spíše nemají. Rozdíl je v tom, že se nečeká na odpověď příjemce, ale pouze se zpráva odešle a zda byla zpracována či ne, není už pro tento systém vůbec důležité. V systému tedy pouze rostou fronty, které zpracovávají různí “workeři”, ale nedojde k jejímu zastavení v případě nedoručení zprávy.

Messeging platform musí umět následující věci:

• jaký bude formát dat (pro odesílatele i příjemce) i s ohledem na rozšiřitelnost systému,
• forma doručování dat (základní jsou tři typy: competing consumers — jedna fronta pro několik workerů, fanout — každý worker má zprávu sám pro sebe a může ji libovolně měnit, aniž by to ovlivnilo ostatní příjemce, routing — směrování zpráv, kam patří a kam ne),
• metadata zprávy (obohacení o údaje k trackování, routování nebo přidání např. dalšího kontextu),
• škálovatelnost procesů (navazování front a workerů na sebe),
• dohledávání a persistence dat (zamezení ztráty dat např. při výpadku proudu),
• stabilita, variabilita a bezpečnost.

Tyto systémy využívají tzv. “message brooker”, což je místo, které shromažďuje všechny zprávy, stejně jako se do něj registrují všechny fronty a workeři. Nevýhoda tohoto systému je plná závislost aplikace na tomto message brookeru a je tak potřeba zajistit jeho duplicitu/paralelu skrze jiný záložní systém.

Nejpoužívanější message platformy:

• ZeroMQ — využívá distribuovanou síť, která spolu více komunikuje a nehrozí pád systému při chybě message brokera,
• RabbitMQ, AyureServiceBus — hodně dobré, popř. dobré k inspiraci,
• NServiceBus — komerční řešení,
• JAsper — je dobrý, ale v raném stádiu vývoje.

Oriflame Messaging Platform pak využívá toho, že má celou infrastrukturu v Azure a používá její komponenty:

• EventHub — skrze data stream řeší příjem a posílání zpráv,
• ServiceBus — slouží jako systémový message brooker,
• Functions — vlastní napsaný kód, slouží pro obsluhu routování,
• StreamAnalytics — běží nad data streamem a snaží se detekovat anomálie v systému,
• ApplicationInsights — slouží k logování systému, převážně pro účely auditů a analýz dat.

Pár postřehů při zavádění nového systému:

Nové řešení messaging platformy Oriflamu je inspirováno MassTransit, kde k serializaci dat bylo použito Cloud Events (ne moc rozšířený, ale postupně se kolem toho tvoří velká základna firem).

Nejtěžší bylo při přechodu definovat jak má vypadat celý kontrakt. Kontraktem pak vlastně rozumíme celou problematiku výsledného řešení — definice zprávy, její předávání, obsah datové části, duplicita a chybovost zpráv. S tím bylo pak spojené i tzv. “at-least-once delivery”, což je stav, ve kterém je zaručeno, že zpráva byla alespoň jednou doručena (a zároveň co s ní dělat, pokud dojde vícekrát).

Posledním problémem bylo SLA služeb. EventHub má sice garantovanou 99.95% dostupnost, ale v rámci jednoho měsíce je to stále 21 minut, kdy je výpadek, nebo-li čas, kdy nedokážeme zajistit jakoukoliv komunikaci v rámci systému a přicházíme o jednotlivé zprávy. Řešením tototo problému pak bylo připojení druhého EventHubu, lokalizovaného v jiném data centru, čímž se výsledná dostupnost zvedla na 99.9975%. Při zaregistrování výpadku na prvním EventHubu je přes automatickou detekci veškerý messaging přesměrován na druhou instanci EventHubu. Řešení to není dokonalé (pořád může nastat situace, kdy nejede ani jeden z těchto systémů), ale nedostupnost služby už je skoro zanedbatelná.

Aktuálně v tomto systému koluje kolem deseti tisíc zpráv denně (při používání tří služeb), ale tento počet bude brzo růst, jak se budou připojovat další a další služby. Tento systém je navíc jen pomocník. Pro některé operace v rámci aplikace je stále potřeba použít jiné nástroje (REST, GraphQL, atp.).

Přednáška č. 5: Jak na machine learning v Azure

Další z přednášek Michala Marušana, tentokrát na téma machine learningu. Příspěvek navazoval na předchozí přednášku (č. 3) — Vision API.

První vrstva pro AI v Azure je předtrénovaný model. Pokud nám toto řešení nestačí, můžeme přejít ke službě “custom machine learnign”, která je nám plně k dispozici.

Microsoft v poslední době (cca 5 let) hodně změnil vnitřní politiku a začal podporovat více externích zdrojů. Aktuálně tedy přímo v Azure najdeme podporu pro populární frameworky, jako je například: Scikit-Learn, Jupyter, TenserFlow, PyTorch a další. Navíc lze mezi jednotlivými platformami migrovat data pomocí formátu ONNX, který má v Azure také svoji podporu.

V rámci custom machine learning služeb pak máme k dispozici 3 produkty pro vývoj vlastní neuronové sítě:

• Azure Databricks
• Azure machine learning
• Azure machine learning VR

Pokud se tedy rozhodneme začít budovat vlastní neuronovou síť v Azure, dostaneme možnost si ji nakonfigurovat. Prvním rozhodnutím je výběr procesoru — CPU (běžný procesor, běžná rychlost), GPU (grafický chip, větší rychlost), FPGA (programovatelná hradla, nejrychlejší). Pro trénink i ostrý běh přitom jde vybrat různé nastavení.

Pro komplexnější práci s machine learning se pak používá tzv. “Cluster”, jedná se o další službu Azure, která umožňuje propojení machine learning s dalšími komponentami. V rámci Azure Databricks je pak tento cluster propojen i s konkrétními uživateli, dalšími funkcemi (Azure Functions) a podobně.

Díky clusteru můžeme navíc řetězit jednotlivé úkony a úlohy za sebe a docílit tak více a více komplexního řešení. Stejně tak se dá celý cluster zabalit do služby (procesu), která se pak dá spouštět opakovaně, automatizovaně nebo ji napojit na další části systému (ať už interně nebo přes REST).

Přednáška č. 6: Azure notebooks

V dalším příspěvku Michal Morušan představil možnost programování přímo v Azure. Slouží k tomu služba Azure Notebooks, která dovoluje psaní vlastního kódu, propojitelného s machine learning.

Nejpoužívanější jazyk pro machine learning je v dnešní době Python, následovaný programovacím jazykem R (dále jen “eRko”). Azure oba tyto jazyky podporuje (skrze kernel — překladač/jádro). Azure Notebook je vlastně implementace Jupyter Notebook, která dovoluje kombinovat popisné bloky s programátorským kódem a při testování kódu navíc vidět i výsledek jednotlivých programových bloků. Jedná se o velice oblíbenou formu programování.

V rámci Azure Notebooks tedy pouze nastavíme kernel pro požadovaný programovací jazyk (Python 2 / Python 3 / F# / eRko / a další) a můžeme začít tvořit vlastní kód. V budoucnu se plánuje tuto službu propojit i s dalšími Azure projekty.

Služba je navíc dostupná veřejně na notebooks.azure.com (pro přihlášení stačí microsoftLive účet). Pouštět se dá na několika strojích (jak free, tak na vlastních VM).

Je dobré každý projekt nakonfigurovat, přidat ReadMe a další markdown (popis projektu — obdoba popisu balíčků jako je například na github.com). Pří úpravě se dá přepínat mezi jednotlivýma kernelama. Při psaní kódu můžeme nad každým blokem zavolat “compute” (command run — spuštění bloku kódu) a vidět výsledky. Pomocí dalších Azure nástrojů pak můžeme vidět zalogované statistiky průběhu (resp. všeho, co v rámci kódu logujeme).

Přednáška č. 7: AI možnosti v Azure

Poslední svou přednášku Michal Morušan začal historickým vymezením AI. Jako první termín přišel ve spojitosti s AI pojem “data mining”, který později nahradil výraz “machine learning”. Dnes tomu stejnému říkáme AI. Nejdůležitější pro tuto operaci ale vždy byla DATA.

V Azure existuje několik služeb, které po předložení vlastního obsahu dokáži vygenerovat nějaký výstup (viz přednáška č. 3 — Vision API). Nadstavba toho je potom vlastní neuronová síť (viz přednáška č. 5 — Jak na machine learning v Azure) a propojení s dalšími službami v Azure (viz přednáška č. 6 — Azure notebooks).

Azure Machine Learning a Azure Databricks dokáží dohromady vytvořit, spravovat a monitorovat celý životní cyklus AI. Infrastrukturu si potom můžeme nechat udělat u Microsoftu (v cloudu) nebo použít vlastní servery.

Protože většina této přednášky se sestávala z názorných ukázek, dovolil bych si zde alespoň vyjmenovat pár čísel. Prvním z nich je výpočetní síla jednotlivých typů procesorů, nad kterými probíhá trénování nebo výpočet neuronové sítě. Pokud například síla jednoho CPU bude zpracování 6.5 obrázků za vteřinu, pak u stejných obrázků můžeme u GPU počítat s výpočetní silou zhruba 65 obrázků/s a u FPGA dokonce až 550 obrázků/s.

Pokud bychom takhle zpracovávali přesně daný počet obrázků, je jasné, že danou operaci provedeme nejrychleji na FPGA. Zároveň je ale možné, že za to zaplatíme několikanásobek toho, co by stejný výpočet obnášel například na CPU (i s ohledem na fakt, že cena se počítá za čas výpočtu jako takového). V závislosti na nutnosti zpracování je tak vhodné volit i odpovídající infrastrukturu (pro učení sítě se dá využít pomalejšího výpočtu, zatímco pro real-time operace může být vhodnější GPU, popř. i FPGA).

Microsoft teď nově uvolnil pro Machine Learning (ML):

• automatizaci tréninku jednotlivých modelů ML (rozšíření o možnost úpravy učebního algoritmu),
• nový vizuální interface pro ML,
• ML Notebooks (pro Jupyter Notebooks),
• MLOps (DevOps for ML) — automatický deploy, atd.,
• hardware-accelerated models,
• ONNX runtime podporu pro NVIDIA TensorRT a Intel nGraph,
• nově Cognitive Services (“Decision”),
• Azure vyhledávání.

Všechny věci se v rámci Machine Learning Service snaží integrovat do jednoho grafického přehledu, který dovoluje vytváření jobů (procesů) pro trénování AI.

Přednáška č. 8: Application Insights

V poslední přednášce dne nám Jan Vilímek pověděl něco o monitorovacích systémech a o tom, jak funguje monitoring v rámci Oriflame software.

Pro monitoring existuje několik metrik (parametrů), které je vhodné sledovat. Naprostým základem je monitorování vytíženosti CPU, RAM paměti, čtení a zápisu na disky, sítě, internetových protokolů a dalších parametrů. Určitě se pak vyplatí monitorovat i aplikační odezvu, latenci (zpoždění) a počet requestů (žádostí), které byly po aplikaci požadovány.

Vždy zde platí zásada, že se člověk u těchto metrik nemůže orientovat podle průměrných hodnot.

Oblíbenými nástroji pak můžou být SCOM, Nagios, Yabbix nebo OMS.

V rámci moderního monitoringu je ale nutné sledovat ještě další parametry systému:

• server side request latency — doba nutná pro provedení požadavku přímo na serveru),
• monitoring aplikačních závislostí,
• monitoring výjimek,
• logování.

To nám naopak umožňují aplikace typu: New Relic, AppDynamics, Dynatrace nebo AppInsights.

Poslední z výše zmiňovaných (Application Insights) se pak dá nasadit na FrotnEnd i BackEnd Vaší aplikace a to pomocí jednoduchého kódu. Tento kód dělá jednoduchý asynchronní požadavek do AppInsights monitoringu a předává tak údaje o fungování aplikace. Pokud propojíme systém s Azure, můžeme si i vybrat ke kterému data centru se má která aplikace hlásit a vidět podrobný výpis všech metrik, které AppInsights dělá.

Co všechno se monitoruje: requests, závislosti aplikace, výjimky aplikace, počet zobrazení a rychlost použitých prohlížečů, výkonnostní metriky, host diagnostics, logování, vlastní zprávy a metriky, dostupnost serveru (40 míst na světe umí jednoduchý http request jen na dostupnost domény).

Systém dále umožňuje: alerts (jak smart, tak i dynamické a vlastní odchytávání a upozorňování na anomálie), analytics (hlavně Kusto — azureMonitor), dashboard (pro účely DevOps), appMap, profiler, live metric stream, napojit se na REST / SQL / REDIS, continuous export (využitelné spíše pro machine learning).

V rámci Dashboardu je pak možnost vidět: real-time monitoring, statistiky, grafy.

Grafy se dají generovat pomocí jazyka podobnému T-SQL, kde jdou napsat vlastní metriky. Analýza peaků — občas dokáže najít request, který vybočuje (10x až 100x větší latence např.). Dá se lehce sdílet vlastní graf skrze dynamický odkaz.

“A rada na závěr: Monitorujte všechno!”

Zdroje:

• vlastní poznámky z přednášek
• oficiální web Oriflame AI Hackathon & Konference 2019