Méthodes pratiques pour réduire la charge de la DB de production et assurer la sécurité des données avec Redash

Si vous êtes un ingénieur travaillant seul, fatigué d'attendre l'approbation du paiement d'un outil de BI payant et que vous avez décidé de mettre en place vous-même un tableau de bord dans votre pipeline, Redash est l'alternative la plus réaliste. Cependant, il ne faut pas se contenter de visualiser les résultats des requêtes. Les portes de l'enfer s'ouvrent dès qu'une requête d'agrégation lourde paralyse la base de données (DB) de production ou que des informations sensibles sur les clients sont exposées sur un tableau de bord partagé avec l'équipe marketing. Voici un résumé des configurations spécifiques pour garantir une stabilité de niveau entreprise tout en économisant le budget d'infrastructure.

Mise en œuvre du cache de requêtes pour isoler la charge de la DB de production

Il est fréquent dans les startups en phase de démarrage que les requêtes analytiques causent des pannes de service. Il est dangereux d'exécuter à chaque fois des requêtes comportant des jointures complexes sur la DB de production. En utilisant la Query Results Data Source (QRDS) de Redash, vous pouvez physiquement séparer la charge imposée au serveur de production. Le QRDS fonctionne en déplaçant les données sources vers le moteur SQLite interne de Redash pour traitement.

En pratique, même avec une configuration de type AWS t3.medium, l'utilisation du QRDS permet de réduire la charge de la DB de plus de 80 %. Activez d'abord le QRDS dans les paramètres de la source de données. Rédigez une requête d'agrégation lourde, mémorisez son numéro d'ID, puis appelez-la depuis une autre fenêtre de requête sous la forme SELECT * FROM cached_query_123. Cette structure permet de ne consulter la DB de production qu'une seule fois, tandis que les utilisateurs du tableau de bord ne voient que les résultats mis en cache.

Un point de vigilance ici est la gestion des workers d'arrière-plan. Un worker Celery consomme généralement entre 200 Mo et 400 Mo de mémoire lorsqu'il traite les résultats d'une requête. Si le nombre de requêtes en attente sur le chemin /status.json continue d'augmenter, vous devez ajuster le WORKERS_COUNT. Attention, si vous augmentez le nombre de workers alors que la mémoire est insuffisante, l'instance risque de planter.

Prévenir les incidents par la séparation des privilèges et le masquage

Le partage de données est une lame à double tranchant. Lorsque vous accordez des permissions aux équipes marketing ou de planification, vous devez impérativement créer et assigner un groupe "View Only" distinct. La priorité est d'empêcher que ces utilisateurs ne modifient par erreur des requêtes ou ne parcourent la structure des tables.

Pour bloquer les incidents de sécurité à la source, créez un nouveau compte en lecture seule (Read-only) avec uniquement les privilèges SELECT au niveau du moteur de la base de données. Ensuite, définissez des vues (Views) où les informations sensibles comme les e-mails ou les numéros de téléphone sont masquées à l'aide de la fonction SQL CONCAT, par exemple jo**@gm****.com. Connectez Redash uniquement à ces vues. L'analyste obtiendra les chiffres statistiques nécessaires, mais ne pourra jamais voir les données sources originales.

Les attaques externes sont contrées par la configuration Nginx. Il est fondamental de bloquer tout accès en dehors de l'IP fixe de l'entreprise et de la plage VPN interne avec la directive deny all. De plus, l'activation de la variable d'environnement REDASH_DISABLE_PUBLIC_URLS permet d'éviter que des URL publiques ne soient créées à l'insu de l'administrateur, provoquant ainsi des fuites de données vers l'extérieur.

Accélérer la détection des incidents grâce à l'intégration Slack

Un tableau de bord n'a de sens que si quelqu'un le regarde. Cependant, le système doit vous interpeller en premier lorsqu'un indicateur dépasse un seuil critique. En connectant la fonction Redash Alert à un Webhook Slack, les développeurs peuvent intervenir immédiatement en cas de taux d'échec de paiement élevé ou d'erreurs serveur.

En incluant {{ALERT_NAME}} et {{QUERY_RESULT_VALUE}} dans le modèle de message d'alerte, vous pouvez évaluer la gravité de la situation simplement en lisant le message Slack. La mise en place de ce système réduit de plus de moitié le temps nécessaire entre la détection d'une panne et le début du débogage.

Toutefois, si vous envoyez des alertes pour chaque variation, vous finirez par ignorer les messages à cause de la "fatigue des alertes". Utilisez le paramètre Just Once pour que les notifications ne soient envoyées que lorsque l'indicateur franchit le seuil pour la première fois et lorsqu'il revient à la normale. Intégrer une logique de calcul du taux de croissance par rapport à l'heure précédente plutôt qu'une valeur absolue dans la requête permet de ne pas avoir à modifier le seuil à chaque fois que le service se développe.

Conception de paramètres pour un environnement de self-service

Si vous perdez une heure ou deux chaque jour à répondre à de simples demandes d'extraction de données, c'est la preuve que vous n'utilisez pas correctement les paramètres de requête. En insérant une syntaxe telle que {{ date_range }} dans une requête, un widget de sélection de date apparaît en haut du tableau de bord. Permettez aux profils non techniques d'extraire eux-mêmes les données en changeant les périodes.

Pour éviter les erreurs de requête dues à des fautes de frappe, le type "Dropdown List" est recommandé. Pour les données qui changent souvent, comme les listes de produits, connectez une Query Based Dropdown List afin que la liste soit automatiquement mise à jour.

Pour des raisons de sécurité, il est préférable d'éviter les types de saisie de texte libre. Comme ils peuvent servir de vecteur d'attaque par injection SQL, Redash ne les autorise de manière limitée qu'aux administrateurs. Pour les tableaux de bord destinés aux utilisateurs généraux, il est plus sûr de ne placer que des sélecteurs de date ou des listes déroulantes permettant de choisir uniquement des valeurs vérifiées. En créant un tel environnement, le développeur gagne du temps pour se concentrer sur l'implémentation de la logique métier principale.