Snowflake : bien choisir votre stratégie Multi-tenant

Introduction

Dans le cadre du développement d’applications SaaS modernes, il est fréquent de vouloir proposer une même plateforme logicielle Snowflake à plusieurs organisations distinctes, qu’il s’agisse d’entreprises clientes, de filiales d’un même groupe ou de partenaires. Chacune de ces entités souhaite accéder à ses propres données, bénéficier d’un certain niveau d’isolation, et parfois même personnaliser certaines fonctionnalités. Ce besoin de mutualisation de l’infrastructure tout en garantissant l’isolation des données et la sécurité conduit naturellement à adopter une architecture Snowflake multi-tenant.

Dans ce contexte, il est crucial de choisir la bonne architecture pour répondre aux besoins spécifiques de chaque client tout en optimisant les coûts, la sécurité et la scalabilité. Snowflake propose trois principaux modèles d’architecture pour les applications multi-tenant : Multi-Tenant Table (MTT), Object Per Tenant (OPT) et Account Per Tenant (APT). Ce blog explore ces trois modèles, leurs avantages, inconvénients et les critères de choix.

1. Snowflake Mutli-Tenant Table (MTT)

Concept : Consolidation des tenants dans une table unique.

Le diagramme logique représenté dans la Figure 1 illustre une configuration d’application assez courante :

• Premièrement, les utilisateurs de l’application accèdent aux données des locataires via des vues sécurisées dans une base de données de service (surlignée en rouge).
• Ensuite, une table des droits contrôle quels utilisateurs ou rôles de Snowflake ont accès à quels locataires.
• De plus, les vues sécurisées garantissent que les utilisateurs de l’application ne voient que les lignes de leur locataire.
• Enfin, toutes les tables sont regroupées par une colonne de type tenant_id.

Pour garantir que les utilisateurs ne peuvent voir que les lignes de leur tenant, les tenants interrogent via des vues sécurisées, qui joignent les tables de base à la table des droits sur tenant_id. Les tables communes, où tout le monde peut voir toutes les lignes, utilisent des vues régulières pointées vers les tables de base.

Figure 1 : Une base de données de service avec des vues sécurisées garantit que les utilisateurs de l’application ne voient que les lignes de leur tenant.

• Avantages:
  • Architecture simple.
  • Évolutivité élevée.
  • Coût réduit.
• Inconvénients:
  • Modèle de données rigide.
  • Gestion de la sécurité complexe.

Caractéristiques :

• Modèle de données: Doit suivre la même structure entre les différents clients. Les opérations de MERGE, d’UPDATE et de CLUSTERING automatique peuvent être un défi sur de très grandes tables.
• Gestion des coûts de stockage: Difficile de déterminer les coûts de stockage par tenant dans une table multi-tenant.
• Gestion des coûts de Warehouse: Warehouse dédié par tenant (facile de déterminer le coût par client mais peut augmenter le coût global) ou partagé entre tenants (optimise le coût global mais difficile de déterminer le coût par client).
• Gestion de la sécurité: Nécessite une gestion de sécurité développée (table de référence tenant, Secure views, RBAC (Role-Based Access Control) et RLS (Row-Level Security) poussée) pour isoler l’accès entre les clients. Risque d’erreur élevé.
• Scalabilité: Relativement facile avec peu de nouveaux objets à créer.

2. Snowflake Object Per Tenant (OPT)

Concept : Isolation des tenants dans des objets séparés (tables, schémas ou bases de données).

OPT vous permet d’isoler les données des locataires par base de données, schéma et table, et d’utiliser le RBAC pour contrôler quel utilisateur ou rôle peut voir ou interroger un objet. Séparer les clients dans leurs propres bases de données est la pratique la plus courante (voir Figure 2), car c’est le niveau d’isolation le plus simple et le plus propre.

Figure 2 : Isolement des clients dans leurs propres bases de données est le modèle OPT le plus courant.

• Avantages:
  • Flexibilité du modèle de données.
  • Sécurité renforcée.
• Inconvénients:
  • Évolutivité limitée.
  • Coûts potentiellement plus élevés.

Caractéristiques :

• Modèle de données: Peut-être unique ou similaire pour chaque client.
• Gestion des coûts de stockage: Stockage cloisonné pour chaque client dans des objets distincts (table, schéma, BDD).
• Gestion des coûts de Warehouse: Warehouse dédié par tenant (facile de déterminer le coût par client mais peut augmenter le coût global) ou partagé entre tenants (optimise le coût global mais difficile de déterminer le coût par client).
• Gestion de la sécurité: Gestion moins complexe que MTT, principalement basée sur RBAC.
• Scalabilité: Créer des objets dans Snowflake est facile, mais maintenir un état cohérent entre de nombreux objets similaires est difficile.

3. Snowflake Account Per Tenant (APT)

Concept : Isolation des tenants au niveau des comptes Snowflake.

Avec le modèle APT, il y a généralement un compte Snowflake, un entrepôt et une base de données par tenant.

Figure 3 : Modèle Account Per Tenant (APT)

• Avantages:
  • Sécurité maximale.
  • Isolation stricte.
• Inconvénients:
  • Gestion complexe.
  • Évolutivité limitée.
  • Coûts élevés.

Caractéristiques :

• Modèle de données: Peut-être unique ou similaire pour chaque client.
• Gestion des coûts de stockage: Stockage cloisonné pour chaque client dans des comptes distincts.
• Gestion des coûts de Warehouse: Warehouse dédié par tenant (facile de déterminer le coût par client mais peut augmenter le coût global).
• Gestion de la sécurité: L’option la plus sécurisée pour cloisonner les données de chaque client. Permet de rajouter des options de sécurité au niveau compte pour renforcer davantage l’accès aux données de chaque client (ex : cryptage spécifique par client).
• Scalabilité: Créer des objets dans Snowflake est facile, mais maintenir un état cohérent entre de nombreux objets similaires est difficile.

4. Comparaison détaillée des approches MTT, OPT et APT

Questions pour s’orienter sur la bonne architecture :

Quelle est la nature des données de chaque tenant ?

• Chaque client a des besoins de modélisation de données spécifiques -> OPT
• Les besoins de modélisation de données suivent un modèle standardisé (« Core Model ») pour tous les clients -> MTT

Quel est le niveau de sécurité requis ?

• Besoin d’une sécurité maximale et d’une isolation stricte des données -> APT
• La sécurité est importante mais l’isolation stricte n’est pas nécessaire -> OPT

Combien de clients ?

• Grand nombre de clients avec des besoins de données similaires -> MTT
• Nombre plus restreint de clients avec des besoins de données variés -> OPT ou APT

Quel est votre budget ?

• Les architectures OPT et APT peuvent entraîner des coûts plus élevés en raison de l’isolation des ressources.

Quelles sont vos capacités techniques ?

• La mise en place et la gestion des architectures OPT et APT peuvent nécessiter une expertise technique significative. Si vous avez des ressources techniques limitées, l’architecture MTT peut être plus facile à gérer.

Conclusion

Le choix du bon modèle multi-tenant Snowflake repose sur l’équilibre entre sécurité, flexibilité, coûts et complexité opérationnelle. Il n’existe pas de solution universelle — chaque contexte client mérite une évaluation fine.

Pour aller plus loin : Snowlake Multi Tenant.

Vous aussi devenez expert Snowflake avec nos formations sur mesure : Formation Snowflake Bilink.

Pour nous contacter c’est ici.

The following two tabs change content below.

• Bio
• Derniers articles

Ayoub Arhiate

"Chez Bilink, nous accompagnons nos clients dans la mise en œuvre d’architectures Snowflake adaptées à leurs enjeux métier et réglementaires." Ayoub Arhiate, Senior data cloud engineer

Derniers articles parAyoub Arhiate (voir tous)

• Snowflake : bien choisir votre stratégie Multi-tenant - 27 mai 2025
• Gestion de la température des données avec BW/4HANA - 9 septembre 2022