Esta página faz parte de uma série de várias partes que discute a hospedagem do Looker, metodologias de implantação e 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 maneira eficaz, você precisa conhecer os conceitos e as práticas da arquitetura do sistema.
Esta série tem três partes:
- Visão geral da infraestrutura hospedada pelo cliente
- Padrões de arquitetura de infraestrutura hospedada pelo cliente (esta página)
- Tutoriais sobre o componente de infraestrutura hospedado 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 atendida pela implantação.
- Faça uma avaliação. Identifique uma lista candidata de 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 de arquitetura com as tarefas e os resultados mais importantes.
- Configurar os componentes da arquitetura e implantar o aplicativo Looker. Implemente o host, as dependências de terceiros e a topologia de rede necessários para estabelecer conexões seguras com o cliente.
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 a cargas de trabalho exigentes escalonando verticalmente o host e aumentando os pools de linhas de execução padrão. No entanto, a sobrecarga de processamento do gerenciamento de um grande heap Java sujeita o escalonamento vertical à lei da redução de retornos. Geralmente, ele é aceitável para cargas de trabalho pequenas a 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
- É fácil implantar e manter uma VM dedicada.
- 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 de forma local ou remota.
- Você pode substituir o servidor SMTP padrão do Looker pelo seu para notificações por e-mail e tarefas programadas.
Práticas recomendadas
- Por padrão, o Looker pode gerar repositórios Git nus 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 é conveniente e leve, mas pode apresentar problemas de desempenho com uso 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 vai precisar ser validada em relação ao 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 com o aumento dos recursos disponíveis e dos 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 linha de execução única e interrompem a execução de todas as outras. Nós com 16 CPUs e 64 GB de RAM oferecem um bom equilíbrio entre preço e desempenho.
- Recomendamos que sua implantação tenha armazenamento com duas operações por segundo (IOPS, na sigla em inglês) 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 de serviço e da redundância. A escalonabilidade horizontal proporciona maior capacidade de processamento sem sobrecarga da pilha e custos excessivos de coleta de lixo. Os nós têm a opção de dedicação da carga de trabalho, o que permite que várias opções de implantação sejam adaptadas para diferentes requisitos de negócios. 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 de balanceadores de carga. Nenhum dos nós nessa configuração teria maior ou menor probabilidade de atender a solicitações de usuários do Looker, uma tarefa de renderização, uma tarefa programada, uma solicitação 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 dividido 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 a geração dos relatórios para segunda-feira de manhã. Um usuário que tenta executar consultas no 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 na capacidade de processamento de todos os recursos do Looker.
O diagrama a seguir mostra como as solicitações feitas ao Looker feitas pelo usuário, apps e scripts são balanceadas em uma instância em cluster do Looker.
Vantagens
- Um cluster padrão maximiza os aspectos gerais com 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 failover e redundância de serviço.
Práticas recomendadas
- Cada nó do Looker deve ser hospedado em uma VM dedicada.
- O balanceador de carga, que é o ponto de entrada do cluster, precisa ser um balanceador de carga da camada 4. Ele precisa ter um tempo limite longo (3.600 segundos), estar equipado com um certificado SSL assinado e configurado para encaminhar de 443 (https) para 9999 (o servidor de porta do Looker detecta).
- Recomendamos que sua implantação tenha armazenamento com 2 IOPS por GB.
Desenvolvimento/Preparação/Prod
Para casos de uso que priorizam o tempo de atividade máximo do conteúdo para os usuários finais, recomendamos ambientes separados do Looker para compartimentar o trabalho de desenvolvimento e analítico. Ao bloquear as mudanças do ambiente de produção por meio 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 de ambientes interconectados e a adoção de um ciclo de lançamento robusto. Uma implantação de Dev/Staging/Prod também requer uma equipe de desenvolvedores familiarizados com a API Looker e o Git para administrar o fluxo de trabalho.
O diagrama a seguir mostra o fluxo de conteúdo entre os desenvolvedores do LookML que desenvolvem o conteúdo na instância de desenvolvimento, os testadores de controle de qualidade (QA) que testam o conteúdo na instância de controle de qualidade e os usuários, aplicativos e scripts que consomem o conteúdo na instância Production.
Vantagens
- O LookML e a validação de conteúdo ocorrem em um ambiente de não produção, garantindo que qualquer modificação na lógica do modelo possa ser cuidadosamente examinada antes de chegar aos usuários de produção.
- Os recursos da instância, como recursos do Labs ou protocolos de autenticação, podem ser testados em isolamento antes de serem ativados no ambiente de produção.
- As políticas de grupo de dados e armazenamento em cache podem ser testadas em um ambiente de não 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, com 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 o 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 teste, é 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. Production é um ambiente altamente visível e não deve conter erros.
- Mantenha um fluxo de trabalho com um ciclo de lançamento documentado e repetível.
- Se for necessário atender a grandes volumes de desenvolvedores e testadores de controle de qualidade, as instâncias de desenvolvimento e/ou controle de qualidade podem ser agrupadas. Seja deixada como uma VM independente ou em um cluster de VMs, as instâncias de desenvolvimento e controle de qualidade estão sujeitas às mesmas considerações arquitetônicas apresentadas nas respectivas seções.
Alta capacidade de programação
Para casos de uso que exigem alta capacidade de processamento programada de relatórios e entregas confiáveis e oportunas, recomendamos que a configuração inclua um cluster com um pool de nós dedicados exclusivamente à programação. Essa configuração ajuda a manter a Web e os aplicativos incorporados rápidos e responsivos. 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
- Dedicar nós para uma função específica compartimental os recursos para programação de funções de desenvolvimento e análises ad hoc.
- Os usuários podem desenvolver o LookML e explorar o conteúdo sem usar ciclos de nós responsáveis por atender a entregas programadas de relatórios.
- O alto tráfego de usuários direcionado para os nós regulares não impede as cargas de trabalho programadas que atendem à programação dos nós.
Práticas recomendadas
- Cada nó do Looker deve ser hospedado em uma VM dedicada.
- O balanceador de carga, que é o ponto de entrada do cluster, precisa ser um balanceador de carga da camada 4. Ele precisa ter um tempo limite longo (3.600 segundos), estar equipado com um certificado SSL assinado e configurado para encaminhar de 443 (https) para 9999 (o servidor de porta do Looker detecta).
- Omita os nós do programador das regras de balanceamento de carga para que eles não atendam ao tráfego do usuário final e às solicitações de API internas.
- 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 com recursos relativamente caros no Looker. A renderização pode consumir muita memória e CPU intensa. Quando o Linux está sob pressão de memória, isso pode acabar com um processo em execução. Como o uso da memória de um job de renderização não pode ser determinado com antecedência, iniciar um job de renderização pode resultar na eliminação do processo do Looker. Configurar nós de renderização dedicados permite o ajuste ideal dos jobs de renderização e, ao mesmo tempo, preserva 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 de processos de terceiros do Chromium que compartilhem o tempo de CPU e a memória.
Vantagens
- A dedicação de nós para uma função específica compartimental os 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 usar os nós responsáveis pela renderização de PNGs e PDFs.
- O alto tráfego de usuários direcionado para os nós regulares não impede a renderização das cargas de trabalho atendidas pelos nós de renderização.
Práticas recomendadas
- Cada nó do Looker deve ser hospedado em uma VM dedicada.
- O balanceador de carga, que é o ponto de entrada do cluster, precisa ser um balanceador de carga da camada 4. Ele precisa ter um tempo limite longo (3.600 segundos), estar equipado com um certificado SSL assinado e configurado para encaminhar de 443 (https) para 9999 (o servidor de porta do Looker detecta).
- Omita os nós de renderização das regras de balanceamento de carga para que eles não disponibilizem tráfego do usuário final e solicitações de API internas.
- Aloque relativamente menos memória para Java nos nós de renderização para dar 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 sem renderização, então a quantidade de memória dedicada ao Looker pode ser aumentada. Em vez do padrão de 60%, considere um número mais alto, como 80%.
- Recomendamos que sua implantação tenha armazenamento com 2 IOPS por GB.