Esta página aborda 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 de arquitetura de sistemas.
Estratégia de fluxo de trabalho
Depois de identificar a autohospedagem como uma opção viável para a implementação do Looker, a próxima etapa é elaborar a estratégia que será usada pela implantação.
- Faça uma avaliação. Identifique uma lista de candidatos de fluxos de trabalho planejados e atuais.
- Listar padrões de arquitetura aplicáveis. Começando pelos fluxos de trabalho indicados, identifique os padrões de arquitetura aplicáveis.
- Priorize e selecione o padrão de arquitetura ideal. Alinhar o padrão de arquitetura com as tarefas e os resultados mais importantes.
- Configure os componentes da arquitetura e implante o aplicativo do Looker. Implemente o host, as dependências de terceiros e a topologia de rede necessárias para estabelecer conexões seguras com o cliente.
Opções de arquitetura
Máquina virtual dedicada
Uma opção é executar o Looker como uma única instância 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, é 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 é 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 simples 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 precisa ser validada pelo 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 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. As implantações de cluster exigem pelo menos um administrador de sistemas que conheça sistemas Linux e seja capaz de gerenciar os 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 falhar quando um grande número de solicitações vem de um programador, um renderizador ou outra origem. Nesse caso, é benéfico designar determinados nós de serviço para lidar com tarefas como programação e renderização.
Por exemplo, os usuários geralmente agendam entregas de dados para serem executadas na manhã de segunda-feira. Um usuário que tentar executar consultas do Looker na segunda-feira de manhã pode ter problemas de desempenho enquanto o Looker trabalha no backlog de 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 a utilização geral com a configuração mínima da topologia do cluster.
- A VM Java sofre degradação de desempenho no limite de 64 GB de memória alocada. É por isso que o escalonamento horizontal tem retornos maiores do que o vertical.
- Uma configuração de cluster garante a redundância do serviço e o failover.
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 de 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 separar os ambientes do Looker para compartimentalizar o trabalho de desenvolvimento e de análise. Ao restringir as mudanças no ambiente de produção por trás de ambientes de desenvolvimento e teste isolados, 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 desenvolvimento/estágio/produção também requer uma equipe de desenvolvedores que conheçam a API Looker e o Git para administração de fluxos 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 garantia de qualidade (QA) que testam o conteúdo na instância de QA e usuários, apps e scripts que consomem o conteúdo na instância de produção.
Vantagens
- A validação do LookML e do conteúdo ocorre em um ambiente que não é de produção, garantindo que todas as modificações na lógica do modelo possam ser analisadas completamente antes de chegar aos usuários de produção.
- Recursos da instância, como Os recursos do Labs ou os protocolos de autenticação podem ser testados em isolamento antes de serem ativados no ambiente de produção.
- As políticas de grupos de dados e de armazenamento em cache podem ser testadas 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, 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 chamada de ambiente de teste ou de preparação, é onde os desenvolvedores executam testes manuais e automatizados. O ambiente de controle de qualidade é complexo e pode consumir muitos recursos.
- Instância de produção: é onde o valor é criado para os clientes e/ou a empresa. Production é um ambiente altamente visível e não deve conter erros.
- Manter um fluxo de trabalho do ciclo de lançamento documentado e repetível.
- Se for necessário atender grandes volumes de desenvolvedores e testadores de controle de qualidade, as instâncias de desenvolvimento e/ou de 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 entrega programada de dados e entregas oportunas e confiáveis, 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. Para aproveitar esses benefícios, é necessário configurar nós com opções de inicialização personalizadas e regras adequadas de balanceamento de carga, conforme mostrado no diagrama a seguir e descrito nas seções Vantagens e Práticas recomendadas para essa 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 analisar conteúdo sem ocupar ciclos dos nós responsáveis por processar as entregas de dados programadas.
- 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 a implantação tenha armazenamento com 2 IOPS por GB.
Alta capacidade de renderização
Para casos de uso que exigem alta taxa de transferência de relatórios de renderização, recomendamos configurar um cluster com um pool de nós dedicado exclusivamente à renderização. Renderizar um arquivo PDF ou uma imagem PNG/JPEG é uma operação relativamente cara em termos de recursos no Looker. A renderização pode consumir muita memória e CPU. Quando o Linux está sob pressão de memória, ele pode encerrar um processo em execução. Como o uso de memória de um job de renderização não pode ser determinado com antecedência, 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 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 a seguir 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 do Chromium de terceiros que compartilham tempo de CPU e 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 analisar o conteúdo sem usar ciclos dos nós responsáveis por renderizar 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 estar configurado para encaminhar a porta de 443 (https) para 9999 (a porta que o servidor do Looker detecta).
- Omita nós de renderização das regras de balanceamento de carga para que eles não atendam o tráfego do usuário final e as solicitações de API internas.
- Aloque menos memória para o 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 de memória foi reduzido nos nós sem renderização. Assim, 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 a implantação tenha armazenamento com 2 IOPS por GB.