Dark Launch é o melhor Light Launch

Ovos de Páscoa por toda parte

No meu último emprego, construíamos sistemas de recomendação de produtos para empresas de e-commerce – o que significa que nossas APIs estavam ativas em todas as páginas de seus sites. Conseguimos um novo cliente, que representava nosso primeiro negócio de 7 dígitos, e fomos tão cautelosos com eles que, inicialmente, os integramos em março com recomendações baseadas em regras. Não queríamos arriscar uma má experiência do usuário com nossos modelos incipientes de Machine Learning.

Mais tarde, em abril, desenvolvemos modelos de Machine Learning e realizamos testes offline extensivos e muita garantia de qualidade manual. Finalmente, nos sentimos confiantes de que nosso modelo teria um bom desempenho e então o lançamos, e duas coisas aconteceram—

1. Chamada de Emergência: Recebemos uma chamada de emergência deles em poucos minutos, enquanto já estávamos confusos com os resultados das recomendações e tentando depurá-los. Tínhamos recomendações de ovos de Páscoa em quase todas as páginas do site deles. Acontece que tínhamos configurado incorretamente o ID do modelo com o modelo que treinamos em abril com os dados de compras de Páscoa deles! Trocamos imediatamente o ID do modelo para o novo e o problema foi resolvido.
2. Aumento na latência p90: Acontece que estávamos usando descrições de produtos como características em nosso modelo e algumas das descrições eram muito longas, o que aumentou nosso tempo de computação de características. Isso não foi fácil de detectar durante nossos testes offline porque a latência do modelo parecia boa na maioria dos casos. Não havia uma boa solução imediata para este problema e basicamente tivemos que reverter para o sistema baseado em regras até corrigirmos nossa extração de características e retestarmos o modelo.

No geral, isso resultou em muito 'apagar incêndios', muita perda de credibilidade e um cliente quase perdido. Através de nossa retrospectiva interna posterior, percebemos que, embora o #1 tenha sido apenas um erro manual, era quase impossível detectar problemas como o #2 offline. Desde então, passamos para o lado bom de fazer 'dark launches'!

O que é 'dark launch'?

'Dark launch' é uma estratégia de implantação que permite reproduzir o tráfego real de produção para o seu serviço recém-implantado e descartar a resposta antes de retorná-la ao usuário. Ele se comporta como se o serviço estivesse realmente ativo, mas não afeta os usuários de forma alguma. Isso permite verificar se o seu novo serviço não possui erros, tem um desempenho comparável ou melhor em relação ao seu serviço antigo e pode lidar com a carga de produção. Uma vez que tudo isso é verificado, é quase trivial mudar para o seu novo serviço incrementalmente. Então, de certa forma,

'Dark launch' é uma maneira leve de lançar seus serviços.

com desvantagens mínimas e um enorme potencial de ganhos.

Como fazer um 'dark launch'?

Fazer 'dark launch' dos seus serviços é uma das formas realistas de testar seus serviços e modelos em um sistema semelhante ao de produção. No entanto, a execução de um 'dark launch' pode exigir muita configuração e maturidade dentro da organização do ponto de vista de desenvolvimento, monitoramento e infraestrutura.

1. Adote uma arquitetura de microsserviços: É importante adotar uma arquitetura de microsserviços orientada por API para poder testar incrementalmente seus novos serviços. A maneira de executar um lançamento sombrio é reproduzir uma cópia do tráfego de produção para um novo backend, o que é melhor feito se o serviço de produção atual e o novo serviço estiverem ambos disponíveis como microsserviços e a comunicação ocorrer por meio de uma chamada REST / gRPC.
2. Bifurcação de tráfego: Na maioria das vezes, o frontend da aplicação é onde as pessoas fazem a bifurcação de tráfego, roteando uma porcentagem do tráfego de produção para o novo serviço.
3. Chamadas assíncronas: Um princípio geral de teste é que ele não deve impactar negativamente sua experiência de produção real. Ao realizar um lançamento sombrio, você está praticamente duplicando o tráfego de produção, o que pode dobrar sua latência, a menos que você torne suas chamadas de backend assíncronas. Se o seu serviço não for crítico em termos de latência, definir tempos limite razoáveis também pode ser uma solução.
4. Infraestrutura: Idealmente, sua organização construiu uma infraestrutura fácil de escalar horizontalmente, pois, à medida que você aumenta a porcentagem de tráfego para o seu serviço de lançamento sombrio, você precisa escalar incrementalmente sua infraestrutura também. Na maioria dos casos, pode até fazer sentido replicar o tráfego de pico completo e além para garantir que seu novo serviço realmente escalará.
5. Registro de logs: Você precisará registrar a requisição e a resposta de seus serviços de backend antigos e novos para poder comparar a resposta e o desempenho do serviço. Se for um modelo de Machine Learning, você quer ter certeza de que as previsões do seu modelo são pelo menos tão boas quanto as do seu modelo antigo. Isso requer um registro de logs extensivo.
6. Monitoramento: O lançamento sombrio é bastante inútil se você não tiver bons painéis de monitoramento e instrumentação onde possa comparar o tempo de atividade, latência, escalabilidade e qualidade da resposta do seu novo serviço. Idealmente, isso deve acontecer em tempo real para que anomalias possam ser detectadas e expostas rapidamente.

O lançamento sombrio é apenas um teste offline sofisticado?

O teste offline permite verificar o comportamento do seu sistema, geralmente isoladamente. Raramente ele permitiria testar o sistema de ponta a ponta juntamente com o estado do sistema circundante com tráfego e configurações de rede realistas como na produção? Você pode alcançar 70% de tudo isso através de registro de logs meticuloso e testes offline muito complicados, mas o lançamento sombrio acaba sendo um sistema muito mais simples. Isso ocorre porque você de qualquer forma acaba fazendo a maioria das etapas acima para lançar e monitorar um serviço normalmente. Depois de realizar um lançamento sombrio bem-sucedido, o lançamento real do novo serviço é quase trivial, então a relação esforço-recompensa vale muito a pena.

Existem alguns casos em que isso pode ser difícil de justificar na prática — por exemplo, se o seu serviço tem estado, ou se ele realmente altera o banco de dados então fazer um dark launch é muito mais complicado. Na minha experiência pessoal, garantir a correção do sistema se torna tão difícil que é quase melhor simplesmente optar por testes offline em vez de um dark launch!

Se você tiver mais curiosidade sobre dark launches ou quiser compartilhar sua experiência, entre em contato comigo em nikunj@truefoundry.com!

TrueFoundry é uma PaaS de Implantação de ML sobre Kubernetes para acelerar os fluxos de trabalho dos desenvolvedores, ao mesmo tempo que lhes permite total flexibilidade no teste e implantação de modelos, garantindo total segurança e controle para a equipe de Infraestrutura. Através da nossa plataforma, capacitamos as equipes de Machine Learning a implantar e monitorar modelos em 15 minutos com 100% de confiabilidade, escalabilidade e a capacidade de reverter em segundos – permitindo-lhes economizar custos e lançar Modelos em produção mais rapidamente, possibilitando a realização de valor de negócio real.