Mehrmandantenfähigkeit im Silo-Modell

In einigen mehrinstanzenfähigen SaaS-Umgebungen müssen die Daten der Mandanten aufgrund von Compliance- und regulatorischen Anforderungen möglicherweise auf vollständig getrennten Ressourcen bereitgestellt werden. In einigen Fällen benötigen Großkunden spezielle Cluster, um die Belastung durch störende Nebengeräusche zu reduzieren. In diesen Situationen können Sie das Silomodell anwenden.

Im Silomodell ist die Speicherung von Mandantendaten vollständig von allen anderen Mandantendaten isoliert. Alle Konstrukte, die zur Darstellung der Mandantendaten verwendet werden, werden als physisch einzigartig für diesen Client betrachtet, was bedeutet, dass jeder Mandant im Allgemeinen über eigene Speicher-, Überwachungs- und Verwaltungsfunktionen verfügt. Jeder Mandant wird außerdem über einen separaten Schlüssel AWS Key Management Service (AWS KMS) für die Verschlüsselung verfügen. In Amazon Neptune ist ein Silo ein Cluster pro Mandant.

Cluster pro Mandant

Sie können ein Silomodell mit Neptune implementieren, indem Sie einen Mandanten pro Cluster haben. Das folgende Diagramm zeigt drei Mandanten, die auf einen Anwendungs-Microservice in einer Virtual Private Cloud (VPC) zugreifen, mit einem separaten Cluster für jeden Mandanten.

Jeder Cluster hat seinen eigenen Endpunkt, um unterschiedliche Zugriffspunkte für eine effiziente Dateninteraktion und -verwaltung zu gewährleisten. Indem Sie jeden Mandanten in einem eigenen Cluster platzieren, schaffen Sie eine klar definierte Grenze zwischen den Mandanten und stellen so sicher, dass die Daten der Kunden erfolgreich von den Daten anderer Mandanten isoliert werden. Diese Isolierung ist auch für SaaS-Lösungen attraktiv, die strengen regulatorischen und sicherheitstechnischen Einschränkungen unterliegen. Wenn jeder Mandant seinen eigenen Cluster hat, müssen Sie sich außerdem keine Gedanken über einen lauten Nachbarn machen, bei dem ein Mandant eine Last auferlegt, die sich negativ auf die Benutzererfahrung anderer Mandanten auswirken könnte.

Das cluster-per-tenant Silomodell hat zwar Vorteile, bringt aber auch Herausforderungen in Bezug auf Management und Agilität mit sich. Aufgrund des dezentralen Charakters dieses Modells ist es schwieriger, die Aktivitäten der Mieter und den Betriebsstatus aller Mieter zu aggregieren und zu bewerten. Die Bereitstellung wird auch schwieriger, da für die Einrichtung eines neuen Mandanten jetzt ein separater Cluster bereitgestellt werden muss. Upgrades werden in Umgebungen mit einer gemeinsamen Client-Ebene schwieriger, wenn Client-Upgrades und Versionen eng mit dem Datenbank-Upgrade verknüpft sind.

Neptune unterstützt sowohl serverlose als auch bereitgestellte Cluster. Beurteilen Sie, ob Ihre Anwendungslast besser durch serverlose oder bereitgestellte Instanzen bewältigt werden kann. Generell gilt: Wenn Ihr Workload einen konstanten Bedarf hat, sind bereitgestellte Instanzen kostengünstiger. Serverless ist für anspruchsvolle, sehr variable Workloads mit starker Datenbanknutzung für kurze Zeiträume optimiert, gefolgt von langen Zeiträumen mit geringer oder keiner Aktivität.

Wenn Sie einen von Neptune bereitgestellten Cluster pro Mandant verwenden, müssen Sie eine Instanzgröße wählen, die der maximalen Belastung entspricht, die Ihr Mandant benötigt. Diese Abhängigkeit von einem Server hat auch kaskadierende Auswirkungen auf die Skalierungseffizienz und die Kosten Ihrer SaaS-Umgebung. Während ein Ziel von SaaS darin besteht, die Größe dynamisch auf der Grundlage der tatsächlichen Mandantenlast zu skalieren, erfordert ein von Neptune bereitgestellter Cluster eine Überprovisionierung, um stärkere Nutzungsperioden und Lastspitzen zu berücksichtigen. Eine übermäßige Bereitstellung erhöht die Kosten pro Mandant. Da sich die Nutzung der Mandanten im Laufe der Zeit ändert, muss das Hoch- oder Herunterskalieren des Clusters außerdem für jeden Mandanten separat angewendet werden.

Das Neptune-Team rät generell von einem Silomodell ab, da ungenutzte Ressourcen höhere Kosten verursachen und zusätzliche betriebliche Komplexität entsteht. Bei stark regulierten oder sensiblen Workloads, die diese zusätzliche Isolierung erfordern, sind Kunden jedoch möglicherweise bereit, die zusätzlichen Kosten zu tragen.

Anleitung zur Implementierung des Silo-Modells

Um ein cluster-per-tenant Silo-Isolationsmodell zu implementieren, erstellen Sie AWS Identity and Access Management (IAM-) Datenzugriffsrichtlinien. Diese Richtlinien kontrollieren den Zugriff auf die Neptun-Cluster der Mandanten, indem sie sicherstellen, dass Mandanten nur auf den Neptun-Cluster zugreifen können, der ihre eigenen Daten enthält. Ordnen Sie die IAM-Richtlinie für jeden Mandanten einer IAM-Rolle zu. Der Anwendungs-Microservice verwendet dann die IAM-Rolle, um mithilfe der Methode () detaillierte temporäre Anmeldeinformationen zu generieren. AssumeRole AWS Security Token Service AWS STS Diese Anmeldeinformationen, die nur Zugriff auf den Neptune-Cluster für diesen Mandanten haben, werden verwendet, um eine Verbindung zum Neptune-Cluster des Mandanten herzustellen.

Der folgende Codeausschnitt zeigt ein Beispiel für eine datenbasierte IAM-Richtlinie:

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

Der Code bietet einem Beispielmandanten,tenant-1, Lese- und Schreibabfragezugriff auf seinen jeweiligen Neptun-Cluster. Das Condition Element stellt sicher, dass nur die aufrufende Entität (der Principal), die die tentant-1 IAM-Rolle (tenant-role-1) übernommen hat, auf den tenant-1 Neptune-Cluster zugreifen darf.