Trends in MLOps - Deel 3 - Ops

Willem, we zijn aangekomen bij het derde en laatste deel over MLOps. Kun je jezelf even voorstellen aan de luisteraar?

Zeker. Ik ben Willem Meints. Ik werk als Chief AI Architect voor Aigency, onderdeel van Info Support. Daarnaast ben ik ook actief als Chapter Lead Data & AI voor de Business Unit Finance binnen Info Support. In deze rol help ik teams bij het opzetten van machine learning oplossingen die niet alleen werken, maar ook schaalbaar en beheersbaar zijn in productie.

Je was bij een sessie op Q-CON San Francisco die ging over het begrijpen van beslissingen achteraf. Wat was daar het centrale thema?

Ja, ik heb een hele interessante sessie bijgewoond die "How Did It Make Sense At That Time" heette, oftewel HDMI SATT. Het ging vooral over die laatste vraag: hoe heeft het op dat moment zin gemaakt? Het bijzondere was dat deze sessie niet specifiek over machine learning ging, maar de lessen zijn zeker toepasbaar op ons vakgebied. De kern was: als er iets fout gaat in je systeem, dan heeft dat meestal te maken met een beslissing die iemand op een bepaald moment heeft genomen. En op dat moment leek die beslissing volkomen logisch. De spreker benadrukte dat niemand 's ochtends uit bed stapt met de gedachte "zo, ik ga vandaag de boel eens lekker kapot maken". Toch gaan dingen regelmatig mis, soms op spectaculaire wijze. Hij gaf twee voorbeelden van grote bedrijven waar dingen echt fout zijn gegaan.

Wat waren die voorbeelden waar het zo mis ging?

Het eerste voorbeeld was van Salesforce. Iemand had daar iets met de DNS-configuratie veranderd, en dat werd vervolgens wereldwijd uitgerold. Het resultaat? Salesforce was vijf uur lang volledig offline, wereldwijd. Dat is natuurlijk enorm pijnlijk voor zo'n groot bedrijf. Maar het kan nog erger. Het tweede voorbeeld was van Atlassian, en dat was echt heftig. Daar was iemand bezig met het opruimen van test-omgevingen. Hij had een lijst gekregen van 883 ID's die verwijderd moesten worden. Hij had de procedure gevolgd, vijftien ID's gepakt, alles getest in acceptatie, alles volgens het boekje gedaan. Maar toen hij de rest van die lijst verwerkte, bleek dat het geen test-ID's waren maar daadwerkelijke site-ID's van klanten. Hij gooide dus per ongeluk een groot aantal klant-sites weg. De meesten waren niet meer terug te halen. Het resultaat? Veertien dagen outage. Dat is echt catastrofaal.

Hoe wordt er normaal gesproken naar zulke incidenten gekeken, en wat was het alternatief dat deze spreker voorstelde?

Normaal gesproken wordt er een root cause analysis gedaan, maar vaak wordt het zelfs een blame game: wie is de schuldige? Bij beide incidenten waren de analyses openbaar gemaakt. In die van Salesforce stond bijvoorbeeld dat iemand zich niet aan de policies had gehouden. Maar de spreker stelde de cruciale vraag: waarom leek het voor diegene op dat moment een goed idee? Hij gebruikte een hele herkenbare analogie. Hij zei: "Ik loop ook regelmatig door het rood. Mag niet, maar we doen het toch." En hoe meer haast je hebt, hoe vaker je het doet. Want bijna altijd gaat door rood lopen goed. Je kijkt naar links, naar rechts, nog een keer naar links, en je denkt: er komt niks aan, het is veilig om over te steken. Datzelfde geldt voor shortcuts in je dagelijks werk. Als je iets vaker hebt gedaan en het ging altijd goed, dan ben je geneigd om het weer te doen. En hoe drukker je bent, hoe meer risico's je neemt. Misschien had bij dat DNS-incident een belangrijke manager wel gezegd: "Pas die DNS even aan, ik heb straks een cruciale demo en ik kom er niet doorheen." Dan denk je: ik heb links gekeken, rechts gekeken, ik heb veel druk, dit kan vast wel even. Maar dat soort context staat niet in die publieke rapporten.

Dus je moet eigenlijk verder kijken dan alleen de technische root cause?

Precies. Het gaat erom dat je blijft doorvragen: waarom leek het op dat moment een goed idee? Dit geldt ook heel direct voor machine learning in productie. Als je problemen tegenkomt, moet je niet alleen naar de root cause kijken, maar ook naar de context waarin beslissingen zijn genomen. Wat was de druk? Wat waren de beperkingen? Wat leek logisch op dat moment? De spreker had nog een mooi statement, in het Engels: "Complex systems are intrinsically hazardous." Complexe systemen zijn van nature gevaarlijk. En hier komt het: je kan nog zoveel preventie doen, de catastrofe ligt altijd op de loer. Het is altijd net om de hoek. Je kunt nooit alles voorkomen, hoe goed je ook je best doet.

Wat is dan de oplossing? Hoe kunnen we leren van beslissingen die in het verleden zijn genomen?

Om dit soort situaties beter te begrijpen en er misschien wel van te voorkomen, is het belangrijk om documentatie te hebben voor jezelf, voor je toekomstige zelf. Je wilt documenteren waarom op dat moment dingen een goed idee leken. Dat brengt ons bij architectuurbesluitdocumentatie, wat eigenlijk een soort documentatie voor je toekomstige zelf is.

Hoe documenteer je dit dan concreet? Wat gebruik je daarvoor?

Een van de technieken die we veel gebruiken binnen Info Support zijn Architecture Decision Records, of ADR's. Het zijn hele eenvoudige documenten. Daarin staat: we hebben dit besluit genomen, dit was de achtergrond van het besluit, en dit zijn de gevolgen van het besluit. Omdat het zo eenvoudig is, gebruik je het ook echt. Het zijn geen Word-documenten, maar gewoon Markdown-bestanden. Markdown is een eenvoudige opmaaktaal waarbij je met simpele symbolen voor de tekst kunt aangeven: dit is een groot kopje, een middelgroot kopje, een opsomming, enzovoort. Maar het blijft gewoon platte tekst, helemaal niet fancy. We hebben ook geen fancy portalen of zo, dat is allemaal niet nodig.

Schrijf je dan hele verhalen in die documenten?

Nee, zeker niet. Het is heel kort en bondig. Geen proza. Vanmorgen was ik bijvoorbeeld bezig met het opzetten van een platformarchitectuur voor machine learning. Dat stond ook in Markdown en dat kon ik gewoon omzetten naar een mooi leesbaar document. Het was heel kort: dit zijn de besluiten, dit is het plaatje wat erbij hoort. Lean en mean, maar wel super duidelijk.

Welke tools gebruik je om die plaatjes te maken?

Ik gebruik Markdown voor de beschrijving, en die kun je in de meeste tools zoals GitHub, Azure DevOps of GitLab gewoon gebruiken. Die zetten het automatisch om naar HTML, zodat je het netjes kunt lezen. En omdat het Markdown is, heb je ook automatisch version control. Dat is niet iedereen misschien gewend, maar het werkt fantastisch. Je kunt de verschillen tussen versies heel makkelijk checken. Ik kan ook tegen een ontwikkelaar zeggen: "Hé, we hebben dit besproken in de meeting, maak even een aanpassing en geef me een pull request." Dan kan ik het zelfs reviewen voordat het in mijn documentatie komt te staan. Voor afbeeldingen gebruik ik PlantUML. Dat is een taal waarmee je declaratief kunt aangeven: ik heb een systeem, ik heb een gebruiker, ik heb een netwerkverbinding, ik heb een relatie, ik heb een context. Die dingen kun je in elkaar stapelen en met PlantUML genereer je daar dan een plaatje van. Het plaatje sla ik ook op in source control omdat dat makkelijk is, maar dat is niet het belangrijkste. Die originele definitie in PlantUML, die is belangrijk voor me. Dat is de documentatie voor je toekomstige zelf.

Dus het idee is dat je vastlegt waarom op dit moment, at this time, dit een goed besluit was?

Exact. Als er na een jaar of twee dingen kapot gaan, dan kun je teruggaan in je documentatie. Dan denk je misschien: "Welke idioot heeft dit bedacht?" En dan ontdek je: "Oh, die idioot was ik zelf." Maar dan zie je ook: "Oh, maar dat en dat en dat. Daarom heb ik het op die manier gedaan." Dat was inderdaad op dat moment de juiste keuze. En daar kun je dan van leren. Ik vond het een heel mooi idee: lean and mean documenteren, vooral geen blame game spelen, en verder gaan dan alleen een root cause analysis. Je vraagt je af: hoe komt het dat iemand tot dat besluit is gekomen om zo'n grove fout te maken? Want niemand komt 's ochtends uit bed met de gedachte: "Zo, ik ga eens even een grove fout maken waardoor alles veertien dagen uitvalt."

Er is toch ook een verschil tussen hoe werk op papier staat en hoe het in de praktijk wordt uitgevoerd?

Ja, dat was ook een belangrijk punt. Je kunt nog zoveel policies, guidelines, handleidingen en SOP's hebben. Maar er is een groot verschil tussen hoe het werk is opgeschreven en hoe het werk uiteindelijk wordt uitgevoerd. De spreker had daar een mooi plaatje bij van IKEA-meubels in elkaar zetten. Iedereen kent die handleidingen wel. In de praktijk zie je jezelf vaak denken: "Oh ja, ik had stap vier toch eigenlijk al gedaan," of "misschien pak ik hier eventjes een hamer bij." Je denkt: "Dat kan wel even zo." En halverwege kom je erachter: "Oh ja, maar nu zit iets toch een beetje scheef of andersom." En je houdt er krassen of groefjes aan over. Je kunt niet alles vangen in procedures. Dus accepteer een beetje chaos en ga ook weer terug naar waarom dingen gebeurd zijn. Dat vond ik een hele mooie insteek.

Je was ook bij een sessie over reliability testing. Wat hield die in?

Ja, ik was naar een sessie toegegaan van Vanguard, een Amerikaanse investeringsmaatschappij. Die hadden een sessie over chaos testing. Het idee is dat je expres fouten in een omgeving gaat introduceren. Je zet een server uit, of je maakt een netwerkverbinding kapot, of je gooit een database weg. En dan ga je kijken hoe je systeem reageert. De reden hiervoor is wat we eerder zeiden: je kunt nooit honderd procent weten wat er gaat gebeuren in productie. Je hebt het allemaal goed ontworpen, allemaal goed gedocumenteerd, oké, dat kan zo zijn. Maar het zou wel mooi zijn als je ook nog een paar testen kunt draaien op je infrastructuur om te controleren: wat gebeurt er als het fout gaat?

Is het dan de bedoeling dat het systeem zichzelf automatisch herstelt?

Nee, dat was niet haar verhaal. Zij zei: het gaat er juist om dat je je bewust wordt van wat de gevolgen zijn als het fout gaat. En ook of je het überhaupt kunt detecteren. Het hoeft niet automatisch up-and-running te blijven, als je maar verwacht dat het niet up-and-running is. Maar je moet het wel kunnen zien in je logging, bijvoorbeeld. Als je zo'n test gaat draaien, kun je van tevoren kijken welke signalen je dan al hebt. Tijdens de test kijk je welke signalen je uit dat systeem krijgt. En wat gebeurt er daarna? Komt het systeem bijvoorbeeld weer terug? Was dat de bedoeling dat het terugkwam? Of misschien was dat helemaal niet de bedoeling.

Waar kijk je dan precies naar in die testen?

In normale unit tests kijken we vooral naar: krijgen we het verwachte resultaat? Eén plus één wordt twee. Maar in dit geval kijk je naar: krijg ik uit mijn monitoring de juiste alerts terug? Krijg ik in de logfiles de juiste dingen terug? Kan ik dat ook bekijken? En je kijkt naar het juiste gedrag. Het kan zijn dat je verwacht dat iets na vijf minuten weer up komt. Dat zit ook in die flow, dat je dan vijf minuten wacht en checkt of bijvoorbeeld een database weer hersteld is waar je uit put met je machine learning model. En dan kan die verder.

Hoe zet je zo'n chaos test op? Is dat ook declaratief?

Ja, en dat was het mooie eraan. We hebben in deel één en deel twee allerlei declaratieve manieren gezien, en hier was ook een declaratieve aanpak. Ze maakten gebruik van Amazon AWS en gebruikten workflows om dat in elkaar te zetten. Je kunt dan blokken erin slepen die bepaalde standaardoperaties doen, standaardchecks en bijvoorbeeld die wachttijden. Dat hij vijf minuten gaat wachten totdat het systeem weer terug is. Dat zit er allemaal ingetekend. Het mooie daarvan is ook dat je het direct kunt documenteren en kunt 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.

Hoe verhoudt deze aanpak zich tot de Netflix Chaos Monkey? Dat is toch vergelijkbaar?

Het is wezenlijk anders. Chaos Monkey is willekeurig en die laat je los op je productieomgeving. Hopelijk is je systeem sterk genoeg om ertegen te kunnen. Deze benadering van Vanguard gaat niet op productie, maar op een staging-omgeving. En het is van tevoren uitgedacht. Ze legde niet heel precies uit hoe ze tot het ontwerp van die testen komen, maar wat wij in het verleden hebben gedaan is dat we een meeting hadden op ons team: The Wheel of Misfortune. Er werd van tevoren aan iemand van het team gevraagd: wil jij eens iets bedenken waarmee ons systeem kapot kan? Bijvoorbeeld het weggooien van de database. En dan gaan we met het team nadenken: wat gebeurt er dan allemaal volgens ons? Als je gaat nadenken over "stel, die database gaat kapot, wat gebeurt er dan allemaal?", dan kan je dat helpen om een ontwerp te maken voor zo'n chaos test.

Hoe werkt het concreet met die hypotheses?

Ze deden het hypothese-gebaseerd. Dit is de hypothese, die leggen ze vast, ook weer in YAML op een declaratieve manier. Dan gaat het systeem eronder werken. En dan kun je uiteindelijk checken of je hypothese uitkomt. Dus of je systeem weer up-and-running is, of dat je juist verwacht dat die dat niet is. Wat ik wel slim bedacht vond, is dat ze vooraf, voor het uitvoeren, toch een killswitch hadden. Want als er ergens een productieprobleem voorbijkomt en mensen willen ook door staging heen, dan willen die niet in de weg zitten met zo'n chaostest. Want je moet ook niet vergeten: het is niet gewoon even een korte test draaien. Zo'n chaostest kan echt enkele uren in beslag nemen als je een uitgebreid scenario hebt. Dan is die killswitch van wezenlijk belang om het goed te laten lopen.

Dus dit geeft weer inspiratie voor het ops-deel van MLOps?

Ja, absoluut. Het zorgt voor inspiratie hoe je hierover nadenkt op het gebied van het ops-deel van MLOps. Je kunt zo testen hoe robuust je machine learning pipeline is als er dingen misgaan. Wat gebeurt er als een model-server crasht? Wat als je feature store niet bereikbaar is? Dat zijn essentiële vragen voor machine learning in productie.

Nu komen we bij Ray, dat in bijna alle MLOps-sessies terugkwam. Kun je uitleggen wat Ray precies is?

Ray is een distributed runtime voor Python. Met die library kun je bestaande code over meerdere machines heen laten draaien. Waarom is dat handig? Nou, waar wij in machine learning vaak tegenaan lopen, is dat datasets niet meer passen in het geheugen van één computer. Dan is het fijn dat je kunt zeggen: ik knip die dataset in een aantal partities op, en ik laat meerdere machines daaraan rekenen. Er zijn meer tools die dit kunnen, maar 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 decorators aangeven: deze code moet je nu gaan uitschalen over meerdere machines. Je zet "@ray.remote" boven je functie, en dan is die functie remote geworden. Dan werkt dat heel mooi voor het uitschalen.

Doet Ray alleen task-distributie, of kan het meer?

Ray doet nog wel meer. Wat ik net noemde, dat noemen ze tasks. Die zijn stateless. Maar je kunt in Ray ook het actor pattern gebruiken. Dan verander je je code in een soort actor die van zichzelf weet in welke staat hij verkeert. Die wordt ergens op een machine gedraaid en er kunnen berichten naartoe gestuurd worden. Zo kun je zowel stateless programma's als stateful programma's draaien, wat je soms in machine learning echt wel nodig hebt. Het is een heel krachtig mechanisme en een heel simpel te gebruiken framework. Het werkt op je laptop, maar je kunt het ook naar de cloud brengen, naar duizend of tweeduizend nodes als je dat wilt, wat bedrijven als DoorDash ook zeker doen. Dat is een heel mooi framework, moet ik wel zeggen.

Maar hoe plaats je Ray in het operations-deel? Het klinkt meer als development. Wat is de operationele kant ervan?

Dat is een goede vraag. Kijk, wat je wel ziet is dat iedereen die grote systemen heeft gebouwd, ook in productie merkt: 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 een node draait omvalt, hij hem automatisch op een andere node opnieuw inplant, opnieuw schedule. Als je operations moet doen, is dat heel erg prettig. Die fault tolerance en de automatische recovery van de spullen, dat zit er allemaal ingebouwd, dus je krijgt dat gewoon cadeau. Dat is een enorm voordeel voor de operationele kant.

En hoe zit het met monitoring van Ray-jobs?

Wat ook heel erg opviel aan Ray, is de manier waarop je het kunt monitoren. Je kunt aan de buitenkant heel goed in de gaten houden: hoe ver is die eigenlijk met het uitvoeren van alle stappen? Want er is niks vervelenders dan dat je een job hebt van vijf uur en 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: wat duurt er nou precies te lang, of welk stuk gaat er precies mis? Dat soort vraagstukken kun je dan allemaal beantwoorden. Die monitoring zit er allemaal ingebouwd voor je. Je krijgt inzicht in resource-gebruik per task, je ziet waar bottlenecks zitten, je kunt precies zien welke nodes druk bezig zijn en welke idle zijn.

Dus Ray helpt eigenlijk met zowel de schaalbaarheid als de betrouwbaarheid van machine learning systemen in productie?

Precies. Het combineert schaalbaarheid met fault tolerance en observeerbaarheid. Dat zijn essentiële eigenschappen voor productiesystemen. Je kunt beginnen met simpele Python-code op je laptop, en als je systeem groeit kun je het geleidelijk uitschalen naar een cluster zonder je code fundamenteel te hoeven herschrijven. En doordat de monitoring en fault tolerance ingebakken zitten, kun je het ook daadwerkelijk betrouwbaar operationeel houden. Voor MLOps is dat essentieel. Je wilt niet dat je trainings-pipeline of je batch-inference job crasht omdat één machine uitvalt. Met Ray blijft je job gewoon doorlopen, en je krijgt inzicht in wat er gebeurt. Dat maakt het verschil tussen een systeem dat je constant moet babystten en een systeem dat robuust in productie draait.

Wat zijn de belangrijkste lessen uit deze hele serie over MLOps trends?

Als ik terugkijk op alle drie de delen, dan zie ik een duidelijk patroon. Ten eerste: declaratieve benaderingen winnen het van imperatieve code. Of het nu gaat om infrastructure as code, workflow-definities of chaos tests, overal zien we dat declaratieve aanpakken de voorkeur krijgen omdat ze beter te begrijpen, te onderhouden en te versie-controleren zijn. Ten tweede: documentatie is niet alleen voor anderen, maar vooral voor je toekomstige zelf. Architecture Decision Records en goede logging van waarom beslissingen zijn genomen, zijn essentieel. Niet om te blamen, maar om te leren en te begrijpen. Ten derde: chaos en falen zijn onvermijdelijk in complexe systemen. De kunst is niet om alle fouten te voorkomen, maar om te zorgen dat je systeem graceful kan omgaan met fouten, dat je ze kunt detecteren en dat je begrijpt wat er gebeurt als het misgaat. Vandaar het belang van chaos testing. En tot slot: tooling zoals Ray die schaalbaarheid, fault tolerance en observeerbaarheid combineert, wordt steeds belangrijker. Machine learning systemen worden groter en complexer, en we hebben tooling nodig die ons helpt om die complexiteit beheersbaar te houden zonder dat we alles vanaf nul moeten bouwen. Al deze trends samen laten zien dat MLOps volwassener wordt. We leren van de lessen uit traditionele software operations, maar passen die aan voor de specifieke uitdagingen van machine learning. Het gaat niet meer alleen om het trainen van modellen, maar om het bouwen van complete, betrouwbare systemen die waarde blijven leveren in productie. Kernpunten en Praktische Adviezen Documenteer beslissingen voor je toekomstige zelf: Gebruik Architecture Decision Records (ADR's) in Markdown om vast te leggen waarom je bepaalde keuzes hebt gemaakt. Focus op de context en waarom het op dat moment logisch leek. Ga verder dan blame games: Bij incidenten moet je niet alleen naar de root cause kijken, maar ook begrijpen waarom iemand dacht dat een bepaalde actie een goed idee was. Begrijp de druk en context waarin beslissingen werden genomen. Gebruik declaratieve tools waar mogelijk: Of het nu gaat om PlantUML voor diagrammen, YAML voor configuraties of workflows voor chaos tests - declaratieve benaderingen zijn beter te begrijpen en te onderhouden dan imperatieve code. Implementeer chaos testing: Test niet alleen of je systeem werkt wanneer alles goed gaat, maar vooral wat er gebeurt als dingen fout gaan. Doe dit hypothese-gebaseerd op staging-omgevingen met een killswitch. Accepteer dat chaos onvermijdelijk is: Complexe systemen zijn intrinsiek gevaarlijk. Je kunt niet alle fouten voorkomen, maar je kunt wel zorgen dat je systeem robuust is en dat je fouten kunt detecteren en begrijpen. Monitor op het juiste niveau: Bij lange-lopende jobs wil je niet vijf uur wachten op een resultaat. Zorg dat je op individuele stappen kunt monitoren om te zien wat lang duurt of waar het misgaat. Kies voor schaalbaarheid met fault tolerance: Ray biedt een unieke combinatie van eenvoud (begint met normale Python-code), schaalbaarheid (van laptop tot duizenden nodes) en ingebouwde fault tolerance. Ideaal voor machine learning workloads. Gebruik version control voor documentatie: Door je documentatie in Markdown in Git te zetten, kun je verschillen tracken, pull requests reviewen en heb je automatisch een geschiedenis van je beslissingen. Test je monitoring: Het is niet genoeg dat je systeem blijft draaien - je moet ook kunnen zien of het blijft draaien en de juiste alerts krijgen als het niet zo is. Begrijp het verschil tussen werk zoals opgeschreven en werk zoals uitgevoerd: Procedures en policies zijn belangrijk, maar in de praktijk neemt iedereen wel eens shortcuts. Houd daar rekening mee in je ontwerp en documentatie. AIToday Live is een podcast die zich richt op de nieuwste ontwikkelingen in AI en de impact ervan op verschillende sectoren. In elke aflevering spreken hosts Niels Naglé en Joop Snijder met experts uit het veld om inzicht te krijgen in de mogelijkheden en uitdagingen van AI-technologie. Luister via je favoriete podcast app: Spotify, Apple podcasts, YouTube Music, en meer.