Conseils pour l’utilisation d’Azure Database pour PostgreSQL dans une solution mutualisée

De nombreuses solutions mutualisées sur Azure utilisent le système de gestion de base de données relationnelle open source Azure Database pour PostgreSQL. Cet article décrit les fonctionnalités d’Azure Database pour PostgreSQL qui sont utiles lorsque vous travaillez avec des systèmes multilocataire. L’article contient également des liens vers des conseils et des exemples sur l’utilisation d’Azure Database pour PostgreSQL dans une solution multilocataire.

Options de déploiement

Les options suivantes sont disponibles pour Azure Database pour PostgreSQL et conviennent à une utilisation avec des applications multilocataires :

  • Azure Database pour PostgreSQL est un bon choix pour la plupart des déploiements multilocataire qui ne nécessitent pas la scalabilité élevée que Azure Cosmos DB pour PostgreSQL fournit.

  • Azure Database pour PostgreSQL clusters élastiques fournit une mise à l’échelle horizontale au sein d’un service géré. Il convient aux applications mutualisées qui doivent passer de quelques locataires à un nombre élevé de locataires.

  • Azure Cosmos DB pour PostgreSQL est un service de base de données géré par Azure conçu pour les solutions qui nécessitent un niveau élevé de mise à l’échelle, comme les applications mutualisées. Ce service fait partie de la famille de produits Azure Cosmos DB.

    Important

    Azure Cosmos DB pour PostgreSQL est sur un chemin de mise hors service et n’est plus recommandé pour les nouveaux projets.

Fonctionnalités Azure Database pour PostgreSQL qui prennent en charge la multiténance.

Lorsque vous utilisez Azure Database pour PostgreSQL pour créer une application mutualisée, les fonctionnalités suivantes peuvent améliorer votre solution.

Remarque

Certaines fonctionnalités sont disponibles uniquement dans des options de déploiement spécifiques. Les instructions suivantes décrivent les fonctionnalités disponibles.

Sécurité au niveau des lignes

La sécurité au niveau des lignes est utile pour appliquer l’isolation au niveau du locataire lorsque vous utilisez des tables partagées. Dans PostgreSQL, vous implémentez la sécurité au niveau des lignes en appliquant des stratégies de sécurité de ligne aux tables pour restreindre l’accès aux lignes par locataire.

L’implémentation de la sécurité au niveau des lignes sur une table peut affecter les performances. Vous devrez peut-être créer d’autres index sur des tables sur lesquelles la sécurité au niveau des lignes est activée pour vous assurer que les performances ne sont pas affectées. Lorsque vous utilisez la sécurité au niveau des lignes, il est important d’utiliser des techniques de test des performances pour vérifier que votre charge de travail répond à vos exigences de performances de référence.

Pour plus d’informations sur la sécurité au niveau des lignes, consultez Gestion des accès pour Azure Database pour PostgreSQL.

Contexte de locataire pour la sécurité au niveau des lignes

Les stratégies de sécurité au niveau des lignes nécessitent l’accès à l’identificateur de locataire actuel. Azure Database pour PostgreSQL fournit deux extensions qui aident à gérer le contexte du locataire :

  • session_variable : fournit des variables délimitées à la session que vous pouvez utiliser pour stocker et récupérer l’identificateur de locataire dans une session. Utilisez ces variables dans vos stratégies de sécurité au niveau des lignes.
  • login_hook : exécute une fonction au moment de la connexion. Utilisez cette extension pour définir automatiquement le contexte du locataire lorsqu’une connexion est établie.

Pour plus d’informations, consultez Extensions et versions d’extension pour Azure Database pour PostgreSQL.

Mise à l’échelle horizontale avec partitionnement

Le modèle de partitionnement vous permet de mettre à l’échelle votre charge de travail entre plusieurs bases de données ou serveurs de base de données.

Les solutions qui ont besoin d’un niveau élevé de mise à l’échelle peuvent utiliser Azure Cosmos DB pour PostgreSQL. Ce mode de déploiement permet le partitionnement horizontal des locataires sur plusieurs serveurs ou nœuds. Utilisez des tables distribuées dans des bases de données mutualisées pour vous assurer que toutes les données d’un locataire sont stockées sur le même nœud. Cette approche améliore les performances des requêtes.

Pour plus d’informations, consultez les articles suivants :

Clusters élastiques

Les clusters élastiques sont une fonctionnalité de Azure Database pour PostgreSQL. Ils fournissent des fonctionnalités de mise à l’échelle horizontale au sein d’un seul service managé. Cette option de déploiement utilise la fonctionnalité de table distribuée pour les charges de travail multitenant qui nécessitent des capacités de scale-out.

Dans les solutions mutualisées, les clusters élastiques activent le partitionnement des données client sur plusieurs nœuds. Les clusters élastiques prennent en charge deux modèles de partitionnement :

  • Partitionnement basé sur les lignes : vous pouvez distribuer des tables par ID de locataire pour garantir que les données des locataires soient colocalisées sur des nœuds spécifiques. Cette approche peut améliorer les performances des requêtes spécifiques au locataire, mais nécessite que les requêtes incluent la colonne de distribution.
  • Partitionnement basé sur le schéma : vous pouvez isoler les locataires à l’aide d’un schéma distinct par locataire. Cette approche est idéale pour les éditeurs de logiciels indépendants qui ne peuvent pas subir de modifications de requête pour prendre en charge le partitionnement basé sur les lignes. Le partitionnement basé sur un schéma convient parfaitement aux charges de travail qui ont entre 1 et 10 000 locataires.

Pour plus d’informations, consultez les articles suivants :

Regroupement de connexions

PostgreSQL utilise un modèle basé sur un processus pour les connexions. Avec ce modèle, il est inefficace de maintenir un grand nombre de connexions inactives. Certaines architectures mutualisées nécessitent de nombreuses connexions actives, ce qui affecte négativement les performances du serveur Postgres.

Le regroupement de connexions via PgBouncer est installé par défaut dans Azure Database pour PostgreSQL.

Pour plus d’informations, consultez les articles suivants :

Microsoft Entra Authentification

Azure Database pour PostgreSQL prend en charge l’authentification de connexion à l’aide de Microsoft Entra ID. Cette fonctionnalité permet aux charges de travail d’application dans un environnement multilocataire de s’authentifier auprès de la base de données à l’aide d’un principal de service spécifique au locataire ou d’une identité managée. L’accès à la base de données peut être étendu à un locataire individuel. En combinant l’authentification Microsoft Entra ID avec des stratégies de sécurité au niveau de la ligne, vous pouvez réduire le risque qu'une application accède aux données d'un autre locataire à partir d'une base de données mutualisée.

Pour plus d’informations, consultez les articles suivants :

Informatique confidentielle Azure

Azure Database pour PostgreSQL prend en charge Azure Confidential Computing par le biais d’environnements d’exécution approuvés, qui offrent une protection matérielle pour les données traitées. Cette fonctionnalité protège les données de locataire contre l’accès non autorisé par le système d’exploitation, l’hyperviseur ou d’autres applications.

Pour les solutions mutualisées qui gèrent des données sensibles, l’informatique confidentielle fournit une protection des données au niveau matériel pendant le traitement. Utilisez l’informatique confidentielle lorsque les locataires ont des exigences strictes en matière de protection des données ou de conformité réglementaire, ou lorsque vous devez vous assurer que le fournisseur d’applications ne peut pas accéder aux données du locataire.

Pour plus d’informations, consultez l'informatique confidentielle Azure pour Azure Database pour PostgreSQL.

Chiffrement

Les données stockées dans Azure Database pour PostgreSQL sont chiffrées au repos par défaut à l’aide de clés gérées par Microsoft, mais vous pouvez également utiliser des clés gérées par le client (CMK) pour permettre aux locataires de spécifier leurs propres clés de chiffrement.

Lorsque vous utilisez des clés CMK, vous pouvez fournir vos propres clés de chiffrement stockées dans Azure Key Vault. Dans les environnements multilocataires, cette approche vous permet d’utiliser différentes clés de chiffrement pour différents locataires, même quand leurs données sont stockées dans le même serveur de base de données. Cette fonctionnalité permet également aux locataires de contrôler leurs propres clés de chiffrement. Si un locataire choisit de désactiver son compte, la suppression de la clé associée garantit que ses données ne sont plus accessibles.

Azure Database pour PostgreSQL prend en charge les mises à jour automatiques de la version de clé pour les CMK. Cette fonctionnalité est automatiquement mise à jour vers de nouvelles versions de clés après la rotation dans Key Vault et ne nécessite pas de gestion manuelle des versions de clé. Dans les environnements multilocataires où la conformité réglementaire nécessite une rotation régulière des clés, cette automatisation réduit les tâches opérationnelles manuelles et gère la protection des données sans interruption de service.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

Autres contributeurs :

  • John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques
  • Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
  • Paul Burpo | Ingénieur client principal, Microsoft FastTrack for Azure pour les éditeurs de logiciels indépendants
  • Assaf Fraenkel | Ingénieur senior/Architecte de données, Azure FastTrack pour les éditeurs de logiciels indépendants et les start-ups

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

  • Last updated on