Multi-location de type silo

Certains environnements SaaS mutualisés peuvent nécessiter le déploiement des données des locataires sur des ressources entièrement séparées pour des raisons de conformité et de réglementation. Dans certains cas, les grands clients ont besoin de clusters dédiés pour réduire l'impact du bruit sur les voisins. Dans ces situations, vous pouvez appliquer le modèle de silo.

Dans le modèle en silo, le stockage des données des locataires est totalement isolé de toutes les autres données des locataires. Toutes les structures utilisées pour représenter les données du locataire sont considérées comme physiquement uniques à ce client, ce qui signifie que chaque locataire bénéficiera généralement d'un stockage, d'une surveillance et d'une gestion distincts. Chaque locataire disposera également d'une clé AWS Key Management Service (AWS KMS) distincte pour le chiffrement. Dans Amazon Neptune, un silo correspond à un cluster par locataire.

Cluster par locataire

Vous pouvez implémenter un modèle de silo avec Neptune en ayant un locataire par cluster. Le schéma suivant montre trois locataires accédant à un microservice d'application dans un cloud privé virtuel (VPC), avec un cluster distinct pour chaque locataire.

Chaque cluster possède son propre point de terminaison afin de garantir des points d'accès distincts pour une interaction et une gestion efficaces des données. En plaçant chaque locataire dans son propre cluster, vous créez une limite bien définie entre les locataires, garantissant aux clients que leurs données sont correctement isolées des données des autres locataires. Cette isolation est également intéressante pour les solutions SaaS soumises à des contraintes réglementaires et de sécurité strictes. De plus, lorsque chaque locataire possède son propre cluster, vous n'avez pas à vous soucier des voisins bruyants, car un locataire impose une charge susceptible de nuire à l'expérience des autres locataires.

Bien que le modèle de cluster-per-tenant silo présente des avantages, il présente également des défis en matière de gestion et d'agilité. La nature distribuée de ce modèle complique l'agrégation et l'évaluation de l'activité des locataires et de la santé opérationnelle de tous les locataires. Le déploiement devient également plus difficile car la configuration d'un nouveau locataire nécessite désormais le provisionnement d'un cluster distinct. La mise à niveau devient plus difficile dans les environnements dotés d'une couche client partagée lorsque les mises à niveau et les versions du client sont étroitement liées à la mise à niveau de la base de données.

Neptune prend en charge les clusters sans serveur et provisionnés. Déterminez si la charge de travail de votre application est mieux gérée par des instances sans serveur ou provisionnées. En général, si le niveau de demande de votre charge de travail est constant, les instances provisionnées seront plus rentables. Le mode Serverless est optimisé pour les charges de travail exigeantes et très variables avec une utilisation intensive des bases de données pendant de courtes périodes, suivies de longues périodes avec une activité légère, voire pas d'activité.

Lorsque vous utilisez un cluster provisionné Neptune par locataire, vous devez sélectionner une taille d'instance qui correspond approximativement à la charge maximale de la demande de votre locataire. Cette dépendance à l'égard d'un serveur a également un impact en cascade sur la scalabilité, l'efficacité et le coût de votre environnement SaaS. Alors que l'un des objectifs du SaaS est de dimensionner dynamiquement en fonction de la charge réelle des locataires, un cluster provisionné par Neptune vous oblige à surapprovisionner pour tenir compte des périodes d'utilisation plus longues et des pics de charge. Le surprovisionnement augmente le coût par locataire. En outre, à mesure que l'utilisation des locataires évolue au fil du temps, l'augmentation ou la réduction du cluster doivent être appliquées séparément pour chaque locataire.

L'équipe Neptune déconseille généralement un modèle en silo en raison des coûts plus élevés liés aux ressources inutilisées et des complexités opérationnelles supplémentaires. Toutefois, si les charges de travail hautement réglementées ou sensibles nécessitent cette isolation supplémentaire, les clients peuvent être disposés à payer le coût supplémentaire.

Guide de mise en œuvre du modèle de silo

Pour implémenter un modèle d' cluster-per-tenant isolation en silo, créez AWS Identity and Access Management (IAM) des politiques d'accès aux données. Ces politiques contrôlent l'accès aux clusters Neptune des locataires en garantissant que les locataires ne peuvent accéder qu'au cluster Neptune contenant leurs propres données. Associez la IAM politique de chaque locataire à un IAM rôle. Le microservice de l'application utilise ensuite le IAM rôle pour générer des informations d'identification temporaires détaillées à l'aide de la AssumeRole méthode de AWS Security Token Service ().AWS STS Ces informations d'identification, qui ont accès uniquement au cluster Neptune pour ce locataire, sont utilisées pour se connecter au cluster Neptune du locataire.

L'extrait de code suivant montre un exemple de politique basée sur les données IAM :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:WriteDataViaQuery"
      ],
      "Resource": "arn:aws:neptune-db:<region>:<account-id>:tenant-1-cluster/*",
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:iam::<account-id>:role/tenant-role-1"
        }      
      }
    }
  ]
}

Le code fournit un exemple de locatairetenant-1, avec un accès aux requêtes en lecture et en écriture à leur cluster Neptune respectif. L'Conditionélément garantit que seule l'entité appelante (le principal), qui a assumé le tentant-1 IAM rôle (tenant-role-1), est autorisée à accéder au tenant-1 cluster Neptune.