Esta página faz parte de uma série que aborda a hospedagem do Looker, as metodologias de implantação e as práticas recomendadas para os componentes envolvidos. Esta página explora os padrões de arquitetura mais comuns para uma implantação hospedada pelo cliente e descreve as práticas recomendadas para implementá-los. Para usar esta página de forma eficaz, você deve estar familiarizado com os conceitos e práticas de arquitetura do sistema.
Esta série consiste em três partes:
- Visão geral da infraestrutura hospedada pelo cliente
- Padrões de arquitetura de infraestrutura hospedados pelo cliente (esta página)
- Tutoriais de componentes de infraestrutura hospedados pelo cliente
Estratégia de fluxo de trabalho
Depois de identificar a auto-hospedagem como uma opção viável para sua implementação do Looker, a próxima etapa é elaborar a estratégia a ser disponibilizada pela implantação.
- Faça uma avaliação. Identifique uma lista de possíveis fluxos de trabalho planejados e existentes.
- Listar padrões de arquitetura aplicáveis. Começando com os fluxos de trabalho candidatos identificados, identifique os padrões de arquitetura aplicáveis.
- Priorize e selecione o padrão de arquitetura ideal. Alinhe o padrão da arquitetura com as tarefas e os resultados mais importantes.
- Configure os componentes da arquitetura e implante o aplicativo Looker. Implemente o host, as dependências de terceiros e a topologia de rede necessários para estabelecer conexões de cliente seguras.
Opções de arquitetura
Máquina virtual dedicada
Uma opção é executar o Looker como uma instância única em uma máquina virtual (VM) dedicada. Uma única instância pode atender cargas de trabalho exigentes ao escalonar verticalmente o host e aumentar os pools de linhas de execução padrão. No entanto, a sobrecarga de processamento do gerenciamento de uma grande pilha Java está sujeita ao dimensionamento vertical à lei da diminuição dos retornos. Geralmente é aceitável para cargas de trabalho pequenas e médias. O diagrama a seguir mostra as configurações padrão e opcionais entre uma instância do Looker em execução em uma VM dedicada, os repositórios locais e remotos, os servidores SMTP e as fontes de dados destacadas nas seções Vantagens e Práticas recomendadas dessa opção.
Vantagens
- Uma VM dedicada é fácil de implantar e manter.
- O banco de dados interno está hospedado no aplicativo Looker.
- Os modelos do Looker, o repositório Git, o servidor SMTP e os componentes do banco de dados de back-end podem ser configurados no local ou remotamente.
- Você pode substituir o servidor SMTP padrão do Looker pelo seu próprio para notificações por e-mail e tarefas programadas.
Práticas recomendadas
- Por padrão, o Looker pode gerar repositórios Git vazios para um projeto. Recomendamos que um repositório Git remoto seja configurado para redundância.
-
Por padrão, o Looker começa com um banco de dados HyperSQL na memória. Esse banco de dados é prático e leve, mas pode apresentar problemas de desempenho se o uso for intenso. Recomendamos o uso de um banco de dados MySQL para implantações maiores. Recomendamos a migração para um banco de dados MySQL remoto quando o arquivo
~/looker/.db/looker.scriptatingir 600 MB. - Sua implantação do Looker precisará ser validada de acordo com o serviço de licenciamento do Looker. O tráfego de saída na porta 443 é obrigatório.
- Uma implantação de VM dedicada pode ser escalonada verticalmente aumentando os recursos disponíveis e os pools de linhas de execução do Looker. No entanto, o aumento da RAM está sujeito à lei da redução de retornos quando atinge 64 GB, já que os eventos de coleta de lixo têm uma única linha de execução e interrompem a execução de todas as outras. Nós com 16 CPUs e 64 GB de RAM são um bom equilíbrio entre preço e desempenho.
- Recomendamos que sua implantação tenha armazenamento com duas operações por segundo (IOPS) por GB.
Cluster de VMs
Executar o Looker como um cluster de instâncias em várias VMs é um padrão flexível que se beneficia do failover e da redundância do serviço. A escalonabilidade horizontal proporciona maior capacidade de processamento sem gerar sobrecarga de heap e custos excessivos de coleta de lixo. Os nós têm a opção de dedicação de carga de trabalho, o que permite que várias opções de implantação sejam adaptadas a diferentes requisitos de negócios. As implantações de cluster exigem pelo menos um administrador de sistema familiarizado com os sistemas Linux e capaz de gerenciar as partes dos componentes.
Cluster padrão
Para a maioria das implantações padrão, um cluster de nós de serviço idênticos é suficiente. Todos os nós no cluster são configurados da mesma maneira e estão todos no mesmo pool do balanceador de carga. Nenhum dos nós nessa configuração teria mais ou menos chances de atender a solicitações de usuários do Looker, tarefas de renderização, tarefas programadas, solicitações de API etc.
Esse tipo de configuração é adequado quando a maioria das solicitações vem diretamente de um usuário do Looker que está executando consultas e interagindo com o Looker. Ele começa a ser detalhado quando um grande número de solicitações vem de um programador, renderizador ou outra origem. Nesse caso, é vantajoso designar determinados nós de serviço para lidar com tarefas como programações e renderização.
Por exemplo, os usuários geralmente programam os relatórios para serem gerados na segunda-feira de manhã. Um usuário que tenta executar consultas do Looker na segunda-feira de manhã pode ter problemas de desempenho enquanto o Looker trabalha no backlog das solicitações programadas. Ao aumentar o número de nós de serviço, o cluster proporciona um aumento proporcional da capacidade em todos os recursos do Looker.
O diagrama a seguir mostra como as solicitações ao Looker feitas pelo usuário, apps e scripts são equilibradas em uma instância em cluster do Looker.
Vantagens
- O cluster padrão maximiza o desempenho geral com a configuração mínima da topologia do cluster.
- A VM Java sofre degradação de desempenho no limite de memória alocada de 64 GB. É por isso que o escalonamento horizontal tem retornos maiores do que o escalonamento vertical.
- A configuração de um cluster garante redundância e failover de serviços.
Práticas recomendadas
- Cada nó do Looker precisa ser hospedado em uma VM dedicada própria.
- O balanceador de carga, que é o ponto de entrada do cluster, precisa ser da camada 4. Ele precisa ter um tempo limite longo (3.600 segundos), ser equipado com um certificado SSL assinado e ser configurado para fazer o encaminhamento de portas de 443 (https) a 9999 (porta que o servidor do Looker detecta).
- Recomendamos que sua implantação tenha armazenamento com 2 IOPS por GB.
Desenvolvimento/fase/produção
Para casos de uso que priorizam o tempo de atividade máximo de conteúdo para os usuários finais, recomendamos ambientes separados do Looker para compartimentalizar o trabalho de desenvolvimento e o trabalho analítico. Ao bloquear mudanças no ambiente de produção por trás de ambientes isolados de desenvolvimento e teste, essa arquitetura mantém um ambiente de produção o mais estável possível.
Esses benefícios exigem a configuração dos ambientes interconectados e a adoção de um ciclo de lançamento robusto. Uma implantação de Desenvolvimento/Preparação/Produção também requer uma equipe de desenvolvedores que conheça a API Looker e o Git para administrar o fluxo de trabalho.
O diagrama a seguir mostra o fluxo de conteúdo entre desenvolvedores do LookML que desenvolvem conteúdo na instância de desenvolvimento, testadores de controle de qualidade (QA) que testam o conteúdo na instância de controle de qualidade e usuários, aplicativos e scripts que consomem o conteúdo na instância de Production.
Vantagens
- O LookML e a validação de conteúdo ocorrem em um ambiente que não é de produção, o que garante que as modificações na lógica do modelo possam ser cuidadosamente verificadas antes de chegar aos usuários em produção.
- Os recursos de toda a instância, como recursos de laboratórios ou protocolos de autenticação, podem ser testados de forma isolada antes de serem ativados no ambiente de produção.
- É possível testar as políticas de armazenamento em cache e de datagroup em um ambiente que não seja de produção.
- O teste do modo de produção do Looker é separado dos ambientes de produção responsáveis por atender os usuários finais.
- As versões do Looker podem ser testadas em um ambiente que não seja de produção, o que dá tempo suficiente para testar novos recursos, mudanças no fluxo de trabalho e problemas antes de atualizar o ambiente de produção.
Práticas recomendadas
- Isole as várias atividades que ocorrem simultaneamente em pelo menos três instâncias separadas:
- Instância de desenvolvimento: os desenvolvedores usam o ambiente de desenvolvimento para confirmar código, realizar experimentos, corrigir bugs e cometer erros com segurança.
- Instância de controle de qualidade: também conhecido como ambiente de teste ou preparação, é onde os desenvolvedores executam testes manuais e automatizados. O ambiente de controle de qualidade é complexo e pode consumir muitos recursos.
- Instância Production: é onde o valor é criado para os clientes e/ou a empresa. O ambiente de Production é altamente visível e não deve ter erros.
- Manter um fluxo de trabalho do ciclo de lançamento documentado e repetível.
- Se for necessário atender a um grande volume de desenvolvedores e testadores de controle de qualidade, as instâncias de desenvolvimento e/ou controle de qualidade podem ser agrupadas. Seja como uma VM independente ou um cluster de VMs, as instâncias de desenvolvimento e controle de qualidade estão sujeitas às mesmas considerações de arquitetura mostradas nas seções acima.
Alta capacidade de programação
Para casos de uso que exigem alta capacidade de processamento de relatórios programados e entregas confiáveis e oportunas, recomendamos que a configuração inclua um cluster com um pool de nós exclusivamente dedicado à programação. Essa configuração ajuda a manter a rapidez e a resposta da Web e dos aplicativos incorporados. Esses benefícios exigem a configuração de nós com opções de inicialização personalizadas e regras de balanceamento de carga adequadas, conforme mostrado no diagrama abaixo e descrito nas seções Vantagens e Práticas recomendadas dessa opção.
Vantagens
- A alocação de nós para uma função específica compartimentaliza recursos para a programação de funções de desenvolvimento e análise ad-hoc.
- Os usuários podem desenvolver o LookML e explorar o conteúdo sem tomar ciclos de nós responsáveis por atender aos envios programados de relatórios.
- O alto tráfego de usuários afunilado para os nós normais não impede cargas de trabalho programadas atendidas por nós de programação.
Práticas recomendadas
- Cada nó do Looker precisa ser hospedado em uma VM dedicada própria.
- O balanceador de carga, que é o ponto de entrada do cluster, precisa ser da camada 4. Ele precisa ter um tempo limite longo (3.600 segundos), ser equipado com um certificado SSL assinado e ser configurado para fazer o encaminhamento de portas de 443 (https) a 9999 (porta que o servidor do Looker detecta).
- Omita os nós do programador das regras de balanceamento de carga para que não atendam ao tráfego do usuário final e às solicitações internas da API.
- Recomendamos que sua implantação tenha armazenamento com 2 IOPS por GB.
Alta capacidade de renderização
Para casos de uso que exigem alta capacidade de processamento de relatórios de renderização, recomendamos configurar um cluster com um pool de nós dedicados exclusivamente à renderização. Renderizar um arquivo PDF ou uma imagem PNG/JPEG é uma operação relativamente cara de recursos no Looker. A renderização pode consumir muita memória e CPU, e quando o Linux está sob pressão da memória, ele pode encerrar um processo em execução. Como o uso da memória de um job de renderização não pode ser determinado antecipadamente, iniciar um job de renderização pode resultar no encerramento do processo do Looker. A configuração de nós de renderização dedicados permite o ajuste ideal dos jobs de renderização, preservando a capacidade de resposta do aplicativo interativo e incorporado.
Esses benefícios exigem a configuração de nós com opções de inicialização personalizadas e regras de balanceamento de carga adequadas, conforme mostrado no diagrama abaixo e explicado nas seções Vantagens e Práticas recomendadas dessa opção. Além disso, os nós de renderização podem exigir mais recursos de host do que os nós padrão, já que o serviço de renderização do Looker depende dos processos de terceiros do Chromium que compartilham o tempo de CPU e a memória.
Vantagens
- A alocação de nós para uma função específica compartimentaliza recursos para renderização de funções de desenvolvimento e análises ad-hoc.
- Os usuários podem desenvolver o LookML e explorar o conteúdo sem ciclos dos nós responsáveis pela renderização de PNGs e PDFs.
- O alto tráfego de usuários direcionado para os nós normais não impede a renderização das cargas de trabalho atendidas pelos nós de renderização.
Práticas recomendadas
- Cada nó do Looker precisa ser hospedado em uma VM dedicada própria.
- O balanceador de carga, que é o ponto de entrada do cluster, precisa ser da camada 4. Ele precisa ter um tempo limite longo (3.600 segundos), ser equipado com um certificado SSL assinado e ser configurado para fazer o encaminhamento de portas de 443 (https) a 9999 (porta que o servidor do Looker detecta).
- Omita os nós de renderização das regras de balanceamento de carga para que eles não atendam ao tráfego do usuário final e às solicitações internas da API.
- Aloque relativamente menos memória para Java nos nós de renderização para fornecer aos processos do Chromium um buffer de memória maior. Em vez de alocar 60% da memória para Java, aloque de 40% a 50%.
- O risco de pressão sobre a memória foi reduzido nos nós não renderização, portanto, a quantidade de memória dedicada ao Looker pode ser aumentada. Em vez do padrão de 60%, considere um número maior, como 80%.
- Recomendamos que sua implantação tenha armazenamento com 2 IOPS por GB.