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 conocer 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 tu implementación de Looker, el siguiente paso es elaborar la estrategia que se aplicará en la implementación.

  1. Realiza una evaluación. Identifica una lista de posibles flujos de trabajo planificados y existentes.
  2. Enumera los patrones de arquitectura aplicables. Comienza por los flujos de trabajo candidatos identificados y reconoce 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. Configura los componentes de la arquitectura e implementa la aplicación de Looker. Implementa el host, las dependencias de terceros y la topología de red necesarios para establecer conexiones seguras del cliente.

Opciones de arquitectura

Máquina virtual dedicada

Una opción es ejecutar Looker como una sola instancia en una máquina virtual (VM) dedicada. Una sola instancia puede atender cargas de trabajo exigentes si se escala verticalmente el host y se aumentan los grupos de subprocesos predeterminados. Sin embargo, la sobrecarga de procesamiento de la administración de un montón de Java grande somete el ajuste de escala vertical a la ley de retornos decrecientes. Por lo general, es aceptable para cargas de trabajo pequeñas y 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 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 dentro de la aplicación de Looker.
  • Los componentes de los modelos de Looker, el repositorio de Git, el servidor SMTP y la base de datos de backend se pueden configurar de forma local o remota.
  • Puedes reemplazar el servidor SMTP predeterminado de Looker por uno propio para las notificaciones por correo electrónico y las 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 la 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 experimentar 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 alcance los 600 MB.
  • Tu implementación de Looker deberá validarse con el servicio de licencias de Looker. Se requiere 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, 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 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 varias 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 una expansión excesiva del montón ni costos excesivos de recolección de elementos no utilizados. Los nodos tienen la opción de dedicación de la carga de trabajo, lo que permite adaptar varias opciones de implementación a diferentes requisitos comerciales. Las implementaciones de clústeres requieren al menos un administrador del sistema que esté familiarizado con los sistemas Linux y sea capaz de administrar las partes componentes.

Clúster estándar

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

Este tipo de configuración es adecuado cuando la mayoría de las solicitudes provienen directamente de un usuario de Looker que ejecuta consultas y que 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 que controlen tareas como la programación y la renderización.

Por ejemplo, los usuarios suelen programar las entregas de datos 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 en la pila de solicitudes programadas. Al aumentar 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 se realizan desde el usuario, las apps y las secuencias de comandos en una instancia de Looker agrupada en clústeres.

Las solicitudes a Looker que se realizan desde el usuario, las apps y los secuencias de comandos se distribuyen en un balanceador de cargas sobre tres nodos de Looker en una instancia de Looker agrupada 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, por lo que el escalamiento horizontal tiene mayores retornos que el escalamiento vertical.
  • La configuración de un clúster garantiza la redundancia y la conmutación por error del servicio.

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 reenviar puertos del 443 (https) al 9999 (puerto en el que escucha el servidor de Looker).
  • Te recomendamos que tu implementación tenga almacenamiento con 2 IOPS por GB.

Desarrollo/etapa de pruebas/producción

Para 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. Al restringir los cambios en el entorno de producción detrás de entornos de desarrollo y pruebas aislados, esta arquitectura 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 desarrollo/etapa de pruebas/producción también requiere un equipo de desarrolladores que estén 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 los lenguajes de programación 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 los usuarios, las apps y las secuencias de comandos lo consumen en la instancia de producción.

Ventajas

  • La validación de LookML y 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 verificar a fondo antes de llegar a los usuarios de producción.
  • Las funciones a nivel de la instancia, como las funciones de Labs o los protocolos de autenticación, se pueden probar de forma aislada antes de habilitarse en el entorno de producción.
  • Las políticas de almacenamiento en caché y de grupos de datos se pueden probar en un entorno que no sea de producción.
  • Las pruebas del modo de producción de Looker se desacoplan de los entornos de producción que son responsables de atender a los usuarios finales.
  • Las versiones de Looker se pueden probar en un entorno que no sea de producción, lo que brinda tiempo suficiente para probar las nuevas funciones, los cambios en el flujo de trabajo y los 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 separadas:
    • Instancia de desarrollo: Los desarrolladores usan el entorno de desarrollo para confirmar código, realizar experimentos, corregir errores y equivocarse de forma segura.
    • Instancia de QA: También conocida como entorno de prueba o etapa de pruebas, es donde los desarrolladores ejecutan pruebas manuales y automatizadas. El entorno de QA es complejo y puede consumir muchos recursos.
    • Instancia de producción: Es donde se crea valor para los clientes o la empresa. La producción es un entorno muy visible y no debe tener errores.
  • Mantén un flujo de trabajo del ciclo de lanzamiento documentado y repetible.
  • Si es necesario atender a grandes cantidades de desarrolladores y verificadores de QA, se pueden agrupar las instancias de desarrollo o de QA. Ya sea que se dejen como una VM independiente o un clúster de VMs, las instancias de desarrollo y QA están sujetas a las mismas consideraciones de arquitectura que se mostraron anteriormente en las secciones respectivas.

Alta capacidad de procesamiento de la programación

Para los casos de uso que requieren un alto rendimiento de entrega de datos programada y entregas confiables y oportunas, recomendamos que la configuración incluya un clúster con un grupo de nodos dedicados exclusivamente a la programación. Esta configuración ayudará a que las aplicaciones web y las aplicaciones integradas sigan siendo rápidas y responsivas. Estos beneficios requieren 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 para esta opción.

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

Ventajas

  • La dedicación de nodos a una función específica compartimenta los recursos para la programación de funciones de desarrollo y de análisis ad hoc.
  • Los usuarios pueden desarrollar LookML y explorar contenido sin consumir ciclos de los nodos responsables de brindar servicios de entregas de datos programadas.
  • El alto tráfico de usuarios canalizado a los nodos normales no impide las cargas de trabajo programadas que atienden los 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 reenviar puertos del 443 (https) al 9999 (puerto en el que escucha el servidor de Looker).
  • Omitir los nodos del programador de las reglas de balanceo de cargas para que no atiendan el tráfico de usuarios finales 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 la renderización

En los casos de uso que requieren un alto rendimiento de los informes de renderización, recomendamos configurar 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, y, cuando Linux está bajo presión de memoria, podría detener un proceso en ejecución. Dado que el uso de memoria de un trabajo de renderización no se puede determinar con anticipación, iniciar un trabajo de renderización podría provocar que se cierre el proceso de Looker. Configurar nodos de renderización dedicados permitirá un ajuste óptimo de los trabajos de renderización y, al mismo tiempo, conservará la capacidad de respuesta de la aplicación interactiva y la aplicación integrada.

Estos beneficios requieren 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 para esta opción. Además, es posible que los nodos de renderización requieran más recursos del host que los nodos estándar, ya que el servicio de renderización de Looker depende de que los procesos de Chromium de terceros compartan tiempo de CPU y memoria.

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

Ventajas

  • La asignación de nodos a una función específica compartimenta los recursos para la renderización de las funciones de desarrollo y de análisis ad hoc.
  • Los usuarios pueden desarrollar LookML y explorar contenido sin utilizar ciclos de los nodos responsables de renderizar PNG y PDF.
  • El alto tráfico de usuarios canalizado a los nodos normales no impide las cargas de trabajo de renderización que atienden 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 configurarse para reenviar puertos del 443 (https) al 9999 (puerto en el que escucha el servidor de Looker).
  • Omitir los nodos de renderización de las reglas de balanceo de cargas para que no atiendan el tráfico de usuarios finales ni las solicitudes internas de la API
  • Asigna relativamente menos memoria a Java en los nodos de renderización para proporcionarles 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 son de renderización, 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%.
  • Te recomendamos que tu implementación tenga almacenamiento con 2 IOPS por GB.