Auf dieser Seite finden Sie Best Practices zum Erstellen einer mehrmandantenfähigen Architektur zum Hosten von nicht vertrauenswürdigem Code mit Cloud Run. Als Google Cloud Kunde wird ein "Mandant" als einer Ihrer eigenen Kunden definiert und "nicht vertrauenswürdiger Code" ist Code, der von diesen Mandanten bereitgestellt wird, um auf Ihrer Plattform ausgeführt zu werden.
Anwendungsfälle
Zu den Anwendungsfällen für solche Architekturen gehören:
- App-Hosting-Plattformen: Sie stellen eine Plattform bereit, auf der Ihre Kunden ihren Code bereitstellen. Beispiele sind eine Webhostingplattform (Kunden stellen einen Web server) oder eine Functions-as-a-Service-Plattform (Kunden stellen eine Funktion bereit).
- Agent-Hosting-Plattformen: Ihre Kunden verwenden SDKs, um KI-Agents zu erstellen, die auf Ihrer Plattform im Hintergrund ausgeführt werden.
- Plattformen für fein abgestimmte Modelle: Sie bieten die Möglichkeit, KI-Modelle kundenspezifisch anzupassen. Ihre Plattform führt sie dann bei Bedarf mit GPUsaus.
- Benutzerdefinierte Funktionen: Mit Ihrer Software können Kunden benutzerdefinierte Logik mithilfe von Code definieren. Beispielsweise stellen Sie eine Analyse-Engine bereit und möchten Kunden die Möglichkeit geben, benutzerdefinierte Funktionen zu schreiben, oder Sie stellen ein API-Gateway bereit und möchten Kunden die Möglichkeit geben, Anfragen basierend auf ihrer eigenen benutzerdefinierten Logik zu filtern oder zu ändern.
- Erweiterbarkeit von Software-as-a-Service (SaaS): Sie bieten möglicherweise eine SaaS-Lösung an und möchten Kunden die Möglichkeit geben, ihre Funktionen mithilfe von Erweiterungen zu erweitern. Diese Erweiterungen können von Kunden oder Partnern geschrieben werden.
Google Cloud Kunden verwenden Cloud Run in der Produktion erfolgreich für diese Anwendungsfälle.
Herausforderungen von mehrmandantenfähigen Plattformen
Zu den typischen Herausforderungen beim Erstellen einer solchen Architektur gehören:
- Sicherheit: Es ist nicht möglich, bereitgestellten Code zu scannen oder zu bereinigen. Nicht vertrauenswürdiger Code kann schädliche Aktionen oder anfällige Abhängigkeiten enthalten. Wenn nicht vertrauenswürdiger Code nicht ordnungsgemäß isoliert ist, kann er möglicherweise auf sensible Daten anderer Mandanten zugreifen. Das einfache Verpacken des Codes in einem Container ist keine ausreichend starke Sicherheitsgrenze. Der Code muss auch in seinen Möglichkeiten eingeschränkt werden, indem das Prinzip der geringsten Berechtigung angewendet wird.
- Kosteneffizienz: Eine solche Architektur kann teuer werden, wenn für jeden Mandanten feste Kosten für Ihre Plattform anfallen.
- Mandantenverwaltung: Die Verwaltung von Hunderttausenden von Mandanten kann eine Herausforderung sein, insbesondere wenn es um das Löschen von Daten geht.
Vorteile von Cloud Run
Eine auf Cloud Run basierende Architektur bietet eine Lösung für häufige Herausforderungen mit vielen Vorteilen wie Sicherheit, Kosteneffizienz und Mandantenverwaltung.
Sicherheit
Cloud Run bietet die sofort einsatzbereiten Sicherheitsfunktionen, die für diese Architektur relevant sind:
- Compute-Isolation: Cloud Run sorgt für eine strikte Isolation zwischen Container instanzen, unabhängig davon, ob sie zum selben Dienst oder zu verschiedenen Diensten aus verschiedenen Projekten gehören. Weitere Informationen zur Containersicherheit und zu Ausführungsumgebungen finden Sie unter Übersicht über das Sicherheitsdesign.
- Sicherheitsupdates: Automatische Sicherheitsupdates von Basis-Images können aktiviert werden, um das Betriebssystem und die Laufzeit der bereitgestellten Arbeitslasten auf dem neuesten Stand zu halten und zu patchen, ohne dass umfangreiche Neuinstallationen erforderlich sind.
- Netzwerkisolation: Cloud Run stellt nicht nur eine Sandbox für die Container bereit, sondern bietet auch einen mehrmandantenfähigen Netzwerkstack.
- Dienstidentität: Cloud Run-Arbeitslasten können so konfiguriert werden, dass sie dedizierte Identitäten mit eingeschränkten Berechtigungen haben.
Kosteneffizienz
- Skalierung auf null und nutzungsabhängige Bezahlung: Cloud Run-Instanzen werden automatisch auf null skaliert, wenn sie nicht verwendet werden. So werden gehostete Arbeitslasten nur dann in Rechnung gestellt, wenn sie ausgeführt werden müssen. Dies führt zu einer sehr effizienten Ressourcennutzung im Vergleich zu Architekturen, die „Always-on“-VMs verwenden.
- Abrechnung pro Anfrage: Zusätzlich zur Skalierung auf null können Sie von einem noch detaillierteren Abrechnungsmodell profitieren, bei dem nur die Verarbeitung von Anfragen in Rechnung gestellt wird, was für noch mehr Kosteneffizienz sorgt.
- On-Demand und schneller Start: Wenn Cloud Run-Dienste herunterskaliert werden, können sie schnell wieder hochskaliert werden. So wird die Latenz für den Endnutzer der bereitgestellten Anwendung minimiert.
- Automatisierte Kostenkennzeichnung: Alle von Cloud Run gemeldeten Kosten werden gekennzeichnet, So können Sie die Kostenzuordnung und -verfolgung Ihrer Mandanten automatisieren.
- Zusicherungen zur Senkung der Gesamtkosten: Auf Rechnungskontoebene können Sie flexible Rabatte für zugesicherte Nutzung verwenden, um die Ausgaben für die Cloud Run-Nutzung zu optimieren.
Mandantenverwaltung
Da Cloud Run ein On-Demand-Dienst ist, sind die Kosten nicht höher, wenn Sie mehrere Google Cloud Projekte verwenden. So können Sie die Mandantenverwaltung wie unter Projekte organisieren Google Cloud beschrieben durchführen.
Zielarchitektur für mehrmandantenfähige Plattformen
Im Folgenden finden Sie die empfohlene Architektur auf hoher Ebene:
Projekte organisieren Google Cloud
Sie müssen eine Google Cloud Organisation und die Offlineabrechnung einrichten und Ihr Account-Management-Team informieren, dass Sie als Reseller-Konto fungieren. Google Cloud kann mit Ihnen zusammenarbeiten, um sicherzustellen, dass geeignete Kommunikationskanäle für die Missbrauchsbekämpfung eingerichtet werden.
Sie müssen Ordner verwenden, um Ihre Google Cloud Projekte zu organisieren. Insbesondere ist es wichtig, dass Sie die Projekte, in denen Ihr eigener Code ausgeführt wird, von den Projekten trennen, in denen nicht vertrauenswürdiger Code Ihrer Mandanten ausgeführt wird. Sie müssen das Onboarding von Mandanten automatisieren, damit die Erstellung der Projekte und Ressourcen eines Mandanten keine menschliche Interaktion erfordert.
Google empfiehlt, ein Google Cloud Projekt pro Mandant zu verwenden. Es ist auch möglich, mehrere Mandanten im selben Projekt zu hosten. Dies ist jedoch mit zusätzlichen Einschränkungen verbunden:
Ein Mandant pro Google Cloud Projekt (empfohlen)
In dieser Architektur wird jeder Mandant Ihrer Plattform in einem eigenen Google Cloud Projekt gehostet. Das bietet viele Vorteile:
- Einfachere Sicherheit: Das Google Cloud Projekt ist eine strikte Grenze für alle darin enthaltenen Ressourcen. Wenn ein Mandant Zugriff auf mehrere Google Cloud Ressourcen wie mehrere Cloud Run-Dienste und einen Cloud Storage Bucket benötigt, können Sie das Projekt als sicheren Perimeter verwenden.
- Weniger Einschränkungen:
- Die Anzahl der Ressourcen in einem bestimmten Projekt ist begrenzt. Mit Cloud Run können beispielsweise nur 1.000 Dienste pro Region in einem Projekt erstellt werden. Ähnliche Limits gelten für die Anzahl der Dienstkonten und anderer zugehöriger Ressourcen.
- Die Anzahl der Projekte ist selbst ein Kontingent und kann erhöht werden. Für eine Google Cloud Organisation gibt es keine Limits für diese Anzahl. Es gibt ein weiches Limit von 100.000 Projekten pro Rechnungskonto, das durch Kontaktaufnahme mit Google erhöht werden kann. Ihre Organisation kann auch viele Rechnungskonten erstellen und sie in einer „Kontogruppe“ zusammenfassen (derzeit in der privaten Vorschau).
- Einfachere Überwachung und Verwaltung:
- Wenn Sie ein Projekt pro Mandant verwenden, sind die Prozesse zum Löschen von Daten einfacher. Das Löschen von Daten für einen Mandanten beschränkt sich auf das Löschen des entsprechenden Projekts.
- Google Cloud Monitoring und Logging funktionieren projektübergreifend und ermöglichen es Ihnen, Ihre gesamte Flotte zu überwachen.
- Mit Kontingenten auf Projektebene können Sie die Nutzung von Cloud Run-Ressourcen für einen bestimmten Mandanten begrenzen und die Limits möglicherweise an Ihre eigenen Preisstufen anpassen.
- Mit benutzerdefinierten Organisationsrichtlinien können Sie auf alle Projekte eines Ordners bestimmte Einschränkungen anwenden, z. B. verfügbare Regionen oder maximale CPU-/Arbeitsspeicherzuweisung.
Das Erstellen eines Google Cloud Projekts und das Initialisieren von APIs und Ressourcen kann zu Latenz führen. Google empfiehlt, einen Pool mit vorab erstellten Projekten zu verwenden, die Sie bei Bedarf Ihren Mandanten zuweisen.
Mehrere Mandanten pro Google Cloud Projekt (nicht empfohlen)
Es ist möglich, mehrere Mandanten im selben Google Cloud Projekt zu hosten. Google empfiehlt diese Architektur jedoch nicht.
Viele Google Cloud Dienste haben Ressourcenlimits pro Projekt. Cloud Run hat beispielsweise ein nicht anpassbares Limit von 1.000 Cloud Run-Diensten pro Region in einem Projekt. Wenn Sie mehrere Mandanten pro Projekt hosten müssen Sie trotzdem eine Flotte von Google Cloud Projekten verwalten, was die Komplexität der Mandantenverwaltung insgesamt erhöht. Aus Sicherheitssicht Google Cloud sind Projekte als Sicherheitsgrenze konzipiert. Wenn Sie zwei verschiedene Mandanten in demselben Projekt hosten, müssen Sie in Bezug auf die Sicherheit vorsichtiger sein, wenn es um die Sicherheit geht. Beispielsweise durch die Verwendung dedizierter Dienstkonten und detaillierter Berechtigungen.
In vielen Regionen bereitstellen
Aus Gründen der Zuverlässigkeit und Skalierbarkeit empfiehlt Google, Mandanten bereitstellungen auf mehrere Google Cloud Regionen zu verteilen. Jede Mandantenanwendung wird in einer einzelnen Region bereitgestellt. Sie können jedoch für verschiedene Mandanten unterschiedliche Regionen verwenden. Die Auswahl der Region kann zufällig erfolgen oder den Standort des Mandanten berücksichtigen, um die Latenz zu optimieren.
Anfragenrouting und benutzerdefinierte Domains
Wenn Sie die Cloud Run-Dienste Ihres Mandanten für Endnutzer verfügbar machen möchten, müssen Sie Ihre eigene Domain hinzufügen und Ihre eigene Routinglogik verwenden. Beispielsweise, um eine Subdomain dem Google Cloud Projekt zuzuordnen, in dem der Dienst des Mandanten gehostet wird.
Sie können Ihren benutzerdefinierten Routingdienst implementieren. Google empfiehlt jedoch, einen globalen externen Application Load Balancer mit Service Extensions für die Routing logik zu verwenden. Service Extensions können als Plug-ins implementiert werden (wobei die Logik inline mit der Anfragenverarbeitung ausgeführt wird) oder als Callouts (die Routinglogik wird an einen separaten Cloud Run-Dienst delegiert, der eine der Google Cloud's skalierbaren multiregionalen Datenbanken wie Spanneraufrufen kann).
Mit einem Application Load Balancer können Sie auch eine Caching-Ebene hinzufügen, indem Sie Cloud CDN und zusätzlichen DDoS-Schutz (Distributed Denial of Service) für Ihre Plattform mit Cloud Armor nutzen.
Reputation und Missbrauch
Jede Hostingplattform, auf der nicht vertrauenswürdiger Code ausgeführt werden darf, ist anfällig für Missbrauch.
Wir empfehlen, für jede von Ihnen angebotene Reputationsebene ein anderes Cloud-Rechnungskonto zu verwenden. Die Mandanten Ihrer kostenlosen Stufe sollten beispielsweise nicht mit demselben Rechnungskonto verknüpft sein wie Ihre zahlungskräftigen Kunden. Google kann diese Rechnungskonten auf unterschiedlichen Reputationsebenen betrachten.
Wie unter Projekte organisieren Google Cloud beschrieben, sollten Sie Projekte nicht nur nach Rechnungskonten trennen, sondern auch Ordner verwenden, um sie zu organisieren. Google kann Ihnen helfen, Kontingente auf Ordner-Ebene festzulegen, um sicherzustellen, dass alle Ressourcen in einem Ordner nie mehr als ein festgelegtes Maximum verbrauchen. So können Sie die Kosten Ihrer Plattform besser verwalten.
Standardmäßig entfernt Google missbräuchliche Arbeitslasten automatisch gemäß den Google Cloud Nutzungsbedingungen. Google kann auch Ereignisse zur Missbrauchserkennung in Cloud Logging protokollieren, auf die Sie dann reagieren können.