Como estender o Notebooks para o Dataproc e o Google Kubernetes Engine

Este documento ajuda administradores de sistema e engenheiros de dados a escolher a melhor abordagem para executar os notebooks do Jupyter no Google Cloud. Para usar este documento, é necessário ter familiaridade com os notebooks do Jupyter e o Dataproc Hub.

O documento faz parte de uma série que inclui:

Esta série é destinada principalmente a administradores que criam ambientes de notebook do Jupyter para pesquisas de ciência de dados.

Introdução

Empresas de todos os portes reúnem uma quantidade cada vez maior de dados. Interpretá-los requer recursos humanos e técnicos. Usuários finais, como cientistas de dados ou analistas de dados, geralmente interagem diretamente com esses dados por meio de ferramentas como editores de texto, ambientes de desenvolvimento integrados (IDEs, na sigla em inglês) ou ambientes de notebook. Administradores de sistema criam uma infraestrutura para ajudar esses usuários a realizar investigações.

Os usuários finais geralmente querem:

  • executar tarefas interativas em escala para facilitar o desenvolvimento e a depuração;
  • executar tarefas de dados e aprendizado de máquina no mesmo notebook;
  • ter acesso a ambientes que atendem às necessidades deles para melhorar a produtividade;
  • manter os notebooks separados da infraestrutura de processamento para que eles não percam trabalho;
  • iniciar rapidamente um ambiente que atenda aos requisitos de hardware e software.

Os administradores de sistema geralmente querem:

  • controlar ambientes de notebook de modo centralizado para facilitar o gerenciamento;
  • automatizar a implantação da plataforma que gerencia ciclos de vida de notebooks para minimizar a sobrecarga operacional;
  • fornecer aos usuários acesso limitado, mas suficiente, para que eles possam executar os jobs;
  • permitir que os usuários executem seus jobs de forma isolada para fornecer flexibilidade ao usuário final;
  • maximizar a utilização de recursos para minimizar custos e sobrecarga.

Neste documento, você terá uma visão geral das opções de notebook no Google Cloud. Os outros documentos desta série se concentram em como personalizar e implantar o JupyterHub no Google Cloud. O JupyterHub ajuda organizações a gerenciar ambientes de notebook do Jupyter em um contexto multiusuário.

Terminologia

Esta série usa os termos e produtos a seguir:

  • Produto: uma oferta oficial e reservada fornecida e aceita pelo Google Cloud.
  • Solução: arquitetura e software de código aberto que usa vários produtos do Google Cloud.
  • Administrador: uma pessoa que gerencia recursos que gerenciam notebooks.
  • Usuário final: uma pessoa que executa tarefas computacionais interativas usando notebooks. Para os fins desta série, os usuários finais são principalmente cientistas de dados.
  • Hub: uma IU para que os usuários finais personalizem e iniciem um novo servidor de notebook ou acessem a interface do Jupyter de um servidor de notebook atual.
  • Endpoint: um URL que um usuário final usa para acessar uma IU de notebook.
  • JupyterHub: um servidor multiusuário que exibe notebooks do Jupyter para vários usuários e gerencia a criação, o proxy e o ciclo de vida dos servidores de notebooks.
  • Perfil do servidor de notebook: uma configuração criada por um administrador que define a configuração de hardware e software para o ambiente de notebook.
  • Gerador: um processo responsável por iniciar um servidor de notebook de usuário único.

Como decidir qual produto usar para implantar plataformas baseadas em notebook

A árvore de decisão a seguir ajuda a determinar qual produto ou solução usar ao implantar sua plataforma de desenvolvimento baseada em notebook.

Árvore de decisão para ajudar a determinar qual produto ou solução usar ao implantar uma plataforma de desenvolvimento baseada em notebook.

A árvore ilustrada no diagrama mostra um conjunto de decisões que ajudam a determinar qual produto ou solução usar ao implantar uma plataforma de notebook no Google Cloud.

A primeira pergunta é se você precisa executar o SDK do Apache Spark em um ambiente distribuído. As demais decisões dependem da resposta para essa pergunta.

Não, você não precisa executar o Apache Spark em um ambiente distribuído

Nesse caso, você precisa usar o SDK do Apache Beam em uma única instância e executar o código no Dataflow?

  • Se você precisar usar o SDK do Beam, use o Notebooks que usa o Direct Runner do Apache Beam para fornecer um ambiente de pesquisa interativo em uma única máquina. Para saber mais detalhes, consulte a documentação do Apache Beam no Notebooks.
  • Se não precisa usar o SDK do Beam, você precisa gerenciar os perfis de processamento de maneira centralizada?
    • Em caso afirmativo, use o GKE Hub Extended.
    • Em caso negativo, você precisa consolidar os custos? Em caso afirmativo, use o GKE Hub Extended. Em caso negativo, use o Notebooks.

Sim, você precisa usar o Apache Spark em um ambiente distribuído

Nesse caso, você precisa gerenciar de maneira centralizada os perfis de cluster do Dataproc?

  • Se precisa gerenciar de maneira centralizada os perfis de cluster, você precisa de personalização avançada do Dataproc Hub? Em caso afirmativo, use o Dataproc Hub Extended. Em caso negativo, use o Dataproc Hub.
  • Se você não precisa gerenciar de maneira centralizada os perfis de cluster, use o Dataproc Notebooks.

Como escolher uma infraestrutura

Por padrão, é possível executar servidores de notebooks do Jupyter nos produtos do Google Cloud a seguir:

  • Dataproc: os usuários executam servidores de notebook por meio do componente Jupyter em um cluster do Dataproc com o Spark ativado. Essa opção é útil se você precisa usar o Spark em um ambiente distribuído.
  • Notebooks: os usuários executam servidores de notebook em uma única instância do Compute Engine. Essa opção é útil se o trabalho puder ser executado em uma única instância.

Se seu framework de processamento não usa o Spark em um ambiente distribuído, primeiro você precisa explorar o Notebooks. Se o Notebooks não atender aos seus requisitos, considere as opções do Google Kubernetes Engine (GKE).

Quando você sabe se precisa do Dataproc, a próxima etapa é decidir quanta flexibilidade os usuários finais terão.

Como escolher um hub

Um hub geralmente permite que os administradores definam a aparência dos ambientes de notebook e que os usuários finais gerenciem o ciclo de vida do ambiente de notebook. O Google Cloud usa o Console do Cloud como um hub padrão. Ainda que o Console do Cloud ofereça flexibilidade aos usuários finais, algumas empresas precisam de mais opções administrativas para gerenciar de maneira centralizada os perfis de notebook. Os motivos incluem:

  • minimizar custos e maximizar o uso de recursos reunindo ambientes de notebook a um número limitado de máquinas;
  • garantir a segurança fornecendo ambientes em sandbox para usuários finais;
  • minimizar tarefas repetitivas predefinindo ambientes de notebook que os usuários finais podem começar a usar com apenas alguns cliques;
  • estabelecer a consistência em toda a organização usando modelos para ambientes de notebook.

Se você não quiser que os usuários finais trabalhem no Console do Cloud por um desses motivos, escolha uma das opções a seguir:

  • Se você usa o Dataproc, pode utilizar o Dataproc Hub, um produto que hospeda o JupyterHub em uma instância de Notebooks e que gera ambientes de notebook no Dataproc. Como o Dataproc Hub é baseado em tecnologia de código aberto, é possível personalizá-lo.
  • Se você não usa o Dataproc, o Google Cloud não fornece uma maneira gerenciada de executar o JupyterHub para cargas de trabalho que não são baseadas no Dataproc. No entanto, para esse cenário, é possível usar o GKE Hub Extended, uma solução leve executada no GKE.

Leia mais sobre cada uma dessas opções nas seções a seguir deste documento:

Dataproc Hub Extended

Se sua empresa está no Google Cloud e usa o Spark, é possível usar o Dataproc para processar dados em escala e executar treinamento e inferência. Com o Dataproc Hub, é possível gerenciar e padronizar de maneira centralizada as configurações de cluster, oferecendo aos usuários finais o ambiente de que precisam. Para fazer isso, use configurações de cluster, que são arquivos YAML declarativos que definem:

  • perfis de hardware para clusters do Dataproc;
  • perfis de software para o ambiente de notebook.

Por exemplo, é possível usar o Dataproc Hub no cenário a seguir:

  1. Um usuário final cria o próprio ambiente de notebook com base em uma lista de configurações selecionadas pelo administrador.
  2. Quando um ambiente está sendo executado pelo notebook, o usuário final explora de maneira interativa os dados em escala com o PySpark. Os usuários também podem executar tarefas de ML com o TensorFlow ou o PyTorch.

Por padrão, a arquitetura do Dataproc Hub é semelhante a esta:

Arquitetura do Dataproc Hub.

O Dataproc Hub usa os produtos do Google Cloud e o software de código aberto a seguir:

  • O Dataproc hospeda o servidor de notebook.
  • O Notebooks fornece uma instância do Compute Engine para executar o JupyterHub e ajudar a fornecer acesso seguro e identificado à IU usando o Inverting Proxy.
  • O servidor Inverting Proxy (em inglês) é uma ferramenta de código aberto que recebe e encaminha solicitações recebidas para o back-end apropriado. O Dataproc Hub usa uma versão gerenciada pelo Google do servidor Inverting Proxy.
  • O agente Inverting Proxy (em inglês) é uma ferramenta de código aberto que é executada além do JupyterHub em uma instância do Compute Engine e corresponde a solicitações e respostas entre o back-end e o cliente.
  • O autenticador do JupyterHub para proxies do Google Cloud (gcp-proxies-authenticator) fornece identificação transparente de usuário usando cabeçalhos fornecidos pelo Inverting Proxy. O código está disponível no repositório do autenticador do JupyterHub para proxies do Google Cloud (em inglês) no GitHub.
  • O JupyterHub está instalado em uma instância do Notebooks do Compute Engine para aproveitar o serviço do agente do Inverting Proxy.
  • O Dataproc Spawner oferece um formulário ao usuário final para que possa criar servidores de notebook no Dataproc em uma zona selecionada. O código está disponível no repositório do autenticador do JupyterHub para proxies do Google Cloud (em inglês) no GitHub.

Em alguns casos, talvez seja necessário estender a versão base do Dataproc Hub para modificar a arquitetura geral ou adaptar um código às necessidades. Como o Dataproc Hub é baseado em software de código aberto, é possível ampliar os recursos do produto. Por exemplo, é possível realizar estas ações:

GKE Hub Extended

O GKE Hub Extended ajuda a consolidar os custos ao centralizar a infraestrutura de computação. A arquitetura a seguir mostra como os usuários finais podem criar os próprios ambientes de sandbox em uma infraestrutura do GKE.

Arquitetura de como os usuários finais podem criar os próprios ambientes de sandbox em uma infraestrutura do GKE.

Nesta arquitetura, os administradores usam perfis de servidor de notebook para fornecer uma lista de ambientes permitidos a uma equipe de usuários finais. Perfis são objetos JSON declarativos que definem:

  • perfis de hardware para os pods;
  • perfis de software para o ambiente de notebook.

No diagrama, os modelos de perfil estão ao lado do administrador de TI como imagens personalizadas. Quando um usuário final escolhe uma imagem, um servidor de notebook é iniciado em um nó do GKE. No diagrama, esses servidores são representados pelas caixas user-*.

Conforme mostrado no diagrama, o GKE Hub Extended é uma solução leve que usa os produtos do Google Cloud e software de código aberto a seguir:

  • O servidor Inverting Proxy é uma ferramenta de código aberto que recebe e encaminha solicitações recebidas para o back-end apropriado. O GKE Hub usa uma versão gerenciada pelo Google do servidor Inverting Proxy.
  • O agente Inverting Proxy é uma ferramenta de código aberto executada no GKE como a própria implantação e que corresponde a solicitações e respostas entre o back-end e o cliente. Há um agente que é executado além da implantação do JupyterHub para ajudar a fornecer acesso seguro à IU do JupyterHub. A tarefa de roteamento de usuários para servidores de notebook é processada pelo JupyterHub. Para mais informações, consulte o arquivo README no repositório Inverting Proxy (em inglês) no GitHub.
  • O autenticador do JupyterHub para proxies do Google Cloud (gcp-proxies-authenticator) fornece identificação transparente de usuário por meio de cabeçalhos fornecidos pelo Inverting Proxy. O código está disponível no repositório do autenticador do JupyterHub para proxies do Google Cloud (em inglês) no GitHub.
  • O KubeSpawner fornece um formulário para que os usuários finais possam criar servidores de notebook no mesmo cluster do Kubernetes que hospeda o JupyterHub. O KubeSpawner também permite que os administradores gerenciem perfis de servidor de notebook por meio de um parâmetro profile_list. O código está disponível no repositório JupyterHub Kubernetes Spawner (em inglês) no GitHub.

A pasta do GKE Hub no repositório serve como exemplo para mostrar como configurar o ambiente descrito nesta seção. É possível bifurcar o repositório pai e estender o código para o GKE Hub.

Considerações comuns para a escolha de um notebook

As considerações a seguir são importantes quando você decide como configurar uma infraestrutura de notebook para experimentos:

  • Acesso a interfaces: como os usuários finais acessam a IU do produto, incluindo autenticação e acesso à rede. Essa decisão afeta a segurança.
  • Relação entre usuários e servidores de notebook: se um usuário poderá usar vários servidores de notebook por vez ou se será limitado a um só servidor de notebook. Essa decisão costuma afetar a produtividade e os custos.
  • Framework de processamento: se você tem requisitos legados ou requisitos de tecnologia específicos para computação. O Spark é um exemplo de requisito de tecnologia. Essa decisão costuma afetar a produtividade.
  • Infraestrutura subjacente: qual produto de infraestrutura do Google Cloud será usado e se os usuários compartilharão a infraestrutura. Essa decisão impacta a escalonabilidade e os custos.

O restante deste documento analisa opções que abordam cada uma dessas considerações.

Acesso à interface da Web

Os usuários finais acessam notebooks e interfaces da Web relacionadas por meio de um URL de endpoint. Os endpoints têm características diferentes:

  • Conectividade: se o endpoint é exposto de forma privada (por exemplo, por meio de notebooks.corp.example.com) ou publicamente (por meio de notebooks.example.com).
  • Segurança de rede: se um recurso em uma rede específica pode acessar o endpoint.
  • Autenticação: como o sistema verifica a identidade dos usuários quando eles acessam o endpoint.
  • Domínio: se o endpoint pode ser acessado por meio de um domínio personalizado ou de um domínio fornecido pelo Google. Você gerencia domínios personalizados por meio do Cloud DNS ou de uma solução semelhante.
  • Hub: qual tecnologia pode rotear os usuários para o servidor de notebook deles.

A maioria dessas considerações depende de uma combinação de qual plataforma de notebook você usa e qual proxy está anexado a ela. Nas arquiteturas descritas nesta série, é possível escolher entre os proxies a seguir:

  • IAP: um produto que gerencia o acesso a aplicativos da Web, como o JupyterHub em execução no Compute Engine ou no GKE.
  • Inverting Proxy: uma solução de código aberto que inclui um servidor proxy reverso e um agente. Esta série usa um servidor gerenciado pelo Google.
  • Gateway de componentes: um produto gerenciado pelo Dataproc que combina o Inverting Proxy e o Apache Knox, um gateway de API, para ajudar a fornecer acesso seguro aos endpoints da Web do Dataproc.

Para simplificar o gerenciamento de domínio, o Google Cloud usa principalmente o Inverting Proxy para produtos como notebooks do Jupyter que precisam externalizar uma IU da Web. O Inverting Proxy usa um domínio gerenciado pelo Google.

A tabela a seguir lista as características da lista anterior para cada produto ou solução de notebook do Google Cloud.

Plataforma Proxy Autenticação Domínio Hub
Dataproc Jupyter Gateway de componentes Gerenciado pelo Google Fornecido por proxy Cloud Console
Dataproc Hub Inverting Proxy gcp-proxies-authenticator Fornecido por proxy Baseado no JupyterHub
Dataproc Hub Extended Inverting Proxy gcp-proxies-authenticator Fornecido por proxy Baseado no JupyterHub
Notebooks Inverting Proxy (em inglês) Gerenciado pelo Google Fornecido por proxy Cloud Console
GKE Hub Extended Inverting Proxy gcp-proxies-authenticator Fornecido por proxy Baseado no JupyterHub

O Dataproc Hub Extended e o GKE Hub Extended também podem usar o IAP e um domínio personalizado. O repositório ai-notebook-extended do GitHub (em inglês) oferece um exemplo de como fazer isso para o Dataproc Hub Extended em grupos gerenciados de instâncias.

Relação entre usuários e servidores de notebook

Dependendo do produto que você usa, a relação entre os notebooks e os usuários pode variar, conforme mostrado na tabela a seguir.

Ferramenta Relação usuário:notebook
Dataproc Jupyter N:N
Dataproc Hub 1:1
Dataproc Hub Extended 1:1 (é possível personalizar o código do gerador para 1:N)
Notebooks N:N
GKE Hub 1:N (é possível configurar o gerador para 1:1)

As implicações das relações na tabela anterior são estas:

  • Se você usar o Dataproc Jupyter, qualquer usuário final com acesso a um URL do gateway de componentes poderá acessar o notebook anexado a esse URL.
  • Se você usar o Dataproc Hub, um usuário final com acesso a um URL do Inverting Proxy poderá acessar o hub anexado a esse URL. Mas o usuário não pode acessar os servidores de notebook de outros usuários. Por padrão, um usuário só pode iniciar um servidor de notebook de usuário único por vez.
  • Se você usar o Dataproc Hub Extended, um usuário final com acesso a um URL do Inverting Proxy poderá acessar o hub anexado a esse URL. Mas o usuário não pode acessar os servidores de notebook de outros usuários. Por padrão, um usuário só pode iniciar um servidor de notebook de usuário único por vez, mas é possível personalizar o código do gerador para alterar esse comportamento.
  • Se você usar o Notebooks, qualquer usuário final com acesso autenticado a um URL do Inverting Proxy poderá acessar o notebook anexado a esse URL.
  • Se você usar a solução GKE Hub, os usuários finais com acesso a um URL do Inverting Proxy poderão acessar o hub anexado a esse URL. Mas os usuários podem ver apenas os próprios servidores de notebook. Por padrão, se você ativar a opção relevante, os usuários poderão executar vários servidores de notebook de usuário único por vez.

É necessário estar ciente das informações a seguir:

  • Para acessar a IU atrás de um URL do Inverting Proxy, o usuário precisa ter o papel serviceAccountUser para a conta de serviço da instância que hospeda o agente.
  • Para acessar um aplicativo protegido pelo IAP, o usuário precisa ter as permissões adequadas no nível do IAP.

Resumo

O Google Cloud oferece várias opções para executar notebooks. Esta série de documentos ajuda você a tomar a decisão certa. Siga estas diretrizes:

  1. Se você não precisar gerenciar de maneira centralizada perfis de servidor de notebook e se os usuários finais puderem trabalhar em uma única instância, use o Notebooks e o Inverting Proxy.
  2. Se você não precisar gerenciar de maneira centralizada perfis de servidor de notebook e se os usuários finais precisarem do Apache Spark em um ambiente distribuído, use o Dataproc Notebooks por meio do componente Dataproc Jupyter e do gateway de componentes.
  3. Se você precisar gerenciar de maneira centralizada perfis de servidor de notebook e se os usuários finais precisarem do Spark em um ambiente distribuído, use o Dataproc Hub e o Inverting Proxy.
  4. Caso precise personalizar o Dataproc Hub, use a respectiva solução no GitHub como base.
  5. Se você precisar gerenciar de maneira centralizada ambientes de usuário e quiser usar o Kubernetes, crie com base na solução de exemplo do GKE Hub. Para informações sobre como configurar o GKE Hub com o Inverting Proxy, consulte Tutorial: como gerar servidores de notebook no Google Kubernetes Engine (GKE) nesta série.

Uma das principais vantagens de usar o Dataproc Hub Extended e o GKE Hub Extended é a possibilidade de personalizá-los totalmente. Por exemplo, é possível executar um hub no GKE e gerar notebooks onde necessário, seja no Dataproc ou no GKE. Se você precisar de ajuda com personalizações que não estão no repositório do GitHub, entre em contato com a equipe local do Google Cloud para saber como podem ajudar.

A seguir