Patrones de arquitectura de infraestructura alojada 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 del sistema.

Estrategia de flujo de trabajo

Después de identificar el alojamiento propio como una opción viable para la implementación de Looker, el siguiente paso es elaborar la estrategia que se publicará con la implementación.

  1. Realiza una evaluación. Identifica una lista de candidatos de flujos de trabajo planificados y existentes.
  2. Enumera los patrones de arquitectura aplicables. Comienza por los flujos de trabajo candidatos identificados y, luego, identifica los patrones de arquitectura 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 o medianas. En el siguiente diagrama, se muestran las configuraciones predeterminadas 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 que se destacan en las secciones Ventajas y Prácticas recomendadas de esta opción.

Diagrama en el que se muestran los parámetros de configuración predeterminados 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 enviar 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 conveniente y liviana, pero puede tener problemas de rendimiento con un uso intensivo. 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 puede escalarse verticalmente mediante el aumento de los recursos disponibles y los grupos de subprocesos de Looker. Sin embargo, aumentar la RAM está sujeto a la ley de rendimientos decrecientes una vez que alcanza los 64 GB, ya que los eventos de recolección de basura son de un solo subproceso y detienen todos los demás subprocesos para su ejecución. 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 varias VMs es un patrón flexible que se beneficia de la conmutación por error del servicio y la redundancia. La escalabilidad horizontal permite una mayor capacidad de procesamiento sin que el montón esté sobrecargado ni los costos excesivos de recolección de elementos no utilizados. 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 fallar cuando una gran cantidad de solicitudes provienen de un programador, un renderizador o alguna 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 entregas de datos para que se ejecuten el lunes por la mañana. Es posible que un usuario que intente ejecutar consultas de Looker el lunes por la mañana experimente problemas de rendimiento mientras Looker trabaja en la lista de tareas pendientes de solicitudes programadas. Cuando aumentas la cantidad de nodos de servicio, el clúster proporciona un aumento 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 realiza 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 el rendimiento general 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. y es por eso que el escalamiento horizontal tiene mayores retornos que el 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 alojarse 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).
  • Recomendamos que tu implementación tenga almacenamiento de 2 IOPS por GB.

Desarrollo, etapa de pruebas y producción

En el caso de los casos de uso que priorizan 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. Dado que esta arquitectura controla los cambios en el entorno de producción detrás de entornos de desarrollo y pruebas aislados, mantiene 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 dev/etapa/prod también requiere un equipo de desarrolladores que estén familiarizados con la API de Looker y Git para la administración de flujos 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

  • La validación de LookML y el contenido se realiza en un entorno que no es de producción, lo que garantiza que cualquier modificación en la lógica del modelo se pueda revisar en detalle 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 grupos 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 son responsables de entregar contenido 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 distintas:
    • 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. Aquí es donde 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 entrega de datos programada 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. Para obtener estos beneficios, debes configurar nodos con opciones de inicio personalizadas y reglas de balanceo de cargas adecuadas, como se muestra en el siguiente diagrama y se describe en las secciones Ventajas y Prácticas recomendadas de 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 datos.
  • 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 alojarse 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).
  • Omite los nodos del programador de las reglas de balanceo de cargas para que no entreguen el tráfico del usuario final ni las solicitudes internas de la API.
  • Te recomendamos que tu implementación tenga almacenamiento con 2 IOPS por GB.

Alta capacidad de procesamiento de renderización

En el caso de los casos de uso que requieren una alta capacidad de procesamiento de informes de renderización, te recomendamos que configures un clúster con un grupo de nodos dedicados exclusivamente 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 las tareas de renderización y, al mismo tiempo, preservará la capacidad de respuesta de la aplicación interactiva y, además, la aplicación incorporada.

Para obtener estos beneficios, debes configurar 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 de 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

  • La asignación de nodos para una función específica compartimenta los recursos de renderización de las funciones de desarrollo y analíticas ad hoc.
  • Los usuarios pueden desarrollar LookML y explorar contenido sin tener que salir de los nodos que se encargan de renderizar los PNG y PDF.
  • El alto tráfico de usuarios que se canaliza a los nodos normales no impide las cargas de trabajo de renderización que se entregan a los nodos de renderización.

Prácticas recomendadas

  • Cada nodo de Looker debe alojarse 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 entre el 40 y el 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.