Modèles d'architecture d'infrastructure hébergée par le client

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 d'architecture système.

Stratégie de workflow

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

1. Effectuez une évaluation. Identifiez une liste des workflows planifiés et existants.
2. Répertoriez les modèles d'architecture applicables. En commençant par les workflows candidats que vous avez identifiés, identifiez les modèles d'architecture applicables.
3. Hiérarchisez 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 architecturaux et déployez l'application Looker. Implémentez l'hôte, les dépendances tierces et la topologie 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 instance unique peut diffuser des charges de travail exigeantes en effectuant un scaling vertical de l'hôte et en augmentant les pools de threads par défaut. Toutefois, les coûts de traitement liés à la gestion d'un tas Java volumineux soumettent la mise à l'échelle verticale à la loi des rendements décroissants. Il est généralement acceptable pour les charges de travail petites et moyennes. Le schéma suivant illustre les configurations par défaut et facultatives entre une instance Looker qui s'exécute 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 pour 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 la 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 nus 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 plus importants. Nous vous recommandons de migrer vers une base de données MySQL distante lorsque le fichier ~/looker/.db/looker.script atteint 600 Mo.
• Votre déploiement Looker devra être validé par rapport au service de licence 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 les ressources disponibles et les pools de threads Looker. Cependant, l'augmentation de la RAM est soumise à la loi des retours décroissants 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 choisir un stockage avec deux opérations par seconde (IOPS) par Go pour votre déploiement.

Cluster de VM

Exécuter Looker en tant que cluster d'instances sur plusieurs VM est un modèle flexible qui bénéficie de la redondance et du basculement de service. L'évolutivité horizontale offre un débit plus élevé sans surcharger le tas de mémoire ni engendrer de coûts excessifs de récupération de mémoire. Les nœuds peuvent être dédiés à l'affectation d'une charge de travail, ce qui permet d'adapter plusieurs options de déploiement aux différentes exigences de l'entreprise. Les déploiements de clusters nécessitent au moins un administrateur système qui connaît les systèmes Linux et qui est capable de gérer les composants.

Cluster standard

Pour la plupart des déploiements standards, un cluster de nœuds de service identiques est suffisant. Tous les nœuds du cluster sont configurés de la même manière et appartiennent au 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 d'API, etc.

Ce type de configuration est adapté lorsque la majorité des requêtes proviennent directement d'un utilisateur Looker qui exécute des requêtes et interagit avec Looker. Il commence à se décomposer 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 les envois de données pour le lundi matin. Un utilisateur qui tente d'exécuter des requêtes Looker le lundi matin peut rencontrer des problèmes de performances pendant que Looker traite les requêtes planifiées en attente. En augmentant le nombre de nœuds de service, le cluster améliore proportionnellement le débit pour toutes les fonctionnalités de Looker.

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

Avantages

• Un cluster standard optimise les opérations générales avec une configuration minimale de la topologie du cluster.
• La VM Java voit ses performances se dégrader au seuil de 64 Go de mémoire allouée. C'est pourquoi le scaling horizontal est plus intéressant que le scaling vertical.
• Une configuration de cluster garantit la redondance et le basculement des services.

Bonnes pratiques

• Chaque nœud Looker doit être hébergé dans 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 délai d'expiration long (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour un transfert de port de 443 (https) vers 9999 (port sur lequel le serveur Looker écoute).
• Nous vous recommandons d'allouer un espace de stockage de 2 IOPS par Go à votre déploiement.

Dev/Staging/Prod

Pour les cas d'utilisation qui privilégient une disponibilité maximale du contenu pour les utilisateurs finaux, nous vous recommandons d'utiliser des environnements Looker distincts afin de compartimenter le travail de développement et le travail d'analyse. En limitant les modifications de l'environnement de production à des environnements de développement et de test isolés, cette architecture maintient un environnement de production aussi stable que possible.

Pour bénéficier de ces avantages, vous devez configurer les environnements interconnectés et adopter un cycle de publication robuste. Un déploiement de développement/préproduction/production nécessite également une équipe de développeurs maîtrisant l'API Looker et Git pour l'administration des flux de travail.

Le diagramme suivant illustre le flux de contenu entre les développeurs LookML qui développent du contenu sur l'instance de développement, les testeurs de contrôle qualité qui testent le contenu sur l'instance de contrôle qualité, et les utilisateurs, les applications et les scripts qui consomment le contenu sur 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 examinée minutieusement avant d'être diffusée auprès des utilisateurs de production.
• des fonctionnalités à l'échelle de l'instance, Les fonctionnalités Labs ou les protocoles d'authentification peuvent être testés de manière isolée avant d'être activés 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, effectuer des tests, corriger des bugs et commettre des erreurs en toute sécurité.
• Instance de contrôle qualité: également appelé environnement de test ou de préproduction, c'est là que les développeurs exécutent des tests manuels et automatisés. L'environnement de test qualité est complexe et peut consommer beaucoup de ressources.
• Instance de production: c'est là que la valeur est créée pour les clients et/ou l'entreprise. L'environnement de production est très visible et doit être exempt d'erreurs.

• Maintenez une structure documentée et reproductible le workflow du cycle de publication.
• S'il est nécessaire de gérer un grand nombre de développeurs et de testeurs du contrôle qualité, les instances de développement et/ou de contrôle qualité peuvent être mises en cluster. Qu'elles soient laissées en tant que VM autonome ou cluster de VM, les instances de développement et de test sont soumises aux mêmes considérations architecturales que celles présentées dans les sections respectives.

Débit de planification élevé

Pour les cas d'utilisation nécessitant un débit élevé pour la livraison de données planifiée ainsi que des livraisons rapides et fiables, nous vous recommandons d'inclure un cluster avec un pool de nœuds exclusivement dédiés à la planification. Cette configuration permet de maintenir la rapidité et la réactivité des applications Web et intégrées. Pour bénéficier de ces avantages, vous devez configurer des nœuds avec des options de démarrage personnalisées et des règles d'équilibrage de charge appropriées, comme illustré dans le diagramme suivant et décrit dans les sections Avantages et Bonnes pratiques pour cette option.

Avantages

• Dédier des nœuds à une fonction spécifique permet de compartimenter les ressources de planification issues des fonctions de développement et d'analyse ad hoc.
• Les utilisateurs peuvent développer LookML et explorer du contenu sans s'occuper des cycles de la maintenance des envois de données planifiées.
• Le trafic utilisateur élevé acheminé 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é dans 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 délai d'expiration long (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour un transfert de port de 443 (https) vers 9999 (port sur lequel le serveur Looker écoute).
• Omettez les nœuds du 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 choisir un 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 rapports de rendu élevé, nous vous recommandons de configurer un cluster avec un pool de nœuds dédiés uniquement au rendu. L'affichage d'un fichier PDF ou d'une image PNG/JPEG est une opération relativement coûteuse en ressources dans Looker. Le rendu peut nécessiter une utilisation intensive de la mémoire et du processeur, et lorsque Linux est sous pression sur la mémoire, cela peut arrêter un processus en cours d'exécution. Étant donné qu'il est impossible de déterminer à l'avance l'utilisation de la mémoire d'une tâche de rendu, le lancement d'une tâche de rendu peut entraîner l'arrêt du processus Looker. La configuration de nœuds de rendu dédiés permet d'optimiser les tâches de rendu tout en préservant la réactivité de l'application interactive et intégrée.

Ces avantages nécessitent de configurer des 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 suivant et expliqué dans les sections Avantages et Bonnes pratiques pour cette option. De plus, 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 qui partagent le temps CPU et la mémoire.

Avantages

• Dédier des nœuds à une fonction spécifique permet de compartimenter les ressources de rendu issues des fonctions de développement et d'analyse ad hoc.
• Les utilisateurs peuvent développer LookML et explorer du contenu sans impliquer les nœuds chargés d'afficher les fichiers PNG et PDF.
• Le trafic utilisateur élevé acheminé 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é dans 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 délai d'expiration long (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour un transfert de port de 443 (https) vers 9999 (port sur lequel le serveur Looker écoute).
• Omettre les nœuds de rendu des règles d'équilibrage de charge afin qu'ils ne servent pas le trafic des utilisateurs finaux ni les requêtes d'API internes.
• Allouez relativement moins de mémoire à Java dans les nœuds de rendu pour donner aux processus de Chromium un tampon de mémoire plus important. Au lieu d'allouer 60 % de la mémoire à Java, allouez-en 40 à 50 %.
• Le risque de pression sur la mémoire a été réduit sur les nœuds de rendu, ce qui permet d'augmenter la quantité de mémoire dédiée à Looker. Au lieu de 60 %, envisagez un nombre plus élevé, comme 80 %.
• Nous vous recommandons d'allouer un espace de stockage de 2 IOPS par Go à votre déploiement.

Ressource associée

• Solutions d'architecture hébergées par le client : présentation des composants