S04E11 - Trends in MLOps - Deel 3 - Ops

Joop Snijder en Willem Meints, Chief Data Scientist @ Aigency, zijn op de conferentie QCon San Francisco en bespreken de trends in MLOps die gepresenteerd zijn op de conferentie.

Dit is het derde en laatste deel van een driedelige serie en gaat over het Operations deel van Machine Learning modellen. 

Let op: De afleveringen zijn wat technischer dan wat je van ons gewend bent en zijn wat meer geschikt voor Data Scientists, Machine Learning experts en verder voor iedereen die enthousiast is over de implementatie van ML-systemen.

De volgende onderwerpen komen aan bod:

• Reliability testing voor Machine Learning Systems
• How did it make sense at that time, over analyseren van productieproblemen tijdens Operations.
• Hoe schaal je eenvoudig van lokaal trainen van modellen naar clusters
• Hoe documenteer je voor je 'Future self'

links

• Howie- The Post-Incident Guide
• Ray.io
• Diagrammen documentatie - PlantUML

Aigency
Aigency ontwerpt en ontwikkelt waardevolle, robuuste en betrouwbare Machine Learning-modellen.

Info Support
Info Support is de specialist in maatwerk software en leidend in kunstmatige intelligentie (AI).

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Schrijf je in voor onze nieuwsbrief en ontvang exclusieve toegang tot nieuws, blik achter de schermen en meer!

Transcript

0:00

Je luistert naar het derde en laatste deel van de driedelige serie over trends in MLOps. Mijn naam is Joke Snijder, CTO bij Agency. In deze aflevering staat het operations deel van MLOps centraal. Voordat we beginnen wil ik opmerken dat deze aflevering wel technischer is dan je van ons gewend bent, maar blijf vooral luisteren en laat weten of je vaker een technische afleggen in mijn lijst. Veel plezier. Zo, we zijn toegekomen aan deel 3 van onze speciale reeks Q-CON San Francisco 2022. We hebben het over MLops, de trends in MLops. MLops, een set van tools en best practices om van het ontwerp van je machine learning tot aan productie te komen. En hoe hou houd je de machine learning modellen ook waardevol in productie en hoe beheers je die. Vandaag het laatste deel, het opsige deel, samen met Willem Mijns. Willem, wil jij je eerst even voorstellen aan de luisteraar? Zeker. Ik ben Willem Mijns. Ik werk als Chief AI Architect voor Agency, onderdeel van InfoSupport. Daarnaast ben ik ook actief als Chapter Lead Data & AI voor de Business Unit Finance binnen InfoSupport. Ja, we hebben veel gezien, veel gehoord en we vinden ook best wel een hele hoop over een aantal dingen. Dus laten we het op z'n deeltes eventjes behandelen. Zal ik even starten? Ja, ik denk dat het goed is, ja. Ja, want ik heb een sessie gehad en die sessie heette eigenlijk, die noemden ze HDMI SATT. Zo had 'ie het ook te heten erover. Wat een tennis. Ja, want dan was het natuurlijk een afkorting en dat was 'How did it make sense at that time?' En vooral dat laatste vond hij heel erg belangrijk. Dat gaat erover, en het is niet machine learning specifiek, maar denk ik ook heel goed toepasbaar voor machine learning, is wat als er nou iets fout is gegaan? Ja, dat heeft te maken gehad met dat er ergens op een moment iemand gedacht heeft om iets te ontwerpen, iets te doen, Wat op dat moment heel logisch leek, op dat moment. O, ja. Snap je? Niemand, zei hij ook, stapt 's ochtends uit bed van 'zo, ik ga dit boel dus even helemaal kapot maken'. En er waren twee voorbeelden van hoe stuk iets kan gaan, wat hij pakte. De eerste was van Salesforce. Iemand had daar iets met de DNS'en veranderd. En dat werd even globaal, werd dat... Ja, globaal, echt wereldwijd zeg maar, uitgerold. En Salesforce was 14... Nee, ik moet zeggen, 5 uur wereldwijd offline. Auw. Ja, pijn hè. Kan nog erger. Atlassian. Ik ben even kwijt wat daar fout was gegaan, maakt het niet zo heel veel uit. Het probleem was 14 dagen een outage. Oh ja, dat is helemaal heel verkeerd. Oh ja, nee, dat was een mooie ja. Wat daar gebeurde, nu weet ik het weer, is dat iemand die... Er waren heel veel sites, Adlessing sites opgespint. En wat hij gedaan had, is dat hij... Dan krijg je web-ids. had 883 ID's lijst gekregen en dat moest allemaal weggegooid worden. Maar het probleem en er zaten 15 diegenen had 15 ID's gepakt, getest, alles, alle procedures gevolgd in acceptatie, alles goed en vervolgens zat over de rest van die 883 maar dat bleken site-id's te zijn. Dus hij gooide gewoon heel veel sites gewoon weg. Dat lijkt me vrij pijnlijk. Dat was heel pijnlijk. De meesten waren ook niet meer terug te halen. Dus de vraag was bij beide, wat is er nou fout gegaan? Wat hij zei is, van er wordt heel vaak een root cause analysis gedaan. Nog erger vaak wordt het een blame game van wie is de schuldige. Maar die root cause analysis waren ook allemaal openbaar. Ja en dan stonden daar dingen in zoals bij die DNS behandeling van iemand had zich niet aan de aan de policies gehouden en er was nog een reden. Maar hij zei van ja maar er is niet, er staat nergens in van waarom leek het voor diegene op dat moment een goed idee. Ja het is eigenlijk niet zozeer de hood calls maar meer wat is eraan vooraf gegaan nog zelfs. Ja en hij zei als voorbeeld van als jij Hij zei, ik loop ook regelmatig door het rood. Zegt hij, mag niet. Doen we toch. Doen we toch. En hoe meer haast je hebt. Want bijna altijd door het rood lopen gaat goed. Want je kijkt eerst naar links, je kijkt naar rechts, je kijkt nog een keer naar links. Je denkt, niks komt eraan. Het kan. Het is veilig om over te steken. Datzelfde geldt natuurlijk ook voor de shortcuts die je neemt in je dagelijks werk. Dat je denkt, oh dat heb ik vaker gedaan. Maar ook hoe drukker je bent, dus als je haast hebt op straat, ben je geneigd om meer risico's te nemen. Dat je denkt, nou, ik steek even snel over. En misschien ren je ook wat harder de straat over. Dat had hij als analogie. En dat zou bij zo iemand best gebeurd kunnen zijn. We weten het niet, want dat staat niet in die publieke rapporten. Wat nou als het een goed idee bleek omdat er bijvoorbeeld een hele belangrijke manager heeft gezegd"Pas die DNS even aan want ik heb straks een hele belangrijke demo en ik kom er even niet doorheen." En je denkt, nou ik heb links gekeken, rechts gekeken, hoe heel veel druk, ik denk dat dat best even kan. Ja precies. Dus het ging er echt heel erg om van dat je door blijft denken van waarom bleek het op dat moment een goed idee. Dus ook als je zo direct in productie met je machine learning problemen tegenkomt en je moet nagaan denken van wat is nou het probleem. Dus niet je root cause analysis ook maar nog verder van waarom leek het op dat moment een goed idee. En omdat dat nou ja tegen tegengaan kan niet. Dat je kan nog zo goed, ik pak even het statement erbij. In het Engels was het complex systems are Heel veel mensen zijn op de hoogte van hun verliezenheid, maar de catastrofe is altijd net rond de hoek. Het ligt altijd op de loer. Hoeveel je ook aan preventie hebt gedaan, er kan altijd wat gebeuren. Nou, dan ga je terug. Maar om dat misschien wel te voorkomen, is het wel handig om in ieder geval een vorm van documentatie te hebben voor jezelf, voor je future self, dat je op zijn minst documenteert waarom op dat moment dingen een goed idee lijken. Dus architectuurbesluiten. Daar weet jij denk ik alles van. Ja, ik doe zelf nog steeds veel met softwarearchitectuur natuurlijk. En sowieso als AI architect ben je eigenlijk een softwarearchitect die dan specifiek voor AI projecten bezig is. Kijk, een van de dingen die ik zelf heel belangrijk vind is aan de ene kant, ik wil graag documentatie die mensen gebruiken. zodat als we willen weten waarom die keuze was gemaakt, waarom het een goed idee was, dat we dat altijd kunnen terughalen en dat dat makkelijk is te vinden. En aan de andere kant, ja, je wilt toch een soort geschiedenis vastleggen. Dus een van de technieken die we veel gebruiken binnen InfoSupport ook, is Architecture Decision Records. Het zijn hele eenvoudige documentjes eigenlijk. Daar staat in, we hebben dit besluit genomen, dit was de achtergrond van het besluit, en dit zijn de gevolgen van het besluit. En omdat dat heel eenvoudig is... Zijn dat Word documenten? Nee, Markdown. Gewoon platte tekst. Wij gebruiken Markdown, dat is een taal eigenlijk die... waarbij je met eenvoudige symbolen voor de tekst kan aangeven. Dit is een groot kopje, middelgroot kopje, klein kopje, opsomming en dat soort dingen. Maar het is gewoon platte tekst. Dus het is helemaal niet zo fancy. We hebben ook geen hele fancy portalen of zo, dat is allemaal niet nodig. En je schrijft ook geen proza, hè? Nee, zeker niet. Het is heel kort. Ik zag jou vanochtend, was je bezig met het opzetten van een platformarchitectuur voor machine learning. Dat stond ook in Markdown en dat kon je gewoon omzetten. Wat gebruikte je daarvoor? Want dat zag er heel mooi uit. Dus je had heel kort beschreven van dit zijn de besluiten, dit is het plaatje wat erbij hoort. Dat is eigenlijk lean en mean, maar wel super duidelijk. Ja, dus ik gebruik zelf, er zijn een aantal dingen die ik gebruik. Ik gebruik Markdown voor de beschrijving. En die kun je in de meeste tools, als je bijvoorbeeld GitHub of als je DevOps of GitLab gebruikt, die zetten hem automatisch onder HTML, zodat je het netjes kan lezen. En door de Markdown heb je ook version control en dat soort zaken, hè? Ja, ik check het in in source control. Dat is niet iedereen misschien gewend, maar dat werkt fantastisch. En je kan de verschillen dus dan heel makkelijk checken. Ik kan ook zeggen tegen een ontwikkelaar, "Hé, we hebben dit besproken in de meeting, maak even een aanpassing en geef me een pull request." Dan kan ik het reviewen zelfs voordat het in mijn documentatie komt te staan. Dus dat is de reden dat ik dat gebruik. Als je dat thema doortrekt, van "Ik wil het gefashioneerd hebben", afbeeldingen maak ik niet als plaatjes. Maar ik gebruik dat plant.uml voor. En dat is een taal, daar kan ik declaratief aan geven. Ik heb een systeem. Ik heb een user. Ik heb een netwerkverbinding. Ik heb een relatie. Ik heb een context. En die dingen die kun je in elkaar stapelen en je kun je met behulp van Plain2ML kun je dan een plaatje daarvan genereren. Het plaatje sla ik ook op in source control, want dat is makkelijk. Maar dat is echt niet belangrijk. Dat diagram, die originele definitie, die is belangrijk voor me. En dat is de documentatie voor je future zelf, dat je vast hebt gelegd, dit zijn de keuzes. Op dit moment, at this moment, at this time, is dat hoe ik erover denk, waarom het een goed besluit is. Dus dat betekent als we straks iets, na een jaar, twee jaar, dingen kapot gaan, waarvan misschien dan dat je echt denkt van, hoe heb ik dat bedacht? Ja, hoe dan? Weet je? Welke idioot, dat je teruggaat, maar ja, die idioot was ik zelf."Oh, maar dat dat en dan en dat." En dat was inderdaad op dat moment, was dat, ja, daarom heb ik dat gedaan. Dat je, en daar kan je dan van leren. Dus ik vond dat wel een heel mooi idee. Dus lean and mean documenteren, maar vooral eigenlijk is geen blame game. En nog verder dan je root cause analysis van, ja, Hoe komt het nou dat iemand tot dat besluit is gekomen om tussen aanhalingstekens zo'n grove fout te maken? Want niemand komt uit bed 's ochtends van zo ik ga eens even een grove fout maken waarbij 14 dagen even alles eruit ligt. Ja toch? Echt een mooi idee. En wat hij ook nog aangaf is van er is ook een heel groot verschil. Want je kan nog zoveel policies, guidelines, handleidingen, werk SOW's hebben. Of SOW's, SOP's hebben. Maar er is een heel verschil tussen hoe het werk is opgeschreven en hoe het werk uiteindelijk uit wordt gevoerd. Het mooiste vond ik een plaatje van het werk hoe het is beschreven. heb je de kast binnen je in elkaar zetten. Iedereen kent dat wel, de beschrijvingen van IKEA. En dat je misschien jezelf op een gegeven moment ziet van, oh ja ik had toch eigenlijk stap 4 even gedaan en misschien pak ik hier eventjes een hamer erbij. Je denkt altijd van, oh ja ik kan dat wel even zo, dat je de halve weg achterkomt van, oh ja maar nou zit toch iets een beetje scheef andersom. Je houdt er pas groefjes over. - Ik houd er pas groefjes over, dat. Dus dat vond ik wel een mooie, weet je, van je kan niet alles vatten in procedures, dus ga ook weer terug. Dus dat vond ik heel erg leuk. Accepteer een beetje chaos, toch wel. Ja, ja. Hé, jij was ook nog naar een sessie geweest over eigenlijk reliability testen, hè? Wat we ook heel, ik bedoel, dat is een algemeen iets, maar kunnen we ook heel goed gebruiken bij de machine learning. Ja, ik was naar die sessie toe gegaan, van ik ben toch wel eens benieuwd. Vanguard, een Amerikaanse investeringsmaatschappij, die had een sessie over chaos testing. Het idee dat je expres fouten in een omgeving gaat introduceren. Je gaat een server uitzetten, of een netwerkverbinding kapot maken, of een database weggooien. En dan ga je kijken hoe je systeem reageert. En dat doen ze met de als reden van, wat wij eerder zeiden, je kan nooit helemaal 100% weten wat er gaat gebeuren in productie. Je hebt het allemaal goed ontworpen, je hebt het allemaal goed gedocumenteerd, oké, dat kan zo zijn. Maar het zou wel mooi zijn als je ook nog een paar testen kan draaien op je infrastructuur om te controleren van, wat nou als het fout gaat? Wat gebeurt er dan? En dan niet zozeer dat het dan allemaal automagisch is, zelf weer moet herstellen ofzo. Dat was niet haar verhaal. Zij zei van het gaat er juist om dat je je bewust wordt als het fout gaat, wat zijn dan de gevolgen van die fout? Nou, en zij... - En kun je het ook detecteren, hè? Dus het is net zo, zei je inderdaad van het hoeft inderdaad niet up and running te blijven, als je ook verwacht dat het niet up and running is, maar dat je het bijvoorbeeld wel in je logging terug ziet ofzo. Ja, je kan als je zo'n test gaat draaien, kun je gewoon kijken Van tevoren, van wat voor signalen heb ik dan al. Je kan tijdens de test kijken welke signalen krijg je uit dat systeem. En wat gebeurt er daarna? Komt ie bijvoorbeeld weer terug? Was dat de bedoeling dat ie terugkwam? Misschien was dat wel helemaal niet de bedoeling dat ie weer terugkwam. Dat zit allemaal in die testen. Dus die testen die kijken, nou helemaal afsproken in testen in code, kijken we vooral naar, krijgen we het verwachte resultaat? 1+1 wordt het automatisch 2. Maar in dit geval kijk je naar, krijg ik uit mijn monitoring de juiste alerts terug? Krijg ik in de logfase de juiste dingen terug? Kan ik dat bekijken ook nog? En het juiste gedrag, want het kan wel zijn dat je verwacht dat iets bijvoorbeeld na 5 minuten weer up komt. Dat zat ook helemaal in die flow, dus dat je dan 5 minuten wacht, checkt of bijvoorbeeld een database weer hersteld is, waar je uit put, misschien met je machine learning. En dan kan die verder. En het mooie was, ook dat ging weer via een declinatieve manier om dat op te schrijven. We hebben in deel 1 en deel 2 allerlei declinatieve manieren gezien van aanpak. Hier zat ook een declinatieve aanpak. Ja, ze hadden hier een workflow. Ze maakten gebruik van Amazon AWS. En zij gebruikten workflows om dat in elkaar te zetten, dat ding. Je kan dan blokken erin slepen die bepaalde standaard operaties doen, standaardchecks en bijvoorbeeld die wachttijden ook, dat hij vijf minuten gaat wachten totdat hij weer terug is. Dat zit er allemaal ingetekend. En het mooie daarvan is ook, je kan het direct documenteren gewoon, je kan het vastleggen en laten zien aan anderen. Kijk, dit is hoe het gegaan is. Het is gelukt of het is niet gelukt. Dat vond ik wel heel sterk aan haar verhaal. Misschien dat de luisteraars ook de Netflix Chaos Monkey kennen. Die doet dat eigenlijk een soort van willekeurig. Die gaat zeg maar door je productiesysteem heen. En als een wilde aap trekt hij gewoon alles eruit. En dit was wel wezenlijk anders toch? Ja, dit was zeker wel anders. Chaos Monkey is willekeurig en die laat jouw productie los. En hopelijk is je systeem sterk genoeg om er tegen te kunnen tegen die aap. Dit gaat niet op productie, dit gaat op een staging omgeving. En dit is van tevoren uitgedacht. Ze heeft dat niet heel precies uitgelegd hoe ze tot het design van die testen komen. Een van de dingen die wij in het verleden hebben gedaan, is dat wij een meeting hadden op ons team, The Wheel of Misfortune. Er werd van tevoren een van het team gevraagd......wil jij eens iets bedenken waarmee ons systeem kapot kan? Bijvoorbeeld het database weggooien. Nou, wat gebeurt er dan allemaal volgens ons? En met zo'n meeting, als je gaat nadenken over van......oké, stel dit gaat kapot, die database. Wat gebeurt er dan allemaal? Dat kan jou helpen om een ontwerp te maken voor zo'n chaos test. Ze deden het eigenlijk hypothese gebaseerd. Ja, dit is de hypothese, die leggen we in, ook weer in YAML, leggen we dat vast. Op een declaratieve manier. Dan gaat het systeem eronder, die gaat werken. En dan kan je uiteindelijk checken of je hypothese uitkomt. Dus of uiteindelijk je systeem weer up-and-running is, of dat je juist verwacht dat die dat niet is. Dus dat was er wel heel mooi aan. En wat ik wel slim bedacht vond, is dat ze vooraf, voor het uitvoeren, dat ze toch een killswitch hadden. Dat ze van als anderen op staging, ja, er komt ergens een productieprobleem of weet ik veel wat voorbij en die willen ook even door staging heen. Ja, dat die niet in de weg zitten met zo'n, nou ja, ook zo'n chaosdeel. Ja, dat vond ik wel een hele goede set. Omdat je ook niet moet vergeten, het is niet gewoon even, ik draai even een hele korte test, zo'n chaostest kan echt enkele uren in beslag nemen Als je een uitgebreid scenario hebt, dan is die kill switch van wezenlijk belang om het goed te laten lopen. Ja. Maar ik vond het wel een heel knappe dag. Ja, was leuk. En zorgt ook wel weer voor inspiratie hoe je hierover nadenkt op het gebied van het opsdeel van MLOps. Ja. Nou, dan zijn we echt bij het laatste onderdeel van de laatste speciale aflevering van deze driedelige serie. en dat is dat we in bijna alle specifieke MLOps-sessies kwam steeds Ray terug. Ja, die komt steeds terug. Ik heb ons er ook al vaker over horen praten. In de vorige twee afleveringen is hij ook al voorbij gekomen. Het is een ding. Het is echt wel belangrijk geworden dat... Ja, heel veel grote spelers gebruikten Ray of de tooling die wij genoemd hebben hebben Ray optioneel eronder voor de schaalbaarheid. Dus misschien kun je even nog uitleggen van de mensen die misschien afleveringen hiervoor niet gehoord hebben. Wat is Ray? Ja, Ray is een distributed runtime voor Python. En met die library kun je bestaande code over meerdere machines heen laten draaien. En waarom is dat dan handig om dat te kunnen doen? Nou, waar wij in de machine learning vaak tegenaan lopen, dat datasets niet meer passen in het geheugen van één computer. En dan is het fijn dat je kan zeggen, ik knip die dataset in een aantal partities op, en ik laat meerdere machines daaraan rekenen. Dat kan al met heel veel tools, er zijn meer tools die dit doen, alleen het unieke aan Ray is dat je begint met een eenvoudig Python programma, zonder speciale instructies, en als je merkt dat het niet meer past, dan kun je met speciale declaraties, met decorators kun je aangeven, Deze code moet je nu gaan uitschalen over meerdere machines in. En dan zeg je, app start je ray.remote, zet je het boven je functie, en dan is die functie is remote geworden. Nou, dat werkt dan heel mooi voor het uitschalen. Ray doet nog wel meer. Ray die heeft namelijk, dit wat ik net noemde, dat noemen ze tasks. Die zijn stateless ook. Maar je kan in Ray ook het actor pattern gebruiken. Dan verander je je code in een soort acteur, die van zichzelf weet wat voor staat hij inverkeert. Die wordt ergens op een machine gedraaid en er kunnen berichten naartoe gestuurd worden. En dan kun je zowel stateless programma's als stateful programma's draaien. Wat je soms ook in machine learning echt wel nodig hebt. Dat is een heel krachtig mechanisme, een heel simpel te gebruiken framework, want het werkt op je laptop, maar je kan er ook pdcloud in, naar 1000, 2000 nodes als je dat wilt, wat ze bij bedrijven als DoorDash ook zeker doen. Dat is een heel mooi framework, moet ik wel zeggen. Ja, en hoe moet ik dit plaatsen in het operations deel? Want zeg maar zeggen van dat die gedistribueerd moet worden en dat soort zaken is dan misschien wat iets meer def. Wat is de operations deel hiervan? Nou ja, kijk, wat je wel ziet is dat iedereen die grote systemen heeft gebouwd, merkt ook wel in productie, er is altijd wat aan de hand. Er valt altijd wel wat om. Een van de dingen die Ray heel slim doet, is dat als een van zijn taken die ergens op het noden draait omvalt, dan schedule hij hem automatisch op een andere. Als je operations moet doen, is dat wel heel erg prettig dat hij dat doet. Die full tolerance en automatisch de recovery van de spullen, dat zit er allemaal in gebouwd, dus je krijgt dat gewoon niet terug. Daarnaast wat ook heel erg opviel aan Ray, is de manier waarop je het kan monitoren. Je kan aan de buitenkant heel goed in de gaten houden, hoe ver is die eigenlijk met uitvoeren van alle stappen. Want ja, er is niks vervelende dat als je een job hebt van vijf uur, dat je vijf uur lang niks te zien krijgt. Dat wil je niet. Je wilt op al die individuele stappen kunnen monitoren, zodat je ook weet van wat duurt er nou precies te lang of welke stuk gaat er precies mis. Dat soort vraagstukken kun je dan allemaal beantwoorden. Dus dat zit er allemaal in gebouwd voor je. - Mooi. Nou, ik denk dat we een en hoop gezien, hoop geleerd, hoop geïnspireerd ook zijn. Mocht je nou de vorige aflevering nog niet geluisterd hebben, dan beveel ik die wel aan. Dus we hebben net een deel ML, deel Dev en nu dan de Ops. Hiermee is deze speciale Q-con San Francisco 2022 trilogie is het bijna. Lord of the Rings, Lord of the VR is nu klaar. Dankjewel voor het luisteren. Zorg dat je ons volgt, dan mis je geen aflevering. Spotify, Apple Music, kan je dat aanzetten. En dan krijg je even een ping als er weer een nieuwe aflevering online staat. Dankjewel voor het luisteren. En Willem, jij dankjewel voor de drie delen. Hopelijk dat je weer eens een keer snel te gast bent in de podcast. Zeker.