Schémas d'architecture de l'infrastructure hébergée par le client

Cette page fait partie d'une série en plusieurs parties qui traite de l'hébergement de Looker, des méthodologies de déploiement et des bonnes pratiques pour les composants impliqués. Cette page explore les modèles d'architecture les plus courants pour un déploiement hébergé par un client et décrit les bonnes pratiques de mise en œuvre. Pour utiliser cette page efficacement, vous devez connaître les concepts et les pratiques liés à l'architecture système.

Cette série se compose de trois parties:

• Présentation de l'infrastructure hébergée par le client
• Modèles d'architecture d'infrastructure hébergée par le client (cette page)
• Tutoriels des composants d'infrastructure hébergés par le client

Stratégie de workflow

Une fois que vous avez identifié l'auto-hébergement comme une option viable pour votre implémentation de Looker, l'étape suivante consiste à élaborer la stratégie de déploiement.

1. Réalisez une évaluation. Identifiez une liste des flux de travail planifiés et existants.
2. Répertoriez les modèles d'architecture applicables. En commençant par les flux de travail candidats identifiés, identifiez les modèles architecturaux applicables.
3. Priorisez et sélectionnez le modèle d'architecture optimal. Alignez le modèle d'architecture sur les tâches et les résultats les plus importants.
4. Configurez les composants d'architecture et déployez l'application Looker. Implémentez l'hôte, les dépendances tierces et la topologie du réseau nécessaires pour établir des connexions client sécurisées.

Options d'architecture

Machine virtuelle dédiée

Une option consiste à exécuter Looker en tant qu'instance unique dans une machine virtuelle (VM) dédiée. Une seule instance peut traiter des charges de travail exigeantes en effectuant un scaling vertical de l'hôte et en augmentant le nombre de pools de threads par défaut. Toutefois, les coûts de traitement liés à la gestion d'un tas de mémoire Java volumineux entraînent le scaling vertical du scaling vertical à la loi des retours décroissants. Elle est généralement acceptable pour les charges de travail de petite à moyenne envergure. Le schéma suivant illustre les configurations par défaut et facultatives entre une instance Looker exécutée sur une VM dédiée, les dépôts locaux et distants, les serveurs SMTP et les sources de données mises en évidence dans les sections Avantages et Bonnes pratiques concernant cette option.

Avantages

• Une VM dédiée est facile à déployer et à gérer.
• La base de données interne est hébergée dans l'application Looker.
• Les modèles Looker, le dépôt Git, le serveur SMTP et les composants de base de données backend peuvent être configurés localement ou à distance.
• Vous pouvez remplacer le serveur SMTP par défaut de Looker par le vôtre pour les notifications par e-mail et les tâches planifiées.

Bonnes pratiques

• Par défaut, Looker peut générer des dépôts Git simples pour un projet. Nous vous recommandons de configurer un dépôt Git distant pour la redondance.
• Par défaut, Looker commence avec une base de données HyperSQL en mémoire. Cette base de données est pratique et légère, mais peut rencontrer des problèmes de performances en cas d'utilisation intensive. Nous vous recommandons d'utiliser une base de données MySQL pour les déploiements de plus grande envergure. Nous vous recommandons de migrer vers une base de données MySQL distante lorsque la taille du fichier ~/looker/.db/looker.script atteint 600 Mo.
• Votre déploiement Looker devra être validé par rapport au service de gestion des licences de Looker ; le trafic sortant sur le port 443 est requis.
• Un déploiement de VM dédié peut être mis à l'échelle verticalement en augmentant le nombre de ressources disponibles et les pools de threads Looker. Toutefois, l'augmentation de la RAM est soumise à la loi de diminution des retours une fois qu'elle atteint 64 Go, car les événements de récupération de mémoire sont monothread et interrompent l'exécution de tous les autres threads. Les nœuds avec 16 processeurs et 64 Go de RAM offrent un bon compromis entre prix et performances.
• Nous vous recommandons de configurer un espace de stockage avec deux opérations par seconde (IOPS) par Go pour votre déploiement.

Cluster de VM

L'exécution de Looker en tant que cluster d'instances sur plusieurs VM est un modèle flexible qui bénéficie du basculement et de la redondance des services. L'évolutivité horizontale permet d'augmenter le débit sans subir de surcharge de tas de mémoire ni de coûts de récupération de mémoire excessifs. Les nœuds peuvent être dédiés aux charges de travail, ce qui permet de les adapter à différentes options de déploiement en fonction des différentes exigences de l'entreprise. Les déploiements de clusters nécessitent au moins un administrateur système qui connaît bien les systèmes Linux et sait gérer les composants.

Cluster standard

Pour la plupart des déploiements standards, un cluster de nœuds de service identiques suffit. Tous les nœuds du cluster sont configurés de la même manière et se trouvent tous dans le même pool d'équilibreur de charge. Aucun des nœuds de cette configuration n'est plus ou moins susceptible de répondre aux requêtes des utilisateurs Looker, à une tâche de rendu, à une tâche planifiée, à une requête API, etc.

Ce type de configuration convient lorsque la majorité des requêtes proviennent directement d'un utilisateur de Looker qui exécute des requêtes et interagit avec Looker. Elle commence à se répartir lorsqu'un grand nombre de requêtes proviennent d'un planificateur, d'un moteur de rendu ou d'une autre source. Dans ce cas, il est utile de désigner certains nœuds de service pour gérer des tâches telles que les planifications et le rendu.

Par exemple, les utilisateurs planifient généralement l'exécution des rapports le lundi matin. Un utilisateur essayant d'exécuter des requêtes Looker le lundi matin peut rencontrer des problèmes de performances, tandis que Looker s'occupe des requêtes planifiées en attente. En augmentant le nombre de nœuds de service, le cluster fournit une augmentation proportionnelle du débit sur l'ensemble des capacités de Looker.

Le schéma suivant illustre l'équilibre entre les requêtes envoyées à Looker par l'utilisateur, les applications et les scripts sur une instance Looker en cluster.

Avantages

• Un cluster standard maximise les performances générales de bout en bout avec une configuration minimale de la topologie du cluster.
• La VM Java subit une dégradation des performances au niveau du seuil de mémoire alloué de 64 Go. C'est pourquoi le scaling horizontal offre des rendements plus élevés que le scaling vertical.
• La configuration d'un cluster garantit la redondance des services et le basculement.

Bonnes pratiques

• Chaque nœud Looker doit être hébergé sur sa propre VM dédiée.
• L'équilibreur de charge, qui est le point d'entrée du cluster, doit être un équilibreur de charge de couche 4. Il doit avoir un long délai avant expiration (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour effectuer un transfert de port de 443 (https) à 9999 (port écoute du serveur Looker).
• Nous vous recommandons de configurer un espace de stockage avec 2 IOPS par Go pour votre déploiement.

Développement/Préproduction/Production

Pour les cas d'utilisation qui donnent la priorité aux utilisateurs finaux pour une disponibilité maximale du contenu, nous recommandons des environnements Looker distincts afin de compartimenter le travail de développement et le travail d'analyse. En contrôlant les changements de l'environnement de production derrière les environnements de développement et de test isolés, cette architecture conserve un environnement de production aussi stable que possible.

Ces avantages nécessitent la configuration d'environnements interconnectés et l'adoption d'un cycle de publication robuste. Un déploiement en développement/préproduction/production nécessite également une équipe de développeurs qui maîtrisent l'API Looker et Git pour l'administration du workflow.

Le schéma suivant illustre le flux de contenu entre les développeurs LookML qui développent du contenu sur l'instance de développement, les testeurs d'assurance qualité qui testent le contenu sur l'instance de contrôle qualité et les utilisateurs, les applications et les scripts qui consomment le contenu de l'instance de production.

Avantages

• La validation du code LookML et du contenu s'effectue dans un environnement hors production, ce qui garantit que toute modification de la logique du modèle peut être minutieusement vérifiée avant d'être transmise aux utilisateurs en production.
• Les fonctionnalités à l'échelle de l'instance, telles que les fonctionnalités de Labs ou les protocoles d'authentification, peuvent être testées de manière isolée avant d'être activées dans l'environnement de production.
• Les règles de groupe de données et de mise en cache peuvent être testées dans un environnement hors production.
• Les tests en mode production de Looker sont dissociés des environnements de production chargés de servir les utilisateurs finaux.
• Les versions de Looker peuvent être testées dans un environnement hors production, ce qui laisse suffisamment de temps pour tester les nouvelles fonctionnalités, les modifications du workflow et les problèmes avant de mettre à jour l'environnement de production.

Bonnes pratiques

• Isolez les différentes activités qui se produisent simultanément dans au moins trois instances distinctes:
• Instance de développement: les développeurs utilisent l'environnement de développement pour valider du code, réaliser des tests, corriger des bugs et commettre des erreurs en toute sécurité.
• Instance de contrôle qualité: environnement également appelé environnement de test ou de préproduction, où les développeurs effectuent des tests manuels et automatisés. L'environnement de contrôle qualité est complexe et peut consommer beaucoup de ressources.
• Instance de production: il s'agit de l'endroit où la valeur est créée pour les clients et/ou l'entreprise. L'environnement de production est très visible et ne devrait comporter aucune erreur.

• Maintenez un workflow de cycle de publication documenté et reproductible.
• S'il est nécessaire de traiter un grand nombre de développeurs et de testeurs de contrôle qualité, les instances de développement et/ou de contrôle qualité peuvent être mises en cluster. Qu'elles soient utilisées en tant que VM autonomes ou en clusters de VM, les instances de développement et de contrôle qualité sont soumises aux mêmes considérations architecturales que celles présentées dans les sections respectives ci-dessus.

Débit de planification élevé

Pour les cas d'utilisation nécessitant un débit de rapport planifié élevé et des envois rapides et fiables, nous vous recommandons d'inclure un cluster avec un pool de nœuds exclusivement dédiés à la planification dans la configuration. Cette configuration contribue à maintenir la rapidité et la réactivité des applications Web et intégrées. Ces avantages nécessitent la configuration de nœuds avec des options de démarrage personnalisées et des règles d'équilibrage de charge appropriées, comme illustré dans le schéma ci-dessous et dans les sections Avantages et Bonnes pratiques concernant cette option.

Avantages

• En attribuant des nœuds à une fonction spécifique, vous compartimentez les ressources pour la planification à partir des fonctions de développement et d'analyse ad hoc.
• Les utilisateurs peuvent développer du code LookML et explorer le contenu sans perdre de temps avec les nœuds responsables de l'envoi des rapports planifiés.
• Un trafic utilisateur élevé dirigé vers les nœuds standards n'entrave pas les charges de travail planifiées gérées par les nœuds de planification.

Bonnes pratiques

• Chaque nœud Looker doit être hébergé sur sa propre VM dédiée.
• L'équilibreur de charge, qui est le point d'entrée du cluster, doit être un équilibreur de charge de couche 4. Il doit avoir un long délai avant expiration (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour effectuer un transfert de port de 443 (https) à 9999 (port écoute du serveur Looker).
• Omettez les nœuds de programmeur des règles d'équilibrage de charge afin qu'ils ne diffusent pas le trafic des utilisateurs finaux ni les requêtes API internes.
• Nous vous recommandons de configurer un espace de stockage avec 2 IOPS par Go pour votre déploiement.

Débit de rendu élevé

Pour les cas d'utilisation nécessitant un débit de rapport élevé, nous vous recommandons de configurer un cluster avec un pool de nœuds exclusivement dédiés au rendu. Le rendu d'un fichier PDF ou d'une image PNG/JPEG est une opération relativement coûteuse en ressources dans Looker. Le rendu peut utiliser de manière intensive la mémoire et le processeur. Lorsque Linux est soumis à une charge de mémoire, il peut interrompre un processus en cours d'exécution. Étant donné que l'utilisation de la mémoire pour un job de rendu ne peut pas être déterminée à l'avance, le lancement d'un job de rendu peut entraîner la fermeture du processus Looker. La configuration de nœuds de rendu dédiés permettra un réglage optimal des tâches de rendu tout en préservant la réactivité de l'application interactive et intégrée.

Ces avantages nécessitent la configuration de nœuds avec des options de démarrage personnalisées et des règles d'équilibrage de charge appropriées, comme illustré dans le schéma ci-dessous et expliqué dans les sections Avantages et Bonnes pratiques concernant cette option. En outre, les nœuds de rendu peuvent nécessiter plus de ressources hôtes que les nœuds standards, car le service de rendu de Looker dépend de processus Chromium tiers partageant le temps CPU et la mémoire.

Avantages

• En attribuant des nœuds à une fonction spécifique, compartimentez les ressources pour le rendu des fonctions de développement et d'analyse ad hoc.
• Les utilisateurs peuvent développer du code LookML et explorer le contenu sans perdre de temps avec les nœuds responsables de l'affichage des fichiers PNG et PDF.
• Un trafic utilisateur élevé dirigé vers les nœuds standards n'entrave pas les charges de travail de rendu gérées par les nœuds de rendu.

Bonnes pratiques

• Chaque nœud Looker doit être hébergé sur sa propre VM dédiée.
• L'équilibreur de charge, qui est le point d'entrée du cluster, doit être un équilibreur de charge de couche 4. Il doit avoir un long délai avant expiration (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour effectuer un transfert de port de 443 (https) à 9999 (port écoute du serveur Looker).
• Omettez les nœuds de rendu des règles d'équilibrage de charge afin qu'ils ne diffusent pas le trafic des utilisateurs finaux ni les requêtes API internes.
• Allouez relativement moins de mémoire à Java dans les nœuds de rendu afin d'offrir aux processus Chromium un tampon de mémoire plus important. Au lieu d'allouer 60% de la mémoire à Java, allouez entre 40 et 50%.
• Le risque de pression sur la mémoire a été réduit sur les nœuds non dédiés au rendu, ce qui permet d'augmenter la quantité de mémoire dédiée à Looker. Au lieu des 60 % par défaut, envisagez un nombre plus élevé (80 %, par exemple).
• Nous vous recommandons de configurer un espace de stockage avec 2 IOPS par Go pour votre déploiement.