Produtionized pipelines in ML

Great talk for whom are looking to get some benchmarks of produtionized machine learning.

Automating Netflix ML Pipelines with Meson

Summary: Davis Shepherd and Eugen Cepoi discuss the evolution of ML automation at Netflix and how that lead them to build Meson, an orchestration system used for many of the personalization / recommendation algorithms. They talk about challenges they faced, and what they learned automating thousands of ML pipelines with Meson.

Produtionized pipelines in ML

Servicing models with R using Plumber package

Shirin Glander made a great post about how to use Plumber to provide some servicing of R models an API. For whom are looking for methods to deploy ML learning algorithms in R in production, this post is mandatory.

The plumber package for R makes it easy to expose existing R code as a webservice via an API (https://www.rplumber.io/, Trestle Technology, LLC 2017).

You take an existing R script and make it accessible with plumber by simply adding a few lines of comments. If you have worked with Roxygen before, e.g. when building a package, you will already be familiar with the core concepts. If not, here are the most important things to know:

  • you define the output or endpoint
  • you can add additional annotation to customize your input, output and other functionalities of your API
  • you can define every input parameter that will go into your function
  • every such annotation will begin with either #' or #*

<

p class=”js-evernote-checked” style=”padding-left:60px;”>With this setup, we can take a trained machine learning model and make it available as an API. With this API, other programs can access it and use it to make predictions.

Servicing models with R using Plumber package

Why you need enforce reproducibility as habit

In the few months that I arrived in Movile, I saw some strange pattern about several “data analysis”. The pattern was: once the analysis is delivered by someone without any background of data science this kind of insight suddenly become a kind of dogma.

In other words, no one will check the information, and in most of the cases there is no code, no commit at github, no .sql file or .R/.py file with the scripts used.

The practical problem is: What if this information was deadly wrong? And worse: How to discover if this information was harmful to the business?

Seeing this, my first mission statement as Data Intelligence Tech Lead at that time was to enforce to every BI Developer, Revenue Assurance Data Analyst, and Data Scientist  that every code must be reproducible no matter what conditions. Every insight must be delivered with some code in github.

Someone could say: “Wow… We have a little dictator here!”

With this simple rule, we are having this not exhaustive list of positive effects:

  • We’re collecting until today a huge dividend about the reproductive science: Any opinion have a code behind, and this code can be tested for anyone with access in github. This avoids the “excel kid” to drive any decision making without one hand on their shoulder, BEFORE the decision making;
  • We unmasked several “BS artists” that exploit the lack of data literacy of our internal clients (e.g. analysts, managers, et cetera) showing unnecessary complexities or delusional estimates without any kind of method behind; and
  • We developed a culture to be very skeptic about our estimates, especially to what we do not know about the data (a.k.a. exogenous factors about the market, brazilian economy, and so on). In another words: We stop to guessing about what we don’t know at that time and MADE IT CLEAR for our internal clients.

To know a little bit more how we operate, this article was the key reference for us to built our culture of compliance and deployment.

 

No matter what time crunch you are facing, it’s not worth putting a flaky implementation of an analysis into production. As data scientists, we are working to create a culture of data-driven decision-making. If your application breaks without an explanation (likely because you are unable to reproduce the results), people will lose confidence in your application and stop making decisions based on the results of your application. Even if you eventually fix it, that confidence is very, very hard to win back.

Data science teams should require reproducibility in the same way they require unit testing, linting, code versioning, and review. Without consistently producing results as good or better than known results for known data, analyses should never be passed on to deployment. This performance can be measured via techniques similar to integration testing. Further, if possible, models can be run in parallel on current data running through your systems for a side-by-side comparison with current production models.

Don’t get me wrong: Without any kind of compliance about your analysis, your organization will be a house of BS artists and any benefit to extract insights of the data, will be contaminated with BS hidden bias and can lead to several disasters in decision making, as we already experienced.

Why you need enforce reproducibility as habit

Microserviços em Machine Learning – Parte 1: Uma (nano)introdução

Este post é uma pequena reflexão sobre uma das melhores palestras do evento The Developers Conference (TDC/2016) de São Paulo que foi a do Gilmar Souza sobre modelos de Machine Learning em produção e de algumas notas do livro do Sam Newman (Building Microservices) além de algumas referências auxiliares.

Um dos assuntos mais discutidos nas comunidades de Data Science/Machine Learning é a atual necessidade da transposição dos modelos stand-alone para ambientes de produção; o que é chamado hoje de Core Machine Learning.

Dessa forma vamos abstrair essa questão da transposição ou não e falaremos direto sobre modelos de arquitetura para Core Machine Learning.

Na palestra do Gilmar ele coloca uma série de potenciais implementações de modelos de ML em produção como (a) re-implementação do modelo via linguagem de programação nativa da plataforma; (b) exportação do modelo em PMML para o ambiente de produção e load em uma suíte de ML para devolver o resultado das predições; (c) Projeção; e finalmente (d) Microserviço que pode ser tanto via chamadas HTTP e/ou REST API dentro de serviços nativos e/ou plataformas de Machine Learning as a Service como Google Prediction, Azure Machine Learning ou Amazon Machine Learning.

A principal diferença de abordagem em termos de Core ML é que no item (a) o algoritmo de ML é totalmente embutido no sistema de produção e na abordagem (d) há uma estrutura auxiliar separada para realizar esse tipo de tarefa, que no caso é o Microserviço.

Mas a primeira pergunta que fica é: O que são os microserviços?

De acordo com o Sam Newton os microserviços é uma abordagem para sistemas distribuídos que promove o uso de serviços mais granulares com os seus próprios ciclos de vida.

Da perspectiva do Sam, esses microserviços são modelados ao redor de domínios de negócios para evitar os problemas das tradicionais arquiteturas monolíticas, isto é, arquiteturas que consideram um sistema único com todos os seus módulos em uma única aplicação.

Então, sabe aquele mel gostoso que você consome? Ele é totalmente feito em uma estrutura de microserviços. Foto: My honey supers by Mandie

Buscando uma outra definição, agora do lendário Martin Fowler e do James Lewis, traduzido do blog do Pedro Mendes temos uma ideia de como é o design dessa arquitetura:

[…] (O) microsserviço é uma abordagem [1] para desenvolver uma única aplicação como uma suíte de serviços, cada um rodando em seu próprio processo e se comunicando através de mecanismos leves, geralmente através de uma API HTTP. Estes serviços são construídos através de pequenas responsabilidades e publicados em produção de maneira independente através de processos de deploys automatizados. Existe um gerenciamento centralizado mínimo destes serviços, que podem serem escritos em diferentes linguagens e usarem diferentes tecnologias para armazenamento de dados.[…]

Vamos ver na prática como seria essa diferença em termos de arquitetura de uma estrutura monolítica seja para outra de microserviços na figura abaixo:

Referência: http://www.martinfowler.com/articles/microservices.html

Como podemos ver, cada elemento/funcionalidade da plataforma/sistema na estrutura monolítica é inserida dentro da aplicação como um todo; já nos microserviços esse funcionalidades são replicadas e isoladas ao longo dos servidores e usadas conforme a necessidade.

Em linhas gerais o que é definido nessa arquitetura é que esses sistemas distribuídos atuam de forma autônoma dentro de um determinado espectro de pequenas atividades específicas através de um serviço.

Extendendo um pouco mais esse conceito, vamos usar alguns dos pontos principais das definições do Sam Newton das características dos microserviços que são:

(a) são sistemas pequenos e focados em fazer bem uma única coisa, isto é, há uma coesão dentro do domínio do negócio no qual o serviço está atrelado; e

(b) baixo acoplamento, o que na prática significa que a manutenção nessa abordagem não afeta o sistema como um todo e sim somente um pequena parte;

Quando falamos de sistemas monolíticos distribuídos logo vem a mente o clássico livro do Michael Feathers chamado Working Effectively with Legacy Code (tradução livre: Trabalhando com código legado) que é uma bíblia para quem trabalha com código/arquiteturas não tão bem desenhadas que constantemente tem problemas de bugs, interdependências desnecessárias, complexidades escondidas o que deixa qualquer atividade de incorporação de novas features ou refactoring um verdadeiro pesadelo que se torna realidade.

E se pensarmos que na grande parte das vezes não estamos nem construindo software novo, mas sim colocando 90% do nosso esforço para manutenção de código antigo não soa tão mal assim pensarmos que faz sentido a adoção deste tipo de arquitetura de microserviços.

Uma das principais características no que se refere aos microserviços é que o isolamento do deployment (e por consequência a autonomia que o sistema tem por conta desse isolamento) é que se ao mesmo tempo o sistema/plataforma legada não é afetado por modificações, com os microserviços a manutenção tende a ganhar uma escala muito maior em termos de volume e administração (óbvio que se tratando de tecnologias de Continuous Integration há tecnologias como Chef e o Jenkins que fazem muito bem esse papel, mas prática é uma questão muito mais complexa de sincronização, orquestração e janelas de deployment; ou seja: não existe resposta fácil aqui).

Nem tudo são rosas quando falamos de microserviços. Se considerarmos alguns pontos do próprio Martin Fowler podemos ver que os microserviços ainda tem alguns calcanhares de Aquiles que são:

(a) aumento da complexidade de mecanismos de tolerância à falha (no caso o Netflix tem até uma aplicação para forçar isso de maneira arbitrária para aumentar a resiliência de suas plataformas);

(b) com maior volume de pequenos serviços distribuídos a parte de disponibilidade passa a ser muito mais crítica e difícil de lidar, o que coloca uma pressão altíssima nas questões de monitoramento e alarmística (o que no caso será um aumento violento da quantidade de alertas sobre jobs, fluxos de sincronização e orquestração em casos que se fosse em um sistema monolítico um time de Dev Ops poderia trabalhar com muito mais foco e minimizar o RTO e o RPO).

Na prática, assim como o número de serviços aumenta, os pontos de falha aumentam multiplicam-se na mesma velocidade;

(c) aumento da latência entre aplicações. Na prática funciona assim: uma coisa é um contexto de 200ms de tempo de resposta em uma arquitetura com um baixo grau de requisições com apenas um módulo de microserviço; outra completamente diferente é ter esses mesmos 200ms através de uma pilha de 6 aplicações interdependentes com mais de 120 milhões de requisições por dia;

(d) heterogeneidade do stack de tecnologia. Em alguns casos os sistemas monolíticos tem (ou ao menos deveriam ter) uma espécie de lingua franca para a construção da plataforma/sistema. Já com os microserviços, como vimos anteriormente eles tem um isolamento que restringe (minimiza) o impacto em plataformas adjacentes; mas que no entanto podem não obedecer algum tipo de padrão de tecnologia. Na prática, você pode ter um stack com um serviço escrito em Java, outro em Elixir, outro em Clojure, alguns até mesmo em Erlang.

Na prática isso é extremamente difícil de trabalhar, o que demanda um tempo maior de desenvolvedores full stack dado que essa abordagem pode em algum grau aumentar o número de redundâncias desnecessárias, limitar a produtividade e de quebra promover ainda mais a epidemia de desenvolvedores Resumé Driven que escolhem a melhor tecnologia para os seus respectivos CVs mas que deixam (muitas) pequenas bombas relógio nas aplicações/sistemas/plataformas mundo a fora.

Agora que temos a definição bem generalista do que é um microserviço, em um próximo post vamos explorar essa ideia para aplicações de Machine Learning dentro desse mesmo universo.

Palestra do Gilmar Souza no TDC 2016 Trilha Machine Learning

Uma ótima referência sobre ML em produção

Machine learning at NRK: From prototype to production: Øyvind Holmstad, Thomas Oldervoll from JavaZone on Vimeo.

Microserviços em Machine Learning – Parte 1: Uma (nano)introdução