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

Cette page présente les modèles d'architecture les plus courants pour un déploiement hébergé par le client et décrit les bonnes pratiques à suivre pour les implémenter. Pour utiliser efficacement cette page, 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. Listez 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. 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 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

Vous pouvez par exemple exécuter Looker en tant qu'instance unique dans une machine virtuelle (VM) dédiée. Une seule instance peut gérer des charges de travail exigeantes en étendant verticalement 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 de petite à moyenne envergure. Le schéma suivant illustre les configurations par défaut et facultatives entre une instance Looker exécutée dans 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 démarre 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 doit être validé par le service de licence Looker. Le trafic sortant sur le port 443 est obligatoire.
• Un déploiement de VM dédié peut être mis à l'échelle verticalement en augmentant les ressources disponibles et les pools de threads Looker. Toutefois, l'augmentation de la RAM est soumise à la loi des rendements décroissants une fois qu'elle atteint 64 Go, car les événements de récupération des déchets sont à un seul thread et arrêtent tous les autres threads à exécuter. Les nœuds avec 16 processeurs et 64 Go de RAM offrent un bon équilibre 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 permet d'augmenter le débit sans avoir à faire face à un gonflement de la mémoire tampon ni à des coûts de collecte des déchets excessifs. Les nœuds peuvent être dédiés à une charge de travail, ce qui permet d'adapter plusieurs options de déploiement à différentes exigences métier. 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 la file d'attente des requêtes planifiées. 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 diagramme suivant montre comment les requêtes envoyées à Looker par l'utilisateur, les applications et les scripts sont réparties sur une instance Looker en cluster.

Avantages

• Un cluster standard maximise la bande passante globale avec une configuration minimale de la topologie du cluster.
• Les performances de la VM Java se dégradent lorsque la mémoire allouée atteint 64 Go. 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 avant expiration long (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour transférer le port 443 (https) vers le port 9999 (port sur lequel le serveur Looker écoute).
• Nous vous recommandons de choisir un stockage avec 2 IOPS par Go pour votre déploiement.

Dev/Staging/Prod

Pour les cas d'utilisation qui donnent la priorité à la disponibilité maximale du contenu pour les utilisateurs finaux, nous vous recommandons de séparer les environnements Looker 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 en développement/préproduction/production nécessite également une équipe de développeurs familiarisés avec l'API Looker et Git pour l'administration des workflows.

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.
• Les fonctionnalités à l'échelle de l'instance, telles que les fonctionnalités 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 vous laisse suffisamment de temps pour tester les nouvelles fonctionnalités, les modifications de workflow et les problèmes avant de mettre à jour l'environnement de production.

Bonnes pratiques

• Identifiez les différentes activités qui se déroulent 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ée environnement de test ou environnement 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.

• Gérez un workflow de cycle de publication documenté et reproductible.
• Si vous devez servir un grand nombre de développeurs et de testeurs d'assurance qualité, vous pouvez regrouper les instances de développement et/ou d'assurance qualité. 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 de diffusion de données planifié élevé et des diffusions ponctuelles et fiables, nous vous recommandons de configurer un cluster avec un pool de nœuds dédiés uniquement à 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 de cette option.

Avantages

• Dédier des nœuds à une fonction spécifique permet de compartimenter les ressources de planification des fonctions de développement et d'analyse ponctuelle.
• Les utilisateurs peuvent développer du code LookML et explorer du contenu sans utiliser de cycles des nœuds chargés de gérer les envois de données planifiés.
• 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 avant expiration long (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour transférer le port 443 (https) vers le port 9999 (port sur lequel le serveur Looker écoute).
• Omettre les nœuds de planification des règles d'équilibrage de charge afin qu'ils ne servent pas le trafic des utilisateurs finaux et les requêtes d'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 utiliser beaucoup de mémoire et de processeur. Lorsque Linux est soumis à une pression de mémoire, il peut interrompre 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.

Pour profiter 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 expliqué dans les sections Avantages et Bonnes pratiques de 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 des fonctions de développement et d'analyse ponctuelle.
• Les utilisateurs peuvent développer du code LookML et explorer du contenu sans utiliser de cycles sur les nœuds chargés d'afficher des 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 avant expiration long (3 600 secondes), être équipé d'un certificat SSL signé et être configuré pour transférer le port 443 (https) vers le port 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.
• Allouer relativement moins de mémoire à Java dans les nœuds de rendu pour fournir 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. La quantité de mémoire dédiée à Looker peut donc être augmentée. Au lieu de 60%, envisagez un nombre plus élevé, comme 80%.
• Nous vous recommandons de choisir un stockage avec 2 IOPS par Go pour votre déploiement.

Ressource associée

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