Dark Launch ist der beste Light Launch

Überall Ostereier

In meinem letzten Job haben wir Produktempfehlungssysteme für E-Commerce-Unternehmen entwickelt. Das bedeutet, dass unsere APIs auf jeder Seite ihrer Website live waren. Wir haben einen neuen Kunden bekommen, was unser erstes siebenstelliges Angebot war, und wir waren so vorsichtig, dass wir ihn im März zunächst mit regelbasierten Empfehlungen an Bord geholt haben. Wir wollten durch unsere im Entstehen begriffenen Machine-Learning-Modelle kein schlechtes Nutzererlebnis riskieren.

Später im April entwickelten wir Modelle für maschinelles Lernen und führten umfangreiche Offline-Tests und viele manuelle Qualitätssicherungen durch. Schließlich waren wir zuversichtlich, dass unser Modell eine gute Leistung erbringen wird, und dann haben wir es auf den Markt gebracht und zwei Dinge sind passiert:

1. Notruf: Wir erhielten innerhalb weniger Minuten einen Notruf von ihnen, während wir bereits über die Empfehlungsergebnisse verwirrt waren und versuchten, diese zu debuggen. Wir hatten auf fast jeder Seite ihrer Website Empfehlungen für Ostereier. Es stellte sich heraus, dass wir die Modell-ID mit dem Modell, das wir im April mit ihren Ostereinkaufsdaten trainiert hatten, falsch konfiguriert hatten! Wir haben die Modell-ID sofort auf die neue umgestellt und das Problem wurde behoben.
2. Erhöhung der p90-Latenz: Es stellte sich heraus, dass wir Produktbeschreibungen als Funktionen in unserem Modell verwendet haben und einige der Beschreibungen sehr lang waren, was unsere Berechnungszeit für Funktionen erhöhte. Dies war bei unseren Offline-Tests nicht leicht zu erkennen, da die Modelllatenz in den meisten Fällen in Ordnung zu sein schien. Es gab keine gute sofortige Lösung für dieses Problem und wir mussten im Grunde zum regelbasierten System zurückkehren, bis wir unsere Funktionen korrigiert und das Modell erneut getestet hatten.

Insgesamt führte dies zu vielen Brandbekämpfungsmaßnahmen, einem großen Glaubwürdigkeitsverlust und einem fast verlorenen Kunden. Bei unserer internen Rückschau später stellten wir fest, dass #1 zwar nur ein manueller Fehlschlag war, es aber fast unmöglich war, Probleme wie #2 offline zu erkennen. Seitdem haben wir uns der guten Seite der Dark Launches zugewandt!

Was ist Dark Launch?

Dark Launch ist eine Bereitstellungsstrategie, mit der Sie Ihren tatsächlichen Produktionsdatenverkehr an Ihren neu bereitgestellten Dienst wiedergeben und die Antwort verwerfen können, bevor Sie sie an den Benutzer zurückgeben. Es verhält sich so, als ob der Dienst tatsächlich live wäre, hat aber keinerlei Auswirkungen auf die Benutzer. Auf diese Weise können Sie überprüfen, ob Ihr neuer Dienst keine Fehler enthält, eine vergleichbare oder bessere Leistung als Ihr alter Dienst aufweist und die Produktionslast bewältigen kann. Sobald all dies verifiziert ist, ist es fast trivial, schrittweise auf Ihren neuen Dienst umzusteigen. Also in gewisser Weise

Dark Launch ist eine einfache Methode, um Ihre Dienste zu starten.

mit sehr minimalem Nachteil und großem potenziellen Aufwärtspotenzial.

Wie startet man Dark Launch?

Dark Launching Ihrer Dienste ist eine der realistischen Möglichkeiten, Ihre Dienste und Modelle auf einem produktionsähnlichen System zu testen. Die Durchführung eines Dark Launchs kann jedoch in Bezug auf Entwicklung, Überwachung und Infrastruktur innerhalb des Unternehmens eine Menge Vorbereitung und Reife erfordern.

1. Nehmen Sie eine Microservice-Architektur an: Es ist wichtig, eine API-gesteuerte Microservice-Architektur einzuführen, um Ihre neuen Dienste schrittweise testen zu können. Die Methode zur Ausführung bei einem Dark Launch besteht darin, eine Kopie des Produktionsdatenverkehrs an ein neues Backend abzuspielen. Dies ist am besten möglich, wenn der aktuelle Produktionsservice und der neue Dienst beide als Mikroservice verfügbar sind und die Kommunikation über einen REST-/gRPC-Aufruf erfolgt.
2. Verkehrsabzweiung: Am häufigsten ist das Anwendungs-Frontend der Ort, an dem die Benutzer den Traffic Fork durchführen, bei dem ein Prozentsatz des Produktionsdatenverkehrs an den neuen Dienst weitergeleitet wird.
3. Asynchrone Anrufe: Ein allgemeiner Grundsatz beim Testen ist, dass es Ihre tatsächliche Produktionserfahrung nicht negativ beeinflussen sollte. Beim Start im Dunkeln duplizieren Sie praktisch den Produktionsdatenverkehr, was Ihre Latenz verdoppeln kann, sofern Sie Ihre Backend-Aufrufe nicht asynchron ausführen. Wenn Ihr Service nicht latenzkritisch ist, kann es auch eine Lösung sein, angemessene Timeouts festzulegen.
4. Infrastruktur: Im Idealfall verfügt Ihr Unternehmen über eine Infrastruktur, die sich leicht horizontal skalieren lässt, denn wenn Sie den Prozentsatz der Zugriffe auf Ihren Dark Launch-Service erhöhen, müssen Sie auch Ihre Infrastruktur schrittweise skalieren. In den meisten Fällen kann es sogar sinnvoll sein, den gesamten Spitzenverkehr und darüber hinaus zu replizieren, um sicherzustellen, dass Ihr neuer Service auch wirklich skalierbar ist.
5. Protokollierung: Sie müssen die Anfrage und Antwort Ihrer alten und neuen Backend-Dienste protokollieren, um die Antwort und die Serviceleistung vergleichen zu können. Wenn es sich um ein Machine-Learning-Modell handelt, sollten Sie sicherstellen, dass Ihre Modellvorhersagen mindestens so gut sind wie Ihr altes Modell. Dies erfordert eine umfangreiche Protokollierung.
6. Überwachung: Dark Launch ist ziemlich nutzlos, wenn Sie keine guten Überwachungs- und Instrumentierungs-Dashboards haben, in denen Sie die Verfügbarkeit, Latenz, Skalierbarkeit und Reaktionsqualität Ihres neuen Dienstes vergleichen können. Idealerweise sollte dies in Echtzeit geschehen, damit Anomalien schnell erkannt und aufgedeckt werden können.

Ist Dark Launch nur ein schicker Offline-Test?

Offline-Tests ermöglichen es Ihnen, das zu überprüfen Verhalten Ihres Systems, in der Regel isoliert. Selten würde es Ihnen ermöglichen, das Komplettsystem zu testen zusammen mit dem Zustand der Umgebungssystem mit realistischen Verkehrs- und Netzwerkeinstellungen wie Produktion? 70% davon können Sie durch akribisches Loggen und sehr komplizierte Offline-Tests erreichen, aber Dark Launch stellt sich als viel einfacheres System heraus. Dies liegt daran, dass Sie sowieso die meisten der oben genannten Schritte ausführen, um einen Dienst normal zu starten und zu überwachen. Nachdem Sie einen erfolgreichen Dark-Launch durchgeführt haben, ist Ihre tatsächliche Veröffentlichung des neuen Dienstes fast trivial, sodass sich das Verhältnis von Aufwand und Belohnung lohnt.

Es gibt eine Reihe von Fällen, in denen dies praktisch schwer zu rechtfertigen sein könnte — zum Beispiel wenn Ihr Dienst statusbehaftet ist oder die Datenbank tatsächlich geändert wird dann ist ein Dark Launch viel komplizierter. Meiner persönlichen Erfahrung nach wird es so schwierig, die Richtigkeit des Systems sicherzustellen, dass es Es ist fast besser, sich einfach mit Offline-Tests gegenüber Dark Launch zufrieden zu geben!

Wenn du mehr neugierig auf Dark Launches bist oder etwas von deinen Erfahrungen teilen möchtest, melde dich bitte bei mir unter nikunj@truefoundry.com!

Wahre Gießerei ist ein ML Deployment PaaS über Kubernetes, um die Workflows von Entwicklern zu beschleunigen und ihnen gleichzeitig volle Flexibilität beim Testen und Bereitstellen von Modellen zu bieten und gleichzeitig die volle Sicherheit und Kontrolle für das Infra-Team zu gewährleisten. Über unsere Plattform ermöglichen wir Teams für maschinelles Lernen bereitstellen und überwachen Modelle innerhalb von 15 Minuten mit 100% iger Zuverlässigkeit, Skalierbarkeit und der Möglichkeit, innerhalb von Sekunden rückgängig zu machen. So können sie Kosten sparen und Modelle schneller für die Produktion freigeben, wodurch ein echter Geschäftswert erzielt wird.