Dark Launch is de beste Light Launch

Überal paaseieren

In mijn vorige baan bouwden we productaanbevelingssystemen voor eCommerce-bedrijven - wat betekende dat onze API's live waren op elke pagina van hun website. We kregen een nieuwe klant, onze eerste deal van 7 cijfers, en we waren zo voorzichtig met hen dat we hen in maart initieel hebben geonboard met regelgebaseerde aanbevelingen. We wilden niet het risico lopen op een slechte gebruikerservaring door onze beginnende Machine learning-modellen.

Later in april bouwden we Machine learning-modellen en voerden we uitgebreide offline testen en veel handmatige QA uit. Uiteindelijk hadden we er alle vertrouwen in dat ons model goed zou presteren en gingen we over tot de lancering. Toen gebeurden er twee dingen -

1. Noodoproep: We kregen na een paar minuten een noodtelefoontje van hen, terwijl we zelf al in verwarring waren over de aanbevelingsresultaten en deze probeerden te debuggen. We hadden paasei-aanbevelingen op bijna elke pagina van hun website. Het bleek dat we de model-id verkeerd hadden geconfigureerd met het model dat we in april hadden getraind met hun Paas-winkeldata! We hebben het model-id onmiddellijk omgezet naar het nieuwe en dat probleem was opgelost.
2. Toename in p90 latency: Het bleek dat we productbeschrijvingen als features in ons model gebruikten en sommige beschrijvingen waren erg lang, wat onze feature-berekeningstijd verlengde. Dit was niet gemakkelijk te detecteren tijdens onze offline testen omdat de model-latency in de meeste gevallen prima leek. Er was geen goede directe oplossing voor dit probleem en we moesten in feite terugvallen op het regelgebaseerde systeem totdat we onze featurization hadden hersteld en het model opnieuw hadden getest.

Al met al leidde dit tot veel brandjes blussen, een groot verlies aan geloofwaardigheid en een bijna verloren klant. Tidens onze interne evaluatie achteraf realisseerden we ons dat hoewel #1 een handmatige fout was, het bijna onmogelijk was om problemen zoals #2 offline te detecteren. Sinds die tijd zijn we overgestapt naar de zonnige zijde van dark launches!

Wat is een dark launch?

Een dark launch is een deployment-strategie waarmee u uw werkelijke productie-verkeer kunt naspelen naar uw nieuw geachte service en de response kunt weggooien voordat deze naar de gebruiker wordt geretourneerd. Het gedraagt zich alsof de service daadwerkelijk live is, maar het beïnvloedt de gebruikers op geen enkele wijze. Dit stelt u in staat om te verifiëren dat uw nieuwe service geen fouten bevat, vergelijkbare of betere prestaties levert ten opzichte van uw oude service, en de productielast kan verwerken. Zodra dit allemaal is geverifieerd, is het bijna triviaal om daadwerkelijk incrementeel over te stappen naar uw nieuwe service. Dus in zekere zin,

Is een dark launch een lichte manier om uw services te lanceren.

met een zeer beperkt nadeel en een enorm potentieel voordeel.

Hoe voert u een dark launch uit?

Het dark launchen van uw services is een van de meest realistische manieren om uw services en modellen te testen op een productie-achtig systeem. Maar het uitvoeren van een dark launch kan veel opzet en volwassenheid binnen de organisatie vereisen vanuit een ontwikkelings-, monitoring- en infrastructuuroogpunt.

1. Luidt een microservice-architectuur in: Het is belangrijk om een API-gedreven microservice-architectuur te hanteren om uw nieuwe services incrementeel te kunnen testen. De manier om een dark launch uit te voeren is door een kopie van het productieverkeer na te spelen naar een nieuwe backend, wat het beste werkt als de huidige productieservice en de nieuwe service beide beschikbaar zijn als microservice & de communicatie plaatsvindt via een REST / gRPC call.
2. Traffic forking: Meestal is de frontend van de applicatie de plek waar mensen traffic forking toepassen, waarbij een percentage van het productieverkeer naar de nieuwe service wordt geleid.
3. Async calls: Een algemeen testprincipe is dat het uw werkelijke productie-ervaring niet negatief mag beïnvloeden. Bij een dark launch dupliceert u praktisch het productieverkeer, wat uw latency met 2x kan verhogen, tenzij u uw backend calls async maakt. Als uw service niet latency-kritisch is, kan het instellen van redelijke timeouts ook een oplossing zijn.
4. Infrastructuur: Idealiter heeft uw organisatie infrastructuur gebouwd die eenvoudig horizontaal kan schalen, want naarmate u het verkeerspercentage naar uw dark launch-service verhoogt, moet u incrementeel ook uw infrastructuur opschalen. In de meeste gevallen kan het zelfs zinvol zijn om het volledige piekverkeer en meer te dupliceren om er zeker van te zijn dat uw nieuwe service echt zal schalen.
5. Logging: U zult de request & response van uw oude en nieuwe backend services moeten loggen om de response en serviceprestaties te kunnen vergelijken. Als het een Machine Learning-model betreft, wilt u er zeker van zijn dat uw modelvoorspellingen minstens zo goed zijn als die van uw oude model. Dit vereist uitgebreide logging.
6. Monitoring: Een dark launch is vrij nutteloos als u geen goede monitoring- & instrumentatiedashboards hebt waar u de uptime, latency, schaalbaarheid en kwaliteit van de response van uw nieuwe service kunt vergelijken. Idealiter gebeurt dit in real-time, zodat anomalieën snel kunnen worden gedetecteerd en gesignaleerd.

Is dark launch gewoon een chique naam voor offline testen?

Offline testen stelt u in staat om het gedrag van uw systeem te controleren, meestal in isolatie. Zelden stelt het u in staat om het end-to-end systeem te testen samen met de status van het omringende systeem met realistisch verkeer en netwerkinstellingen zoals in productie? U kunt 70% van dit alles bereiken door nauwkeurige logging en zeer ingewikkeld offline testen, maar een dark launch blijkt een veel eenvoudiger systeem te zijn. Dit komt omdat u uiteindelijk toch de meeste van de bovenstaande stappen uitvoert om een service normaal te lanceren en te monitoren. Nadat u een succesvolle dark launch hebt uitgevoerd, is uw daadwerkelijke release van de nieuwe service bijna triviaal, waardoor de inspanning-beloningsverhouding ruimschoots de moeite waard wordt.

Er zijn een paar gevallen waarin dit praktisch gezien moeilijk te rechtvaardigen is - bijvoorbeeld, als uw service stateful is, of als het daadwerkelijk de database wijzigt, dan is het uitvoeren van een dark launch een stuk ingewikkelder. In mijn persoonlijke ervaring wordt het waarborgen van de correctheid van het systeem zo moeilijk dat het bijna beter is om te kiezen voor offline testen boven een dark launch!

Als u meer nieuwsgierig bent naar dark launches of uw ervaringen wilt delen, neem dan gerust contact met mij op via nikunj@truefoundry.com!

TrueFoundry is een ML Deployment PaaS over Kubernetes om developer workflows te versnellen, terwijl ze volledige flexibiliteit behouden bij het testen en deployen van modellen met behoud van volledige beveiliging en controle voor het Infra-team. Via ons platform stellen we Machine learning-teams in staat om modellen te deployen en monitoren in 15 minuten met 100% betrouwbaarheid, schaalbaarheid en de mogelijkheid om binnen seconden te roolbacken - waardoor ze kosten besparen en Modellen sneller naar productie brengen, wat zorgt voor het realiseren van echte bedrijfswaarde.