Jupyter Notebooks e VS Code Hospedados no Kubernetes

Jupyter notebooks são uma ferramenta poderosa e popular que oferece um ambiente de computação interativo, combinando código, visualização de dados e texto explicativo, facilitando o trabalho com dados e o compartilhamento de insights.  Cientistas de dados usam Jupyter notebooks para diversas tarefas ao longo do ciclo de vida da análise de dados e aprendizado de máquina, como análise exploratória de dados (EDA), pré-processamento de dados, visualização, desenvolvimento de modelos, avaliação e validação, etc. Para muitos desses casos de uso, apenas instalar o Jupyter Notebook no seu laptop é suficiente para começar. No entanto, para muitas empresas e organizações, esta não é uma opção e precisamos de Jupyter notebooks hospedados.

Por que precisamos de Jupyter notebooks hospedados?

1. Acesso a recursos: Muitas cargas de trabalho de Ciência de Dados exigem computação pesada que não pode ser suportada por máquinas locais de DS ou MLEs. Os Jupyter notebooks hospedados podem fornecer aos DS/MLEs acesso a máquinas poderosas e GPUs.
2. Acesso e Segurança de Dados: Em muitas empresas, DS/MLEs trabalham em projetos que envolvem dados sensíveis que não podem ser baixados no laptop do funcionário. Assim, com Jupyter notebooks hospedados, as empresas podem fornecer acesso aos DS/MLEs para trabalhar em projetos sensíveis.
3. Reprodutibilidade e Colaboração: Jupyter Notebooks hospedados são uma excelente forma de compartilhar código executável e resultados dentro de uma equipe. Como o ambiente de desenvolvimento é o mesmo, os resultados são 100% reproduzíveis e os membros da equipe podem colaborar em projetos.

Como uma empresa pode fornecer Notebooks hospedados aos seus cientistas de dados?

Aqui estão as opções que uma empresa pode ter hoje para fornecer acesso ao Jupyter Notebook aos seus engenheiros:

Provisionar uma VM para cada Cientista de Dados:

DS/MLEs podem configurar o ambiente e executar um jupyter-server em uma VM que pode ser usada para executar as cargas de trabalho. Aqui está um guia simples sobre como você pode executar o jupyterlab em uma instância ec2.

👍 Prós:
- Oferece controle total da máquina para um DS
- Todo o ambiente é persistente. A VM pode ser parada e reiniciada no mesmo estado.

👎 Contras:
- Alto custo de computação em nuvem - Não haverá recurso de parada automática. O DS pode iniciar uma VM e deixá-la sem utilização por grande parte do tempo, aumentando assim os custos.
- Difícil de gerenciar e rastrear um grande número de VMs centralizadamente.
- O DS precisa configurar muitas coisas para preparar o ambiente de trabalho para iniciar a experimentação.
- Dificuldade na reprodutibilidade - O DS pode ter instalado vários pacotes que não são mais rastreados e leva muito tempo para colocar em produção o código que roda nessa VM.

Usar uma Solução Gerenciada:

Outra opção pode ser usar uma solução gerenciada como AWS Sagemaker, Vertex AI Notebooks ou Azure ML Notebooks. Embora cada um desses métodos tenha vantagens, aqui estão alguns prós e contras deles em geral.

Vamos discutir o que cada um desses campos significa:

• Ambientes Persistentes: Isso se refere à persistência do ambiente Python. (Se as instalações de pacotes pip e os ambientes criados pelo usuário são salvos após as reinicializações do Notebook ou não)
• Instalações de Root Persistentes: Quando o acesso root é fornecido ao usuário, se as instalações de pacotes root (por exemplo, apt install pkgs) persistem ou não após as reinicializações do Notebook.
• Monitor de Uso de Recursos: Se o usuário pode ou não monitorar o uso de CPU/Memória a partir do notebook, dentro da própria tela do notebook.
• Suporte a Servidor de Código: Se a instância do notebook pode ser conectada a um servidor VS Code hospedado.
• SSH no contêiner: Capacidade de acessar via SSH um notebook em execução e conectar-se a partir da máquina local
• Parada Automática: Funcionalidade para parar o notebook após "Período de Inatividade". O Vertex oferece esta funcionalidade na sua versão "Managed Notebooks". O Sagemaker tem uma forma de parar notebooks após um tempo de inatividade, mas a pessoa precisa configurar um "Init Script" para isso, em vez de uma opção de implantação simples, o que gera um pouco de atrito para o usuário.
• Suporte Multi-Cloud: Esta funcionalidade é exclusiva da Truefoundry, pois você pode executar o notebook em qualquer um dos três provedores de nuvem com a mesma experiência de usuário.
• Personalização da Imagem: Iniciar o notebook com um conjunto específico de pacotes pré-instalados.
• Montar Volume Compartilhado no Notebook: Notebooks fornecidos por cada um dos provedores de nuvem (AWS/Azure/Vertex) permitem a criação de um volume separado para cada notebook, mas não oferecem uma forma de montar um volume compartilhado. Por exemplo, considere que uma empresa possui um conjunto de dados de 500GB que está sendo usado por vários Cientistas de Dados para diferentes casos de uso. Agora, cada CD precisa duplicar esses dados e pagar pelo custo de múltiplos volumes, mesmo quando os notebooks não estão em execução. Isso poderia potencialmente drenar centenas e milhares de dólares em custos de nuvem!
  Com a Truefoundry, você pode montar um volume do tipo NFS em modo somente leitura em múltiplos notebooks, economizando assim os custos de duplicação de dados!

Hospedar Notebooks sobre Kubernetes:

Outra opção pode ser hospedar notebooks sobre Kubernetes, mas isso vem com seu próprio conjunto de desafios, pois os cientistas de dados não podem interagir diretamente com o Kubernetes e precisam de um software intermediário que forneça uma interface simples para iniciar notebooks Jupyter. Vejamos quais são as opções disponíveis para isso:

Operador de Notebook do Kubeflow:
Kubeflow ajuda a tornar as implantações de fluxos de trabalho de aprendizado de máquina (ML) no Kubernetes simples, portáteis e escaláveis. Ele possui um recurso de notebook que ajuda a gerenciar e executar notebooks facilmente.
Embora o Kubeflow seja um grande projeto de código aberto que oferece muitas funcionalidades para casos de uso de Machine Learning, é muito difícil instalar e gerenciar o Kubeflow por conta própria.

👍 Prós:
- Fácil de iniciar e gerenciar notebooks para CD
- Diretório inicial persistente com suporte de disco
- Opção para imagens pré-definidas para sklearn, pytorch e tensorflow, que vêm com todas as dependências instaladas.
- Código-base de código aberto
- Obter um recurso de encerramento automático que interrompe notebooks após algum tempo de inatividade.

👎 Contras:
- Difícil de configurar o Kubeflow no Kubernetes. Leva muito tempo para instalar e manter o Kubeflow
- Para fornecer notebooks em várias regiões, diferentes clusters Kubernetes precisam ser criados e o Kubeflow precisa ser instalado em cada cluster - o que leva a altos custos de infraestrutura e manutenção.
- Os pacotes Python não são persistentes por padrão, o que significa que você precisa instalar os pacotes cada vez que reinicia
- Nenhuma maneira direta de obter acesso root ao contêiner [ pode ser útil para vários casos de uso ]
- Parar notebooks não pode ser configurado a nível de notebook e é uma configuração global. 

Hospedar JupyterHub no Kubernetes:
JupyterHub é uma ótima configuração para casos de uso multiusuário, o que ajuda no uso ideal dos recursos. A implantação do JupyterHub no Kubernetes pode ser feita com um projeto de código aberto chamado Zero a JupyterHub com Kubernetes:

👍 Prós:
 - Vários usuários podem trabalhar juntos facilmente com suporte a autenticação
 - Configuração fácil de parada automática para notebooks
 - Fácil gerenciamento de ambientes

👎 Contras:
- Difícil de configurar e gerenciar. É preciso configurar Rede, Volumes Persistentes, Escalabilidade e Balanceamento de Carga para que o JupyterHub funcione corretamente.
- Difícil executar cargas de trabalho de GPU em diferentes tipos de GPUs no Jupyterhub. Por exemplo, leia isto.
- Ambientes não são persistentes

Embora existam muitas soluções disponíveis atualmente, cada uma delas apresenta seu próprio conjunto de limitações. Na Truefoundry, tentamos preencher essa lacuna e construir uma solução de notebook que satisfaça todas as necessidades de um Cientista de Dados (DS) e também mantenha os custos sob controle. Na próxima seção, descreveremos nossa abordagem para construir a solução de notebook e os desafios que enfrentamos ao fazê-lo.

A abordagem da Truefoundry para construir uma solução de Notebook

Truefoundry é uma plataforma de desenvolvedores para equipes de ML que ajuda na implantação de Modelos, Serviços, Jobs e, agora, Notebooks no Kubernetes. Você pode ler mais sobre o que fazemos aqui.  Nossa motivação para construir uma solução de notebook foi simplesmente permitir a experimentação e o desenvolvimento em nossa plataforma. Após estudar todas as soluções disponíveis, decidimos resolver os pontos problemáticos e as funcionalidades ausentes em outras plataformas para que os cientistas de dados pudessem ter a melhor experiência sem incorrer em muitos custos. Algumas coisas que queríamos possibilitar são:

1. Persistir ambientes
2. A capacidade do usuário de instalar dependências raiz dinamicamente e não se limitar a alguns conjuntos de dependências.
3. Capacidade de executar de imediato em certos casos, uma vez que os seus preços podem ser drasticamente mais baixos. A experiência pode ser ruim em alguns casos, pois a VM pode ser reivindicada, mas descobrimos que isso é bastante raro na prática e o custo-benefício justifica o contratempo ocasional.
4. Capacidade de configurar a parada automática para economizar custos.

Construído sobre  Kubeflow Notebooks

O Kubeflow suporta a execução de notebooks no Kubernetes. Ele oferece uma série de recursos para notebooks prontos para uso. No entanto, queríamos resolver os problemas que destacamos acima nos Notebooks do Kubeflow e proporcionar uma experiência fluida para cientistas de dados e desenvolvedores.

Então, tivemos que fazer alterações no controlador de notebooks, integrá-lo com o backend da Truefoundry e disponibilizamos os notebooks em nossa UI.

Instalamos o controlador de notebooks, mas deparamo-nos com alguns problemas, por causa dos quais tivemos que fazer alterações no kubeflow-notebook-controller:

1. A desativação (recurso de parada automática para Notebooks) não funciona com endpoints personalizados. O Kubeflow Notebook Controller dependia de certos formatos de endpoint para que a desativação funcionasse. Isso limita o usuário a definir o endpoint de sua escolha.
2. Mesmo Tempo Limite de Desativação em todo o cluster. Isso significa que você só pode definir um "Tempo Limite de Inatividade" para notebooks em nível de cluster. Não é possível definir valores de tempo limite de desativação diferentes para notebooks diferentes.
3. O ambiente Python padrão não é persistente

Resolvemos os dois problemas acima e lançamos o tfy-notebook-controller
e o publicamos como um helm-chart no repositório de Charts Públicos da Truefoundry. Você pode encontrar o chart aqui.

UI para criar, iniciar e parar notebooks:

Criamos uma interface de usuário fácil de entender para cientistas de dados iniciarem notebooks. O usuário pode personalizar o Tempo Limite de Inatividade (tempo de inatividade após o qual o notebook será parado), o Tamanho do Volume Persistente (Tamanho do Disco que armazena o Conjunto de Dados e os arquivos de código), os Recursos (requisitos de CPU, Memória e GPU) e iniciar o notebook!

Com todas essas mudanças, lançamos o v0 dos nossos notebooks.

Mas ainda estamos longe de uma boa experiência de usuário, vejamos os prós e contras desta abordagem:

👍 Vantagens:
- Diretório home persistente [todos os arquivos e pacotes serão persistidos]
- Tempo limite de inatividade (Cull Timeout) por notebook pode ser configurado
- Iniciar notebook com poucos cliques
- Iniciar notebook facilmente com GPUs

👎 Limitações:
- O ambiente Python não é persistente (todos os pacotes instalados desaparecem com o reinício do pod)
- Não há como instalar pacotes que exigem acesso root
- Não há uma maneira adequada de gerenciar múltiplos ambientes para experimentação
- Não é possível configurar um endpoint para o notebook [adicionado na próxima versão]

Agora, estas limitações são cruciais para resolver, pois bloqueiam muitos fluxos de trabalho de Cientistas de Dados, que podem ser tão simples quanto instalar 'apt-packages' como ffmpeg.

Resolvendo problemas críticos no fluxo de trabalho do usuário

Até este ponto, estávamos usando as imagens pré-construídas para Jupyterlab fornecidas pelo Kubeflow. Mas como precisamos resolver a questão dos ambientes não persistentes, permitir acesso root e instalar apt-packages, precisamos ter nosso próprio conjunto de imagens docker.
Então, vejamos como resolvemos esses problemas!

• Ambientes Não Persistentes: O objetivo era tornar o ambiente Python base persistente para que os usuários pudessem usar facilmente notebooks para seus casos de uso.

- Modificamos o script de inicialização da imagem docker e clonamos o ambiente conda base para o diretório home e o nomeamos jupyter-base
- Adicionamos um arquivo .condarc e definimos $HOME diretório como o caminho padrão do ambiente
- Modificamos o arquivo .bashrc para ativar o jupyter-base ambiente por padrão

• Instalar pacotes apt
  O usuário tem a opção de fornecer uma lista de pacotes apt que deseja pré-instalados com a imagem.
  Em seguida, adicionamos uma etapa de construção e criamos uma imagem personalizada que já vem com todos os pacotes mencionados pré-instalados no notebook!

• Fornecendo Acesso Root
  Em muitos casos, o usuário precisa de acesso root para instalar alguns pacotes e testar algumas coisas rapidamente. Para isso, criamos duas imagens para cada tipo de imagem.
  truefoundrycloud/jupyter:latest e truefoundrycloud/jupyter:latest-sudo. Onde as imagens com sudo fornecem acesso sudo sem senha ao usuário.
  Isso foi feito instalando o binário sudo e adicionando o usuário à lista de sudoers, conforme descrito neste link.

Nota: Como estamos executando notebooks no kubernetes com o diretório inicial montado, apenas o diretório inicial será persistente. As instalações de pacotes raiz não serão persistentes após reinícios de pod. Para um melhor entendimento, leia isto.

Ao resolver esses problemas, solucionamos a maioria das questões enfrentadas por um usuário e proporcionamos uma experiência decente com notebooks. Mas, com o tempo, percebemos que os usuários enfrentavam alguns desafios que descreveremos na próxima seção.

Problemas de usabilidade em notebooks

• Dificuldade em monitorar o uso de recursos (CPU e memória para um notebook): O kernel falha com muita frequência devido a problemas de falta de memória. Frequentemente nos deparamos com cenários em que estamos executando um notebook e o kernel falha por uma ou outra razão, o que pode ser difícil de depurar.

• A modificação do ambiente Python pode, por vezes, levar a um estado ruim onde o servidor de notebook não consegue reiniciar. Isso pode acontecer por várias razões, como alguém ir e desinstalar jupyterlab o pacote. Como o ambiente é persistente, o notebook não consegue iniciar (assim que o notebook atual é parado)
• Gerenciar múltiplos ambientes é possível. Mas o usuário precisa adicionar manualmente o ambiente conda a kernelspec e garantir que kernelspec esteja configurado corretamente, o que pode causar problemas.

Resolvendo os Problemas de Usabilidade

Adicionando métricas de uso de recursos ao notebook:
Adicionamos as métricas de uso de recursos ao notebook instalando a extensão jupyterlab-system-monitor==0.8.0 e configuramos suas definições no script de inicialização, passando argumentos ao iniciar o servidor Jupyterlab.

...


jupyter lab \
   ...
   --ResourceUseDisplay.mem_limit=${mem_limit} \
   --ResourceUseDisplay.cpu_limit=${cpu_limit} \
   --ResourceUseDisplay.track_cpu_percent=True \
   --ResourceUseDisplay.mem_warning_threshold=0.8


É assim que se parece na UI:

Separando o kernel que executa o servidor Jupyterlab do kernel de execução

Precisamos garantir que, quaisquer que sejam as alterações feitas pelo usuário no diretório inicial, o notebook sempre reinicie sem problemas. Para isso, usamos o ambiente anaconda 'base' de /opt/conda o diretório para iniciar o servidor Jupyterlab.
Além disso, criamos um ambiente separado no $HOME diretório, mas isso adiciona um kernel do base ambiente conda para listas de Kernels.

Para resolver isso, instalamos nb_conda_kernels para gerenciar kernels Jupyter. Configuramos o script de inicialização para garantir que apenas os ambientes Python persistentes apareçam na lista de kernels.

jupyter lab \
   ...
   --CondaKernelSpecManager.conda_only=True \
   --CondaKernelSpecManager.name_format={environment} \
   --CondaKernelSpecManager.env_filter=/opt/conda/*"


Com isso, garantimos que o servidor de notebooks sempre iniciará com quaisquer alterações que um usuário faça dentro do notebook.
Também facilita o gerenciamento de múltiplos kernels. Basta criar um novo ambiente conda usando o comando conda create -n myenv e ele começará a aparecer na lista de kernels.

Adicionando Suporte ao Code-Server

Embora os notebooks Jupyter resolvam vários problemas, há uma série de tarefas em que eles deixam de ser úteis:

1. Desenvolvimento de serviços como um aplicativo simples Gradio ou Streamlit. Os usuários podem escrever e executar o código no Jupyter Notebook, mas não conseguem visualizar o serviço no navegador.
2. Se um usuário estiver trabalhando em um projeto cujo código está empacotado em múltiplos arquivos, o ambiente Jupyterlab não é adequado para esse desenvolvimento.

Considerando essas limitações, decidimos resolver o problema. Adicionamos suporte ao code-server para oferecer uma experiência IDE completa aos usuários no navegador.

Ao adicionar suporte ao VS Code, permitimos que os usuários façam o seguinte:

1. Desenvolva e teste serviços no próprio navegador com o proxy de encaminhamento de porta do VS Code. Isso significa que seus serviços implantados  localhost:8000 podem ser disponibilizados em ${NOTEBOOK_URL}/proxy/8000
2. Gerencie facilmente o código com pacotes adequados, pois isso oferece uma experiência IDE completa.
3. Utilize todas as famosas extensões do VS Code para aumentar a produtividade.
4. Depure facilmente aplicativos executando-os em modo de depuração e aplicando pontos de interrupção.

Isso foi feito adicionando outra imagem Docker. Aqui está um diagrama que mostra as imagens Docker da Truefoundry.

Acesso SSH ao seu Notebook/VSCode:

Embora na maioria dos casos o VS Code Hospedado possa resolver o problema. Mas pode haver casos (especialmente para Jupyter Notebooks) em que o usuário fica preso e precisa de acesso direto ao contêiner que executa seu Jupyter Notebook / Servidor VS Code.
Então, simplificamos isso instalando um servidor SSH em cada um dos notebooks e para se conectar ao seu contêiner, você precisa executar um comando simples e inserir sua senha:

ssh -p 2222 jovyan@test-notebook.ctl.truefoundry.tech


O poder desta ferramenta pode ser aprimorado com sua Extensão do VS Code chamada Remote Explorer onde você pode abrir diretamente todos os arquivos dentro do seu VS Code!
Clique aqui para saber mais sobre isso

A Experiência Final do Usuário:

Com todos os recursos incluídos em nossa solução de notebook, veja como é o nosso formulário de implantação de notebook:

Comparação de Preços

Por fim, vamos comparar os preços de cada uma das soluções gerenciadas com a Truefoundry.

Como a Truefoundry funciona implantando na nuvem do cliente ao conectar seu Cluster Kubernetes, aqui está o preço da Truefoundry rodando em diferentes provedores de nuvem.

No caso da Truefoundry, você pode economizar muitos custos, pois:

• Não cobramos nenhum custo adicional sobre o custo das Máquinas Virtuais
• Suportamos a execução de notebooks em instâncias spot para cargas de trabalho que não são de produção, uma adição de 50-60% a mais em custos de nuvem.

Conclusão

Este foi um breve resumo sobre nosso esforço na construção da solução de notebooks. Você pode se juntar ao nosso Friends of Truefoundry canal do Slack se quiser discutir em profundidade nossa abordagem ou se tiver alguma sugestão.

Se você quiser experimentar nossa plataforma, pode se registrar aqui!