Patrones de arquitectura de infraestructura alojados por el cliente

En esta página, se exploran los patrones de arquitectura más comunes para una implementación alojada por el cliente y se describen las prácticas recomendadas para implementarlos. Para usar esta página de manera eficaz, debes familiarizarte con los conceptos y las prácticas de la arquitectura de sistemas.

Estrategia de flujo de trabajo

Luego de identificar el hosting automático como una opción viable para tu implementación de Looker, el siguiente paso es elaborar la estrategia que utilizará la implementación.

  1. Realizar una evaluación. Identifica una lista de candidatos de flujos de trabajo planificados y existentes.
  2. Enumera los patrones de arquitectura aplicables. Comenzando con los posibles flujos de trabajo identificados, identifica los patrones arquitectónicos aplicables.
  3. Prioriza y selecciona el patrón de arquitectura óptimo. Alinea el patrón de arquitectura con las tareas y los resultados más importantes.
  4. Configurar los componentes de la arquitectura y, luego, implementar la aplicación de Looker; Implementa el host, las dependencias de terceros y la topología de red necesarios para establecer conexiones seguras de clientes.

Opciones de arquitectura

Máquina virtual dedicada

Una opción es ejecutar Looker como una única instancia en una máquina virtual (VM) dedicada. Una sola instancia puede entregar cargas de trabajo exigentes mediante el escalamiento vertical del host y el aumento de los grupos de subprocesos predeterminados. Sin embargo, la sobrecarga de procesamiento de la administración de un montón de Java grande somete al escalamiento vertical a la ley de rendimientos decrecientes. Por lo general, es aceptable para cargas de trabajo pequeñas y medianas. En el siguiente diagrama, se muestran los parámetros de configuración predeterminados y opcionales entre una instancia de Looker que se ejecuta en una VM dedicada, los repositorios locales y remotos, los servidores SMTP y las fuentes de datos destacadas en las secciones Ventajas y Prácticas recomendadas para esta opción.

Diagrama que muestra las configuraciones predeterminadas y opcionales entre Looker que se ejecuta en una VM dedicada con repositorios locales y remotos, servidores SMTP y fuentes de datos.

Ventajas

  • Una VM dedicada es fácil de implementar y mantener.
  • La base de datos interna se aloja en la aplicación de Looker.
  • Los modelos de Looker, el repositorio de Git, el servidor SMTP y los componentes de la base de datos de backend se pueden configurar de forma local o remota.
  • Puedes reemplazar el servidor SMTP predeterminado de Looker por el tuyo para recibir notificaciones por correo electrónico y tareas programadas.

Prácticas recomendadas

  • De forma predeterminada, Looker puede generar repositorios de Git básicos para un proyecto. Recomendamos configurar un repositorio de Git remoto para obtener redundancia.
  • De forma predeterminada, Looker comienza con una base de datos HyperSQL en la memoria. Esta base de datos es cómoda y liviana, pero puede experimentar problemas de rendimiento si se usa mucho. Recomendamos el uso de una base de datos MySQL para implementaciones más grandes. Recomendamos migrar a una base de datos MySQL remota una vez que el archivo ~/looker/.db/looker.script alcanza los 600 MB.
  • Tu implementación de Looker deberá validarse con el servicio de licencias de Looker. se requiere el tráfico saliente en el puerto 443.
  • Una implementación de VM dedicada se puede escalar verticalmente aumentando los recursos disponibles y los grupos de subprocesos de Looker. Sin embargo, el aumento de la memoria RAM está sujeto a la ley de rendimientos decrecientes una vez que alcanza los 64 GB, ya que los eventos de recolección de elementos no utilizados son de un solo subproceso y detienen todos los demás subprocesos para ejecutarse. Los nodos con 16 CPU y 64 GB de RAM ofrecen un buen equilibrio entre precio y rendimiento.
  • Recomendamos que tu implementación tenga almacenamiento con 2 operaciones por segundo (IOPS) por GB.

Clúster de VMs

Ejecutar Looker como un clúster de instancias en múltiples VMs es un patrón flexible que se beneficia de la redundancia y la conmutación por error del servicio. La escalabilidad horizontal permite aumentar el rendimiento sin generar un aumento excesivo del montón ni costos excesivos de recolección de basura. Los nodos tienen la opción de dedicarse a la carga de trabajo, lo que permite que varias opciones de implementación se adapten a los distintos requisitos empresariales. Las implementaciones de clústeres requieren al menos un administrador del sistema que esté familiarizado con los sistemas Linux y sea capaz de administrar los componentes.

Clúster estándar

Para la mayoría de las implementaciones estándar, un clúster de nodos de servicio idénticos es suficiente. Todos los nodos del clúster se configuran de la misma manera y están en el mismo grupo de balanceadores de cargas. Ninguno de los nodos de esta configuración tendría más o menos probabilidades de entregar las solicitudes de los usuarios de Looker, una tarea de renderización, una tarea programada, una solicitud a la API, etcétera.

Este tipo de configuración es adecuada cuando la mayoría de las solicitudes provienen directamente de un usuario de Looker que ejecuta consultas y, además, interactúa con Looker. Comienza a desglosarse cuando una gran cantidad de solicitudes proviene de un programador, un procesador u otra fuente. En este caso, es beneficioso designar ciertos nodos de servicio para manejar tareas como los programas y la renderización.

Por ejemplo, los usuarios suelen programar los informes para que se ejecuten el lunes por la mañana. Un usuario que intenta ejecutar consultas de Looker el lunes por la mañana puede experimentar problemas de rendimiento mientras Looker trabaja con solicitudes pendientes programadas. Con el aumento de la cantidad de nodos de servicio, el clúster proporciona una efectividad proporcional en la capacidad de procesamiento en todas las funciones de Looker.

En el siguiente diagrama, se muestra cómo se equilibran las solicitudes a Looker que realiza el usuario, las apps y las secuencias de comandos en una instancia de Looker en clústeres.

Las solicitudes a Looker que realizan el usuario, las apps y las secuencias de comandos se distribuyen en un balanceador de cargas sobre tres nodos de Looker en una instancia de Looker en clústeres.

Ventajas

  • Un clúster estándar maximiza las posibilidades generales con una configuración mínima de la topología del clúster.
  • La VM de Java sufre una degradación del rendimiento en el umbral de memoria asignada de 64 GB. Por este motivo, el escalamiento horizontal tiene mayores rendimientos que el escalamiento vertical.
  • Una configuración de clúster garantiza la redundancia del servicio y la conmutación por error.

Prácticas recomendadas

  • Cada nodo de Looker debe estar alojado en su propia VM dedicada.
  • El balanceador de cargas, que es el punto de entrada del clúster, debe ser un balanceador de cargas de capa 4. Debe tener un tiempo de espera largo (3,600 segundos), estar equipado con un certificado SSL firmado y configurarse para que la redirección de puertos de 443 (https) a 9999 (el servidor de puerto de Looker escucha).
  • Recomendamos que tu implementación tenga almacenamiento de 2 IOPS por GB.

Desarrollo, etapa de pruebas y producción

En los casos de uso en los que se prioriza el tiempo de actividad máximo del contenido para los usuarios finales, recomendamos entornos de Looker separados para compartimentar el trabajo de desarrollo y el trabajo analítico. Esta arquitectura controla los cambios del entorno de producción detrás de entornos aislados de pruebas y desarrollo para mantener un entorno de producción lo más estable posible.

Estos beneficios requieren la configuración de los entornos interconectados y la adopción de un ciclo de lanzamiento sólido. Una implementación de desarrollo, etapa de pruebas y producción también requiere un equipo de desarrolladores familiarizados con la API de Looker y Git para la administración del flujo de trabajo.

En el siguiente diagrama, se muestra el flujo de contenido entre los desarrolladores de LookML que desarrollan contenido en la instancia de desarrollo, los verificadores de control de calidad (QA) que prueban el contenido en la instancia de QA y los usuarios, las apps y las secuencias de comandos que consumen el contenido en la instancia de producción.

El contenido se desarrolla en la instancia de desarrollo, se prueba en la instancia de QA y lo consumen los usuarios, las apps y las secuencias de comandos en la instancia de producción.

Ventajas

  • LookML y la validación de contenido ocurren en un entorno que no es de producción, lo que garantiza que cualquier modificación en la lógica del modelo se pueda verificar minuciosamente antes de llegar a los usuarios de producción.
  • Funciones en toda la instancia, como Las funciones de Labs o los protocolos de autenticación se pueden probar de forma aislada antes de que se habiliten en el entorno de producción.
  • Las políticas de grupo de datos y almacenamiento en caché se pueden probar en un entorno que no sea de producción.
  • Las pruebas del modo de producción de Looker están separadas de los entornos de producción que se encargan de atender a los usuarios finales.
  • Las versiones de Looker se pueden probar en entornos que no son de producción, lo que brinda tiempo suficiente para probar nuevas funciones, cambios en el flujo de trabajo y problemas antes de actualizar el entorno de producción.

Prácticas recomendadas

  • Aísla las diversas actividades que ocurren de forma simultánea en, al menos, tres instancias independientes:
    • Instancia de desarrollo: Los desarrolladores usan el entorno de desarrollo para confirmar código, realizar experimentos, corregir errores y cometer errores de forma segura.
    • Instancia de QA: También se conoce como entorno de prueba o de etapa de pruebas, en el que los desarrolladores ejecutan pruebas manuales y automatizadas. El entorno de QA es complejo y puede consumir muchos recursos.
    • Instancia de producción: Aquí es donde se crea valor para los clientes o la empresa. La producción es un entorno muy visible y no debería contener errores.
  • Mantén una base de datos documentada flujo de trabajo del ciclo de lanzamiento.
  • Si es necesario entregar grandes volúmenes de desarrolladores y verificadores de QA, las instancias de desarrollo o QA se pueden agrupar en clústeres. Ya sea que se dejan como una VM independiente o como un clúster de VMs, las instancias de desarrollo y control de calidad están sujetas a las mismas consideraciones arquitectónicas que se mostraron anteriormente en las secciones respectivas.

Alta capacidad de procesamiento de programación

Para los casos de uso que requieren una alta capacidad de procesamiento de informes programados y entregas oportunas y confiables, recomendamos que la configuración incluya un clúster con un grupo de nodos dedicados únicamente a la programación. Esta configuración ayudará a que la Web y las aplicaciones incorporadas sigan siendo rápidas y receptivas. Estos beneficios requieren la configuración de nodos con opciones de inicio personalizadas y reglas de balanceo de cargas adecuadas, como se muestra en el siguiente diagrama y se describen en las secciones Ventajas y Prácticas recomendadas para esta opción.

Configuración del clúster de Looker con un grupo de nodos dedicados únicamente a la programación.

Ventajas

  • Los nodos dedicados para una función específica compartien los recursos para la programación de las funciones de análisis ad hoc y de desarrollo.
  • Los usuarios pueden desarrollar LookML y explorar contenido sin tener que pasar de los nodos responsables de atender las entregas programadas de informes.
  • El alto tráfico de usuarios canalizado a los nodos regulares no impide las cargas de trabajo programadas atendidas por nodos de programación.

Prácticas recomendadas

  • Cada nodo de Looker debe estar alojado en su propia VM dedicada.
  • El balanceador de cargas, que es el punto de entrada del clúster, debe ser un balanceador de cargas de capa 4. Debe tener un tiempo de espera largo (3,600 segundos), estar equipado con un certificado SSL firmado y estar configurado para reenviar puertos desde 443 (HTTPS) a 9999 (puerto en el que escucha el servidor de Looker).
  • Omite los nodos del programador de las reglas de balanceo de cargas para que no entreguen tráfico de usuario final ni solicitudes a la API internas.
  • Recomendamos que tu implementación tenga almacenamiento de 2 IOPS por GB.

Alta capacidad de procesamiento de renderización

Para los casos de uso que requieren una alta capacidad de procesamiento de informes de renderización, recomendamos configurar un clúster con un grupo de nodos dedicados únicamente a la renderización. Renderizar un archivo PDF o una imagen PNG/JPEG es una operación relativamente costosa en términos de recursos en Looker. La renderización puede consumir mucha memoria y CPU, por lo que, cuando Linux está bajo presión de memoria, podría finalizar un proceso en ejecución. Dado que no se puede determinar con anticipación el uso de memoria de un trabajo de renderización, si inicias un trabajo de renderización, es posible que finalice el proceso de Looker. La configuración de nodos de renderización dedicados permitirá un ajuste óptimo de los trabajos de renderización y, al mismo tiempo, preservará la capacidad de respuesta de la aplicación incorporada y interactiva.

Estos beneficios requieren la configuración de nodos con opciones de inicio personalizadas y reglas de balanceo de cargas adecuadas, como se muestra en el siguiente diagrama y se explica en las secciones Ventajas y Prácticas recomendadas para esta opción. Además, es posible que los nodos de renderización requieran más recursos de host que los nodos estándar, ya que el servicio de renderización de Looker depende de procesos de Chromium de terceros que comparten tiempo y memoria de la CPU.

Configuración del clúster de Looker con un grupo de nodos dedicados a la renderización.

Ventajas

  • Los nodos dedicados para una función específica compartien los recursos para la renderización de funciones de estadísticas ad hoc y de desarrollo.
  • Los usuarios pueden desarrollar LookML y explorar contenido sin quitar ciclos de los nodos responsables de renderizar archivos PNG y PDF.
  • El alto tráfico de usuarios que se canaliza a los nodos normales no impide la renderización de cargas de trabajo que se atienden con nodos de renderización.

Prácticas recomendadas

  • Cada nodo de Looker debe estar alojado en su propia VM dedicada.
  • El balanceador de cargas, que es el punto de entrada del clúster, debe ser un balanceador de cargas de capa 4. Debe tener un tiempo de espera largo (3,600 segundos), estar equipado con un certificado SSL firmado y estar configurado para reenviar puertos desde 443 (HTTPS) a 9999 (puerto en el que escucha el servidor de Looker).
  • Omite los nodos de renderización de las reglas de balanceo de cargas, de modo que no entreguen tráfico de usuarios finales ni solicitudes a la API internas.
  • Asigna relativamente menos memoria a Java en los nodos de procesamiento para dar a los procesos de Chromium un búfer de memoria más grande. En lugar de asignar el 60% de la memoria a Java, asigna del 40 al 50%.
  • Se redujo el riesgo de presión de memoria en los nodos que no renderizan, por lo que se puede aumentar la cantidad de memoria dedicada a Looker. En lugar del 60% predeterminado, considera un número más alto, como el 80%.
  • Recomendamos que tu implementación tenga almacenamiento de 2 IOPS por GB.