Google Cloud-Architektur-Framework

Last reviewed 2023-11-09 UTC

Sie können diese Seite drucken oder die Seite im PDF-Format mit der Druckfunktion Ihres Browsers speichern und die Option Speichern unter PDF-Option wählen. Kehren Sie für die Standardversion dieser Seite zum Architektur-Framework zurück.

Das Google Cloud Architektur-Framework bietet Empfehlungen und beschreibt Best Practices, mit denen Architekten, Entwickler, Administratoren und andere Cloud-Experten eine Cloud-Topologie entwerfen und betreiben können, die sicher, effizient, stabil, leistungsstark und kostengünstig ist. Das Google Cloud-Architektur-Framework ist unsere Version eines gut strukturierten Frameworks.

Ein funktionsübergreifendes Team von Experten überprüft die Empfehlungen und Best Practices des Architektur-Frameworks. Das Team stellt das Architektur-Framework so zusammen, dass die zunehmenden Funktionen von Google Cloud, Best Practices der Branche, Community-Wissen und Feedback von Ihnen widergespiegelt werden. Eine Zusammenfassung der wichtigsten Änderungen finden Sie unter Das ist neu.

Die Designanleitung im Architektur-Framework gilt für Anwendungen, die für die Cloud entwickelt wurden, und für Arbeitslasten, die von lokalen Umgebungen zu Google Cloud migriert werden, Hybrid-Cloud-Bereitstellungen und Multi-Cloud-Umgebungen.

Das Google Cloud Architektur-Framework ist in sechs Kategorien unterteilt (auch als Säulen bezeichnet), wie im folgenden Diagramm dargestellt:

Systemdesign

Diese Kategorie ist die Grundlage des Google Cloud-Architektur-Frameworks. Definieren Sie die Architektur, Komponenten, Module, Schnittstellen und Daten, die zum Erfüllen der Cloud-Systemanforderungen erforderlich sind. Informieren Sie sich außerdem über Google Cloud-Produkte und -Features, die das Systemdesign unterstützen.

Operative Exzellenz

Cloud-Arbeitslasten effizient bereitstellen, betreiben, überwachen und verwalten.

Sicherheit, Datenschutz und Compliance

Maximieren Sie die Sicherheit Ihrer Daten und Arbeitslasten in der Cloud, entwickeln Sie sie für den Datenschutz und passen Sie sie an rechtliche Bestimmungen und Standards an.

Zuverlässigkeit

Entwickeln und betreiben Sie stabile und hochverfügbare Arbeitslasten in der Cloud.

Kostenoptimierung

Maximieren Sie den Wert Ihrer Investition in Google Cloud.

Leistungsoptimierung

Erstellen und optimieren Sie Ihre Cloud-Ressourcen für eine optimale Leistung.

Zusammenfassungen von Google Cloud-Produkten und ihrer Beziehung zueinander finden Sie unter Google Cloud-Produkte, -Features und -Dienste in vier Wörtern oder weniger.

Google Cloud-Architektur-Framework: Systemdesign

Das Systemdesign ist die grundlegende Kategorie des Google Cloud-Architektur-Frameworks. Diese Kategorie bietet Designempfehlungen und beschreibt Best Practices und Prinzipien, mit denen Sie die Architektur, Komponenten, Module, Schnittstellen und Daten auf einer Cloud-Plattform definieren können, um Ihre Systemanforderungen zu erfüllen. Außerdem erfahren Sie mehr über Google Cloud-Produkte und -Features, die das Systemdesign unterstützen.

In den Dokumenten der Kategorie "Systemdesign" wird davon ausgegangen, dass Sie die grundlegenden Grundsätze für das Systemdesign kennen. Dabei wird nicht davon ausgegangen, dass Sie mit Cloud-Konzepten und Google Cloud-Produkten vertraut sind.

Für komplexe Cloud-Migrations- und Bereitstellungsszenarien empfehlen wir die Verwendung von Google Cloud-Beratungsdiensten. Unsere Berater haben Fachkenntnisse zu Best Practices und Leitlinien, die Sie auf Ihrem Weg in die Cloud unterstützen. Google Cloud bietet außerdem ein umfassendes Netzwerk aus Partnern – von weltweit führenden Systemintegratoren bis hin zu Partnern mit Know-how in einem bestimmten Bereich, wie z. B. maschinelles Lernen. Wir empfehlen Ihnen, sich an Google Cloud-Partner zu wenden, um die digitale Transformation zu beschleunigen und die Geschäftsergebnisse zu verbessern.

Hinweis: Bevor Sie Ihre Produktionsumgebung ändern, empfehlen wir, mit neuen Features oder einem Design in einer Sandbox-Umgebung zu experimentieren.

In der Kategorie zum Systemdesign des Architektur-Frameworks lernen Sie Folgendes:

• Kernprinzipien des Systemdesigns anwenden.
• Geografische Regionen zur Unterstützung Ihrer Geschäftsanwendungen auswählen.
• Cloud-Ressourcen verwalten.
• Computing auswählen und verwalten.
• Netzwerkinfrastruktur entwerfen.
• Speicherstrategie auswählen und implementieren.
• Datenbank optimieren.
• Daten analysieren.
• Maschinelles Lernen implementieren.
• Entwickeln Sie Ihre Cloud-Arbeitslasten für mehr Nachhaltigkeit.

Grundprinzipien des Systemdesigns

In diesem Dokument im Google Cloud-Architektur-Framework werden die Grundprinzipien des Systemdesigns beschrieben. Ein robustes Systemdesign ist sicher, zuverlässig, skalierbar und unabhängig. Sie können iterative und umkehrbare Änderungen vornehmen, ohne das System zu stören, potenzielle Risiken zu minimieren und die betriebliche Effizienz zu verbessern. Damit Sie ein robustes Systemdesign erreichen können, sollten Sie vier Grundprinzipien folgen.

Alles dokumentieren

Wenn Sie mit dem Verschieben Ihrer Arbeitslasten in die Cloud oder mit dem Erstellen Ihrer Anwendungen beginnen, ist das Fehlen einer Dokumentation des Systems ein Hauptblock. Die Dokumentation ist besonders wichtig, um die Architektur Ihrer aktuellen Bereitstellungen korrekt zu visualisieren.

Eine ordnungsgemäß dokumentierte Cloud-Architektur legt eine gemeinsame Sprache und Standards fest, die es funktionsübergreifenden Teams ermöglichen, effektiv zu kommunizieren und zusammenzuarbeiten. Außerdem finden Sie hier die Informationen, die zur Ermittlung und Steuerung zukünftiger Designentscheidungen erforderlich sind. Die Dokumentation sollte unter Berücksichtigung Ihrer Anwendungsfälle geschrieben werden, um Kontext für die Designentscheidungen zu bieten.

Im Laufe der Zeit werden sich Ihre Designentscheidungen weiterentwickeln und ändern. Der Änderungsverlauf liefert die Kontextinformationen, die Ihre Teams benötigen, um Initiativen abzustimmen, Duplikate zu vermeiden und Leistungsänderungen im Zeitverlauf effektiv zu messen. Änderungslogs sind besonders nützlich, wenn Sie einen neuen Cloud-Architekten einrichten, der mit Ihrem aktuellen Systemdesign, Ihrer Strategie oder Ihrem Verlauf noch nicht vertraut ist.

Design vereinfachen und vollständig verwaltete Dienste nutzen

Einfachheit ist für das Systemdesign von entscheidender Bedeutung. Wenn Ihre Architektur zu komplex ist, um sie zu verstehen, ist es schwierig, das Design zu implementieren und im Laufe der Zeit zu verwalten. Verwenden Sie nach Möglichkeit vollständig verwaltete Dienste, um die Risiken, den Zeit- und Arbeitsaufwand für die Verwaltung und Wartung von Basissystemen zu minimieren.

Wenn Sie Ihre Arbeitslasten bereits in der Produktion laufen lassen, sollten Sie mit verwalteten Diensten testen, wie sie Ihnen helfen können, die betriebliche Komplexität zu verringern. Wenn Sie neue Arbeitslasten entwickeln, fangen Sie einfach an, erstellen Sie ein minimales Viable Product (MVP) und widerstehen Sie dem Drang zum Over-Engineering. Sie können außergewöhnliche Anwendungsfälle identifizieren, Ihre Systeme iterieren und im Laufe der Zeit verbessern.

Architektur entkoppeln

Entkoppeln ist eine Technik, die zum Trennen Ihrer Anwendungen und Dienstkomponenten in kleinere Komponenten verwendet wird, die unabhängig voneinander ausgeführt werden können. Sie können beispielsweise ein monolithisches Anwendungspaket in separate Dienstkomponenten aufteilen. In einer entkoppelten Architektur kann eine Anwendung ihre Funktionen unabhängig von den verschiedenen Abhängigkeiten ausführen.

Eine entkoppelte Architektur bietet Ihnen mehr Flexibilität bei den folgenden Aufgaben:

• Unabhängige Upgrades anwenden.
• Bestimmte Sicherheitskontrollen durchsetzen.
• Zuverlässigkeitsziele für jedes Subsystem festlegen.
• Zustand überwachen.
• Granulare Leistung und Kostenparameter steuern.

Sie können bereits früh in Ihrer Designphase entkoppeln oder sie als Teil Ihrer Systemupgrades integrieren, wenn Sie skalieren.

Zustandslose Architektur verwenden

Eine zustandslose Architektur kann sowohl die Zuverlässigkeit als auch die Skalierbarkeit Ihrer Anwendungen erhöhen.

Zustandsorientierte Anwendungen benötigen verschiedene Abhängigkeiten, um Aufgaben wie lokal zwischengespeicherte Daten auszuführen. Zustandsorientierte Anwendungen erfordern oft zusätzliche Mechanismen, um den Fortschritt zu erfassen und ordnungsgemäß neu zu starten. Zustandslose Anwendungen können Aufgaben ohne signifikante lokale Abhängigkeiten ausführen, indem sie freigegebenen Speicher oder im Cache gespeicherte Dienste verwenden. Eine zustandslose Architektur ermöglicht es Ihnen, Anwendungen mit minimalen Boot-Abhängigkeiten schnell zu skalieren. Die Anwendungen können soliden Neustarts standhalten, eine geringere Ausfallzeit aufweisen und eine bessere Leistung für Endnutzer bieten.

In der Kategorie "Systemdesign" werden Empfehlungen beschrieben, mit denen Sie Ihre Anwendungen zustandslos machen oder cloudnative Features verwenden können, um den Erfassungsstatus der Maschinen für Ihre zustandsorientierten Anwendungen zu verbessern.

Nächste Schritte

• Geografische Regionen zur Unterstützung Ihrer Geschäftsanwendungen auswählen.
• Cloud-Ressourcen verwalten.
• Computing auswählen und verwalten.
• Netzwerkinfrastruktur entwerfen.
• Speicherstrategie auswählen und implementieren.
• Datenbank optimieren.
• Daten analysieren.
• Maschinelles Lernen implementieren.
• Entwickeln Sie Ihre Cloud-Arbeitslasten für mehr Nachhaltigkeit.

Google Cloud-Bereitstellungs-Archetypen auswählen

In diesem Dokument im Google Cloud-Architektur-Framework werden sechs Bereitstellungsarchetypen¹ – zonal, regional, multiregional, global, Hybrid und Multi-Cloud – beschrieben. Sie können mit ihnen Architekturen für Ihre Cloud-Arbeitslasten basierend auf Ihren Anforderungen an Verfügbarkeit, Kosten, Leistung und betriebliche Effizienz erstellen.

Was ist ein Bereitstellungs-Archetyp?

Ein Bereitstellungs-Archetyp ist ein abstraktes, anbieterunabhängiges Modell, das Sie als Grundlage für die Erstellung anwendungsspezifischer Bereitstellungsarchitekturen verwenden, die Ihre geschäftlichen und technischen Anforderungen erfüllen. Jeder Bereitstellungs-Archetyp gibt eine Kombination aus fehlerhaften Domains an, in denen eine Anwendung ausgeführt werden kann. Diese fehlerhaften Domains können eine oder mehrere Google Cloud-Zonen oder -Regionen und sogar Ihre lokalen Rechenzentren oder fehlerhaften Domains bei anderen Cloud-Anbietern umfassen.

Das folgende Diagramm zeigt sechs in Google Cloud bereitgestellte Anwendungen. Jede Anwendung verwendet einen Bereitstellungs-Archetyp, der die spezifischen Anforderungen erfüllt.

Wie das obige Diagramm zeigt, basiert die Cloud-Topologie in einer Architektur mit dem Archetyp für hybride oder Multi-Cloud-Bereitstellungen auf einem der grundlegenden Archetypen: zonal, regional, multiregional oder global. In diesem Sinne können die Archetypen für hybride und Multi-Cloud-Bereitstellungen als zusammengesetzte Archetypen betrachtet werden, die einen der grundlegenden Archetypen enthalten.

Hinweis: Die Bereitstellungs-Archetypen unterscheiden sich von den Standortbereichen. Der Standortbereich einer Google Cloud-Ressource definiert ihre Verfügbarkeitsgrenze. Der Standortbereich einer Compute Engine-VM ist beispielsweise zonal. Das bedeutet, dass die Verfügbarkeit der VM beeinträchtigt ist, wenn die Google Cloud-Zone, in der eine VM bereitgestellt wird, ausfällt. Wenn Sie VMs jedoch auf mehrere Zonen verteilen, können Sie eine hochverfügbare Architektur erstellen, die auf dem Archetyp für regionale Bereitstellungen basiert.

Die Auswahl eines Bereitstellungs-Archetyps vereinfacht nachfolgende Entscheidungen in Bezug auf zu verwendende Google Cloud-Produkte und -Features. Wenn Sie beispielsweise bei einer hochverfügbaren containerisierten Anwendung den Archetyp für regionale Bereitstellungen auswählen, sind regionale GKE-Cluster (Google Kubernetes Engine) besser geeignet als zonale GKE-Cluster.

Wenn Sie einen Bereitstellungs-Archetyp für eine Anwendung auswählen, müssen Sie Kompromisse zwischen Faktoren wie Verfügbarkeit, Kosten und operative Komplexität berücksichtigen. Wenn eine Anwendung beispielsweise Nutzer in mehreren Ländern bedient und Hochverfügbarkeit benötigt, wählen Sie den Archetyp für multiregionale Bereitstellungen. Bei einer internen Anwendung, die von Mitarbeitern in einer einzelnen geografischen Region verwendet wird, priorisieren Sie jedoch möglicherweise die Kosten gegenüber der Verfügbarkeit und wählen daher den Archetyp für regionale Bereitstellungen.

Übersicht über Bereitstellungs-Archetypen

Die folgenden Tabs enthalten Definitionen der Bereitstellungs-Archetypen und eine Zusammenfassung der Anwendungsfälle sowie Designaspekte.

Zonal

Ihre Anwendung wird in einer einzelnen Google Cloud-Zone ausgeführt, wie im folgenden Diagramm dargestellt:

Anwendungsfälle	Entwicklungs- und Testumgebungen. Anwendungen, die keine Hochverfügbarkeit erfordern. Netzwerk mit niedriger Latenz zwischen Anwendungskomponenten. Standardarbeitslasten migrieren. Anwendungen, die Software mit Lizenzbeschränkung verwenden.
Designaspekte	Ausfallzeiten bei zonalen Ausfällen. Um Geschäftskontinuität zu erzielen, können Sie ein passives Replikat der Anwendung in einer anderen Zone in derselben Region bereitstellen. Wenn ein zonaler Ausfall auftritt, können Sie die Anwendung mit dem passiven Replikat in der Produktion wiederherstellen.
Weitere Informationen	Weitere Informationen finden Sie in den folgenden Abschnitten: Archetyp für zonale Bereitstellungen Vergleichsanalyse aller Bereitstellungs-Archetypen

Regional

Ihre Anwendung wird unabhängig in zwei oder mehr Zonen innerhalb einer einzelnen Google Cloud-Region ausgeführt, wie im folgenden Diagramm dargestellt:

Anwendungsfälle	Hochverfügbare Anwendungen für Nutzer in einem geografischen Gebiet Einhaltung der Anforderungen hinsichtlich Datenstandort und Datenhoheit
Designaspekte	Ausfallzeiten bei regionalen Ausfällen. Um Geschäftskontinuität zu erzielen, können Sie die Anwendung und Daten in einer anderen Region sichern. Wenn ein regionaler Ausfall auftritt, können Sie die Sicherungen in der anderen Region verwenden, um die Anwendung in der Produktion wiederherzustellen. Kosten und Aufwand für die Bereitstellung und Verwaltung redundanter Ressourcen.
Weitere Informationen	Weitere Informationen finden Sie in den folgenden Abschnitten: Archetyp für regionale Bereitstellungen Vergleichsanalyse aller Bereitstellungs-Archetypen

Multiregional

Ihre Anwendung wird unabhängig in mehreren Zonen in zwei oder mehr Google Cloud-Regionen ausgeführt. Sie können DNS-Routingrichtlinien verwenden, um eingehenden Traffic an die regionalen Load Balancer weiterzuleiten. Die regionalen Load Balancer verteilen den Traffic dann auf die zonalen Replikate der Anwendung, wie im folgenden Diagramm dargestellt:

Anwendungsfälle	Hochverfügbare Anwendung mit geografisch verteilten Nutzern Anwendungen, die eine niedrige Latenz beim Endnutzer erfordern. Einhaltung der Anforderungen hinsichtlich Datenstandort und Datenhoheit mit einer Geofencing-DNS-Routingrichtlinie.
Designaspekte	Kosten für die regionenübergreifende Datenübertragung und Datenreplikation. Operative Komplexität.
Weitere Informationen	Weitere Informationen finden Sie in den folgenden Abschnitten: Archetyp für multiregionale Bereitstellungen Vergleichsanalyse aller Bereitstellungs-Archetypen

Global

Ihre Anwendung wird weltweit in Google Cloud-Regionen ausgeführt, entweder als global verteiltes (standortunabhängiges) Paket oder als regional isolierte Pakete. Ein globaler Anycast-Load-Balancer verteilt den Traffic auf die Region, die dem Nutzer am nächsten ist. Andere Komponenten des Anwendungspakets können ebenfalls global sein, wie z. B. die Datenbank, der Cache und der Objektspeicher.

Das folgende Diagramm zeigt die global verteilte Variante des Archetyps für globale Bereitstellungen. Ein globaler Anycast-Load-Balancer leitet Anfragen an ein Anwendungspaket weiter, das auf mehrere Regionen verteilt ist und eine global replizierte Datenbank verwendet.

Das folgende Diagramm zeigt eine Variante des Archetyps für globale Bereitstellungen mit regional isolierten Anwendungspaketen. Ein globaler Anycast-Load-Balancer leitet Anfragen an ein Anwendungspaket in einer der Regionen weiter. Alle Anwendungspakete verwenden eine einzige global replizierte Datenbank.

Anwendungsfälle	Hochverfügbare Anwendungen für global verteilte Nutzer. Sie können die Kosten optimieren und Vorgänge vereinfachen, indem Sie globale Ressourcen anstelle mehrerer Instanzen regionaler Ressourcen verwenden.
Designaspekte	Kosten für die regionenübergreifende Datenübertragung und Datenreplikation.
Weitere Informationen	Weitere Informationen finden Sie in den folgenden Abschnitten: Archetyp für globale Bereitstellungen Vergleichsanalyse aller Bereitstellungs-Archetypen

Hybrid

Bestimmte Teile Ihrer Anwendung werden in Google Cloud bereitgestellt, während andere lokal ausgeführt werden. Dies ist im folgenden Diagramm dargestellt. Die Topologie in Google Cloud kann den Archetyp für zonale, regionale, multiregionale oder globale Bereitstellungen verwenden.

Anwendungsfälle	Standort für die Notfallwiederherstellung (Disaster Recovery, DR) für lokale Arbeitslasten. Lokale Entwicklung für Cloud-Anwendungen. Schrittweise Migration zur Cloud für Legacy-Anwendungen. Lokale Anwendungen mit Cloud-Funktionen optimieren.
Designaspekte	Einrichtung und operative Komplexität festlegen. Kosten für redundante Ressourcen.
Weitere Informationen	Weitere Informationen finden Sie in den folgenden Abschnitten: Archetyp für Hybridbereitstellungen Vergleichsanalyse aller Bereitstellungs-Archetypen

Multi-Cloud

Einige Teile Ihrer Anwendung werden in Google Cloud und andere auf anderen Cloud-Plattformen bereitgestellt, wie im folgenden Diagramm dargestellt. Die Topologie auf jeder Cloud-Plattform kann den Archetyp für zonale, regionale, multiregionale oder globale Bereitstellungen verwenden.

Anwendungsfälle	Google Cloud als primärer Standort und eine weitere Cloud als DR-Standort. Anwendungen mit erweiterten Google Cloud-Funktionen optimieren
Designaspekte	Einrichtung und operative Komplexität festlegen. Kosten für redundante Ressourcen und cloudübergreifenden Netzwerktraffic.
Weitere Informationen	Weitere Informationen finden Sie in den folgenden Abschnitten: Archetyp für Multi-Cloud-Bereitstellungen Vergleichsanalyse aller Bereitstellungs-Archetypen

Geografische Zonen und Regionen auswählen

Dieses Dokument des Google Cloud-Architektur-Frameworks enthält Best Practices zur Bereitstellung Ihres Systems basierend auf den geografischen Anforderungen. Sie erfahren, wie Sie optimale geografische Zonen und Regionen anhand von Verfügbarkeit und Nähe auswählen, um für Compliance zu sorgen, Kosten zu optimieren und Load-Balancing zu implementieren.

Wenn Sie eine Region oder mehrere Regionen für Ihre Geschäftsanwendungen auswählen, berücksichtigen Sie Kriterien wie Dienstverfügbarkeit, Endnutzerlatenz, Anwendungslatenz, Kosten sowie rechtliche oder Nachhaltigkeitsanforderungen. Wägen Sie diese Anforderungen ab und ermitteln Sie die besten Kompromisse, um Ihre Geschäftsprioritäten und -richtlinien zu unterstützen. Beispielsweise ist die Region, die die Konformität erfüllt, möglicherweise nicht die kostengünstigste Region oder die geringste CO2-Bilanz.

In mehreren Regionen bereitstellen

Regionen sind unabhängige geografische Gebiete, die aus mehreren Zonen bestehen. Eine Zone ist ein Bereitstellungsbereich für Google Cloud-Ressourcen innerhalb einer Region. Jede Zone steht für eine einzelne fehlerhafte Domain innerhalb einer Region.

Zum Schutz vor erwarteten Ausfallzeiten (einschließlich Wartung) und zum Schutz vor unerwarteten Ausfallzeiten wie Vorfällen empfehlen wir, fehlertolerante Anwendungen mit Hochverfügbarkeit bereitzustellen und Ihre Anwendungen über mehrere Zonen in einer oder mehreren Regionen bereitzustellen. Weitere Informationen finden Sie unter Geografie und Regionen, Überlegungen zur Anwendungsbereitstellung und Best Practices für die Auswahl der Region in Compute Engine.

Multizonale Bereitstellungen können Ausfallsicherheit bieten, wenn multiregionale Bereitstellungen aufgrund von Kosten oder anderen Aspekten begrenzt sind. Dieser Ansatz ist besonders hilfreich, um zonale oder regionale Ausfälle zu verhindern und Probleme hinsichtlich der Notfallwiederherstellung und Geschäftskontinuität zu beheben. Weitere Informationen finden Sie unter Skalierbares Hochverfügbarkeit bereitstellen.

Regionen basierend auf der geografischen Nähe auswählen

Die Latenz wirkt sich auf die Nutzerfreundlichkeit aus und auch auf die Kosten für die Bereitstellung externer Nutzer. Wählen Sie zum Minimieren der Latenz beim Bereitstellen von Traffic für externe Nutzer eine Region oder eine Gruppe von Regionen aus, die sich geografisch in der Nähe Ihrer Nutzer befinden und wo Ihre Dienste konform ausgeführt werden. Weitere Informationen finden Sie unter Cloudstandorte und im Center für Compliance-Ressourcen.

Regionen anhand der verfügbaren Dienste auswählen

Wählen Sie eine Region anhand der verfügbaren Dienste aus, die Ihr Unternehmen benötigt. Die meisten Dienste sind in allen Regionen verfügbar. Einige Unternehmensdienste sind möglicherweise in einer Teilmenge der Regionen mit ihrer ersten Version verfügbar. Informationen zum Prüfen der Regionsauswahl finden Sie unter Cloudstandorte.

Regionen zur Gewährleistung der Compliance auswählen

Wählen Sie eine bestimmte Region oder eine Gruppe von Regionen aus, um geografisch bedingte Vorschriften oder Compliance-Bestimmungen zu erfüllen, die die Verwendung bestimmter Regionen erfordern, z. B. Datenschutz-Grundverordnung (DSGVO) oder der Datenstandort. Weitere Informationen zum Entwerfen sicherer Systeme finden Sie unter Compliance-Angebote und in der Publikation Data residency, operational transparency, and privacy for European customers on Google Cloud.

Preise für wichtige Ressourcen vergleichen

In verschiedenen Regionen gelten für dieselben Dienste unterschiedliche Preise. Vergleichen Sie zur Identifizierung einer kosteneffizienten Region die Preise der wichtigsten Ressourcen, die Sie verwenden möchten. Die Aspekte, die bezüglich der Kosten berücksichtigt werden müssen, variieren je nach Sicherungsanforderungen und Ressourcen wie Computing, Netzwerk und Datenspeicher. Weitere Informationen finden Sie in der Kategorie zur Kostenoptimierung.

Cloud Load Balancing für globale Nutzer verwenden

Verwenden Sie zum Verbessern der Nutzererfahrung globaler Nutzer Cloud Load Balancing, um eine einzelne IP-Adresse bereitzustellen, die an Ihre Anwendung weitergeleitet wird. Weitere Informationen zum Entwerfen zuverlässiger Systeme finden Sie unter Google Cloud-Architektur-Framework: Zuverlässigkeit.

Mit der Cloud-Regionsauswahl die Nachhaltigkeit fördern

Google ist seit 2007 klimaneutral und wird bis 2030 CO2-frei sein. Verwenden Sie die Google Cloud-Regionsauswahl, um eine Region anhand ihrer CO2-Bilanz auszuwählen. Weitere Informationen zum Nachhaltigkeitsdesign finden Sie unter Nachhaltigkeit von Cloud.

Nächste Schritte

Mit Resource Manager, der Ressourcenhierarchie von Google Cloud, und dem Organisationsrichtliniendienst Cloud-Ressourcen verwalten.

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Cloud-Ressourcen verwalten

In diesem Dokument des Google Cloud-Architektur-Frameworks finden Sie Best Practices zum Organisieren und Verwalten Ihrer Ressourcen in Google Cloud.

Ressourcenhierarchie

Google Cloud-Ressourcen sind in Organisationen, Ordnern und Projekten hierarchisch angeordnet. Mithilfe dieser Hierarchie können Sie gemeinsame Aspekte Ihrer Ressourcen wie Zugriffssteuerung, Konfigurationseinstellungen und Richtlinien verwalten. Best Practices zum Entwerfen der Hierarchie Ihrer Cloud-Ressourcen finden Sie unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen.

Ressourcenlabels und -Tags

Dieser Abschnitt enthält Best Practices zum Verwenden von Labels und Tags zum Organisieren Ihrer Google Cloud-Ressourcen.

Einfache Ordnerstruktur verwenden

Mit Ordnern können Sie eine beliebige Kombination aus Projekten und Unterordnern gruppieren. Erstellen Sie eine einfache Ordnerstruktur zum Organisieren Ihrer Google Cloud-Ressourcen. Sie können bei Bedarf weitere Ebenen hinzufügen, um Ihre Ressourcenhierarchie zu definieren, damit sie Ihren Geschäftsanforderungen entspricht. Die Ordnerstruktur ist flexibel und erweiterbar. Weitere Informationen finden Sie unter Ordner erstellen und verwalten.

Data Governance-Richtlinien in Ordnern und Projekten darstellen

Verwenden Sie Ordner, Unterordner und Projekte, um Ressourcen voneinander zu trennen, um die Richtlinien für die Data Governance in Ihrer Organisation widerzuspiegeln. Sie können beispielsweise eine Kombination aus Ordnern und Projekten verwenden, um Finanz-, Personal- und Technikteams zu trennen.

Verwenden Sie Projekte zum Gruppieren von Ressourcen mit der gleichen Vertrauensgrenze. Zum Beispiel können Ressourcen für das gleiche Projekt oder den gleichen Mikrodienst zum gleichen Projekt gehören. Weitere Informationen finden Sie unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone auswählen.

Tags und Labels bereits am Anfang Ihres Projekts verwenden

Verwenden Sie Labels und Tags, wenn Sie Google Cloud-Produkte bereits verwenden, auch wenn Sie sie nicht sofort benötigen. Das Hinzufügen von Labels und Tags erfordert später möglicherweise einen manuellen Aufwand, der fehleranfällig und schwer zu handhaben ist.

Mit Tags können Sie Richtlinien abhängig davon zulassen oder ablehnen, ob eine Ressource ein bestimmtes Tag hat. Ein Label ist ein Schlüssel/Wert-Paar, mit dem Sie Ihre Google Cloud-Instanzen organisieren können. Weitere Informationen zu Labels finden Sie unter Anforderungen für Labels, eine Liste von Diensten, die Labels unterstützen und Labelformate.

Resource Manager bietet Labels und Tags, mit denen Sie Ressourcen verwalten, Kosten zuweisen und entsprechende Berichte erstellen sowie Richtlinien verschiedenen Ressourcen für eine detaillierte Zugriffssteuerung zuweisen können. Sie können beispielsweise Labels und Tags verwenden, um detaillierte Zugriffs- und Verwaltungsprinzipien auf verschiedene Mandantenressourcen und -dienste anzuwenden. Informationen zu VM-Labels und Netzwerk-Tags finden Sie unter Beziehung zwischen VM-Labels und Netzwerk-Tags.

Sie können Labels für mehrere Zwecke verwenden, einschließlich:

• Ressourcenabrechnung verwalten: Labels sind im Abrechnungssystem verfügbar, sodass Sie Kosten durch Labels aufteilen können. Sie können beispielsweise verschiedene Kostenstellen oder Budgets mit Labels versehen.
• Ressourcen nach ähnlichen Merkmalen oder nach Beziehung gruppieren: Sie können Labels verwenden, um verschiedene Phasen oder Umgebungen der Anwendung zu unterteilen. Beispielsweise können Sie Produktions-, Entwicklungs- und Testumgebungen mit Labels versehen.

Labels für Support- und Abrechnungsberichte zuweisen

Damit detaillierte Kosten- und Abrechnungsberichte basierend auf Attributen außerhalb Ihrer integrierten Berichtsstrukturen (z. B. pro Projekt oder produktspezifischer Typ) unterstützt werden können, weisen Sie Ressourcen Labels zu. Mithilfe von Labels können Sie die Nutzung den Kostenstellen, Abteilungen, bestimmten Projekten oder internen Lademechanismen zuordnen. Weitere Informationen finden Sie unter Kategorie zur Kostenoptimierung.

Zu viele Labels vermeiden

Vermeiden Sie es, zu viele Labels zu erstellen. Wir empfehlen, Labels in erster Linie auf Projektebene zu erstellen und Labels auf der Ebene von Untergruppen zu vermeiden. Wenn Sie zu detaillierte Labels erstellen, kann dies zu unnötigen Analysen führen. Informationen zu gängigen Anwendungsfällen für Labels finden Sie unter Gängige Anwendungsfälle von Labels.

Labels keine vertraulichen Informationen hinzufügen

Labels sind nicht für vertrauliche Informationen gedacht. Labels dürfen keine vertraulichen Informationen enthalten, einschließlich Informationen, die möglicherweise personenbezogen sind, z. B. den Namen oder Titel einer Person.

Informationen in Projektnamen anonymisieren

Verwenden Sie ein Projektnamensmuster wie COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME, wobei die Platzhalter eindeutig sind und keine Namen von Unternehmen oder Anwendungen erkennen lassen. Geben Sie keine Attribute an, die sich in Zukunft ändern können, z. B. einen Teamname oder eine Technologie.

Tags auf Modellgeschäftsdimensionen anwenden

Sie können Tags anwenden, um zusätzliche Geschäftsdimensionen wie Organisationsstruktur, Regionen, Arbeitslasttypen oder Kostenstellen zu modellieren. Weitere Informationen zu Tags finden Sie unter Tags – Übersicht, Tag-Übernahme und Tags erstellen und verwalten. Informationen zum Verwenden von Tags mit Richtlinien finden Sie unter Richtlinien und Tags. Informationen zur Verwendung von Tags zur Verwaltung der Zugriffssteuerung finden Sie unter Tags und Zugriffssteuerung.

Organisationsrichtlinien

Dieser Abschnitt enthält Best Practices zum Konfigurieren von Governance-Regeln für Google Cloud-Ressourcen in der gesamten Cloudressourcenhierarchie.

Namenskonventionen für Projekte festlegen

Legen Sie eine standardisierte Namenskonvention für Projekte fest, z. B. SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).

Projektnamen dürfen nicht länger als 30 Zeichen sein.

Sie können zwar ein Präfix wie COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG anwenden, aber Projektnamen können veraltet sein, wenn Unternehmen Reorganisationen durchlaufen. Ziehen Sie in Betracht, identifizierbare Namen von Projektnamen zu Projektlabels zu verschieben.

Projekterstellung automatisieren

Um Projekte für die Produktion und für große Unternehmen zu erstellen, verwenden Sie einen automatisierten Prozess wie Deployment Manager oder Terraform-Modul für Google Cloud Project Factory. Diese Tools tun Folgendes:

• Entwicklungs-, Test- und Produktionsumgebungen oder Projekte mit den entsprechenden Berechtigungen automatisch erstellen.
• Logging und Monitoring konfigurieren.

Mit dem Terraform-Modul für Google Cloud Project Factory können Sie die Erstellung von Google Cloud-Projekten automatisieren. In großen Unternehmen empfehlen wir Ihnen, Projekte zu prüfen und zu genehmigen, bevor Sie sie in Google Cloud erstellen. Dadurch wird Folgendes sichergestellt:

• Kosten können zugeordnet werden. Weitere Informationen finden Sie unter Kategorie zur Kostenoptimierung.
• Für Datenuploads gelten Genehmigungen.
• Gesetzliche oder Compliance-Anforderungen werden erfüllt.

Die Automatisierung der Erstellung und Verwaltung von Google Cloud-Projekten und -Ressourcen bietet Ihnen Konsistenz, Reproduzierbarkeit und Testbarkeit. Wenn Sie Ihre Konfiguration als Code behandeln, können Sie den Lebenszyklus der Konfiguration zusammen mit den Softwareartefakten versionieren und verwalten. Die Automatisierung ermöglicht Ihnen, Best Practices wie konsistente Namenskonventionen und Ressourcenlabels zu unterstützen. Wenn sich Ihre Anforderungen ändern, vereinfacht die Automatisierung die Projektrefaktorierung.

Systeme regelmäßig prüfen

Binden Sie das Ticketsystem Ihres Unternehmens oder ein eigenständiges System mit Auditing ein, um sicherzustellen, dass Anfragen für neue Projekte geprüft und genehmigt werden können.

Projekte einheitlich konfigurieren

Konfigurieren Sie Projekte so, dass sie die Anforderungen Ihrer Organisation einheitlich erfüllen. Geben Sie beim Einrichten von Projekten Folgendes an:

• Projekt-ID und Namenskonventionen
• Rechnungskontoverknüpfung
• Netzwerkkonfiguration
• Aktivierte APIs und Dienste
• Compute Engine-Zugriffskonfiguration
• Logexport und -nutzungsberichte
• Sperre für Löschen von Projekten

Arbeitslasten oder Umgebungen entkoppeln und isolieren

Kontingente und Limits werden auf Projektebene erzwungen. Zur Verwaltung von Kontingenten und Limits entkoppeln und isolieren Sie Arbeitslasten oder Umgebungen auf Projektebene. Weitere Informationen finden Sie unter Mit Kontingenten arbeiten.

Die Entkoppelung von Umgebungen unterscheidet sich von den Anforderungen an die Datenklassifizierung. Die Trennung der Daten von der Infrastruktur kann teuer und komplex sein, daher empfehlen wir, die Datenklassifizierung basierend auf den Anforderungen an die Vertraulichkeit und Compliance der Daten implementieren.

Abrechnungsisolation erzwingen

Erzwingen Sie die Abrechnungsisolation, um verschiedene Rechnungskonten und Kostentransparenz pro Arbeitslast und Umgebung zu unterstützen. Weitere Informationen finden Sie unter Selfservice-Cloud-Rechnungskonto erstellen, ändern oder schließen und Abrechnung für ein Projekt aktivieren, deaktivieren oder ändern.

Verwenden Sie zur Minimierung der administrativen Komplexität detaillierte Steuerelemente für die Zugriffsverwaltung für kritische Umgebungen auf Projektebene oder für Arbeitslasten, die auf mehrere Projekte verteilt sind. Wenn Sie die Zugriffssteuerung für kritische Produktionsanwendungen auswählen, sorgen Sie dafür, dass Arbeitslasten effektiv gesichert und verwaltet werden.

Ressourcen mit dem Organisationsrichtliniendienst steuern

Der Organisationsrichtliniendienst gibt Richtlinienadministratoren die zentrale und programmatische Kontrolle über die Cloud-Ressourcen Ihrer Organisation. Die Richtlinienadmistratoren können Einschränkungen für die gesamte Ressourcenhierarchie konfigurieren. Weitere Informationen finden Sie unter Organisationsrichtlinienadministrator hinzufügen.

Mit dem Organisationsrichtliniendienst rechtliche Bestimmungen einhalten

Verwenden Sie zum Erfüllen der Compliance-Anforderungen den Organisationsrichtliniendienst und erzwingen Sie so die Einhaltung der Compliance-Anforderungen bei der Ressourcenfreigabe und dem Ressourcenzugriff. Sie können beispielsweise die Freigabe für externe Parteien beschränken oder festlegen, wo Cloudressourcen geografisch bereitgestellt werden sollen. Weitere Compliance-Szenarien:

• Sie zentralisieren die Kontrolle, um Einschränkungen zu konfigurieren, die festlegen, wie die Ressourcen Ihrer Organisation verwendet werden können.
• Sie definieren Richtlinien, damit Ihre Entwicklungsteams die Compliance-Einschränkungen einhalten können.
• Sie unterstützen Projektinhaber und ihre Teams dabei, Systemänderungen vorzunehmen und gleichzeitig die Einhaltung gesetzlicher Vorschriften zu gewährleisten und Bedenken hinsichtlich Verletzung von Compliance-Regeln zu minimieren.

Ressourcenfreigabe auf Grundlage der Domain beschränken

Mit einer Organisationsrichtlinie für die eingeschränkte Freigabe können Sie verhindern, dass Google Cloud-Ressourcen für Identitäten außerhalb Ihrer Organisation freigegeben werden. Weitere Informationen finden Sie unter Identitäten nach Domain einschränken und Einschränkungen für Organisationsrichtlinien.

Erstellen von Dienstkonten und Schlüsseln deaktivieren

Zur Verbesserung der Sicherheit sollten Sie die Verwendung von IAM-Dienstkonten (Identity and Access Management) und entsprechenden Schlüsseln einschränken. Weitere Informationen finden Sie unter Nutzung von Dienstkonten einschränken.

Standort neuer Ressourcen einschränken

Beschränken Sie den physischen Standort neu erstellter Ressourcen, indem Sie Ressourcenstandorte einschränken. Eine Liste der Einschränkungen, die Ihnen die Kontrolle über die Ressourcen Ihrer Organisation ermöglichen, finden Sie unter Einschränkungen für Organisationsrichtliniendienste.

Nächste Schritte

Computing auswählen und verwalten, einschließlich:

• Ansatz zur Compute-Migration

• Arbeitslasten entwerfen und Arbeitslasten skalieren

• Vorgänge verwalten.

• VM-Migrationen verwalten

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Computing auswählen und verwalten.

In diesem Dokument des Google Cloud-Architektur-Frameworks finden Sie Best Practices zum Bereitstellen Ihres Systems auf Grundlage der Computeranforderungen. Sie erfahren, wie Sie eine Computing-Plattform und einen Migrationsansatz auswählen, Arbeitslasten entwerfen und skalieren sowie Vorgänge und VM-Migrationen verwalten.

Die Berechnung ist der Kern vieler Arbeitslasten, unabhängig davon, ob es sich um die Ausführung einer benutzerdefinierten Geschäftslogik oder die Anwendung komplexer Berechnungsalgorithmen auf Datasets handelt. Die meisten Lösungen verwenden in irgendeiner Form Rechenressourcen und es ist wichtig, dass Sie die richtigen Rechenressourcen für Ihre Anwendungsanforderungen auswählen.

Google Cloud bietet mehrere Optionen zur Verwendung der Zeit auf einer CPU. Die Optionen basieren auf CPU-Typen, der Leistung und der geplanten Ausführung des Codes, einschließlich der Nutzungsabrechnung.

Zu den Google Cloud-Computing-Optionen gehören:

• VMs (Virtuelle Maschinen) mit cloudspezifischen Vorteilen wie Live-Migration
• Bin-Packing von Containern auf Cluster-Maschinen, die sich CPUs teilen können.
• Functions und serverlose Ansätze, bei denen Ihre CPU-Zeit auf die Arbeit angerechnet werden kann, die während einer einzelnen HTTP-Anfrage ausgeführt wird.

Computing auswählen

Dieser Abschnitt enthält Best Practices zum Auswählen und Migrieren zu einer Computing-Plattform.

Computing-Plattform auswählen

Berücksichtigen Sie bei der Auswahl einer Computing-Plattform für Ihre Arbeitslast die technischen Anforderungen der Arbeitslast, der Prozesse für die Lebenszyklusautomatisierung, der Regionalisierung und der Sicherheit.

Bewerten Sie die Art der CPU-Nutzung durch Ihre Anwendung und das gesamte unterstützende System, einschließlich der Art und Weise, wie Ihr Code verpackt und bereitgestellt, verteilt und aufgerufen wird. Während einige Szenarien mit mehreren Plattformoptionen kompatibel sein können, sollte eine portable Arbeitslast auf einer Reihe von Compute-Optionen geeignet und leistungsfähig sein.

Die folgende Tabelle gibt einen Überblick über die für verschiedene Anwendungsfälle empfohlenen Google Cloud-Computing-Dienste:

Rechenplattform	Anwendungsfälle	Empfohlene Produkte
Serverlos	Erste Anwendung bereitstellen. Konzentrieren Sie sich auf die Daten- und Verarbeitungslogik sowie auf die Anwendungsentwicklung, anstatt sich um die Verwaltung der Infrastrukturvorgänge zu kümmern.	Cloud Run: Mit dieser vollständig verwalteten Option können Sie Ihre Geschäftslogik in Container verlagern. Cloud Run wurde für Arbeitslasten entwickelt, die rechenintensiv, aber nicht immer aktiviert sind. Skalieren Sie kostengünstig von 0 (kein Traffic) und definieren Sie die CPU und den RAM für Ihre Aufgaben und Dienste. Stellen Sie diese mit einem einzigen Befehl bereit. Google stellt automatisch die richtige Menge an Ressourcen bereit. Cloud Functions: Trennen Sie Ihren Code in flexible Teile der Geschäftslogik, ohne sich um die Infrastruktur wie Load-Balancing, Aktualisierungen, Authentifizierung oder Skalierung kümmern zu müssen.
Kubernetes	Komplexe Mikrodienstarchitekturen, die zusätzliche Dienste wie Istio zur Verwaltung der Service Mesh-Steuerung benötigen.	Google Kubernetes Engine: Eine Open-Source-Engine zur Containerorchestrierung, die die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert.
Virtuelle Maschinen (VMs)	Erstellen und führen Sie VMs aus vordefinierten und anpassbaren VM-Familien aus, die Ihre Anwendungs- und Arbeitslastanforderungen sowie Software und Dienste von Drittanbietern unterstützen.	Compute Engine: Fügen Sie Ihren VM-Instanzen Grafikprozessoren (GPUs) hinzu. Sie können diese GPUs nutzen, um bestimmte Arbeitslasten wie maschinelles Lernen und Datenverarbeitung auf Ihren Instanzen zu beschleunigen. Weitere Informationen zum Auswählen geeigneter Maschinentypen gemäß Ihren Anforderungen finden Sie unter Empfehlungen für Maschinenfamilien.

Weitere Informationen finden Sie unter Computing-Optionen auswählen.

Ansatz der Compute-Migration auswählen

Wenn Sie Ihre bestehenden Anwendungen aus einer anderen Cloud oder aus der lokalen Umgebung migrieren, verwenden Sie eines der folgenden Google Cloud-Produkte, um Leistung, Skalierung, Kosten und Sicherheit zu optimieren.

Migrationsziel	Anwendungsfall	Empfohlenes Produkt
Lift-and-Shift	Migrieren Sie Ihre VMware-Arbeitslasten in wenigen Minuten zu Google Cloud.	Google Cloud VMware Engine
Lift-and-Shift	Verschieben Sie Ihre VM-basierten Anwendungen in Compute Engine.	Migrate to Virtual Machines
Upgrade auf Container	Modernisieren Sie traditionelle Anwendungen in integrierte Container in Google Kubernetes Engine.	Zu Containern migrieren

Informationen zum Migrieren Ihrer Arbeitslasten bei der Ausrichtung interner Teams finden Sie unter VM-Migrationslebenszyklus und Umfangreiches Migrationsprogramm mit Google Cloud erstellen.

Arbeitslasten entwerfen

Dieser Abschnitt enthält Best Practices zum Entwerfen von Arbeitslasten, die Ihr System unterstützen.

Serverlose Optionen für einfache Logik bewerten

Einfache Logik ist ein Computing-Typ, der keine speziellen Hardware oder Maschinentypen wie CPU-optimierte Maschinen erfordert. Bevor Sie in Google Kubernetes Engine (GKE) oderCompute Engine Implementierungen investieren, um den operativen Aufwand zu abstrahieren und Kosten und Leistung zu optimieren, evaluieren SIe die Serverlosen Optionen für eine einfache Logik.

Anwendungen als zustandslos entkoppeln

Entkoppeln Sie Ihre Anwendungen nach Möglichkeit als zustandslos, um die Verwendung von serverlosen Computing-Optionen zu maximieren. Mit diesem Ansatz können Sie verwaltete Computing-Angebote verwenden, Anwendungen nach Bedarf skalieren und Kosten und Leistung optimieren. Weitere Informationen zum Entkoppeln Ihrer Anwendung für die Skalierung und Hochverfügbarkeit finden Sie unter Für Skalierung und Hochverfügbarkeit entwerfen.

Caching-Logik zum Entkoppeln von Architekturen verwenden

Wenn Ihre Anwendung zustandsorientiert ist, verwenden Sie Caching-Logik, um Ihre Arbeitslast zu entkoppeln und skalierbar zu machen. Weitere Informationen finden Sie unter Best Practices für Datenbanken.

Live-Migrationen zur Vereinfachung von Upgrades verwenden

Verwenden Sie Live-Migration, indem Sie Instanzverfügbarkeitsrichtlinien festlegen, um Google-Wartungsupgrades zu erleichtern. Weitere Informationen finden Sie unter Wartungsrichtlinie für VM-Host festlegen.

Arbeitslasten skalieren

Dieser Abschnitt enthält Best Practices zum Skalieren von Arbeitslasten zur Unterstützung Ihres Systems.

Start- und Shutdown-Skripts verwenden

Verwenden Sie für zustandsorientierte Anwendungen Startskripts und Shutdown-Skripts nach Möglichkeit, um den Anwendungsstatus ordnungsgemäß zu starten und zu beenden. Ein ordnungsgemäßer Start ist, wenn ein Computer durch eine Softwarefunktion aktiviert wird und das Betriebssystem seine Aufgaben für das sichere Starten von Prozessen und das Öffnen von Verbindungen ausführen darf.

Ein ordnungsgemäßes Starten und Herunterfahren ist wichtig, da zustandsorientierte Anwendungen von der sofortigen Verfügbarkeit für die Daten abhängen, die sich in der Nähe der Rechenleistung befinden, normalerweise auf lokalen oder nichtflüchtigen Speichern oder im RAM. Damit für jeden Startvorgang keine Anwendungsdaten neu ausgeführt werden, verwenden Sie ein Startskript, um die zuletzt gespeicherten Daten neu zu laden und den Prozess auszuführen, bei dem sie zuvor beim Herunterfahren beendet wurden. Verwenden Sie ein Shutdown-Script, um den Speicherstatus der Anwendung zu speichern, damit kein Fortschritt beim Herunterfahren verloren geht. Verwenden Sie beispielsweise ein Shutdown-Script, wenn eine VM aufgrund von Herunterskalierung oder Google-Wartungsereignissen heruntergefahren wird.

MIGs zur Unterstützung der VM-Verwaltung verwenden

Wenn Sie Compute Engine-VMs verwenden, unterstützen verwaltete Instanzgruppen (Managed Instance Groups, MIGs) Funktionen wie automatische Reparatur, Load-Balancing, Autoscaling und Auto-Aktualisierung und zustandsorientierte Arbeitslasten. Sie können zonale oder regionale MIGs anhand Ihrer Verfügbarkeitsziele erstellen. Sie können MIGs für zustandslose Bereitstellungs- oder Batcharbeitslasten und für zustandsorientierte Anwendungen verwenden, die den eindeutigen Zustand jeder VM beibehalten müssen.

Mit Pod-Autoscaling die GKE-Arbeitslasten skalieren

Verwenden Sie horizontale und vertikale Pod-Autoscaler, um Ihre Arbeitslasten zu skalieren, und verwenden Sie die automatische Knotenbereitstellung, um die zugrunde liegenden Rechenressourcen zu skalieren.

Anwendungstraffic verteilen

Um Ihre Anwendungen global zu skalieren, verwenden Sie Cloud Load Balancing, um Ihre Anwendungsinstanzen auf mehrere Regionen oder Zonen zu verteilen. Load-Balancer optimieren das Paketrouting von Edge-Netzwerken von Google Cloud zur nächstgelegenen Zone, wodurch die Bereitstellungseffizienz des Traffics erhöht und die Bereitstellungskosten minimiert werden. Verwenden Sie zum Optimieren der Endnutzerlatenz Cloud CDN, um statische Inhalte nach Möglichkeit im Cache zu speichern.

Compute-Erstellung und -Verwaltung automatisieren

Minimieren Sie menschliche Fehler in Ihrer Produktionsumgebung, indem Sie das Erstellen und Verwalten von Computing automatisieren.

Vorgänge verwalten

Dieser Abschnitt enthält Best Practices für das Managen von Vorgängen zur Unterstützung Ihres Systems.

Von Google bereitgestellte öffentliche Images verwenden

Öffentliche Images verwenden, die von Google Cloud bereitgestellt werden Die öffentlichen Images von Google Cloud werden regelmäßig aktualisiert. Weitere Informationen finden Sie unter Liste der in Compute Engine verfügbaren öffentlichen Images.

Sie können auch eigene Images mit bestimmten Konfigurationen und Einstellungen erstellen. Die Image-Erstellung sollte nach Möglichkeit in einem separaten Projekt automatisiert und zentralisiert werden, das Sie für autorisierte Nutzer innerhalb Ihrer Organisation freigeben können. Wenn Sie ein benutzerdefiniertes Image in einem separaten Projekt erstellen und auswählen, können Sie eine VM mit Ihren eigenen Konfigurationen aktualisieren, patchen und erstellen. Sie können dann das ausgewählte VM-Image für relevante Projekte freigeben.

Snapshots für Instanzsicherungen verwenden

Mit Snapshots können Sie Sicherungen für Ihre Instanzen erstellen. Snapshots sind besonders nützlich für zustandsorientierte Anwendungen, die nicht flexibel genug sind, um den Status zu erhalten, oder den Fortschritt speichern, wenn bei einem abrupten Herunterfahren ein Fehler auftritt. Wenn Sie häufig Snapshots verwenden, um neue Instanzen zu erstellen, können Sie Ihren Sicherungsprozess optimieren, indem Sie aus diesem Snapshot ein Basis-Image erstellen.

VM-Instanzerstellung mit einem Maschinen-Image

Bei einem Snapshot werden neben den Daten nur ein Image der Daten auf einem Computer, aber auch ein Maschinen-Image erfasst Maschinenkonfigurationen und -einstellungen. Verwenden Sie ein Maschinen-Image, um alle Konfigurationen, Metadaten, Berechtigungen und Daten von einem oder mehreren Laufwerken zu speichern, die zum Erstellen einer VM-Instanz erforderlich sind.

Wenn Sie eine Maschine aus einem Snapshot erstellen, müssen Sie die Instanzeinstellungen auf den neuen VM-Instanzen konfigurieren, was viel Arbeit erfordert. Mithilfe von Maschinen-Images können Sie diese bekannten Einstellungen auf neue Maschinen kopieren und so den Aufwand reduzieren. Weitere Informationen finden Sie unter Gründe für die Verwendung von Maschinen-Images.

Kapazität, Reservierungen und Isolation

Dieser Abschnitt enthält Best Practices zum Verwalten von Kapazität, Reservierungen und Isolation, um das System zu unterstützen.

Rabatte für zugesicherte Nutzung zur Kostensenkung verwenden

Mit Rabatten für zugesicherte Nutzung können Sie die Betriebskosten für Arbeitslasten, die immer aktiviert sind, reduzieren. Weitere Informationen finden Sie unter Kostenoptimierungskategorie.

Maschinentypen zur Unterstützung von Kosten und Leistung auswählen

Google Cloud bietet Maschinentypen, mit denen Sie Computing basierend auf Kosten- und Leistungsparametern auswählen können. Sie können sich für ein Angebot mit geringerer Leistung entscheiden, um die Kosten zu optimieren, oder eine Hochleistungs-Computing-Option zu höheren Kosten wählen. Weitere Informationen finden Sie unter Kostenoptimierungskategorie.

Knoten für einzelne Mandanten verwenden, um Compliance-Anforderungen zu erfüllen

Knoten für einzelne Mandanten sind physische Compute Engine-Server, auf denen ausschließlich die VMs Ihres Projekts gehostet werden. Mit Knoten für einzelne Mandanten können Sie Complianceanforderungen für die physische Isolation erfüllen, darunter:

• Ihre VMs bleiben physisch von VMs in anderen Projekten getrennt.
• Ihre VMs auf derselben Hosthardware gruppieren.
• Die Arbeitslasten zur Zahlungsverarbeitung isolieren.

Weitere Informationen finden Sie unter Knoten für einzelne Mandanten.

Reservierungen für sichere Ressourcenverfügbarkeit verwenden

Mit Google Cloud können Sie Reservierungen für Ihre Arbeitslasten definieren, damit diese Ressourcen immer verfügbar sind. Für das Erstellen von Reservierungen fallen keine zusätzlichen Gebühren an. Sie zahlen jedoch für die reservierten Ressourcen, auch wenn Sie sie nicht verwenden. Weitere Informationen finden Sie unter Reservierungen nutzen und verwalten.

VM-Migration

Dieser Abschnitt enthält Best Practices zum Migrieren von VMs zur Unterstützung Ihres Systems.

Integrierte Migrationstools bewerten

Prüfen Sie mit integrierten Migrationstools Ihre Arbeitslasten aus einer anderen Cloud oder einer lokalen Umgebung. Weitere Informationen finden Sie unter Migration zu Google Cloud. Google Cloud bietet Tools und Dienste, mit denen Sie Ihre Arbeitslasten migrieren und Kosten und Leistung optimieren können. Unter Google Cloud-Programm "Rapid Assessment & Migration Program" finden Sie eine kostenlose Bewertung der Migrationskosten anhand Ihrer aktuellen IT-Landschaft.

Import virtueller Laufwerke für benutzerdefinierte Betriebssysteme verwenden

Informationen zum Importieren benutzerdefinierter unterstützter Betriebssysteme finden Sie unter Virtuelle Laufwerke importieren. Knoten für einzelne Mandanten können Ihnen helfen, Ihre Anforderungen an die Lizenznutzung für die eigene Lizenz zu erfüllen. Weitere Informationen finden Sie unter Eigene Lizenz verwenden (Bring your own License, BYOL).

Empfehlungen

Befolgen Sie diese Empfehlungen, um die Anleitung im Architektur-Framework auf Ihre eigene Umgebung anzuwenden:

• Prüfen Sie die Google Cloud Marketplace-Angebote, um zu beurteilen, ob Ihre Anwendung unter einem unterstützten Anbieter aufgeführt wird. Google Cloud unterstützt die Ausführung verschiedener Open-Source-Systeme und verschiedener Drittanbietersoftware.

• Mit Migrate to Containers and GKE können Sie Ihre VM-basierte Anwendung als containerisierte Anwendung, die in GKE ausgeführt wird, extrahieren und verpacken.

• Verwenden Sie Compute Engine, um Ihre Anwendungen in Google Cloud auszuführen. Wenn Legacy-Abhängigkeiten in einer VM-basierten Anwendung ausgeführt werden, prüfen Sie, ob sie Ihren Anbieteranforderungen entsprechen.

• Prüfen Sie die Verwendung eines internen Google Cloud-Passthrough-Netzwerk-Load-Balancers zur Skalierung Ihrer entkoppelten Architektur. Weitere Informationen finden Sie unter Übersicht über internen Passthrough-Netzwerk-Load-Balancer.

• Prüfen Sie die Optionen für den Wechsel von herkömmlichen lokalen Anwendungsfällen wie der HA-Proxy-Nutzung. Weitere Informationen finden Sie unter Best Practice für Floating-IP-Adresse.

• Verwalten Sie mit VM Manager die Betriebssysteme für Ihre großen VM-Flotten unter Windows oder Linux auf Compute Engine und wenden Sie einheitliche Konfigurationsrichtlinien an.

• Erwägen Sie die Verwendung von GKE Autopilot und lassen Sie Google SRE Ihre Cluster vollständig verwalten.

• Verwenden Sie Policy Controller und Config Sync für die Richtlinien- und Konfigurationsverwaltung in Ihren GKE-Clustern.

• Gewährleistung der Verfügbarkeit und Skalierbarkeit von Maschinen in bestimmten Regionen und Zonen Google Cloud kann gemäß Ihren Computing-Anforderungen skaliert werden. Wenn Sie jedoch viele spezifische Maschinentypen in einer bestimmten Region oder Zone benötigen, wenden Sie sich an Ihre Account-Management-Teams, um die Verfügbarkeit zu gewährleisten. Weitere Informationen finden Sie unter Reservierungen für Compute Engine.

Nächste Schritte

Weitere Informationen zu Netzwerkdesignprinzipien, darunter:

• VPC-Arbeitslast-Architekturen entwerfen.

• Inter-VPC-Konnektivität entwerfen.

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Netzwerkinfrastruktur entwerfen.

In diesem Dokument des Google Cloud-Architektur-Frameworks werden Best Practices für die Bereitstellung Ihres Systems auf Basis des Netzwerkdesigns vorgestellt. Sie erfahren, wie Sie eine VPC (Virtual Private Cloud) auswählen und implementieren und die Netzwerksicherheit testen und verwalten.

Grundprinzipien

Das Netzwerkdesign ist für ein erfolgreiches Systemdesign von entscheidender Bedeutung, da es dabei hilft, die Leistung zu optimieren und die Anwendungskommunikation mit internen und externen Diensten zu sichern. Bei der Auswahl von Netzwerkdiensten ist es wichtig, Ihre Anwendungsanforderungen und die Art der zukünftigen Kommunikationen zwischen Anwendungen zu bewerten. Beispiel: Einige Komponenten benötigen globale Dienste, andere mögen sich in einer bestimmten Region befinden müssen.

Das private Netzwerk von Google verbindet regionale Standorte mit mehr als 100 Netzwerk-Points-of-Presence weltweit. Google Cloud nutzt ein softwarebasiertes Netzwerk und verteilte Systemtechnologien, um Ihre Dienste zu hosten und weltweit bereitzustellen. Googles Kernelement für Netzwerkaktivitäten innerhalb von Google Cloud ist die globale VPC. Die VPC verwendet das globale Hochgeschwindigkeitsnetzwerk von Google, um Ihre Anwendungen regionenübergreifend zu verknüpfen, und unterstützt gleichzeitig Datenschutz und Zuverlässigkeit. Google sorgt dafür, dass Ihre Inhalte dank Technologien wie der intelligenten Engpassansprache BBR (Bottlehal Bandwidth and Round-Trip Propagation Time) mit hohem Durchsatz bereitgestellt werden.

Die Entwicklung Ihres Cloudnetzwerk-Designs umfasst folgende Schritte:

1. Entwerfen Sie die VPC-Architektur für Arbeitslasten. Ermitteln Sie zuerst, wie viele Google Cloud-Projekte und VPC-Netzwerke Sie benötigen.
2. Fügen Sie dann die VPC-Konnektivität hinzu. Planen Sie, wie Ihre Arbeitslasten mit anderen Arbeitslasten in verschiedenen VPC-Netzwerken verbunden werden sollen
3. Entwicklung hybrider Netzwerkkonnektivität. Entwurf der Art, wie Arbeitslast-VPCs Verbindungen zu lokalen und anderen Cloud-Umgebungen herstellen.

Beachten Sie beim Entwurf Ihres Google Cloud-Netzwerks Folgendes:

• Eine VPC bietet eine private Netzwerkumgebung in der Cloud für die Verbindung von Diensten, die auf Compute Engine, Google Kubernetes Engine (GKE) und Serverless Computing Solutions basieren. Sie können eine VPC auch nutzen, um privat auf von Google verwaltete Dienste wie Cloud Storage, BigQuery und Cloud SQL zuzugreifen.
• VPC-Netzwerke und die damit verknüpften Routen und Firewallregeln sind globale Ressourcen. Sie sind keiner bestimmten Region oder Zone zugeordnet.
• Subnetze sind regionale Ressourcen. Compute Engine-VM-Instanzen, die in verschiedenen Zonen in derselben Cloud-Region bereitgestellt werden, können IP-Adressen aus demselben Subnetz verwenden.
• Der Traffic zu und von Instanzen kann über VPC-Firewallregeln gesteuert werden.
• Die Netzwerkverwaltung kann über IAM-Rollen (Identity and Access Management) gesichert werden.
• VPC-Netzwerke können in Hybridumgebungen über Cloud VPN oder Cloud Interconnect sicher verbunden werden.

Eine vollständige Liste der VPC-Spezifikationen finden Sie unter Spezifikationen.

VPC-Architektur der Arbeitslast

Dieser Abschnitt enthält Best Practices zum Entwerfen von Arbeitslast-VPC-Architekturen zur Unterstützung Ihres Systems.

Frühzeitig VPC-Netzwerkdesign in Betracht ziehen

Erwägen Sie das VPC-Netzwerkdesign bereits früh während des Entwurfs der organisatorischen Einrichtung. Designoptionen auf Organisationsebene können später nicht mehr einfach umgekehrt werden. Weitere Informationen finden Sie unter Best Practices und Referenzarchitekturen für das VPC-Design und Legen Sie das Netzwerkdesign für Ihre Google Cloud-Landing-Zone fest.

Mit einem einzelnen VPC-Netzwerk beginnen

In vielen Anwendungsfällen, die Ressourcen mit gemeinsamen Anforderungen umfassen, bietet ein einzelnes VPC-Netzwerk die benötigten Features. VPC-Netzwerke lassen sich einfach erstellen, verwalten und verstehen. Weitere Informationen finden Sie unter Spezifikationen für VPC-Netzwerke.

VPC-Netzwerktopologie einfach halten

Um eine überschaubare, zuverlässige und leicht verständliche Architektur zu bedingen, sollten Sie das Design Ihrer VPC-Netzwerktopologie so einfach wie möglich halten.

VPC-Netzwerke im benutzerdefinierten Modus verwenden

Damit Google Cloud-Netzwerke nahtlos in Ihre vorhandenen Netzwerksysteme eingebunden werden, empfehlen wir Ihnen, beim Erstellen von VPC-Netzwerken den benutzerdefinierten Modus zu verwenden. Mit dem benutzerdefinierten Modus können Sie Google Cloud-Netzwerke in vorhandene IP-Adressverwaltungsschemas einbinden und steuern, welche Cloudregionen in der VPC enthalten sind. Weitere Informationen finden Sie unter VPC.

Inter-VPC-Konnektivität

Dieser Abschnitt enthält Best Practices zum Entwurf der Inter-VPC-Konnektivität zur Unterstützung Ihres Systems.

VPC-Verbindungsmethode auswählen

Wenn Sie mehrere VPC-Netzwerke implementieren möchten, müssen Sie diese Netzwerke verbinden. VPC-Netzwerke sind isolierte Mandantenbereiche innerhalb des softwarebasierten Netzwerks von Andromeda (SDN). VPC-Netzwerke können auf verschiedene Arten miteinander kommunizieren. Wählen Sie aus, wie Sie Ihr Netzwerk basierend auf Ihren Anforderungen an Bandbreite, Latenz und Service Level Agreement (SLA) verbinden möchten. Weitere Informationen zu Verbindungsoptionen finden Sie unter VPC-Verbindungsmethode entsprechend Ihres Budgets und Ihrer Leistungs- und Sicherheitsanforderungen wählen.

Mit freigegebener VPC mehrere Arbeitsgruppen verwalten

Freigegebene VPCs ermöglichen es Organisationen mit mehreren Teams, die architektonische Einfachheit eines einzelnen VPC-Netzwerks effektiv auf mehrere Arbeitsgruppen auszudehnen.

Einfache Namenskonventionen verwenden

Wählen Sie einfache, intuitive und konsistente Namenskonventionen. Administratoren und Nutzer können dadurch den Zweck jeder Ressource besser verstehen und wissen, wo sie diese finden und wie sie sich von anderen Ressourcen unterscheidet.

Konnektivitätstests zum Prüfen der Netzwerksicherheit verwenden

Im Kontext der Netzwerksicherheit können Sie durch Konnektivitätstests prüfen, ob Traffic, der zwischen zwei Endpunkten verhindert werden soll, blockiert wird. Definieren Sie einen Test zwischen zwei Endpunkten und bewerten Sie die Ergebnisse, um zu prüfen, ob und warum der Traffic blockiert wird. Beispiel: Sie können ein VPC-Feature testen, mit dem Sie Regeln zum Blockieren von traffic definieren können. Weitere Informationen finden Sie unter Konnektivitätstests – Übersicht.

Mit Private Service Connect private Endpunkte erstellen

Verwenden Sie Private Service Connect, um private Endpunkte zu erstellen, die Ihnen den Zugriff auf Google-Dienste mit Ihrem eigenen IP-Adressschema ermöglichen. Sie können innerhalb Ihrer VPC und über Hybridkonnektivität auf die privaten Endpunkte zugreifen, die in Ihrer VPC enden.

Externe Konnektivität sichern und einschränken

Beschränken Sie den Internetzugriff auf die Ressourcen, die diesen wirklich benötigen. Ressourcen, die nur eine private, interne IP-Adresse haben, können über den privaten Google-Zugriff weiterhin auf viele Google APIs und Google-Dienste zugreifen.

Network Intelligence zum Überwachen Ihrer Cloud-Netzwerke verwenden

Network Intelligence Center bietet eine umfassende Ansicht Ihrer Google Cloud-Netzwerke in allen Regionen. So können Sie Traffic- und Zugriffsmuster ermitteln, die operative oder Sicherheitsrisiken verursachen können.

Nächste Schritte

Erfahren Sie mehr über die Best Practices für die Speicherverwaltung, darunter:

• Wählen Sie einen Speichertyp.
• Wählen Sie Speicherzugriffsmuster und Arbeitslasttypen.

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Speicherstrategie wählen und implementieren

In diesem Dokument des Google Cloud-Architektur-Frameworks werden Best Practices für die Bereitstellung Ihres Systems auf Basis von Speicherüberlegungen vorgestellt. Sie erfahren, wie Sie eine Speicherstrategie wählen und Speicher, Zugriffsmuster und Arbeitslasten verwalten.

Um den Datenaustausch zu ermöglichen und Daten gefahrlos zu sichern und zu speichern, müssen Organisationen einen Speicherplan auswählen, basierend auf Arbeitslast, Ein-/Ausgabevorgängen pro Sekunde (IOPS), Latenz, Abrufhäufigkeit, Standort, Kapazität und Format (Block, Datei und Objekt).

Cloud Storage bietet zuverlässige, sichere Objektspeicherdienste, darunter:

• Integrierte Redundanzoptionen zum Schutz Ihrer Daten vor Geräteausfällen und zur Gewährleistung der Datenverfügbarkeit während der Wartung von Rechenzentren.
• Optionen zur Datenübertragung, darunter:
  • Storage Transfer Service
  • Transfer Appliance
  • BigQuery Data Transfer Service
  • Migration zu Google Cloud: Große Datasets übertragen
• Speicherklassen zur Unterstützung Ihrer Arbeitslasten.
• Berechnete Prüfsummen für alle Cloud Storage-Vorgänge, wodurch Google Lese- und Schreibvorgänge prüfen kann.

In Google Cloud wird der IOPS-Wert anhand des bereitgestellten Speicherplatzes skaliert. Speichertypen wie Persistent Disk erfordern eine manuelle Replikation und Sicherung, da sie zonal oder regional sind. Im Gegensatz dazu ist der Objektspeicher hochverfügbar und repliziert Daten automatisch in einer einzelnen Region oder in mehrere Regionen.

Speichertyp

Dieser Abschnitt enthält Best Practices zur Auswahl eines für Ihr System geeigneten Speichertyps.

Optionen für Hochleistungsspeicheranforderungen prüfen

Bewerten Sie nichtflüchtige Speicher oder lokale Solid-State-Laufwerke (SSD) für Rechenanwendungen, die Hochleistungsspeicher benötigen. Cloud Storage ist ein unveränderlicher Objektspeicher mit Versionsverwaltung. Die Verwendung von Cloud Storage mit Cloud CDN hilft bei der Kostenoptimierung, insbesondere bei häufig aufgerufenen statischen Objekten.

Filestore unterstützt Anwendungen mit mehreren Schreibvorgängen, die einen leistungsfähigen, gemeinsam genutzten Speicherplatz benötigen. Filestore unterstützt auch Legacy- und moderne Anwendungen, die POSIX-ähnliche Dateivorgänge über NFS-Bereitstellungen (Network File System) erfordern.

Cloud Storage unterstützt Anwendungsfälle wie das Erstellen von Data Lakes und die Erfüllung von Archivierungsanforderungen. Kompromisse bei der Auswahl der Cloud Storage-Klasse aufgrund des Zugriffs und des Abrufs, insbesondere wenn Sie Aufbewahrungsrichtlinien konfigurieren Weitere Informationen finden Sie unter Optimale Speicherstrategie für Ihre Cloudarbeitslast entwerfen.

Alle Speicheroptionen werden bei Inaktivität und während der Übertragung standardmäßig mit von Google verwalteten Schlüsseln verschlüsselt. Für Speichertypen wie Persistent Disk und Cloud Storage können Sie entweder Ihren eigenen Schlüssel bereitstellen oder diese über den Cloud Key Management Service (Cloud KMS) verwalten. Legen Sie eine Strategie für die Verarbeitung solcher Schlüssel fest, bevor Sie sie für Produktionsdaten verwenden.

Google Cloud-Dienste für Speicherdesign auswählen

Verwenden Sie folgende Tabelle, um mehr über die Google Cloud-Dienste zu erfahren, die das Speicherdesign unterstützen:

Google Cloud-Dienst	Beschreibung
Cloud Storage	Sie können jederzeit beliebige Datenmengen global speichern und abrufen. Sie können Cloud Storage für verschiedene Aufgaben verwenden, beispielsweise das Bereitstellen von Websiteinhalten, das Speichern von Daten für die Archivierung und Notfallwiederherstellung oder das Verteilen großer Datenobjekte an Nutzer über direkte Downloads. Hier finden Sie weitere Informationen: Best Practices für Cloud Storage Bucket-Standorte Speicherklassen Cloud Storage FUSE
Persistent Disk	Ein leistungsstarker Blockspeicher für Google Cloud Persistent Disk bietet SSD- und Festplattenspeicher (HDD), den Sie an Instanzen anhängen können, die in Compute Engine oder Google Kubernetes Engine (GKE) ausgeführt werden. Regionale Laufwerke bieten eine dauerhafte Speicherung und Replikation von Daten zwischen zwei Zonen in derselben Region. Wenn Sie einen höheren IOPS-Wert und eine niedrige Latenz benötigen, bietet Google Cloud dafür Filestore. Lokale SSDs sind direkt mit dem Server verbunden, der Ihre VM-Instanzen hostet. Sie können lokale SSDs als temporären Speicherplatz nutzen.
Filestore	Ein verwalteter Dateispeicherdienst für Anwendungen, die eine Dateisystemschnittstelle und ein freigegebenes Dateisystem für Daten benötigen. Filestore bietet Nutzern eine nahtlose Bereitstellung von verwaltetem NAS (Network Attached Storage) und dessen Compute Engine- und GKE-Instanzen.
Cloud Storage for Firebase	Für App-Entwickler gedacht, die nutzergenerierte Inhalte wie Fotos oder Videos speichern und bereitstellen müssen. Alle Dateien werden in Cloud Storage-Buckets gespeichert, sodass sie sowohl über Firebase als auch über Google Cloud zugänglich sind.

Speicherstrategie auswählen

Verwenden Sie folgende Tabelle, um eine Ihren Anwendungsanforderungen entsprechende Speicherstrategie zu wählen:

Anwendungsfall	Empfehlungen
Sie möchten Daten in geeigneter Skalierung zu den niedrigsten Kosten speichern; die Zugriffsleistung stellt kein Problem dar.	Cloud Storage
Sie führen Rechenanwendungen aus, die sofort verfügbaren Speicher benötigen. Weitere Informationen finden Sie unter Leistung von Persistent Disk und lokalen SSDs optimieren.	Persistent Disk oder lokale SSD
Sie führen leistungsstarke Arbeitslasten aus, die Lese- und Schreibzugriff auf freigegebenen Speicherplatz benötigen.	Filestore
Sie haben Anwendungsfälle, die Hochleistungs-Computing (HPC) oder High-Throughput-Computing (HTC) benötigen.	Cluster für umfassendes technisches Computing in der Cloud verwenden

Aktiv- oder Archivspeicher auf Basis der Speicherzugriffsanforderungen auswählen

Eine Speicherklasse ist ein Metadatenelement, das von jedem Objekt verwendet wird. Verwenden Sie für Daten, die mit hoher Rate und Hochverfügbarkeit bereitgestellt werden, die Klasse "Standard Storage". Verwenden Sie für Daten, auf die selten zugegriffen wird und für die eine etwas geringere Verfügbarkeit genügt, die Klasse "Nearline Storage", "Coldline Storage" oder "Archive Storage". Weitere Informationen zu den Kosten für die Auswahl einer Speicherklasse finden Sie unter Cloud Storage-Preise.

Anforderungen an Speicherorte und Datenschutz für Cloud Storage prüfen

Bei einem Cloud Storage-Bucket in einer Region werden die darin enthaltenen Daten automatisch zonenübergreifend in der Region repliziert. Die zonenübergreifende Datenreplikation schützt Daten, falls innerhalb einer Region ein zonaler Ausfall auftritt.

Cloud Storage bietet auch Standorte, die über Regionen hinweg redundant sind. Das bedeutet, dass Daten über mehrere, geografisch getrennte Rechenzentren repliziert werden. Weitere Informationen finden Sie unter Bucket-Standorte.

Mit Cloud CDN die statische Objektbereitstellung verbessern

Verwenden Sie Cloud CDN, um die Kosten für das Abrufen von Objekten zu optimieren und die Zugriffslatenz zu minimieren. Cloud CDN nutzt den externen Application Load Balancer von Cloud Load Balancing, um Routing, Systemdiagnosen und Anycast-IP-Adressen zu unterstützen. Weitere Informationen finden Sie unter Cloud CDN mit Cloud-Buckets einrichten.

Speicherzugriffsmuster und Arbeitslasttyp

Dieser Abschnitt enthält Best Practices zur Auswahl von Speicherzugriffsmustern und Arbeitslasttypen, die zu Ihrem System passen.

Nichtflüchtigen Speicher für Hochleistungsspeicherzugriff verwenden

Datenzugriffsmuster hängen davon ab, wie Sie die Systemleistung gestalten. Cloud Storage bietet skalierbaren Speicher, ist jedoch keine ideale Wahl, wenn Sie hohe Rechenarbeitslasten ausführen, die einen hohen Durchsatz für den Zugriff auf große Datenmengen benötigen. Verwenden Sie für den leistungsstarken Speicherzugriff nichtflüchtigen Speicher.

Exponentiellen Backoff bei der Implementierung einer Wiederholungslogik verwenden

Verwenden Sie exponentiellen Backoff, wenn Sie die Wiederholungslogik zur Behandlung der Fehler 5XX, 408 und 429 implementieren. Jeder Cloud Storage-Bucket wird mit einer anfänglichen E/A-Kapazität bereitgestellt. Weitere Informationen finden Sie unter Richtlinien für die Anforderungsrate und Zugriffsverteilung. Planen Sie eine schrittweise Erhöhung bei Wiederholungsanfragen.

Speicherverwaltung

Dieser Abschnitt enthält Best Practices zur Speicherverwaltung zur Unterstützung Ihres Systems.

Jedem Bucket eindeutige Namen zuweisen

Achten Sie darauf, dass jeder Bucket-Name im Cloud Storage-Namespace einmalig ist. Der Bucket-Name darf keine vertraulichen Informationen enthalten. Wählen Sie Bucket- und Objektnamen, die schwer zu erraten sind. Weitere Informationen finden Sie in den Benennungsrichtlinien für Buckets und in den Benennungsrichtlinien für Objekte.

Cloud Storage-Buckets privat halten

Achten Sie darauf, dass Ihr Cloud Storage-Bucket weder anonym noch öffentlich zugänglich ist, es sei denn, es gibt dafür einen geschäftlichen Grund. Weitere Informationen finden Sie unter Zugriffssteuerung.

Zufällige Objektnamen zuweisen, um die Last gleichmäßig zu verteilen

Weisen Sie zufällige Objektnamen zu, um die Leistung zu vereinfachen und Hotspots zu vermeiden. Verwenden Sie nach Möglichkeit ein zufälliges Präfix für Objekte. Weitere Informationen finden Sie unter Namenskonvention verwenden, um die Last gleichmäßig über die Schlüsselbereiche zu verteilen.

Verweigerung des öffentlichen Zugriffs verwenden

Nutzen Sie die Verweigerung des öffentlichen Zugriffs, um den Zugriff auf Organisations-, Ordner-, Projekt- oder Bucket-Ebene zu verhindern. Weitere Informationen finden Sie unter Verweigerung des Öffentliche Zugriffs verwenden.

Nächste Schritte

Informationen zu Google Cloud-Datenbankdiensten und Best Practices, darunter:

• Auswahl und Migration Ihrer Datenbank.
• Verwaltung der Datenbankverschlüsselung.
• Verwaltung von Netzwerk und Zugriff für die Datenbank.

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Datenbank optimieren

In diesem Dokument des Google Cloud-Architektur-Frameworks werden Best Practices für die Bereitstellung Ihres Systems auf Basis des Datenbankdesigns vorgestellt. Sie erfahren, wie Sie Datenbanken entwerfen, migrieren und skalieren, Datenbankinformationen verschlüsseln, die Lizenzierung verwalten und Ihre Datenbank auf Ereignisse überwachen.

Vorteile

In diesem Dokument der Architektur-Framework-Systemdesignkategorie werden Best Practices für verschiedene Google Cloud-Datenbankdienste vorgestellt. Die folgende Tabelle gibt einen allgemeinen Überblick über diese Dienste:

Google Cloud-Dienst	Beschreibung
Cloud SQL	Ein vollständig verwalteter Datenbankdienst, mit dem Sie Ihre relationalen Datenbanken einrichten, pflegen und verwalten können, die Cloud SQL for PostgreSQL, Cloud SQL for MySQL und Cloud SQL for SQL Server verwenden. Cloud SQL bietet hohe Leistung und Skalierbarkeit. Cloud SQL wird auf Google Cloud gehostet und bietet eine Datenbankinfrastruktur, mit der Anwendungen überall ausgeführt werden können.
Bigtable	Eine Tabelle, die auf Milliarden von Zeilen und Tausende von Spalten skaliert werden kann, sodass Sie bis zu Petabyte an Daten speichern können. Ein einzelner Wert in jeder Zeile ist indexiert. Dieser Wert wird als Zeilenschlüssel bezeichnet. Verwenden Sie Bigtable zum Speichern von großen Datenmengen mit einem Schlüssel bei kleiner Latenz. Cloud Bigtable unterstützt einen hohen Durchsatz an Lese- und Schreibvorgängen bei kleiner Latenz und ist eine Datenquelle für MapReduce-Vorgänge.
Spanner	Ein skalierbarer, global verteilter Unternehmensdatenbankdienst, der für die Cloud entwickelt wurde und eine relationale Datenbankstruktur und nicht relationale horizontale Skalierung umfasst. Diese Kombination bietet leistungsstarke Transaktionen und Konsistenz über Zeilen, Regionen und Kontinente hinweg. Spanner bietet ein SLA mit einer Verfügbarkeit von 99,999 %, keine geplanten Ausfallzeiten und Sicherheit auf Unternehmensniveau.
Memorystore	Ein vollständig verwalteter Redis-Dienst für Google Cloud. Anwendungen, die in Google Cloud ausgeführt werden, können mithilfe des hochverfügbaren, skalierbaren und sicheren Redis-Dienstes die Leistung erhöhen, ohne komplexe Redis-Bereitstellungen zu verwalten.
Firestore	Eine NoSQL-Dokumentendatenbank, die für Autoscaling, hohe Leistung und einfache Anwendungsentwicklung konzipiert ist. Firestore hat zwar hinsichtlich der Benutzeroberfläche viele Features mit traditionellen Datenbanken gemeinsam, ist jedoch eine NoSQL-Datenbank und beschreibt Beziehungen zwischen Datenobjekten anders.
Firebase Realtime Database	Eine in der Cloud gehostete Datenbank. Firebase speichert Daten als JSON und wird in Echtzeit mit jedem verbundenen Client synchronisiert. Wenn Sie plattformübergreifende Anwendungen mit Google-, iOS-, Android- und JavaScript-SDKs erstellen, nutzen alle Ihre Clients dieselbe Echtzeit-Datenbankinstanz und erhalten automatisch Updates mit den neuesten Daten.
Open-Source-Datenbanken	Google-Partner bieten verschiedene Open-Source-Datenbanken, einschließlich MongoDB, MariaDB und Redis.
AlloyDB for PostgreSQL	Ein vollständig verwalteter PostgreSQL-kompatibler Datenbankdienst für anspruchsvolle Unternehmensarbeitslasten. Bietet eine bis zu viermal höhere Geschwindigkeit bei transaktionalen Arbeitslasten und bis zu 100-mal schnellere analytische Abfragen im Vergleich zu Standard-PostgreSQL. AlloyDB for PostgreSQL vereinfacht die Verwaltung über Autopilotsysteme mit maschinellem Lernen.

Datenbankauswahl

Dieser Abschnitt enthält Best Practices für die Auswahl einer Datenbank zur Unterstützung Ihres Systems.

Verwalteten Datenbankdienst verwenden

Bewerten Sie die verwalteten Datenbankdienste von Google Cloud, bevor Sie Ihre eigene Datenbank oder Ihren eigenen Datenbankcluster installieren. Die Installation Ihrer eigenen Datenbank ist mit Wartungsaufwand verbunden, u. a. durch die Installation von Patches und Updates sowie der Verwaltung täglicher operativer Aktivitäten wie dem Monitoring und Ausführen von Sicherungen.

Verwenden Sie funktionale und nicht funktionale Anwendungsanforderungen für die Datenbankauswahl. Berücksichtigen Sie Zugriff mit niedriger Latenz, die Verarbeitung von Zeitachsendaten, die Notfallwiederherstellung und die Synchronisierung mobiler Clients.

Verwenden Sie zum Migrieren von Datenbanken eines der in der folgenden Tabelle beschriebenen Produkte:

Produkt für die Datenbankmigration	Beschreibung
Cloud SQL	Ein regionaler Dienst, der Lesereplikate in entfernten Regionen, Lesevorgänge mit niedriger Latenz und Notfallwiederherstellung unterstützt.
Spanner	Ein multiregionales Angebot, das externe Konsistenz, globale Replikation und ein SLA mit einer Verfügbarkeit von 99,999 % bietet.
Bigtable	Vollständig verwalteter, skalierbarer NoSQL-Datenbankdienst für große analytische und operative Arbeitslasten mit bis zu 99,999 % Verfügbarkeit.
Memorystore	Ein vollständig verwalteter Datenbankdienst, der eine verwaltete Version von zwei beliebten Open-Source-Caching-Lösungen bereitstellt: Redis und Memcached.
Firebase Realtime Database	Die Firebase Realtime Database ist eine in der Cloud gehostete NoSQL-Datenbank, mit der Sie Daten in Echtzeit speichern und unter Nutzern synchronisieren können.
Firestore	Eine NoSQL-Dokumentendatenbank, die auf Autoscaling, hohe Leistung und einfache Anwendungsentwicklung ausgelegt ist.
Open Source	Alternative Datenbankoptionen wie MongoDB und MariaDB

Datenbankmigration

Damit Nutzer keine Ausfallzeiten von Anwendungen erleben, wenn Sie vorhandene Arbeitslasten zu Google Cloud migrieren, ist es wichtig, Datenbanktechnologien auszuwählen, die Ihre Anforderungen unterstützen. Informationen zu Optionen für die Datenbankmigration und Best Practices finden Sie unter Lösungen für die Datenbankmigration und Best Practices für homogene Datenbankmigrationen.

Die Planung einer Datenbankmigration umfasst Folgendes:

• Aktuelle Datenbank bewerten und erkennen
• Erfolgskriterien für die Migration definieren
• Umgebung für die Migration und die Zieldatenbank einrichten
• Schema in der Zieldatenbank erstellen
• Daten in die Zieldatenbank migrieren
• Migration validieren, um zu überprüfen, ob alle Daten ordnungsgemäß migriert wurden und in der Datenbank vorhanden sind
• Rollback-Strategie erstellen

Migrationsstrategie auswählen

Die Auswahl der entsprechenden Zieldatenbank ist einer der Schlüssel für eine erfolgreiche Migration. Die folgende Tabelle enthält Migrationsoptionen für einige Anwendungsfälle:

Anwendungsfall	Empfehlung
Neue Entwicklung in Google Cloud	Wählen Sie eine der verwalteten Datenbanken aus, die für die Cloud entwickelt wurden – Cloud SQL, Spanner, Bigtable oder Firestore –, um die Anforderungen Ihres Anwendungsfalls zu erfüllen.
Lift-and-Shift-Migration	Wählen Sie einen kompatiblen verwalteten Datenbankdienst wie Cloud SQL, MYSQL, PostgreSQL oder SQLServer aus.
Ihre Anwendung erfordert detaillierten Zugriff auf eine Datenbank, die von CloudSQL nicht unterstützt wird.	Führen Sie Ihre Datenbank auf Compute Engine-VMs aus.

Memorystore zur Unterstützung der Caching-Datenbankebene verwenden

Memorystore ist eine vollständig verwaltete Redis- und Memcached-Datenbank, die Latenzen unter einer Millisekunde unterstützt. Memorystore ist vollständig mit Open-Source-Redis und -Memcached kompatibel. Wenn Sie diese Caching-Datenbanken in Ihren Anwendungen verwenden, können Sie Memorystore nutzen, ohne im Code Änderungen auf Anwendungsebene vorzunehmen.

Bare-Metal-Server zum Ausführen einer Oracle-Datenbank verwenden

Wenn Ihre Arbeitslasten eine Oracle-Datenbank erfordern, verwenden Sie Bare-Metal-Server von Google Cloud. Dieser Ansatz passt zu einer Lift-and-Shift-Migrationsstrategie.

Wenn Sie Ihre Arbeitslast in Google Cloud verschieben und modernisieren möchten, nachdem Ihre Basisarbeitslast funktioniert, dann sollten Sie verwaltete Datenbankoptionen wie Spanner, Bigtable und Firestore verwenden.

Für die Cloud entwickelte Datenbanken sind moderne verwaltete Datenbanken, die von Grund auf in der Cloud-Infrastruktur erstellt werden. Diese Datenbanken bieten besondere Standardfunktionen wie Skalierbarkeit und Hochverfügbarkeit, die mit einer eigenen Datenbank nur schwer erreichen lassen.

Datenbank modernisieren

Planen Sie Ihre Datenbankstrategie frühzeitig im Systemdesignprozess, unabhängig davon, ob Sie eine neue Anwendung in der Cloud entwerfen oder eine vorhandene Datenbank in die Cloud migrieren. Google Cloud bietet verwaltete Datenbankoptionen für Open-Source-Datenbanken wie Cloud SQL for MySQL und Cloud SQL for PostgreSQL. Wir empfehlen die Verwendung der Migration als Gelegenheit, Ihre Datenbank zu modernisieren und auf zukünftige Geschäftsanforderungen vorzubereiten.

Feste Datenbanken mit Standardanwendungen verwenden

COTS-Anwendungen (Commercial off-the-shelf) erfordern einen festen Datenbanktyp und eine feste Konfiguration. Lift-and-Shift ist in der Regel der am besten geeignete Migrationsansatz für COTS-Anwendungen.

Das Wissen Ihres Teams über Datenbankmigration überprüfen

Wählen Sie einen Cloud-Datenbank-Migrationsansatz auf der Grundlage der Datenbankmigrationsfunktionen und -qualifikationen Ihres Teams aus. Mit Google Cloud Partner Advantage finden Sie einen Partner, der Sie bei Ihrer Migration unterstützt.

Datenbank so entwickeln, dass sie die Anforderungen hinsichtlich Hochverfügbarkeit und Notfallwiederherstellung erfüllt

Wenn Sie Ihre Datenbanken so gestalten, dass sie Hochverfügbarkeitsanforderungen und Notfallwiederherstellungsanforderungen (Disaster Recovery, DR) erfüllen, bewerten Sie die Kompromisse zwischen Zuverlässigkeit und Kosten. Datenbankdienste, die für die Cloud erstellt wurden, erstellen je nach Datenbank und Konfiguration mehrere Kopien Ihrer Daten innerhalb einer Region oder in mehreren Regionen.

Einige Google Cloud-Dienste haben multiregionale Varianten, z. B. BigQuery und Spanner. Verwenden Sie nach Möglichkeit diese multiregionalen Dienste in Ihrem Design, um es vor regionalen Ausfällen zu schützen.

Wenn Sie die Datenbank auf Compute Engine-VMs entwerfen, anstatt verwaltete Datenbanken in Google Cloud zu verwenden, führen Sie mehrere Kopien Ihrer Datenbanken aus. Weitere Informationen finden Sie unter Bei der Entwicklung für Skalierung und Hochverfügbarkeit sorgen in der Kategorie "Zuverlässigkeit".

Cloud-Regionen angeben, um den Datenstandort zu unterstützen

Der Datenstandort beschreibt, wo sich Ihre inaktiven Daten befinden. Denken Sie darüber nach, bestimmte Cloud-Regionen auszuwählen, um Ihre Datenbanken anhand Ihrer Anforderungen an den Datenstandort bereitzustellen.

Wenn Sie Ihre Datenbanken in mehreren Regionen bereitstellen, kann es zu einer Datenreplikation zwischen ihnen kommen, je nachdem, wie Sie sie konfigurieren. Wählen Sie die Konfiguration aus, die Ihre Daten im Ruhezustand in den gewünschten Regionen hält. Einige Datenbanken wie Spanner bieten eine multiregionale Standardreplikation. Sie können den Datenstandort auch durch Festlegen einer Organisationsrichtlinie erzwingen, die Einschränkungen für die Ressourcenstandorte enthält. Weitere Informationen finden Sie unter Ressourcenstandorte einschränken.

Notfallwiederherstellung in das Design von Datenstandorten einbeziehen

Nehmen Sie RTO (Recovery Time Objective) und RPO (Recovery Point Objective) in Ihre Datenstandortpläne auf und berücksichtigen Sie den Kompromiss zwischen RTO/RPO und den Kosten der Notfallwiederherstellungslösung. Kleinere RTO-/RPO-Zahlen führen zu höheren Kosten. Wenn Sie möchten, dass das System nach Unterbrechungen schneller wiederhergestellt wird, erhöhen sich die Betriebskosten. Berücksichtigen Sie auch die Zufriedenheit der Kunden bei Ihrem Ansatz der Notfallwiederherstellung, damit Ihre Zuverlässigkeitsinvestitionen angemessen sind. Weitere Informationen finden Sie unter 100 % Zuverlässigkeit ist das falsche Ziel und Leitfaden zur Planung der Notfallwiederherstellung.

Datenbank Google Cloud-konform machen

Wenn Sie eine Datenbank für Ihre Arbeitslast auswählen, achten Sie darauf, dass der ausgewählte Dienst den Complianceanforderungen der geografischen Region entspricht, in der Sie sich befinden und in der Ihre Daten physisch gespeichert werden. Weitere Informationen zu den Zertifizierungen und Compliance-Standards von Google finden Sie unter Compliance-Angebote.

Verschlüsselung

Dieser Abschnitt enthält Best Practices zum Identifizieren der Verschlüsselungsanforderungen und zum Auswählen einer Strategie für Verschlüsselungsschlüssel, um Ihr System zu unterstützen.

Verschlüsselungsanforderungen festlegen

Die Verschlüsselungsanforderungen hängen von mehreren Faktoren ab, z. B. von den Sicherheitsrichtlinien des Unternehmens und von Compliance-Anforderungen. Alle in Google Cloud gespeicherten Daten werden standardmäßig ruhend mit AES256 verschlüsselt, ohne dass Sie etwas tun müssen. Weitere Informationen finden Sie unter Verschlüsselung inaktiver Daten in Google Cloud.

Strategie für Verschlüsselungsschlüssel auswählen

Entscheiden Sie, ob Sie Verschlüsselungsschlüssel selbst verwalten oder einen verwalteten Dienst verwenden möchten. Google Cloud unterstützt beide Szenarien. Wenn Sie einen vollständig verwalteten Dienst zum Verwalten Ihrer Verschlüsselungsschlüssel in Google Cloud verwenden möchten, wählen Sie Cloud Key Management Service (Cloud KMS) aus. Wenn Sie Ihre Verschlüsselungsschlüssel verwalten möchten, um mehr Kontrolle über den Lebenszyklus eines Schlüssels zu haben, können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Wählen Sie eine der folgenden Optionen aus, um Ihre Verschlüsselungsschlüssel außerhalb von Google Cloud zu erstellen und zu verwalten:

• Wenn Sie Ihre Schlüssel mit einer Partnerlösung verwalten, verwenden Sie Cloud External Key Manager.
• Wenn Sie Ihre Schlüssel lokal verwalten und diese Schlüssel zum Verschlüsseln der Daten in Google Cloud verwenden möchten, importieren Sie diese Schlüssel in Cloud KMS entweder als KMS-Schlüssel oder HSM-Schlüssel (Hardware Key Module). Verwenden Sie diese Schlüssel zum Verschlüsseln Ihrer Daten in Google Cloud.

Datenbankdesign und -skalierung

Dieser Abschnitt enthält Best Practices zum Entwerfen und Skalieren einer Datenbank zur Unterstützung Ihres Systems.

Skalierungsmesswerte mithilfe von Monitoring-Messwerten bewerten

Verwenden Sie Messwerte aus vorhandenen Monitoring-Tools und -Umgebungen, um eine Grundlage für das Verständnis der Datenbankgröße und der Skalierungsanforderungen zu bilden, z. B. Größenanpassung und Design von Skalierungsstrategien für die Datenbankinstanz.

Bestimmen Sie bei neuen Datenbankdesigns die Skalierungszahlen anhand der erwarteten Last- und Traffic-Muster der Bereitstellungsanwendung. Weitere Informationen finden Sie unter Cloud SQL-Instanzen überwachen, Monitoring mit Cloud Monitoring und Instanz überwachen.

Netzwerk und Zugriff

Dieser Abschnitt enthält Best Practices zum Verwalten des Netzwerks und des Zugriffs für Ihr System.

Datenbanken in einem privaten Netzwerk ausführen

Führen Sie die Datenbanken in Ihrem privaten Netzwerk aus und gewähren Sie eingeschränkten Zugriff nur bei Clients, die mit der Datenbank interagieren müssen. Sie können Cloud SQL-Instanzen in einer VPC erstellen. Google Cloud bietet außerdem VPC Service Controls für Cloud SQL-, Spanner- und Bigtable-Datenbanken, damit der Zugriff auf diese Ressourcen nur für Clients in autorisierten VPC-Netzwerken möglich ist.

Nutzern Mindestberechtigungen gewähren

Identity and Access Management (IAM) steuert den Zugriff auf Google Cloud-Dienste, einschließlich Datenbankdiensten. Um das Risiko eines nicht autorisierten Zugriffs zu minimieren, gewähren Sie Ihren Nutzern die geringstmögliche Anzahl an Berechtigungen. Verwenden Sie für den Zugriff auf Datenbanken auf Anwendungsebene Dienstkonten mit der geringsten Anzahl an Berechtigungen.

Automatisierung und Größenanpassung

Dieser Abschnitt enthält Best Practices zum Definieren der Automatisierung und Größenanpassung zur Unterstützung Ihres Systems.

Datenbankinstanzen als Code definieren

Einer der Vorteile der Migration zu Google Cloud ist die Möglichkeit, Ihre Infrastruktur und andere Aspekte Ihrer Arbeitslast zu automatisieren, z. B. Rechen- und Datenbankebenen. Mit Google Deployment Manager und Tools von Drittanbietern wie Terraform Cloud können Sie Ihre Datenbankinstanzen als Code definieren, sodass Sie einen konsistenten und wiederholbaren Ansatz zum Erstellen und Aktualisieren von Datenbanken anwenden können.

Liquibase zur Versionsverwaltung der Datenbank verwenden

Google-Datenbankdienste wie Cloud SQL und Spanner unterstützen Liquibase, ein Open-Source-Tool zur Versionsverwaltung für Datenbanken. Mit Liquibase können Sie Änderungen am Datenbankschema verfolgen, Rollbacks für Schemaänderungen durchführen und wiederholbare Migrationen vornehmen.

Datenbank testen und optimieren, um Skalierung zu unterstützen

Führen Sie Lasttests für Ihre Datenbankinstanz durch und passen Sie sie basierend auf den Testergebnissen an die Anforderungen Ihrer Anwendung an. Bestimmen Sie den anfänglichen Umfang der Datenbank. Verwenden Sie dafür Leistungskennzahlen (KPIs) der Lasttests oder verwenden Sie aus der aktuellen Datenbank abgeleitete Monitoring-KPIs.

Beginnen Sie beim Erstellen von Datenbankinstanzen mit einer Größe, die auf den Testergebnissen oder historischen Monitoring-Messwerten basiert. Testen Sie Ihre Datenbankinstanzen mit der erwarteten Last in der Cloud. Optimieren Sie dann die Instanzen, bis Sie die gewünschten Ergebnisse für die erwartete Last auf Ihren Datenbankinstanzen erhalten.

Die richtige Datenbank für Ihre Skalierungsanforderungen auswählen

Die Skalierung von Datenbanken unterscheidet sich von der Skalierung von Komponenten der Rechenebene. Datenbanken haben einen Zustand. Wenn eine Instanz Ihrer Datenbank die Last nicht bewältigen kann, sollten Sie über die geeignete Strategie zum Skalieren Ihrer Datenbankinstanzen nachdenken. Die Skalierungsstrategien variieren je nach Datenbanktyp.

In der folgenden Tabelle erfahren Sie mehr über Google-Produkte für verschiedene Anwendungsfälle für die Skalierung.

Anwendungsfall	Empfohlenes Produkt	Beschreibung
Skalieren Sie Ihre Datenbankinstanz horizontal, indem Sie Ihrer Datenbank Knoten hinzufügen, wenn Sie die Bereitstellungskapazität und den Speicher hochskalieren müssen.	Spanner	Eine relationale Datenbank, die für die Cloud entwickelt wurde.
Fügen Sie Knoten hinzu, um Ihre Datenbank zu skalieren.	Bigtable	Ein vollständig verwalteter NoSQL-Big-Data-Datenbankdienst.
Automatische Skalierung der Datenbank.	Firestore	Flexible, skalierbare Datenbank für Mobil-, Web- und Serverentwicklung.
Wenn Sie mehr Abfragen verarbeiten möchten, können Sie Cloud SQL-Datenbankinstanzen vertikal skalieren, um mehr Rechen- und Speicherkapazität zu bieten. In Cloud SQL ist die Speicherebene von der Datenbankinstanz entkoppelt. Sie können Ihre Speicherebene automatisch skalieren, wenn sie sich dem Kapazitätslimit nähert.	Cloud SQL	Ein vollständig verwalteter Datenbankdienst, mit dem Sie Ihre relationalen Datenbanken in Google Cloud einrichten, pflegen und verwalten können.

Vorgänge

Dieser Abschnitt enthält Best Practices für Vorgänge zur Unterstützung Ihres Systems.

Cloud Monitoring zur Überwachung und Einrichtung von Benachrichtigungen für Ihre Datenbank verwenden

Mit Cloud Monitoring können Sie Ihre Datenbankinstanzen überwachen und Benachrichtigungen einrichten, um die entsprechenden Teams über Ereignisse zu informieren. Informationen zu Best Practices für effiziente Benachrichtigungen finden Sie unter Effiziente Benachrichtigungen erstellen.

Alle für die Cloud entwickelten Datenbanken bieten Logging- und Monitoring-Messwerte. Jeder Dienst bietet ein Dashboard zur Visualisierung von Logging- und Monitoring-Messwerten. Die Monitoring-Messwerte für alle Dienste sind in die Operations-Suite von Google Cloud eingebunden. Spanner bietet Tools zur Abfrageüberprüfung wie Key Visualizer zum Debugging und zur Ursachenanalyse. Key Visualizer bietet die folgenden Funktionen:

• Hilft Ihnen bei der Analyse von Spanner-Nutzungsmustern, indem visuelle Berichte für Ihre Datenbanken generiert werden. In den Berichten werden Nutzungsmuster nach Zeilenbereichen im Zeitverlauf angezeigt.
• Umfassende Einblicke in Nutzungsmuster.

Bigtable bietet auch ein Key Visualizer-Diagnosetool, mit dem Sie Bigtable-Instanznutzungsmuster analysieren können.

Lizenzen

Dieser Abschnitt enthält Best Practices zur Lizenzierung, um Ihr System zu unterstützen.

On-Demand-Lizenzen oder vorhandene Lizenzen auswählen

Wenn Sie Cloud SQL for SQL Server verwenden, wird das Verwenden eigener Lizenzen nicht unterstützt. Die Lizenzkosten basieren auf der Stundennutzung pro Kern.

Wenn Sie vorhandene Lizenzen für Cloud SQL for SQL Server verwenden möchten, sollten Sie Cloud SQL for SQL Server auf Compute-VMs ausführen. Weitere Informationen finden Sie unter Microsoft-Lizenzen und On-Demand-Lizenzen auswählen oder eigene Lizenzen verwenden.

Wenn Sie Oracle verwenden und zur Bare-Metal-Lösung für Oracle migrieren, können Sie Ihre eigenen Lizenzen verwenden. Weitere Informationen finden Sie unter Bare-Metal-Lösung planen.

Zeitpläne, Methoden und Toolsets für die Migration

Dieser Abschnitt enthält Best Practices zur Planung und Unterstützung der Datenbankmigration, um Ihr System zu unterstützen.

Bereitschaft für Datenbankmodernisierung ermitteln

Prüfen Sie, ob Ihre Organisation bereit ist, Ihre Datenbanken zu modernisieren und Datenbanken zu verwenden, die für die Cloud entwickelt wurden.

Ziehen Sie eine Datenbankmodernisierung in Betracht, wenn Sie Zeitpläne für die Migration der Arbeitslast planen, da die Modernisierung wahrscheinlich Auswirkungen auf Seiten der Anwendung hat.

Relevante Stakeholder in die Migrationsplanung einbeziehen

Führen Sie die folgenden Aufgaben aus, um eine Datenbank zu migrieren:

• Zieldatenbanken einrichten
• Das Schema konvertieren
• Datenreplikation zwischen der Quell- und Zieldatenbank einrichten
• Probleme beheben, die während der Migration auftreten
• Netzwerkverbindung zwischen der Anwendungsebene und der Datenbank herstellen
• Sicherheit für die Zieldatenbank implementieren
• Prüfen, ob die Anwendungen eine Verbindung zu den Zieldatenbanken herstellen

Diese Aufgaben erfordern oft unterschiedliche Kompetenzen und mehrere Teams in Ihrer Organisation arbeiten zusammen, um die Migration abzuschließen. Beziehen Sie bei der Planung der Migration Beteiligte aus allen Teams ein, z. B. Anwendungsentwickler, Datenbankadministratoren sowie Infrastruktur- und Sicherheitsteams.

Wenn Ihr Team keine Fähigkeiten zur Unterstützung dieser Art von Migration hat, können die Partner von Google Sie bei der Migration unterstützen. Weitere Informationen finden Sie unter Google Cloud Partner Advantage.

Tools für homogene und heterogene Migrationen identifizieren

Eine homogene Migration ist eine Datenbankmigration zwischen den Quell- und Zieldatenbanken derselben Datenbanktechnologie. Eine heterogene Migration ist eine Migration, deren Zieldatenbank von der Quelldatenbank abweicht.

Heterogene Migrationen umfassen in der Regel zusätzliche Schritte der Schemakonvertierung von der Quelldatenbank zum Typ der Zieldatenbankmoduls. Ihre Datenbankteams müssen die Herausforderungen bei der Schemakonvertierung bewerten, da sie von der Komplexität des Quelldatenbankschemas abhängen.

Jeden Schritt der Datenmigration testen und validieren

Datenmigrationen umfassen mehrere Schritte. Testen und validieren Sie jeden Schritt der Migration, bevor Sie mit dem nächsten Schritt fortfahren, um Migrationsfehler zu minimieren. Die folgenden Faktoren bestimmen den Migrationsprozess:

• Ist die Migration homogen oder heterogen?
• Welche Tools und Kompetenzen benötigen Sie für die Migration?
• Bei heterogenen Migrationen Ihre Erfahrung mit dem Zieldatenbankmodul.

Anforderungen für kontinuierliche Datenreplikation bestimmen

Erstellen Sie einen Plan zur ersten Migration der Daten und replizieren Sie dann die Daten kontinuierlich aus der Quelle in die Zieldatenbank. Fahren Sie mit der Replikation fort, bis das Ziel stabilisiert ist und die Anwendung vollständig zur neuen Datenbank migriert wurde. Mit diesem Plan können Sie potenzielle Ausfallzeiten beim Datenbankwechsel ermitteln und entsprechend planen.

Wenn Sie Datenbankmodule von Cloud SQL, Cloud SQL für MySQL oderCloud SQL für PostgreSQL migrieren möchten, verwenden Sie Database Migration Service, um diesen Prozess vollständig zu automatisieren. Informationen zu Tools von Drittanbietern, die andere Migrationstypen unterstützen, finden Sie unter Cloud Marketplace.

Empfehlungen

Befolgen Sie diese Empfehlungen, um die Anleitung im Architektur-Framework auf Ihre eigene Umgebung anzuwenden:

• Mandantenfähigkeit für Datenbanken umfasst das Speichern von Daten von mehreren Kunden in einer gemeinsam genutzten Infrastruktur, in diesem Fall in einer Datenbank. Wenn Sie Ihren Kunden ein SaaS-basiertes (Software as a Service) Angebot machen, müssen Sie wissen, wie Sie Datasets, die zu verschiedenen Kunden gehören, logisch isolieren und ihre Zugriffsanforderungen unterstützen können. Bewerten Sie Ihre Anforderungen außerdem anhand der Trennungsebenen.

  Für relationale Datenbanken wie Spanner und Cloud SQL gibt es mehrere Ansätze wie das Isolieren der Daten von Mandanten auf Datenbankinstanz-, Datenbank-, Schema- oder Datenbanktabellenebene. Wie bei anderen Designentscheidungen muss ein Kompromiss zwischen dem Isolationsgrad und anderen Faktoren wie Kosten und Leistung eingegangen werden. IAM-Richtlinien steuern den Zugriff auf Ihre Datenbankinstanzen.

• Wählen Sie die richtige Datenbank für Ihre Datenmodellanforderungen aus.

• Wählen Sie Schlüsselwerte aus, um ein Heißlaufen (Hotspotting) von Schlüsseln zu vermeiden. Ein Hotspot ist ein Ort innerhalb einer Tabelle, der deutlich mehr Zugriffsanfragen als andere Orte erhält. Weitere Informationen zu Hotspots finden Sie unter Best Practices für Schemadesign.

• Fragmentieren Sie Ihre Datenbankinstanz, wenn möglich.

• Greifen Sie auf Best Practices für das Verbindungsmanagement zurück, z. B. Verbindungs-Pooling und exponentiellen Backoff.

• Vermeiden Sie sehr große Transaktionen.

• Konfigurieren und testen Sie die Reaktion Ihrer Anwendung auf Wartungsupdates für Datenbanken.

• Sichern und isolieren Sie die Verbindungen zu Ihrer Datenbank.

• Passen Sie die Größe Ihrer Datenbank und Wachstumserwartungen an, um sicherzustellen, dass die Datenbank Ihre Anforderungen erfüllt.

• Testen Sie Ihre Failover-Strategien für Hochverfügbarkeit und Notfallwiederherstellung.

• Führen Sie Sicherungen und Wiederherstellungen sowie Exporte und Importe durch, damit Sie mit dem Prozess vertraut sind.

Cloud SQL-Empfehlungen

• Verwenden Sie ein privates IP-Adressnetzwerk (VPC). Beachten Sie für zusätzliche Sicherheit Folgendes:
  • Verwenden Sie den Cloud SQL Auth Proxy, um private Netzwerke zu unterstützen.
  • Schränken Sie den Zugriff über öffentliche IP-Adressen ein (constraints/sql.restrictPublicIp).
• Wenn Sie ein öffentliches IP-Adressnetzwerk benötigen, beachten Sie Folgendes:
  • Verwenden Sie die integrierte Firewall mit einer eingeschränkten oder kleinen IP-Adressliste und achten Sie darauf, dass eingehende Verbindungen auf Cloud SQL-Instanzen nur über SSL möglich sind. Weitere Informationen finden Sie unter SSL/TLS-Zertifikate konfigurieren.
• Beachten Sie für zusätzliche Sicherheit Folgendes:
  • Gewähren Sie keinen allgemeinen Zugriff, sondern verwenden Sie stattdessen den Cloud SQL Auth-Proxy.
  • Schränken Sie autorisierte Netzwerke ein constraints/sql.restrictAuthorizedNetworks.
• Verwenden Sie eingeschränkte Berechtigungen für Datenbanknutzer.

Nächste Schritte

Informationen zu Best Practices für die Datenanalyse, darunter:

• Weitere Informationen zu den Grundsätzen der Datenanalyse und den wichtigsten Google Cloud-Diensten
• Informationen zum Datenlebenszyklus
• Daten aufnehmen
• Datenspeicherung auswählen und verwalten
• Daten verarbeiten und transformieren

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Daten analysieren

In diesem Dokument des Google Cloud-Architektur-Frameworks werden einige Grundprinzipien und Best Practices für Datenanalysen in Google Cloud erläutert. Sie erfahren mehr über einige der wichtigsten Datenanalysedienste und dazu, wie sie in den verschiedenen Phasen des Datenlebenszyklus helfen können. Mit diesen Best Practices können Sie Ihre Datenanalyseanforderungen erfüllen und Ihr Systemdesign erstellen.

Grundprinzipien

Unternehmen möchten Daten analysieren und daraus umsetzbare Informationen gewinnen. Google Cloud bietet Ihnen verschiedene Dienste, die Sie im gesamten Datenlebenszyklus unterstützen – von der Datenaufnahme über Berichte bis hin zur Visualisierung. Die meisten dieser Dienste sind vollständig verwaltet und einige sind serverlos. Sie können auch eine Datenanalyseumgebung auf Compute Engine-VMs erstellen und verwalten, z. B. für das selbst gehostete Apache Hadoop oder Beam.

Anhand Ihres speziellen Fokus, Ihres Teamwissens und Ihrer strategischen Einblicke können Sie feststellen, welche Google Cloud-Dienste Sie für die Anforderungen Ihrer Datenanalyse nutzen sollten. Mit Dataflow können Sie beispielsweise komplexe Transformationen in einem serverlosen Ansatz schreiben. Sie müssen sich jedoch auf eine bestimmte Version der Konfigurationen verlassen, wenn es um Rechen- und Verarbeitungsanforderungen geht. Alternativ können Sie mit Dataproc dieselben Transformationen ausführen, aber Sie verwalten die Cluster und optimieren die Jobs selbst.

Überlegen Sie in Ihrem Systemdesign, welche Verarbeitungsstrategie Ihre Teams verwenden, z. B. Extrahieren, Transformieren, Laden (ETL) oder Extrahieren, Laden, Transformieren (ELT). Außerdem sollte das Systemdesign berücksichtigen, ob Batchanalysen oder Streaminganalysen verarbeitet werden müssen. Google Cloud bietet eine einheitliche Datenplattform, mit der Sie einen Data Lake oder ein Data Warehouse für Ihre Geschäftsanforderungen erstellen können.

Vorteile

Die folgende Tabelle bietet einen allgemeinen Überblick über Google Cloud-Analysedienste:

Google Cloud-Dienst	Beschreibung
Pub/Sub	Einfache, zuverlässige und skalierbare Grundlage für Streamanalysen und ereignisgesteuerte Computing-Systeme.
Dataflow	Ein vollständig verwalteter Dienst zur Transformation und Anreicherung von Daten im Streammodus (Echtzeitdaten) und Batchmodus (Verlaufsdaten).
Dataprep by Trifacta	Intelligenter Datendienst für die visuelle Untersuchung, Bereinigung und Vorbereitung von strukturierten und unstrukturierten Daten für die Analyse
Dataproc	Schneller, nutzerfreundlicher und vollständig verwalteter Cloud-Dienst, um Apache Spark- und Apache Hadoop-Cluster auszuführen.
Cloud Data Fusion	Vollständig verwalteter Datenintegrationsdienst, der für die Cloud entwickelt wurde und Ihnen ermöglicht, ETL-/ELT-Datenpipelines zu erstellen und zu verwalten. Cloud Data Fusion bietet eine grafische Benutzeroberfläche und eine umfassende Open-Source-Bibliothek mit vorkonfigurierten Connectors und Transformationen.
BigQuery	Vollständig verwaltetes, kostengünstiges Data Warehouse, das mit Ihren Anforderungen an Speicherkapazität und Rechenleistung Schritt hält. BigQuery ist eine spaltenorientierte, ANSI-konforme SQL-Datenbank, die Terabyte bis Petabyte an Daten analysieren kann.
Cloud Composer	Vollständig verwalteter Dienst zur Workflow-Orchestrierung, mit dem Sie Pipelines erstellen, planen und überwachen können, die sich über Clouds und lokale Umgebungen erstrecken.
Data Catalog	Ein vollständig verwalteter und skalierbarer Dienst zur Metadatenverwaltung, mit dem Sie alle Ihre Daten finden, verwalten und verstehen können.
Looker Studio	Vollständig verwalteter Dienst für visuelle Analysen, mit dem Sie mithilfe interaktiver Dashboards Informationen aus Daten gewinnen können.
Looker	Unternehmensplattform, die Daten über Multi-Cloud-Umgebungen hinweg verbindet, analysiert und visualisiert.
Dataform	Vollständig verwaltetes Produkt für die Zusammenarbeit, Erstellung und Bereitstellung von Datenpipelines und die Gewährleistung der Datenqualität.
Dataplex	Verwalteter Data-Lake-Dienst, der Daten über Data Lakes, Data Warehouses und Data Marts mithilfe einheitlicher Kontrollen verwaltet, überwacht und steuert.
AnalyticsHub	Plattform, die Datenanalyse-Assets in Ihrer Organisation effizient und sicher austauscht, um Herausforderungen im Hinblick auf Datenzuverlässigkeit und Kosten zu bewältigen.

Datenlebenszyklus

Wenn Sie Ihr Systemdesign erstellen, können Sie die Google Cloud-Datenanalysedienste um die allgemeine Datenbewegung in einem beliebigen System oder um den Datenlebenszyklus gruppieren.

Der Datenlebenszyklus umfasst die folgenden Phasen und Beispieldienste:

• Datenaufnahme umfasst Dienste wie Pub/Sub, Storage Transfer Service, Transfer Appliance und BigQuery.
• Speicherung enthält Dienste wie Cloud Storage, Bigtable, Memorystore und BigQuery.
• Verarbeitung und Transformation umfasst Dienste wie Dataflow, Dataproc, Dataprep, Schutz sensibler Daten und BigQuery.
• Analyse und Warehousing umfasst Dienste wie BigQuery.
• Berichterstellung und Visualisierung umfasst Dienste wie Looker Studio und Looker.

Die folgenden Phasen und Dienste werden über den gesamten Datenlebenszyklus ausgeführt:

• Datenintegration umfasst Dienste wie Data Fusion.
• Die Verwaltung und Governance von Metadaten umfasst Dienste wie Data Catalog.
• Die Workflowverwaltung umfasst Dienste wie Cloud Composer.

Datenaufnahme

Wenden Sie folgende Best Practices für die Datenaufnahme auf Ihre eigene Umgebung an.

Datenquelle für die Aufnahme festlegen

Daten stammen in der Regel von einem anderen Cloud-Anbieter oder Dienst oder von einem lokalen Standort:

• Zur Aufnahme von Daten von anderen Cloud-Anbietern verwenden Sie in der Regel Cloud Data Fusion, Storage Transfer Service oder BigQuery Transfer Service.

• Berücksichtigen Sie bei der lokalen Datenaufnahme das Datenvolumen, das aufgenommen werden soll, und die Fähigkeiten Ihres Teams. Wenn Ihr Team einen Ansatz mit einer grafischen Benutzeroberfläche mit wenig Code bevorzugt, verwenden Sie Cloud Data Fusion mit einem geeigneten Connector, z. B. mit Java Database Connectivity (JDBC). Für große Datenmengen können Sie Transfer Appliance oder Storage Transfer Service verwenden.

Überlegen Sie, wie Sie Ihre Daten nach der Aufnahme verarbeiten möchten. Storage Transfer Service schreibt beispielsweise Daten nur in einen Cloud Storage-Bucket und BigQuery Data Transfer Service nur in ein BigQuery-Dataset. Cloud Data Fusion unterstützt mehrere Ziele.

Streaming- oder Batchdatenquellen identifizieren

Überlegen Sie, wie Sie Ihre Daten verwenden müssen und wo Sie Streaming- oder Batchanwendungsfälle haben. Wenn Sie beispielsweise einen globalen Streamingdienst mit niedrigen Latenzanforderungen ausführen, können Sie Pub/Sub verwenden. Wenn Sie Ihre Daten für die Analyse und Berichterstellung benötigen, können Sie Daten in BigQuery streamen.

Wenn Sie Daten aus einem System wie Apache Kafka in einer lokalen oder einer anderen Cloud-Umgebung streamen müssen, verwenden Sie die Dataflow-Vorlage "Kafka zu BigQuery". Bei Batcharbeitslasten besteht der erste Schritt in der Regel darin, Daten in Cloud Storage aufzunehmen. Verwenden Sie das gsutil-Tool oder Storage Transfer Service, um Daten aufzunehmen.

Daten mit automatisierten Tools aufnehmen

Das manuelle Verschieben von Daten aus anderen Systemen in die Cloud kann eine Herausforderung sein. Verwenden Sie nach Möglichkeit Tools, mit denen Sie die Datenaufnahmeprozesse automatisieren können. Cloud Data Fusion bietet beispielsweise Connectors und Plug-ins, um Daten aus externen Quellen mit einer Drag-and-drop-GUI zu übertragen. Wenn Ihre Teams Code schreiben möchten, können Sie mithilfe von Dataflow oder BigQuery die Datenaufnahme automatisieren. Pub/Sub kann sowohl bei einem Ansatz mit wenig Code als auch bei einem Code-First-Ansatz hilfreich sein. Wenn Sie Daten in Storage-Buckets aufnehmen möchten, verwenden Sie gsutil für Datenmengen von bis zu 1 TB. Um Daten mit einer Größe von mehr als 1 TB aufzunehmen, verwenden Sie Storage Transfer Service.

Daten mit einem Migrationstool aus einem anderen Data Warehouse aufnehmen

Wenn Sie von einem anderen Data-Warehouse-System wie Teradata, Netezza oder Redshift migrieren müssen, können Sie die Migrationsunterstützung von BigQuery Data Transfer Service verwenden. BigQuery Data Transfer Service bietet auch Übertragungen von Drittanbietern, mit denen Sie Daten nach einem Zeitplan aus externen Quellen aufnehmen können. Weitere Informationen finden Sie in den detaillierten Migrationsansätzen für jedes Data Warehouse.

Anforderungen an die Datenaufnahme bewerten

Durch die Menge an Daten, die Sie aufnehmen müssen, können Sie ermitteln, welcher Dienst in Ihrem Systemdesign verwendet werden sollte. Für die Streamingaufnahme von Daten skaliert Pub/Sub auf zehn Gigabyte pro Sekunde. Kapazitäts-, Speicher- und regionale Anforderungen für Ihre Daten helfen Ihnen, zu bestimmen, ob Pub/Sub Lite eine bessere Option für Ihr Systemdesign ist. Weitere Informationen finden Sie unter Pub/Sub oder Pub/Sub Lite auswählen.

Schätzen Sie für die Batchaufnahme der Daten, wie viele Daten Sie insgesamt übertragen möchten und wie schnell Sie dies tun möchten. Sehen Sie sich die verfügbaren Migrationsoptionen an, einschließlich einer zeitlichen Schätzung und des Vergleichs von Online- und Offlineübertragungen.

Geeignete Tools verwenden, um regelmäßig Daten nach einem Zeitplan aufzunehmen

Mit Storage Transfer Service und BigQuery Data Transfer Service können Sie Aufnahmejobs planen. Verwenden Sie ein Workflow-Verwaltungssystem wie Cloud Composer, um eine genaue Kontrolle über den Zeitpunkt der Aufnahme oder das Quell- und Zielsystem zu erhalten. Wenn Sie einen manuellen Ansatz wünschen, können Sie Cloud Scheduler und Pub/Sub verwenden, um eine Cloud Functions-Funktion auszulösen.
Wenn Sie die Computing-Infrastruktur verwalten möchten, können Sie den Befehl gsutil mit Cron für die Datenübertragung bis zu 1 TB verwenden. Wenn Sie diesen manuellen Ansatz anstelle von Cloud Composer verwenden, folgen Sie den Best Practices für die Skripterstellung für Produktionsübertragungen.

Anforderungen an die Datenaufnahme von einem FTP/SFTP-Server prüfen

Wenn Sie eine codefreie Umgebung benötigen, um Daten von einem FTP/SFTP-Server aufzunehmen, können Sie die FTP-Kopier-Plug-ins verwenden. Wenn Sie eine Modernisierung vornehmen und eine langfristige Workflow-Lösung erstellen möchten, ist Cloud Composer ein vollständig verwalteter Dienst, mit dem Sie aus verschiedenen Quellen und Senken lesen und schreiben können.

Apache Kafka-Connectors zur Datenaufnahme verwenden

Wenn Sie Pub/Sub, Dataflow oder BigQuery verwenden, können Sie Daten mithilfe eines der Apache Kafka-Connectors aufnehmen. Mit dem Open-Source-Kafka-Connector für Pub/Sub können Sie beispielsweise Daten aus Pub/Sub oder Pub/Sub Lite aufnehmen.

Weitere Informationen

• Best Practices für den Cloud Storage Transfer Dienst-Agent
• So werden Daten in BigQuery aufgenommen, um sie zu analysieren
• Klinische Daten und Betriebsdaten mit Cloud Data Fusion aufnehmen
• Aufnahme umfangreicher Analyseereignisse und -logs optimieren

Datenspeicher

Wenden Sie folgende Best Practices für die Datenspeicherung auf Ihre eigene Umgebung an.

Geeigneten Datenspeicher für Ihre Anforderungen auswählen

Sehen Sie sich die nachgelagerte Nutzung Ihrer Daten an, um sich die Wahl der zu verwendenden Speicherlösung zu erleichtern. Die folgenden gängigen Anwendungsfälle für Ihre Daten geben Empfehlungen dafür, welches Google Cloud-Produkt Sie verwenden sollten:

Datenanwendungsfall	Produktempfehlung
Dateibasiert	Filestore
Objektbasiert	Cloud Storage
Niedrige Latenz	Bigtable
Zeitreihe	Bigtable
Online-Cache	Memorystore
Transaktionsverarbeitung	Cloud SQL
Business Intelligence (BI) und Analysen	BigQuery
Batchverarbeitung	Cloud Storage Bigtable, wenn eingehende Daten Zeitachsen sind und Sie mit geringer Latenz darauf zugreifen müssen BigQuery, wenn Sie SQL verwenden

Ihre Anforderungen an Datenstruktur prüfen

Für die meisten unstrukturierten Daten wie Dokumente und Textdateien, Audio- und Videodateien oder Logs ist ein objektbasierter Speicher die beste Wahl. Bei Bedarf können Sie die Daten dann aus dem Objektspeicher laden und verarbeiten.

Bei halbstrukturierten Daten wie XML oder JSON helfen Ihnen Ihre Anwendungsfälle und Datenzugriffsmuster bei der Auswahl. Sie können derartige Datasets zur automatischen Schemaerkennung in BigQuery laden. Wenn die Anforderungen an die Latenz niedrig sind, können Sie Ihre JSON-Daten in Bigtable laden. Wenn Sie Legacy-Anforderungen haben oder Ihre Anwendungen mit relationalen Datenbanken arbeiten, können Sie Datasets auch in einen Beziehungsspeicher laden.

Für strukturierte Daten wie CSV, Parquet, Avro oder ORC können Sie BigQuery verwenden, wenn Sie BI- und Analyseanforderungen haben, für die Sie SQL verwenden. Weitere Informationen finden Sie unter Daten im Batch laden. Wenn Sie einen Data Lake mit offenen Standards und Technologien erstellen möchten, können Sie Cloud Storage verwenden.

Daten migrieren und Kosten für HDFS reduzieren

Suchen Sie nach Möglichkeiten, HDFS-Daten (Hadoop Distributed File System) von lokalen oder anderen Cloud-Anbietern zu einem kostengünstigeren Objektspeichersystem zu verschieben. Cloud Storage ist die gängigste Wahl von Unternehmen für einen alternativen Datenspeicher. Informationen zu den Vor- und Nachteilen dieser Wahl finden Sie unter HDFS im Vergleich zu Cloud Storage.

Sie können Daten mit einer Push- oder Pull-Methode verschieben. Beide Methoden verwenden den Befehl hadoop distcp. Weitere Informationen finden Sie unter Lokale HDFS-Daten zu Google Cloud migrieren.

Sie können auch den Open-Source-Cloud Storage-Connector verwenden, damit Hadoop- und Spark-Jobs auf Daten in Cloud Storage zugreifen können. Der Connector wird standardmäßig auf Dataproc-Clustern installiert und kann manuell auf anderen Clustern installiert werden.

Mit einem Objektspeicher einen zusammenhängenden Data Lake erstellen

Ein Data Lake ist ein zentrales Repository zum Speichern, Verarbeiten und Sichern großer Mengen strukturierter, semistrukturierter oder unstrukturierter Daten. Sie können Cloud Composer und Cloud Data Fusion verwenden, um einen Data Lake zu erstellen.

Zum Erstellen einer modernen Datenplattform können Sie BigQuery als zentrale Datenquelle anstelle von Cloud Storage verwenden. BigQuery ist ein modernes Data Warehouse mit Trennung von Speicher und Computing. Mit einem auf BigQuery basierenden Data Lake können Sie herkömmliche Analysen von BigQuery in der Cloud Console ausführen. Außerdem können Sie über andere Frameworks wie Apache Spark auf die gespeicherten Daten zugreifen.

Weitere Informationen

• Best Practices für Cloud Storage
• Best Practices für die Kostenoptimierung von Cloud Storage:
• Best Practices für Datenschutz und Sicherheit Ihrer Daten in Cloud Storage
• Best Practices für Memorystore
• BigQuery-Speicher optimieren
• Bigtable-Schemadesign

Daten verarbeiten und transformieren

Wenden Sie die folgenden Best Practices für die Datenanalyse in Ihrer eigenen Umgebung an, wenn Sie Daten verarbeiten und transformieren.

Open-Source-Software zur Verwendung in Google Cloud ermitteln

Viele Google Cloud-Dienste verwenden Open-Source-Software, um die Umstellung nahtlos zu gestalten. Google Cloud bietet verwaltete und serverlose Lösungen mit Open APIs, die mit Open-Source-Frameworks kompatibel sind, um die Anbieterabhängigkeit zu reduzieren.

Dataproc ist ein Hadoop-kompatibler verwalteter Dienst, mit dem Sie Open-Source-Software mit geringem operativem Aufwand hosten können. Dataproc enthält Unterstützung für Spark, Hive, Pig, Presto und Zookeeper. Es bietet auch Hive Metastore als verwalteten Dienst, um sich als Single Point of Failure in der Hadoop-Umgebung zu entfernen.

Sie können zu Dataflow migrieren, wenn Sie derzeit Apache Beam als Batch- und Streamingverarbeitungs-Engine verwenden. Dataflow ist ein vollständig verwalteter und serverloser Dienst, der Apache Beam verwendet. Verwenden Sie Dataflow, um Jobs in Beam zu schreiben. Google Cloud verwaltet jedoch die Ausführungsumgebung.

Wenn Sie CDAP als Datenintegrationsplattform verwenden, können Sie zu Cloud Data Fusion migrieren, um eine vollständig verwaltete Umgebung zu erhalten.

Anforderungen zur ETL- oder ELT-Datenverarbeitung ermitteln

Die Erfahrungen und Präferenzen Ihres Teams helfen Ihnen, das Systemdesign zur Verarbeitung von Daten zu bestimmen. Google Cloud bietet Ihnen die Möglichkeit, entweder ein traditionelles ETL- oder ein moderneres ELT-System zur Datenverarbeitung zu verwenden.

• Für ETL-Pipelines können Sie Data Fusion, Dataproc oder Dataflow verwenden.

  • Für neue Umgebungen empfehlen wir Dataflow für eine einheitliche Möglichkeit, Batch- und Streaminganwendungen zu erstellen.
  • Für einen vollständig verwalteten Ansatz bietet Data Fusion eine Drag-and-drop-GUI, mit der Sie Pipelines erstellen können.

• Verwenden Sie für ELT-Pipelines BigQuery, das das Laden von Batch- und Streamingdaten unterstützt. Nachdem sich Ihre Daten in BigQuery befinden, führen Sie mit SQL alle Transformationen durch, um neue Datasets für Ihre geschäftlichen Anwendungsfälle abzuleiten.

• Wenn Sie die Modernisierung und die Migration von ETL zu ELT durchführen möchten, können Sie Dataform verwenden. Zur Unterstützung von BI mit BigQuery können Sie auch einen Drittanbieterdienst wie Fivetran verwenden.

Geeignetes Framework für Ihren Anwendungsfall verwenden

Ihre Daten-Anwendungsfälle bestimmen, welche Tools und Frameworks verwendet werden sollen. Einige Google Cloud-Produkte sind für alle der folgenden Daten-Anwendungsfälle ausgelegt, während andere nur einen bestimmten Anwendungsfall optimal unterstützen.

• Bei einem Batchverarbeitungssystem können Sie Daten in BigQuery mit einer vertrauten SQL-Schnittstelle verarbeiten und umwandeln. Wenn Sie bereits eine Pipeline haben, die lokal in Apache Hadoop oder Spark oder in einer anderen öffentlichen Cloud ausgeführt wird, können Sie Dataproc verwenden.
  • Sie können Dataflow auch verwenden, wenn Sie eine einheitliche Programmierschnittstelle für Batch- und Streaming-Anwendungsfälle wünschen. Wir empfehlen, dass Sie eine Modernisierung vornehmen und Dataflow für ETL und BigQuery für ELT verwenden.

• Für Streaming-Datenpipelines verwenden Sie einen verwalteten und serverlosen Dienst wie Dataflow, der Windowing, Autoscaling und Vorlagen bietet. Weitere Informationen finden Sie unter Produktionsfertige Datenpipelines mit Dataflow erstellen.

  • Wenn Sie Analyse- und SQL-orientierte Teams und Funktionen haben, können Sie auch Daten in BigQuery streamen.

• Verwenden Sie Dataflow für Echtzeit-Anwendungsfälle, z. B. für die Zeitreihenanalyse oder für Streaming-Videoanalysen.

Auch in Zukunft die Kontrolle über Ihre Ausführungs-Engine behalten

Nutzen Sie das Apache Beam-Programmiermodell und Dataflow als verwaltete serverlose Lösung, um die Anbieterabhängigkeit zu minimieren und in Zukunft eine andere Plattform verwenden zu können. Mit dem Beam-Programmiermodell können Sie die zugrunde liegende Ausführungs-Engine ändern, z. B. von Dataflow zu Apache Flink oder Apache Spark.

Dataflow verwenden, um Daten aus mehreren Quellen aufzunehmen

Verwenden Sie Dataflow, um Daten aus mehreren Quellen wie Pub/Sub, Cloud Storage, HDFS, S3 oder Kafka aufzunehmen. Dataflow ist ein verwalteter serverloser Dienst, der Dataflow-Vorlagen unterstützt, sodass Ihre Teams Vorlagen aus verschiedenen Tools ausführen können.

Dataflow Prime bietet horizontales und vertikales Autoscaling von Maschinen, die im Ausführungsprozess einer Pipeline verwendet werden. Außerdem finden Sie intelligente Diagnosen und Empfehlungen, die Probleme erkennen und Lösungen vorschlagen.

Vertrauliche Daten ermitteln, identifizieren und schützen

Mit dem Schutz sensibler Daten können Sie strukturierte und unstrukturierte Daten untersuchen und transformieren. Der Schutz sensibler Daten funktioniert für Daten, die sich an einem beliebigen Ort in Google Cloud befinden, z. B. in Cloud Storage oder Datenbanken. Sie können Ihre vertraulichen Daten klassifizieren, maskieren und tokenisieren, um sie für die nachgelagerte Verarbeitung sicher verwenden zu können. Verwenden Sie den Schutz sensibler Daten, um BigQuery-Daten zu scannen oder personenidentifizierbare Informationen in umfangreichen Datasets zu de-identifizieren und neu zu identifizieren.

Datentransformationsprozesse modernisieren

Verwenden Sie Dataform, um Datentransformationen als Code zu schreiben und standardmäßig die Versionsverwaltung zu verwenden. Sie können auch Best Practices für die Softwareentwicklung wie CI/CD, Unittests und Versionsverwaltung für SQL-Code anwenden. Dataform unterstützt alle wichtigen Cloud-Data-Warehouse-Produkte und -Datenbanken wie PostgreSQL.

Zusätzliche Ressourcen

• Dataproc
  • Best Practices-Leitfaden
  • Tipps für Cluster mit langer Ausführungszeit
  • Apache Hive in Dataproc verwenden
  • Best Practices für die Ausführung in der Produktion
  • Best Practices für die Verwendung von Apache Ranger
  • Empfehlungen für die Autoscaling-Konfiguration
  • Hilfe bei langsamen Hadoop-/Spark-Jobs
• Dataflow
  • Pipelines in die Produktion verschieben
  • Gängige Anwendungsfälle
• Data Fusion
  • Pipelineleistung
• BigQuery
  • Abfrageleistung optimieren
• Dataform
  • Best Practices für die Projektverwaltung
• Schutz sensibler Daten
  • Kosten unter Kontrolle halten
  • Speicher und Datenbanken auf sensible Daten prüfen
  • Text auf vertrauliche Daten prüfen

Datenanalyse und Data Warehouses

Wenden Sie die folgenden Best Practices für die Datenanalyse und das Data Warehouse auf Ihre eigene Umgebung an.

Ihre Datenspeicheranforderungen prüfen

Data Lakes und Data Warehouses schließen sich nicht gegenseitig aus. Data Lakes sind für die unstrukturierte und semistrukturierte Datenspeicherung und -verarbeitung nützlich. Data Warehouses eignen sich am besten für Analysen und BI.

Prüfen Sie Ihre Datenanforderungen, um zu ermitteln, wo Ihre Daten gespeichert werden sollten und welches Google Cloud-Produkt sich für die Verarbeitung und Analyse der Daten am besten eignet. Produkte wie BigQuery können Petabyte an Daten verarbeiten und mit Ihren Anforderungen wachsen.

Möglichkeiten zur Migration von einem traditionellen Data Warehouse zu BigQuery identifizieren

Prüfen Sie die herkömmlichen Data Warehouses, die derzeit in Ihrer Umgebung verwendet werden. Identifizieren Sie Möglichkeiten zur Migration Ihrer traditionellen Data Warehouses zu einem Google Cloud-Dienst wie BigQuery, um die Komplexität zu verringern und möglicherweise die Kosten zu senken. Weitere Informationen und Beispielszenarien finden Sie unter Data Warehouses zu BigQuery migrieren.

Föderierten Zugriff auf Daten planen

Prüfen Sie, welche Datenanforderungen Sie haben und wie Sie möglicherweise mit anderen Produkten und Diensten interagieren müssen. Ermitteln Sie die Anforderungen für Ihre Datenföderation und erstellen Sie ein geeignetes Systemdesign.

Mit BigQuery können Sie beispielsweise externe Tabellen definieren, die Daten aus anderen Quellen wie Bigtable, Cloud SQL, Cloud Storage oder Google Drive lesen können. Sie können diese externen Quellen mit Tabellen verknüpfen, die Sie in BigQuery speichern.

Flex-Slots von BigQuery verwenden, um On-Demand-Burst-Kapazität bereitzustellen

Manchmal benötigen Sie zusätzliche Kapazität für experimentelle oder explorative Analysen, die umfangreiche Rechenressourcen erfordern. BigQuery bietet zusätzliche Rechenkapazität in Form von Flex-Slots. Diese Flex-Slots sind nützlich, wenn eine Zeit mit hoher Nachfrage vorhanden ist oder Sie eine wichtige Analyse abschließen möchten.

Schemaunterschiede im Falle der Migration zu BigQuery verstehen

BigQuery unterstützt sowohl Sternschemas als auch Schneeflockenschemas, verwendet jedoch standardmäßig verschachtelte und wiederkehrende Felder. Verschachtelte und wiederkehrende Felder können im Vergleich zu anderen Schemas leichter gelesen und korreliert werden. Wenn Ihre Daten in einem Stern- oder Schneeflockenschema dargestellt sind und Sie zu BigQuery migrieren möchten, prüfen Sie Ihr Systemdesign auf erforderliche Änderungen an Prozessen oder Analysen.

Weitere Informationen

• Best Practices für mehrmandantenfähige Arbeitslasten in BigQuery
• Best Practices für die Sicherheit auf Zeilenebene in BigQuery
• Best Practices für materialisierte Ansichten in BigQuery

Berichte und Visualisierung

Wenden Sie die folgenden Best Practices für die Berichterstellung und Visualisierung auf Ihre eigene Umgebung an.

Daten mit BigQuery BI Engine visualisieren

BigQuery BI Engine ist ein schneller In-Memory-Analysedienst. Sie können BI Engine verwenden, um in BigQuery gespeicherte Daten mit Abfragereaktionszeiten von weniger als einer Sekunde und mit hoher Nebenläufigkeit zu analysieren. BI Engine ist in die BigQuery API integriert. Verwenden Sie die reservierte BI Engine-Kapazität, um die On-Demand- oder Pauschalpreise für Ihre Anforderungen zu verwalten. BI Engine kann auch mit anderen BI- oder benutzerdefinierten Dashboard-Anwendungen verwendet werden, die Antwortzeiten von unter einer Sekunde erfordern.

BI-Prozesse mit Looker modernisieren

Looker ist eine moderne Unternehmensplattform für BI, Datenanwendungen und eingebettete Analysen. Sie können konsistente Datenmodelle zusätzlich zu Ihren Daten mit Geschwindigkeit und Genauigkeit erstellen und auf Daten in transaktionalen und analytischen Datenspeichern zugreifen. Looker kann auch Ihre Daten in mehreren Datenbanken und Clouds analysieren. Wenn Sie bereits BI-Prozesse und -Tools haben, empfehlen wir, eine Modernisierung vorzunehmen und eine zentrale Plattform wie Looker zu verwenden.

Weitere Informationen

• Data Warehouses zu BigQuery migrieren: Berichterstellung und Analyse
• Architektur zum Verbinden von Visualisierungssoftware mit Hadoop in Google Cloud
• Kleine Abfragen in BigQuery mit BI Engine beschleunigen

Workflow-Managementtools verwenden

Die Datenanalyse umfasst viele Prozesse und Dienste. Während des Datenanalyselebenszyklus werden Daten zwischen verschiedenen Tools und Verarbeitungspipelines verschoben. Verwenden Sie geeignete Tools zur Workflowverwaltung, um End-to-End-Datenpipelines zu verwalten und zu pflegen. Cloud Composer ist ein vollständig verwaltetes Workflow-Managementtool, das auf dem Open-Source-Projekt Apache Airflow basiert.

Sie können Cloud Composer verwenden, um Dataflow-Pipelines zu starten und Dataproc-Workflow-Vorlagen zu verwenden. Cloud Composer unterstützt Sie auch beim Erstellen einer CI/CD-Pipeline zum Testen, Synchronisieren und Bereitstellen von DAGs oder beim Verwenden einer CI/CD-Pipeline für die Datenverarbeitungsworkflows. Weitere Informationen finden Sie unter Cloud Composer: Best Practices für die Entwicklung.

Migrationsressourcen

Wenn Sie bereits eine Datenanalyseplattform ausführen und einige oder alle Arbeitslasten zu Google Cloud migrieren möchten, finden Sie Best Practices und Anleitungen in den folgenden Migrationsressourcen:

• Allgemeine Anleitung zur Migration
  • Migration zu Google Cloud: Migrationspfad auswählen
  • Beispiel für die Modernisierung der Analyseplattform für Anzeigeninteraktionen von Twitter
• Cloud Storage-Migration
  • Lokale HDFS-Daten zu Google Cloud migrieren.
  • Daten mit VPC Service Controls und Storage Transfer Service von Amazon S3 zu Cloud Storage übertragen.
• Pub/Sub-Migration
  • Migration von Kafka zu Pub/Sub.
• Bigtable-Migration
  • Daten von HBase zu Bigtable migrieren.
  • Von Aerospike zu Bigtable migrieren.
• Dataproc-Migration
  • Lokale Hadoop-Infrastruktur zu Google Cloud migrieren.
  • Kosten und Tipps für eine Hadoop-Migration.
  • Hadoop nach Dataproc.
  • Lokale Hadoop-Jobs nach Dataproc.
  • Apache Spark nach Dataproc.
  • Externer Hive-Metastore in Dataproc Metastore.
• BigQuery-Migration
  • Herausforderungen bei der Migration von Legacy-Data Warehouses.
  • Data Warehouses zu BigQuery migrieren.
  • BigQuery für Data-Warehouse-Experten.
• Composer-Migration
  • Umgebungen zu Airflow 2 migrieren.

Nächste Schritte

Informationen zu Best Practices für das Systemdesign für KI und maschinelles Lernen von Google Cloud, einschließlich:

• Weitere Informationen zu Google Cloud-Diensten für KI und maschinelles Lernen, die das Systemdesign unterstützen.
• Best Practices für die ML-Datenverarbeitung.
• Best Practices die Modellentwicklung und -training.

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Machine Learning implementieren

In diesem Dokument des Google Cloud-Architektur-Frameworks werden einige Grundprinzipien und Best Practices für Datenanalysen in Google Cloud erläutert. Sie erfahren etwas über die wichtigsten Dienste von KI und maschinellem Lernen (ML) und wie sie in den verschiedenen Phasen des KI- und ML-Lebenszyklus helfen können. Mit diesen Best Practices können Sie Ihre KI- und ML-Anforderungen erfüllen und Ihr Systemdesign erstellen. In diesem Dokument wird davon ausgegangen, dass Sie mit grundlegenden KI- und ML-Konzepten vertraut sind.

Nutzen Sie die für Ihren Anwendungsfall höchste Abstraktionsebene, um den Entwicklungsprozess zu vereinfachen und den Aufwand beim Erstellen von ML-Modellen in Google Cloud zu minimieren. Der Abstraktionsgrad ist die Komplexität, mit der ein System betrachtet oder programmiert wird. Je höher der Abstraktionsgrad, desto weniger Details sind für den Betrachter verfügbar.

Verwenden Sie folgende Tabelle, um Google-KI- und ML-Dienste anhand Ihrer Geschäftsanforderungen auszuwählen:

Identität	Google-Dienste
Geschäftliche Nutzer	Standardlösungen wie Contact Center AI Insights, Document AI, Discovery AI und Cloud Healthcare API.
Entwickler mit minimaler ML-Erfahrung	Vortrainierte APIs entwickeln gängige wahrnehmungsbasierte Aufgaben wie Vision, Video und Natural Language. Diese APIs werden von vortrainierten Modellen unterstützt und bieten Standarddetektoren. Sie sind ohne ML-Fachwissen und Modellentwicklungsarbeit einsatzbereit. Zu den vortrainierten APIs gehören Vision API, Video API, Natural Language API, Speech-to-Text API, Text-to-Speech API und Cloud Translation API.
Generative KI für Entwickler	Mit Vertex AI Search and Conversation können Entwickler dank der integrierten Funktionen Chatbots in wenigen Minuten und Suchmaschinen in wenigen Stunden erstellen und bereitstellen. Entwickler, die mehrere Funktionen zu Workflows für Unternehmen kombinieren möchten, können die Gen App Builder API für die direkte Integration verwenden.
Entwickler und Data Scientists	AutoML ermöglicht die benutzerdefinierte Modellentwicklung mit eigenen Bild-, Video-, Text- oder tabellarischen Daten. AutoML beschleunigt die Modellentwicklung, indem die Vielfalt an Google-Modellen automatisch nach der leistungsstärksten Modellarchitektur durchsucht wird, sodass Sie das Modell nicht erstellen müssen. AutoML führt allgemeine Aufgaben für Sie aus, z. B. die Auswahl einer Modellarchitektur, Hyperparameter-Abstimmung und die Bereitstellung von Maschinen für Training und Bereitstellung.
Data Scientists und ML-Entwickler	Mit den benutzerdefinierten Vertex AI-Modelltools können Sie eigene Modelle trainieren und bereitstellen und sie für den ML-Workflow operationalisieren. Sie können Ihre ML-Arbeitslast auch auf selbstverwalteten Rechenressourcen wie Compute Engine-VMs ausführen.
Data Scientists und ML-Entwickler	Die Unterstützung für generative KI in Vertex AI (auch als genai bezeichnet) bietet Zugriff auf die großen generativen KI-Modelle von Google, damit Sie die Modelle in Ihren KI-gestützten Anwendungen testen, optimieren und bereitstellen können.
Data Engineers, Data Scientists und Datenanalysten, die mit SQL-Schnittstellen vertraut sind	Mit BigQuery ML können Sie SQL-basierte Modelle auf Basis von in BigQuery gespeicherten Daten entwickeln.

Vorteile

Folgende Tabelle bietet einen allgemeinen Überblick über KI- und ML-Dienste:

Google-Dienst	Beschreibung
Cloud Storage und BigQuery	Flexible Speicheroptionen für ML-Daten und -Artefakte bereitstellen.
BigQuery ML	Ermöglicht das Erstellen von Modellen für maschinelles Lernen direkt aus in BigQuery befindlichen Daten.
Pub/Sub, Dataflow, Cloud Data Fusion und Dataproc	Unterstützen Sie die Batchaufnahme und Verarbeitung von Daten in Echtzeit. Weitere Informationen finden Sie unter Datenanalyse.
Vertex AI	Bietet Data Scientists und ML-Entwicklern eine zentrale Plattform zum Erstellen, Trainieren, Testen, Überwachen, Optimieren und Bereitstellen von ML-Modellen für alles von generativer KI bis MLOps. Die Tools umfassen: Vertex-Daten-Labeling zum Abrufen präziser Datenlabel. Deep Learning Container zum Erstellen und Bereitstellen von Modellen in einer portablen und konsistenten Umgebung. Vertex AI Workbench für eine verwaltete oder vom Nutzer verwaltete JupyterLab-Umgebung. Vertex-Training für einen vollständig verwalteten Schulungsdienst. Vertex AI TensorBoard für Test-Tracking. Vertex AI Vizier für die Hyperparameter-Abstimmung. Vertex-Vorhersagen für ein einheitliches Framework zur Bereitstellung, das selbsttrainierte BigQuery ML- und AutoML-Modelle unterstützt. Vertex Explainable AI zur Erstellung von Erläuterungen zu Modellvorhersagen. Vertex-Tests, um die Bereitstellung von Modellen in der Produktion zu beschleunigen. Jetzt mit schnellerer Modellauswahl. MLOps-Tools wie Vertex AI Pipelines für die Orchestrierung und Vertex AI Feature Store für ein vollständig verwaltetes Feature-Repository.
Vertex AI Search and Conversation	Ermöglicht die Erstellung von Chatbots und Suchmaschinen für Websites und für die Verwendung über Unternehmensdaten hinweg. Conversational AI in Vertex AI Search und Conversation kann dabei helfen, Kunden- und Mitarbeiterinteraktionen mit generativen KI-gestützten Chatbots und digitalen Assistenten neu zu erfinden. Mit diesen Tools können Sie beispielsweise mehr als nur Informationen bereitstellen, indem Sie Transaktionen von innerhalb des Chats aktivieren. Mit Enterprise Search in Vertex AI Search and Conversation können Unternehmen Suchumgebungen für Kunden und Mitarbeiter auf ihren öffentlichen oder privaten Websites erstellen. Enterprise Search bietet nicht nur hochwertige multimodale Suchergebnisse, es kann auch Ergebnisse zusammenfassen und entsprechende Zitationen dank generativer KI liefern.
Generative AI on Vertex AI	Ermöglicht den Zugriff auf die großen generativen KI-Modelle von Google, sodass Sie die Modelle testen, optimieren und für die Verwendung in Ihren KI-gestützten Anwendungen bereitstellen können. Generative AI on Vertex AI wird auch als genai bezeichnet. Generative KI-Modelle, die auch als Foundation Models bezeichnet werden, werden nach der Art der Inhalte kategorisiert, die sie generieren sollen. Dieser Inhalt umfasst Text- und Chat-, Bild-, Code- und Texteinbettungen. Mit Vertex AI Studio können Sie in der Google Cloud Console schnell Prototypen für generative KI-Modelle erstellen und testen. Sie können Beispiel-Prompts testen, eigene Prompts entwerfen und Foundation Models anpassen, um Aufgaben zu verarbeiten, die die Anforderungen Ihrer Anwendung erfüllen. Model Tuning ermöglicht die Anpassung von Foundation Models für bestimmte Anwendungsfälle, indem Sie diese mithilfe eines Datasets von Eingabe-Ausgabe-Beispielen für optimieren. Modell Garden bietet Foundation Models, aufgabenspezifische Modelle und APIs für Unternehmen.
Vortrainierte APIs	Zu den vortrainierten APIs gehören Vision API, Video API, Natural Language API, Speech-to-Text API, Text-to-Speech API und Cloud Translation API.
AutoML	Bietet benutzerdefinierte Modelltools zum Erstellen, Bereitstellen und Skalieren von ML-Modellen. Entwickler können ihre eigenen Daten hochladen und den entsprechenden AutoML-Dienst verwenden, um ein benutzerdefiniertes Modell zu erstellen. AutoML Image: Führt Bildklassifizierung und Objekterkennung für Bilddaten durch. AutoML Video: Führt Objekterkennung, Klassifizierung und Aktionserkennung für Videodaten durch. AutoML Text: Führt Sprachklassifizierung, Entitätsextraktion und Sentimentanalyse für Textdaten durch. AutoML Translation: Erkennt Sprachpaare und übersetzt zwischen diesen. AutoML Tabular: Ermöglicht das Erstellen eines Regressions-, Klassifizierungs- oder Prognosemodells. Vorgesehen für strukturierte Daten.
AI Infrastructure	Ermöglicht die Verwendung von AI-Beschleunigern zur Verarbeitung großer ML-Arbeitslasten. Mit diesen Beschleunigern können Sie Deep-Learning-Modelle und ML-Modelle kostengünstig trainieren und Inferenzen daraus ableiten. GPUs können für kostengünstige Inferenz sowie für das vertikale und horizontale Skalieren von Training für Deep-Learning-Modelle hilfreich sein. Tensor Processing Units (TPUs) sind benutzerdefinierte ASICs zum Trainieren und Ausführen von neuronalen Deep-Learning-Netzwerken.
Dialogflow	Bietet virtuelle Kundenservicemitarbeiter, die Unterhaltungserfahrungen bereitstellen.
Contact Center AI	Bietet ein automatisiertes, informiertes Kontaktcenter-Erlebnis mit Agent Assist-Funktionen für menschliche Mitarbeiter.
Document AI	Bietet ein umfassendes Verständnis von Dokumenten im Allgemeinen und für bestimmte Dokumenttypen, darunter finanzierungs- und beschaffungsbezogene Dokumente.
Lending DocAI	Automatisiert die Verarbeitung von Hypothekendokumenten. Die Verarbeitungszeit wird reduziert und die Datenerfassung wird optimiert – unter Einhaltung der Vorschriften und Compliance-Anforderungen.
Procurement DocAI	Automatisiert die Erfassung von Beschaffungsdaten im großen Stil: Verwandelt unstrukturierte Dokumente wie Rechnungen und Belege in strukturierte Daten, um die betriebliche Effizienz zu steigern, die Nutzerumgebung zu optimieren und fundierte Grundlagen für die Entscheidungsfindung bereitzustellen.
Empfehlungen	Bietet personalisierte Produktempfehlungen.
Healthcare Natural Language API	Ermöglicht die Prüfung und Analyse medizinischer Dokumente.
Media Translation API	Aktiviert die Echtzeitübersetzung von Audiodaten.

Datenverarbeitung

Wenden Sie folgende Best Practices für die Datenverarbeitung auf Ihre eigene Umgebung an.

Darauf achten, dass Ihre Daten die ML-Anforderungen erfüllen

Die für ML verwendeten Daten müssen unabhängig vom Datentyp bestimmte grundlegende Anforderungen erfüllen. Zu diesen Anforderungen gehören die Fähigkeit der Daten, das Ziel vorherzusagen, die Konsistenz zwischen den für das Training verwendeten Daten und den für die Vorhersage verwendeten Daten und genau mit Labels versehene Daten für das Training vorherzusagen. Auch das Volumen der Daten sollte ausreichen. Weitere Informationen finden Sie unter Datenverarbeitung.

Tabellarische Daten in BigQuery speichern

Wenn Sie tabellarische Daten verwenden, sollten Sie alle Daten in BigQuery speichern und die BigQuery Storage API zum Lesen von Daten daraus verwenden. Verwenden Sie eine der folgenden zusätzlichen Tooloptionen, um die Interaktion mit der API zu vereinfachen:

• Wenn Sie Dataflow verwenden, verwenden Sie den BigQuery-E/A-Connector.
• Wenn Sie TensorFlow oder Keras nutzen, verwenden Sie den tf.data.dataset-Reader für BigQuery.
• Wenn Sie unstrukturierte Daten wie Bilder oder Videos verwenden, sollten Sie alle Daten in Cloud Storage speichern.

Der Eingabedatentyp bestimmt auch die verfügbaren Tools zur Modellentwicklung. Vortrainierte APIs, AutoML und BigQuery ML können kostengünstigere und zeiteffiziente Entwicklungsumgebungen für bestimmte Bild-, Video-, Text- und strukturierte Datenanwendungsfälle bereitstellen.

Ausreichende Daten für die Entwicklung eines ML-Modells bereitstellen

Um ein nützliches ML-Modell zu entwickeln, benötigen Sie genügend Daten. Um eine Kategorie vorherzusagen, ist die empfohlene Anzahl von Beispielen für jede Kategorie zehnmal die Anzahl der Features. Je mehr Kategorien Sie vorhersagen möchten, desto mehr Daten benötigen Sie. Unausgeglichene Datasets erfordern noch mehr Daten. Wenn nicht genügend Daten mit Labels verfügbar sind, sollten Sie halbüberwachtes Lernen in Betracht ziehen.

Die Dataset-Größe hat auch Auswirkungen auf Training und Bereitstellung: Wenn Sie ein kleines Dataset haben, können Sie es direkt in einer Notebooks-Instanz trainieren. Wenn Sie größere Datasets haben, die verteilte Verteilung erfordern, verwenden Sie den benutzerdefinierten Vertex AI-Trainingsdienst. Wenn Google das Modell für Ihre Daten trainieren soll, verwenden Sie AutoML.

Daten für den Verbrauch vorbereiten

Gut vorbereitete Daten können die Modellentwicklung beschleunigen. Achten Sie beim Konfigurieren der Datenpipeline darauf, dass sowohl Batch- als auch Stream-Daten verarbeitet werden können, damit Sie für beide Datentypen konsistente Ergebnisse erhalten.

Modellentwicklung und -training

Wenden Sie folgende Best Practices für Modellentwicklung und Training auf Ihre eigene Umgebung an.

Verwaltet oder benutzerdefiniert trainierte Modellentwicklung auswählen

Berücksichtigen Sie beim Erstellen Ihres Modells die höchste Abstraktionsebene, die möglich ist. Verwenden Sie nach Möglichkeit AutoML, damit die Entwicklungs- und Trainingsaufgaben für Sie übernommen werden. Wählen Sie für benutzerdefinierte Modelle anstelle von selbstverwalteten Optionen verwaltete Optionen für Skalierbarkeit und Flexibilität aus. Weitere Informationen zu Modellentwicklungsoptionen finden Sie unter Empfohlene Tools und Produkte verwenden.

Erwägen Sie die Nutzung des Vertex AI-Trainingsservice statt eines selbstverwalteten Trainings auf Compute Engine-VMs oder Deep Learning VM-Containern. Für eine JupyterLab-Umgebung eignet sich Vertex AI Workbench, das sowohl verwaltete als auch vom Nutzer verwaltete JupyterLab-Umgebungen bietet. Weitere Informationen finden Sie unter Entwicklung maschinellen Lernens und Operationalisiertes Training.

Vorgefertigte oder benutzerdefinierte Container für benutzerdefiniert trainierte Modelle verwenden

Für benutzerdefinierte Modelle in Vertex AI können Sie je nach ML-Framework und Framework-Version vordefinierte oder benutzerdefinierte Container verwenden. Vordefinierte Container stehen für Python-Trainingsanwendungen zur Verfügung, die für bestimmte TensorFlow-, scikit-learn-, PyTorch- und XGBoost-Versionen erstellt wurden.

Andernfalls können Sie einen benutzerdefinierten Container für Ihren Trainingsjob erstellen. Sie können beispielsweise einen benutzerdefinierten Container verwenden, wenn Sie Ihr Modell mit einem Python ML-Framework trainieren möchten, das in einem vordefinierten Container nicht verfügbar ist, oder wenn Sie mit einer anderen Programmiersprache als Python trainieren möchten. Installieren Sie in Ihrem benutzerdefinierten Container im Vorfeld die Trainingsanwendung und alle zugehörigen Abhängigkeiten in einem Image, in dem der Trainingsjob ausgeführt wird.

Anforderungen für verteiltes Training berücksichtigen

Prüfen Sie Ihre Anforderungen für verteiltes Training. Mit einigen ML-Frameworks wie TensorFlow und PyTorch können Sie identischen Trainingscode auf mehreren Computern ausführen. Diese Frameworks koordinieren die Arbeitsteilung automatisch anhand der Umgebungsvariablen, die auf jeder Maschine festgelegt werden. Andere Frameworks erfordern möglicherweise zusätzliche Anpassungen.

Nächste Schritte

Weitere Informationen zu AI und maschinellem Lernen finden Sie hier:

• Best Practices für die Implementierung von maschinellem Lernen in Google Cloud.
• Leitfaden zu MLOps: Ein ML-Framework für Continuous Delivery und Automatisierung von maschinellem Lernen.

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Zuverlässigkeit, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance.

Design für umweltfreundliche Nachhaltigkeit

Dieses Dokument des Google Cloud-Architektur-Frameworks fasst zusammen, wie Sie die ökologische Nachhaltigkeit Ihrer Arbeitslasten in Google Cloud angehen können. Es enthält Informationen dazu, wie Sie Ihren CO2-Fußabdruck in Google Cloud minimieren können.

Informationen zur CO2-Bilanz

Verwenden Sie das Dashboard CO₂-Bilanz, um den CO2-Ausstoß in Ihrer Google Cloud-Nutzung zu verstehen. Das CO₂-Bilanz-Dashboard ordnet die Emissionen Ihren eigenen Google Cloud-Projekten und den von Ihnen verwendeten Cloud-Diensten zu.

Weitere Informationen finden Sie unter Informationen zu Ihrer CO₂-Bilanz im Artikel „CO₂-Bilanz reduzieren“.

Geeignetste Cloud-Regionen auswählen

Eine einfache und effektive Möglichkeit, CO2-Emissionen zu reduzieren, ist die Wahl von Cloud-Regionen mit geringeren CO2-Emissionen. Als Entscheidungshilfe veröffentlicht Google CO2-Daten für alle Google Cloud-Regionen.

Wenn Sie eine Region auswählen, müssen Sie möglicherweise die Emissionen gegen andere Anforderungen wie Preis und Netzwerklatenz abwägen. Verwenden Sie zum Auswählen einer Region die Google Cloud-Regionsauswahl.

Weitere Informationen finden Sie unter Geeignete Cloud-Regionen auswählen im Artikel „Reduzieren Sie Ihre CO₂-Bilanz.“

Geeignetste Cloud-Dienste auswählen

Erwägen Sie zur Reduzierung Ihrer vorhandenen CO2-Bilanz die Migration Ihrer lokalen VM-Arbeitslasten zu Compute Engine.

Beachten Sie auch, dass für viele Arbeitslasten keine VMs erforderlich sind. Stattdessen können Sie ein serverloses Angebot verwenden. Diese verwalteten Dienste können die Nutzung von Cloud-Ressourcen optimieren, oft automatisch, wodurch gleichzeitig die Cloud-Kosten und der CO2-Fußabdruck reduziert werden.

Weitere Informationen finden Sie unter Wählen Sie die am besten geeigneten Cloud-Dienste aus in „Reduzieren Sie Ihre CO₂-Bilanz.“

Inaktive Cloud-Ressourcen minimieren

Inaktive Ressourcen verursachen unnötige Kosten und Emissionen. Einige häufige Ursachen für inaktive Ressourcen sind:

• Nicht verwendete, aktive Cloud-Ressourcen, z. B. inaktive VM-Instanzen.
• Übermäßig bereitgestellte Ressourcen, z. B. größere VM-Maschinentypen als für eine Arbeitslast erforderlich.
• Nicht optimale Architekturen wie Lift-and-Shift-Migrationen, die nicht immer für Effizienz optimiert werden. Erwägen Sie inkrementelle Verbesserungen dieser Architekturen.

Im Folgenden finden Sie einige allgemeine Strategien, um nicht genutzte Cloudressourcen zu minimieren:

• Identifizieren Sie inaktive oder nicht ausreichend bereitgestellte Ressourcen und löschen Sie sie oder passen Sie ihre Größe an.
• Refaktorieren Sie Ihre Architektur so, dass sie ein optimales Design bietet.
• Migrieren Sie Arbeitslasten zu verwalteten Diensten.

Weitere Informationen finden Sie unter Inaktive Cloud-Ressourcen minimieren in „CO2-Bilanz reduzieren“.

Emissionen von Batcharbeitslasten reduzieren

Batch-Arbeitslasten in Regionen mit niedrigeren CO2-Emissionen ausführen. Wenn möglich, sollten Sie die Arbeitslasten zu Zeiten mit geringerer Kohlenstoffintensität im Netz ausführen, um Emissionen weiter zu reduzieren.

Weitere Informationen finden Sie unter Emissionen für Batcharbeitslasten reduzieren unter „Google Cloud-CO2-Bilanz reduzieren“.

Nächste Schritte

• Erfahren Sie, wie Sie CO₂-Bilanz-Daten verwenden, um Ihre CO2-Emissionen zu messen, zu melden und zu reduzieren.
• Reduzierung der CO₂-Bilanz von Google Cloud.

Google Cloud-Architektur-Framework: Operative Exzellenz

In dieser Kategorie des Google Cloud-Architektur-Frameworks erfahren Sie, wie Sie Dienste in Google Cloud effizient betreiben. Es wird erläutert, wie Sie Systeme ausführen, verwalten und überwachen, die einen Mehrwert bieten. Außerdem werden Google Cloud-Produkte und -Features, die operative Exzellenz unterstützen, beschrieben. Mithilfe der Prinzipien der operativen Exzellenz können Sie die Grundlage für Zuverlässigkeit schaffen. Dazu werden grundlegende Elemente wie Beobachtbarkeit, Automatisierung und Skalierbarkeit eingerichtet.

Dieses Architektur-Framework beschreibt Best Practices, bietet Empfehlungen zur Implementierung und erläutert einige verfügbare Produkte und Dienste, mit denen Sie die operative Exzellenz erreichen. Mit dem Framework unterstützen wir Sie bei der Entwicklung Ihrer Google Cloud-Bereitstellung, sodass sie den Anforderungen Ihres Unternehmens bestmöglich gerecht wird.

In der Kategorie „Operative Exzellenz“ des Architektur-Frameworks lernen Sie Folgendes:

• Bereitstellungen automatisieren
• Monitoring, Benachrichtigungen und Logging einrichten
• Cloud-Support- und Eskalationsprozesse festlegen
• Kapazitäten und Kontingente verwalten
• Spitzenlasten und Startereignisse planen
• Unternehmenskultur der Automatisierung schaffen

Bereitstellungen automatisieren

In diesem Dokument im Google Cloud-Architektur-Framework finden Sie Best Practices zur Automatisierung Ihrer Builds, Tests und Bereitstellungen.

Die Automatisierung unterstützt Sie bei der Standardisierung Ihrer Builds, Tests und Bereitstellungen, da durch Nutzer verursachte Fehler bei wiederkehrenden Prozessen wie Codeaktualisierungen eliminiert werden. In diesem Abschnitt wird beschrieben, wie Sie verschiedene Prüfungen und Sicherheitsmaßnahmen bei der Automatisierung verwenden. Ein standardisierter maschinengesteuerter Prozess sorgt dafür, dass Ihre Bereitstellungen sicher angewendet werden. Er bietet auch einen Mechanismus, um frühere Bereitstellungen nach Bedarf wiederherzustellen, ohne die Nutzererfahrung wesentlich zu beeinträchtigen.

Code in zentralen Code-Repositories speichern

Speichern Sie Ihren Code in zentralen Code-Repositories, die ein Versionsverwaltungssystem mit Tagging und der Möglichkeit enthalten, Rollback von Codeänderungen durchzuführen. Mit der Versionsverwaltung können Sie Dateien organisieren und den Zugriff, die Aktualisierung und das Löschen zwischen Teams und Organisationen steuern.

Sie können die Repositories nach Bedarf in verschiedenen Entwicklungsphasen versionieren und mit Labels versehen. Labels könnten beispielsweise test, dev und prod sein.

In Google Cloud können Sie Ihren Code in Cloud Source Repositories speichern, versionieren in andere Google Cloud-Produkte einbinden. Wenn Sie Containeranwendungen erstellen, verwenden Sie Artifact Registry, eine verwaltete Registry für Container.

Weitere Informationen zur Versionsverwaltung finden Sie unter Versionsverwaltung. Weitere Informationen zur Implementierung der Entwicklung nach Baumschema mit Ihren Repositories finden Sie unter Entwicklung nach Baumschema.

Continuous Integration und Continuous Deployment (CI/CD) verwenden

Automatisieren Sie Ihre Bereitstellungen mit einem Verfahren für Continuous Integration und kontinuierliche Bereitstellung (CI/CD). Ein CI/CD-Ansatz ist eine Kombination aus Pipelines, die Sie konfigurieren, und Prozessen, denen Ihr Entwicklungsteam folgt.

Ein CI/CD-Ansatz erhöht die Bereitstellungsgeschwindigkeit, indem Ihr Softwareentwicklungsteam produktiver wird. Auf diese Weise können Entwickler kleinere und häufigere Änderungen vornehmen, die gründlich getestet werden, während die für die Bereitstellung dieser Änderungen erforderliche Zeit verkürzt wird.

Automatisieren Sie im Rahmen Ihres CI/CD-Ansatzes alle Schritte, die zum Erstellen, Testen und Bereitstellen Ihres Codes erforderlich sind. Beispiel:

• Wenn neuer Code per Commit an das Repository übergeben wird, ruft der Commit automatisch die Build- und Testpipeline auf.
• Automatisieren Sie Integrationstests.
• Automatisieren Sie Ihre Bereitstellung, damit Änderungen erst dann bereitgestellt werden, wenn Ihr Build bestimmte Testkriterien erfüllt.

In Google Cloud können Sie Cloud Build und Cloud Deploy für Ihre CI/CD-Pipelines verwenden.

Mit Cloud Build können Sie Abhängigkeiten und Versionen definieren, die Sie zum Verpacken und Erstellen eines Anwendungspakets verwenden können. Versionieren Sie Ihre Build-Konfiguration, damit alle Builds konsistent sind und Sie bei Bedarf ein Rollback zu einer vorherigen Konfiguration durchführen können.

Mit Cloud Deploy können Sie Ihre Anwendungen in bestimmten Umgebungen in Google Cloud bereitstellen und Ihre Bereitstellungspipelines verwalten.

Weitere Informationen zur Implementierung von CI/CD finden Sie unter Continuous Integration und Bereitstellungsautomatisierung.

Infrastruktur mithilfe von IaC (Infrastruktur als Code) bereitstellen und verwalten

Infrastruktur als Code ist die Verwendung eines Beschreibungsmodells für die Verwaltung von Infrastrukturen, wie z. B. VMs, und Konfigurationen, wie z. B. Firewallregeln. Mit Infrastruktur als Code können Sie Folgendes tun:

• Erstellen Sie automatisch Ihre Cloud-Ressourcen, einschließlich der Bereitstellungs- und Testumgebungen für Ihre CI/CD-Pipeline.
• Infrastrukturänderungen wie Anwendungsänderungen behandeln. Sie sollten zum Beispiel sicherstellen, dass Änderungen an der Konfiguration geprüft und getestet werden und sich nachprüfen lassen.
• Ihre Cloud-Infrastruktur basiert auf einer einzigen aktuellen Version.
• Replizieren Sie Ihre Cloud-Umgebung nach Bedarf.
• Falls erforderlich, führen Sie ein Rollback zu einer vorherigen Konfiguration durch.

Dieses Konzept von Infrastruktur als Code gilt auch für Projekte in Google Cloud. Sie können diesen Ansatz verwenden, um in Ihren Projekten Ressourcen wie freigegebene VPC-Verbindungen oder IAM-Zugriff (Identity and Access Management) zu definieren. Ein Beispiel für diesen Ansatz finden Sie unter Terraform-Modul für Google Cloud Project Factory.

Tools von Drittanbietern wie Terraform helfen Ihnen beim automatischen Erstellen der Infrastruktur in Google Cloud. Weitere Informationen finden Sie unter Infrastruktur als Code mit Terraform, Cloud Build und GitOps verwalten.

Sie können Google Cloud-Features wie diese verwenden: Projektsperren, Aufbewahrungsrichtlinien für Cloud Storage und Bucket-Sperren für Cloud Storage, um wichtige Ressourcen vor versehentlichem oder böswilligem Löschen zu schützen.

Tests während des gesamten Lebenszyklus der Softwarebereitstellung integrieren

Tests sind entscheidend für die erfolgreiche Einführung Ihrer Software. Kontinuierliche Tests unterstützen Teams dabei, qualitativ hochwertige Software schneller zu erstellen und die Softwarestabilität zu verbessern.

Testtypen:

• Unittests. Unittests sind schnell und helfen Ihnen, schnelle Bereitstellungen durchzuführen. Behandeln Sie Unittests als Teil der Codebasis und nehmen Sie sie in den Build-Prozess auf.
• Integrationstests. Integrationstests sind wichtig, insbesondere für Arbeitslasten, die für die Skalierung entwickelt wurden und von mehr als einem Dienst abhängen. Diese Tests können komplex werden, wenn Sie die Integration mit verbundenen Diensten testen.
• Systemtests. Systemtests sind zeitaufwendig und komplex. Sie helfen Ihnen jedoch, Grenzfälle zu erkennen und Probleme vor der Bereitstellung zu beheben.
• Andere Tests. Es sollten noch andere Tests ausgeführt werden, darunter statische Tests, Lasttests, Sicherheitstests und Richtlinienvalidierungstests. Führen Sie diese Tests aus, bevor Sie die Anwendung in der Produktion bereitstellen.

So integrieren Sie Tests:

• Alle Testarten kontinuierlich während des gesamten Lebenszyklus der Softwarebereitstellung durchführen.
• Automatisieren Sie diese Tests und fügen Sie sie in die CI/CD-Pipeline ein. Ihre Pipeline sollte fehlschlagen, wenn einer der Tests fehlschlägt.
• Aktualisieren die Tests und fügen Sie kontinuierlich neue Tests hinzu, um den Betriebszustand Ihrer Bereitstellung zu verbessern und beizubehalten.

Für Ihre Testumgebungen:

• Verwenden Sie separate Google Cloud-Projekte für jede Ihrer Testumgebungen. Verwenden Sie für jede Anwendung eine separate Projektumgebung. Diese Trennung sorgt für eine klare Abgrenzung zwischen Ressourcen der Produktionsumgebung und den Ressourcen Ihrer niedrigeren Umgebungen. Diese Trennung trägt dazu bei, dass Änderungen in einer Umgebung nicht versehentlich andere Umgebungen beeinträchtigen.
• Automatisieren Sie die Erstellung von Testumgebungen. Eine Möglichkeit für diese Automatisierung ist die Verwendung von Infrastruktur als Code.
• Testen Sie Änderungen in einer synthetischen Produktionsumgebung. Diese Umgebung bietet eine produktionsähnliche Umgebung, um Ihre Anwendung zu testen und verschiedene Arten von Tests für Ihre Arbeitslasten durchzuführen. Dazu gehören End-to-End-Tests und Leistungstests.

Weitere Informationen zur Implementierung von kontinuierlichen Tests finden Sie unter Testautomatisierung.

Bereitstellungen schrittweise einführen

Wählen Sie Ihre Bereitstellungsstrategie anhand wichtiger Parameter wie minimalen Unterbrechungen für Endnutzer, Rolling Updates, Rollback-Strategien und A/B-Teststrategien aus. Bewerten Sie für jede Arbeitslast diese Anforderungen und wählen Sie eine Bereitstellungsstrategie aus bewährten Verfahren wie Rolling Updates, Blau/Grün-Bereitstellungen und Canary-Deployments aus.

Lassen Sie nur CI/CD-Prozesse Änderungen in Ihrer Produktionsumgebung vornehmen und veröffentlichen.

Ziehen Sie die Verwendung einer unveränderlichen Infrastruktur in Betracht. Eine unveränderliche Infrastruktur ist eine Infrastruktur, die nicht geändert oder aktualisiert wird. Wenn Sie neuen Code bereitstellen oder eine andere Konfiguration in Ihrer Umgebung ändern müssen, ersetzen Sie die gesamte Umgebung (z. B. eine Sammlung von VMs oder Pods) durch die neue Umgebung. Blau/Grün-Bereitstellungen sind ein Beispiel für eine unveränderliche Infrastruktur.

Wir empfehlen, Canary-Tests durchzuführen und Ihr System auf Fehler zu beobachten, während Sie Änderungen bereitstellen. Diese Art der Beobachtung ist einfacher, wenn Sie ein robustes Monitoring- und Benachrichtigungssystem haben. Für A/B-Tests oder Canary-Tests können Sie die verwalteten Instanzgruppen von Google Cloud verwenden. Sie können dann einen langsamen Roll-out oder bei Bedarf eine Wiederherstellung ausführen.

Mit Cloud Deploy können Sie Bereitstellungen automatisieren und Ihre Bereitstellungspipeline verwalten. Sie können auch viele Tools von Drittanbietern wie Spinnaker und Tekton in Google Cloud sowohl für automatisierte Bereitstellungen als auch für das Erstellen von Bereitstellungspipelines verwenden.

Frühere Releases nahtlos wiederherstellen

Definieren Sie Ihre Wiederherstellungsstrategie als Teil Ihrer Bereitstellungsstrategie. Prüfen Sie, ob Sie eine Bereitstellung oder eine Infrastrukturkonfiguration auf eine frühere Version des Quellcodes zurücksetzen können. Die Wiederherstellung einer vorherigen stabilen Bereitstellung ist ein wichtiger Schritt beim Vorfallmanagement für Zuverlässigkeits- und Sicherheitsvorfälle.

Achten Sie außerdem darauf, dass Sie die Umgebung in dem Zustand wiederherstellen können, in dem sie sich vor dem Start des Bereitstellungsprozesses befand. Dies kann Folgendes beinhalten:

• Die Möglichkeit, Codeänderungen in Ihrer Anwendung rückgängig zu machen.
• Die Möglichkeit, alle Konfigurationsänderungen rückgängig zu machen, die an der Umgebung vorgenommen wurden.
• Verwendung einer unveränderlichen Infrastruktur und Sicherstellung, dass Bereitstellungen die Umgebung nicht ändern Durch diese Vorgehensweisen können Konfigurationsänderungen leichter rückgängig gemacht werden.

CI/CD-Pipelines überwachen

Überwachen Sie Ihre CI/CD-Pipelines, um Ihren automatisierten Prozess für das Entwickeln, Testen und Bereitstellen reibungslos zu gestalten. Legen Sie Benachrichtigungen fest, die angeben, wenn etwas in einer Pipeline fehlschlägt. Jeder Schritt Ihrer Pipeline sollte geeignete Logberichte schreiben, damit Ihr Team die Ursachenanalyse durchführen kann, wenn eine Pipeline fehlschlägt.

In Google Cloud sind alle CI/CD-Dienste in die Operations-Suite von Google Cloud eingebunden. Beispiel:

• Cloud Source Repositories sind in den Pub/Sub-Dienst eingebunden.
• Cloud Build ist in Pub/Sub eingebunden und speichert auch Audit-Logs und Build-Logs. Mit dem Dienst Cloud Monitoring können Sie Benachrichtigungen für bestimmte Keywords in Ihren Build-Logs und für viele andere Messwerte festlegen.
• Cloud Deploy speichert Audit-Logs.

Weitere Informationen zum Monitoring und Logging finden Sie unter Monitoring, Benachrichtigungen und Logging einrichten.

Anwendungen sicher bereitstellen

Lesen Sie den Abschnitt Anwendungen sicher bereitstellen in der Kategorie Sicherheit, Compliance und Datenschutz des Architektur-Frameworks.

Verwaltungsrichtlinien für Versions-Releases festlegen

Damit Ihre Entwickler Fehler vermeiden können und eine schnelle Softwarebereitstellung ermöglicht wird, müssen Ihre Verwaltungsrichtlinien für die Veröffentlichung neuer Softwareversionen klar dokumentiert sein.

Release-Entwickler überwachen, wie Software erstellt und ausgeliefert wird. Das Release-Engineering basiert auf vier Vorgehensweisen:

• Selfservice-Modus: Erstellen Sie Richtlinien, mit denen Softwareentwickler häufige Fehler vermeiden können. Diese Richtlinien werden im Allgemeinen in automatisierten Prozessen kodifiziert.

• Häufige Releases: Eine hohe Geschwindigkeit hilft bei der Fehlerbehebung. Häufige Releases basieren auf automatisierten Einheitentests.

• Hermetische Builds: Achten Sie auf Konsistenz mit Ihren Build-Tools. Versionieren Sie die Build-Compiler, die Sie zum Erstellen von Versionen im Vergleich zu vor einem Monat verwenden.

• Richtlinienerzwingung: Alle Änderungen erfordern eine Codeüberprüfung, idealerweise eine Reihe von Richtlinien zur Durchsetzung der Sicherheit. Die Durchsetzung von Richtlinien verbessert den Code Review, die Fehlerbehebung und das Testen eines neuen Releases.

Nächste Schritte

• Monitoring, Benachrichtigungen und Logging einrichten (nächstes Dokument in dieser Reihe)
• Anwendungen sicher bereitstellen aus der Kategorie Sicherheits, Compliance und Datenschutz des Architektur-Frameworks
• Best Practices für Containererstellung
• Weitere Informationen zu technischen Funktionen
• Entdecken Sie weitere Kategorien im Architektur-Framework, z. B. Systemdesign, Sicherheit, Datenschutz und Compliance, Zuverlässigkeit, Kostenoptimierung und Leistungsoptimierung.

Monitoring, Benachrichtigungen und Logging einrichten

In diesem Dokument im Google Cloud-Architektur-Framework wird gezeigt, wie Sie Monitoring, Benachrichtigungen und Logging einrichten, um auf Basis des Verhaltens Ihres Systems reagieren zu können. Dazu gehört die Ermittlung aussagekräftiger, in Dashboards angezeigter Messwerte, um das Aufrufen von Informationen zu Ihren Systemen zu erleichtern.

Das Forschungsprogramm DORA (DevOps Resource and Assessment) definiert Monitoring so:

Monitoring ist der Vorgang des Erfassens, Analysierens und Nutzens von Informationen aus der Überwachung von Anwendungen und Infrastrukturen, um fundierte Geschäftsentscheidungen zu treffen. Monitoring ist eine wichtige Funktion, die Ihnen Einblicke in Ihre Systeme und Arbeitsvorgänge verleiht.

Mit Monitoring können Serviceinhaber:

• Fundierte Entscheidungen treffen, wenn Änderungen am Service die Leistung beeinträchtigen
• Informierte Ansätze zur Reaktion auf Vorfälle nutzen
• Das Verhältnis des Service zu den Geschäftsziele messen

Wenn Monitoring, Logging und Benachrichtigungen eingerichtet sind, können Sie:

• Langfristige Trends analysieren
• Ihre Tests im Zeitverlauf vergleichen
• Benachrichtigungen für wichtige Messwerte definieren
• Relevante Echtzeit-Dashboards erstellen
• Aufarbeitungsanalysen durchführen
• Messwerte zum Unternehmen als auch zum Systemzustand überwachen
  • Messwerte zum Unternehmen geben Aufschluss darüber, wie gut Ihre Systeme Ihr Unternehmen unterstützen. Verwenden Sie Messwerte, um beispielsweise Folgendes zu überwachen:
    • Die Kosten der Bereitstellung einer Anwendung für einen Nutzer
    • Die Volumenänderung in den Websitezugriffe nach einer Neugestaltung
    • Wie lange ein Kunde benötigt, um ein Produkt auf Ihrer Website zu kaufen
  • Messwerte zum Systemzustand geben Aufschluss darüber, ob Ihre Systeme ordnungsgemäß funktionieren und sich innerhalb eines akzeptablen Leistungsniveaus befinden.

Verwenden Sie zum Monitoring Ihres Systems die folgenden vier goldenen Signale:

• Latenz. Die Zeit, die für die Bearbeitung einer Anfrage benötigt wird.
• Traffic. Der Umfang der Nachfrage für das System
• Fehler. Die Rate der fehlgeschlagenen Anfragen. Fehler können explizit (z. B. HTTP 500s), implizit (z. B. eine HTTP 200-Erfolgsantwort bei falschem Inhalt) oder nach Richtlinie (werden z. B. Antwortzeiten von einer Sekunde garantiert, so ist jede Bearbeitungszeit über einer Sekunde ein Fehler) sein.
• Sättigung. Wie ausgelastet Ihr Dienst ist. Die Sättigung ist ein Maß für den Systemanteil, wobei die am meisten belasteten Ressourcen hervorgehoben werden (in einem speicherbeschränkten System wird die Speichermenge angezeigt; in einem E/A-beschränkten System werden E/A-Vorgänge angezeigt).

Monitoring-Plan erstellen

Erstellen Sie einen Monitoring-Plan, der auf die Ziele Ihrer Organisation und deren Betriebsstrategie zugeschnitten ist. Berücksichtigen Sie bei der Anwendungsentwicklung Monitoring und Beobachtbarkeitsplanung. Früh in der Anwendungsentwicklung einen Monitoring-Plan einzubeziehen kann eine Organisation zu operativer Exzellenz führen.

Fügen Sie Ihrem Monitoring-Plan folgende Details hinzu:

• Schließen Sie alle Ihre Systeme ein, einschließlich lokaler Ressourcen und Cloud-Ressourcen.
• Überwachen Sie Ihre Cloudkosten, um sicherzustellen, dass Ihre Budgetgrenzen nicht aufgrund von Skalierungsereignissen überschritten werden.
• Erstellen Sie verschiedene Monitoring-Strategien, um die Leistung der Infrastruktur, die Benutzererfahrung und die Leistungskennzahlen (KPIs, Key Performance Indicators) Ihres Unternehmens zu erfassen. Beispielsweise können statische Schwellenwerte gut geeignet sein, um die Infrastrukturleistung zu messen, sie sagen aber wenig über das Benutzererlebnis aus.

Aktualisieren Sie den Plan, während Ihre Monitoring-Strategien reifen. Iterieren Sie den Plan, um den Zustand Ihrer Systeme zu verbessern.

Definieren Sie Messwerte, die alle Aspekte Ihrer Organisation messen

Definieren Sie die Messwerte, die erforderlich sind, um das Verhalten Ihrer Bereitstellung zu messen. Anleitung:

• Definieren Sie Ihre Geschäftsziele.
• Identifizieren Sie die Messwerte und KPIs, die quantifizierbare Informationen zur Leistungsmessung liefern. Achten Sie darauf, dass Ihre Messwertdefinitionen für alle Aspekte Ihrer Organisation relevant sind – von geschäftlichen Anforderungen (inklusive der Cloud-Kosten) bis hin zu technischen Komponenten.
• Verwenden Sie diese Messwerte, um für Ihre Anwendungen Service Level Indicators (SLIs) zu erstellen. Weitere Informationen finden Sie unter Geeignete SLIs auswählen.

Typische Messwerte für verschiedene Komponenten

Messwerte werden auf allen Ebenen Ihres Service generiert, von der Infrastruktur über Netzwerke bis hin zur Geschäftslogik. Beispiel:

• Infrastrukturmesswerte:
  • VM-Statistiken, darunter Instanzen, CPU, Arbeitsspeicher, Auslastung und Mengen
  • Containerbasierte Statistiken, darunter Clusterauslastung, Clusterkapazität, Pod-Level-Nutzung und Mengen
  • Netzwerkstatistiken, darunter eingehende/ausgehende Bandbreite, Bandbreite zwischen Komponenten, Latenz und Durchsatz
  • Anfragen pro Sekunde, gemessen vom Load-Balancer
  • Gesamtzahl der gelesenen Laufwerksblöcke pro Laufwerk
  • Pakete, die über eine bestimmte Netzwerkschnittstelle gesendet werden
  • Größe des Arbeitsspeicher-Heaps für einen bestimmten Prozess
  • Verteilung der Antwortlatenzen
  • Anzahl der ungültigen Abfragen, die von einer Datenbankinstanz abgelehnt wurden
• Anwendungsmesswerte:
  • Anwendungsspezifisches Verhalten, darunter Abfragen pro Sekunde, Schreibvorgänge pro Sekunde und pro Sekunde gesendete Nachrichten
• Messwerte für verwaltete Servicestatistiken:
  • QPS, Durchsatz, Latenz, Auslastung von Google verwalteter Dienste (APIs oder Produkte wie BigQuery, App Engine und Bigtable)
• Messwerte für Netzwerkverbindungsstatistiken:
  • Statistiken zu VPN-/Interconnect-Verbindungen zu lokalen Systemen oder Systemen, die sich außerhalb von Google Cloud befinden.
• SLIs
  • Messwerte, die etwas über den Gesamtzustand des Systems aussagen.

Monitoring einrichten

Monitoring einrichten, um sowohl lokale Ressourcen als auch Cloud-Ressourcen zu überwachen.

Wählen Sie eine Monitoring-Lösung aus, die:

• Plattformunabhängig ist
• Einheitliche Funktionen für das Monitoring von lokalen, Hybrid- und Multi-Cloud-Umgebungen bietet

Wenn Sie eine einzelne Plattform nutzen, um Monitoringdaten aus verschiedenen Quellen zu konsolidieren, können Sie einheitliche Messwerte und Dashboards zur Visualisierung erstellen.

Wenn Sie das Monitoring einrichten, sollten Sie Monitoring-Aufgaben nach Möglichkeit automatisieren.

Monitoring mit Google Cloud

Ein Monitoringdienst wie Cloud Monitoring zu verwenden ist einfacher, als selbst einen Monitoringdienst zu erstellen. Das Monitoring einer komplexen Anwendung ist ein erhebliches technisches Unterfangen. Selbst wenn eine vorhandene Infrastruktur für Instrumentierung, Datenerfassung und -anzeige sowie Benachrichtigungen vorhanden ist, ist die Erstellung und Verwaltung ein Vollzeitjob für Nutzer.

Mit Cloud Monitoring erhalten Sie Einblick in Leistung, Verfügbarkeit und Zustand Ihrer Anwendungen und Ihrer Infrastruktur, und zwar für lokale und Cloud-Ressourcen.

Cloud Monitoring ist ein verwalteter Dienst, der Teil der Operations-Suite von Google Cloud ist. Mit Cloud Monitoring können Sie Google Cloud-Dienste und benutzerdefinierte Messwerte beobachten. Cloud Monitoring bietet eine API für die Integration in Monitoringtools von Drittanbietern.

Cloud Monitoring fasst Messwerte, Logs und Ereignisse aus der cloudbasierten Infrastruktur Ihres Systems zusammen. Diese Daten bieten Entwicklern und Betreibern eine Vielzahl von beobachtbaren Signalen, die die Ursachenanalyse beschleunigen und die durchschnittliche Zeit der Problembehebung reduzieren können. Mit Cloud Monitoring können Sie Benachrichtigungen und benutzerdefinierte Messwerte definieren, die Ihren Geschäftszielen entsprechen und Sie beim Zusammenfassen, Visualisieren und Monitoring des Systemzustands unterstützen.

Cloud Monitoring bietet Standard-Dashboards für Cloud- und Open-Source-Anwendungsdienste. Mit dem Messwertmodell können Sie benutzerdefinierte Dashboards mit leistungsstarken Visualisierungstools definieren und Diagramme im Metrics Explorerkonfigurieren.

Benachrichtigung einrichten

Ein gutes Benachrichtigungssystem verbessert die Möglichkeit, Funktionen freizugeben. Es hilft, die Leistung im Zeitverlauf zu vergleichen, um die Geschwindigkeit von Feature-Releases oder die Notwendigkeit eines Rollbacks für ein Feature-Release zu ermitteln. Informationen zu Rollbacks finden Sie unter Frühere Releases nahtlos wiederherstellen.

Weisen Sie bei der Einrichtung von Benachrichtigungen diese direkt kritischen Messwerten zu. Zu diesen kritischen Messwerten gehören:

• Die vier goldenen Signale:
  • Latenz
  • Traffic
  • Fehler
  • Sättigung
• Systemzustand
• Service Usage
• Sicherheitshinweise
• Benutzererfahrung

Wenn Benachrichtigungen verwertbar sind, wird die Zeit bis zur Problembehebung minimiert. Gehen Sie dazu für jede Benachrichtigung so vor:

• Fügen Sie eine klare Beschreibung hinzu, die auch besagt, was überwacht wird und welche geschäftsrelevanten Auswirkungen diese Elemente haben.
• Geben Sie alle erforderlichen Informationen für sofortige Aktionen an. Wenn es einige Klicks und Aufrufe braucht, um Benachrichtigungen zu verstehen, ist es für den Bereitschaftsdienst schwierig, zu reagieren.
• Definieren Sie Prioritätsstufen für verschiedene Benachrichtigungen.
• Geben Sie die für eine Reaktion auf die Benachrichtigung zuständige Person oder das relevante Team klar an.

Binden Sie bei kritischen Anwendungen und Diensten selbstreparierende Aktionen in Benachrichtigungen ein, die aufgrund häufiger Fehlerbedingungen wie Dienstfehler, Konfigurationsänderungen oder Durchsatzspitzen ausgelöst werden.

Versuchen Sie beim Einrichten von Benachrichtigungen, zusätzlichen Aufwand zu vermeiden. Zusätzlichen Aufwand können Sie zum Beispiel vermeiden, indem Sie häufige Fehler vermeiden oder Korrekturen für diese Fehler automatisieren, sodass möglicherweise keine Benachrichtigung ausgelöst wird. Wenn Sie zusätzlichen Aufwand vermeiden, können sich die Mitarbeiter darauf konzentrieren, dass die Betriebskomponenten Ihrer Anwendung zuverlässig sind. Weitere Informationen finden Sie unter Automatisierungskultur schaffen.

Monitoring- und Benachrichtigungs-Dashboards erstellen

Sobald das Monitoring eingerichtet ist, erstellen Sie relevante, unkomplizierte Dashboards, die Informationen aus Ihren Monitoring- und Benachrichtigungssystemen enthalten.

Es kann schwierig sein, die Auswahl einer geeigneten Methode zur Dashboard-Visualisierung mit Ihren Zielen in Sachen Zuverlässigkeit in Einklang zu bringen. Erstellen Sie Dashboards, um Folgendes zu visualisieren:

• Kurzzeit- und Echtzeitanalysen
• Langzeitanalysen

Weitere Informationen zur Implementierung eines visuellen Managements finden Sie im Artikel Visuelles Management.

Logging für kritische Anwendungen aktivieren

Logging-Dienste sind für das Monitoring Ihrer Systeme entscheidend. Während Messwerte die Grundlage für bestimmte zu überwachende Elemente bilden, enthalten Logs wertvolle Informationen, die Sie für die Fehlerbehebung, sicherheitsbezogene Analysen und Compliance-Anforderungen benötigen.

Durch das Logging der von Ihren Systemen generierten Daten können Sie einen effektiven Sicherheitsstatus gewährleisten. Weitere Informationen zu Logging und Sicherheit finden Sie unter Logging- und Erkennungskontrollen implementieren in der Sicherheitskategorie des Architektur-Frameworks.

Cloud Logging ist ein integrierter Logging-Dienst, den Sie zum Speichern, Suchen, Analysieren, Überwachen und Melden von Logdaten und Ereignissen nutzen können. Logging erfasst automatisch Logs aus Diensten von Google Cloud und anderen Cloud-Anbietern. Sie können diese Logs verwenden, um Messwerte für das Monitoring zu erstellen und Logging-Exporte in externen Diensten wie Cloud Storage, BigQuery und Pub/Sub zu erstellen.

Audit-Trail einrichten

Verwenden Sie Cloud-Audit-Logs, um in Ihren Google Cloud-Projekten Fragen wie „Wer hat was, wo und wann getan?“ zu beantworten.

Cloud-Audit-Logging zeichnet verschiedene Arten von Aktivitäten auf, z. B.:

• Logs zur Administratoraktivität enthalten Logeinträge für API-Aufrufe oder andere Aktionen, die die Konfiguration oder Metadaten von Ressourcen ändern. Administratoraktivitäts-Logs sind immer aktiviert.
• In Audit-Logs für den Datenzugriff werden API-Aufrufe zum Erstellen, Ändern oder Lesen der von Nutzern bereitgestellten Daten aufgezeichnet. Da Audit-Logs für den Datenzugriff relativ groß sein können, sind sie standardmäßig deaktiviert. Sie können konfigurieren, für welche Google Cloud-Dienste Datenzugriffslogs erzeugt werden.

Eine Liste der Google Cloud-Dienste, die Audit-Logs schreiben, finden Sie unter Google-Dienste mit Audit-Logs. Mit IAM-Steuerelementen (Identity and Access Management) können Sie einschränken, wer Audit-Logs aufrufen kann.

Nächste Schritte

• Cloud-Support- und Eskalationsprozesse festlegen (nächstes Dokument in dieser Reihe).
• Operations-Suite von Google Cloud
• Nutzen Sie Cloud Monitoring, um Einblick in die Leistung, Verfügbarkeit und Integrität Ihrer Anwendungen und Infrastruktur zu erhalten.
• Weitere Informationen zu Monitoring und Beobachtbarkeit
• Entdecken Sie weitere Kategorien im Architektur-Framework, z. B. Systemdesign, Sicherheit, Datenschutz und Compliance, Zuverlässigkeit, Kostenoptimierung und Leistungsoptimierung.

Cloud-Support- und Eskalationsprozesse festlegen

In diesem Dokument des Google Cloud-Architektur-Frameworks erfahren Sie, wie Sie einen effektiven Eskalationsprozess definieren. Die Einrichtung des Supports von Ihrem Cloud-Anbieter oder einem anderen Drittanbieter ist ein wichtiger Bestandteil einer effektiven Eskalationsverwaltung.

Google Cloud bietet verschiedene Supportkanäle, darunter Live-Support oder Support über publizierte Hilfsmedien wie Entwickler-Communities oder . Produktdokumentationen. Ein Angebot von Cloud Customer Care sorgt dafür, dass Sie mit Google Cloud daran arbeiten können, Ihre Arbeitslasten effizient auszuführen.

Support von Ihren Anbietern ermitteln

Erwerben Sie einen Supportvertrag von Ihrem Cloud- oder einem anderen Drittanbieter. Der Support ist entscheidend, um eine schnelle Reaktion und Lösung verschiedener operativer Probleme zu garantieren.

Wenn Sie mit Google Cloud Customer Care arbeiten, sollten Sie ein Customer Care-Angebot erwerben, das den standardmäßigen, erweiterten oder den Premiumsupport umfasst. Ziehen Sie den erweiterten oder den Premiumsupport für wichtige Produktionsumgebungen in Betracht.

Eskalationsprozess definieren

Ein klar definierter Eskalationsprozess ist wichtig, um Aufwand und Zeit für die Identifizierung und Behebung von Problemen in Ihren Systemen zu reduzieren. Dazu gehören auch Probleme, die Unterstützung für Google Cloud-Produkte oder für andere Cloud-Producer oder Drittanbieterdienste erfordern.

So erstellen Sie Ihren Eskalationspfad:

• Definieren Sie, wann und wie Probleme intern eskaliert werden.
• Definieren Sie, wann und wie Supportfälle bei Ihrem Cloud- oder einem anderen Drittanbieter erstellt werden.
• Erfahren Sie, wie Sie mit den Teams zusammenarbeiten, die Ihnen Support bieten. Für Google Cloud sollten Sie und Ihre Betriebsteams die Best Practices für die Arbeit mit dem Kundendienst lesen. Binden Sie diese Vorgehensweisen in Ihren Eskalationspfad ein.
• Suchen oder erstellen Sie Dokumente, die Ihre Architektur beschreiben. Stellen Sie sicher, dass diese Dokumente Informationen enthalten, die für die Supporttechniker hilfreich sind.
• Definieren Sie, wie Ihre Teams während eines Ausfalls kommunizieren.
• Sorgen Sie dafür, dass Personen, die Support benötigen, entsprechende Supportberechtigungen haben, um auf das Google Cloud-Supportcenter zuzugreifen oder mit anderen Supportanbietern zu kommunizieren. Informationen zur Verwendung des Google Cloud-Supportcenters finden Sie unter Supportverfahren.
• Richten Sie Monitoring, Benachrichtigungen und Logging ein, damit Sie die erforderlichen Informationen haben, um auf Problemen reagieren zu können.
• Erstellen Sie Vorlagen für Vorfallberichte. Informationen zur Aufnahme in die Vorfallberichte finden Sie unter Best Practices für die Arbeit mit dem Kundendienst.
• Dokumentieren Sie den Eskalationsprozess Ihrer Organisation. Sorgen Sie dafür, dass es klar definierte Aktionen zur Behebung von Eskalationen gibt.
• Erstellen Sie einen Schulungsplan, mit dem neue Teammitglieder die Interaktion mit dem Support erlernen können.

Testen Sie Ihren Eskalationsprozess regelmäßig intern. Testen Sie Ihren Eskalationsprozess vor größeren Ereignissen wie Migrationen, Produkteinführungen und Spitzenlasten. Wenn Sie den Premium-Support von Google Cloud Customer Care haben, kann Ihr Technical Account Manager Ihren Eskalationsprozess prüfen und Ihre Tests mit Google Cloud Customer Care koordinieren.

Prüfen Sie, ob Sie Kommunikationen vom Support erhalten.

Achten Sie darauf, dass Ihre Administratoren Kommunikation von Cloud-Anbietern und Drittanbietern erhalten. Mit diesen Informationen können Administratoren fundierte Entscheidungen treffen und Probleme beheben, bevor sie noch größere Probleme verursachen. Prüfen Sie, ob Folgendes zutrifft:

• Sicherheits-, Netzwerk- und Systemadministratoren können wichtige E-Mails von Google Cloud und Ihren anderen Anbietern oder Diensten empfangen.
• Sicherheits-, Netzwerk- und Systemadministratoren können Systembenachrichtigungen erhalten, die von Monitoringtools wie Cloud Monitoring generiert wurden.
• Projektinhaber haben E-Mail-fähige Nutzernamen, damit sie kritische E-Mails erhalten können.

Informationen zum Verwalten von Benachrichtigungen über Google Cloud finden Sie unter Kontakte für Benachrichtigungen verwalten.

Prüfprozesse festlegen

Richten Sie Prüf- oder Postmortem-Prozesse ein. Nutzen Sie diese Prozesse, nachdem Sie ein neues Support-Ticket erstellt oder ein vorhandenes Support-Ticket eskaliert haben. Dokumentieren Sie im Rahmen von Postmortems gewonnenen Erkenntnisse und verfolgen Sie Migrationen. Unterstützen Sie bei dieser Prüfung eine Postmortem-Kultur ohne Schuldzuweisung.

Weitere Informationen zu Postmortems finden Sie unter Postmortem-Kultur: Aus Fehlern lernen.

Kompetenzzentren aufbauen

Es kann sich als nützlich erweisen, die Informationen, Erfahrungswerte und Arbeitsabläufe Ihrer Organisation in einer internen Wissensdatenbank wie einem Wiki, einer Google Sites-Website oder einer Intranet-Website festzuhalten. Immer mehr neue Produkte und Features werden in Google Cloud eingeführt. Dieses Wissen kann Ihnen helfen, herauszufinden, warum Sie ein bestimmtes Design für Ihre Anwendungen und Dienste ausgewählt haben. Weitere Informationen finden Sie unter Architekturentscheidungsdatensätze.

Außerdem empfiehlt es sich, Google Cloud-Experten und -Champions in Ihrer Organisation zu ernennen. Für diese Champions stehen eine Reihe von Schulungs- und Zertifizierungsoptionen zur Verfügung, mit denen sie ihr jeweiliges Fachwissen erweitern können. Teams können den Google Cloud-Blog abonnieren, um immer auf dem Laufenden zu bleiben und aktuelle Neuigkeiten, Ankündigungen und Kundenberichte zu erhalten.

Nächste Schritte

• Kapazitäten und Kontingente verwalten (nächstes Dokument in dieser Reihe)
• Entdecken Sie weitere Kategorien im Architektur-Framework, z. B. Systemdesign, Sicherheit, Datenschutz und Compliance, Zuverlässigkeit, Kostenoptimierung und Leistungsoptimierung.

Kapazitäten und Kontingente verwalten

Dieses Dokument im Google Cloud Architecture Framework zeigt Ihnen, wie Sie Ihre Kapazität und Ihr Kontingent in der Cloud bewerten und planen können.

In herkömmlichen Rechenzentren müssen Sie in der Regel mehrmals pro Quartal den aktuellen Ressourcenbedarf prüfen und den bevorstehenden Bedarf schätzen. Sie müssen physische, logistische und personelle Aspekte berücksichtigen. Elemente wie Rackfläche, Kühlung, Stromversorgung, Bandbreite, Verkabelung, Beschaffungszeiten, Lieferzeiten und die Anzahl der zur Arbeit mit neuer Ausrüstung verfügbaren Ingenieure sind zu berücksichtigen. Sie müssen weiter die Verteilung von Kapazitäten und Arbeitslasten aktiv verwalten, damit ressourcenintensive Jobs, darunter Hadoop-Pipelines, nicht Dienste wie Webserver beeinträchtigen, die hochverfügbar sein müssen.

Im Gegensatz dazu übergeben Sie bei der Nutzung von Google Cloud die meisten Kapazitätsplanungen an Google. Wenn Sie die Cloud nutzen, müssen Sie inaktive Ressourcen nicht bereitstellen und verwalten, wenn diese nicht benötigt werden. Beispiel: Sie können VM-Instanzen nach Bedarf erstellen oder hoch- und herunterskalieren. Da Sie nur für die tatsächliche Nutzung zahlen, können Sie Ihre Ausgaben optimieren, einschließlich überschüssiger Kapazität, die Sie nur zu Spitzenzeiten benötigen. Um Sie bei Ihren Einsparungen zu unterstützen, stellt Compute Engine Empfehlungen für Maschinentypen bereit, sobald nicht ausgelastete VM-Instanzen erfasst werden, deren Größe angepasst oder die gelöscht werden können.

Cloud-Kapazitätsanforderungen bewerten

Um Ihre Kapazitäten effizient verwalten zu können, müssen Sie die Kapazitätsanforderungen Ihrer Organisation kennen.

Um Ihre Kapazitätsanforderungen zu bewerten, ermitteln Sie zuerst Ihre wichtigsten Cloud-Arbeitslasten. Bestimmen Sie die durchschnittliche und maximale Auslastung dieser Arbeitslasten sowie deren aktuellen und zukünftigen Kapazitätsanforderungen.

Identifizieren Sie die Teams, die diese Top-Arbeitslasten verwenden. Arbeiten Sie mit ihnen zusammen, um einen internen Bedarfsplanungsprozess einzurichten. Verwenden Sie diesen Prozess, um seine aktuellen und prognostizierten Cloud-Ressourcenanforderungen zu verstehen.

Analysieren Sie Lademuster und Aufrufverteilung. Nutzen Sie in Ihrer Analyse Faktoren wie den Spitzenwert der letzten 30 Tage, den stündlichen Spitzenwert und den Spitzenwert pro Minute.

Sie können Cloud Monitoring nutzen, um Einblicke in die Leistung, die Verfügbarkeit und den Gesamtzustand von Anwendungen und Infrastruktur zu erhalten.

Messwerte zur Infrastrukturauslastung ansehen

Erfassen und speichern Sie Verlaufsdaten zur Nutzung von Cloud-Ressourcen in Ihrer Organisation, um die Kapazitätsplanung zu vereinfachen.

Verschaffen Sie sich einen Überblick über Messwerte zur Infrastrukturauslastung. Prüfen Sie für wichtige Arbeitslasten beispielsweise:

• Durchschnittliche und maximale Auslastung
• Spitzen bei Nutzungsmustern
• Saisonale Spitzen basierend auf Geschäftsanforderungen, z. B. an Feiertagen (für Einzelhändler)
• Wie viel Überdimensionierung ist erforderlich, um auf Spitzenereignisse vorzubereitet zu sein und potenzielle Trafficspitzen schnell ansprechen zu können

Achten Sie darauf, dass Ihre Organisation Warnungen eingerichtet hat, die Sie automatisch benachrichtigen, sobald Kontingent- und Kapazitätslimits erreicht sind.

Mit den Monitoring-Tools von Google erhalten Sie Informationen zur Anwendungsnutzung und -kapazität. Beispielsweise können Sie mit Monitoring benutzerdefinierte Messwerte definieren. Verwenden Sie diese benutzerdefinierten Messwerte, um Benachrichtigungstrends zu definieren. Monitoring bietet außerdem flexible Dashboards und umfangreiche Visualisierungstools, mit denen sich potenzielle Probleme rechtzeitig erkennen lassen.

Prozess für die Kapazitätsplanung erstellen

Legen Sie einen Prozess für die Kapazitätsplanung fest und dokumentieren Sie diesen Plan.

Gehen Sie beim Erstellen des Plans so vor:

1. Führen Sie Lasttests durch, um festzustellen, wie viel Last das System unter Einhaltung der Latenzvorgaben bei einer festen Anzahl von Ressourcen bewältigen kann. Lasttests sollten eine Mischung aus Anfragetypen verwenden, die mit Produktions-Traffic-Profilen von Livenutzern übereinstimmen. Verwenden Sie keine einheitliche oder zufällige Mischung von Vorgängen. Beziehen Sie Nutzungsspitzen in Ihr Traffic-Profil ein.
2. Erstellen Sie ein Kapazitätsmodell. Ein Kapazitätsmodell ist eine Reihe von Formeln zur Berechnung der zusätzlichen Ressourcen, die pro Einheitsanstieg der Dienstlast erforderlich sind, wie sie bei Lasttests ermittelt wurden.
3. Prognostizieren Sie den zukünftigen Traffic und berücksichtigen Sie dabei eventuelles Wachstum. Eine Beschreibung der Erstellung von Trafficprognosen durch Google finden Sie im Artikel Messung der zukünftigen Last.
4. Wenden Sie das Kapazitätsmodell auf die Prognose an, um den zukünftigen Ressourcenbedarf zu ermitteln.
5. Schätzen Sie die Kosten für Ressourcen, die Ihre Organisation benötigt. Lassen Sie sich dann von Ihrer Finanzorganisation eine Budgetgenehmigung erteilen. Dieser Schritt ist wichtig, da das Unternehmen bei einer Reihe von Produkten einen Kompromiss zwischen Kosten und Risiko eingehen kann. Diese Kompromisse können dazu führen, dass aufgrund von geschäftlichen Prioritäten Kapazitäten erworben werden, die niedriger oder höher sind als der vorhergesagte Bedarf für ein bestimmtes Produkt.
6. Wenden Sie sich an Ihren Cloud-Anbieter, um die erforderliche Anzahl an Ressourcen zur richtigen Zeit über Kontingente und Reservierungen zu erhalten. Beziehen Sie Infrastrukturteams in die Kapazitätsplanung ein und lassen Sie Betriebsabläufe mit Konfidenzintervallen erstellen.
7. Wiederholen Sie die vorherigen Schritte alle ein bis zwei Quartale.

Eine ausführlichere Anleitung zur Kapazitätsplanung bei gleichzeitiger Optimierung der Ressourcennutzung finden Sie unter Kapazitätsplanung.

Kontingente an Ihre Kapazitätsanforderungen anpassen

Google Cloud verwendet Kontingente, um den Umfang einer bestimmten freigegebenen Google Cloud-Ressource einzuschränken. Jedes Kontingent stellt eine bestimmte zählbare Ressource dar, z. B. API-Aufrufe an einen bestimmten Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load-Balancer oder die Anzahl der Projekte, die Sie erstellen können. Mit Kontingenten wird zum Beispiel verhindert, dass wenige Kunden oder Projekte CPU-Kerne in einer bestimmten Region oder Zone monopolisieren.

Beachten Sie beim Prüfen Ihres Kontingents folgende Details:

• Sie sollten die Kapazitätsanforderungen Ihrer Projekte im Voraus planen, um unerwartete Einschränkungen bei der Ressourcennutzung zu vermeiden.
• Legen Sie Ihr Kontingent und Ihre Kapazität so fest, dass ein Ausfall der gesamten Region abgefangen werden kann.
• Verwenden Sie Kontingente, um die Nutzung einer bestimmten Ressource zu begrenzen. Sie können zum Beispiel ein Kontingent für die maximale Abfragenutzung pro Tag über die BigQuery API festlegen, damit ein Projekt nicht zu viel für BigQuery ausgibt.
• Planen Sie Nutzungsspitzen und berücksichtigen Sie diese bei der Kontingentplanung. Spitzen bei der Nutzung können durch tägliche Schwankungen, unerwartete Traffic-Spitzen oder bekannte Spitzenlasten und Startereignisse geschätzt werden. Weitere Informationen zur Planung von Traffic-Spitzen und Startereignissen finden Sie im nächsten Abschnitt von Operative Exzellenz: Planen Sie Traffic-Spitzen und Startereignisse.

Wenn Ihre aktuellen Kontingente nicht ausreichen, können Sie Kontingente über die Google Cloud Console verwalten. Sollten Sie eine sehr große Kapazität benötigen, wenden Sie sich an Ihr Google Cloud-Vertriebsteam. Beachten Sie, dass viele Dienste Limits haben, die nicht mit dem Kontingentsystem in Zusammenhang stehen. Weitere Informationen finden Sie unter Mit Kontingenten arbeiten.

Prüfen Sie regelmäßig Ihre Kontingente. Senden Sie Kontingentanfragen, bevor sie benötigt werden. Weitere Informationen dazu, wie Kontingentanfragen evaluiert und wie Anfragen genehmigt oder abgelehnt werden, finden Sie unter Mit Kontingenten arbeiten.

Es gibt mehrere Möglichkeiten, Ihr Google Cloud-Kontingent aufzurufen und zu verwalten:

• Google Cloud Console verwenden
• Google Cloud CLI verwenden
• Mit der Service Usage API
• Angebotsmesswerte mit Monitoring ansehen
• Erwägen Sie die Implementierung der Dashboard-Lösung zur Kontingentüberwachung, um Kontingente für mehrere Google Cloud-Projekte innerhalb einer Organisation oder eines Ordners zu verwalten.

Nächste Schritte

• Planung von Traffic-Spitzen und Startereignisse (nächstes Dokument in dieser Reihe).
• Entdecken Sie weitere Kategorien im Architektur-Framework, z. B. Systemdesign, Sicherheit, Datenschutz und Compliance, Zuverlässigkeit, Kostenoptimierung und Leistungsoptimierung.

Planen Sie Traffic-Spitzen und Startereignisse

In diesem Dokument im Google Cloud-Architektur-Framework erfahren Sie, wie Sie Traffic-Spitzen und Startereignisse in Ihre Planung einbeziehen, um Unterbrechungen Ihres Geschäftsangebots zu vermeiden.

Spitzen-Events sind wichtige geschäftsbezogene Ereignisse, die einen starken Anstieg des Traffics über die Standardwerte der Anwendung hinaus bedingen. Für diese Spitzen-Events ist eine geplante Skalierung erforderlich.

So können Einzelhändler, die online präsent sind, beispielsweise an Feiertagen Spitzenereignisse erwarten. Black Friday, ein Tag nach Thanksgiving in den USA, ist einer der geschäftigsten Tage des Jahres. Für die Gesundheitsbranche in den USA können in den Monaten Oktober und November die Spitzenereignisse aufgrund von Spitzen beim Online-Traffic für die Anmeldung von Vorteilen auftreten.

Startereignisse sind alle größeren Rollouts oder Migrationen neuer Funktionen in der Produktion. Beispiel: Eine Migration von der lokalen Umgebung zur Cloud oder die Einführung eines neuen Produktdienstes oder -Features.

Wenn Sie ein neues Produkt einführen, sollten Sie während der Bekanntgabe und möglicherweise danach eine stärkere Auslastung Ihrer Systeme erwarten. Diese Ereignisse bedingen häufig eine Erhöhung der Last um das 5- bis 20-Fache (oder höher) auf Frontend-Systemen. Durch diese erhöhte Last wird auch die Last auf Backend-Systemen erhöht. Häufig sind diese Frontend- und Backend-Lasten durch eine schnelle Skalierung über eine kurze Zeit gekennzeichnet, während das Event für Web-Traffic freigegeben wird. Nach Einführungen sinkt der Traffic langsam auf normale Werte ab. Die Abnahme verläuft in der Regel langsamer als der Anstieg auf den Spitzenwert.

Spitzen- und Einführungs-Events umfassen drei Phasen:

• Planung und Vorbereitung für das Einführungs- oder Spitzen-Event
• Event starten
• Ereignisleistung und nachträgliche Ereignisanalyse überprüfen

Die in diesem Dokument beschriebenen Praktiken können dazu beitragen, dass jede dieser Phasen reibungslos abläuft.

Allgemeines Playbook für Einführungen und Spitzenereignisse erstellen

Erstellen Sie ein allgemeines Playbook mit einer langfristigen Ansicht der aktuellen und zukünftigen Spitzen-Events. Erweitern Sie das Dokument, damit es als Referenz für zukünftige Spitzen-Events dienen kann.

Bereiten Sie sich auf Ihre Einführungs- und Spitzen-Events vor

Planen Sie vor. Erstellen Sie Geschäftsprognosen für zukünftige Markteinführungen und für erwartete (und unerwartete) Spitzen-Events. Wie Sie Ihr System auf Skalierungsspitzen vorbereiten, hängt von Ihren Geschäftsprognosen ab. Je mehr über frühere Prognosen bekannt ist, desto genauer können Sie neue Geschäftsprognosen erstellen. Diese neuen Prognosen lassen wichtige Rückschlüsse darüber zu, welche Systemlast zu erwarten ist.

Die Einrichtung von Programmmanagement und koordinierter Planung – organisationsübergreifend und mit Drittanbietern – ist ebenfalls ein Schlüssel zum Erfolg. Richten Sie die Teams frühzeitig ein, damit Ihr Programmverwaltungsteam Zeitpläne festlegen, Budgets sichern und Ressourcen für zusätzliche Infrastruktur, Tests und Schulungen aufbauen kann.

Es ist wichtig, klare Kommunikationskanäle einzurichten. Gute Kommunikation ist in allen Phasen der Einführung oder eines Spitzenereignisses von entscheidender Bedeutung. Besprechen Sie Risiken und Bereiche frühzeitig und lassen Sie Probleme gemeinschaftlich durch die Teams bearbeiten, bevor sie zu unüberwindbaren Hindernissen werden. Erstellen Sie eine Dokumentation zur Ereignisplanung. Fassen Sie die wichtigsten Informationen zu dem Spitzenereignis zusammen und verteilen Sie sie. Auf diese Weise können Mitarbeiter Planungsinformationen aufnehmen und grundlegende Fragen lösen. Neue Mitarbeiter können damit auf den aktuellen Planungsstand gebracht werden.

Dokumentieren Sie Ihren Plan für jedes Ereignis. Achten Sie beim Dokumentieren Ihres Plans auf Folgendes:

• Identifizieren Sie Annahmen, Risiken und unbekannte Faktoren.
• Prüfen Sie frühere Ereignisse, um relevante Informationen für den bevorstehenden Start oder das Spitzenereignis zu ermitteln. Ermitteln Sie, welche Daten verfügbar sind und welche Aussagekraft sie in der Vergangenheit hatten.
• Detaillieren Sie den Rollback-Plan für Start- und Migrationsereignisse.
• Führen Sie eine Architekturüberprüfung durch:
  • Dokumentieren Sie Schlüsselressourcen und Architekturkomponenten.
  • Verwenden Sie das Architektur-Framework um alle Aspekte der Umgebung auf Risiken und Skalierungsaspekte zu prüfen.
  • Erstellen Sie ein Diagramm, das zeigt, wie die Hauptkomponenten der Architektur verbunden sind. Eine Prüfung des Diagramms kann Ihnen dabei helfen, Probleme zu isolieren und ihre Lösung zu beschleunigen.
• Konfigurieren Sie gegebenenfalls den Service so, dass Benachrichtigungen zu einem automatischen Neustart führen, wenn ein Fehler auftritt. Verwenden Sie bei Nutzung von Compute Engine für die Verarbeitung von Durchsatzspitzen das Autoscaling.
• Verwenden Sie Reservierungen, damit Compute Engine-Ressourcen verfügbar sind, wenn Sie sie benötigen. Reservierungen bieten ein sehr hohes Maß an Sicherheit beim Beschaffen von Kapazitäten für zonale Ressourcen von Compute Engine. Mit Reservierungen können Sie dafür sorgen, dass in Ihrem Projekt Ressourcen verfügbar sind.
• Identifizieren Sie Messwerte und Benachrichtigungen, die verfolgt werden sollen:
  • Identifizieren Sie Geschäfts- und Systemmesswerte, die auf das Ereignis überwacht werden sollen. Wenn keine Messwerte oder Service Level Indicators (SLIs) erfasst werden, ändern Sie das System so, dass diese Daten erfasst werden.
  • Achten Sie auf ausreichende Monitoring- und Benachrichtigungsfunktionen und prüfen Sie die normalen und vorherigen Traffic-Muster. Prüfen Sie, ob die Benachrichtigungen entsprechend festgelegt sind. Mit Google Cloud Monitoring-Tools können Sie Anwendungsnutzung, -kapazität und den Gesamtzustand von Anwendungen und Infrastruktur einsehen.
  • Erfassen Sie Systemmesswerte mit Monitoring- und Benachrichtigungsebenen, die von Interesse sind.
• Prüfen Sie mit Ihrem Google Cloud-Kontoteam die erhöhten Kapazitätsanforderungen und planen Sie die erforderliche Kontingentverwaltung. Weitere Informationen finden Sie unter Prüfen, ob Ihre Kontingente Ihren Kapazitätsanforderungen entsprechen.
• Sorgen Sie dafür, dass Sie geeignete Cloud-Supportstufen haben, und Ihr Team versteht, wie Supportfälle geöffnet werden. Außerdem muss ein Eskalationspfad eingerichtet sein. Weitere Informationen finden Sie unter Cloud-Support- und Eskalationsprozesse einrichten.
• Definieren Sie einen Kommunikationsplan, einen Zeitplan und Verantwortlichkeiten:
  • Binden Sie funktionsübergreifende Stakeholder ein, um die Kommunikation und Programmplanung zu koordinieren. Zu diesen Beteiligten können geeignete Personen aus technischen, operativen und Führungsteams sowie Drittanbietern gehören.
  • Legen Sie einen eindeutigen Zeitplan fest, der wichtige Aufgaben und die jeweils besitzenden Teams enthält.
  • Richten Sie eine RACI-Matrix (Verantwortlichkeitszuweisung) ein, um die Inhaberschaft für Teams, Teamleiter, Beteiligte und Verantwortliche zu kommunizieren.
  • Für geplante Spitzenereignisse können Sie den Event Management Service des Premium-Supports nutzen. Bei diesem Dienst arbeiten Customer Care-Partner mit Ihrem Team zusammen, um einen Plan zu erstellen und Sie während des Ereignisses zu begleiten.

Überprüfungsverfahren festlegen

Wenn das Spitzenereignis für den Traffic oder das Startereignis beendet ist, prüfen Sie das Ereignis, um die gewonnenen Erkenntnisse zu dokumentieren. Aktualisieren Sie dann Ihr Playbook mit diesen Lektionen. Wenden Sie schließlich das Gelernte auf das nächste Hauptereignis an. Das Lernen von früheren Ereignissen ist wichtig, insbesondere wenn sie unter Stress Beschränkungen für das System hervorheben.

Rückblickende Überprüfungen, auch Postmortems genannt, sind bei Trafficspitzen oder Startereignissen ein hilfreiches Verfahren zum Erfassen von Daten und zum Verständnis der aufgetretenen Vorfälle. Prüfen Sie diese Überprüfung auf Spitzenzugriffs- und Einführungsereignisse, die wie erwartet erfolgt sind, und auf Vorfälle, die Probleme verursacht haben. Unterstützen Sie bei dieser Prüfung eine Kultur ohne Schuldzuweisung.

Weitere Informationen zu Postmortems finden Sie unter Postmortem-Kultur: Aus Fehlern lernen.

Nächste Schritte

• Erstellen Sie eine Automatisierungskultur (nächstes Dokument in dieser Reihe)
• Entdecken Sie weitere Kategorien im Architektur-Framework, z. B. Systemdesign, Sicherheit, Datenschutz und Compliance, Zuverlässigkeit, Kostenoptimierung und Leistungsoptimierung.

Unternehmenskultur der Automatisierung schaffen

In diesem Dokument des Google Cloud-Architektur-Frameworks erfahren Sie, wie Sie zusätzlichen Aufwand bewerten und die Auswirkungen auf Ihre Systeme und Teams reduzieren können.

Als Aufwand werden manuelle und sich wiederholende Arbeiten ohne bleibenden Wert bezeichnet, die zunehmen, je umfangreicher ein Dienst wird. Versuchen Sie kontinuierlich, den Arbeitsaufwand zu reduzieren oder zu vermeiden. Andernfalls kann die operative Arbeit die Operatoren überfordern und jeder Anstieg der Produktnutzung oder der Komplexität erfordert möglicherweise zusätzliches Personal.

Automatisierung ist eine wichtige Möglichkeit, den Arbeitsaufwand zu minimieren. Automatisierung verbessert außerdem die Releasegeschwindigkeit und hilft, durch Menschen verursachte Fehler zu minimieren.

Weitere Informationen finden Sie unter Arbeitsaufwand vermeiden.

Inventar erstellen und Kosten für Arbeitsaufwand bewerten

Erstellen Sie zuerst ein Inventar und bewerten Sie die Kosten des Teams, das Ihre Systeme verwaltet. Gestalten Sie diesen Prozess kontinuierlich und investieren Sie in eine benutzerdefinierte Automatisierung, um die bereits von Google Cloud-Diensten und -Partnern bereitgestellten Dienste zu erweitern. Häufig können Sie die eigene Automatisierung von Google Cloud ändern, z. B. Autoscaling von Compute Engine.

Beseitigung von Arbeitsaufwand priorisieren

Automatisierung ist zwar nützlich, aber nicht eine Lösung für alle operativen Probleme. Als ersten Schritt zur Handhabung bekannter Arbeit sollten Sie das Inventar der vorhandenen Arbeit prüfen und Prioritäten für die Beseitigung von möglichst viel Aufwand setzen. Anschließend können Sie sich auf die Automatisierung konzentrieren.

Erforderliche Arbeit automatisieren

Ein Teil der Arbeit in Ihren Systemen kann nicht beseitigt werden. Automatisieren Sie in einem zweiten Schritt den Arbeitsaufwand durch Lösungen, die Google Cloud durch konfigurierbare Automatisierung bereitstellt.

In den folgenden Bereichen können die konfigurierbare Automatisierung oder die benutzerdefinierte Automatisierung helfen, den Arbeitsaufwand Ihrer Organisation zu verringern:

• Identitätsverwaltung, z. B. Cloud Identity und Identity and Access Management
• Von Google Cloud gehostete Lösungen anstelle von selbst erstellten Lösungen wie Clusterverwaltung (Google Kubernetes Engine (GKE)), relationale Datenbankverwaltung (Cloud SQL), Data-Warehouse-Verwaltung (BigQuery) und API-Verwaltung (Apigee)
• Google Cloud-Dienste und Mandantenbereitstellung, z. B. Terraform und Cloud Foundation Toolkit
• Automatisierte Workflow-Orchestrierung für mehrstufige Vorgänge, z. B. Cloud Composer
• Zusätzliche Kapazitätsbereitstellung – so bieten beispielsweise mehrere Google Cloud-Produkte wie Compute Engine und GKE ein konfigurierbares Autoscaling Prüfen Sie, welche Google Cloud-Dienste Sie verwenden, um festzustellen, ob sie konfigurierbares Autoscaling enthalten.
• CI/CD-Pipelines mit automatischer Bereitstellung, z. B. CIoud Build
• Canary-Analyse zur Validierung von Bereitstellungen
• Automatisiertes Modelltraining (für maschinelles Lernen), z. B. AutoML

Wenn ein Google Cloud-Produkt oder -Dienst Ihre technischen Anforderungen beim Automatisieren oder Beseitigen manueller Workflows nur teilweise erfüllt, können Sie eine Funktionsanfrage über Ihren Google Cloud-Kundenbetreuer stellen. Ihr Problem kann auch für andere Kunden Priorität haben oder bereits Teil unserer Planung sein. Wenn dies der Fall ist, können Sie durch Informationen zur Priorität und zum Zeitplan des Features besser abwägen, ob Sie Ihre eigene Lösung erstellen oder warten möchten, bis Sie sie als Google Cloud-Feature nutzen können.

Lösungen für kostenintensiven Aufwand entwickeln oder kaufen

Der dritte Schritt, der parallel zum ersten und zweiten Schritt ausgeführt werden kann, besteht darin, andere Lösungen zu entwickeln oder zu kaufen, wenn Ihr Arbeitsaufwand hoch bleibt, z. B. wenn der Arbeitsaufwand für jedes Team, das Ihre Produktionssysteme verwaltet, sehr viel Zeit in Anspruch nimmt.

Berücksichtigen Sie beim Erstellen oder Kaufen von Lösungen die Kosten für Integration, Sicherheit, Datenschutz und Compliance. Das Entwerfen und Implementieren einer eigenen Automatisierung führt zu Wartungskosten und Risiken, die über die anfänglichen Entwicklungs- und Einrichtungskosten hinausgehen. Ziehen Sie diese Option daher als letztes Mittel in Betracht.

Nächste Schritte

Entdecken Sie weitere Kategorien im Architektur-Framework, z. B. Systemdesign, Sicherheit, Datenschutz und Compliance, Zuverlässigkeit, Kostenoptimierung und Leistungsoptimierung.

Google Cloud-Architektur-Framework: Sicherheit, Datenschutz und Compliance

In diesem Abschnitt des Google Cloud-Architektur-Frameworks erfahren Sie, wie Sie sichere Dienste in Google Cloud entwerfen und betreiben. Außerdem erfahren Sie mehr über Produkte und Funktionen von Google Cloud, die Sicherheit und Compliance unterstützen.

Im Architektur-Framework werden Best Practices beschrieben, Implementierungsempfehlungen gegeben und einige verfügbare Produkte und Dienste erläutert. Mit dem Framework können Sie Ihre Google Cloud-Bereitstellung so gestalten, dass sie Ihren geschäftlichen Anforderungen entspricht.

Das Verschieben Ihrer Arbeitslasten in Google Cloud erfordert eine Bewertung Ihrer Geschäftsanforderungen, Risiken, Complianceverpflichtungen und Sicherheitskontrollen. In diesem Dokument werden wichtige Best Practices zum Entwerfen einer sicheren Lösung in Google Cloud erläutert.

Zu den Grundprinzipien von Google gehört die standardmäßige Verteidigung in der Tiefe und in der Breite. In Google Cloud werden Daten und Systeme durch mehrschichtige Verteidigungsmaßnahmen geschützt, wobei Richtlinien und Kontrollen verwendet werden, die für IAM, Verschlüsselung, Netzwerke, Erkennung, Logging und Monitoring konfiguriert werden.

Google Cloud bietet zahlreiche Sicherheitskontrollen, auf denen Sie aufbauen können, darunter:

• Sichere Optionen für Daten bei der Übertragung und die Standardverschlüsselung inaktiver Daten.
• Integrierte Sicherheitsfeatures für Google Cloud-Produkte und -Dienste.
• Eine globale Infrastruktur, die auf Georedundanz ausgelegt ist, mit Sicherheitskontrollen im gesamten Lebenszyklus der Informationsverarbeitung.
• Automatisierungsfunktionen, die Infrastruktur als Code (IaC) und Konfigurationsleitplanken verwenden.

Weitere Informationen zum Sicherheitsstatus von Google Cloud finden Sie im Google-Sicherheitsdokument und in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google. Ein Beispiel für eine standardmäßig sichere Umgebung finden Sie im Blueprint: Google Cloud-Unternehmensgrundlagen.

Im Abschnitt „Sicherheit“ des Architektur-Frameworks erhalten Sie weitere Informationen über:

• Geteilte Verantwortung und Fate-Sharing in Google Cloud ansehen
• Sicherheitsgrundsätze
• Risiken mit Kontrollen verwalten
• Inhalte verwalten
• Identität und Zugriff verwalten
• Computing- und Containersicherheit implementieren
• Netzwerk sichern
• Datensicherheit implementieren
• Anwendungssicherheit bereitstellen
• Gesetzliche Verpflichtungen verwalten
• Anforderungen an den Datenstandort und die Datenhoheit umsetzen
• Datenschutzanforderungen implementieren
• Logging- und Erkennungskontrollen implementieren

Geteilte Verantwortung und Fate-Sharing in Google Cloud

In diesem Dokument werden die Unterschiede zwischen dem Modell der geteilten Verantwortung und dem Fate-Sharing in Google Cloud beschrieben. Darin werden die Herausforderungen und Nuancen des Modells der geteilten Verantwortung erläutert. In diesem Dokument wird beschrieben, was Fate-Sharing ist und wie wir gemeinsam mit unseren Kunden an der Herausforderung der Cloud-Sicherheit arbeiten.

Das Modell der geteilten Verantwortung ist wichtig, um zu bestimmen, wie Sie Ihre Daten und Arbeitslasten in Google Cloud am besten schützen. Das Modell der geteilten Verantwortung beschreibt die Aufgaben, die Sie in puncto Sicherheit in der Cloud haben, und wie sich diese Aufgaben für Cloudanbieter unterscheiden.

Es ist jedoch nicht immer einfach, die geteilte Verantwortung zu verstehen. Das Modell erfordert ein umfassendes Verständnis jedes von Ihnen verwendeten Dienstes, die Konfigurationsoptionen, die jeder Dienst bereitstellt, und die Maßnahmen, die Google Cloud zum Schutz des Dienstes unternimmt. Jeder Dienst hat ein anderes Konfigurationsprofil und es kann schwierig sein, die beste Sicherheitskonfiguration zu ermitteln. Google ist der Meinung, dass das Modell der geteilten Verantwortung nicht hilft, Cloud-Kunden dabei zu unterstützen, bessere Sicherheitsergebnisse zu erzielen. Anstelle von geteilter Verantwortung setzen wir auf Fate-Sharing.

Fate-Sharing umfasst das Erstellen und Betreiben einer vertrauenswürdigen Cloud-Plattform für Ihre Arbeitslasten. Wir bieten Best Practice-Anleitungen und sicheren, bestätigten Infrastrukturcode, mit dem Sie Ihre Arbeitslasten sicher bereitstellen können. Wir veröffentlichen Lösungen, die verschiedene Google Cloud-Dienste kombinieren, um komplexe Sicherheitsprobleme zu beheben. Darüber hinaus bieten wir innovative Versicherungsoptionen, mit denen Sie die zu akzeptierenden Risiken messen und minimieren können. Fate-Sharing erfordert eine engere Interaktion mit Ihnen, wenn Sie Ihre Ressourcen in Google Cloud schützen.

Geteilte Verantwortung

Sie sind der Experte für die Sicherheits- und behördlichen Anforderungen an Ihr Unternehmen und für die Anforderungen zum Schutz vertraulicher Daten und Ressourcen. Wenn Sie Ihre Arbeitslasten in Google Cloud ausführen, müssen Sie die Sicherheitskontrollen ermitteln, die Sie in Google Cloud konfigurieren müssen, um Ihre vertraulichen Daten und jede Arbeitslast zu schützen. Um zu entscheiden, welche Sicherheitskontrollen implementiert werden sollen, müssen Sie die folgenden Faktoren berücksichtigen:

• Die für Sie geltenden gesetzlichen Vorschriften
• Sicherheitsstandards und Risikomanagementplan Ihrer Organisation
• Sicherheitsanforderungen Ihrer Kunden und Anbieter

Durch Arbeitslasten definiert

Üblicherweise werden Verantwortlichkeiten basierend auf der Art der ausgeführten Arbeitslast und den erforderlichen Cloud-Diensten definiert. Cloud-Dienste umfassen die folgenden Kategorien:

Clouddienst	Beschreibung
Infrastructure as a Service (IaaS)	Zu den IaaS-Diensten gehören Compute Engine, Cloud Storage sowie Netzwerkdienste wie Cloud VPN, Cloud-Load-Balancing undCloud DNS. IaaS bietet Computing-, Speicher- und Netzwerkdienste on demand mit „Pay as you go“-Preise. Sie können IaaS verwenden, wenn Sie eine vorhandene lokale Arbeitslast mithilfe von Lift-and-Shift zur Cloud migrieren möchten oder wenn Sie Ihre Anwendung auf bestimmten VMs mit bestimmten Datenbanken oder Netzwerkkonfigurationen ausführen möchten. Bei IaaS liegt der Großteil der Sicherheitsaufgaben bei Ihnen und unsere Verantwortlichkeiten konzentrieren sich auf die zugrunde liegende Infrastruktur und physische Sicherheit.
Platform as a service (PaaS)	Zu den PaaS-Diensten gehören App Engine, Google Kubernetes Engine (GKE) und BigQuery. PaaS bietet die Laufzeitumgebung, in der Sie Anwendungen entwickeln und ausführen können. Sie können PaaS verwenden, wenn Sie eine Anwendung erstellen (z. B. eine Website) und sich auf die Entwicklung statt auf die zugrunde liegende Infrastruktur konzentrieren möchten. Bei PaaS sind wir für mehr Kontrolle als bei IaaS verantwortlich, einschließlich der Netzwerksteuerung. Sie übernehmen die Verantwortung für Kontrollen auf Anwendungsebene und für die IAM-Verwaltung. Sie sind für die Datensicherheit und den Clientschutz verantwortlich.
Software as a Service (SaaS)	SaaS-Anwendungen umfassen Google Workspace, Chronicle und SaaS-Anwendungen von Drittanbietern im Google Cloud Marketplace. SaaS stellt Onlineanwendungen bereit, die Sie abonnieren oder bezahlen können. Sie können SaaS-Anwendungen verwenden, wenn Ihr Unternehmen nicht die internen Fachkenntnisse oder die Geschäftsanforderungen zum Erstellen der Anwendung hat, aber die Möglichkeit erfordert, Arbeitslasten zu verarbeiten. Bei SaaS sind wir für den Großteil der Sicherheitsaufgaben zuständig. Sie sind weiterhin für Ihre Zugriffssteuerung und die Daten verantwortlich, die Sie in der Anwendung speichern.
FaaS (Function as a Service) oder serverlos	FaaS bietet Entwicklern eine Plattform für die Ausführung kleiner Codefunktionen (Funktionen), die als Reaktion auf bestimmte Ereignisse ausgeführt werden. Sie verwenden FaaS, wenn Sie bestimmte Funktionen basierend auf einem bestimmten Ereignis ausführen möchten. Sie können beispielsweise eine Funktion erstellen, die bei jedem Hochladen von Daten in Cloud Storage ausgeführt wird, damit die Daten klassifiziert werden können. FaaS hat eine ähnliche Liste geteilter Verantwortung wie SaaS. Cloud Functions ist eine FaaS-Anwendung.

Das folgende Diagramm zeigt die Clouddienste und definiert, wie die Zuständigkeiten zwischen dem Cloudanbieter und dem Kunden geteilt werden.

Wie das Diagramm zeigt, bleibt der Cloud-Anbieter immer für das zugrunde liegende Netzwerk und die zugrunde liegende Infrastruktur verantwortlich und die Kunden sind immer für ihre Zugriffsrichtlinien und Daten verantwortlich.

Nach Branchen- und behördlichen Rahmenbedingungen definiert

Verschiedene Branchen haben rechtliche Rahmenbedingungen, die die Sicherheitskontrollen definieren, die vorhanden sein müssen. Wenn Sie Ihre Arbeitslasten in die Cloud verschieben, müssen Sie Folgendes verstehen:

• Welche Sicherheitskontrollen liegen in Ihrer Verantwortung
• Welche Sicherheitskontrollen sind im Rahmen des Cloud-Angebots verfügbar
• Welche Standard-Sicherheitskontrollen werden übernommen

Übernommene Sicherheitskontrollen (z. B. unsere Standardverschlüsselung und Infrastrukturkontrollen) sind Steuerelemente, die Sie als Teil der Beweisführung zu Ihrem Sicherheitsstatus bei Prüfern und Aufsichtsbehörden bereitstellen können. Zum Beispiel definiert der Datensicherheitsstandard der Zahlungskartenindustrie (Payment Card Industry Data Security Standard, PCI DSS) Vorschriften für Zahlungsabwickler. Wenn Sie Ihr Unternehmen in die Cloud verschieben, werden diese Vorschriften zwischen Ihnen und Ihrem CSP aufgeteilt. Informationen dazu, wie die Verantwortlichkeiten aus dem PCI DSS zwischen Ihnen und Google Cloud geteilt werden, finden Sie unter: Google Cloud: Matrix der geteilten Verantwortung (PCI-DSS) .

Ein weiteres Beispiel in den USA ist der Health Insurance Portability and Accountability Act (HIPAA), der Standards zur Verarbeitung elektronischer Gesundheitsdaten (Personal Health Information, PHI) festlegt. Diese Verantwortlichkeiten werden auch zwischen dem CSP und Ihnen aufgeteilt. Weitere Informationen dazu, wie Google Cloud unsere Verpflichtungen gemäß HIPAA erfüllt, finden Sie unter HIPAA-Compliance.

Andere Branchen (z. B. Finanzen oder Fertigung) haben auch Vorschriften, die festlegen, wie Daten erfasst, verarbeitet und gespeichert werden können. Weitere Informationen zu diesen Aufgaben und dazu, wie Google Cloud unsere Verpflichtungen erfüllt, finden Sie im Center für Compliance-Ressourcen.

Nach Standort definiert

Abhängig von Ihrem Geschäftsszenario müssen Sie möglicherweise Ihre Verantwortlichkeiten anhand des Standorts Ihrer Geschäftsstellen, Ihrer Kunden und Ihrer Daten berücksichtigen. In verschiedenen Ländern und Regionen gibt es Bestimmungen, mit denen festgelegt wird, wie Sie die Daten Ihrer Kunden verarbeiten und speichern können. Wenn Ihr Unternehmen beispielsweise Kunden hat, die in der Europäischen Union wohnen, muss Ihr Unternehmen möglicherweise die Anforderungen der Datenschutz-Grundverordnung (DSGVO) erfüllen und Sie sind möglicherweise verpflichtet, Ihre Kundendaten in der EU selbst aufzubewahren. In diesem Fall sind Sie dafür verantwortlich, dass die erfassten Daten in den Google Cloud-Regionen in der EU verbleiben. Weitere Informationen dazu, wie wir unsere Verpflichtungen nach der DSGVO erfüllen, finden Sie unter DSGVO und Google Cloud.

Informationen zu den Anforderungen in Ihrer Region finden Sie unter Compliance-Angebote. Wenn Ihr Szenario besonders kompliziert ist, empfehlen wir Ihnen, sich an unser Vertriebsteam oder einen unserer Partner zu wenden, um die Evaluierung Ihrer Sicherheitsaufgaben vorzunehmen.

Herausforderungen für die gemeinsame Verantwortung

Obwohl die gemeinsame Verantwortung die Definition der Sicherheitsrollen ermöglicht, die Sie oder der Cloudanbieter haben, kann die gemeinsame Verantwortung weiterhin Herausforderungen schaffen. Sehen Sie sich die folgenden Szenarien an:

• Die meisten Verstöße gegen die Cloud-Sicherheit sind das direkte Ergebnis einer Fehlkonfiguration (siehe Nummer 3 im Pandemic 11-Bericht der Cloud Security Alliance) und dieser Trend wird voraussichtlich zunehmen. Cloud-Produkte ändern sich ständig und neue werden kontinuierlich eingeführt. Mit den ständigen Veränderungen Schritt zu halten, kann überwältigend erscheinen. Kunden benötigen Cloud-Anbieter, um ihnen bewährte Best Practices zur Verfügung zu stellen und mit den Änderungen Schritt zu halten. Dabei beginnen sie standardmäßig mit Best Practices und haben eine grundlegende Basiskonfiguration.
• Obwohl die Aufteilung von Elementen nach Cloud-Diensten hilfreich ist, haben viele Unternehmen Arbeitslasten, für die mehrere Cloud-Diensttypen erforderlich sind. In diesem Fall müssen Sie berücksichtigen, wie verschiedene Sicherheitskontrollen für diese Dienste interagieren, einschließlich der Frage, ob sie sich zwischen Diensten überschneiden. Sie könnten beispielsweise eine lokale Anwendung haben, die Sie zu Compute Engine migrieren, Google Workspace für geschäftliche E-Mail-Adressen verwenden und BigQuery zur Analyse von Daten ausführen, um Ihre Produkte zu verbessern.
• Ihr Unternehmen und Ihre Märkte verändern sich ständig, durch Änderungen der Vorschriften, wenn Sie an neuen Märkten teilnehmen oder beim Erwerb anderer Unternehmen. In Ihren neuen Märkten gelten möglicherweise andere Anforderungen und Ihre neue Akquisition kann ihre Arbeitslasten in einer anderen Cloud hosten. Um die konstanten Änderungen zu verwalten, müssen Sie Ihr Risikoprofil ständig neu bewerten und in der Lage sein, neue Kontrollen schnell zu implementieren.
• Wie und wo Sie Ihre Datenverschlüsselungsschlüssel verwalten, ist eine wichtige Entscheidung, die mit Ihren Verantwortlichkeiten zum Schutz Ihrer Daten zusammenhängt. Welche Option Sie auswählen, hängt von Ihren rechtlichen Anforderungen ab, unabhängig davon, ob Sie eine Hybrid-Cloud-Umgebung ausführen oder noch eine lokale Umgebung haben, ebenso wie von der Vertraulichkeit der verarbeiteten und gespeicherten Daten.
• Das Vorfallmanagement ist ein wichtiger und häufig übersehener Bereich, in dem Ihre Verantwortlichkeiten und die Verantwortlichkeiten des Cloudanbieters nicht einfach definiert sind. Viele Vorfälle erfordern eine enge Zusammenarbeit und Unterstützung vom Cloudanbieter, um sie zu untersuchen und zu beheben. Andere Vorfälle können durch falsch konfigurierte Cloud-Ressourcen oder gestohlene Anmeldedaten verursacht werden. Es kann recht schwierig sein, die Best Practices für den Schutz Ihrer Ressourcen und Konten zu erfüllen.
• Erweiterte persistente Bedrohungen (APT) und neue Sicherheitslücken können sich in einer Weise auf Ihre Arbeitslasten auswirken, ohne die beim Start der Cloud-Transformation vielleicht noch nicht absehbar war. Es ist schwierig, in der sich ändernden Umgebung immer auf dem Laufenden zu bleiben und zu wissen, wer für die Mitigation von Bedrohungen verantwortlich ist, insbesondere wenn Ihr Unternehmen kein großes Sicherheitsteam hat.

Geteiltes Schicksal

Wir haben für Google Cloud das Fate-Sharing entwickelt, um die Herausforderungen zu meistern, denen das Modell der geteilten Verantwortung nicht gerecht wird. Fate-Sharing konzentriert sich darauf, wie alle Parteien besser interagieren können, um die Sicherheit kontinuierlich zu verbessern. Fate-Sharing basiert auf dem Modell der geteilten Verantwortung, da es die Beziehung zwischen Cloud-Anbieter und Kunden als laufende Partnerschaft zur Verbesserung der Sicherheit betrachtet.

Beim Fate-Sharing geht es darum, dass wir die Verantwortung dafür übernehmen, Google Cloud sicherer zu machen. Fate-Sharing umfasst den Einstieg in eine gesicherte Landing Zone und eine klare und transparente Darstellung der empfohlenen Sicherheitskontrollen, -einstellungen und der zugehörigen Best Practices. Es hilft Ihnen mithilfe des Risikoschutzprogramms, Ihr Risiko bei der Cyberversicherung zu quantifizieren und zu verwalten. Unser Ziel ist es, das Standard-Framework für geteilte Verantwortung zu einem verbesserten Modell zu entwickeln, mit dem Sie Ihr Unternehmen schützen und Vertrauen in Google Cloud aufbauen können.

In den folgenden Abschnitten werden verschiedene Komponenten des Fate-Sharings beschrieben.

Hilfe beim Einstieg

Eine wichtige Komponente des Fate-Sharings sind die Ressourcen, die wir Ihnen zur Verfügung stellen, um Ihnen den Einstieg in eine sichere Konfiguration in Google Cloud zu erleichtern. Wenn Sie mit einer sicheren Konfiguration beginnen, verringert sich das Problem von Fehlkonfigurationen, die die Ursache der meisten Sicherheitsverstöße sind.

Zu unseren Ressourcen gehören:

• Blueprint für Unternehmensgrundlagen, in dem die wichtigsten Sicherheitsbedenken und unsere besten Empfehlungen behandelt werden.

• Sichere Blueprints, mit denen Sie sichere Lösungen mit Infrastruktur als Code (IaC) bereitstellen und verwalten können. Für Blueprints sind unsere Sicherheitsempfehlungen standardmäßig aktiviert. Viele Blueprints werden von Google-Sicherheitsteams erstellt und als Produkte verwaltet. Dieser Support bedeutet, dass sie regelmäßig aktualisiert werden, einen strengen Testprozess durchlaufen und Attestierungen von Testgruppen von Drittanbietern erhalten. Blueprints umfassen Folgendes: Unternehmensgrundlagen – Blueprint ,Gesichertes Data Warehouse-Blueprint und Blueprint für Vertex AI Workbench-Notebooks.

• Best Practices für das Architektur-Framework, um die wichtigsten Empfehlungen für die Einbindung von Sicherheit in Ihre Designs zu erfüllen. Das Architektur-Framework umfasst einen Sicherheitsabschnitt und eine Community-Zone, über die Sie mit Experten und Peers kommunizieren können.

• Leitfäden zur Navigation der Landing Zone führen Sie durch die wichtigsten Entscheidungen, die Sie treffen müssen, um eine sichere Grundlage für Ihre Arbeitslasten zu schaffen, einschließlich Ressourcenhierarchie, Onboarding von Identitäten, Sicherheit und Schlüsselverwaltung und Netzwerkstruktur.

Risikosicherheitsprogramm

Fate-Sharing enthält auch das Risikoschutzprogramm (derzeit in der Vorschau), das Ihnen hilft, die Leistungsfähigkeit von Google Cloud als Plattform zu nutzen, um Risiken zu verwalten, anstatt Cloud-Arbeitslasten lediglich als weitere Risikoquelle zu sehen, die Sie verwalten müssen. Das Risikoschutzprogramm ist eine Zusammenarbeit von Google Cloud und zwei führenden Unternehmen im Bereich Cyberversicherungen, Munich Re und Allianz Global & Corporate Speciality.

Das Risikoschutzprogramm enthält den Risk Manager, der datengesteuerte Einblicke bietet, mit denen Sie Ihren Cloud-Sicherheitsstatus besser verstehen können. Wenn Sie nach einer Cyberversicherungsleistung suchen, können Sie diese Informationen von Risk Manager direkt mit unseren Versicherungspartnern teilen, um ein Angebot zu erhalten. Weitere Informationen finden Sie unter Google Cloud-Risikoschutzprogramm jetzt in der Vorschau.

Hilfe bei der Bereitstellung und Governance

Fate-Sharing hilft auch bei der fortlaufenden Governance Ihrer Umgebung. Beispielsweise konzentrieren wir uns auf Produkte wie die folgenden:

• Assured Workloads: So können Sie Ihre Compliance-Anforderungen erfüllen.
• Security Command Center Premium, das Bedrohungsinformationen, Bedrohungserkennung, Webscan und andere erweiterte Methoden zum Monitoring und Erkennen von Bedrohungen verwendet. Bietet auch die Möglichkeit, viele dieser Bedrohungen schnell und automatisch zu beheben.
• Mit Organisationsrichtlinien und Ressourceneinstellungen können Sie Richtlinien in Ihrer Hierarchie von Ordnern und Projekten konfigurieren.
• Policy Intelligence-Tools mit Informationen zum Zugriff auf Konten und Ressourcen.
• Confidential Computing, mit dem Sie aktive Daten verschlüsseln können.
• Sovereign Cloud, das in Deutschland verfügbar ist und die Anforderungen an den Datenstandort implementiert.

Gemeinsame Verantwortung und gemeinsames Fate in der Praxis

Berücksichtigen Sie im Rahmen des Planungsprozesses die folgenden Maßnahmen, um die geeigneten Sicherheitskontrollen zu verstehen und zu implementieren:

• Erstellen Sie eine Liste der Arbeitslasten, die Sie in Google Cloud hosten möchten, und ob diese IaaS-, PaaS- und SaaS-Dienste erfordern. Sie können das Diagramm der geteilten Verantwortung als Checkliste verwenden, um herauszufinden, welche Sicherheitskontrollen Sie berücksichtigen müssen.
• Erstellen Sie eine Liste der gesetzlichen Anforderungen, die Sie erfüllen müssen, und greifen Sie im Center für Compliance-Ressourcen auf Ressourcen zu, die sich auf diese Anforderungen beziehen.
• Überprüfen Sie die Liste der verfügbaren Blueprints und Architekturen im Architekturcenter für die Sicherheitskontrollen, die Sie für Ihre jeweiligen Arbeitslasten benötigen. Die Blueprints enthalten eine Liste empfohlener Steuerelemente und den IaC-Code, den Sie zum Bereitstellen dieser Architektur benötigen.
• Verwenden Sie die Dokumentation zu Landing-Zones und die Empfehlungen im Leitfaden zu Unternehmensgrundlagen, um eine Ressourcenhierarchie und eine Netzwerkarchitektur zu entwerfen, die Ihren Anforderungen entsprechen. Sie können die angegebenen Blueprints für Arbeitslasten, wie das gesicherte Data Warehouse, verwenden, um Ihren Entwicklungsprozess zu beschleunigen.
• Prüfen Sie nach der Bereitstellung Ihrer Arbeitslasten, ob Sie Ihre Sicherheitsaufgaben erfüllen, mit Diensten wie Risk Manager, Assured Workloads, Policy Intelligence-Tools und Security Command Center Premium.

Weitere Informationen finden Sie im CISO-Leitfaden zur Cloud-Transformation.

Nächste Schritte

• Sicherheitsgrundsätze (nächstes Dokument in dieser Reihe)
• Bleiben Sie mit Fate-Sharing-Ressourcen auf dem neuesten Stand.
• Machen Sie sich mit den verfügbaren Blueprints vertraut, einschließlich der Blueprints für Sicherheitsgrundlagen und Beispielen für Arbeitslasten wie dem gesicherten Data Warehouse.
• Weitere Informationen zum Fate-Sharing
• Informationen zu unserer zugrunde liegenden sicheren Infrastruktur finden Sie in der Übersicht über das Sicherheitsdesign der Infrastruktur von Google.
• NIST Cybersecurity Framework Best Practices in Google Cloud (PDF) implementieren.

Sicherheitsgrundsätze

In diesem Dokument des Google Cloud-Architektur-Frameworks werden die wichtigsten Grundsätze für die Ausführung sicherer und konformer Dienste in Google Cloud erläutert. Viele der Sicherheitsgrundsätze, die Sie in Ihrer lokalen Umgebung kennen, gelten auch für Cloud-Umgebungen.

Einen mehrstufigen Sicherheitsansatz entwickeln

Implementieren Sie die Sicherheit auf jeder Ebene Ihrer Anwendung und Infrastruktur, indem Sie ein Konzept mit gestaffelten Sicherheitsebenen anwenden. Verwenden Sie die Funktionen in den einzelnen Produkten, um den Zugriff einzuschränken und bei Bedarf die Verschlüsselung zu konfigurieren.

Bei der Entwicklung für sichere entkoppelte Systeme sorgen

Vereinfachen Sie das Systemdesign, damit dies möglichst flexibel ist, und dokumentieren Sie die Sicherheitsanforderungen für jede Komponente. Integrieren Sie einen robusten, sicheren Mechanismus, um Ausfallsicherheit und Wiederherstellung zu berücksichtigen.

Bereitstellung sensibler Aufgaben automatisieren

Entfernen Sie Personen aus dem Workstream, indem Sie Bereitstellungs- und andere Administratoraufgaben automatisieren.

Sicherheitsmonitoring automatisieren

Verwenden Sie automatisierte Tools, um Ihre Anwendung und Infrastruktur zu überwachen. Verwenden Sie automatisierte Scans in Ihren CI/CD-Pipelines (Continuous Integration / Continuous Deployment), um Ihre Infrastruktur auf Sicherheitslücken zu scannen und Sicherheitsvorfälle zu erkennen.

Compliance-Anforderungen für die Regionen erfüllen

Beachten Sie, dass Sie möglicherweise personenidentifizierbare Informationen verschleiern oder entfernen müssen, um Ihre regulatorischen Anforderungen zu erfüllen. Automatisieren Sie nach Möglichkeit Ihre Compliance-Maßnahmen. Verwenden Sie beispielsweise den Schutz sensibler Daten und Dataflow, um das Entfernen personenbezogener Informationen zu automatisieren, bevor neue Daten im System gespeichert werden.

Anforderungen hinsichtlich Datenstandort und Datenhoheit erfüllen

Möglicherweise haben Sie interne (oder externe) Anforderungen, bei denen Sie die Standorte für Datenspeicherung und -verarbeitung steuern müssen. Diese Anforderungen variieren je nach Designzielsystemen, branchenüblichen Vorschriften, nationalem Recht, Auswirkungen auf die Steuer und Kultur. Der Datenstandort beschreibt, wo Ihre Daten gespeichert werden. Um die Anforderungen an den Datenstandort zu erfüllen, können Sie in Google Cloud steuern, wo Daten gespeichert werden, wie auf Daten zugegriffen wird und wie sie verarbeitet werden.

Sicherheit nach links verschieben

Mit DevOps- und Bereitstellungsautomatisierung kann Ihre Organisation Produkte schneller bereitstellen. Damit Ihre Produkte sicher bleiben, beziehen Sie Sicherheitsprozesse zu Beginn des Entwicklungsprozesses ein. Sie haben zum Beispiel folgende Möglichkeiten:

• Code in der Bereitstellungspipeline frühzeitig testen.
• Container-Images und die Cloud-Infrastruktur kontinuierlich scannen.
• Automatisieren Sie die Erkennung von Fehlkonfigurationen und Sicherheitsmustern. Sie können beispielsweise mithilfe von Automatisierung nach Secrets suchen, die in Anwendungen oder in der Konfiguration hartcodiert sind.

Nächste Schritte

Weitere Informationen zu den wichtigsten Sicherheitsgrundsätzen finden Sie in den folgenden Ressourcen:

• Risiken mit Steuerelementen bewältigen (nächstes Dokument in dieser Reihe)
• Blueprint für Google Cloud-Unternehmensgrundlagen
• Google Security Whitepaper
• Das Sicherheitsdesign der Infrastruktur von Google
• Gemeinsamen Prozess für Vorfallmanagement aufbauen
• Einsetzbare Blueprints für verschiedene Branchen

Risiko mit Steuerelementen verwalten

In diesem Dokument des Google Cloud-Architektur-Frameworks werden Best Practices zur Verwaltung von Risiken in einer Cloud-Bereitstellung beschrieben. Durch eine sorgfältige Analyse der Risiken, die für Ihre Organisation gelten, können Sie die erforderlichen Sicherheitskontrollen ermitteln. Sie sollten die Risikoanalyse durchführen, bevor Sie Arbeitslasten in Google Cloud bereitstellen. Außerdem sollten Sie diese regelmäßig wiederholen, da sich Ihre geschäftlichen Anforderungen, die gesetzlichen Vorschriften und die für Ihre Organisation relevanten Bedrohungen ändern.

Risiken für Ihre Organisation erkennen

Bevor Sie Ressourcen in Google Cloud erstellen und bereitstellen, führen Sie eine Risikobewertung durch, um zu ermitteln, welche Sicherheitsmaßnahmen Sie benötigen, um Ihre internen Sicherheitsanforderungen und externe gesetzliche Anforderungen zu erfüllen. Die Risikobewertung liefert eine Auflistung aller relevanten Risiken und Informationen dazu, in welchem Maße Ihr Unternehmen in der Lage ist, Sicherheitsbedrohungen zu erkennen und ihnen entgegenzuwirken.

Die Risiken in einer Cloudumgebung unterscheiden sich von den Risiken in einer lokalen Umgebung aufgrund der Vereinbarung zur geteilten Verantwortung, die Sie mit Ihrem Cloudanbieter eingehen. In einer lokalen Umgebung müssen Sie beispielsweise Sicherheitslücken im Hardware-Stack minimieren. Im Gegensatz dazu werden diese Risiken in einer Cloudumgebung vom Cloudanbieter übernommen.

Darüber hinaus unterscheiden sich Ihre Risiken je nachdem, wie Sie Google Cloud verwenden möchten. Übertragen Sie einige Ihrer Arbeitslasten in Google Cloud – oder alle? Verwenden Sie Google Cloud nur für die Notfallwiederherstellung? Richten Sie eine Hybrid-Cloud-Umgebung ein?

Wir empfehlen die Verwendung eines branchenüblichen Frameworks zur Risikobewertung für Cloud-Umgebungen, dass die jeweils geltenden gesetzlichen Vorschriften berücksichtigt. Beispielsweise bietet die Cloud Security Alliance (CSA) die Cloud Controls Matrix (CCM). Darüber hinaus gibt es Bedrohungsmodelle wie das OWASP-App-Bedrohungsmodell, die potenzielle Sicherheitslücken und Vorschläge zur Behebung dieser Lücken bereitstellen. In unserem Partnerverzeichnis finden Sie eine Liste der Experten, die Risikobewertungen für Google Cloud ausführen.

Wenn Sie Ihre Risiken katalogisieren möchten, sollten Sie den Risiko-Manager in Betracht ziehen, der Teil des Risiko-Schutzprogramms ist. Dieses Programm befindet sich derzeit in der Vorschau. Risk Manager scannt Ihre Arbeitslasten, damit Sie die Geschäftsrisiken besser nachvollziehen können. Die detaillierten Berichte bieten eine Sicherheitsreferenz. Darüber hinaus können Sie mithilfe von Risk Manager-Berichten Ihre Risiken mit den in der CIS-Benchmark (Center for Internet Security) beschriebenen Risiken vergleichen.

Nachdem Sie die Risiken katalogisiert haben, müssen Sie festlegen, wie Sie auf diese reagieren möchten, d. h. ob Sie sie akzeptieren, vermeiden, übertragen oder minimieren möchten. Im folgenden Abschnitt werden Sicherheitskontrollen zur Risikominderung beschrieben.

Risiken minimieren

Sie können Risiken mithilfe von technischen Kontrollen, vertraglichen Schutzmaßnahmen sowie Prüfungen oder Attestierungen von Drittanbietern minimieren. In der folgenden Tabelle ist aufgeführt, wie Sie diese Abhilfemaßnahmen für die Einführung neuer öffentlicher Cloud-Dienste verwenden können.

Risikominderung	Beschreibung
Technische Steuerelemente	Technische Steuerelemente beziehen sich auf die Funktionen und Technologien, mit denen Sie Ihre Umgebung schützen. Dazu gehören integrierte Cloud-Sicherheitskontrollen wie Firewalls und Logging. Technische Kontrollen können auch die Verwendung von Drittanbietertools umfassen, um Ihre Sicherheitsstrategie zu stärken oder zu unterstützen. Es gibt zwei Kategorien technischer Steuerelemente: Google Cloud bietet verschiedene Sicherheitskontrollen zur Minderung von Risiken, die auf Ihre Umgebung zutreffen. Wenn Sie beispielsweise eine lokale Umgebung haben, können Sie Cloud VPN und Cloud Interconnect verwenden, um die Verbindung zwischen Ihrer lokalen Umgebung und Ihren Cloud-Ressourcen zu schützen. Google umfasst robuste interne Kontrollmechanismen und Prüfungen, um den Zugriff auf Kundendaten durch Insider zu schützen. Unsere Audit-Logs bieten unseren Kunden echtzeitnahe Logs über den Google-Administratorzugriff in Google Cloud.
Vertraglicher Schutz	Vertragliche Schutzmaßnahmen beziehen sich auf die rechtlichen Verpflichtungen, die wir in Bezug auf Google Cloud-Dienste eingehen. Google Cloud setzt sich für die Erhaltung und Erweiterung des Compliance-Portfolios ein. Im Dokument Zusatz zur Verarbeitung von Cloud-Daten ist festgelegt, dass wir unsere Zertifizierungen nach ISO 27001, 27017 und 27018 beibehalten und unsere Berichte zu SOC 2 und SOC 3 alle 12 Monate aktualisieren. Das DPST-Dokument beschreibt außerdem die Zugriffssteuerungen, die den Zugriff durch Entwickler des Google-Supports auf die Umgebungen von Kunden beschränken, und beschreibt unser strenges Logging und einen Genehmigungsprozess. Wir empfehlen Ihnen, die vertraglichen Kontrollen von Google Cloud mit Ihren Rechts- und Regulierungsexperten zu prüfen und zu bestätigen, dass sie Ihren Anforderungen entsprechen. Wenn Sie weitere Informationen benötigen, wenden Sie sich an Ihren technischen Kundenbetreuer.
Überprüfungen oder Bescheinigungen von Drittanbietern	Überprüfungen oder Bescheinigungen von Drittanbietern beziehen sich darauf, dass ein Drittanbieter den Cloud-Anbieter prüft, um sicherzustellen, dass der Anbieter die Compliance-Anforderungen erfüllt. Google wurde beispielsweise von einem Drittanbieter auf die Einhaltung der ISO 27017 geprüft. Die aktuellen Google Cloud-Zertifizierungen und -Bescheinigungen finden Sie im Center für Compliance-Ressourcen.

Nächste Schritte

Weitere Informationen zum Risikomanagement finden Sie in den folgenden Ressourcen:

• Assets verwalten (nächstes Dokument in dieser Reihe)

• Risikosicherheitsprogramm

• Center für Compliance-Ressourcen

• Risiko-Governance für den digitalen Wandel in der Cloud (PDF)

Assets verwalten

In diesem Dokument des Google Cloud-Architektur-Frameworks finden Sie Best Practices zum Verwalten von Assets.

Die Asset-Verwaltung ist ein wichtiger Bestandteil der Analyse der Geschäftsanforderungen. Sie müssen wissen, welche Assets Sie haben, und Ihre Assets, deren Wert und alle mit diesen verbundenen kritischen Pfade oder Prozesse genau verstehen. Sie brauchen ein exaktes Asset-Inventar, bevor Sie Sicherheitskontrollen für den Schutz Ihrer Assets entwerfen können.

Um Sicherheitsvorfälle zu verwalten und die regulatorischen Anforderungen Ihrer Organisation zu erfüllen benötigen Sie ein präzises und aktuelles Asset-Inventar, das eine Möglichkeit zur Analyse von Verlaufsdaten bietet. Sie müssen in der Lage sein, Ihre Assets zu verfolgen, einschließlich der Art der Veränderung ihres Risikos im Laufe der Zeit.

Beim Wechsel zu Google Cloud müssen Sie Ihre Asset-Verwaltungsprozesse ändern und an eine Cloud-Umgebung anpassen. Einer der Vorteile der Umstellung auf die Cloud ist , dass Ihrer Organisation so schneller skalieren kann. Eine schnelle Skalierung kann jedoch zu Schatten-IT-Problemen führen, bei denen Mitarbeiter Cloud-Ressourcen erstellen, die nicht ordnungsgemäß verwaltet und gesichert sind. Daher müssen die Prozesse der Asset-Verwaltung Mitarbeitern genug Flexibilität bieten, um ihre Arbeit zu tun und gleichzeitig geeignete Sicherheitskontrollen bereitstellen.

Cloud-Asset-Managementtools verwenden

Googles Cloud-Asset-Managementtools sind speziell auf unsere Umgebung und wichtige Anwendungsfälle unserer Kunden zugeschnitten.

Eines dieser Tools ist Cloud Asset Inventory. Es enthält sowohl Echtzeitinformationen zum aktuellen Status Ihrer Ressourcen als auch einen fünfwöchigen Verlauf. Mit diesem Dienst können Sie einen organisationsweiten Snapshot Ihres Inventars für eine Vielzahl von Google Cloud-Ressourcen und -Richtlinien abrufen. Automatisierungstools können den Snapshot dann zur Überwachung oder Durchsetzung von Richtlinien verwenden oder die Snapshots zur Compliance-Prüfung archivieren. Wenn Sie Änderungen an den Assets analysieren möchten, können Sie mit dem Asset-Inventar auch den Metadatenverlauf exportieren.

Weitere Informationen zu Cloud Asset Inventory finden Sie unter Benutzerdefinierte Lösung zur Reaktion auf Asset-Änderungen und Erkennungsfunktionen.

Asset-Verwaltung automatisieren

Mithilfe von Automatisierung können Sie Assets auf Basis der von Ihnen angegebenen Sicherheitsanforderungen schnell erstellen und verwalten. Sie können Aspekte des Asset-Lebenszyklus auf folgende Arten automatisieren:

• Cloud-Infrastruktur mit Automatisierungstools wie Terraform bereitstellen Google Cloud bietet den Blueprint: Unternehmensgrundlagen, mit dem Sie Infrastrukturressourcen einrichten können, die den Best Practices für Sicherheit entsprechen. Darüber hinaus werden Asset-Änderungen und Benachrichtigungen zur Richtliniencompliance in Cloud Asset Inventory konfiguriert.
• Stellen Sie Ihre Anwendungen mit Automatisierungstools wie Cloud Run und Artifact Registry bereit.

Auf Abweichungen von Ihren Compliance-Richtlinien prüfen

Abweichungen von Richtlinien können in allen Phasen des Asset-Lebenszyklus auftreten. Beispielsweise können Assets ohne die richtigen Sicherheitskontrollen erstellt oder ihre Berechtigungen eskaliert werden. Ebenso können Assets verworfen werden, ohne dass die entsprechenden Abläufe am Ende des Lebenszyklus befolgt werden.

Damit diese Szenarien vermieden werden, empfehlen wir Ihnen, Assets auf Abweichungen von Compliance zu prüfen. Welche Gruppe von Assets Sie überwachen, hängt von den Ergebnissen Ihrer Risikobewertung und den Geschäftsanforderungen ab. Weitere Informationen zum Überwachen von Assets finden Sie unter Asset-Änderungen überwachen.

In bestehende Monitoring-Systeme der Asset-Verwaltung einbinden

Wenn Sie bereits ein SIEM-System oder ein anderes Monitoring-System verwenden, binden Sie Ihre Google Cloud-Assets in dieses System ein. Durch die Einbindung erhält Ihre Organisation unabhängig von der Umgebung einen einzigen, umfassenden Überblick über alle Ressourcen. Weitere Informationen finden Sie unter Google Cloud-Sicherheitsdaten in Ihr SIEM-System exportieren und Szenarien zum Exportieren von Cloud Logging-Daten: Splunk.

Datenanalyse für eine bessere Überwachung nutzen

Sie können Ihr Inventar zur weiteren Analyse in eine BigQuery-Tabelle oder einen Cloud Storage-Bucket exportieren.

Nächste Schritte

Erfahren Sie mehr über die Verwaltung Ihrer Assets mit folgenden Ressourcen:

• Identität und Zugriff verwalten (nächstes Dokument in dieser Reihe)
• Ressourcenverwaltung
• Systemdesign

Identität und Zugriff verwalten

In diesem Dokument des Google Cloud-Architektur-Frameworks finden Sie Best Practices zum Verwalten von Identität und Zugriff.

Mit der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) können Sie dafür sorgen, dass die richtigen Personen auf die richtigen Ressourcen zugreifen können. IAM berücksichtigt die folgenden Authentifizierungs- und Autorisierungsaspekte:

• Kontoverwaltung, einschließlich Bereitstellung
• Identity Governance
• Authentifizierung
• Zugriffssteuerung (Autorisierung)
• Identitätsföderation

Die Verwaltung von IAM kann schwierig sein, wenn Sie verschiedene Umgebungen haben oder mehrere Identitätsanbieter verwenden. Es ist jedoch wichtig, dass Sie ein System einrichten, das Ihre Geschäftsanforderungen erfüllt und gleichzeitig Risiken minimiert.

Die Empfehlungen in diesem Dokument helfen Ihnen, Ihre aktuellen IAM-Richtlinien und -Verfahren zu prüfen und zu ermitteln, welche Sie möglicherweise für Ihre Arbeitslasten in Google Cloud ändern müssen. Prüfen Sie beispielsweise Folgendes:

• Ob Sie vorhandene Gruppen zur Verwaltung des Zugriffs verwenden können oder ob Sie neue Gruppen erstellen müssen.
• Ihre Authentifizierungsanforderungen (z. B. Multi-Faktor-Authentifizierung (MFA) mit einem Token).
• Die Auswirkungen von Dienstkonten auf Ihre aktuellen Richtlinien
• Wenn Sie Google Cloud für die Notfallwiederherstellung verwenden, müssen Sie eine angemessene Aufgabentrennung beibehalten.

In Google Cloud verwenden Sie Cloud Identity, um Ihre Nutzer und Ressourcen sowie das IAM-Produkt (Identity and Access Management) zu authentifizieren und den Ressourcenzugriff zu bestimmen. Administratoren können den Zugriff auf Organisations-, Ordner-, Projekt- und Ressourcenebene einschränken. Google IAM-Richtlinien legen fest, wer was mit welchen Ressourcen tun darf. Korrekt konfigurierte IAM-Richtlinien tragen zum Schutz Ihrer Umgebung bei, indem sie unerwünschten Zugriff auf Ressourcen verhindern.

Weitere Informationen finden Sie unter Übersicht über die Identitäts- und Zugriffsverwaltung.

Einzelnen Identitätsanbieter verwenden

Viele unserer Kunden haben Nutzerkonten, die von Identitätsanbietern außerhalb von Google Cloud verwaltet und bereitgestellt werden. Google Cloud unterstützt die Föderation mit den meisten Identitätsanbietern und mit lokalen Verzeichnissen wie Active Directory.

Bei den meisten Identitätsanbietern können Sie die Einmalanmeldung (Single Sign-on, SSO) für Ihre Nutzer und Gruppen aktivieren. Für Anwendungen, die Sie in Google Cloud bereitstellen und die Ihren externen Identitätsanbieter verwenden, können Sie Ihren Identitätsanbieter auf Google Cloud erweitern. Weitere Informationen finden Sie unter Referenzarchitekturen und Muster für die Authentifizierung von Unternehmensnutzern in einer Hybridumgebung.

Wenn Sie noch keinen Identitätsanbieter haben, können Sie die Identitäten mit der Cloud Identity Premiumversion oder Google Workspace für Ihre Mitarbeiter verwalten.

Super Admin-Konto schützen

Mit dem Super Admin-Konto (von Google Workspace oder Cloud Identity verwaltet) können Sie Ihre Google Cloud-Organisation erstellen. Dieses Administratorkonto ist daher stark privilegiert. Best Practices für dieses Konto sind:

• Erstellen Sie zu diesem Zweck ein neues Konto; verwenden Sie kein vorhandenes Nutzerkonto.
• Erstellen und schützen Sie Sicherungskonten.
• Aktivieren Sie MFA.

Weitere Informationen finden Sie unter Best Practices für Super Admin-Konten.

Verwendung von Dienstkonten planen

Ein Dienstkonto ist ein Google-Konto, mit dem Anwendungen die Google API eines Dienstes aufrufen können.

Im Gegensatz zu Ihren Nutzerkonten werden Dienstkonten in Google Cloud erstellt und verwaltet. Dienstkonten authentifizieren sich auch anders als Nutzerkonten:

• Damit sich eine in Google Cloud ausgeführte Anwendung über ein Dienstkonto authentifizieren kann, können Sie an die Computing-Ressource, auf der die Anwendung ausgeführt wird, ein Dienstkonto anhängen.
• Damit sich eine in GKE ausgeführte Anwendung über ein Dienstkonto authentifizieren kann, können Sie Workload Identity verwenden.
• Damit Anwendungen, die außerhalb von Google Cloud ausgeführt werden, über ein Dienstkonto authentifiziert werden können, können Sie die Workload Identity-Föderation verwenden.

Wenn Sie Dienstkonten verwenden, müssen Sie eine geeignete Trennung der Aufgaben während des Entwurfprozesses berücksichtigen. Notieren Sie sich die erforderlichen API-Aufrufe und ermitteln Sie die Dienstkonten und die zugehörigen Rollen, die für die API-Aufrufe erforderlich sind. Wenn Sie beispielsweise ein BigQuery-Data-Warehouse einrichten, benötigen Sie wahrscheinlich Identitäten für mindestens die folgenden Prozesse und Dienste:

• Cloud Storage oder Pub/Sub, je nachdem, ob Sie eine Batchdatei bereitstellen oder einen Streamingdienst erstellen.
• Dataflow und Sensitive Data Protection, um sensible Daten zu de-identifizieren.

Weitere Informationen finden Sie unter Best Practices für die Arbeit mit Dienstkonten.

Identitätsprozesse für die Cloud aktualisieren

Mit Identity Governance können Sie den Zugriff, die Risiken und Richtlinienverstöße verfolgen und so Ihre gesetzlichen Anforderungen erfüllen. Für diese Art von Governance benötigen Sie Prozesse und Richtlinien, um Rollen und Berechtigungen für die Zugriffssteuerung gewähren und prüfen zu können. Ihre Prozesse und Richtlinien müssen den Anforderungen Ihrer Umgebungen entsprechen, z. B. Test-, Entwicklungs- und Produktionsumgebung.

Bevor Sie Arbeitslasten in Google Cloud bereitstellen, sollten Sie Ihre aktuellen Identitätsprozesse prüfen und bei Bedarf aktualisieren. Achten Sie darauf, dass Sie die Kontentypen, die Ihre Organisation benötigt, entsprechend planen und Ihre Rollen- und Zugriffsanforderungen gut kennen.

Zur Prüfung von Google IAM-Aktivitäten erstellt Google Cloud die folgenden Audit-Logs:

• Administratoraktivität Dieses Logging kann nicht deaktiviert werden.
• Datenzugriffsaktivität. Dieses Logging muss aktiviert werden.

Wenn es für die Compliance erforderlich ist oder wenn Sie eine Loganalyse einrichten wollen (z. B. mit Ihrem SIEM-System), können Sie die Logs exportieren. Da Logging den Speicherbedarf erhöhen kann, kann es sich auf Ihre Kosten auswirken. Achten Sie darauf, dass Sie nur die erforderlichen Aktionen loggen und geeignete Aufbewahrungspläne festlegen.

SSO und MFA einrichten

Ihr Identitätsanbieter verwaltet die Authentifizierung von Nutzerkonten. Föderierte Identitäten können sich mit SSO bei Google Cloud authentifizieren. Bei privilegierten Konten wie Super Admins sollten Sie MFA konfigurieren. Titan-Sicherheitsschlüssel sind physische Tokens, die Sie für die 2-Faktor-Authentifizierung (2FA) verwenden können, um Phishing-Angriffe zu verhindern.

Cloud Identity unterstützt MFA mithilfe verschiedener Methoden. Weitere Informationen finden Sie unter Einheitliche Multi-Faktor-Authentifizierung für unternehmenseigene Ressourcen erzwingen.

Google Cloud unterstützt die Authentifizierung für Arbeitslastidentitäten mit dem OAuth 2.0-Protokoll oder mit signierten JSON Web Tokens (JWT). Weitere Informationen zur Arbeitslastauthentifizierung finden Sie unter Authentifizierung.

Geringste Berechtigung und Aufgabentrennung implementieren

Sie müssen dafür sorgen, dass die richtigen Personen nur auf die Ressourcen und Dienste zugreifen können, die sie für ihre Arbeit benötigen. Das heißt, Sie sollten dem Prinzip der geringsten Berechtigung folgen. Darüber hinaus muss eine angemessene Aufgabentrennung vorhanden sein.

Eine Überdimensionierung des Nutzerzugriffs kann das Risiko von Insider-Bedrohungen, falsch konfigurierten Ressourcen und fehlender Compliance mit Audits erhöhen. Bei zu wenigen Berechtigungen haben Nutzer möglicherweise keinen Zugriff auf die Ressourcen, die sie für ihre Aufgaben benötigen.

Eine Möglichkeit zur Vermeidung einer Überdimensionierung ist die Verwendung des Just-in-Time-Zugriffs auf Berechtigungen, das heißt, der privilegierte Zugriff wird nur bei Bedarf und nur vorübergehend gewährt.

Beachten Sie, dass beim Erstellen einer Google Cloud-Organisation standardmäßig allen Nutzern in Ihrer Domain die Rollen „Rechnungskontoersteller“ und „Projektersteller“ zugewiesen werden. Bestimmen Sie die Nutzer, die diese Aufgaben übernehmen sollen, und entziehen Sie anderen Nutzern diese Rollen. Weitere Informationen finden Sie unter Organisationen erstellen und verwalten.

Weitere Informationen zur Funktionsweise von Rollen und Berechtigungen in Google Cloud finden Sie in der IAM-Dokumentation unter Übersicht und Informationen zu Rollen. Weitere Informationen zum Erzwingen der geringsten Berechtigung finden Sie unter Geringste Berechtigung mit Rollenempfehlungen erzwingen.

Zugriff prüfen

Verwenden Sie Cloud-Audit-Logs, um die Aktivitäten von privilegierten Konten auf Abweichungen von genehmigten Aktivitäten zu prüfen. Cloud-Audit-Logs loggt die Aktionen, die Mitglieder Ihrer Google Cloud-Organisation in Ihren Google Cloud-Ressourcen durchgeführt haben. Sie können mit verschiedenen Audit-Logtypen in allem Google-Diensten arbeiten. Weitere Informationen finden Sie unter Verwendung von Cloud-Audit-Logs zur Handhabung von Insiderrisiken (Video).

Verwenden Sie IAM Recommender, um die Nutzung zu verfolgen und bei Bedarf Berechtigungen anzupassen. Mit den von IAM-Recommender empfohlenen Rollen können Sie anhand des bisherigen Verhaltens und anderer Kriterien bestimmen, welche Rollen einem Nutzer zugewiesen werden sollen. Weitere Informationen finden Sie unter Best Practices für Rollenempfehlungen.

Mit Access Transparency können Sie den Zugriff auf Ihre Ressourcen durch den Support und die Entwickler von Google prüfen und steuern. Access Transparency zeichnet die von Google-Mitarbeitern ausgeführten Aktionen auf. Verwenden Sie die Zugriffsgenehmigung, die Teil von Access Transparency ist, um bei jedem Zugriff auf Kundeninhalte eine ausdrückliche Genehmigung zu erteilen. Weitere Informationen finden Sie unter Zugriff auf Cloud-Administratoren auf Ihre Daten steuern.

Richtlinienkontrollen automatisieren

Legen Sie nach Möglichkeit programmatisch Berechtigungen fest. Best Practices finden Sie unter Organisationsrichtlinieneinschränkungen. Die Terraform-Skripts für den Blueprint zu Unternehmensgrundlagen befinden sich im Beispiel-Grundlagen-Repository.

Google Cloud umfasst Policy Intelligence. Damit können Sie Ihre Zugriffsberechtigungen automatisch prüfen und aktualisieren. Policy Intelligence umfasst die Tools Recommender, Policy Troubleshooter und Policy Analyzer, mit denen Sie folgende Aufgaben ausführen können:

• Empfehlungen für die Zuweisung von IAM-Rollen geben.
• IAM-Richtlinien überwachen und verhindern, dass sie zu großzügig sind.
• Hilfestellung bei der Behebung von Problemen bei der Zugriffssteuerung erhalten.

Einschränkungen für Ressourcen festlegen

Google IAM konzentriert sich auf Identitäten. Sie können Nutzer autorisieren, auf der Grundlage ihrer Berechtigungen auf bestimmte Ressourcen zuzugreifen. Der Organisationsrichtliniendienst konzentriert sich auf Ressourcen und ermöglicht Ihnen, Einschränkungen für Ressourcen festzulegen, um anzugeben, wie diese konfiguriert werden können. Mit einer Organisationsrichtlinie können Sie beispielsweise Folgendes tun:

• Beschränken der Ressourcenfreigabe auf Grundlage der Domain.
• Nutzung von Dienstkonten einschränken.
• Beschränken des physischen Standorts neu erstellter Ressourcen.

Zusätzlich zur Verwendung von Organisationsrichtlinien für diese Aufgaben können Sie den Zugriff auf Ressourcen mit einer der folgenden Methoden einschränken:

• Verwenden Sie Tags, um den Zugriff auf Ihre Ressourcen zu verwalten, ohne die Zugriffsberechtigungen für jede Ressource zu definieren. Stattdessen fügen Sie das Tag hinzu und legen dann die Zugriffsdefinition für das Tag selbst fest.
• IAM Conditions ermöglichen eine bedingte, attributbasierte Steuerung für den Zugriff auf Ressourcen.
• Implementieren Sie mit VPC Service Controls gestaffelte Sicherheitsebenen, um den Zugriff auf Ressourcen weiter einzuschränken.

Weitere Informationen zur Ressourcenverwaltung finden Sie unter Ressourcenverwaltung.

Nächste Schritte

Weitere Informationen zu IAM finden Sie in den folgenden Ressourcen:

• Computing- und Containersicherheit implementieren (nächstes Dokument in dieser Reihe)

• IAM sicher verwenden

• Referenzarchitekturen

• IAM Recommender: Geringste Berechtigung mit weniger Aufwand

• Clouddatenschutz

• Identitäts- und Zugriffsverwaltung – Übersicht

Computing- und Containersicherheit implementieren

Google Cloud bietet Steuerelemente zum Schutz Ihrer Computing- und GKE (Google Kubernetes Engine)-Containerressourcen. In diesem Dokument des Google Cloud-Architektur-Frameworks werden wichtige Steuerelemente und die Best Practices für deren Verwendung beschrieben.

Gehärtete und ausgewählte VM-Images verwenden

Google Cloud enthält Shielded VM, mit der Sie Ihre VM-Instanzen härten können. Shielded VM ist so konzipiert, dass während des Bootvorgangs kein schädlicher Code geladen wird. Es bietet Bootsicherheit, überwacht die Integrität und verwendet das Virtual Trusted Platform Module (vTPM). Verwenden Sie Shielded VM für sensible Arbeitslasten.

Zusätzlich zur Verwendung von Shielded VM können Sie Google Cloud-Partnerlösungen nutzen, um Ihre VMs noch besser zu schützen. Viele in Google Cloud angebotene Partnerlösungen sind in das Security Command Center eingebunden, das die Erkennung von Bedrohungen und die Statusüberwachung bietet. Sie können Partner für die erweiterte Bedrohungsanalyse oder zur Verbesserung der Laufzeitsicherheit nutzen.

Verwenden Sie Confidential Computing zum Verarbeiten vertraulicher Daten.

Standardmäßig verschlüsselt Google Cloud inaktive und aktuell übertragene Daten im Netzwerk, aber nicht, während sie im Speicher verwendet werden. Falls Ihre Organisation vertrauliche Daten verarbeitet, müssen Sie gegen Bedrohungen vorgehen, die die Vertraulichkeit und Integrität der Anwendung oder der Daten im Systemspeicher beeinträchtigen. Vertrauliche Daten sind personenidentifizierbare Informationen (PIIs), Finanz- und Gesundheitsdaten.

Confidential Computing baut auf Shielded VM auf. Sie schützt aktive Daten, indem sie eine Berechnung in einer hardwarebasierten vertrauenswürdigen Ausführungsumgebung durchführt. Diese Art von sicherer und isolierter Umgebung trägt dazu bei, unbefugten Zugriff oder Änderungen an Anwendungen und Daten zu verhindern, während diese Daten verwendet werden. Eine vertrauenswürdige Ausführungsumgebung erhöht auch die Sicherheit für Organisationen, die sensible und regulierte Daten verwalten.

Um in Google Cloud Confidential Computing zu aktivieren führen Sie Confidential VMs oder Confidential GKE Nodes aus. Aktivieren Sie Confidential Computing, wenn Sie vertrauliche Arbeitslasten verarbeiten oder vertrauliche Daten (z. B. Secrets) haben, die während ihrer Verarbeitung sichtbar sein müssen. Weitere Informationen finden Sie im Confidential Computing-Consortium.

VMs und Container schützen

OS Login ermöglicht es Ihren Mitarbeitern, Verbindungen zu Ihren VMs herzustellen. Dazu verwenden Sie IAM (Identity and Access Management)-Berechtigungen statt SSH-Schlüsseln als "Source of Truth". Entsprechend müssen Sie SSH-Schlüssel nicht in Ihrer gesamten Organisation verwalten. OS Login verknüpft den Zugriff eines Administrators mit dessen Mitarbeiter-Lebenszyklus. Wenn ein Mitarbeiter zu einer anderen Rolle wechselt oder Ihre Organisation verlässt, wird dessen Zugriff mit dessen Konto ungültig. OS Login unterstützt auch die 2-Faktor-Authentifizierung, die eine zusätzliche Sicherheitsebene bei Kontoübernahmeangriffen bietet.

In GKE führt App Engine Anwendungsinstanzen in Docker-Containern aus. Achten Sie darauf, dass Ihre Container zustandslos und unveränderlich sind, um ein definiertes Risikoprofil zu aktivieren und zu verhindern, dass Mitarbeiter Änderungen an Containern vornehmen. Das Prinzip der Unveränderlichkeit bedeutet, dass Ihre Mitarbeiter den Container nicht ändern oder interaktiv aufrufen. Wenn es geändert werden muss, erstellen Sie ein neues Image und stellen es noch einmal bereit. Aktivieren Sie den SSH-Zugriff auf die zugrunde liegenden Container nur in bestimmten Debugging-Szenarien.

Externe IP-Adressen deaktivieren, sofern sie nicht erforderlich sind

Um die externe IP-Adresszuweisung für Ihre Produktions-VMs zu deaktivieren (Video) und die Verwendung externer Load-Balancer zu verhindern, können Sie Organisationsrichtlinien verwenden. Wenn Ihre VMs auf das Internet oder Ihr lokales Rechenzentrum zugreifen müssen, können Sie ein Cloud NAT-Gateway aktivieren.

Sie können in GKE private Cluster bereitstellen. In einem privaten Cluster haben Knoten nur interne IP-Adressen. Das heißt, Knoten und Pods sind standardmäßig vom Internet isoliert. Sie können auch Netzwerkrichtlinien definieren, um die Pod-zu-Pod-Kommunikation im Cluster zu verwalten. Weitere Informationen finden Sie unter Private Zugriffsoptionen für Dienste.

Compute-Instanz und GKE-Nutzung überwachen

Cloud-Audit-Logs werden für Compute Engine und GKE automatisch aktiviert. Mit Audit-Logs können Sie automatisch alle Aktivitäten mit Ihrem Cluster erfassen und auf verdächtige Aktivitäten überwachen.

Sie können GKE zur Laufzeitsicherheit in Partnerprodukte einbinden. Sie können diese Lösungen in das Security Command Center einbinden und so eine zentrale Oberfläche zum Überwachen Ihrer Anwendungen erhalten.

Images und Cluster auf dem neuesten Stand halten

Google Cloud bietet ausgewählte Betriebssystem-Images, die regelmäßig gepatcht werden. Sie können benutzerdefinierte Images verwenden und in Compute Engine ausführen, aber in diesem Fall müssen Sie diese selbst patchen. Google Cloud aktualisiert Betriebssystem-Images regelmäßig, um neue Sicherheitslücken zu beheben, wie in Sicherheitsbulletins beschrieben, und bietet Lösungen zur Behebung von Sicherheitslücken bei vorhandenen Bereitstellungen.

Wenn Sie GKE verwenden, empfehlen wir, das automatische Knotenupgrade zu aktivieren, damit Google Ihre Clusterknoten mit den neuesten Patches aktualisiert. Google verwaltet GKE-Steuerungsebenen, die automatisch aktualisiert und gepatcht werden. Verwenden Sie außerdem von Google ausgewählte containeroptimierte Images für Ihre Bereitstellung. Google patcht und aktualisiert diese Images regelmäßig.

Zugriff auf Images und Cluster steuern

Es ist wichtig zu wissen, wer Instanzen erstellen und einführen kann. Sie können diesen Zugriff per IAM steuern. Informationen zur Bestimmung des erforderlichen Zugriffs von Arbeitslasten finden Sie unter Workload Identities planen.

Darüber hinaus können Sie mit VPC Service Controls benutzerdefinierte Kontingente für Projekte definieren, um einzuschränken, wer Images starten kann. Weitere Informationen finden Sie im Abschnitt Netzwerk sichern.

Zur Gewährleistung der Infrastruktursicherheit Ihres Clusters können Sie in GKE IAM mit RBAC (Role-Based Access Control) nutzen, um den Zugriff auf Ihren Cluster und Ihre Namespaces zu verwalten.

Container in einer Sandbox isolieren

Verwenden Sie GKE Sandbox, um mehrmandantenfähige Anwendungen bereitzustellen, die eine zusätzliche Sicherheitsebene und die Isolation von ihrem Host-Kernel erfordern. Beispiel: Verwenden Sie GKE Sandbox, wenn Sie unbekannten oder nicht vertrauenswürdigen Code ausführen. GKE Sandbox ist eine Containerisolierungslösung, die eine zweite Sicherheitsebene zwischen Containerarbeitslasten in GKE bietet.

GKE Sandbox wurde für Anwendungen mit niedrigen E/A-Anforderungen entwickelt, die hoch skaliert sind. Diese containerisierten Arbeitslasten müssen ihre Geschwindigkeit und Leistung beibehalten, können jedoch auch nicht vertrauenswürdigen Code enthalten, der zusätzliche Sicherheitsmaßnahmen erfordert. Verwenden Sie gVisor, eine Container-Laufzeit-Sandbox, um eine zusätzliche Sicherheitsisolation zwischen Anwendungen und dem Host-Kernel herzustellen. gVisor bietet zusätzliche Integritätsprüfungen und begrenzt die Zugriffsoptionen von Diensten. Das ist kein Container-Härtungsdienst zum Schutz vor externen Bedrohungen. Weitere Informationen zu gVisor finden Sie unter gVisor: Schutz von GKE- und serverlosen Nutzern in echten Welt.

Nächste Schritte

Hier finden Sie weitere Informationen zur Computing- und Containersicherheit:

• Netzwerk sichern (nächstes Dokument in dieser Reihe)
• Warum die Containersicherheit wichtig ist (PDF)
• Start-Checkliste für Google Cloud
• Identität von Instanzen prüfen
• Workload Identity
• Shielded VM
• Best Practices für Snapshots nichtflüchtiger Speicher
• Best Practices für die Imageverwaltung

Netzwerk sichern

In diesem Dokument des Google Cloud-Architektur-Frameworks finden Sie Best Practices zum Schutz Ihres Netzwerks.

Die Erweiterung Ihres vorhandenen Netzwerks auf Cloud-Umgebungen hat viele Auswirkungen auf die Sicherheit. Ihr lokaler Ansatz für mehrschichtige Verteidigungen umfasst wahrscheinlich einen eindeutigen Perimeter zwischen dem Internet und Ihrem internen Netzwerk. Den Perimeter schützen Sie wahrscheinlich mit physischen Firewalls, Routern, Systemen zur Angriffserkennung usw. Da die Grenze klar definiert ist, können Sie leicht auf Eindringvorgänge überwachen und entsprechend reagieren.

Wenn Sie die Cloud entweder vollständig oder in einem hybriden Ansatz nutzen, begeben Sie sich über den lokalen Perimeter hinaus. In diesem Dokument wird beschrieben, wie Sie die Daten und Arbeitslasten Ihrer Organisation in Google Cloud weiter schützen können. Wie Sie unter Risiken mit Kontrollen verwalten lesen können, hängt die Einrichtung und Sicherung Ihres Google Cloud-Netzwerks von Ihren Geschäftsanforderungen und Ihrer Risikobereitschaft ab.

In diesem Abschnitt wird davon ausgegangen, dass Sie den Abschnitt Netzwerk in der Kategorie Systemdesign gelesen und bereits eine grundlegendes Architekturdiagramm Ihrer Google Cloud-Netzwerkkomponenten erstellt haben. Ein Beispieldiagramm finden Sie unter Hub-and-Spoke.

Zero-Trust-Netzwerke bereitstellen

Durch den Wechsel in die Cloud muss sich das Vertrauensmodell Ihres Netzwerks ändern. Da sich Ihre Nutzer und Ihre Arbeitslasten nicht mehr hinter Ihrem lokalen Perimeter befinden, können Sie den Perimeterschutz nicht mehr auf die gleiche Weise verwenden, um ein vertrauenswürdiges, internes Netzwerk zu erstellen. Das Zero-Trust-Sicherheitsmodell bedeutet, dass niemand standardmäßig vertrauenswürdig ist, unabhängig davon, ob er sich innerhalb oder außerhalb des Netzwerks Ihrer Organisation befindet. Beim Überprüfen von Zugriffsanfragen erfordert das Zero-Trust-Sicherheitsmodell sowohl eine Prüfung auf die Identität als auch auf den Kontext des Nutzers. Im Gegensatz zu einem VPN verschieben Sie die Zugriffssteuerungen vom Netzwerkperimeter auf die Nutzer und Geräte.

In Google Cloud können Sie BeyondCorp Enterprise als Zero-Trust-Lösung verwenden. BeyondCorp Enterprise bietet Bedrohungs- und Datenschutz sowie zusätzliche Zugriffssteuerungen. Weitere Informationen zur Einrichtung finden Sie unter Erste Schritte mit BeyondCorp Enterprise.

Neben BeyondCorp Enterprise enthält Google Cloud auch Identity-Aware Proxy (IAP). Mit IAP können Sie die Zero-Trust-Sicherheit auf Ihre Anwendungen sowohl in Google Cloud als auch lokal erweitern. IAP verwendet Zugriffssteuerungsrichtlinien, um Nutzern, die auf Ihre Anwendungen und Ressourcen zugreifen, eine Authentifizierung und Autorisierung bereitzustellen.

Sichern Sie die Verbindungen zu Ihren lokalen bzw. Multi-Cloud-Umgebungen.

Viele Organisationen haben Arbeitslasten sowohl in Cloud-Umgebungen als auch lokal. Für Ausfallsicherheit verwenden einige Organisationen Multi-Cloud-Lösungen. In diesen Szenarien ist es wichtig, die Verbindung zwischen allen Umgebungen zu sichern.

Google Cloud umfasst private Zugriffsmethoden für VMs, die vonCloud VPN oder Cloud Interconnect unterstützt werden. Dazu gehören folgende:

• Verwenden Sie Cross-Cloud Interconnect als verwalteten Dienst, um Ihre VPC-Netzwerke über direkte Hochgeschwindigkeitsverbindungen direkt mit anderen unterstützten Cloud-Anbietern zu verbinden. Bei Cross-Cloud Interconnect müssen Sie keinen eigenen Router bereitstellen und nicht mit einem Drittanbieter zusammenarbeiten.
• Verwenden Sie Dedicated Interconnect und Partner Interconnect, um Ihre VPC-Netzwerke über direkte Hochgeschwindigkeitsverbindungen mit Ihrem lokalen Rechenzentrum oder mit anderen Cloud-Anbietern zu verbinden.
• Verwenden Sie IPSec-VPNs, um Ihre VPC-Netzwerke (Virtual Private Cloud) mit Ihrem lokalen Rechenzentrum oder mit anderen Cloud-Anbietern zu verbinden.
• Verwenden Sie Private Service Connect-Endpunkte für den Zugriff auf veröffentlichte Dienste, die von Ihrer Organisation oder von einem anderen Anbieter bereitgestellt werden.
• Verwenden Sie Private Service Connect-Endpunkte, damit Ihre VMs über interne IP-Adressen auf Google APIs zugreifen können. Mit Private Service Connect müssen Ihre VMs keine externen IP-Adressen haben, um auf Google-Dienste zugreifen zu können.
• Wenn Sie GKE Enterprise nutzen, sollten Sie Egress-Gateways von Anthos Service Mesh in Betracht ziehen. Wenn Sie GKE Enterprise nicht nutzen, werden Sie eine Drittanbieteroption verwenden.

Einen Vergleich zwischen den Produkten finden Sie unter Netzwerkverbindungsprodukt auswählen.

Standardnetzwerke deaktivieren

Wenn Sie ein neues Google Cloud-Projekt erstellen, werden ein VPC-Standardnetzwerk von Google Cloud mit IP-Adressen im automatischen Modus und vorkonfigurierte Firewallregeln automatisch bereitgestellt. Für Produktionsbereitstellungen empfehlen wir, die Standardnetzwerke in vorhandenen Projekten zu löschen und in neuen Projekten die Erstellung von Standardnetzwerken zu deaktivieren.

Mit Virtual Private Cloud-Netzwerken können Sie jede interne IP-Adresse verwenden. Um Konflikte mit IP-Adressen zu vermeiden, empfehlen wir, dass Sie zuerst die Netzwerk- und IP-Adresszuweisung für Ihre verbundenen Bereitstellungen und Ihre Projekte planen. Ein Projekt lässt mehrere VPC-Netzwerke zu, aber es ist normalerweise Best Practice, diese Netzwerke auf ein Netzwerk pro Projekt zu beschränken, um die Zugriffssteuerung effektiv zu erzwingen.

Perimeter sichern

In Google Cloud können Sie Ihren Cloud-Perimeter mithilfe verschiedener Methoden segmentieren und sichern, einschließlich Firewalls und VPC Service Controls.

Sie können eine freigegebene VPC verwenden, um ein Produktionsbereitstellung zu erstellen, die Ihnen ein einzelnes freigegebenes Netzwerk bietet und Arbeitslasten in einzelnen Projekten isoliert, die von verschiedenen Teams verwaltet werden können. Eine freigegebene VPC bietet eine zentralisierte Bereitstellung, Verwaltung und Steuerung der Netzwerk- und Netzwerksicherheitsressourcen über mehrere Projekte hinweg. Eine freigegebene VPC besteht aus Host- und Dienstprojekten, die die folgenden Funktionen ausführen:

• Ein Hostprojekt enthält die netzwerk- und sicherheitsbezogenen Ressourcen wie VPC-Netzwerke, Subnetze, Firewallregeln und Hybridkonnektivität.
• Ein Dienstprojekt wird an ein Hostprojekt angehängt. So können Sie Arbeitslasten und Nutzer auf Projektebene mithilfe von Identity and Access Management (IAM) isolieren, während die Netzwerkressourcen im zentral verwalteten Hostprojekt geteilt werden.

Definieren Sie Firewallrichtlinien und -regeln auf Organisations-, Ordner- und VPC-Netzwerkebene. Sie können Firewallregeln konfigurieren, um den Traffic von oder zu VM-Instanzen zuzulassen oder zu verweigern. Beispiele finden Sie unter Beispiele für globale und regionale Netzwerk-Firewallrichtlinien und Beispiele für hierarchische Firewallrichtlinien. Neben der Definition von Regeln anhand von IP-Adressen, Protokollen und Ports können Sie auch Traffic verwalten und Firewallregeln auf Basis des Dienstkontos anwenden, das von einer VM-Instanz oder mithilfe von sicheren Tags verwendet wird.

Ziehen Sie VPC Service Controls in Betracht, um die Verschiebung von Daten in Google-Diensten zu steuern und die kontextbasierte Perimetersicherheit einzurichten. VPC Service Controls bietet eine zusätzliche Sicherheitsebene für Google Cloud-Dienste, die unabhängig von IAM- und Firewallregeln und -Richtlinien ist. Mit VPC Service Controls können Sie beispielsweise Perimeter zwischen vertraulichen und nicht vertraulichen Daten einrichten, um Kontrollen anzuwenden, die eine Daten-Exfiltration verhindern.

Mit Google Cloud Armor-Sicherheitsrichtlinien können Sie den Zugriff auf Ihren externen Application Load Balancer am Google Cloud-Rand so nahe wie möglich an der Quelle des eingehenden Traffics zulassen, sperren oder weiterleiten. Diese Richtlinien verhindern, dass unerwünschter Traffic Ressourcen verbraucht oder in Ihr Netzwerk gelangt.

Verwenden Sie Secure Web Proxy, um detaillierte Zugriffsrichtlinien auf Ihren ausgehenden Webtraffic anzuwenden und den Zugriff auf nicht vertrauenswürdige Webdienste zu überwachen.

Netzwerkverkehr prüfen

Sie können Cloud IDS und die Paketspiegelung verwenden, um für die Sicherheit und Compliance von Arbeitslasten zu sorgen, die in Compute Engine und Google Kubernetes Engine (GKE) ausgeführt werden.

Verwenden Sie das Cloud Intrusion Detection System (derzeit in der Vorschau), um einen Einblick in den Traffic zu erhalten, der in und aus Ihren VPC-Netzwerken kommt. Cloud IDS erstellt ein von Google verwaltetes Peering-Netzwerk, das gespiegelte VMs hat. Die Bedrohungsschutz-Technologien von Palo Alto Networks spiegeln den Traffic wider und prüfen ihn. Weitere Informationen finden Sie unter Cloud IDS – Übersicht.

Bei der Paketspiegelung wird der Traffic bestimmter VM-Instanzen in Ihrem VPC-Netzwerk geklont und zur Erfassung, Aufbewahrung und Prüfung weitergeleitet. Nachdem Sie die Paketspiegelung konfiguriert haben, können Sie den Netzwerktraffic mithilfe von Cloud IDS oder Drittanbietertools im großen Maßstab erfassen und prüfen. Die Prüfung des Netzwerkverkehrs auf diese Weise erleichtert die Angriffserkennung und das Monitoring der Anwendungsleistung.

Webanwendungs-Firewall verwenden

Für externe Webanwendungen und Dienste können Sie Google Cloud Armor aktivieren, um DDoS-Schutz (Distributed Denial of Service) und WAF-Funktionen (Web Application Firewall) bereitzustellen. Google Cloud Armor unterstützt Google Cloud-Arbeitslasten, die über externes HTTP(S)-Load-Balancing, TCP-Proxy-Load-Balancing oder SSL-Proxy-Load-Balancing verfügbar gemacht werden.

Google Cloud Armor wird in zwei Dienststufen angeboten: Standard und Managed Protection Plus: Damit Sie die fortgeschrittenen Google Cloud Armor-Funktionen nutzen können, sollten Sie für Ihre wichtigsten Arbeitslasten in Managed Protection Plus investieren.

Infrastrukturbereitstellung automatisieren

Durch Automatisierung können Sie eine unveränderliche Infrastruktur erstellen, das heißt, sie kann nach der Bereitstellung nicht mehr geändert werden. Diese Maßnahme bietet Ihrem operativen Team einen gut funktionierenden Status sowie schnelle Rollbacks und Fehlerbehebungsfunktionen. Zur Automatisierung können Sie Tools wie Terraform, Jenkins und Cloud Build verwenden.

Damit Sie eine Umgebung mit Automatisierung erstellen können, bietet Google Cloud eine Reihe von Sicherheits-Blueprints, die wiederum auf dem Blueprint zu Unternehmensgrundlagen basieren. Der Blueprint zu den Sicherheitsgrundlagen bietet Googles Design für eine sichere Anwendungsumgebung und beschreibt Schritt für Schritt, wie Sie Ihre Google Cloud-Infrastruktur konfigurieren und bereitstellen. Mithilfe der Anweisungen und der Skripts, die Teil des Blueprints für die Sicherheitsgrundlagen sind, können Sie eine Umgebung konfigurieren, die unseren Best Practices und Richtlinien für die Sicherheit entspricht. Sie können auf diesen Blueprint mit zusätzlichen Blueprints aufbauen oder Ihre eigene Automatisierung entwerfen.

Weitere Informationen zur Automatisierung finden Sie unter CI/CD-Pipeline für Datenverarbeitungsworkflows verwenden.

Netzwerk überwachen

Überwachen Sie Ihr Netzwerk und Ihren Traffic mithilfe von Telemetrie.

VPC-Flusslogs und Firewallregel-Logging bieten nahezu in Echtzeit Einblick in den Traffic und die Firewallnutzung in Ihrer Google Cloud-Umgebung finden Sie weitere Informationen. Beispiel: Das Logging von Firewallregeln protokolliert den Traffic von und zu Compute Engine-VM-Instanzen. Wenn Sie diese Tools mit Cloud Logging und Cloud Monitoring kombinieren, können Sie den Traffic verfolgen, melden und visualisieren. Mit Zugriffsmustern verbessern Sie außerdem die Betriebssicherheit Ihrer Bereitstellung.

Mit Firewall Insights können Sie prüfen, welche Firewallregeln mit eingehenden und ausgehenden Verbindungen übereinstimmen und ob die Verbindungen zugelassen oder abgelehnt wurden. Mit dem Feature für verdeckte Regeln können Sie Ihre Firewall-Konfiguration optimieren. Sie prüfen, welche Regeln nie ausgelöst werden, da eine andere Regel immer zuerst ausgelöst wird.

Im Network Intelligence Center können Sie die Leistung Ihrer Netzwerktopologie und Architektur einsehen. Sie erhalten detaillierte Informationen zur Netzwerkleistung und können Ihre Bereitstellung dann optimieren, um Engpässe in Ihrem Dienst zu vermeiden. Konnektivitätstests bieten Einblicke in die Firewallregeln und -richtlinien, die auf den Netzwerkpfad angewendet werden.

Weitere Informationen zum Monitoring finden Sie unter Logging- und Erkennungskontrollen implementieren.

Nächste Schritte

Weitere Informationen zur Netzwerksicherheit finden Sie in den folgenden Ressourcen:

• Datensicherheit implementieren (nächstes Dokument in dieser Reihe)
• Best Practices und Referenzarchitekturen für das VPC-Design
• IAM-Rollen für die Verwaltung von VPC Service Controls
• Als Security Command Center-Partner anmelden
• Sicherheitslücken und Bedrohungen im Security Command Center ansehen
• Packet Mirroring: Visualize and protect your cloud network
• Paketspiegelung für die Einbruchserkennung verwenden
• Paketspiegelung mit einer Partner-IDS-Lösung verwenden

Datensicherheit implementieren

Dieses Dokument des Google Cloud-Architektur-Frameworks enthält Best Practices für die Implementierung der Datensicherheit.

Berücksichtigen Sie als Teil Ihrer Deployment-Architektur, welche Daten Sie in Google Cloud verarbeiten und speichern möchten und wie vertraulich die Daten sind. Entwerfen Sie Ihre Steuerelemente so, dass die Daten während ihres Lebenszyklus gesichert werden, die Eigentümerschaft und Klassifizierung von Daten identifiziert und Daten vor unbefugter Verwendung geschützt werden.

Ein Sicherheits-Blueprint, der ein BigQuery-Data Warehouse mit den in diesem Dokument beschriebenen Best Practices für die Sicherheit bereitstellt, finden Sie unter BigQuery-Data Warehouse zum Speichern vertraulicher Daten sichern.

Daten automatisch klassifizieren

Führen Sie die Datenklassifizierung so früh wie möglich im Lebenszyklus der Datenverwaltung durch, idealerweise beim Erstellen. Normalerweise sind für die Datenklassifizierung nur wenige Kategorien erforderlich. Beispiele:

• Öffentlich: Daten, die für den öffentlichen Zugriff genehmigt wurden.
• Intern: Nicht vertrauliche Daten, die nicht veröffentlicht wurden.
• Vertraulich: Vertrauliche Daten, die für die allgemeine interne Verteilung verfügbar sind.
• Eingeschränkt: Hochsensible oder regulierte Daten, die eine eingeschränkte Verteilung erfordern.

Verwenden Sie den Schutz sensibler Daten, um Daten in Ihrer Google Cloud-Umgebung zu ermitteln und zu klassifizieren. Schutz sensibler Daten bietet integrierte Unterstützung für das Scannen und Klassifizieren sensibler Daten in Cloud Storage, BigQuery und Datastore. Es verfügt auch über eine Streaming-API, die zusätzliche Datenquellen und benutzerdefinierte Arbeitslasten unterstützt.

Schutz sensibler Daten kann sensible Daten mithilfe von integrierten infoTypes identifizieren. Er kann sensible Elemente wie PII-Daten automatisch klassifizieren, maskieren, tokenisieren und umwandeln, um das Risiko des Erfassens, Speicherns und Verwendens von Daten zu steuern. Mit anderen Worten, sie kann in Ihre Datenlebenszyklusprozesse integriert werden, um dafür zu sorgen, dass Daten in jeder Phase geschützt sind.

Weitere Informationen finden Sie unter Personenidentifizierbare Informationen in umfangreichen Datasets mit Schutz sensibler Daten de-identifizieren und re-identifizieren.

Data Governance mithilfe von Metadaten verwalten

Data Governance ist eine Kombination aus Prozessen, die dafür sorgen, dass Daten sicher, privat, präzise, verfügbar und nutzbar sind. Obwohl Sie für die Definition einer Data Governance-Strategie für Ihre Organisation verantwortlich sind, bietet Google Cloud Tools und Technologien, mit denen Sie Ihre Strategie in die Praxis umsetzen können. Google Cloud bietet außerdem ein Framework für Data Governance (PDF) in der Cloud.

Data Catalog verwenden zum Suchen, Auswählen und Verwenden von Metadaten zur Beschreibung Ihrer Datenassets in der Cloud. Mit Data Catalog können Sie nach Datenassets suchen und dann die Assets mit Metadaten taggen. Binden Sie Data Catalog in den Schutz sensibler Daten ein, um Ihre Datenklassifizierung zu beschleunigen und vertrauliche Daten automatisch zu erkennen. Nachdem Daten getaggt wurden, können Sie mit Google Identity and Access Management (IAM) einschränken, welche Daten Nutzer über Data Catalog-Ansichten abfragen oder verwenden können.

Verwenden Sie Dataproc Metastore oder Hive Metastore, um Metadaten für Arbeitslasten zu verwalten. Data Catalog hat einen Hive-Connector, mit dem der Dienst Metadaten in einem Hive-Metastore erkennen kann.

Verwenden Sie Dataprep by Trifacta, um Regeln für die Datenqualität über eine Konsole zu definieren und zu erzwingen. Sie können Dataprep in Cloud Data Fusion oder Dataprep als eigenständigen Dienst verwenden.

Daten gemäß ihrer Lebenszyklusphase und Klassifizierung schützen

Nachdem Sie Daten im Kontext ihres Lebenszyklus definiert und anhand ihrer Vertraulichkeit und Risiken klassifiziert haben, können Sie die richtigen Sicherheitskontrollen zum Schutz zuweisen. Sie müssen dafür sorgen, dass Ihre Steuerelemente einen angemessenen Schutz bieten, Compliance-Anforderungen erfüllen und das Risiko reduzieren. Wenn Sie zur Cloud wechseln, sollten Sie Ihre aktuelle Strategie überprüfen und möglicherweise Ihre aktuellen Prozesse ändern.

In der folgenden Tabelle werden drei Merkmale einer Datensicherheitsstrategie in der Cloud beschrieben.

Merkmal	Beschreibung
Identifizierung	Machen Sie sich mit der Identität von Nutzern, Ressourcen und Anwendungen vertraut, wenn Sie Daten erstellen, ändern, speichern, verwenden, freigeben und löschen. Verwenden Sie Cloud Identity und IAM, um den Datenzugriff zu steuern. Wenn Ihre Identitäten Zertifikate erfordern, sollten Sie den Zertifizierungsstellendienst in Betracht ziehen. Weitere Informationen finden Sie unter Identität und Zugriff verwalten.
Grenze und Zugriff	Legen Sie Steuerelemente für den Zugriff auf Daten, von wem und unter welchen Umständen fest. Zugriffsgrenzen für Daten können auf folgenden Ebenen verwaltet werden: Zugriff auf Netzwerkebene mit Steuerungen wie Cloud Firewall. Weitere Informationen zu Ihrer Netzwerkebene erhalten Sie über das Network Intelligence Center. Verwenden Sie VPC Service Controls, um Perimeter zu erstellen, die die von Ihnen angegebenen Ressourcen und Daten von Diensten schützen. IAM-Zugriffssteuerungen mit IAM Weitere Informationen zum Verwalten von IAM-Rollen finden Sie unter Ressourcenhierarchien für die Zugriffssteuerung verwenden.
Sichtbarkeit	Sie können die Nutzung prüfen und Berichte erstellen, die zeigen, wie Daten kontrolliert und aufgerufen werden. Google Cloud Logging und Access Transparency bieten Einblicke in die Aktivitäten Ihrer eigenen Cloud-Administratoren und Google-Mitarbeiter. Weitere Informationen finden Sie unter Daten überwachen.

Daten verschlüsseln

Google Cloud verschlüsselt inaktive Kundendaten standardmäßig, ohne dass Sie etwas unternehmen müssen. Zusätzlich zur Standardverschlüsselung bietet Google Cloud Optionen für die Umschlagverschlüsselung und die Verwaltung von Verschlüsselungsschlüsseln. Beispielsweise werden nichtflüchtige Compute Engine-Speicher automatisch verschlüsselt, aber Sie können Ihre eigenen Schlüssel bereitstellen oder verwalten.

Sie müssen die Lösungen ermitteln, die Ihren Anforderungen für die Generierung, Speicherung und Rotation von Schlüsseln am besten entsprechen, unabhängig davon, ob Sie die Schlüssel für Ihre Speicher-, Computing- oder für Big-Data-Arbeitslasten auswählen.

Google Cloud bietet die folgenden Optionen für die Verschlüsselung und Schlüsselverwaltung:

• Vom Kunden verwaltete Verschlüsselungsschlüssel (Customer Managed Encryption Keys, CMEK). Sie können Ihre Verschlüsselungsschlüssel mit dem Cloud Key Management Service (Cloud KMS) generieren und verwalten. Verwenden Sie diese Option, wenn Sie bestimmte Anforderungen an die Schlüsselverwaltung haben, z. B. dass Verschlüsselungsschlüssel regelmäßig rotiert werden müssen.
• Vom Kunden bereitgestellte Verschlüsselungsschlüssel (CSEK, Customer-Supplied Encryption Keys). Sie können eigene Verschlüsselungsschlüssel erstellen und verwalten und sie bei Bedarf an Google Cloud senden. Verwenden Sie diese Option, wenn Sie eigene Schlüssel mit Ihrem lokalen Schlüsselverwaltungssystem generieren, um Ihren eigenen Schlüssel zu verwenden (BYOK). Wenn Sie eigene Schlüssel mit CSEK bereitstellen, repliziert Google sie und stellt sie Ihren Arbeitslasten zur Verfügung. Die Sicherheit und Verfügbarkeit von CSEK liegt jedoch in Ihrer Verantwortung, da vom Kunden bereitgestellte Schlüssel nicht in Instanzvorlagen oder in der Google-Infrastruktur gespeichert werden. Wenn Sie den Zugriff auf die Schlüssel verlieren, kann Google Sie bei der Wiederherstellung der verschlüsselten Daten nicht unterstützen. Überlegen Sie sich sorgfältig, welche Schlüssel Sie selbst erstellen und verwalten möchten. Sie können CSEK nur für die sensibelsten Informationen verwenden. Eine weitere Option besteht darin, die clientseitige Verschlüsselung Ihrer Daten durchzuführen und die verschlüsselten Daten dann in Google Cloud zu speichern, wo die Daten von Google noch einmal verschlüsselt werden.
• Schlüsselverwaltungssystem eines Drittanbieters mit Cloud External Key Manager (Cloud EKM) Cloud EKM schützt Ihre inaktiven Daten mit Verschlüsselungsschlüsseln, die in einem Drittanbieterschlüssel gespeichert und verwaltet werden und die Sie außerhalb der Google-Infrastruktur steuern. Mit dieser Methode stellen Sie sicher, dass niemand außerhalb Ihrer Organisation auf Ihre Daten zugreifen kann. Mit Cloud EKM können Sie ein sicheres HYOK-Modell (Bring Your Own Key) für die Schlüsselverwaltung erreichen. Informationen zur Kompatibilität finden Sie in der Liste der aktivierten Cloud EKM-Dienste.

Mit Cloud KMS können Sie Ihre Daten auch mit softwaregestützten Verschlüsselungsschlüsseln oder gemäß FIPS 140-2 Level 3 validierten Hardwaresicherheitsmodulen (HSMs) verschlüsseln. Wenn Sie Cloud KMS verwenden, werden Ihre kryptografischen Schlüssel in der Region gespeichert, in der Sie die Ressource bereitstellen. Cloud HSM verteilt die Anforderungen an Ihre Schlüsselverwaltung auf Regionen und bietet Redundanz und globale Verfügbarkeit von Schlüsseln.

Weitere Informationen zur Envelope-Verschlüsselung finden Sie unter Inaktive Daten in der Google Cloud Platform verschlüsseln.

Zugriff von Cloud-Administratoren auf Ihre Daten steuern

Sie können den Zugriff durch Google-Support- und technisches Personal auf Ihre Umgebung in Google Cloud steuern. Mit der Zugriffsgenehmigung können Sie explizit genehmigen, bevor Google-Mitarbeiter auf Ihre Daten oder Ressourcen in Google Cloud zugreifen. Dieses Produkt ergänzt die Sichtbarkeit, die durch Access Transparency bereitgestellt wird. Logs werden generiert, wenn Google-Mitarbeiter mit Ihren Daten interagieren. Diese Logs enthalten den Bürostandort und den Grund für den Zugriff.

Wenn Sie diese Produkte zusammen verwenden, können Sie Google erlauben, Ihre Daten aus bestimmten Gründen zu entschlüsseln.

Konfigurieren, wo Ihre Daten gespeichert werden und von wo aus Nutzer darauf zugreifen können

Mit VPC Service Controls können Sie die Netzwerkstandorte steuern, von denen Nutzer auf Daten zugreifen können. Mit diesem Produkt können Sie den Zugriff auf Nutzer in einer bestimmten Region beschränken. Sie können diese Einschränkung auch dann erzwingen, wenn der Nutzer gemäß Ihrer Google Cloud IAM-Richtlinie autorisiert ist. Mit VPC Service Controls erstellen Sie einen Dienstperimeter, der die virtuellen Grenzen definiert, von denen auf einen Dienst zugegriffen werden kann, um zu verhindern, dass Daten außerhalb dieser Grenzen verschoben werden.

Hier finden Sie weitere Informationen:

• Klassifizierung der in Cloud Storage hochgeladenen Daten automatisieren
• Data Governance in der Cloud
• Data Warehouse zu BigQuery – Data Governance
• Cloud Hive-Metastore jetzt verfügbar

Secrets mit Secret Manager verwalten

Mit Secret Manager können Sie alle Ihre Secrets an einem zentralen Ort speichern. Secrets sind Konfigurationsinformationen wie Datenbankpasswörter, API-Schlüssel oder TLS-Zertifikate. Sie können Secrets automatisch rotieren und Anwendungen so konfigurieren, dass automatisch die neueste Version eines Secrets verwendet wird. Jede Interaktion mit Secret Manager generiert ein Audit-Log, sodass Sie jeden Zugriff auf jedes Secret sehen können.

Der Schutz sensibler Daten verfügt auch über eine Kategorie von Detektoren, mit denen Sie Anmeldedaten und Secrets in Daten identifizieren können, die mit Secret Manager geschützt werden könnten.

Daten überwachen

Verwenden Sie Cloud-Audit-Logs, um Logs zu Administratoraktivitäten und Schlüsselverwendung anzuzeigen. Überwachen Sie zum Schutz Ihrer Daten Logs mit Cloud Monitoring, um die ordnungsgemäße Verwendung Ihrer Schlüssel zu gewährleisten.

Cloud Logging erfasst Google Cloud-Ereignisse und bietet Ihnen die Möglichkeit, bei Bedarf zusätzliche Quellen hinzuzufügen. Sie können Ihre Logs nach Region segmentieren, sie in Buckets speichern und benutzerdefinierten Code für die Verarbeitung von Logs einbinden. Ein Beispiel finden Sie unter Benutzerdefinierte Lösung für die automatisierte Loganalyse.

Sie können auch Logs nach BigQuery exportieren, um Sicherheits- und Zugriffsanalysen durchzuführen, um nicht autorisierte Änderungen und unangemessenen Zugriff auf die Daten Ihrer Organisation zu identifizieren.

Mit dem Security Command Center können Sie Probleme mit unsicherem Zugriff auf sensible Organisationsdaten erkennen und beheben, die in der Cloud gespeichert sind. Über eine einzige Verwaltungsoberfläche können Sie nach einer Vielzahl von Sicherheitslücken und Risiken in Ihrer Cloud-Infrastruktur suchen. Sie können beispielsweise die unbefugte Datenweitergabe überwachen, Speichersysteme nach vertraulichen Daten scannen und ermitteln, welche Cloud Storage-Buckets mit dem Internet verbunden sind.

Nächste Schritte

Weitere Informationen zur Datensicherheit finden Sie in den folgenden Ressourcen:

• Anwendungen sicher bereitstellen (nächstes Dokument in dieser Reihe)

• BigQuery-Data-Warehouse sichern, in dem vertrauliche Daten gespeichert werden

• Designing and deploying data security strategy (PDF)

• Trusting your data with Google Cloud (PDF)

• Aufbewahrungsrichtlinien und Bucket-Sperre

• Best Practices für Cloud Storage

• Best Practices für SQL-Serverinstanzen

• Best Practices für Datastore

• Data Catalog

Anwendungen sicher bereitstellen

In diesem Dokument des Google Cloud-Architektur-Frameworks werden Best Practices für die sichere Bereitstellung von Anwendungen vorgestellt.

Für die Bereitstellung sicherer Anwendungen müssen Sie einen klar definierten Lebenszyklus für die Softwareentwicklung mit entsprechenden Sicherheitsprüfungen während der Design-, Entwicklungs-, Test- und Bereitstellungsphasen haben. Beim Entwerfen von Anwendungen empfehlen wir eine mehrschichtige Systemarchitektur, die standardisierte Frameworks für die Identitäts-, Autorisierungs- und Zugriffssteuerung nutzt.

Sichere Releases automatisieren

Ohne automatisierte Tools kann es schwierig sein, komplexe Anwendungsumgebungen bereitzustellen, zu aktualisieren und zu patchen, um konsistente Sicherheitsanforderungen zu erfüllen. Daher empfehlen wir Ihnen, für diese Aufgaben eine CI/CD-Pipeline zu erstellen, die viele dieser Probleme lösen kann. Automatisierte Pipelines entfernen manuelle Fehler, bieten standardisierte Entwicklungs-Feedbackschleifen und ermöglichen schnelle Produktiterationen. Mit privaten Pools von Cloud Build können Sie beispielsweise eine hochsichere, verwaltete CI/CD-Pipeline für stark regulierte Branchen wie Finanzen und das Gesundheitswesen bereitstellen.

Sie können die Automatisierung nutzen, um beim Erstellen von Artefakten nach Sicherheitslücken zu suchen. Sie können auch Richtlinien für verschiedene Umgebungen (Entwicklung, Test, Produktion usw.) definieren, damit nur verifizierte Artefakte bereitgestellt werden.

Garantieren, dass Anwendungsbereitstellungen genehmigten Prozessen folgen

Wenn ein Angreifer Ihre CI/CD-Pipeline manipuliert, kann sich dies auf Ihren gesamten Stack auswirken. Zum Sichern der Pipeline sollten Sie einen festgelegten Genehmigungsprozess erzwingen, bevor Sie den Code in der Produktion bereitstellen.

Wenn Sie Google Kubernetes Engine (GKE) oder GKE Enterprise verwenden möchten, können Sie diese Prüfungen und Balancings mithilfe der Binärautorisierung einrichten. Die Binärautorisierung hängt konfigurierbare Signaturen an Container-Images an. Diese Signaturen (auch Attestierungen genannt) helfen, das Image zu validieren. Bei der Bereitstellung verwendet die Binärautorisierung diese Attestierungen, um zu ermitteln, ob ein Prozess zuvor abgeschlossen wurde. Sie können die Binärautorisierung beispielsweise für Folgendes verwenden:

• Prüfen Sie, ob eine bestimmte Build-System- oder CI-Pipeline (Container Integration) ein Container-Image erstellt hat.
• Prüfen Sie, ob ein Container-Image mit einer Signaturrichtlinie für Sicherheitslücken kompatibel ist.
• Prüfen Sie, ob ein Container-Image die Kriterien für das Hochstufen in die nächste Bereitstellungsumgebung erfüllt, z. B. von Entwicklung zu QA.

Vor der Bereitstellung nach bekannten Sicherheitslücken scannen

Es wird empfohlen, automatisierte Tools zu nutzen, die kontinuierlich auf Sicherheitslücken für Container-Images scannen können, bevor Container für die Produktion bereitgestellt werden.

Mit Artefaktanalyse automatisch nach Sicherheitslücken für Container suchen, die in Artifact Registry und Container Registry gespeichert sind. Dieser Vorgang umfasst zwei Aufgaben: Scannen und kontinuierliche Analyse.

Als Erstes scannt Artefaktanalyse neue Images, sobald diese in Artifact Registry oder Container Registry hochgeladen werden. Bei diesem Scan werden Informationen zu den Systempaketen im Container extrahiert.

Artefaktanalyse sucht dann während des Hochladens des Image nach Sicherheitslücken. Nach dem ersten Scan überwacht Artefaktanalyse kontinuierlich die Metadaten gescannter Images in Artifact Registry und Container Registry auf neue Sicherheitslücken. Wenn Artefaktanalyse neue und aktualisierte Informationen zu Sicherheitslücken aus den entsprechenden Quellen erhält, führt es folgende Schritte aus:

• Aktualisiert die Metadaten der gescannten Bilder, um sie auf dem neuesten Stand zu halten.
• Erstellt neue Vorkommen von Sicherheitslücken für neue Hinweise.
• Löscht Vorkommen von Sicherheitslücken, die nicht mehr gültig sind.

Anwendungscode auf bekannte Sicherheitslücken überwachen

Es empfiehlt sich, automatisierte Tools zu verwenden, die Ihren Anwendungscode ständig auf bekannte Sicherheitslücken wie die OWASP Top 10 überwachen. Eine Beschreibung der Google Cloud-Produkte und -Features, die OWASP-Top-10-Abhilfemaßnahmen unterstützen, finden Sie unter OWASP-Top-10-Abhilfemaßnahmen in Google Cloud.

Mit dem Web Security Scanner können Sie Sicherheitslücken in Ihren App Engine-, Compute Engine- und Google Kubernetes Engine-Webanwendungen identifizieren. Der Scanner durchsucht Ihre Anwendung, folgt dabei allen Links im Bereich der Start-URLs und versucht, so viele Nutzereingaben und Event-Handler wie möglich anzuwenden. Er kann automatisch nach allgemeinen Sicherheitslücken suchen und diese erkennen, einschließlich Cross-Site-Scripting (XSS), Flash Injection, gemischtem Inhalt (HTTP in HTTPS) und veralteter oder unsicherer Bibliotheken. Der Web Security Scanner ermöglicht Ihnen eine frühzeitige Identifizierung solcher Sicherheitslücken bei nur wenigen falsch positiven Ergebnissen.

Die Bewegung von Daten über Perimeter hinweg steuern

Um die Bewegung von Daten über einen Perimeter zu steuern, können Sie Sicherheitsperimeter für die Ressourcen Ihrer von Google verwalteten Dienste konfigurieren. Mit VPC Service Controls können Sie alle Komponenten und Dienste in Ihrer CI/CD-Pipeline (z. B. Container Registry, Artifact Registry, Artefaktanalyse und Binärautorisierung) innerhalb eines Sicherheitsperimeters platzieren.

Mit VPC Service Controls verringern Sie das Risiko unerlaubten Kopierens oder unbefugten Übertragens von Daten (Daten-Exfiltration) aus von Google verwalteten Diensten. Sie können Sicherheitsperimeter für die Ressourcen Ihrer von Google verwalteten Dienste konfigurieren und die Übertragung von Daten in und aus dem Perimeter steuern. Wenn ein Dienstperimeter erzwungen wird, werden Anfragen, die gegen die Perimeterrichtlinie verstoßen, abgelehnt, darunter Anfragen an geschützte Dienste von außerhalb eines Perimeters. Wenn ein Dienst durch einen erzwungenen Perimeter geschützt ist, garantiert VPC Service Controls Folgendes:

• Ein Dienst kann keine Daten über die Perimetergrenzen hinaus übertragen. Innerhalb des Perimeters funktionieren geschützte Dienste wie gewohnt, es können jedoch keine Ressourcen und Daten außerhalb des Perimeters gesendet werden. Diese Einschränkung verhindert, dass böswillige Insider, die möglicherweise Zugriff auf Projekte innerhalb des Perimeters haben, Daten unbefugt weitergeben.
• Anfragen von außerhalb des Perimeters an den geschützten Dienst werden nur akzeptiert, wenn die Anfragen die Kriterien der Zugriffsebenen erfüllen, die dem Perimeter zugewiesen wurden.
• Ein Dienst kann über Perimeter-Bridges für Projekte in anderen Perimetern zugänglich gemacht werden.

Container-Images verschlüsseln

In Google Cloud können Sie Ihre Container-Images mit kundenverwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEKs) verschlüsseln. CMEK-Schlüssel werden vom Cloud Key Management Service (Cloud KMS) verwaltet. Wenn Sie CMEK verwenden, können Sie den Zugriff auf ein verschlüsseltes Container-Image vorübergehend oder dauerhaft deaktivieren, indem Sie den Schlüssel deaktivieren oder löschen.

Nächste Schritte

Hier erfahren Sie mehr über die Sicherung Ihrer Lieferkette und die Anwendungssicherheit:

• Compliance-Verpflichtungen verwalten (nächstes Dokument in dieser Reihe)
• Operative Exzellenz
• Binärautorisierung
• Artefaktanalyse
• Artifact Registry

Gesetzliche Verpflichtungen verwalten

Dieses Dokument des Google Cloud-Architektur-Frameworks enthält Best Practices zur Verwaltung von gesetzlichen Verpflichtungen.

Die aufsichtsrechtlichen Anforderungen an Ihre Cloud hängen von einer Kombination von Faktoren ab, darunter:

• Die Gesetze und Bestimmungen, die die physischen Standorte Ihrer Organisation betreffen.
• Die Gesetze und Bestimmungen, die für die physischen Standorte Ihrer Kunden gelten.
• Die aufsichtsrechtlichen Anforderungen Ihrer Branche.

Diese Anforderungen bestimmen viele der Entscheidungen, die Sie hinsichtlich der Sicherheitskontrollen treffen müssen, die für Ihre Arbeitslasten in Google Cloud aktiviert werden sollen.

Ein typisches Compliance-Verfahren besteht aus drei Phasen: Bewertung, Lückenbeseitigung und kontinuierliches Monitoring. In diesem Abschnitt werden die Best Practices beschrieben, die Sie in jeder Phase anwenden können.

Compliance-Anforderungen ermitteln

Die Compliance-Bewertung beginnt mit einer gründlichen Prüfung aller regulatorischen Verpflichtungen und ihrer Implementierung in Ihrem Unternehmen. Verwenden Sie das Center für Compliance-Ressourcen, um Hilfe bei der Bewertung von Google Cloud-Diensten zu erhalten. Auf dieser Website finden Sie Details zu folgenden Themen:

• Dienstunterstützung für verschiedene Vorschriften
• Google Cloud-Zertifizierungen und -Attestierungen

Sie können auch Kontakt zu einem Compliance-Experten von Google anfordern, um den Compliance-Lebenszyklus bei Google besser zu verstehen und zu ermitteln, wie Ihre Anforderungen erfüllt werden können.

Weitere Informationen finden Sie unter Compliance in der Cloud gewährleisten (PDF).

Assured Workloads bereitstellen

Assured Workloads ist das Google Cloud-Tool, das auf den Einstellungen in Google Cloud basiert und Ihnen hilft, Ihre Compliance-Verpflichtungen zu erfüllen. Assured Workloads bietet folgende Möglichkeiten:

• Wählen Sie Ihre Compliance-Richtlinie aus. Das Tool legt dann die grundlegenden Zugriffsrechte für Mitarbeiter automatisch fest.
• Legen Sie den Speicherort für Ihre Daten mithilfe von Organisationsrichtlinien fest, damit Ihre ruhenden Daten und Ihre Ressourcen in dieser Region verbleiben.
• Wählen Sie die Option zur Schlüsselverwaltung (z. B. den Schlüsselrotationszeitraum) aus, die Ihren Sicherheits- und Compliance-Anforderungen am besten entspricht.
• Wählen Sie für bestimmte aufsichtsrechtliche Anforderungen wie FedRAMP Moderate die Kriterien für den Zugriff durch Google-Supportmitarbeiter aus (z. B. ob die entsprechenden Zuverlässigkeitsüberprüfungen abgeschlossen sind).
• Von Google verwaltete Verschlüsselungsschlüssel müssen FIPS-140-2-konform sein und die FedRAMP Moderate-Compliance unterstützen. Für eine zusätzliche Kontrollebene und Aufgabentrennung können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) verwenden. Weitere Informationen zu Schlüsseln finden Sie unter Daten verschlüsseln.

Blueprints für Vorlagen und Best Practices prüfen, die für Ihre Compliance-Richtlinie gelten

Google hat Blueprints und Lösungsleitfäden veröffentlicht, die Best Practices beschreiben und Terraform-Module bereitstellen, mit denen Sie eine Umgebung bereitstellen können, die Sie beim Erreichen der Compliance unterstützt. Die folgende Tabelle enthält eine Auswahl von Blueprints, die die Sicherheit und die Einhaltung von Compliance-Anforderungen betreffen.

Standard	Beschreibung
PCI	Sicherheits-Blueprint: PCI in GKE Compliance mit dem PCI-Datensicherheitsstandard Geltungsbereich der Compliance für PCI-Umgebungen in Google Cloud verringern PCI-DSS-Compliance in GKE
FedRAMP	Google Cloud FedRAMP-Implementierungsleitfaden (PDF) Dreistufige FedRAMP-konforme Arbeitslast in Google Cloud einrichten
HIPAA	PDF „Protecting healthcare data on Google Cloud“ HIPAA-konforme Arbeitslast mit Data Protection Toolkit einrichten (PDF)

Compliance überwachen

Bei den meisten Vorschriften müssen Sie bestimmte Aktivitäten, einschließlich des Zugriffs, überwachen. Folgendes können Sie beim Monitoring als Hilfe verwenden:

• Access Transparency bietet Logs nahezu in Echtzeit, wenn Google Cloud-Administratoren auf Ihre Inhalte zugreifen.
• Logging von Firewallregeln zum Aufzeichnen von TCP- und UDP-Verbindungen in einem VPC-Netzwerk für alle Regeln, die Sie selbst erstellen. Diese Logs können nützlich sein, um den Netzwerkzugriff zu prüfen oder frühzeitig auf eine unzulässige Netzwerknutzung hinzuweisen.
• VPC-Flusslogs zum Aufzeichnen von Netzwerk-Traffic, der von VM-Instanzen gesendet oder empfangen wird.
• Security Command Center Premium zur Überwachung der Compliance mit verschiedenen Standards.
• OSSEC (oder ein anderes Open-Source-Tool) zum Logging der Aktivität von Personen mit Administratorzugriff auf die Umgebung.
• Key Access Justifications, um die Gründe für eine Schlüsselzugriffsanfrage aufzurufen.

Compliance automatisieren

Prüfen Sie, ob es Möglichkeiten gibt, Ihre Sicherheitsrichtlinien zu automatisieren, indem Sie sie als Code-Deployments in Ihre Infrastruktur einbinden, um die Einhaltung von gesetzlichen Vorschriften zu gewährleisten. Sie könnten beispielsweise Folgendes versuchen:

• Verwenden Sie Sicherheits-Blueprints, um Ihre Sicherheitsrichtlinien in Ihre Infrastrukturbereitstellungen zu integrieren.

• Konfigurieren Sie Security Command Center so, dass Benachrichtigungen gesendet werden, wenn Probleme mit der Compliance auftreten. Achten Sie zum Beispiel auf Probleme wie die Deaktivierung der zweistufigen Verifizierung durch Nutzer oder überprivilegierte Dienstkonten. Weitere Informationen finden Sie unter Benachrichtigungen einrichten.

• Richten Sie die automatische Korrektur für bestimmte Benachrichtigungen ein. Weitere Informationen finden Sie im Cloud Functions-Code.

Weitere Informationen zur Compliance-Automatisierung finden Sie in der RCaC-Lösung (Risiko und Compliance).

Nächste Schritte

Weitere Informationen zur Compliance finden Sie in den folgenden Ressourcen:

• Anforderungen an den Datenstandort und die Datenhoheit umsetzen (nächstes Dokument in dieser Reihe)
• Center für Compliance-Ressourcen
• Whitepaper zum Thema Sicherheit bei Google (PDF)
• Assured Workloads

Anforderungen an den Datenstandort und die Datenhoheit umsetzen

Dieses Dokument des Google Cloud-Architektur-Frameworks beschreibt Best Practices für die Umsetzung von Anforderungen im Hinblick auf Datenstandort und Datenhoheit.

Die Anforderungen an den Datenstandort und die Datenhoheit richten sich nach Ihren regionalen und branchenspezifischen Vorschriften. Unterschiedliche Organisationen haben möglicherweise unterschiedliche Anforderungen hinsichtlich der Datenhoheit. Beispiel: Es gelten möglicherweise die folgenden Anforderungen:

• Kontrolle über den gesamten Zugriff auf Ihre Daten durch Google Cloud, einschließlich Informationen über die Art des zugriffsberechtigten Personals und die Region, über die der Zugriff erfolgt.
• Überprüfbarkeit von Änderungen an der Cloud-Infrastruktur und den Diensten, die sich auf den Zugriff auf Ihre Daten oder die Sicherheit Ihrer Daten auswirken können. Diese Arten von Änderungen zu verstehen, trägt dazu bei, dass Google Cloud die Kontrollen nicht umgehen oder Ihre Daten aus der Region verschieben kann.
• Beständigkeit Ihrer Arbeitslasten über einen längeren Zeitraum, wenn Sie keine Softwareupdates von Google Cloud erhalten können.

Datenhoheit verwalten

Datenhoheit bietet Ihnen einen Mechanismus, durch den Google nicht auf Ihre Daten zugreifen kann. Sie genehmigen den Zugriff nur für Anbieterverhalten, dem Sie zustimmen.

Beispielsweise können Sie Ihre Datenhoheit so verwalten:

• Verschlüsselungsschlüssel in der Cloud speichern und verwalten
• Zugang auf diese Schlüssel nur basierend auf detaillierten Zugriffsbegründungen gewähren
• Aktive Daten schützen

Betriebshoheit verwalten

Die Betriebshoheit sorgt dafür, dass Google-Mitarbeiter Ihre Arbeitslasten nicht beeinträchtigen können.

Beispielsweise können Sie die Betriebshoheit auf folgende Weise verwalten:

• Bereitstellung neuer Ressourcen auf bestimmte Anbieterregionen beschränken
• Zugriff von Google-Mitarbeitern anhand vordefinierter Attribute wie der Staatsbürgerschaft oder dem geografischen Standort beschränken

Softwarehoheit verwalten

Die Softwarehoheit bietet Ihnen die Sicherheit, dass Sie die Verfügbarkeit Ihrer Arbeitslasten steuern und sie überall ausführen können, ohne an einen einzelnen Cloud-Anbieter abhängig zu sein (oder an ihn gebunden zu sein). Die Softwarehoheit umfasst die Fähigkeit, Ereignisse zu überstehen, bei denen Sie schnell ändern müssen, wo Ihre Arbeitslasten bereitgestellt werden und welches Maß an externer Verbindung zulässig ist.

Google Cloud unterstützt beispielsweise Hybrid- und Multi-Cloud-Bereitstellungen. Darüber hinaus können Sie mit GKE Enterprise Ihre Anwendungen sowohl in Cloud- als auch in lokalen Umgebungen verwalten und bereitstellen.

Datenstandort steuern

Mit Datenstandort wird beschrieben, wo Ihre inaktiven Daten gespeichert werden. Die Anforderungen an den Datenstandort hängen von den Zielsetzungen von Systemdesigns, branchenüblichen Vorschriften, nationalen Gesetzen, Steuerbelangen und sogar der Kultur ab.

Die Steuerung des Datenstandorts beginnt mit Folgendem:

• Datentyp und deren Speicherort verstehen
• Bestimmen, welche Risiken für Ihre Daten bestehen und welche Gesetze und Vorschriften gelten
• Steuern, wo sich Daten befinden oder wohin sie übertragen werden

Um die Anforderungen an den Datenstandort zu erfüllen, können Sie in Google Cloud steuern, wo Ihre Daten gespeichert werden, wie auf sie zugegriffen wird und wie sie verarbeitet werden. Mit Richtlinien für Ressourcenstandorte können Sie einschränken, wo Ressourcen erstellt werden, und begrenzen, wo Daten zwischen Regionen repliziert werden. Mit dem Standortattribut einer Ressource lässt sich angeben, wo der Dienst bereitgestellt wird und wer ihn verwaltet.

Weitere Support-Informationen finden Sie unter Unterstützte Dienste für Ressourcenstandorte.

Nächste Schritte

Weitere Informationen zum Datenstandort und zur Datenhoheit finden Sie in den folgenden Ressourcen:

• Datenschutzanforderungen umsetzen (nächstes Dokument in dieser Reihe)
• Data residency, operational transparency, and privacy for European customers on Google Cloud (PDF)
• Designing and deploying data security strategy (PDF)
• Cloud Key Management Service
• Trusting your data with Google Cloud (PDF)
• Privilegierter Zugriff bei Google
• Google Cloud Access Transparency

Datenschutzanforderungen implementieren

Dieses Dokument im Google Cloud-Architektur-Framework enthält Best Practices zur Implementierung von Datenschutzanforderungen.

Datenschutzbestimmungen definieren, wie Sie die Daten Ihrer Nutzer abrufen, verarbeiten, speichern und verwalten können. Viele Datenschutzeinstellungen (z. B. Steuerelemente für Cookies, Sitzungsverwaltung und Erhalt von Nutzerberechtigungen) liegen in Ihrer Verantwortung, da Sie Inhaber Ihrer Daten sind (einschließlich der Daten, die Sie von Ihren Nutzern erhalten).

Google Cloud umfasst die folgenden Kontrollen, die den Datenschutz fördern:

• Standardverschlüsselung aller Daten, wenn sie inaktiv sind, übertragen werden und während sie verarbeitet werden.
• Schutzmaßnahmen vor Insiderzugriffen.
• Unterstützung zahlreicher Datenschutzbestimmungen.

Weitere Informationen finden Sie unter Datenschutzverpflichtungen von Google Cloud.

Vertrauliche Daten klassifizieren

Sie müssen festlegen, welche Daten vertraulich sind, und dann gewährleisten, dass die vertraulichen Daten ordnungsgemäß geschützt sind. Vertrauliche Daten können Kreditkartennummern, Adressen, Telefonnummern und andere personenidentifizierbare Informationen sein.

Mit dem Schutz sensibler Daten können Sie geeignete Klassifizierungen einrichten. Sie können dann Ihre Daten taggen und tokenisieren, bevor Sie sie in Google Cloud speichern. Weitere Informationen finden Sie unter Daten automatisch klassifizieren.

Zugriff auf sensible Daten sperren

Platzieren Sie vertrauliche Daten mit VPC Service Controls in einem eigenen Dienstperimeter und legen Sie die Zugriffssteuerung von Google Identity and Access Management (IAM) für diese Daten fest. Konfigurieren Sie die Multi-Faktor-Authentifizierung (MFA) für alle Nutzer, die Zugriff auf vertrauliche Daten benötigen.

Weitere Informationen finden Sie unter Datenverschiebung zwischen Perimetern steuern und SSO und MFA einrichten.

Auf Phishing-Angriffe überwachen

Achten Sie darauf, dass Ihr E-Mail-System zum Schutz vor Phishing-Angriffen konfiguriert ist, die häufig für Betrugs- und Malware-Angriffe verwendet werden.

Wenn Ihre Organisation Gmail verwendet, können Sie erweiterten Phishing- und Malware-Schutz verwenden. Diese Sammlung von Einstellungen bietet Kontrollen zur Quarantäne von E-Mails, schützt vor ungewöhnlichen Anhangstypen und schützt vor eingehenden Spoofing-E-Mails. Die Sicherheits-Sandbox erkennt Malware in Anhängen. Gmail wird kontinuierlich und automatisch mit den neuesten Sicherheitsverbesserungen und Schutzfunktionen aktualisiert, um die E-Mail-Sicherheit Ihrer Organisation zu schützen.

Zero-Trust-Sicherheit für hybride Mitarbeiter erweitern

Ein Zero-Trust-Sicherheitsmodell bedeutet, dass niemand implizit als vertrauenswürdig eingestuft wird, unabhängig davon, ob es sich innerhalb oder außerhalb des Netzwerks Ihrer Organisation befindet. Wenn Ihre IAM-Systeme Zugriffsanfragen überprüfen, bedeutet ein Zero-Trust-Sicherheitsstatus, dass die Identität des Nutzers und der Kontext (z. B. seine IP-Adresse oder sein Standort) berücksichtigt werden. Im Gegensatz zu einem VPN verschiebt die Zero-Trust-Sicherheit die Zugriffssteuerungen vom Netzwerkperimeter auf Nutzer und deren Geräte. Zero-Trust-Sicherheit ermöglicht es Nutzern, von überall aus sicherer zu arbeiten. Beispielsweise können Nutzer über ihre Laptops oder Mobilgeräte von zu Hause aus auf die Ressourcen Ihrer Organisation zugreifen.

In Google Cloud können Sie BeyondCorp Enterprise und Identity-Aware Proxy (IAP) konfigurieren, um Zero-Trust für Ihre Google Cloud-Ressourcen zu aktivieren. Wenn Ihre Nutzer Google Chrome verwenden und BeyondCorp Enterprise aktivieren, können Sie Zero-Trust-Sicherheit in die Nutzerbrowser einbinden.

Nächste Schritte

Hier finden Sie weitere Informationen zu Sicherheit und Datenschutz:

• Logging- und Erkennungskontrollen implementieren (nächstes Dokument in dieser Reihe)
• Datenschutz-Center

• Google Cloud-Datenschutzhinweise

• Best Practices für den Datenschutz bei Interaktionen mit dem Google Cloud-Support

• Wie Google in Ihrer Organisation Sicherheit und Datenschutz bietet

• Häufig gestellte Fragen zum Datenschutz

Logging- und Erkennungskontrollen implementieren

Dieses Dokument im Google Cloud-Architektur-Framework enthält Best Practices für die Implementierung von Logging- und Erkennungskontrollen.

Erkennungskontrollen verwenden Telemetrie, um Fehlkonfigurationen, Sicherheitslücken und potenziell schädliche Aktivitäten in einer Cloudumgebung zu erkennen. Mit Google Cloud können Sie maßgeschneiderte Monitoring- und Erkennungskontrollen für Ihre Umgebung erstellen. In diesem Abschnitt werden diese zusätzlichen Features und Empfehlungen für ihre Verwendung beschrieben.

Netzwerkleistung überwachen

Im Network Intelligence Center erhalten Sie Einblick in die Leistung Ihrer Netzwerktopologie und Architektur. Sie erhalten detaillierte Informationen zur Netzwerkleistung und können diese Informationen dann zur Optimierung Ihrer Bereitstellung nutzen und so Engpässe in Ihren Diensten vermeiden. Konnektivitätstests bieten Einblicke in die Firewallregeln und -richtlinien, die auf den Netzwerkpfad angewendet werden.

Daten-Exfiltration überwachen und verhindern

Die unbefugte Datenweitergabe ist für Unternehmen ein wichtiges Problem. In der Regel geschieht das, wenn eine autorisierte Person Daten aus einem gesicherten System extrahiert und diese Daten dann an eine nicht autorisierte Partei weitergibt oder in ein unsicheres System verschiebt.

Google Cloud bietet verschiedene Features und Tools, mit denen Sie Daten-Exfiltration erkennen und verhindern können. Weitere Informationen finden Sie unter Daten-Exfiltration verhindern.

Monitoring zentralisieren

Das Security Command Center bietet Einblick in die Ressourcen in Google Cloud und deren Sicherheitsstatus. Mit Security Command Center können Sie Bedrohungen verhindern, erkennen und darauf reagieren. Es bietet ein zentrales Dashboard, mit dem Sie Sicherheitsfehlkonfigurationen in virtuellen Maschinen, in Netzwerken, Anwendungen und in Storage-Buckets identifizieren können. Sie können diese Probleme beheben, bevor sie zu Schäden oder Verlusten für das Unternehmen führen. Die integrierten Funktionen von Security Command Center können verdächtige Aktivitäten in Ihren Cloud Logging-Sicherheitslogs anzeigen oder auf manipulierte virtuelle Maschinen hinweisen.

Sie können auf Bedrohungen reagieren, wenn Sie die Handlungsempfehlungen befolgen oder Logs in Ihr SIEM exportieren, um sie näher zu untersuchen. Informationen zur Verwendung eines SIEM-Systems mit Google Cloud finden Sie unter Sicherheitsloganalysen in Google Cloud.

Security Command Center bietet außerdem mehrere Detektoren, mit denen Sie die Sicherheit Ihrer Infrastruktur analysieren können. Zu diesen Detektoren gehören:

• Event Threat Detection
• Security Health Analytics (SHA)
• Sensitive Actions Service

Andere Google Cloud-Dienste wie Google Cloud Armor-Logs liefern ebenfalls Ergebnisse für die Anzeige im Security Command Center.

Aktivieren Sie die Dienste, die Sie für Ihre Arbeitslasten benötigen, und überwachen und analysieren Sie dann nur wichtige Daten. Weitere Informationen zum Aktivieren von Logging für Dienste finden Sie im Abschnitt Logs aktivieren von Sicherheitsloganalysen in Google Cloud.

Auf Bedrohungen überwachen

Event Threat Detection ist ein optionaler verwalteter Dienst von Security Command Center Premium, der Bedrohungen in Ihrem Logstream erkennt. Mithilfe von Event Threat Detection können Sie riskante und kostspielige Bedrohungen wie Malware, Kryptomining, nicht autorisierten Zugriff auf Google Cloud-Ressourcen, DDoS-Angriffe und Brute-Force-SSH-Angriffe erkennen. Mithilfe der Features des Tools, mit denen die Menge von Logdaten generiert wird, können Ihre Sicherheitsteams Vorfälle mit hohem Risiko schnell erkennen und sich auf die Behebung konzentrieren.

Um potenziell gefährdete Nutzerkonten in Ihrem Unternehmen aufzuspüren, verwenden Sie die Sensitive Actions Cloud Platform-Logs, um festzustellen, wann sensible Aktionen durchgeführt werden, und um zu bestätigen, dass gültige Nutzer diese Aktionen für gültige Zwecke durchgeführt haben. Eine sensible Aktion ist eine Aktion, z. B. das Hinzufügen einer Rolle mit umfangreichen Berechtigungen, die Ihrem Unternehmen schädigen könnte, wenn ein böswilliger Akteur die Aktion ausführt. Verwenden Sie Cloud Logging, um die Cloud Platform-Logs mit vertraulichen Aktionen anzuzeigen, zu überwachen und abzufragen. Sie können sich die vertraulichen Aktionslogeinträge auch mit dem Sensitive Actions Service ansehen, einem integrierten Dienst von Security Command Center Premium.

Chronicle kann alle Ihre Sicherheitsdaten zentral speichern und analysieren. Damit Sie den gesamten Umfang eines Angriffs sehen können, kann Chronicle die Logs einem gemeinsamen Modell zuordnen, sie anreichern und dann in Zeitachsen zusammenfassen. Sie können Chronicle verwenden, um Erkennungsregeln zu erstellen, den Abgleich von Kompromittierungsindikatoren (IoC) einzurichten und Aktivitäten zur Bedrohungssuche auszuführen. Sie schreiben Ihre Erkennungsregeln in der YARA-L-Sprache. Beispiele für Bedrohungserkennungsregeln in YARA-L finden Sie im Repository Community Security Analytics (CSA). Sie können nicht nur Ihre eigenen Regeln schreiben, sondern auch die abgestimmten Erkennungsmechanismen in Chronicle nutzen. Diese abgestimmten Erkennungsmechanismen sind vordefinierte und verwaltete YARA-L-Regeln, mit denen Sie Bedrohungen identifizieren können.

Eine weitere Möglichkeit zur Zentralisierung Ihrer Logs für Sicherheitsanalysen, -audits und -prüfungen ist die Verwendung von BigQuery. In BigQuery beobachten Sie häufige Bedrohungen oder Fehlkonfigurationen mithilfe von SQL-Abfragen (z. B. im CSA-Repository), um Berechtigungsänderungen, Bereitstellungsaktivitäten, Arbeitslastnutzung, Datenzugriffe und Netzwerkaktivitäten zu analysieren. Weitere Informationen zu Sicherheitsloganalysen in BigQuery von der Einrichtung über die Analyse finden Sie unter Sicherheitsloganalysen in Google Cloud.

Das folgende Diagramm zeigt, wie Sie das Monitoring mithilfe der integrierten Bedrohungserkennungsfunktionen von Security Command Center und der Bedrohungserkennung in BigQuery, Chronicle oder einer SIEM-Lösung eines Drittanbieters zentralisieren können. “

Wie im Diagramm dargestellt, sollten Sie verschiedene Sicherheitsdatenquellen überwachen. Zu diesen Datenquellen gehören Logs aus Cloud Logging, Assetänderungen aus Cloud Asset Inventory, Google Workspace-Logs oder Ereignisse von Hypervisor oder einem Gast-Kernel. Das Diagramm zeigt, dass Sie diese Datenquellen mit Security Command Center überwachen können. Dieses Monitoring erfolgt automatisch, wenn Sie die entsprechenden Features und Bedrohungsdetektoren in Security Command Center aktiviert haben. Das Diagramm zeigt, dass Sie auch auf Bedrohungen überwachen können. Exportieren Sie dazu Sicherheitsdaten und Security Command Center-Ergebnisse in ein Analysetool wie BigQuery, Chronicle oder ein SIEM eines Drittanbieters. Das Diagramm in Ihrem Analysetool zeigt, dass Sie weitere Analysen und Untersuchungen durchführen können, indem Sie Abfragen und Regeln, wie die in CSA verfügbaren, verwenden und erweitern.

Nächste Schritte

Weitere Informationen zum Logging und zur Erkennung finden Sie in den folgenden Ressourcen:

• Cloud Logging

• Introducing Chronicle Detect from Google Cloud (Blog)

• Gemeinsamen Prozess für Vorfallmanagement aufbauen

Google Cloud-Architektur-Framework: Zuverlässigkeit

In diesem Abschnitt des Google Cloud-Architektur-Frameworks wird beschrieben, wie Sie zuverlässige Dienste auf einer Cloud-Plattform entwerfen und betreiben. Außerdem lernen Sie einige der Google Cloud-Produkte und -Features kennen, die Zuverlässigkeit unterstützen.

Im Architektur-Framework werden Best Practices beschrieben, Implementierungsempfehlungen gegeben und einige verfügbare Produkte und Dienste erläutert. Mit dem Framework unterstützen wir Sie bei der Entwicklung Ihrer Google Cloud-Bereitstellung, um den Anforderungen Ihres Unternehmens bestmöglich gerecht zu werden.

Ihre Architektur muss folgende Elemente enthalten, um einen zuverlässigen Dienst ausführen zu können:

• Messbare Zuverlässigkeitsziele mit von Ihnen unmittelbar korrigierten Abweichungen.
• Designmuster für Skalierbarkeit, Hochverfügbarkeit, Notfallwiederherstellung und automatisiertes Änderungsmanagement
• Komponenten, die sich nach Möglichkeit selbst reparieren können, und Code, der eine Instrumentierung für die Beobachtbarkeit enthält
• Betriebsabläufe, die den Dienst mit einem minimalen manuellen Aufwand und geringer Arbeitslast für die ausführenden Personen ausführen, und bei denen Sie Fehler schnell erkennen und beheben können.

Die Zuverlässigkeit liegt in der Verantwortung aller an der Entwicklung Beteiligten, z. B. im Entwicklungs-, Produktmanagement-, Betriebs- und Site Reliability Engineering-Team (SRE). Jeder muss Verantwortung übernehmen und die Zuverlässigkeitsziele der Anwendung sowie die Risiko- und Fehlerbudgets verstehen. Teams sollten in der Lage sein, Aufgaben entsprechend zu priorisieren und Prioritätskonflikte zwischen Zuverlässigkeit und Produktfeature-Entwicklung zu eskalieren.

Im Abschnitt zur Zuverlässigkeit des Architektur-Frameworks lernen Sie Folgendes:

• Grundlagen der Zuverlässigkeit verstehen
• Zuverlässigkeitsziele definieren
• SLOs definieren
• SLOs übernehmen
• Für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen sorgen
• Bei der Entwicklung für Skalierung und Hochverfügbarkeit sorgen
• Zuverlässige operative Prozesse und Tools erstellen
• Effiziente Benachrichtigungen erstellen
• Gemeinsamen Prozess für Vorfallmanagement aufbauen

Grundsätze für Zuverlässigkeit

In diesem Dokument des Google Cloud-Architektur-Frameworks werden einige der Grundprinzipien für die Ausführung zuverlässiger Dienste auf einer Cloud-Plattform erläutert. Diese Prinzipien helfen Ihnen, ein allgemeines Verständnis zu erreichen, wenn Sie zusätzliche Abschnitte des Architektur-Frameworks lesen. Diese zeigen Ihnen, wie einige der Google Cloud-Produkte und -Features zuverlässige Dienste unterstützen.

Schlüsselterminologie

Im Zusammenhang mit Zuverlässigkeitspraktiken gibt es mehrere gängige Begriffe. Diese werden vielen Lesern bekannt vorkommen. Eine Übersicht finden Sie jedoch auf der Seite Terminologie in den detaillierten Beschreibungen.

Grundprinzipien

Der Zuverlässigkeitsansatz von Google basiert auf den folgenden Grundprinzipien.

Zuverlässigkeit ist das Wichtigste Feature

Neue Produktfunktionen haben manchmal kurzfristig oberste Priorität. Zuverlässigkeit ist jedoch langfristig das wichtigste Produktfeature. Wenn das Produkt zu langsam ist oder über einen längeren Zeitraum nicht verfügbar ist, verlassen Ihre Nutzer möglicherweise die Anwendung, wodurch andere Produktfeatures irrelevant werden.

Die Zuverlässigkeit wird vom Nutzer definiert.

Messen Sie bei nutzerorientierten Arbeitslasten die Nutzererfahrung. Der Nutzer muss mit der Leistung des Dienstes zufrieden sein. Messen Sie beispielsweise das Erfolgsverhältnis von Nutzeranfragen ab und nicht nur Servermesswerte wie CPU-Auslastung.

Bei Batch- und Streamingarbeitslasten müssen Sie unter Umständen Leistungskennzahlen (Key Performance Indicators, KPIs) für den Datendurchsatz messen, z. B. Zeilen, die pro Zeitfenster gescannt werden, anstelle von Servermesswerten wie der Laufwerksnutzung. Durchsatz-KPIs können sicherstellen, dass ein täglicher oder vierteljährlicher Bericht, der von den Nutzern benötigt wird, rechtzeitig abgeschlossen wird.

100 % Zuverlässigkeit ist das falsche Ziel

Ihre Systeme sollten so zuverlässig sein, dass Nutzer zufrieden sind. Gleichzeitig sollten Sie darauf achten, dass sich die Investition lohnt und Sie durch übermäßige Zuverlässigkeit nicht den Kürzeren ziehen. Definieren Sie SLOs, die den gewünschten Zuverlässigkeitsschwellenwert festlegen, und verwenden Sie dann Fehlerbudgets, um die passende Änderungsrate zu verwalten.

Wenden Sie die Design- und Betriebsprinzipien in diesem Framework nur dann auf ein Produkt an, wenn das SLO für dieses Produkt oder diese Anwendung die Kosten rechtfertigt.

Zuverlässigkeit und schnelle Innovation ergänzen sich

Verwenden Sie Fehlerbudgets, um ein Gleichgewicht zwischen Systemstabilität und Entwicklerflexibilität zu schaffen. Anhand der folgenden Anleitung können Sie ermitteln, wann Sie schnell oder langsam vorangehen sollten:

• Wenn ein ausreichendes Fehlerbudget verfügbar ist, können Sie schnell Innovationen vornehmen und das Produkt verbessern oder Produktfeatures hinzufügen.
• Wenn das Fehlerbudget verringert ist, drosseln Sie das Tempo und konzentrieren Sie sich auf Zuverlässigkeitsfeatures.

Design- und operative Prinzipien

Für die Maximierung der Systemzuverlässigkeit gelten die folgenden Design- und operativen Prinzipien. Jedes dieser Prinzipien wird im weiteren Verlauf der Betrachtung der Zuverlässigkeitskategorie des Architektur-Frameworks ausführlich erläutert.

Definieren Sie Zuverlässigkeitsziele.

In diesem Abschnitt des Architektur-Frameworks werden die folgenden Best Practices behandelt:

• Geeignete SLIs auswählen
• SLOs auf Basis der Nutzererfahrung festlegen
• SLOs iterativ verbessern
• Strikte interne SLOs verwenden
• Nutzen Sie Fehlerbudgets, um die Entwicklungsgeschwindigkeit zu steuern.

Weitere Informationen finden Sie unter Zuverlässigkeitsziele definieren in der Kategorie „Zuverlässigkeit für Architektur-Framework“.

Für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen sorgen

Das folgende Designprinzip wird in diesem Abschnitt des Architektur-Frameworks behandelt:

• Instrumentieren Sie Ihren Code, um die Beobachtbarkeit zu maximieren.

Weitere Informationen finden Sie unter Für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen sorgen in der Zuverlässigkeitskategorie des Architektur-Frameworks.

Bei der Entwicklung für Skalierung und Hochverfügbarkeit sorgen

Die folgenden Designprinzipien werden in diesem Abschnitt des Architektur-Frameworks behandelt:

• Redundanz für höhere Verfügbarkeit schaffen
• Daten über Regionen hinweg für die Notfallwiederherstellung replizieren
• Multiregionale Architektur für Sicherheit gegen regionale Ausfälle entwerfen
• Engpässe bei der Skalierbarkeit beseitigen
• Service-Levels bei Überlastung reibungslos heruntersetzen
• Trafficspitzen verhindern und minimieren
• Eingaben bereinigen und validieren
• Ausfallsicherheit unter Beibehaltung der Systemfunktion
• API-Aufrufe und operative Befehle wiederholbar entwickeln
• Systemabhängigkeiten ermitteln und verwalten
• Kritische Abhängigkeiten minimieren
• Gewährleisten, dass jede Änderung rückgängig gemacht werden kann

Weitere Informationen finden Sie unter Bei der Entwicklung für Skalierung und Hochverfügbarkeit sorgen in der Zuverlässigkeitskategorie für "Architecture Framework".

Zuverlässige operative Prozesse und Tools erstellen

Die folgenden operativen Prinzipien werden in diesem Abschnitt des Architektur-Frameworks behandelt:

• Einen guten Namen für Anwendungen und Dienste auswählen
• Schrittweise Rollouts mit Canary-Testverfahren implementieren
• Traffic für zeitlich begrenzte Werbeaktionen und Markteinführungen verteilen
• Build-, Test- und Bereitstellungsprozess automatisieren
• Vor Operatorfehlern schützen
• Verfahren zur Wiederherstellung nach Fehlern testen
• Notfallwiederherstellung testen
• Chaos Engineering üben

Weitere Informationen finden Sie unter Zuverlässige operative Prozesse und Tools erstellen in der Zuverlässigkeitskategorie des Architektur-Frameworks.

Effiziente Benachrichtigungen erstellen

Die folgenden operativen Prinzipien werden in diesem Abschnitt des Architektur-Frameworks behandelt:

• Benachrichtigungsverzögerungen optimieren
• Benachrichtigungen zu Symptomen und nicht zu Ursachen festlegen
• Benachrichtigung bei Ausreißern, nicht Durchschnittswerte

Weitere Informationen finden Sie unter Effiziente Benachrichtigungen erstellen in der Kategorie "Zuverlässigkeit für das Architecture Framework".

Gemeinsamen Prozess für Vorfallmanagement aufbauen

Die folgenden operativen Prinzipien werden in diesem Abschnitt des Architektur-Frameworks behandelt:

• Klare Dienstinhaberschaft zuweisen
• Zeit zur Erkennung (Time to detect, TTD) mit gut abgestimmten Benachrichtigungen reduzieren
• Zeit zur Problemminderung (Time to Mitigate, TTM) durch Vorfallmanagementpläne und -schulungen verkürzen
• Dashboard-Layouts und Inhalte gestalten, um die TTM zu minimieren
• Verfahren zur Dokumentdiagnose und Abhilfe für bekannte Ausfallszenarien
• Nachbesprechung ohne Schuldzuweisung nutzen, um aus Ausfällen zu lernen und Wiederholungen zu verhindern

Weitere Informationen finden Sie unter Kollaboratives Vorfallmanagement erstellen in der Kategorie „Zuverlässigkeit für das Architecture Framework“.

Nächste Schritte

• Zuverlässigkeitsziele definieren (nächstes Dokument in dieser Reihe)

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance

Definieren Sie Zuverlässigkeitsziele.

In diesem Dokument des Google Cloud-Architektur-Frameworks werden Best Practices beschrieben, um geeignete Arten zu definieren, wie die Kundenerfahrung hinsichtlich Ihrer Dienste gemessen werden kann, damit Sie zuverlässige Dienste ausführen können. Sie lernen, wie Sie die von Ihnen definierten Service Level Objectives (SLOs) iterieren und wie Sie mithilfe von Fehlerbudgets feststellen, wann die Zuverlässigkeit vielleicht beeinträchtigt wird, wenn Sie zusätzliche Aktualisierungen veröffentlichen.

Geeignete SLIs auswählen

Es ist wichtig, geeignete Service Level Indicators (SLIs) auszuwählen, um die Leistung Ihres Dienstes vollständig zu verstehen. Wenn Ihre Anwendung beispielsweise eine mehrmandantenfähige Architektur hat, die für SaaS-Anwendungen üblich ist, die von mehreren unabhängigen Kunden verwendet werden, erfassen Sie SLIs auf der Ebene einzelner Mandanten. Wenn Ihre SLIs nur auf globaler aggregierter Ebene gemessen werden, könnten Sie kritische Probleme in Ihrer Anwendung verpassen, die einen einzelnen wichtigen Kunden oder eine Minderheit der Kunden betreffen. Stattdessen sollten Sie Ihre Anwendung so konfigurieren, dass sie in jede Nutzeranfrage eine Mandanten-ID aufnimmt und diese dann über jede Schicht des Stacks weitergibt. Mit dieser ID kann das Monitoringsystem Statistiken auf der Ebene einzelner Mandanten für jede Schicht oder jeden Mikrodienst im Anfragepfad zusammenfassen.

Die Art des ausgeführten Dienstes bestimmt auch, welche SLIs überwacht werden sollen, wie in den folgenden Beispielen gezeigt.

Bereitstellungssysteme

Die folgenden SLIs sind in Systemen üblich, die Daten bereitstellen:

• Die Verfügbarkeit gibt an, wie lange ein Dienst nutzbar ist. Dieser Wert wird häufig als Anteil der erfolgreichen Anfragen definiert, z. B. 99 %.
• Die Latenz gibt an, wie schnell ein bestimmter Prozentsatz an Anfragen erfüllt werden kann. Sie wird oft als ein Perzentil ungleich 50 definiert, z. B.  99. Perzentil bei 3000ms“.
• Die Qualität weist darauf hin, wie gut eine bestimmte Antwort ist. Die Definition der Qualität ist oft dienstspezifisch und gibt an, inwieweit der Inhalt der Antwort auf eine Anfrage vom idealen Antwortinhalt abweicht. Die Antwortqualität kann binär (gut oder schlecht) oder auf einer Skala von 0 % bis 100 % ausgedrückt werden.

Datenverarbeitungssysteme

Die folgenden SLIs sind in Systemen üblich, die Daten verarbeiten:

• Die Abdeckung gibt den Anteil der verarbeiteten Daten an, z. B. 99,9 %.
• Die Richtigkeit gibt den Anteil der Ausgabedaten an, die als korrekt betrachtet werden, z. B. 99,99 %.
• Die Aktualität gibt an, wie aktuell die Quelldaten oder die aggregierten Ausgabedaten sind. Typischerweise gilt: Je aktueller, desto besser, z. B. vor 20 Minuten.
• Der Durchsatz gibt an, wie viele Daten verarbeitet werden, z. B. 500 MiB/s oder sogar 1.000 Anfragen pro Sekunde (RPS).

Speichersysteme

Die folgenden SLIs sind in Systemen typisch, in denen Daten gespeichert werden:

• Die Langlebigkeit gibt an, wie wahrscheinlich es ist, dass die in das System geschriebenen Daten in Zukunft abgerufen werden können, z. B. 99,9999 %. Bei einem dauerhaften Datenverlust wird der Messwert für die Langlebigkeit reduziert.
• Durchsatz und Latenz sind auch gängige SLIs für Speichersysteme.

SLIs auswählen und SLOs festlegen basierend auf der Nutzererfahrung

Eines der grundlegenden Prinzipien in diesem Architektur-Framework-Abschnitt besteht darin, dass die Zuverlässigkeit vom Nutzer definiert wird. Messen Sie die Zuverlässigkeitsmesswerte so nah wie möglich am Nutzer, z. B. mit den folgenden Optionen:

• Wenn möglich, sollten Sie den mobilen Client oder Webclient instrumentieren.
  • Verwenden Sie beispielsweise Firebase Performance Monitoring, um einen Einblick in die Leistungsmerkmale Ihrer iOS-, Android- und Web-Apps zu erhalten.
• Wenn dies nicht möglich ist, führen Sie eine Instrumentierung des Load-Balancers durch.
  • Verwenden Sie beispielsweise Cloud Monitoring für das Logging und Monitoring eines externen Application Load Balancers.
• Ein Messen der Zuverlässigkeit auf dem Server sollte die letzte Option sein.
  • Beispielsweise haben Sie die Möglichkeit, eine Compute Engine-Instanz mit Cloud Monitoring zu beobachten.

Legen Sie das SLO nur so hoch fest, dass fast alle Nutzer mit Ihrem Dienst zufrieden sind, und nicht höher. Aufgrund der Netzwerkverbindung oder anderer vorübergehender clientseitiger Probleme bemerken Ihre Kunden möglicherweise keine kurzen Zuverlässigkeitsprobleme in Ihrer Anwendung, sodass Sie Ihr SLO senken können.

Versuchen Sie bei der Verfügbarkeit und anderen wichtigen Messwerten ein Ziel von weniger als 100 %, aber nahe daran zu erreichen. Dienstinhaber sollten objektiv bewerten, welche Mindestanforderungen an die Leistung und Verfügbarkeit der Dienste erfüllt werden müssen, damit die meisten Nutzer zufrieden sind, und nicht nur Ziele auf der Grundlage von externen Verträgen festlegen.

Die Geschwindigkeit, mit der Sie Änderungen vornehmen, wirkt sich auf die Zuverlässigkeit Ihres Systems aus. Die Möglichkeit, häufig kleine Änderungen vorzunehmen, hilft Ihnen jedoch, Features schneller und mit höherer Qualität bereitzustellen. Erreichbare Ziele für die Zuverlässigkeit, die auf die Kundenerfahrung abgestimmt sind, helfen dabei, das maximale Tempo und den Umfang von Änderungen (Feature-Geschwindigkeit) zu definieren, den Kunden tolerieren können.

Wenn Sie die Kundenerfahrung nicht messen und keine Ziele definieren können, können Sie eine Benchmark-Wettbewerbsanalyse ausführen. Wenn kein vergleichbarer Wettbewerber vorhanden ist, sollten Sie die Kundenerfahrung messen, auch wenn Sie noch keine Ziele definieren können. Messen Sie beispielsweise die Systemverfügbarkeit oder die Rate aussagekräftiger und erfolgreicher Transaktionen an den Kunden. Sie können diese Daten mit Geschäftsmesswerten oder KPIs korrelieren, z. B. dem Umfang der Bestellungen im Einzelhandel oder der Anzahl der Kundensupportanrufe und -tickets sowie ihrem Schweregrad. Im Laufe der Zeit können Sie solche Korrelationsübungen verwenden, um einen angemessenen Schwellenwert für die Zufriedenheit der Kunden zu erhalten. Dieser Schwellenwert ist Ihr SLO.

SLOs iterativ verbessern

SLOs sollten nicht in Stein gemeißelt sein. Überprüfen Sie die SLOs vierteljährlich oder mindestens einmal pro Jahr und bestätigen Sie, dass sie auch weiterhin exakt die Zufriedenheit der Nutzer widerspiegeln und mit Dienstausfällen korrelieren. Gewährleisten Sie, dass sie die aktuellen Geschäftsanforderungen und neues wichtiges Nutzerverhalten abdecken. Überarbeiten Sie Ihre SLOs und erweitern Sie sie nach Bedarf nach diesen regelmäßigen Prüfungen.

Strikte interne SLOs verwenden

Es empfiehlt sich, interne SLOs höher als externe SLAs festzulegen. Da SLA-Verstöße in der Regel dazu führen, dass Finanzgutschriften oder Kundenerstattungen veranlasst werden muss, sollten Sie eventuelle Probleme beheben, bevor sie finanzielle Auswirkungen haben.

Wir empfehlen, diese strengeren internen SLOs mit einem Post-Mortem-Prozess ohne Schuldzuweisung und mit Vorfallprüfungen zu verwenden. Weitere Informationen finden Sie unter Kollaboratives Vorfallmanagement erstellen in der Kategorie „Zuverlässigkeit für das Architecture Framework“.

Nutzen Sie Fehlerbudgets, um die Entwicklungsgeschwindigkeit zu steuern.

Fehlerbudgets geben Aufschluss darüber, ob Ihr System über einen bestimmten Zeitraum hinweg mehr oder weniger zuverlässig ist als erforderlich. Fehlerbudgets werden als 100 % – SLO über einen bestimmten Zeitraum, z. B. 30 Tage, berechnet.

Wenn in Ihrem Fehlerbudget noch Kapazitäten vorhanden sind, können Sie weiterhin schnell Verbesserungen oder neue Funktionen einführen. Wenn das Fehlerbudget fast null ist, können Sie Dienständerungen einfrieren oder verlangsamen und technische Ressourcen für die Verbesserung von Zuverlässigkeitsfeatures nutzen.

Operations-Suite von Google Cloud bietet SLO-Monitoring, um den Aufwand für die Einrichtung von SLOs und Fehlerbudgets zu minimieren. Die Suite enthält eine grafische Benutzeroberfläche, mit der Sie SLOs manuell konfigurieren können, eine API für die programmatische Einrichtung von SLOs und integrierte Dashboards, um die Burn-Rate des Fehlerbudgets zu verfolgen. Weitere Informationen finden Sie unter SLO erstellen.

Empfehlungen

Befolgen Sie diese Empfehlungen, um die Anleitung im Architektur-Framework auf Ihre eigene Umgebung anzuwenden:

• Definieren und messen Sie kundenorientierte SLIs wie die Verfügbarkeit oder Latenz des Dienstes.
• Definieren Sie ein kundenorientiertes Fehlerbudget, das strenger als Ihr externes SLA ist. Schließen Sie Konsequenzen für Verstöße ein, z. B. Produktionsstopps.
• Richten Sie Latenz-SLIs zum Erfassen von Ausreißerwerten ein, z. B. das 90. oder 99. Perzentil, um die langsamsten Antworten zu erkennen.
• Prüfen Sie die SLOs mindestens einmal pro Jahr und vergewissern Sie sich, dass sie gut mit der Zufriedenheit der Nutzer und mit Dienstausfällen korrelieren.

Nächste Schritte

Weitere Informationen zum Definieren Ihrer Zuverlässigkeitsziele finden Sie in den folgenden Ressourcen:

• Für mehr Beobachtbarkeit in Ihrer Infrastruktur und Anwendung sorgen (nächstes Dokument in dieser Reihe)
• Coursera – SRE: Measuring and Managing Reliability
• SRE-Kapitel zu SLOs und SRE-Arbeitsmappe, um SLOs zu implementieren
• Tune up your SLI metrics

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance

SLOs definieren

Dieses Dokument ist der erste von zwei Teilen, die zeigen, wie Teams, die Onlinedienste betreiben, mithilfe von Service Level Objectives (SLOs) eine Kultur des Site Reliability Engineering (SRE) aufbauen und übernehmen können. Ein SLO ist ein Zielniveau für die Zuverlässigkeit für einen Dienst.

In Software as a Service (SaaS) gibt es eine natürliche Spannung zwischen der Geschwindigkeit der Produktentwicklung und der Betriebsstabilität. Je mehr Sie Ihr System ändern, desto größer ist die Wahrscheinlichkeit, dass es abstürzt. Tools für das Monitoring und die Beobachtbarkeit helfen Ihnen dabei, das Vertrauen in Ihre Betriebsstabilität nicht zu verlieren, während Sie die Entwicklungsgeschwindigkeit erhöhen. Obwohl diese auch als APM-Tools (Application Performance Management) bekannten Tools wichtig sind, ist eine ihrer wichtigsten Anwendungen das Festlegen von SLOs.

Bei korrekter Definition kann ein SLO Teams dabei unterstützen, datengestützte Betriebsentscheidungen zu treffen, die die Entwicklungsgeschwindigkeit erhöhen, ohne die Stabilität zu beeinträchtigen. Das SLO kann auch Entwicklungs- und Betriebsteams auf ein einziges vereinbartes Ziel ausrichten, wodurch die natürliche Spannung zwischen ihren Zielen – Erstellung und Iteration von Produkten (Entwicklung) und Aufrechterhaltung der Systemintegrität (Betrieb) – verringert werden kann.

SLOs werden neben anderen SRE-Praktiken in The SRE Book und The SRE Workbook ausführlich beschrieben. Diese Reihe versucht, das Verständnis und die Entwicklung von SLOs zu vereinfachen, damit Sie sie leichter anwenden können. Sobald Sie diese Artikel gelesen und verstanden haben, finden Sie weitere Informationen in den Büchern.

Diese Reihe soll Ihnen einen klaren Weg zur Implementierung von SLOs in Ihrer Organisation zeigen:

• In diesem Dokument wird erläutert, was SLOs sind und wie sie für Ihre Dienste definiert werden.
• SLOs übernehmen behandelt verschiedene Arten von SLOs basierend auf Arbeitslasttypen, die Messung dieser SLOs und die Entwicklung von darauf basierenden Benachrichtigungen.

Diese Reihe richtet sich an SREs, Betriebsteams, DevOps, Systemadministratoren und andere, die für die Stabilität und Zuverlässigkeit eines Onlinedienstes verantwortlich sind. Dabei wird das Wissen vorausgesetzt, wie Internetdienste mit Webbrowsern und Mobilgeräten kommunizieren, und dass Sie Grundkenntnisse bezüglich des Monitorings, der Bereitstellung und der Fehlerbehebung haben.

Die State of DevOps-Berichte haben Faktoren aufgezeigt, die die Leistung bei der Softwarebereitstellung beeinflussen. In dieser Reihe finden Sie Hilfe zu den folgenden Ressourcen:

• Monitoring und Beobachtbarkeit
• Monitoringsysteme für fundierte Geschäftsentscheidungen
• Proaktive Fehlerbenachrichtigung

Warum SLOs?

Wenn Sie eine SRE-Kultur aufbauen, warum sollten Sie mit SLOs beginnen? Kurz gesagt: Wenn Sie kein Service-Level definieren, ist es schwierig zu messen, ob Ihre Kunden mit Ihrem Service zufrieden sind. Auch wenn Sie wissen, dass Sie Ihren Service verbessern können, ist es aufgrund des Fehlens eines definierten Service-Levels schwierig zu entscheiden, wo und wie viel in Verbesserungen investiert werden soll.

Es kann verlockend sein, separate SLOs für jeden Dienst zu entwickeln, ob für Nutzer oder nicht. Ein häufiger Fehler besteht beispielsweise darin, zwei oder mehr Dienste separat zu messen, z. B. einen Frontend-Dienst und einen Backend-Datenspeicher, wenn der Nutzer beide Dienste verwendet und die Unterscheidung missachtet. Ein besserer Ansatz besteht darin, SLOs zu entwickeln, die auf dem Produkt (der Sammlung von Diensten) basieren und sich auf die wichtigsten Interaktionen Ihrer Nutzer konzentrieren.

Daher ist es für die Entwicklung eines effektiven SLO ideal, wenn Sie die Interaktionen Ihrer Nutzer mit Ihrem Dienst verstehen, die als Kritisches Nutzerverhalten (CUJs) bezeichnet werden. Ein CUJ berücksichtigt die Ziele Ihrer Nutzer und wie Ihre Nutzer Ihre Dienste nutzen, um diese Ziele zu erreichen. Der CUJ wird aus der Perspektive Ihres Kunden ohne Berücksichtigung von Dienstgrenzen definiert. Wenn der CUJ erfüllt ist, ist der Kunde zufrieden und zufriedene Kunden sind ein wichtiger Erfolgsfaktor für einen Dienst.

Ein wichtiger Aspekt für die Zufriedenheit von Kunden mit einem Dienst ist die Zuverlässigkeit eines Dienstes. Es ist irrelevant, was ein Dienst tut, wenn er nicht zuverlässig ist. Daher ist Zuverlässigkeit das wichtigste Merkmal. Ein häufiger Messwert für Zuverlässigkeit ist die Betriebszeit, die üblicherweise die Betriebszeit eines Systems angibt. Wir bevorzugen jedoch einen hilfreicheren und präziseren Messwert: Verfügbarkeit. Verfügbarkeit beantwortet weiterhin die Frage, ob ein System aktiv ist, aber genauer als durch Messen der Zeit seit dem Ausfall eines Systems. In den verteilten Systemen von heute können Dienste teilweise ausgefallen sein, was von der Betriebszeit nicht gut erfasst wird.

Die Verfügbarkeit wird häufig in Form von Neunen beschrieben, z. B.99,9 % (drei Neunen) oder 99,99 % (vier Neunen). Das Messen eines Verfügbarkeits-SLO ist eine der besten Methoden, um die Zuverlässigkeit Ihres Systems zu messen.

Mit einem SLO können Sie nicht nur den Betriebserfolg definieren, sondern auch entscheiden, wo Sie Ressourcen investieren. SRE-Bücher stellen beispielsweise häufig fest, dass jede Neun, für die Sie Entwicklungsarbeit leisten, zu inkrementellen Kosten mit geringfügigem Nutzen führen kann. Es ist allgemein bekannt, dass das Erreichen der nächsten Neun an Verfügbarkeit zehnmal so viel kostet wie die vorherige.

SLI auswählen

Sie benötigen eine Messung, um festzustellen, ob ein SLO erreicht (also erfolgreich) ist. Diese Messung wird als Service Level Indicator (SLI) bezeichnet. Ein SLI misst das Level eines bestimmten Dienstes, den Sie für Ihren Kunden bereitstellen. Im Idealfall ist das SLI mit einem akzeptierten CUJ verknüpft.

Die besten Messwerte auswählen

Der erste Schritt bei der Entwicklung eines SLI besteht darin, einen zu messenden Messwert auszuwählen, z. B. Anfragen pro Sekunde, Fehler pro Sekunde, Warteschlangenlänge, Verteilung der Antwortcodes während eines bestimmten Zeitraums oder die Anzahl der übertragenen Byte.

Solche Messwerte sind in der Regel folgende:

• Zähler: Zum Beispiel die Anzahl der Fehler, die bis zu einem bestimmten Messpunkt aufgetreten sind. Diese Art von Messwert kann sich erhöhen, aber nicht verringern.
• Verteilung: Zum Beispiel die Anzahl der Ereignisse, die ein bestimmtes Messsegment für einen bestimmten Zeitraum füllen. Sie können messen, wie viele Anfragen 0 bis 10 ms dauern, wie viele 11 bis 30 ms dauern und wie viele 31 bis 100 ms benötigen. Das Ergebnis ist eine Zählung für jeden Bucket, z. B. [0–10: 50], [11–30: 220], [31–100: 1103].
• Anzeige: Zum Beispiel der tatsächliche Wert eines messbaren Teiles des Systems (z. B. die Länge der Warteschlange). Diese Art von Messwert kann sich erhöhen oder verringern.

Weitere Informationen zu diesen Typen finden Sie in der Prometheus-Projektdokumentation und den Cloud Monitoring-Messwerttypen ValueType und MetricKind.

Ein wichtiger Unterschied zu SLIs ist, dass nicht alle Messwerte SLIs sind. Tatsächlich enthält die SRE-Arbeitsmappe Folgendes (Hervorhebung hinzugefügt):

"...Wir empfehlen generell, den SLI als Verhältnis von zwei Zahlen zu behandeln: die Anzahl der guten Ereignisse geteilt durch die Gesamtzahl der Ereignisse..."

"Der SLI reicht von 0 % bis 100 %, wobei 0 % bedeutet, dass nichts funktioniert, und 100 %, dass nichts fehlerhaft ist. Wir finden diese Skalierung intuitiv und dieser Stil eignet sich gut für das Konzept eines Fehlerbudgets."

Viele Softwareunternehmen erfassen Hunderte oder Tausende von Messwerten, wobei nur wenige Messwerte als SLIs dienen. Was ist neben einem Verhältnis von guten Ereignissen zu den gesamten Ereignissen also ein guter SLI-Messwert? Ein guter SLI-Messwert hat folgende Merkmale:

• Der Messwert bezieht sich direkt auf die Zufriedenheit der Nutzer. Im Allgemeinen sind Nutzer unzufrieden, wenn sich ein Dienst nicht wie erwartet verhält, ausfällt oder langsam ist. Alle SLOs, die auf diesen Messwerten basieren, können validiert werden, indem Sie Ihren SLI mit anderen Signalen der Nutzerzufriedenheit vergleichen, z. B. die Anzahl der Kundenbeschwerde-Tickets, das Supportanrufvolumen, die Stimmung in sozialen Medien oder Eskalationen. Wenn Ihr Messwert nicht mit diesen anderen Messwerten zur Nutzerzufriedenheit übereinstimmt, ist er möglicherweise nicht als SLI geeignet.
• Eine Verschlechterung der Messwerte hängt mit Ausfällen zusammen. Ein Messwert, der während eines Ausfalls gut aussieht, ist der falsche Messwert für einen SLI. Ein Messwert, der während des normalen Betriebs schlecht aussieht, ist auch der falsche Messwert für einen SLI.
• Der Messwert bietet ein gutes Signal-Rausch-Verhältnis. Messwerte, die zu einer großen Anzahl falsch-negativer oder falsch-positiver Ergebnisse führen, sind kein guter SLI.
• Der Messwert skaliert monoton und annähernd linear mit der Kundenzufriedenheit. Wenn sich der Messwert verbessert, steigt auch die Zufriedenheit der Kunden.

Betrachten Sie die Grafiken im folgenden Diagramm. Zwei Messwerte, die als SLIs für einen Dienst verwendet werden können, werden im Zeitverlauf grafisch dargestellt. Der Zeitraum, in dem ein Dienst schlecht läuft wird, wird rot markiert und der Zeitraum, in dem ein Dienst in Ordnung ist, blau hervorgehoben.

Im Falle eines schlechten SLI entspricht die Unzufriedenheit des Nutzers nicht direkt einem negativen Ereignis (z. B. Dienstausfall, Langsamkeit oder Ausfall). Außerdem schwankt der SLI unabhängig von der Zufriedenheit der Nutzer. Bei einem guten SLI hängen der SLI und die Nutzerzufriedenheit zusammen, die verschiedenen Zufriedenheitsstufen sind klar und es gibt weitaus weniger irrelevante Schwankungen.

Die richtige Anzahl von Messwerten auswählen

Normalerweise hat ein einzelner Dienst mehrere SLIs, insbesondere wenn der Dienst verschiedene Arten von Aufgaben ausführt oder unterschiedliche Arten von Nutzern bedient. Beispielsweise ist es sinnvoll, Lese- und Schreibanfragen zu trennen, da diese Anfragen in der Regel unterschiedlich funktionieren. In diesem Fall ist es am besten, für jeden Dienst geeignete Messwerte auszuwählen.

Im Gegensatz dazu führen viele Dienste im gesamten Dienst ähnliche Aufgaben aus, die direkt vergleichbar sind. Wenn Sie beispielsweise einen Online-Marktplatz haben, können Nutzer eine Startseite, eine Unterkategorie oder eine Top-10-Liste, eine Detailseite oder eine Suche nach Artikeln aufrufen. Anstatt für jede dieser Aktionen einen separaten SLI zu entwickeln und zu messen, können Sie sie in einer einzigen SLI-Kategorie kombinieren, z. B. Dienste durchsuchen.

Tatsächlich ändern sich die Erwartungen eines Nutzers bei Aktionen einer ähnlichen Kategorie nicht zu stark. Ihre Zufriedenheit hängt nicht von der Struktur der Daten ab, die sie durchsuchen. Es ist unerheblich, ob die Daten aus einer statischen Liste von beworbenen Artikeln stammen oder das dynamisch generierte Ergebnis einer durch maschinelles Lernen unterstützten Suche in einem riesigen Dataset sind. Ihre Zufriedenheit ist durch die Antwort auf die Frage "Habe ich schnell eine ganze Seite mit Artikeln gesehen?" messbar.

Im Idealfall sollten Sie so wenig SLIs wie möglich verwenden, um die Toleranzen eines bestimmten Dienstes genau darzustellen. In der Regel sollte ein Dienst zwischen zwei und sechs SLIs haben. Wenn Sie zu wenig SLIs haben, können Sie wertvolle Signale verpassen. Sind zu viele SLIs vorhanden, hat Ihr Bereitschaftsteam zu viel zu erfassen und nur einen geringen zusätzlichen Nutzen. Denken Sie daran, dass SLIs das Verständnis der Produktionsintegrität vereinfachen und ein Gefühl der Abdeckung vermitteln.

SLO auswählen

Ein SLO besteht aus den folgenden Werten:

• SLI: Zum Beispiel das Verhältnis der Anzahl der Antworten mit dem HTTP-Code 200 zur Gesamtzahl der Antworten.
• Dauer: Der Zeitraum, in dem ein Messwert gemessen wird. Dieser Zeitraum kann kalenderbasiert sein (z. B. vom ersten Tag eines Monats bis zum ersten Tag des nächsten Monats) oder ein gleitender Zeitraum (z. B. die letzten 30 Tage).
• Ziel: Beispiel: Ein Zielprozentsatz von guten Ereignissen an Gesamtereignissen (z. B. 99,9 %), die Sie für eine bestimmte Dauer erreichen möchten.

Wenn Sie ein SLO entwickeln, kann es schwierig sein, die Dauer und das Ziel festzulegen. Eine Möglichkeit, den Prozess zu beginnen, besteht darin, SLIs zu identifizieren und sie im Zeitverlauf grafisch darzustellen. Wenn Sie sich nicht entscheiden können, welche Dauer und welches Ziel Sie verwenden sollen, denken Sie daran, dass Ihr SLO nicht sofort perfekt sein muss. Sie werden Ihr SLO wahrscheinlich wiederholen, damit es mit der Zufriedenheit der Kunden übereinstimmt und Ihren Geschäftsanforderungen entspricht. Sie können einen Monat lang mit zwei Neunen (99,0 %) beginnen.

Wenn Sie die SLO-Compliance bei Ereignissen wie Bereitstellungen, Ausfällen und täglichen Trafficmustern verfolgen, können Sie Informationen darüber erhalten, welches Ziel gut, schlecht oder sogar tolerierbar ist. In einem Hintergrundprozess könnten Sie beispielsweise 75 % Erfolg als angemessen definieren. Bei geschäftskritischen, nutzerorientierten Anfragen können Sie jedoch etwas aggressiveres versuchen, z. B. 99,95 %.

Natürlich gibt es nicht für jeden Anwendungsfall ein einzelnes SLO. SLOs hängen von mehreren Faktoren ab:

• Erwartungen der Kunden
• Arbeitslasttyp
• Infrastruktur für Bereitstellung, Ausführung und Monitoring
• Problematische Domain

In Teil 2 dieser Reihe, SLOs übernehmen, geht es um domainunabhängige SLOs. Domainunabhängige SLOs (z. B. Dienstverfügbarkeit) ersetzen keine allgemeinen Indikatoren (z. B. pro Minute verkaufte Widgets). Mit ihnen lässt sich jedoch messen, ob ein Dienst unabhängig vom geschäftlichen Anwendungsfall funktioniert.

Domainunabhängige Indikatoren können oft auf eine Frage reduziert werden, z. B. "Ist der Dienst verfügbar?" oder "Ist der Dienst schnell genug?" Die Antwort ist meistens in einem SLO zu finden, das zwei Faktoren berücksichtigt: Verfügbarkeit und Latenz. Sie können ein SLO folgendermaßen beschreiben, wobei X = 99,9 % und Y = 800 ms ist:

X % der gültigen Anfragen sind erfolgreich und schneller als Y ms.

Nächste Schritte

• Lesen Sie SLOs übernehmen. Darin werden diese Definitionen ausführlicher erläutert und andere SLIs vorgestellt, die für verschiedene Arbeitslasttypen besser geeignet sind.
• Weitere SRE-Ressourcen:
  • The SRE Book
  • The SRE Workbook
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center
• Ressourcen zu DevOps
• Mehr über die DevOps-Ressourcen aus dieser Reihe erfahren:
  • Monitoring und Beobachtbarkeit
  • Monitoringsysteme für fundierte Geschäftsentscheidungen
  • Proaktive Fehlerbenachrichtigung
• Über den DevOps Quick Check erfahren, wo Sie im Vergleich zum Rest der Branche stehen

SLOs übernehmen

In diesem Dokument werden mehrere Service Level Objectives (SLOs) definiert, die für verschiedene Arten von gängigen Dienstarbeitslasten nützlich sind. Dieses Dokument ist Teil 2 von zwei Teilen. Teil 1, SLOs definieren, stellt SLOs vor und zeigt, wie SLOs aus Service Level Indicators (SLIs) abgeleitet werden. Außerdem wird darin beschrieben, was ein gutes SLO ausmacht.

Die State of DevOps-Berichte haben Faktoren aufgezeigt, die die Leistung bei der Softwarebereitstellung beeinflussen. Diese beiden Dokumente bieten folgende Funktionen:

• Monitoring und Beobachtbarkeit
• Monitoringsysteme für fundierte Geschäftsentscheidungen
• Proaktive Fehlerbenachrichtigung

Geeignete Messwerte

Unabhängig von Ihrer Domain haben viele Dienste die gleichen gängigen Features und können generische SLOs verwenden. Die folgende Beschreibung generischer SLOs ist nach Diensttyp unterteilt und enthält detaillierte Erläuterungen zu den SLIs, die für jedes SLO gelten.

Anfragengesteuerte Dienste

Ein anfragengesteuerter Dienst empfängt eine Anfrage von einem Client (einem anderen Dienst oder einem Nutzer), führt eine Berechnung durch, sendet möglicherweise Netzwerkanfragen an ein Back-End und gibt dann eine Antwort an den Client zurück. Anfragengesteuerte Dienste werden meist anhand von Verfügbarkeits- und Latenz-SLIs gemessen.

Verfügbarkeit als SLI

Der SLI für die Verfügbarkeit gibt an, ob der Dienst funktioniert. Der SLI für Verfügbarkeit ist so definiert:

Der Anteil der gültigen Anfragen, die erfolgreich verarbeitet wurden.

Sie müssen zuerst gültig definieren. Einige grundlegende Definitionen sind beispielsweise "nicht null" oder "entspricht einem Client-Server-Protokoll", aber es ist Aufgabe des Dienstinhabers, die Bedeutung von gültig zu definieren. Eine gängige Methode zum Beurteilen der Gültigkeit ist die Verwendung eines HTTP- oder RPC-Antwortcodes. Beispielsweise stufen wir häufig HTTP-500-Fehler als Serverfehler ein, die auf ein SLO angerechnet werden, während 400-Fehler Clientfehler sind, für die dies nicht gilt.

Nachdem Sie entschieden haben, was gemessen werden soll, müssen Sie jeden vom System zurückgegebenen Antwortcode prüfen, um sicherzustellen, dass die Anwendung diese Codes richtig und konsistent verwendet. Wenn Sie Fehlercodes für SLOs verwenden, sollten Sie sich fragen, ob ein Code ein genauer Indikator für die Erfahrung der Nutzer mit Ihrem Dienst ist. Wenn ein Nutzer beispielsweise versucht, einen Artikel zu bestellen, der nicht auf Lager ist, wird dann auf der Website eine Fehlermeldung angezeigt oder werden ähnliche Produkte vorgeschlagen? Für die Verwendung mit SLOs müssen Fehlercodes an die Erwartungen der Nutzer gebunden sein.

Entwickler können Fehler auf falsche Art verwenden. Für den Fall, dass ein Nutzer ein Produkt bestellen möchte, das vorübergehend nicht auf Lager ist, könnte ein Entwickler versehentlich einen Fehler programmieren, der zurückgegeben werden soll. Das System funktioniert in diesem Fall jedoch ordnungsgemäß und ist nicht fehlerhaft. Es darf kein Fehlercode zurückgegeben werden, obwohl der Nutzer den gewünschten Artikel nicht kaufen konnte. Natürlich müssen die Inhaber dieses Dienstes wissen, dass ein Produkt nicht auf Lager ist, aber die Tatsache, dass kein Kauf möglich war, ist aus Kundensicht kein Fehler und sollte nicht auf ein SLO angerechnet werden. Wenn der Dienst jedoch keine Verbindung zur Datenbank herstellen kann, um festzustellen, ob der Artikel auf Lager ist, ist das ein Fehler, der auf Ihr Fehlerbudget angerechnet wird.

Möglicherweise ist Ihr Dienst komplexer. Angenommen, der Dienst verarbeitet asynchrone Anfragen oder bietet Kunden einen zeitaufwendigen Prozess. In diesen Fällen können Sie die Verfügbarkeit auf andere Weise definieren. Wir empfehlen jedoch, die Verfügbarkeit weiterhin als Anteil der gültigen Anfragen darzustellen, die erfolgreich sind. Sie können die Verfügbarkeit als die Anzahl der Minuten definieren, für die die Arbeitslast eines Kunden wie gewünscht ausgeführt wird. Dieser Ansatz wird manchmal als "gute Minuten"-Methode zum Messen der Verfügbarkeit bezeichnet. Im Fall einer virtuellen Maschine können Sie die Verfügbarkeit als den Anteil der Minuten nach einer ersten Anfrage für eine VM messen, in dem über SSH auf die VM zugegriffen werden kann.

Latenz als SLI

Der SLI für Latenz (manchmal als Geschwindigkeit bezeichnet) gibt an, ob der Dienst schnell genug ist. Der SLI für Latenz ist ähnlich wie der für Verfügbarkeit definiert:

Der Anteil gültiger Anfragen, die schneller verarbeitet wurden, als dies ein festgelegter Schwellenwert vorsieht.

Sie können die Latenz messen, indem Sie die Differenz zwischen dem Start und dem Ende eines Timers für einen bestimmten Anfragetyp berechnen. Der Schlüssel ist die Wahrnehmung der Latenz durch Nutzer. Ein häufiges Problem besteht darin, die Latenz zu präzise zu messen. Tatsächlich können Nutzer keinen Unterschied feststellen, wenn eine Aktualisierung 100 Millisekunden (ms) oder 300 ms dauert und akzeptieren möglicherweise jeden beliebigen Wert zwischen 300 ms und 1.000 ms.

Stattdessen empfiehlt es sich, aktivitätsbezogene Messwerte zu entwickeln, bei denen der Nutzer im Blick behalten wird, z. B. wie bei den folgenden Prozessen:

• Interactive: 1.000 ms für die Zeit, die ein Nutzer nach dem Klicken auf ein Element auf ein Ergebnis wartet.
• Write: 1.500 ms zum Ändern eines zugrunde liegenden verteilten Systems. Diese Zeitspanne gilt zwar für ein System als langsam, wird aber von Nutzern tendenziell akzeptiert. Wir empfehlen Ihnen, bei den Messwerten explizit zwischen Schreib- und Lesevorgängen zu unterscheiden.
• Background: 5.000 ms für eine Aktion, die für den Nutzer nicht sichtbar ist, z. B. eine regelmäßige Aktualisierung von Daten oder andere asynchrone Anfragen.

Die Latenz wird allgemein als Verteilung gemessen (siehe SLI auswählen in Teil 1 dieser Reihe). Bei einer Verteilung können Sie verschiedene Perzentile messen. Sie können beispielsweise die Anzahl der Anfragen messen, die langsamer als das frühere 99. Perzentil sind. In diesem Fall werden solche Ereignisse als gute Ereignisse betrachtet, die diesen Schwellenwert überschreiten, der durch das Prüfen der historischen Verteilung festgelegt wurde. Sie können diesen Schwellenwert auch anhand von Produktanforderungen festlegen. Sie können sogar SLOs mit mehreren Latenzen festlegen, z. B. die typische Latenz im Vergleich zur Extremwertlatenz.

Wir empfehlen, nicht nur die durchschnittliche Latenz oder Medianlatenz als SLI zu verwenden. Wenn Sie feststellen, dass die Medianlatenz zu langsam ist, ist bereits die Hälfte Ihrer Nutzer unzufrieden. Es kann also sein, dass die Latenz mehrere Tage lang zu hoch ist, bis Sie feststellen, dass sich dies negativ auf Ihr langfristiges Fehlerbudget auswirken könnte. Daher empfehlen wir Ihnen, Ihr SLO für die Extremwertlatenz (95. Perzentil) und für die Medianlatenz (50. Perzentil) zu definieren.

Im ACM-Artikel Metrics That Matter schreibt Benjamin Treynor Sloss Folgendes:

"Eine gute praktische Faustregel ... ist: Die Latenz des 99. Perzentils sollte nicht mehr als das Drei- bis Fünffache der Medianlatenz betragen."

Treynor Sloss schreibt weiterhin:

"Wir halten die Latenzmesswerte für das 50., 95. und 99. Perzentil eines Dienstes alle für wertvoll und legen daher idealerweise SLOs für jeden der Werte fest."

Ein gutes Modell ist es, die Latenzschwellenwerte auf Grundlage historischer Perzentile zu ermitteln und dann zu messen, wie viele Anfragen in jedem Bucket landen. Weitere Informationen finden Sie im Abschnitt zu Latenzbenachrichtigungen weiter unten in diesem Dokument.

Qualität als SLI

Die Qualität ist ein hilfreicher SLI für komplexe Dienste, die so konzipiert sind, dass sie auf behutsame Weise fehlschlagen, indem Sie schlechter funktionieren, wenn Abhängigkeiten langsam oder nicht verfügbar sind. Der SLI für Qualität ist so definiert:

Der Anteil gültiger Anfragen, die ohne Beeinträchtigung des Dienstes verarbeitet wurden

Beispielsweise kann eine Webseite ihren Hauptinhalt aus einem Datenspeicher und optionale Zusatz-Assets aus 100 anderen Diensten und Datenspeichern laden. Wenn ein optionaler Dienst außer Betrieb oder zu langsam ist, kann die Seite trotzdem ohne die Zusatzelemente gerendert werden. Indem Sie die Anzahl der Anfragen messen, die eine eingeschränkte Antwort erhalten (d. h. eine Antwort, bei der die Antwort mindestens eines Back-End-Dienstes fehlt), können Sie sich die relative Anzahl der fehlerhaften Anfragen anzeigen lassen. Sie können sogar erfassen, wie vielen Antworten an den Nutzer eine Antwort von einem einzelnen Back-End oder Antworten von mehreren Back-Ends gefehlt haben.

Datenverarbeitungsdienste

Einige Dienste sind nicht darauf ausgelegt, auf Nutzeranfragen zu reagieren, sondern nutzen Daten aus einer Eingabe, verarbeiten diese Daten und generieren eine Ausgabe. Die Leistung dieser Dienste bei Zwischenschritten ist nicht so wichtig wie das Endergebnis. Bei solchen Diensten sind die aussagekräftigsten SLIs Aktualität, Abdeckung, Richtigkeit und Durchsatz, nicht Latenz und Verfügbarkeit.

Aktualität als SLI

Der SLI für Aktualität ist so definiert:

Der Anteil gültiger Daten, die vor der im Schwellenwert festgelegten Zeit aktualisiert wurden

In Batchverarbeitungssystemen kann die Aktualität beispielsweise als die Zeit gemessen werden, die seit dem erfolgreichen Abschluss eines Verarbeitungslaufs für eine bestimmte Ausgabe verstrichen ist. In komplexeren Verarbeitungssystemen oder Echtzeitverarbeitungssystemen können Sie das Alter des zuletzt in einer Pipeline verarbeiteten Datensatzes verfolgen.

Angenommen, ein Onlinespiel generiert in Echtzeit Kartenkacheln. Nutzer bemerken möglicherweise nicht, wie schnell Kartenkacheln erstellt werden, aber sie bemerken vielleicht, wenn Kartendaten fehlen oder nicht aktuell sind.

Oder stellen Sie sich ein System vor, das Datensätze aus einem Tracking-System für den Lagerbestand liest, um die Meldung "X Artikel auf Lager" für eine E-Commerce-Website zu generieren. Sie können den SLI für Aktualität so definieren:

Der Prozentsatz der Aufrufe, für die Lagerinformationen verwendet wurden, die innerhalb der letzten Minute aktualisiert wurden

Sie können auch einen Messwert für die Bereitstellung nicht aktueller Daten verwenden, um den SLI für Qualität zu informieren.

Abdeckung als SLI

Der SLI für die Abdeckung ist so definiert:

Der Anteil der gültigen Daten, die erfolgreich verarbeitet wurden

Um die Abdeckung zu definieren, legen Sie zuerst fest, ob eine Eingabe als gültig akzeptiert oder übersprungen werden soll. Wenn ein Eingabedatensatz beispielsweise beschädigt ist oder die Länge null hat und nicht verarbeitet werden kann, können Sie diesen Datensatz für die Messung Ihres Systems als ungültig einstufen.

Als Nächstes zählen Sie die Anzahl der gültigen Datensätze. Sie können diesen Schritt mit einer einfachen count()-Methode oder einer anderen Methode ausführen. Diese Zahl ist die Gesamtzahl Ihrer Datensätze.

Damit Sie den SLI für die Abdeckung generieren können, zählen Sie schließlich die Anzahl der erfolgreich verarbeiteten Datensätze und vergleichen diese Anzahl mit der Gesamtzahl der gültigen Datensätze.

Richtigkeit als SLI

Der SLI für Richtigkeit ist so definiert:

Der Anteil gültiger Daten, die eine korrekte Ausgabe erzeugt haben

In manchen Fällen gibt es Methoden zum Bestimmen der Richtigkeit einer Ausgabe, mit denen die Verarbeitung der Ausgabe geprüft werden kann. Beispielsweise sollte ein System, das ein Bild rotiert oder einfärbt, niemals ein Null-Byte-Bild oder ein Bild mit einer Länge oder Breite von null erzeugen. Es ist wichtig, diese Validierungslogik von der Verarbeitungslogik selbst zu trennen.

Eine Methode zum Messen eines Richtigkeits-SLI ist die Verwendung einwandfreier Testeingabedaten. Dabei handelt es sich um Daten mit bekanntermaßen korrekter Ausgabe. Die Eingabedaten müssen für Nutzerdaten repräsentativ sein. In anderen Fällen kann es sein, dass eine mathematische oder logische Prüfung der Ausgabe durchgeführt wird, wie im vorherigen Beispiel, bei dem ein Bild gedreht wurde. Ein weiteres Beispiel wäre ein Abrechnungssystem, das feststellt, ob eine Transaktion gültig ist, indem geprüft wird, ob die Differenz zwischen dem Kontostand vor der Transaktion und dem Kontostand nach der Transaktion mit dem Wert der Transaktion selbst übereinstimmt.

Durchsatz als SLI

Der SLI für den Durchsatz ist so definiert:

Der Anteil der Zeit, in der die Datenverarbeitungsrate über einem Schwellenwert lag

In einem Datenverarbeitungssystem ist häufig der Durchsatz repräsentativer für die Zufriedenheit der Nutzer als beispielsweise eine einzelne Latenzmessung für einen bestimmten Arbeitsvorgang. Wenn beispielsweise die Größe jeder Eingabe stark variiert, ist es möglicherweise nicht sinnvoll, zu vergleichen, wie lange jedes einzelne Element bearbeitet wird, wenn der Job an sich mit einer akzeptablen Geschwindigkeit ausgeführt wird.

Byte pro Sekunde ist eine gängige Methode, um den Arbeitsaufwand für das Verarbeiten von Daten unabhängig von der Größe eines Datasets zu messen. Aber es kann jeder Messwert, der in Bezug auf die Verarbeitungskosten ungefähr linear skaliert wird, funktionieren.

Es kann sich lohnen, Datenverarbeitungssysteme anhand der erwarteten Durchsatzraten zu partitionieren oder ein Dienstqualitätssystem zu implementieren, um sicherzustellen, dass Eingaben mit hoher Priorität verarbeitet und Eingaben mit niedriger Priorität in die Warteschlange gestellt werden. In jedem Fall können Sie durch das Messen des Durchsatzes auf die in diesem Abschnitt beschriebene Weise feststellen, ob Ihr System wie erwartet funktioniert.

Dienste mit geplanter Ausführung

Für Dienste, die in regelmäßigen Abständen eine Aktion ausführen müssen, z. B. Kubernetes-Cronjobs, können Sie die Verzerrung und die Ausführungsdauer messen. Im Folgenden finden Sie ein Beispiel für einen geplanten Kubernetes-Cronjob:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

Verzerrung als SLI

Als SLI ist die Verzerrung so definiert:

Der Anteil der Ausführungen, die innerhalb eines akzeptablen Zeitfensters vor oder nach der erwarteten Startzeit beginnen

Die Verzerrung misst die Zeitdifferenz zwischen dem planmäßigen Start eines Jobs und dem tatsächlichen Start. Wenn beispielsweise der vorherige Kubernetes-Cronjob, der so eingerichtet ist, dass er zur Minute null jeder Stunde startet, drei Minuten nach Anbruch der Stunde beginnt, beträgt die Verzerrung drei Minuten. Wenn ein Job zu früh ausgeführt wird, kommt es zu einer negativen Verzerrung.

Sie können messen, wie sich die Verzerrung im Laufe der Zeit entwickelt, indem sie entsprechende akzeptable Bereiche festlegen, die eine gute Verzerrung definieren. Zum Ermitteln des SLI vergleichen Sie die Anzahl der Ausführungen, die innerhalb eines guten Bereichs lagen.

Ausführungsdauer als SLI

Als SLI ist die Ausführungsdauer so definiert:

Der Anteil der Ausführungen, die innerhalb des zulässigen Dauerfensters abgeschlossen werden

Ausführungsdauer ist die Zeit, die zum Fertigstellen eines Jobs benötigt wird. Bei einer Ausführung kommt es häufig zu dem Fehler, dass die tatsächliche Dauer die geplante Dauer überschreitet.

Ein interessanter Fall ist die Anwendung dieses SLI, um einen nie endenden Job zu erfassen. Da diese Jobs nicht abgeschlossen werden, müssen Sie die für einen bestimmten Job aufgewendete Zeit erfassen, anstatt auf den Abschluss eines Jobs zu warten. Dieser Ansatz bietet eine genaue Verteilung dafür, wie lange es dauert, bis die Arbeit fertiggestellt wurde, selbst in Worst-Case-Szenarien.

Wie bei der Verzerrung können Sie die Verteilung der Ausführungsdauer verfolgen und akzeptable Ober- und Untergrenzen für gute Ereignisse definieren.

Arten von Messwerten für andere Systeme

Viele andere Arbeitslasten haben eigene Messwerte, mit denen Sie SLIs und SLOs generieren können. Betrachten Sie folgende Beispiele:

• Speichersysteme: Langlebigkeit, Durchsatz, Zeit bis zum ersten Byte, Blob-Verfügbarkeit
• Medien/Video: Client-Wiedergabekontinuität, Startzeit für die Wiedergabe, Vollständigkeit von Transcode-Diagrammausführungen
• Gaming: Zeit zum Zuordnen aktiver Spieler und Zeit für die Erstellung einer Karte

So messen Sie

Sobald Sie entschieden haben, was Sie messen möchten, können Sie entscheiden, wie die Messung durchgeführt werden soll. Sie können die SLIs auf verschiedene Arten erfassen.

Serverseitiges Logging

Methode zum Generieren von SLIs

Verarbeiten serverseitiger Logs von Anfragen oder verarbeiteten Daten

Hinweise

Vorteile:

• Vorhandene Logs können noch einmal verarbeitet werden, um für historische SLI-Datensätze ein Backfill durchzuführen.
• Mit dienstübergreifenden Sitzungs-IDs kann komplexes Nutzerverhalten über mehrere Dienste hinweg rekonstruiert werden.

Nachteile:

• Anfragen, die nicht beim Server eingehen, werden nicht aufgezeichnet.
• Anfragen, die einen Serverabsturz verursachen, werden möglicherweise nicht aufgezeichnet.
• Die Dauer der Verarbeitung von Logs kann zu veralteten SLIs führen, deren Daten dann für eine operative Antwort möglicherweise ungeeignet sind.
• Das Schreiben von Code in Verarbeitungslogs kann eine fehleranfällige und zeitaufwendige Aufgabe sein.

Methoden und Tools zum Implementieren:

• BigQuery
• Dataflow, Apache Spark
• Splunk

Anwendungsserver-Messwerte

Methode zum Generieren von SLIs

Exportieren von SLI-Messwerten aus dem Code, der Anfragen von Nutzern oder deren Daten verarbeitet

Hinweise

Vorteil:

• Das Hinzufügen neuer Messwerte zum Code ist normalerweise schnell und kostengünstig

Nachteile:

• Anfragen, die nicht bei Anwendungsservern eingehen, werden nicht aufgezeichnet
• Multidienstanfragen sind möglicherweise schwer zu verfolgen

Methoden und Tools zum Implementieren:

• Cloud Monitoring
• Prometheus
• APM-Produkte von Drittanbietern

Frontend-Infrastrukturmesswerte

Methode zum Generieren von SLIs

Messwerte aus der Load-Balancing-Infrastruktur verwenden (z. B. dem globalen Layer-7-Load-Balancer von Google Cloud).

Hinweise

Vorteile:

• Messwerte und Verlaufsdaten sind oft bereits vorhanden, was die für den Einstieg erforderlichen Entwicklungsbemühungen verringert.
• Die Messwerte werden an dem Punkt erhoben, der sich am nächsten am Kunden, aber noch innerhalb der Bereitstellungsinfrastruktur befindet.

Nachteile:

• Nicht für Datenverarbeitungs-SLIs geeignet
• Kann Nutzerverhalten mit mehreren Anfragen nur näherungsweise ermitteln

Methoden und Tools zum Implementieren:

• Cloud Monitoring
• CDN/LB-Messwerte oder Reporting APIs (Cloudflare, Akamai, Fastly)

Synthetische Clients oder Daten

Methode zum Generieren von SLIs

Erstellen eines Clients, der in regelmäßigen Abständen künstliche Anfragen sendet und die Antworten validiert. Für Datenverarbeitungspipelines: Erstellen von synthetischen, einwandfreien Eingabedaten und Validieren der Ausgaben.

Hinweise

Vorteile:

• Erstellt Messwerte für alle Schritte eines Nutzerverhaltens mit mehreren Anfragen
• Das Senden von Anfragen von außerhalb Ihrer Infrastruktur führt zum Erfassen eines größeren Teils des gesamten Anfragepfads im SLI

Nachteile:

• Approximiert die Nutzererfahrung mit synthetischen Anfragen, die irreführend sein können (sowohl falsch positive als auch falsch negative Ergebnisse).
• Es ist schwierig, alle seltenen Fälle abzudecken und dieser Versuch kann in Integrationstests übergehen.
• Ziele mit hoher Zuverlässigkeit erfordern häufige Prüfungen für genaue Messwerte.
• Der Prüfungs-Traffic kann den echten Traffic in den Hintergrund rücken.

Methoden und Tools zum Implementieren:

• Verfügbarkeitsdiagnosen von Cloud Monitoring
• Open-Source-Lösungen:
  • Cloudprober
  • blackbox_exporter
• Herstellerlösungen:
  • Catchpoint Synthetic Monitoring
  • New Relic Synthetics
  • Datadog Synthetic Monitoring

Client-Instrumentierung

Methode zum Generieren von SLIs

Hinzufügen von Sichtbarkeits-Features zu dem Client, mit dem der Nutzer interagiert, und Logging von Ereignissen in der Bereitstellungsinfrastruktur, die SLIs verfolgt

Hinweise

Vorteile:

• Liefert die genauesten Messwerte für die Nutzererfahrung
• Kann die Zuverlässigkeit von Drittanbietern wie CDN oder Zahlungsdienstleistern messen

Nachteile:

• Die Aufnahme von Clientlogs und die Verarbeitungslatenz machen diese SLIs zum Auslösen einer operativen Antwort ungeeignet.
• SLI-Messwerte enthalten eine Reihe von sehr variablen Faktoren, die sich möglicherweise nicht direkt kontrollieren lassen.
• Das Integrieren von Instrumentierung in den Client kann viel Entwicklungsarbeit erfordern.

Methoden und Tools zum Implementieren:

• Google Analytics, Firebase
• Nutzeranalyse: Amplitude und ähnliche Tools
• Mobiles/Frontend-Monitoring: New Relic Browser, Raygun Real User Monitoring, Sentry
• Benutzerdefinierter Client und benutzerdefinierter Server zum Aufzeichnen und Verfolgen

Messmethode auswählen

Im Idealfall wählen Sie eine Messmethode aus, die möglichst gut auf die Erfahrung der Kunden mit Ihrem Dienst abgestimmt ist und den geringstmöglichen Aufwand Ihrerseits erfordert. Um dieses Ideal zu erreichen, müssen Sie möglicherweise die Methoden in den vorherigen Tabellen kombinieren. Hier ist ein Vorschlag, dessen einzelne Schritte Sie im Laufe der Zeit implementieren können. Die Schritte sind in der Reihenfolge des zunehmenden Aufwands aufgeführt:

1. Exporte von Anwendungsservern und Infrastrukturmesswerte verwenden. In der Regel können Sie sofort auf diese Messwerte zugreifen und sie bieten schnell einen Mehrwert. Einige APM-Tools enthalten eingebundene SLO-Tools.
2. Clientinstrumentierung verwenden. Da in Legacy-Systeme normalerweise keine Clientinstrumentierung für Endnutzer eingebunden ist, kann das Einrichten der Instrumentierung eine erhebliche Investition erfordern. Wenn Sie jedoch eine APM-Suite oder ein Frontend-Framework verwenden, das eine Clientinstrumentierung bietet, können Sie schnell einen Einblick in die Zufriedenheit Ihrer Kunden gewinnen.
3. Logverarbeitung verwenden. Wenn Sie keine Serverexporte oder Clientinstrumentierung implementieren können, aber Logs vorhanden sind, kann die Logverarbeitung den besten Mehrwert bieten. Ein weiterer Ansatz besteht darin, Exporte und die Logverarbeitung zu kombinieren. Dabei werden Exporte als direkte Quelle für einige SLIs verwendet (z. B. sofortige Verfügbarkeit) und die Logverarbeitung für langfristige Signale (z. B. Benachrichtigungen bei langsamem Durchsatz, die weiter unten im Leitfaden zu SLos und Benachrichtigungen beschrieben sind).
4. Synthetische Tests implementieren. Nachdem Sie sich ein grundlegendes Verständnis davon verschafft haben, wie die Kunden Ihren Dienst nutzen, testen Sie Ihr Service Level. Sie können beispielsweise fehlerfreie Daten in Testkonten übertragen und sie abfragen. Dieser Test kann helfen, Fehlermodi herauszustellen, die nicht leicht zu beobachten sind, z. B. bei Diensten mit geringem Traffic.

Ziele festlegen

Eine der besten Möglichkeiten zum Festlegen von Zielen besteht darin, ein freigegebenes Dokument zu erstellen, das Ihre SLOs und wie Sie diese entwickelt haben beschreibt. Ihr Team kann über das Dokument iterieren, während es die Implementierung vornimmt und im Laufe der Zeit über die SLOs iteriert.

Wir empfehlen den Geschäftsinhabern, Produktinhabern und Führungskräften, dieses Dokument zu lesen. Diese Beteiligten können Ihnen Einblicke in die Erwartungen an die Dienste und die Zuverlässigkeitskompromisse Ihres Produktes bieten.

Hier finden Sie eine Vorlage für die Entwicklung eines SLO für die wichtigsten kritischen Nutzerverhaltensschemas (Critical User Journeys, CUJs) Ihres Unternehmens:

1. Wählen Sie eine SLI-Spezifikation aus (z. B. Verfügbarkeit oder Aktualität).
2. Definieren Sie, wie die SLI-Spezifikation implementiert werden soll.
3. Lesen Sie sich Ihren Plan durch, um sicherzustellen, dass die CUJs abgedeckt sind.
4. Legen Sie SLOs basierend auf früherer Leistung oder geschäftlichen Anforderungen fest.

CUJs sollten nicht auf einen einzelnen Dienst oder ein einzelnes Entwicklungsteam oder eine einzelne Organisation beschränkt sein. Wenn Ihre Nutzer auf Hunderte von Mikrodiensten angewiesen sind, die mit nur 99,5 % an Kapazität arbeiten, aber niemand die End-to-End-Verfügbarkeit erfasst, ist Ihr Kunde wahrscheinlich nicht zufrieden.

Angenommen, Sie haben eine Abfrage, die von fünf Diensten abhängt, die nacheinander ausgeführt werden: einem Load-Balancer, einem Frontend, einem Mixer, einem Backend und einer Datenbank.

Wenn jede Komponente eine Verfügbarkeit von 99,5 % hat, ergibt sich für den Nutzer im schlimmsten Fall folgende Verfügbarkeit:

99,5 % * 99,5 % * 99,5 % * 99,5 % * 99,5 % = 97,52 %

Dies ist das schlechteste Verfügbarkeitsszenario für den Nutzer, da das Gesamtsystem ausfällt, wenn einer der fünf Dienste ausfällt. Dies ist nur der Fall, wenn alle Ebenen des Stacks immer sofort für die Verarbeitung jeder Nutzeranfrage verfügbar sein müssen, ohne dass es Belastbarkeitsfaktoren wie Zwischenwiederholungsversuche, Cache-Speichervorgänge oder Warteschlangen gibt. Ein System mit einer so engen Kopplung zwischen den Diensten ist schlecht aufgebaut und entspricht nicht dem Konzept des Mikrodienstmodells.

Wenn Sie die Leistung auf diese Weise (Dienst für Dienst) anhand des SLO eines verteilten Systems messen, spiegelt dies die Erfahrung Ihrer Nutzer nicht getreu wider und kann zu einer Interpretation führen, bei der zu viele Faktoren berücksichtigt wurden.

Stattdessen sollten Sie die Leistung anhand des SLO am Frontend messen, um nachzuvollziehen, welche Erfahrung die Nutzer machen. Es ist dem Nutzer egal, wenn ein Komponentendienst fehlschlägt und dadurch eine Abfrage automatisch und auch erfolgreich wiederholt wird, so lange die Abfrage des Nutzers am Ende erfolgreich ist. Wenn Sie freigegebene interne Dienste haben, können diese Dienste die Leistung anhand ihrer SLOs separat messen, wobei die für den Nutzer sichtbaren Dienste als ihre Kunden fungieren. Sie sollten diese SLOs getrennt voneinander verarbeiten.

Sie können einen hochverfügbaren Dienst (z. B. mit 99,99 % Verfügbarkeit) auf Basis eines weniger gut verfügbaren Dienstes erstellen (z. B. mit 99,9 % Verfügbarkeit), indem Sie Belastbarkeitsfaktoren wie die intelligente Wiederholungsfunktion, das Caching und das Stellen von Aufgaben in die Warteschlange verwenden.

Grundsätzlich sollten alle, die statistische Grundkenntnisse haben, Ihr SLO lesen und verstehen können, ohne den zugrunde liegenden Dienst oder das Organisationslayout verstehen zu müssen.

Beispiel für ein SLO-Arbeitsblatt

Beachten Sie bei der Entwicklung des SLO Folgendes:

• Achten Sie darauf, dass in den SLIs ein Ereignis, ein Erfolgskriterium und der Ort und die Art, wo und wie Sie Erfolg oder Misserfolg dokumentieren möchten, angegeben sind.
• Definieren Sie die SLI-Spezifikation im Hinblick auf den Anteil an Ereignissen, die gut sind.
• Achten Sie darauf, dass im SLO sowohl eine Zielstufe als auch ein Messfenster angegeben sind.
• Beschreiben Sie die Vor- und Nachteile des Ansatzes, damit Interessenten die damit verbundenen Vor- und Nachteile und Feinheiten kennen.

Sehen Sie sich beispielsweise das folgende SLO-Arbeitsblatt an.

CUJ: Laden der Startseite

SLI-Typ: Latenz SLI-Spezifikation: Anteil der Startseitenanfragen, die in weniger als 100 ms verarbeitet werden SLI-Implementierungen: Anteil der Startseitenanfragen, die in weniger als 100 ms verarbeitet werden, gemäß der Messwerte in der Latenzspalte des Serverlogs. Nachteil: Bei diesen Messwerten werden Anfragen nicht erfasst, die das Back-End nicht erreichen. Anteil der Startseitenanfragen, die in weniger als 100 ms verarbeitet werden, was von Probern gemessen wird, die JavaScript in einem Browser ausführen, der auf einer virtuellen Maschine ausgeführt wird. Vor- und Nachteile: Bei dieser Messung werden zwar Fehler berücksichtigt, bei denen Anfragen das Netzwerk nicht erreichen können, aber möglicherweise werden Probleme nicht berücksichtigt, die nur einen Teil der Nutzer betreffen. SLO: 99 % der Startseitenanfragen der letzten 28 Tage wurden in weniger als 100 ms verarbeitet

Hinweis: Wenn Sie sich als Team nicht auf eine Zielstufe einigen können, wählen Sie eine Stufe aus und vereinbaren Sie, dies in sechs Monaten noch einmal zu besprechen. Es ist besser, sich für eine falsche Zahl zu entscheiden, als für keine Zahl.

Nächste Schritte

• Workshop The Art of SLOs des Google-Teams für Customer Reliability Engineering
• Onlinekurs Site Reliability Engineering: Measuring and Managing Reliability zum Erstellen von SLOs absolvieren
• Site Reliability Engineering: Implementing SLOs
• Konzepte beim Dienstmonitoring
• Developing SLOs with Cloud Monitoring
• Flexiblen SLO Generator der Professional Services Organization (PSO) von Google testen
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center
• Ressourcen zu DevOps
• Mehr über die DevOps-Ressourcen aus dieser Reihe erfahren:
  • Monitoring und Beobachtbarkeit
  • Monitoringsysteme für fundierte Geschäftsentscheidungen
  • Proaktive Fehlerbenachrichtigung
• Über den DevOps Quick Check erfahren, wo Sie im Vergleich zum Rest der Branche stehen

Terminologie

Dieses Dokument enthält allgemeine Definitionen für SLO-bezogene Begriffe, die im Abschnitt Google Cloud-Architektur-Framework: Zuverlässigkeit verwendet werden.

• Service-Level: Eine Messung, wie gut ein bestimmter Dienst die erwartete Arbeit für den Nutzer erfüllt. Sie können diese Messung im Hinblick auf die Zufriedenheit der Nutzer beschreiben und mit verschiedenen Methoden messen, je nachdem, was der Dienst tut und was der Nutzer erwartet oder was er tun soll.

  Beispiel: "Ein Nutzer erwartet, dass unser Dienst schnell und verfügbar ist."

• Kritisches Nutzerverhalten (CUJ): Eine Reihe von Interaktionen, die ein Nutzer mit einem Dienst erlebt, um ein einzelnes Ziel zu erreichen, z. B. einen einzelnen Klick oder eine Pipeline mit mehreren Schritten.

  Beispiel: "Ein Nutzer klickt auf die Schaltfläche zum Bezahlen und wartet auf die Antwort, dass der Einkaufswagen verarbeitet und ein Beleg zurückgegeben wurde."

• Service Level Indicator (SLI): Ein Maß für die Zufriedenheit der Nutzer, das für ein Service-Level gemessen werden kann. Mit anderen Worten: Um ein Service-Level zu messen, müssen Sie einen Indikator messen, der die Zufriedenheit der Nutzer mit diesem Service-Level darstellt, z. B. die Verfügbarkeit eines Dienstes. Ein SLI kann als Linie in einer Grafik betrachtet werden, die sich im Laufe der Zeit ändert, wenn sich der Dienst verbessert oder verschlechtert. Dies ist in der Regel ein Radio von "gut" / "gesamt", ausgedrückt als Prozentsatz ohne Einheiten. Durch die Verwendung dieser Prozentsätze können Teams den SLI verstehen, ohne umfassende Kenntnisse über ihre Implementierung zu haben.

  Beispiel: "Messen Sie die Anzahl der erfolgreichen Anfragen in den letzten zehn Minuten geteilt durch die Anzahl aller gültigen Anfragen in den letzten zehn Minuten."

• Service Level Objective (SLO): Das Level, das ein Dienst die meiste Zeit erreichen soll und anhand dessen ein SLI gemessen wird.

  Beispiel: "Die Antworten eines Dienstes sollen bei 95 % aller gültigen Anfragen über 14 Tage schneller als 400 Millisekunden (ms) sein."

  

• Service Level Agreement (SLA): Eine Beschreibung dessen, was geschehen muss, wenn ein SLO nicht erreicht wird. Im Allgemeinen ist ein SLA eine rechtliche Vereinbarung zwischen Anbietern und Kunden und kann sogar Vergütungsbedingungen enthalten. In technischen Diskussionen über SRE wird dieser Begriff oft vermieden.

  Beispiel: "Wenn der Dienst innerhalb eines Kalendermonats keine Verfügbarkeit von 99,95 % bietet, erstattet der Dienstanbieter dem Kunden jede Minute, in der er die Richtlinien nicht erfüllt."

• Fehlerbudget: Gibt an, wie viel Zeit oder negative Ereignisse Sie überstehen können, bevor Sie Ihr SLO verletzen. Dieser Messwert gibt an, wie viele Fehler Ihr Unternehmen erwarten oder ertragen kann. Das Fehlerbudget ist entscheidend, um potenziell riskante Entscheidungen zu treffen.

  Beispiel: "Wenn unser SLO zu 99,9 % verfügbar ist, gestatten wir 0,1 % unserer Anfragen, Fehler durch Vorfälle, Unfälle oder Tests zu verarbeiten."

SLOs und Benachrichtigungen

Dieses Dokument im Abschnitt Google Cloud-Architektur-Framework: Zuverlässigkeit enthält Details zu Benachrichtigungen zu SLOs.

Der falsche Ansatz beim Einführen eines neuen Beobachtbarkeitssystems wie einem SLO-System besteht darin, das alte System vollständig durch dieses System zu ersetzen. Stattdessen sollten Sie SLOs als ergänzendes System betrachten. Anstatt dass Sie z. B. die vorhandenen Benachrichtigungen löschen, sollten Sie dafür sorgen, dass diese parallel zu den hier vorgestellten SLO-Benachrichtigungen ausgeführt werden. Mit diesem Ansatz können Sie ermitteln, welche Legacy-Benachrichtigungen darauf hindeuten, dass auch SLO-Benachrichtigungen ausgelöst werden, welche Benachrichtigungen parallel zu den SLO-Benachrichtigungen ausgelöst werden und welche Benachrichtigungen nie ausgelöst werden.

Ein Prinzip des SRE besteht darin, dass Benachrichtigungen auf Grundlage von Symptomen und nicht auf Grundlage von Ursachen ausgelöst werden. Bei SLOs werden immer Symptome gemessen. Wenn Sie zunehmend mehr SLO-Benachrichtigungen integrieren, stellen Sie möglicherweise fest, dass eine Symptombenachrichtigung zusammen mit anderen Benachrichtigungen ausgelöst wird. Wenn Sie feststellen, dass die ursachenbasierten Legacy-Benachrichtigungen ausgelöst werden, ohne dass ein SLO betroffen ist oder Symptome aufgetreten sind, sollten Sie diese vollständig deaktivieren, in Ticketbenachrichtigungen umwandeln oder einfach für später in Logs speichern.

Weitere Informationen finden Sie im SRE-Workbook, Kapitel 5.

SLO-Brennrate

Der Durchsatz eines SLO ist ein Messwert dafür, wie schnell es bei einem Ausfall für Nutzer zu Fehlern kommt und das Fehlerbudget aufgebraucht ist. Durch das Messen des Durchsatzes können Sie die Zeit ermitteln, bis ein Dienst gegen sein SLO verstößt. Das Einrichten von Benachrichtigungen auf Basis des SLO-Durchsatzes ist ein guter Ansatz. Denken Sie daran, dass der SLO auf einer Zeitdauer basiert, die ziemlich lang sein kann (Wochen oder sogar Monate). Das Ziel besteht jedoch darin, schnell eine Bedingung zu ermitteln, die zu einem SLO-Verstoß führt, bevor dieser Verstoß tatsächlich auftritt.

Die folgende Tabelle zeigt die Zeitdauer, die zum Überschreiten eines Ziels erforderlich ist, wenn 100 % der Anfragen für das angegebene Intervall fehlschlagen, vorausgesetzt, die Abfragen pro Sekunde (Queries Per Second, QPS) sind konstant. Wenn Sie beispielsweise ein 99,9 %-SLO haben, das für einen Zeitraum von 30 Tagen gemessen wurde, ist während dieser 30 Tage eine Zeit von 43,2 Minuten tolerierbar, in denen ein vollständiger Ausfall vorlag. Diese Ausfallzeit kann beispielsweise auf einmal oder auf mehrere Vorfälle verteilt auftreten.

Ziel	90 Tage	30 Tage	7 Tage	1 Tag
90 %	9 Tage	3 Tage	16,8 Stunden	2,4 Stunden
99 %	21,6 Stunden	7,2 Stunden	1,7 Stunden	14,4 Minuten
99,9 %	2,2 Stunden	43,2 Minuten	10,1 Minuten	1,4 Minuten
99,99 %	13 Minuten	4,3 Minuten	1 Minute	8,6 Sekunden
99,99 %	1,3 Minuten	25,9 Sekunden	6 Sekunden	0,9 Sekunden

In der Praxis können Sie sich keine Vorfälle mit einem 100 %-Ausfall leisten, wenn Sie hohe Erfolgsquoten erreichen möchten. Viele verteilte Systeme können jedoch teilweise ausfallen oder ihre Leistung schrittweise herabsetzen. Auch in diesen Fällen möchten Sie wissen, ob ein Mensch eingreifen muss, selbst bei Teilausfällen. Mit SLO-Benachrichtigungen können Sie dies feststellen.

Zeitpunkt der Benachrichtigung

Eine wichtige Frage ist, wann anhand des SLO-Durchsatzes gehandelt werden sollte. Wenn das Fehlerbudget in 24 Stunden aufgebraucht sein wird, sollten Sie in der Regel jetzt jemanden zur Fehlerbehebung kontaktieren.

Das Messen der Fehlerrate ist nicht immer einfach. Eine Reihe kleinerer Fehler kann im Moment beunruhigend wirken, sich jedoch als kurzlebig erweisen und sich dann kaum auf das SLO auswirken. Wenn ein System dagegen über einen längeren Zeitraum leicht fehlerhaft ist, können diese Fehler in Summe zu einem SLO-Verstoß führen.

Im Idealfall reagiert Ihr Team so auf diese Signale, dass Sie in einem bestimmten Zeitraum fast das gesamte Fehlerbudget ausschöpfen, aber es nicht überschreiten. Wenn Sie das Budget überschreiten, verstoßen Sie gegen das SLO. Wenn zu wenige Fehler auftreten, gehen Sie nicht genug Risiken ein oder brennen möglicherweise Ihr Bereitschaftsteam aus.

Sie müssen eine Möglichkeit finden, um festzustellen, wann ein System so fehlerhaft ist, dass ein Mensch eingreifen sollte. In den folgenden Abschnitten werden einige Ansätze zum Beantworten dieser Frage erläutert.

Schneller Durchsatz

Eine Art des SLO-Durchsatzes ist der schnelle SLO-Durchsatz, da das Fehlerbudget schnell ausgeschöpft wird und Sie einschreiten müssen, um einen SLO-Verstoß zu vermeiden.

Angenommen, Ihr Dienst verarbeitet normalerweise 1.000 QPS und Sie möchten eine Verfügbarkeit von 99 % aufrechterhalten, die für einen Zeitraum von einer Woche gemessen wird. Ihr Fehlerbudget beträgt etwa 6 Millionen zulässige Fehler bei etwa 600 Millionen Anfragen. Wenn Sie beispielsweise noch 24 Stunden Zeit haben, bevor das Fehlerbudget aufgebraucht ist, liegt das Fehlermaximum bei etwa 70 Fehlern pro Sekunde oder 252.000 Fehlern pro Stunde. Diese Parameter basieren auf der allgemeinen Regel, dass auf Seiten aufteilbare Vorfälle mindestens 1 % des vierteljährlichen Fehlerbudgets aufbrauchen sollten.

Sie können diese Fehlerrate vor Ablauf der Stunde ermitteln. Wenn Sie beispielsweise 15 Minuten lang eine Rate von 70 Fehlern pro Sekunde beobachtet haben, können Sie den Bereitschaftsentwickler anrufen, wie das folgende Diagramm zeigt.

Im Idealfall wird das Problem gelöst, bevor eine Stunde der verbleibenden 24 Stunden vergangen ist. Wenn Sie diese Rate für ein kürzeres Zeitfenster (z. B. eine Minute) ermitteln möchten, kommt es wahrscheinlich zu einer zu großen Fehlerzahl. Wenn die Zielzeit für die Erkennung weniger als 15 Minuten beträgt, kann dieser Wert angepasst werden.

Langsames Brennen

Eine weitere Art des Durchsatzes ist ein langsamer Durchsatz. Nehmen Sie an, Sie führen einen Programmfehler ein, infolgedessen Ihr wöchentliches Fehlerbudget am fünften oder sechsten Tag oder das Monatsbudget nach der zweiten Woche aufgebraucht ist. Wie gehen Sie am besten damit um?

In diesem Fall können Sie eine Benachrichtigung zum langsamen SLO-Durchsatz einrichten, die Sie darüber informiert, dass Sie nach derzeitigem Stand das gesamte Fehlerbudget vor Ende des Benachrichtigungsfensters ausgeschöpft haben werden. Natürlich kann sich diese Warnung im Nachhinein oftmals als falsch erweisen. Es kann beispielsweise oft vorkommen, dass Fehler nur kurz auftreten, aber mit einer Rate, die das Fehlerbudget schnell ausschöpfen würde. In diesen Fällen wurde die Benachrichtigung zu Unrecht ausgelöst, da die Fehler nur für kurze Zeit aufgetreten sind und keine langfristige Gefahr besteht, dass das Fehlerbudget ausgeschöpft wird. Denken Sie daran, dass das Ziel nicht darin besteht, alle Fehlerquellen zu beseitigen, sondern sich innerhalb des zulässigen Bereichs zu bewegen, um das Fehlerbudget nicht zu überschreiten. Sie sollten vermeiden, dass ein Mitarbeiter per Benachrichtigung zum Eingreifen aufgefordert wird, wenn das entsprechende Ereignis gar nicht dazu führen wird, dass das Fehlerbudget ausgeschöpft wird.

Wir empfehlen Ihnen, bei Ereignisse mit langsamem Durchsatz eine Ticketwarteschlange zu benachrichtigen, anstatt den Mitarbeiter auszurufen, ihn anzupiepsen oder ihn per E-Mail zu benachrichtigen. Ereignisse mit langsamem Durchsatz sind keine Notfälle, erfordern aber dennoch die Aufmerksamkeit eines Mitarbeiters, bevor das Budget abläuft. Diese Warnungen sollten nicht per E-Mail an einen Teamverteiler geschickt werden, da solche E-Mails schnell ignoriert werden können. Tickets sollten nachverfolgbar, zuweisbar und übertragbar sein. Teams sollten Berichte zu Ticketbelastung, Erledigungsraten, Bearbeitbarkeit und Duplikatanteil erstellen. Übermäßig viele Tickets, aus denen sich keine Handlungen ableiten lassen, sind ein gutes Beispiel für mühevolle Arbeit.

Die gezielte Verwendung von SLO-Benachrichtigungen kann Zeit in Anspruch nehmen und hängt von der Kultur und den Erwartungen Ihres Teams ab. Vergessen Sie nicht, dass Sie die SLO-Benachrichtigungen auch im Laufe der Zeit optimieren können. Sie können je nach Bedarf auch mehrere Benachrichtigungsmethoden mit unterschiedlichen Benachrichtigungsfenstern verwenden.

Latenzbenachrichtigungen

Zusätzlich zu Verfügbarkeitsbenachrichtigungen können Sie auch Latenzbenachrichtigungen einrichten. Mit Latenz-SLOs messen Sie den Prozentsatz der Anfragen, für die ein Latenzziel nicht erreicht wird. Wenn Sie dieses Modell verwenden, können Sie dasselbe Benachrichtigungsmodell verwenden, mit dem Sie auch schnelle oder langsame Durchsätze in Bezug auf Ihr Fehlerbudget ermitteln.

Wie bereits erwähnt, kann bei SLOs mit Medianlatenz die Hälfte der Anfragen außerhalb des SLO liegen. Es kann also sein, dass Ihre Nutzer tagelang mit einer hohen Latenz zu kämpfen haben, bevor Sie deren Auswirkung auf Ihr langfristiges Fehlerbudget feststellen. Stattdessen sollten für Dienste Extremwertlatenzziele und typische Latenzziele definiert werden. Wir empfehlen, das historische 90. Perzentil zu verwenden, um die typische Latenz zu definieren, und das 99. Perzentil, um die Extremwertlatenz zu definieren. Nachdem Sie diese Ziele festgelegt haben, können Sie die SLOs basierend auf der Anzahl der Anfragen definieren, die laut Ihren Erwartungen in der jeweiligen Latenzkategorie landen und wie viele zu langsam sein werden. Dieser Ansatz entspricht dem Konzept eines Fehlerbudgets und sollte genauso behandelt werden. Ihre Aussage könnte also so lauten: "Bei 90 % der Anfragen wird die Verarbeitung innerhalb der typischen Latenzziele stattfinden und bei 99,9 % innerhalb der Ziele der Extremwertlatenz." Mit diesen Zielen sorgen Sie dafür, dass bei den meisten Nutzern die typische Latenz auftritt und können trotzdem nachverfolgen, wie viele Anfragen langsamer sind als es in den Extremwertlatenzzielen festgelegt ist.

Bei einigen Diensten variieren die erwarteten Laufzeiten möglicherweise stark. So kann es beispielsweise vorkommen, dass Sie beim Lesen aus einem Datenspeichersystem deutlich andere Leistungserwartungen als beim Schreiben in das Datenspeichersystem haben. Anstatt alle möglichen Erwartungen aufzuzählen, können Sie Laufzeitleistungs-Buckets einführen, wie in den folgenden Tabellen gezeigt. Bei diesem Ansatz wird davon ausgegangen, dass diese Anfragetypen identifizierbar sind und dem jeweiligen Bucket durch Vorkategorisieren zugeordnet wurden. Sie sollten nicht davon ausgehen, Anfragen dynamisch kategorisieren zu können.

Für den Nutzer sichtbare Website
Bucket	Erwartete maximale Laufzeit
Lesen	1 Sekunde
Schreiben/Aktualisieren	3 Sekunden

Datenverarbeitungssysteme
Bucket	Erwartete maximale Laufzeit
Klein	10 Sekunden
Mittel	1 Minute
Groß	5 Minuten
Riesig	1 Stunde
Riesengroß	8 Stunden

Indem Sie das aktuelle System messen, können Sie ermitteln, wie lange die Ausführung dieser Anfragen normalerweise dauert. Betrachten Sie als Beispiel ein System zum Verarbeiten von Videouploads. Wenn das Video sehr lang ist, sollte davon ausgegangen werden, dass die Verarbeitung länger dauert. Wir können die Länge des Videos in Sekunden verwenden, um diese Arbeit in einem Bucket zu kategorisieren, wie die folgende Tabelle zeigt. In der Tabelle werden die Anzahl der Anfragen pro Bucket sowie verschiedene Perzentile für die Laufzeitverteilung im Laufe einer Woche aufgezeichnet.

Videolänge	Anzahl der in einer Woche gemessenen Anfragen	10 %	90 %	99,95 %
Klein	0	-	–	-
Mittel	1,9 Millionen	864 Millisekunden	17 Sekunden	86 Sekunden
Groß	25 Millionen	1,8 Sekunden	52 Sekunden	9,6 Minuten
Riesig	4,3 Millionen	2 Sekunden	43 Sekunden	23,8 Minuten
Riesengroß	81.000	36 Sekunden	1,2 Minuten	41 Minuten

Aus einer solchen Analyse können Sie einige Parameter für Benachrichtigungen ableiten:

• fast_typical: Höchstens 10 % der Anfragen sind schneller als dieser Zeitwert. Wenn zu viele Anfragen schneller als dieser Zeitwert sind, sind Ihre Ziele möglicherweise inkorrekt oder es hat sich vielleicht etwas an Ihrem System geändert.
• slow_typical: Mindestens 90 % der Anfragen sind schneller als dieser Zeitwert. Durch dieses Limit wird Ihr Hauptlatenz-SLO bestimmt. Dieser Parameter gibt an, ob die meisten Anfragen schnell genug sind.
• slow_tail: Mindestens 99,95 % der Anfragen sind schneller als dieser Zeitwert. Mit diesem Limit wird sichergestellt, dass nicht zu viele langsame Anfragen vorhanden sind.
• deadline: Zeitpunkt, an dem ein Nutzer-RPC oder die Hintergrundverarbeitung das Zeitlimit überschreitet und fehlschlägt. Dieses Limit ist in der Regel bereits im System hartcodiert. Diese Anfragen sind nicht langsam, sondern schlagen mit einem Fehler fehl und werden stattdessen auf Ihr Verfügbarkeits-SLO angerechnet.

Eine Richtlinie beim Definieren von Buckets besteht darin, die Kategorien fast_typical, slow_typical und slow_tail eines Buckets in eine Größenordnung zueinander zu zwingen. Mit dieser Richtlinie wird sichergestellt, dass der Bucket nicht zu umfassend ist. Wir empfehlen, dass Sie nicht versuchen, Überschneidungen oder Lücken zwischen den Buckets zu vermeiden.

Bucket	fast_typical	slow_typical	slow_tail	deadline
Klein	100 Millisekunden	1 Sekunde	10 Sekunden	30 Sekunden
Mittel	600 Millisekunden	6 Sekunden	60 Sekunden (1 Minute)	300 Sekunden
Groß	3 Sekunden	30 Sekunden	300 Sekunden (5 Minuten)	10 Minuten
Riesig	30 Sekunden	6 Minuten	60 Minuten (1 Stunde)	3 Stunden
Riesengroß	5 Minuten	50 Minuten	500 Minuten (8 Stunden)	12 Stunden

Dies führt zu einer Regel wie api.method: SMALL => [1s, 10s]. In diesem Fall würde das SLO-Tracking-System eine Anfrage registrieren, den passenden Bucket ermitteln (möglicherweise durch Analysieren des Methodennamens oder URIs und Vergleichen des Namens mit einer Suchtabelle) und dann die Statistik anhand der Laufzeit dieser Anfrage aktualisieren. Wenn dies 700 Millisekunden gedauert hat, liegt die Anfrage innerhalb des Ziels slow_typical. Wenn es 3 Sekunden dauerte, liegt sie innerhalb von slow_tail. Wenn es 22 Sekunden dauerte, fällt sie nicht mehr in slow_tail, zählt jedoch noch nicht als Fehler.

Im Hinblick auf die Zufriedenheit der Nutzer können Sie sich Anfragen, deren Antwort die Extremwertlatenz überschreitet, so vorstellen, als wäre die Verfügbarkeit nicht gegeben. Die Antwort ist also so langsam, dass sie als "fehlgeschlagen" angesehen werden sollte. Aus diesem Grund empfehlen wir, denselben Prozentsatz wie für die Verfügbarkeit zu verwenden. Beispiel:

99,95 % aller Anfragen werden innerhalb von 10 Sekunden verarbeitet.

Was Sie als typische Latenz betrachten, liegt ganz bei Ihnen. Einige Teams bei Google halten 90 % für ein gutes Ziel. Dies hängt mit Ihrer Analyse und der Auswahl der Dauerwerte für slow_typical zusammen. Beispiel:

90 % aller Anfragen werden innerhalb einer Sekunde verarbeitet.

Vorgeschlagene Benachrichtigungen

Im Sinne dieser Richtlinien enthält die folgende Tabelle einen Vorschlag für einen grundlegenden Satz von SLO-Benachrichtigungen.

SLOs	Messfenster	Durchsatz	Aktion
Verfügbarkeit, schneller Durchsatz Typische Latenz Extremwertlatenz	Zeitfenster von einer Stunde	Weniger als 24 Stunden bis zum SLO-Verstoß	Jemanden ausrufen oder anpiepsen
Verfügbarkeit, langsamer Durchsatz Typische Latenz, langsamer Durchsatz Extremwertlatenz, langsamer Durchsatz	Fenster von sieben Tagen	Mehr als 24 Stunden bis zum SLO-Verstoß	Ein Ticket erstellen

Das Entwickeln von SLO-Benachrichtigungen kann einige Zeit in Anspruch nehmen. Die Dauerwerte in diesem Abschnitt sind Vorschläge. Sie können diese gemäß Ihrer eigenen Bedürfnisse und Genauigkeitslevels anpassen. Es kann hilfreich sein, die Benachrichtigungen mit dem Messfenster oder dem Ausschöpfungsgrad des Fehlerbudgets zu verknüpfen. Sie können alternativ auch eine weitere Benachrichtigungsebene zwischen dem schnellen Durchsatz und dem langsamen Durchsatz hinzufügen.

Sorgen Sie für mehr Beobachtbarkeit Ihrer Infrastruktur und Ihrer Anwendungen.

Dieses Dokument im Google Cloud-Architektur-Framework enthält Best Practices, mit denen Sie Ihre Dienste beobachtbar machen können, um die Leistung Ihres Dienstes besser zu verstehen und Probleme schnell zu identifizieren. Die Beobachtbarkeit umfasst Monitoring, Logging, Tracing, Profiling, Debugging und ähnliche Systeme.

Monitoring bildet die Basis der Dienstzuverlässigkeitshierarchie im Google-SRE-Handbuch. Ohne ein ordnungsgemäßes Monitoring können Sie nicht feststellen, ob eine Anwendung ordnungsgemäß funktioniert.

Instrumentieren Sie Ihren Code, um die Beobachtbarkeit zu maximieren.

Ein gut durchdachtes System zielt darauf ab, das richtige Maß an Beobachtbarkeit zu erhalten, die in der Entwicklungsphase beginnt. Warten Sie nicht, bis sich eine Anwendung in der Produktion befindet, bevor Sie anfangen, sie zu beobachten. Instrumentieren Sie Ihren Code und beachten Sie die folgenden Richtlinien:

• Für eine effiziente Fehlerbehebung müssen Sie überlegen, welche Log- und Trace-Einträge geschrieben werden sollen und welche Messwerte überwacht und exportiert werden sollen. Priorisieren Sie nach den wahrscheinlichsten oder häufigsten Fehlermodi des Systems.
• Prüfen und bereinigen Sie Ihr Monitoringsystem regelmäßig. Löschen Sie nicht verwendete oder nutzlose Dashboards, Grafiken, Benachrichtigungen, Tracing- und Logging-Daten, um überflüssige Daten zu entfernen.

Operations-Suite von Google Cloud bietet Echtzeit-Monitoring, Hybrid-Multi-Cloud-Monitoring und -Logging (z. B. für AWS und Azure) sowie Tracing, Profiling und Debugging. Die Operations-Suite von Google Cloud kann auch Mikrodienste automatisch erkennen und überwachen, die in App Engine oder in einem Service Mesh wie Istio ausgeführt werden.

Wenn Sie viele Anwendungsdaten generieren, können Sie die umfassende Aufnahme von Analyseereignislogs mit BigQuery optimieren. BigQuery eignet sich auch zum Speichern und Analysieren von Zeitachsendaten mit hoher Kardinalität aus Ihrem Monitoring-Framework. Dieser Ansatz ist nützlich, da Sie damit beliebige Abfragen zu geringeren Kosten ausführen können, statt das Monitoring von Anfang an perfekt zu planen, und die Berichterstellung vom Monitoring entkoppelt wird. Sie können aus den Daten Berichte mit Looker Studio oder Looker erstellen.

Empfehlungen

Befolgen Sie diese Empfehlungen, um die Anleitung im Architektur-Framework auf Ihre eigene Umgebung anzuwenden:

• Implementieren Sie das Monitoringsystem frühzeitig, z. B. bevor Sie eine Migration starten oder bevor Sie eine neue Anwendung in einer Produktionsumgebung bereitstellen.
• Unterscheiden Sie zwischen Anwendungsproblemen und zugrunde liegenden Cloud-Problemen. Verwenden Sie die Monitoring API oder andere Cloud Monitoring-Produkte und das Google Cloud Status-Dashboard.
• Definieren Sie neben dem Monitoring eine Strategie für Beobachtbarkeit, die Tracing, Profiling und Debugging umfasst.
• Bereinigen Sie regelmäßig Beobachtbarkeitsartefakte, die Sie nicht verwenden oder keinen Wert bieten, z. B. nicht umsetzbare Benachrichtigungen.
• Wenn Sie große Mengen an Beobachtbarkeitsdaten generieren, senden Sie Anwendungsereignisse an ein Data-Warehouse-System wie BigQuery.

Nächste Schritte

• Für Skalierung und Hochverfügbarkeit entwickeln (nächstes Dokument in dieser Reihe)

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance

Bei der Entwicklung für Skalierung und Hochverfügbarkeit sorgen

In diesem Dokument des Google Cloud-Architektur-Frameworks werden Designprinzipien erläutert, um Ihre Dienste so zu gestalten, dass sie fehlertolerant sind und entsprechend der Kundennachfrage skaliert werden können. Ein zuverlässiger Dienst kann auch dann Kundenanfragen beantworten, wenn eine hohe Nachfrage nach dem Dienst besteht oder wenn ein Wartungsereignis auftritt. Die folgenden Prinzipien und Best Practices für das Zuverlässigkeitsdesign sollten Teil Ihrer Systemarchitektur und Ihres Bereitstellungsplans sein.

Redundanz für höhere Verfügbarkeit schaffen

Systeme mit hohen Zuverlässigkeitsanforderungen dürfen keine Single Points of Failure haben. Ihre Ressourcen müssen über mehrere fehlerhafte Domains hinweg repliziert werden. Eine fehlerhafte Domain ist ein Pool von Ressourcen, die unabhängig voneinander ausfallen können, z. B. eine VM-Instanz, eine Zone oder eine Region. Wenn Sie über fehlerhafte Domains hinweg replizieren, erhalten Sie eine höhere aggregierte Verfügbarkeit, als es einzelne Instanzen erreichen könnten. Weitere Informationen finden Sie unter Regionen und Zonen.

Zur Isolierung von Fehlern bei der DNS-Registrierung in einzelne Zonen können Sie zonale DNS-Namen für Instanzen im selben Netzwerk verwenden, um aufeinander zuzugreifen. Dies wäre ein spezifisches Beispiel für Redundanz in Ihrer Systemarchitektur.

Mehrzonenarchitektur mit Failover für Hochverfügbarkeit entwerfen

Schützen Sie Ihre Anwendung gegen zonale Ausfälle, indem Sie sie für Ressourcenpools verwenden, die über mehrere Zonen verteilt sind – mit Datenreplikation, Load-Balancing und automatisiertem Failover zwischen den Zonen. Führen Sie zonale Replikate jeder Ebene des Anwendungspakets aus und entfernen Sie alle zonenübergreifenden Abhängigkeiten in der Architektur.

Daten über Regionen hinweg für die Notfallwiederherstellung replizieren

Replizieren oder archivieren Sie Daten in eine entfernte Region, um bei einem regionalen Ausfall oder einem Datenverlust eine Notfallwiederherstellung zu ermöglichen. Wenn die Replikation verwendet wird, ist die Wiederherstellung schneller, da Speichersysteme in der Remote-Region bereits Daten enthalten, die nahezu auf dem neuesten Stand sind. Es besteht weiter die Möglichkeit des Verlusts einer kleinen Datenmenge aufgrund der Replikationsverzögerung. Wenn Sie die regelmäßige Archivierung anstelle der kontinuierlichen Replikation verwenden, müssen Sie bei einer Notfallwiederherstellung Daten aus Sicherungen oder Archiven in einer neuen Region wiederherstellen. Dieses Verfahren führt in der Regel zu längeren Dienstausfällen als bei der Aktivierung eines kontinuierlich aktualisierten Datenbankreplikats und kann aufgrund der Zeitlücke zwischen aufeinanderfolgenden Sicherungsvorgängen zu mehr Datenverlust führen. Unabhängig vom verwendeten Ansatz muss das gesamte Anwendungspaket neu bereitgestellt und in der neuen Region gestartet werden. In diesem Fall ist der Dienst nicht verfügbar.

Ausführliche Informationen zu Konzepten und Techniken zur Notfallwiederherstellung finden Sie unter Architektur der Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur.

Multiregionale Architektur für Sicherheit gegen regionale Ausfälle entwerfen

Wenn Ihr Dienst auch im seltenen Fall, wenn eine ganze Region ausfällt, kontinuierlich ausgeführt werden muss, sollten Sie ihn so gestalten, dass er Pools von Rechenressourcen verwendet, die über verschiedene Regionen verteilt sind. Führen Sie regionale Replikate jeder Ebene des Anwendungspakets aus.

Verwenden Sie Datenreplikation über Regionen und automatisches Failover, wenn eine Region ausfällt. Einige Google Cloud-Dienste haben multiregionale Varianten wie Spanner. Verwenden Sie nach Möglichkeit diese multiregionalen Dienste in Ihrem Design, um es vor regionalen Ausfällen zu schützen. Weitere Informationen zu Regionen und Dienstverfügbarkeit finden Sie unter Google Cloud-Standorte.

Sorgen Sie dafür, dass keine regionenübergreifenden Abhängigkeiten vorhanden sind, damit die Auswirkungen eines Ausfalls auf Regionsebene auf diese Region beschränkt sind.

Beseitigen Sie regionale Single Points of Failure, z. B. eine primäre Datenbank in einer Region, die bei Nichterreichbarkeit einen globalen Ausfall verursachen kann. Multiregionale Architekturen kosten oft mehr. Berücksichtigen Sie daher die geschäftlichen Anforderungen und die Kosten, bevor Sie diesen Ansatz anwenden.

Weitere Informationen zur Implementierung der Redundanz in allen fehlerhaften domains finden Sie im Dokument Deployment-Archetypen für Cloudanwendungen (PDF).

Engpässe bei der Skalierbarkeit beseitigen

Ermitteln Sie Systemkomponenten, die nicht über die Ressourcenlimits einer einzelnen VM oder einer einzelnen Zone hinauswachsen können. Einige Anwendungen skalieren vertikal. Hierbei fügen Sie einer einzelnen VM-Instanz weitere CPU-Kerne, Arbeitsspeicher oder Netzwerkbandbreite hinzu, um den Anstieg der Last zu bewältigen. Die Skalierbarkeit dieser Anwendungen ist stark eingeschränkt. Sie müssen sie häufig manuell konfigurieren, um das Wachstum zu bewältigen.

Gestalten Sie diese Komponenten nach Möglichkeit neu, damit sie horizontal skaliert werden können, beispielsweise mit einer Fragmentierung oder Partitionierung über VMs oder Zonen. Fügen Sie weitere Shards hinzu, um das Wachstum des Traffics oder der Nutzung zu bewältigen. Verwenden Sie Standard-VM-Typen, die automatisch hinzugefügt werden können, um erhöhte Shard-Lasten zu bewältigen. Weitere Informationen finden Sie unter Muster für skalierbare und robuste Anwendungen.

Wenn Sie die Anwendung nicht neu entwerfen können, können Sie von Ihnen verwaltete Komponenten durch vollständig verwaltete Cloud-Dienste ersetzen, die für eine horizontale Skalierung ohne Nutzeraktion konzipiert sind.

Service-Levels bei Überlastung reibungslos heruntersetzen

Entwerfen Sie Ihre Dienste so, dass sie eine Überlastung tolerieren können. Dienste sollten eine Überlastung erkennen und Antworten mit geringerer Qualität an den Nutzer zurückgeben oder den Traffic teilweise unterbrechen, damit die Daten nicht vollständig überlastet werden.

So kann ein Dienst beispielsweise auf Nutzeranfragen mit statischen Webseiten reagieren und dynamisches Verhalten, das in der Verarbeitung teurer ist, vorübergehend deaktivieren. Dieses Verhalten ist im Warm-Failover-Muster von Compute Engine zu Cloud Storage ausführlich beschrieben. Alternativ kann der Dienst schreibgeschützte Vorgänge zulassen und Datenaktualisierungen vorübergehend deaktivieren.

Operatoren sollten benachrichtigt werden, um die Fehlerbedingung zu korrigieren, wenn ein Dienst beeinträchtigt wird.

Trafficspitzen verhindern und minimieren

Synchronisieren Sie keine Anfragen zwischen Clients. Wenn zu viele Clients gleichzeitig Traffic senden, verursacht dies Trafficspitzen, die zu kaskadierenden Fehlern führen können.

Implementieren Sie Strategien zur Minderung von Spitzen auf der Serverseite, wie z. B. Drosselung, Warteschlangen, Entlastung oder Schutzschaltung, graduelle Fehlertoleranz und Priorisierung kritischer Anfragen.

Strategien zur Risikominderung auf dem Client umfassen clientseitige Drosselung und exponentiellen Backoff mit Jitter.

Eingaben bereinigen und validieren

Um fehlerhafte, zufällige oder böswillige Eingaben zu verhindern, die Serviceausfälle oder Sicherheitsverstöße verursachen, sollten Sie die Eingabeparameter für APIs und operative Tools bereinigen und validieren. Apigee und Google Cloud Armor können beispielsweise vor Injektionsangriffen schützen.

Verwenden Sie regelmäßig Fuzzing-Tests, bei denen ein Test-Harnisch vorsätzlich APIs mit zufälligen, leeren oder zu großen Eingaben aufruft. Führen Sie diese Tests in einer isolierten Testumgebung durch:

Operative Tools sollten Konfigurationsänderungen automatisch validieren, bevor die Änderungen eingeführt werden, und Änderungen ablehnen, wenn die Validierung fehlschlägt.

Ausfallsicherheit unter Beibehaltung der Funktion

Wenn ein Problem auftritt, sollten die Systemkomponenten so ausfallen, dass das Gesamtsystem weiter funktioniert. Zu diesen Problemen zählen möglicherweise ein Softwarefehler, eine fehlerhafte Eingabe oder Konfiguration, ein ungeplanter Ausfall einer Instanz oder ein menschliches Versagen. Anhand des Prozesses, den Ihre Dienste durchlaufen, lässt sich feststellen, ob Sie übermäßig moderat oder übermäßig vereinfachend sein sollten, anstatt übermäßig restriktiv.

Betrachten Sie die folgenden Beispielszenarien und die Reaktion darauf, wie auf einen Fehler reagiert wird:

• In der Regel ist es besser, wenn eine Firewallkomponente mit einer fehlerhaften oder leeren Konfiguration "offen" ausfällt und nicht autorisierten Netzwerktraffic für kurze Zeit durchlässt, bis der Zuständige den Fehler behoben hat. Durch dieses Verhalten bleibt der Dienst verfügbar und fällt nicht geschlossen aus und blockiert den gesamten Traffic. Der Dienst muss sich dann auf Authentifizierungs- und Autorisierungsprüfungen im Anwendungs-Stack verlassen, um vertrauliche Bereiche zu schützen, während der gesamte Traffic weitergeleitet wird.
• Jedoch ist es besser, wenn eine Berechtigungsserverkomponente, die den Zugriff auf Nutzerdaten steuert, geschlossen ausfällt und jeden Zugriff blockiert. Dieses Verhalten führt zu einem Ausfall des Dienstes, wenn die Konfiguration beschädigt ist, vermeidet aber das Risiko eines Lecks vertraulicher Nutzerdaten, wenn sie offen ausfällt.

In beiden Fällen sollte der Fehler eine Benachrichtigung mit hoher Priorität auslösen, damit ein Operator die Fehlerbedingung beheben kann. Dienstkomponenten sollten dem Fehler standhalten, es sei denn, es birgt große Risiken für das Unternehmen.

API-Aufrufe und operative Befehle wiederholbar entwickeln

APIs und Tools müssen Aufrufe so weit wie möglich wiederholungssicher machen. Bei vielen Fehlerbedingungen wird oft versucht, die vorherige Aktion zu wiederholen, aber Sie wissen möglicherweise nicht, ob der erste Versuch erfolgreich war.

Ihre Systemarchitektur sollte dafür sorgen, dass Aktionen idempotent sind – wenn Sie die gleiche Aktion an einem Objekt zwei oder mehr Mal hintereinander ausführen, sollte dies zu den gleichen Ergebnissen führen wie ein einziger Aufruf. Nicht-idempotente Aktionen erfordern komplexeren Code, um eine Verfälschung des Systemzustands zu vermeiden.

Dienstabhängigkeiten erkennen und verwalten

Dienstdesigner und -inhaber müssen eine vollständige Liste von Abhängigkeiten von anderen Systemkomponenten verwalten. Das Dienstdesign muss auch die Wiederherstellung nach Abhängigkeitsfehlern oder eine graduelle Fehlertoleranz umfassen, wenn keine vollständige Wiederherstellung möglich ist. Berücksichtigen Sie Abhängigkeiten von Cloud-Diensten, die von Ihrem System und externen Abhängigkeiten verwendet werden, z. B. Dienst-APIs von Drittanbietern, wissend, dass jede Systemabhängigkeit eine Fehlerquote ungleich null hat.

Beachten Sie beim Festlegen von Zuverlässigkeitszielen, dass das SLO für einen Dienst mathematisch durch die SLOs aller kritischen Abhängigkeiten beschränkt ist. Sie können nicht zuverlässiger als das niedrigste SLO einer der Abhängigkeiten sein. Weitere Informationen finden Sie im Bereich der Dienstverfügbarkeit.

Startabhängigkeiten

Dienste verhalten sich im Vergleich zu ihrem stabilen Zustand-Verhalten beim Start anders. Startabhängigkeiten können sich erheblich von stabilen Zustand-Laufzeitabhängigkeiten unterscheiden.

So kann es beispielsweise sein, dass ein Service beim Start Nutzer- oder Kontoinformationen aus einem Nutzer-Metadatendienst laden muss, den er nur selten wieder aufruft. Wenn viele Dienstreplikate nach einem Absturz oder einer routinemäßigen Wartung neu gestartet werden, können die Replikate die Last für Startabhängigkeiten stark erhöhen, insbesondere wenn Caches leer sind und neu gefüllt werden müssen.

Testen Sie den Starts des Services unter Last und stellen Sie die Startabhängigkeiten entsprechend bereit. Ziehen Sie ein Design in Erwägung, das eine schrittweise Herabsetzung durch Speichern einer Kopie der Daten vorsieht, die es von kritischen Startabhängigkeiten abruft. Durch dieses Verhalten kann Ihr Service mit möglicherweise veralteten Daten neu gestartet werden, anstatt bei einem Ausfall einer kritischen Abhängigkeit nicht mehr starten zu können. Ihr Service kann später aktuelle Daten laden, wenn dies möglich ist, um zum normalen Betrieb zurückzukehren.

Startabhängigkeiten sind auch wichtig, wenn Sie einen Dienst in einer neuen Umgebung booten. Entwerfen Sie Ihren Anwendungs-Stack mit einer mehrschichtigen Architektur, ohne zyklische Abhängigkeiten zwischen den Schichten. Zyklische Abhängigkeiten scheinen vielleicht tolerierbar zu sein, da sie inkrementelle Änderungen an einer einzelnen Anwendung nicht blockieren. Durch zyklische Abhängigkeiten kann es jedoch schwierig oder unmöglich sein, einen Neustart auszuführen, wenn ein schwerwiegendes Ereignis den gesamten Dienst-Stack deaktiviert hat.

Kritische Abhängigkeiten minimieren

Minimieren Sie die Anzahl der kritischen Abhängigkeiten für Ihren Dienst, d. h. andere Komponenten, deren Fehler zu Ausfällen bei Ihrem Dienst führen. werden. Wenn Sie Ihren Dienst gegenüber Fehlern oder Verzögerungen bei anderen Komponenten, von denen er abhängig ist, stabiler machen möchten, sollten Sie die folgenden Methoden und Prinzipien des Beispieldesigns beachten, um kritische Abhängigkeiten in nicht kritische Abhängigkeiten umzuwandeln:

• Erhöhen Sie die Redundanzstufe in kritischen Abhängigkeiten. Weitere Replikate verringern die Wahrscheinlichkeit, dass eine ganze Komponente nicht mehr verfügbar ist.
• Verwenden Sie asynchrone Anfragen an andere Dienste, anstatt eine Antwort zu blockieren, oder veröffentlichen/abonnieren Sie Nachrichten, um Anfragen von Antworten zu entkoppeln.
• Speichern Sie Antworten von anderen Diensten im Cache, um eine Wiederherstellung nach kurzfristiger Nichtverfügbarkeit von Abhängigkeiten durchzuführen.

Berücksichtigen Sie die folgenden Beispieldesigntechniken und -prinzipien, um Fehler oder Langsamkeit in Ihrem Dienst für andere Komponenten, die davon abhängig sind, weniger schädlich zu machen:

• Verwenden Sie priorisierte Anfragewarteschlangen und weisen Sie Anfragen, bei denen ein Nutzer auf eine Antwort wartet, eine höhere Priorität zu.
• Stellen Sie Antworten aus einem Cache bereit, um Latenz und Last zu reduzieren.
• Ausfallsicherheit unter Beibehaltung der Funktion
• Setzen Sie bei Traffic-Überlastung die Dienstleistung schrittweise herab.

Gewährleisten, dass jede Änderung rückgängig gemacht werden kann

Wenn es keine klar definierte Möglichkeit gibt, bestimmte Arten von Änderungen an einem Dienst rückgängig zu machen, ändern Sie das Design des Dienstes so, dass ein Rollback unterstützt wird. Testen Sie die Rollback-Prozesse regelmäßig. APIs für jede Komponente oder jeden Mikrodienst müssen versionsverwaltet und abwärtskompatibel sein, damit die vorherige Generation von Clients weiterhin korrekt funktioniert, wenn die API weiterentwickelt wird. Dieser Gestaltungsgrundsatz ist unerlässlich, um eine schrittweise Einführung von API-Änderungen und bei Bedarf ein schnelles Rollback zu ermöglichen.

Ein Rollback kann für mobile Anwendungen teuer sein. Firebase Remote Config ist ein Google Cloud-Dienst, der das Rollback von Features vereinfacht.

Änderungen des Datenbankschemas können nicht einfach rückgängig gemacht werden. Führen Sie sie daher in mehreren Phasen aus. Entwerfen Sie jede Phase so, dass Anfragen zum sicheren Lesen und Aktualisieren des Schemas durch die neueste Version Ihrer Anwendung und die vorherige Version zugelassen werden. Dieser Designansatz ermöglicht ein sicheres Rollback, wenn ein Problem mit der neuesten Version auftritt.

Empfehlungen

Befolgen Sie diese Empfehlungen, um die Anleitung im Architektur-Framework auf Ihre eigene Umgebung anzuwenden:

• Implementieren Sie den exponentiellen Backoff mit zufälliger Anordnung in der Fehlerwiederholungslogik von Clientanwendungen.
• Implementieren Sie eine multiregionale Architektur mit automatischem Failover für Hochverfügbarkeit.
• Verwenden Sie Load-Balancing, um Nutzeranfragen auf Shards und Regionen zu verteilen.
• Entwickeln Sie die Anwendung so, dass sie ihre Leistung bei Überlastung schrittweise herabsetzt. Bieten Sie Teilantworten oder bieten Sie eingeschränkte Funktionen an, anstatt vollständig auszufallen.
• Richten Sie einen datengetriebenen Prozess für die Kapazitätsplanung ein und legen Sie mithilfe von Lasttests und Traffic-Prognosen fest, wann Ressourcen bereitgestellt werden sollten.
• Legen Sie Notfallwiederherstellungsverfahren fest und testen Sie sie regelmäßig.

Nächste Schritte

• Zuverlässige operative Prozesse und Tools erstellen (nächstes Dokument in dieser Reihe)

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance

Zuverlässige operative Prozesse und Tools erstellen

In diesem Dokument des Google Cloud-Architektur-Frameworks finden Sie Best Practices zum zuverlässigen Ausführen Ihres Dienstes, z. B. zum Bereitstellen von Aktualisierungen, zum Ausführen von Diensten in Produktionsumgebungen und zu Problemtests. Eine Architektur, die auf Zuverlässigkeit achtet, sollte den gesamten Lebenszyklus des Dienstes abdecken und nicht nur das Softwaredesign.

Geeignete Namen für Anwendungen und Dienste auswählen

Vermeiden Sie die Verwendung interner Codenamen in Produktionskonfigurationsdateien, da sie verwirrend sein können, insbesondere für neuere Mitarbeiter, wodurch die Zeit zur Problemminderung (TTM) bei Ausfällen möglicherweise länger wird. Wählen Sie nach Möglichkeit gute Namen für alle Ihre Anwendungen, Dienste und wichtigen Systemressourcen wie VMs, Cluster und Datenbankinstanzen, wobei die jeweiligen Längenbeschränkungen gelten. Ein guter Name beschreibt den Zweck der Entität. Er ist präzise, spezifisch und unverwechselbar; und ist für jeden verständlich, der ihn sieht. Ein guter Name hat keine Akronyme, Codenamen, Abkürzungen und potenziell anstößige Terminologie. Außerdem verursacht er keine negative öffentliche Reaktion, wenn er extern veröffentlicht wird.

Schrittweise Rollouts mit Canary-Tests implementieren

Sofortige globale Änderungen an Dienstbinärdateien oder -konfigurationen sind mit Risiken verbunden. Führen Sie neue Versionen ausführbarer Dateien und Konfigurationsänderungen schrittweise ein. Beginnen Sie mit einem kleinen Bereich, z. B. einigen VM-Instanzen in einer Zone, und erweitern Sie dann den Bereich schrittweise. Es kann schnell ein Rollback durchgeführt werden, wenn die Änderung nicht Ihren Erwartungen entspricht oder die Nutzer in jeder Phase der Einführung negativ beeinflusst. Ihr Ziel ist es, Programmfehler zu erkennen und zu beheben, wenn sie nur einen kleinen Teil des Nutzertraffics betreffen, bevor Sie die Änderung global einführen.

Richten Sie ein Canary-Testsystem ein, das Dienständerungen erkennt und einen A/B-Vergleich der Messwerte der geänderten Server mit den verbleibenden Servern durchführt. Das System sollte unerwartetes oder ungewöhnliches Verhalten melden. Wenn die Änderung nicht wie erwartet funktioniert, sollte das Canary-Testsystem Rollouts automatisch anhalten. Probleme können offensichtlich sein, z. B. Nutzerfehler, oder geringfügig, wie die Erhöhung der CPU-Auslastung oder ein überhöhtes Speichervolumen.

Es ist besser, beim ersten Hinweis auf ein Problem zu stoppen, ein Rollback durchzuführen und die Probleme ohne die bei einem Ausfall unvermeidliche Eile zu diagnostizieren. Nachdem die Änderung den Canary-Test bestanden hat, geben Sie sie nach und nach an größere Bereiche weiter, z. B. erst an eine gesamte Zone und dann an eine weitere Zone. Warten Sie, während das geänderte System immer größere Mengen an Nutzertraffic verarbeitet, um eventuell latente Probleme zu erkennen.

Weitere Informationen finden Sie unter Strategien für Bereitstellung und Tests von Anwendungen.

Traffic für zeitlich begrenzte Werbeaktionen und Markteinführungen verteilen

Möglicherweise gibt es Werbeaktionen, z. B. Rabatte, die zu einem bestimmten Zeitpunkt beginnen und viele Nutzer gleichzeitig dazu anregen, sich mit dem Dienst zu verbinden. Falls ja, entwerfen Sie Clientcode, um den Traffic über einige Sekunden zu verteilen. Verwenden Sie zufällige Verzögerungen, bevor sie Anfragen initiieren.

Sie können das System auch vorwärmen. Wenn Sie das System vorwärmen, senden Sie das voraussichtlich erwartete Volumen an Nutzertraffic im Voraus, um zu prüfen, ob die Leistung Ihren Erwartungen entspricht. Durch ein solches Design werden plötzlich auftretende Trafficspitzen verhindert, die Ihre Server zum geplanten Beginn zum Absturz bringen könnten.

Erstellung, Test und Bereitstellung automatisieren

Verringern Sie den manuellen Aufwand Ihres Releaseprozesses durch die Verwendung von Continuous Integration- und Continuous Delivery-Pipelines (CI/CD). Führen Sie automatisierte Integrationstests und Bereitstellungen durch. Erstellen Sie beispielsweise einen modernen CI-/CD-Prozess mit GKE.

Weitere Informationen finden Sie unter Continuous Integration, Continuous Delivery, Testautomatisierung und Bereitstellungsautomatisierung.

Schutz vor Operatorfehlern implementieren

Entwickeln Sie Ihre Betriebstools, um potenziell ungültige Konfigurationen abzulehnen. Erkennen und benachrichtigen, wenn eine Konfigurationsversion leer, teilweise oder gekürzt, beschädigt, logisch falsch oder unerwartet ist oder nicht innerhalb der erwarteten Zeit empfangen wird. Tools sollten auch Konfigurationsversionen ablehnen, die sich zu stark von der vorherigen Version unterscheiden.

Vermeide Änderungen oder Befehle mit einem zu umfassenden Bereich, die potenziell destruktiv sein können. Diese allgemeinen Befehle können "Berechtigungen für alle Nutzer widerrufen", "Alle VMs in dieser Region neu starten" oder "Alle Laufwerke in dieser Zone neu formatieren" sein. Änderungen sollten nur angewendet werden, wenn der Operator beim Bereitstellen der Konfiguration Befehlszeilen-Flags oder Optionseinstellungen zur Notfall-Überschreibung hinzugefügt hat.

Die Tools müssen die mögliche Wirkungen riskanter Befehle darstellen, z. B. die Anzahl der VMs, auf die sich die Änderungen auswirken. Weiter muss eine explizite Bestätigung des Operators nötig sein, bevor das Tool fortgesetzt wird. Um wichtige Ressourcen zu sperren und deren versehentliches oder nicht autorisiertes Löschen zu verhindern können Sie Funktionen wie das Sperren von Cloud Storage-Aufbewahrungsrichtlinien nutzen.

Test auf Wiederherstellung nach Fehlern

Testen Sie Ihre betrieblichen Abläufe zur Wiederherstellung nach Dienstausfällen regelmäßig. Ohne regelmäßige Tests greifen Ihre Abläufe möglicherweise nicht, sollten Sie sie benötigen, wenn ein echter Fehler auftritt. Zu den Elementen, die regelmäßig getestet werden sollten, gehören der regionale Failover, das Rollback eines Releases und die Wiederherstellung von Daten aus Back-ups.

Notfallwiederherstellungstests anwenden

Wie bei Tests zur Wiederherstellung nach Fehlern sollten Sie hier nicht darauf warten, bis eine Katastrophe passiert. Testen und prüfen Sie Ihre Abläufe und Prozesse zur Notfallwiederherstellung regelmäßig.

Vielleicht erstellen Sie eine Systemarchitektur, um Hochverfügbarkeit bereitzustellen. Eine solche Architektur überschneidet sich nicht vollständig mit der Notfallwiederherstellung (DR, Disaster Recovery), muss aber häufig in Überlegungen zu RTO- (Recovery Time Objective) und RPO-Werten (Recovery Point Objective) einbezogen werden.

HA hilft Ihnen dabei, eine vereinbarte Betriebsleistung zu erreichen oder zu übertreffen, z. B. die Betriebszeit. Wenn Sie Produktionsarbeitslasten in Google Cloud ausführen, können Sie eine passive oder aktive Standby-Instanz in einer zweiten Region bereitstellen. Bei dieser Architektur stellt die Anwendung weiterhin Dienste aus der nicht betroffenen Region bereit, wenn es in der primären Region eine Katastrophe gibt. Weitere Informationen finden Sie unter Architektur der Notfallwiederherstellung bei Cloudausfällen.

Chaos Engineering üben

Erwägen Sie den Einsatz von Chaos Engineering in Testpraktiken. Führen Sie in einer sicheren Umgebung tatsächliche Fehler in verschiedene Komponenten von Produktionssystemen unter Last ein. Dieser Ansatz hilft, allgemeinen Systemauswirkungen vorzubeugen, da Ihr Dienst Fehler auf jeder Ebene ordnungsgemäß verarbeitet.

In das System eingeschleuste Probleme können Absturzaufgaben, Fehler und Zeitüberschreitungen bei RPCs und eine Reduzierung der Ressourcenverfügbarkeit umfassen. Verwenden Sie zufällige Fehlerinjektionen, um zeitweise Probleme (flapping) in Dienstabhängigkeiten zu testen. Solches Verhalten ist in der Produktion schwer zu erkennen und zu minimieren.

Chaos Engineering sorgt dafür, dass die Auswirkungen solcher Experimente minimiert und beschränkte bleiben. Behandeln Sie solche Tests als Praxis für tatsächliche Ausfälle und nutzen Sie alle erfassten Informationen, um Ihre Ausfallreaktion zu verbessern.

Nächste Schritte

• Effiziente Benachrichtigungen erstellen (nächstes Dokument in dieser Reihe)

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance

Effiziente Benachrichtigungen erstellen

Dieses Dokument im Google Cloud-Architektur-Framework enthält Betriebsprinzipien zum Erstellen von Benachrichtigungen, die Ihnen beim Ausführen zuverlässiger Dienste helfen. Je mehr Informationen Sie über die Leistung Ihres Dienstes haben, desto besser sind Ihre Entscheidungen über ein Problem. Gestalten Sie Ihre Benachrichtigungen so, dass alle nutzerrelevanten Systemprobleme frühzeitig und genau erkannt und falsch positive Ergebnisse minimiert werden.

Benachrichtigungsverzögerung optimieren

Zu früh gesendete Benachrichtigungen, durch die das operative Team überlastet wird, und zu spät gesendete Benachrichtigungen, die lange Dienstausfälle verursachen, sollten in ein Gleichgewicht gebracht werden. Passen Sie die Benachrichtigungsverzögerung an, nach der das Monitoringsystem Personen über ein Problem benachrichtigt. Dadurch minimieren Sie die Zeit zur Erkennung und maximieren gleichzeitig das Signal-zu-Rausch-Verhältnis. Verwenden Sie die Fehlerbudget-Verbrauchsrate, um die optimale Benachrichtigungskonfiguration zu ermitteln.

Benachrichtigung bei Symptomen statt Ursachen

Lösen Sie Benachrichtigungen auf Basis der direkten Auswirkungen auf die Nutzererfahrung aus. Die Nichteinhaltung globaler oder kundenspezifischer SLOs weist auf eine direkte Auswirkung hin. Senden Sie Warnungen nicht bei jeder möglichen Ursache für einen Fehler, besonders wenn die Auswirkungen auf ein einzelnes Replikat beschränkt sind. Ein gut durchdachtes verteiltes System wird nahtlos wiederhergestellt, wenn ein einzelnes Replikat ausfällt.

Benachrichtigung über Ausreißerwerte anstelle von Durchschnittswerten

Definieren Sie beim Überwachen der Latenz SLOs und legen Sie Benachrichtigungen für Latenzen für das 90., 95. oder 99. Perzentil fest (zwei von drei auswählen), nicht für die durchschnittliche oder die 50. Perzentillatenz. Gute Werte für durchschnittliche oder Median-Latenz können inakzeptabel hohe Werte beim 90. Perzentil oder höher verbergen, die zu einer sehr schlechten Nutzererfahrung führen. Daher sollten Sie dieses Prinzip der Benachrichtigung bei Ausreißerwerten anwenden, wenn die Latenz bei kritischen Vorgängen überwacht wird, z. B. bei einer Anfrage-Antwort-Interaktion mit einem Webserver, einer Batchabschluss in einer Datenverarbeitungspipeline oder einem Lesevorgang oder Schreibvorgang in einem Speicherdienst.

Gemeinsamen Prozess für Vorfallmanagement aufbauen

Dieses Dokument im Google Cloud-Architektur-Framework enthält Best Practices zum Verwalten von Diensten und zum Definieren von Prozessen, um auf Vorfälle zu reagieren. Vorfälle treten in allen Diensten auf. Daher ist ein gut dokumentierter Prozess erforderlich, um diese Probleme effizient zu beheben und zu minimieren.

Übersicht über das Vorfallmanagement

Es ist unvermeidlich, dass Ihr gut konzipiertes System irgendwann seine SLOs nicht mehr erfüllt. Ohne eines SLOs definieren Ihre Kunden das akzeptable Serviceniveau aufgrund ihrer bisherigen Erfahrungen selbst. Die Kunden wenden sich an Ihren technischen Support oder eine ähnliche Gruppe, unabhängig davon, was in Ihrem SLA steht.

Um Ihren Kunden einen angemessenen Service zu bieten, sollten Sie einen Plan für das Vorfallmanagement erstellen und regelmäßig testen. Der Plan kann so kurz sein wie eine einseitige Checkliste mit zehn Punkten. Dieser Prozess hilft Ihrem Team, die Zieldiagnosezeit (TTD) und die Zeit zur Problem-Reduzierung (TTM) zu reduzieren.

TTM wird im Gegensatz zu TTR bevorzugt, wobei mit dem R für Repair (Reparatur) oder Recovery (Wiederherstellung) häufig eine vollständige Korrektur im Vergleich zu Problemminderung gemeint ist. TTM legt den Schwerpunkt auf eine schnelle Schadensbegrenzung, um die Auswirkungen eines Ausfalls auf die Kunden schnell zu beenden, und beginnt dann mit dem oft viel längeren Prozess zur vollständigen Behebung des Problems.

Ein gut konzipiertes System, bei dem Vorgänge hervorragend sind, erhöht die Zeit zwischen Fehlern (TBF). Mit anderen Worten, die Betriebsgrundsätze für Zuverlässigkeit, einschließlich eines guten Vorfallmanagements, versuchen, Fehler weniger häufig zu vermeiden.

Um zuverlässige Services auszuführen, wenden Sie die folgenden Best Practices für Ihren Vorfallmanagement-Prozess an.

Klare Dienstinhaberschaft zuweisen

Alle Services und ihre kritischen Abhängigkeiten müssen klare Inhaber haben, die für die Einhaltung ihrer SLOs verantwortlich sind. Bei Reorganisationen oder Abzügen durch das Team muss die Leitenden Mitarbeiter der Entwicklung darauf achten, dass die Inhaberschaft zusammen mit der Dokumentation und der Schulung explizit an ein neues Team übergeben wird. Die Inhaber eines Service müssen für andere Teams leicht auffindbar sein.

Zeit zur Erkennung (Time to detect, TTD) mit gut abgestimmten Benachrichtigungen reduzieren

Bevor Sie die TTD reduzieren können, sollten Sie die Empfehlungen in den Abschnitten Für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen sorgen und Zuverlässigkeitsziele definieren der Zuverlässigkeitskategorie des Architektur-Frameworks überprüfen und umsetzen. Unterscheiden Sie beispielsweise zwischen Anwendungsproblemen und zugrunde liegenden Cloud-Problemen.

Mit gut abgestimmten SLIs wird Ihr Team zur richtigen Zeit benachrichtigt, ohne dass es zu einer Überlastung mit Benachrichtigungen kommt. Weitere Informationen finden Sie im Abschnitt Effiziente Benachrichtigungen erstellen in der Zuverlässigkeitskategorie des Architektur-Frameworks oder unter SLI-Messwerte optimieren: CRE Life Lessons.

Zeit zur Problemminderung (Time to Mitigate, TTM) durch Vorfallmanagementpläne und -schulungen verkürzen

Um die TTM zu reduzieren, sollten Sie einen dokumentierten und gut geübten Plan für das Vorfallmanagement erstellen. Sie sollten leicht zugängliche Daten darüber haben, was sich in der Umgebung geändert hat. Sorgen Sie dafür, dass Teams allgemeine Schadensbegrenzungen kennen, die sie schnell anwenden können, um die TTM zu minimieren. Diese Maßnahmen umfassen Draining, Rollback von Änderungen, Ressourcen erweitern und Verschlechtern der Dienstqualität.

Wie in einer anderen Kategoriedokument zur Architektur-Frameworks-Zuverlässigkeit erörtert, sollten Sie zuverlässige betriebliche Prozesse und Tools entwickeln, um ein sicheres und schnelles Rollback von Änderungen zu ermöglichen.

Dashboard-Layouts und Inhalte gestalten, um die TTM zu minimieren

Organisieren Sie das Layout und die Navigation Ihres Dienst-Dashboards so, dass ein Operator innerhalb von ein oder zwei Minuten feststellen kann, ob der Dienst sowie alle seine kritischen Abhängigkeiten laufen. Um mögliche Problemursachen schnell ausfindig zu machen, müssen die Operatoren auf alle Diagramme auf dem Dashboard zugreifen können, um schnell nach Diagrammen zu suchen, die sich zum Zeitpunkt der Benachrichtigung signifikant verändern.

Die folgende Liste mit Beispieldiagrammen kann sich auf Ihrem Dashboard befinden, um Probleme zu beheben. Das Vorfallmanagementteam sollte sie in einer einzigen Ansicht parat haben und ansehen können:

• Service Level Indicators, z. B. erfolgreiche Anfragen geteilt durch die Gesamtzahl der gültigen Anfragen
• Konfiguration und binäre Rollouts
• Anfragen pro Sekunde an das System
• Fehlerantworten pro Sekunde vom System
• Anfragen pro Sekunde vom System an seine Abhängigkeiten
• Fehlerantworten pro Sekunde an das System von seinen Abhängigkeiten

Weitere gängige Diagramme, die bei der Fehlersuche helfen, sind für Latenz, Sättigung, Anfragegröße, Antwortgröße, Abfragekosten, Thread-Pool-Auslastung und Java Virtual Machine (JVM)-Messwerten (falls zutreffend). Sättigung bezieht sich auf die Auslastung durch einen Grenzwert wie die Quote oder die Größe des Systemspeichers. Bei der Thread-Pool-Auslastung wird nach Rückschritten aufgrund einer Erschöpfung des Pools gesucht.

Testen Sie die Platzierung dieser Diagramme anhand einiger Ausfallszenarien, damit die wichtigsten Diagramme ganz oben stehen und damit die Reihenfolge der Diagramme Ihrem Standard-Diagnose-Workflow entspricht. Sie können auch maschinelles Lernen und die statistische Erkennung von Anomalien einsetzen, um die richtige Teilmenge dieser Diagramme zu ermitteln.

Verfahren zur Dokumentdiagnose und Abhilfe für bekannte Ausfallszenarien

Schreiben Sie Playbooks und verknüpfen Sie sie mit den Benachrichtigungen. Wenn diese Dokumente von den Benachrichtigungen aus zugänglich sind, können die Operatoren schnell die Informationen abrufen, die sie für die Fehlerbehebung von Problemen benötigen.

Nachbesprechung ohne Schuldzuweisung nutzen, um von Ausfällen zu lernen und Wiederholungen zu verhindern

Etablieren Sie eine Nachbesprechungskultur ohne Schuldzuweisung und einen Prozess zur Überprüfung von Vorfällen. Ohne Schuldzuweisung bedeutet, dass Ihr Team objektiv bewertet und dokumentiert, was schief gelaufen ist, ohne Schuldzuweisungen vorzunehmen.

Fehler sind eine Gelegenheit zum Lernen und kein Grund zur Kritik. Versuchen Sie immer, das System stabiler zu machen, damit es sich schnell von menschlichen Fehlern erholen kann, oder noch besser, damit es menschliche Fehler erkennen und verhindern kann. Extrahieren Sie aus jedem Postmortem so viel Erkenntnisse wie möglich und nachbearbeiten Sie sorgfältig jedes Postmortem-Aufgabe, um Ausfälle weniger häufig zu machen und dadurch die TBF zu erhöhen.

Beispiel für einen Vorfallmanagementplan

Produktionsprobleme wurden erkannt, z. B. durch eine Benachrichtigung oder eine Seite, oder sie wurden an mich weitergeleitet:

• Sollte ich an eine andere Person delegieren?
  • Ja, wenn Sie und Ihr Team das Problem nicht lösen können.
• Handelt es sich um einen Datenschutz- oder Sicherheitsverstoß?
  • Wenn ja, delegieren Sie diesen an das Datenschutz- oder Sicherheitsteam.
• Ist es ein Notfall oder sind SLOs gefährdet?
  • Im Zweifelsfall sollten Sie den Vorfall als Notfall behandeln.
• Sollte ich weitere Personen einbeziehen?
  • Ja, wenn mehr als X % der Kunden betroffen sind oder die Behebung mehr als Y Minuten dauert. Im Zweifelsfall sollten Sie immer mehr Personen einbeziehen, insbesondere während der Geschäftszeiten.
• Definieren Sie einen primären Kommunikationskanal wie IRC, Hangouts Chat oder Slack.
• Delegieren Sie zuvor definierte Rollen wie die folgenden:
  • Incident Commander, der für die Gesamtkoordinierung verantwortlich ist.
  • Communications Lead, der für die interne und externe Kommunikation verantwortlich ist
  • Operations Lead, der dafür verantwortlich ist, das Problem zu minimieren.
• Definieren Sie, wann der Vorfall als beendet gilt. Dafür ist möglicherweise eine Bestätigung durch einen Supportmitarbeiter oder ein ähnliches Team erforderlich.
• Zusammenarbeit in der Nachbesprechung ohne Schuldzuweisung
• Nehmen Sie an einer Nachbesprechung zur Überprüfung von Vorfällen teil, um Aufgaben zu besprechen und an Mitarbeiter zu verteilen.

Empfehlungen

Befolgen Sie diese Empfehlungen, um die Anleitung im Architektur-Framework auf Ihre eigene Umgebung anzuwenden:

• Legen Sie einen Plan für das Vorfallsmanagement fest und schulen Sie Ihre Teams in der Verwendung dieses Plans.
• Wenn Sie die TTD reduzieren möchten, implementieren Sie die Empfehlungen, um für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen zu sorgen.
• Erstellen Sie ein "Was hat sich geändert?"-Dashboard, auf das Sie bei einem Vorfall einen Blick werfen können.
• Dokumentieren Sie Abfrage-Snippets oder erstellen Sie ein Looker Studio-Dashboard mit häufigen Logabfragen.
• Prüfen Sie Firebase Remote Config, um Rollout-Probleme bei mobilen Anwendungen zu minimieren.
• Testen Sie die Wiederherstellung nach Fehlern, einschließlich der Wiederherstellung von Daten aus Sicherungen, um die TTM für einen Teil Ihrer Vorfälle zu reduzieren.
• Entwerfen und testen Sie Konfigurationen und binäre Rollbacks.
• Replizieren Sie Daten für die Notfallwiederherstellung regionenübergreifend und verwenden Sie Notfallwiederherstellungstests, um die TTM nach regionalen Ausfällen zu reduzieren.
• Erstellen Sie eine multiregionale Architektur, um Widerstandsfähigkeit gegen regionale Ausfälle zu gewährleisten, wenn das Hochverfügbarkeitsbedürfnisse des Unternehmens die Kosten rechtfertigt, um so TBF zu erhöhen.

Nächste Schritte

Weitere Informationen zum Erstellen eines kollaborativen Vorfallmanagementprozesses finden Sie in den folgenden Ressourcen:

• Google Cloud-Status-Dashboard
• Vorfallmanagement bei Google
• Reaktion auf Vorfälle im Zusammenhang mit Kundendaten
• Kapitel zum Umgang mit Vorfällen im SRE-Buch

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance

Architektur-Framework von Google Cloud: Leitfäden zur Produktzuverlässigkeit

Dieser Abschnitt im Architektur-Framework enthält produktspezifische Best Practices für die Zuverlässigkeit, Verfügbarkeit und Konsistenz einiger Google Cloud-Produkte. Die Leitfäden enthalten auch Empfehlungen zur Minimierung von Ausfällen und zur Wiederherstellung danach sowie zur Skalierung Ihrer Anwendungen unter Last.

Hinweis: Informationen zu Zuverlässigkeitsbausteinen auf Plattformebene in Google Cloud (Zonen, Regionen und standortbezogene Ressourcen) und zu den Verfügbarkeitsstufen finden Sie im Leitfaden zur Zuverlässigkeit der Infrastruktur von Google Cloud. Dieser Leitfaden enthält auch Richtlinien zum Bewerten der Zuverlässigkeitsanforderungen Ihrer Arbeitslasten sowie Architekturempfehlungen zum Erstellen und Verwalten einer zuverlässigen Infrastruktur in Google Cloud.

Die Leitfäden zur Produktzuverlässigkeit sind in folgenden Bereichen organisiert:

• Computing
  • Compute Engine
  • Cloud Run
  • Cloud Functions
  • Google Kubernetes Engine
• Speicher und Datenbanken
  • Cloud Storage
  • Firestore
  • Bigtable
  • Cloud SQL
  • Spanner
  • Filestore
  • Memorystore
• Netzwerk
  • Cloud DNS
  • Cloud Load Balancing
  • Cloud CDN
• Datenanalyse
  • BigQuery
  • Dataflow
  • Dataproc

Leitfaden zur Zuverlässigkeit von Compute Engine

Compute Engine ist ein anpassbarer Computing-Dienst, mit dem Nutzer nach Bedarf virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.

Best Practices

• Best Practices für die Compute Engine API – empfohlene Best Practices zur Verwendung der Compute Engine API und zur Minderung der Auswirkungen von API-Ratenbegrenzungen.
• Stabile Systeme konzipieren – detaillierte Anleitungen zur Gestaltung Ihrer Compute Engine-Anwendungen, um eine Wiederherstellung nach Ausfällen einzelner VMs oder Neustarts sowie zonalen oder regionalen Ausfällen zu gewährleisten.
• Verfügbarkeit durch Überdimensionierung erhöhen – fügen Sie redundante Ressourcen hinzu, um Ihre Anwendung bei Kapazitätsverlusten aufgrund von zonalen oder regionalen Störungen am Laufen zu halten.
• Load-Balancing für hochverfügbare Anwendungen verwenden – wie Sie Cloud Load Balancing mit Compute Engine verwenden, um Hochverfügbarkeit auch bei einem Zonenausfall zu gewährleisten
• Best Practices zur Regionsauswahl in Compute Engine – Informationen dazu, wie Sie die Google Cloud-Regionen auswählen, die für Ihre Compute Engine-Ressourcen verwendet werden sollen, um die Latenz für Ihre Anwendungen zu optimieren und gleichzeitig Kompromisse zwischen Preis und Leistung zu berücksichtigen.
• Best Practices für die Migration von VMs mit Migrate zu virtuellen Maschinen – Hier erfahren Sie, wie Sie VMs mit Migrate zu virtuellen Maschinen von einer unterstützten Quellumgebung zu Compute Engine migrieren, einschließlich Bewertung, Planung und Durchführung der Migration. Außerdem erfahren Sie, wie Sie häufige Probleme bei der Migration beheben können.
• Muster für die Verwendung von Floating-IP-Adressen in Compute Engine – Erfahren Sie, wie Sie freigegebene oder virtuelle IP-Adressen in einer Compute Engine-Umgebung implementieren. Ändern Sie dazu die Architektur in ein Muster für Ihren Anwendungsfall. Zu den Mustern gehören jene, die das Load-Balancing, Google Cloud-Routen und die automatische Reparatur verwenden.
• Best Practices für Snapshots nichtflüchtiger Speicher – erstellen Sie Snapshots schneller und mit höherer Zuverlässigkeit.
• Nichtflüchtige Speicher und Replikation – wie nichtflüchtige Speicher Colossus für das Speicher-Backend verwenden und von VMs auf nichtflüchtige Speicher zugreifen Auch die Überwachung der Latenz nichtflüchtiger Speicher, die Replikation von nichtflüchtigem Speicher zwischen Regionen oder Zonen sowie die Verarbeitung von Lese- und Schreibanfragen für Replikate.
• Laufwerke so konfigurieren, dass sie die Leistungsanforderungen erfüllen – Faktoren, die sich auf die Leistung von Blockspeicher-Volumes auswirken, die an VM-Instanzen angehängt sind.
• Best Practices für die Imageverwaltung – Ausführliche Anleitung zur Verwaltung von Compute Engine-Images, z. B. zur Auswahl eines Boot-Images, zur Anpassung von Images, für den Image-Lebenszyklus und für die Freigabe von Images für Projekte.
• Best Practices für Image-Familien – die Bedeutung des Testens des neuesten Images in einer Image-Familie, bevor es in der Produktion verwendet wird, und die Einrichtung des Testverfahrens.
• Best Practices für SQL Server-Instanzen: Best Practices zur Optimierung von Compute Engine-Instanzen, die Microsoft SQL Server ausführen, und zur Optimierung der SQL Server Enterprise Edition. Außerdem erfahren Sie, wie Sie die Standardnetzwerkeinstellungen des Betriebssystems und die operativen Aktivitäten verwenden, um die Leistung und Stabilität zu erhöhen.

Leitfaden zur Zuverlässigkeit von Cloud Run

Cloud Run ist eine verwaltete Computing-Plattform für die Bereitstellung von containerisierten Anwendungen und ist serverlos. Bei Cloud Run wird die Infrastruktur abstrahiert, sodass sich Nutzer auf das Erstellen von Anwendungen konzentrieren können.

Best Practices

• Allgemeine Tipps zu Cloud Run – Hier erfahren Sie, wie Sie einen Cloud Run-Dienst implementieren, Container schnell starten, globale Variablen verwenden und die Sicherheit von Containern verbessern.
• Best Practices für Lasttests: Informationen zum Lasttest von Cloud Run-Diensten, einschließlich der Behebung von Gleichzeitigkeitsproblemen vor dem Lasttest, zur Verwaltung der maximalen Anzahl von Instanzen, zur Auswahl der besten Region für Lasttests und zur Sicherstellung, dass Dienste mit Last skaliert werden.
• Instanzskalierung – So skalieren und begrenzen Sie Containerinstanzen und minimieren die Antwortzeit, indem Sie einige Instanzen inaktiv lassen, anstatt sie zu beenden.
• Mindestinstanzen verwenden – Geben Sie die geringste Anzahl von Containerinstanzen an, die bereitgestellt werden können. Wenn Sie einen ausreichend hohen Wert festlegen, minimieren Sie die durchschnittliche Antwortzeit, indem Sie die Anzahl der Kaltstarts reduzieren.
• Java-Anwendungen für Cloud Run optimieren – Erfahren Sie mehr über die Vor- und Nachteile einiger Optimierungen für Cloud Run-Dienste, die in Java geschrieben wurden, und reduzieren Sie die Startzeit und die Arbeitsspeichernutzung.
• Python-Anwendungen für Cloud Run optimieren – Optimieren Sie das Container-Image, indem Sie die Effizienz des WSGI-Servers verbessern, und optimieren Sie Anwendungen, indem Sie die Anzahl der Threads reduzieren und Startaufgaben parallel ausführen.

Leitfaden zur Zuverlässigkeit von Cloud Functions

Cloud Functions ist eine skalierbare, ereignisgesteuerte, serverlose Plattform zum Erstellen und Verbinden von Diensten. Cloud Functions-Funktionen können über HTTP-Anfragen aufgerufen oder anhand von Hintergrundereignissen ausgelöst werden.

Best Practices

• Best Practices für Cloud Functions – Richtlinien zur Verwendung und Interaktion mit Cloud Functions, Implementieren der Idempotenz, Bereitstellen von Funktionen und Optimieren der Leistung.

Leitfaden zur Zuverlässigkeit von Google Kubernetes Engine

Google Kubernetes Engine (GKE) ist ein System für den Betrieb von containerisierten Anwendungen in der Cloud in großem Maßstab. GKE stellt Ressourcen für Ihre containerisierten Anwendungen bereit und verwaltet diese. Die GKE-Umgebung besteht aus Compute Engine-Instanzen, die zusammen einen Cluster bilden.

Best Practices

• Best Practices für den Betrieb von Containern – Hier erfahren Sie, wie Sie Logging-Mechanismen verwenden, Container zustandslos und unveränderlich machen, Anwendungen überwachen sowie Aktivitäts- und Bereitschaftsprüfungen durchführen.
• Best Practices für die Containererstellung – Erfahren Sie, wie Sie eine einzelne Anwendung pro Container verpacken, Prozesskennungen (PIDs) verarbeiten, den Docker-Build-Cache optimieren und kleinere Images für schnellere Upload- und Downloadzeiten erstellen.
• Best Practices für Google Kubernetes Engine-Netzwerke: Verwenden Sie VPC-native Cluster für die einfachere Skalierung, das Planen von IP-Adressen, das Skalieren der Clusterkonnektivität, die Verwendung von Google Cloud Armor, um DDoS-Angriffe (Distributed Denial of Service) zu blockieren, zur Implementierung des containernativen Load-Balancing für geringere Latenz, zur Nutzung der Systemdiagnosefunktion eines externen Application Load Balancers für ein ordnungsgemäßes Failover, und zur Verwendung von regionalen Clustern, um die Verfügbarkeit von Anwendungen in einem Cluster zu erhöhen
• Cloudbasierte Kubernetes-Anwendungen vorbereiten: Best Practices zur Planung der Anwendungskapazität, zur horizontalen oder vertikalen Erweiterung der Anwendung, zur Einstellung der Renssourcenlimits relativ zu den Ressourcenanforderungen (Arbeitsspeicher vs. CPU), um Container für einen schlanken Anwendungsstart zu optimieren und zur Begrenzung der Pod-Unterbrechung durch Festlegen eines Pod Disruption Budget (PDB). Machen Sie sich auch mit der Einrichtung von Aktivitäts- und Bereitschaftsprüfungen für einen ordnungsgemäßen Anwendungsstart vertraut, sorgen Sie für ein unterbrechungsfreies Herunterfahren und implementieren Sie einen exponentiellen Backoff bei wiederholten Anfragen, um Trafficspitzen zu verhindern, die Ihre Anwendung überfordern.
• Best Practices zur GKE-Mehrmandantenfähigkeit: Wie Sie eine mehrmandantenfähige Clusterarchitektur für Hochverfügbarkeit und Zuverlässigkeit entwerfen, die Messung der Nutzung von Google Kubernetes Engine (GKE) für Messwerte zur Nutzung pro Mandanten nutzen, und mandantenspezifische Logs und mandantenspezifisches Monitoring bereitstellen.

Leitfaden zur Zuverlässigkeit von Cloud Storage

Cloud Storage ist ein langlebiges und hochverfügbares Objekt-Repository mit erweiterten Sicherheits- und Freigabefunktionen. Dieser Dienst wird zum Speichern und Zugreifen auf Daten in der Google Cloud-Infrastruktur verwendet.

Best Practices

• Best Practices für Cloud Storage: Allgemeine Best Practices für Cloud Storage, einschließlich Tipps zum Maximieren der Verfügbarkeit und Minimieren der Latenz Ihrer Anwendungen, Verbessern der Zuverlässigkeit von Uploadvorgängen und Verbessern der Leistung bei umfangreichen Datenlöschungen.
• Richtlinien für die Anforderungsrate und Zugriffsverteilung: Erfahren Sie, wie Sie die Latenz und Fehlerantworten bei Lese-, Schreib- und Löschvorgängen bei sehr hohen Anforderungsraten minimieren, indem Sie verstehen, wie die automatische Skalierung von Cloud Storage funktioniert.

Firestore-Leitfaden zur Zuverlässigkeit

Firestore ist eine NoSQL-Dokumentdatenbank, mit der Sie Daten für mobile Apps und Webanwendungen weltweit speichern, synchronisieren und abfragen können.

Best Practices

• Best Practices für Firestore: So wählen Sie Ihren Datenbankspeicherort aus, um die Zuverlässigkeit zu erhöhen, Leistungsprobleme bei der Indexierung zu minimieren, die Leistung von Lese- und Schreibvorgängen zu verbessern, die Latenz für Änderungsbenachrichtigungen zu reduzieren und die Skalierung zu entwerfen.

Bigtable-Zuverlässigkeitsleitfaden

Bigtable ist eine vollständig verwaltete, skalierbare NoSQL-Datenbank für große analytische und operative Arbeitslasten. Es ist als dünn populierte Tabelle konzipiert, die auf Milliarden von Zeilen und Tausende von Spalten skaliert werden kann und einen hohen Lese- und Schreibdurchsatz bei niedriger Latenz unterstützt.

Best Practices

• Bigtable-Leistung verstehen: Schätzung des Durchsatzes für Bigtable, Planen einer Bigtable-Kapazität durch Prüfen von Durchsatz und Speichernutzung, Einsicht in die unterschiedliche Auswirkung der Replikation auf den Lese- und Schreibdurchsatz und Einsicht darin, wie Bigtable Daten im Laufe der Zeit optimiert.
• Bigtable-Schemadesign: Anleitung zum Entwerfen eines Bigtable-Schemas, einschließlich Konzepten für Schlüssel/Wert-Speicher, das Entwerfen von Zeilenschlüsseln basierend auf geplanten Leseanfragen, der Verarbeitung von Spalten und Zeilen sowie speziellen Anwendungsfällen.
• Übersicht über die Bigtable-Replikation: Wie Sie Bigtable über mehrere Zonen oder Regionen replizieren, die Auswirkungen auf die Leistung der Replikation verstehen und wie Bigtable Konflikte löst und Failovers verarbeitet.
• Informationen zu Bigtable-Sicherungen – wie Sie eine Kopie des Schemas und der Daten einer Tabelle mit Bigtable-Sicherungen speichern. Dies kann bei der Wiederherstellung nach Datenbeschädigung auf Anwendungsebene oder durch Operatorfehler wie das versehentliche Löschen einer Tabelle hilfreich sein.

Leitfaden zur Zuverlässigkeit von Cloud SQL

Cloud SQL ist ein vollständig verwalteter relationaler Datenbankdienst für MySQL, PostgreSQL und SQL Server. Cloud SQL lässt sich einfach in vorhandene Anwendungen und Google Cloud-Dienste wie Google Kubernetes Engine und BigQuery einbinden.

Best Practices

• Hohe Verfügbarkeit in Cloud SQL: Übersicht über die Hochverfügbarkeitskonfiguration für Cloud SQL, einschließlich der Verarbeitung von Lesereplikaten und des Failover-Prozesses. Außerdem wird beschrieben, wie Sie den Zeitpunkt von Datenbankwartungsereignissen steuern und wie sich die Verwendung von regionalem nichtflüchtigem Speicher in der HA-Konfiguration auf die Datenbankleistung auswirkt. Der Inhalt ist in drei Abschnitte unterteilt:

  • MySQL-Hochverfügbarkeit
  • PostgreSQL-Hochverfügbarkeit
  • SQL Server-Hochverfügbarkeit

• Cloud SQL-Datenbank-Notfallwiederherstellung: Eine Übersicht über die Konfiguration der Notfallwiederherstellung für Cloud SQL mithilfe eines regionenübergreifenden Lesereplikats.

  • MySQL-Notfallwiederherstellung
  • PostgreSQL-Notfallwiederherstellung
  • Notfallwiederherstellung für SQL Server

• Allgemeine Best Practices für Cloud SQL: Anleitungen zum Konfigurieren von Instanzen, Datenarchitektur, Import und Export von Daten sowie Sicherung und Wiederherstellung. Der Inhalt ist in drei Abschnitte unterteilt:

  • Best Practices für MySQL
  • Best Practices für PostgreSQL
  • Best Practices für SQL Server

• Best Practices für den Import und Export von Daten: Unter welchen Umständen Cloud Storage-Buckets nicht verwendet werden können, die Komprimierung von Daten zur Kostenreduzierung, bekannte Einschränkungen beim Importieren und Exportieren von Daten, die Automatisierung von Exportvorgängen sowie die Fehlerbehebung bei Import- und Exportvorgängen.

  • Best Practices für MySQL
  • Best Practices für PostgreSQL
  • Best Practices für SQL Server

Leitfaden zur Zuverlässigkeit von Spanner

Spanner ist ein verteilter SQL-Datenbankverwaltungs- und Speicherdienst mit Funktionen wie globalen Transaktionen und hochverfügbarer horizontaler Skalierung und Transaktionskonsistenz.

Best Practices

• Sicherung und Wiederherstellung von Spanner – wichtige Funktionen von Spanner-Sicherung und -Wiederherstellung, Vergleich von Sicherung und Wiederherstellung mit Import und Export, Implementierungsdetails und Steuerung des Zugriffs auf Spanner-Ressourcen
• Regionale und multiregionale Konfigurationen: Beschreibung der beiden Arten von Instanzkonfigurationen, die Spanner bietet: regionale Konfigurationen und Konfigurationen mit mehreren Regionen. Die Beschreibung enthält die Vor- und Nachteile der einzelnen Konfigurationen.
• Autoscaling-Spanner: Einführung in das Autoscaling-Tool für Spanner (Autoscaler), ein Open-Source-Tool, das Sie als Begleittool für Cloud Spanner verwenden können. Mit diesem Tool können Sie die Anzahl der Knoten oder Verarbeitungseinheiten in einer oder mehreren Spanner-Instanzen automatisch erhöhen oder reduzieren, je nach Auslastungsmesswerten jeder Spanner-Instanz.
• Informationen zur Wiederherstellung zu einem bestimmten Zeitpunkt: Beschreibung der Wiederherstellung zu einem bestimmten Zeitpunkt in Spanner zum Schutz vor versehentlichem Löschen oder Schreiben von Spanner-Daten. Beispiele: Ein Operator schreibt versehentlich Daten oder eine Anwendungseinführung beschädigt die Datenbank. Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie Ihre Daten zu einem bestimmten Zeitpunkt in der Vergangenheit (bis zu sieben Tage) nahtlos wiederherstellen.
• Best Practices für Spanner – Anleitungen zum Laden im Bulk, mithilfe von DML (Data Manipulation Language) und zum Entwerfen von Schemas zur Vermeidung von Hotspots und Best Practices für SQL.

Anleitung zur Zuverlässigkeit für Filestore

Filestore ist ein verwalteter Dateispeicherdienst für Google Cloud-Anwendungen mit einer Dateisystemschnittstelle und einem freigegebenen Dateisystem für Daten. Filestore bietet Network Attached Storage (NAS) online in Petabyte-Dimensionen für Compute Engine- und Google Kubernetes Engine-Instanzen.

Best Practices

• Filestore-Leistung: Leistungseinstellungen und Compute Engine-Empfehlungen zu Maschinentypen, NFS-Bereitstellungsoptionen für die beste Leistung auf Linux-Client-VM-Instanzen und die Verwendung des fio-Tools zum Testen der Leistung. Enthält Empfehlungen zur Verbesserung der Leistung mehrerer Google Cloud-Ressourcen.

• Filestore-Sicherungen: Beschreibung von Filestore-Sicherungen, gängigen Anwendungsfällen und Best Practices für die Erstellung und Verwendung von Sicherungen

• Filestore-Snapshots: Beschreibung von Filestore-Snapshots, gängigen Anwendungsfällen und Best Practices für die Erstellung und Verwenden von Snapshots

• Filestore-Netzwerk: Anforderungen für Netzwerke und IP-Ressourcen, die zum Verwenden von Filestore erforderlich sind

Memorystore-Zuverlässigkeitsleitfaden

Memorystore ist ein vollständig verwalteter In-Memory-Speicher, der eine verwaltete Version von zwei Open-Source-Caching-Lösungen bietet: Redis und Memcached. Memorystore ist skalierbar und automatisiert komplexe Aufgaben wie Bereitstellung, Replikation, Failover und Patching.

Best Practices

• Allgemeine Best Practices von Redis: Anleitungen zum Exportieren von RDB-Sicherungen (Redis Database), ressourcenintensiven Vorgängen und Vorgängen, bei denen eine Verbindungswiederholung erforderlich ist. Darüber hinaus finden Sie Informationen zu Wartung, Arbeitsspeicherverwaltung und Einrichtung des Connectors für serverlosen VPC-Zugriff sowie zum Verbindungsmodus für private Dienste sowie Monitoring und Benachrichtigungen.
• Best Practices für die Redis-Speicherverwaltung – Speicherverwaltungskonzepte wie Instanzkapazität und Maxmemory-Konfiguration, -Export, -Skalierung und -Versionsupgrade-Vorgänge, Messwerte zur Speicherverwaltung und Lösungen für nicht genügend Arbeitsspeicher.
• Redis – exponentieller Backoff – Funktionsweise des exponentiellen Backoffs, des maximalen Backoff und der maximalen Anzahl an Wiederholungsversuchen sowie ein Beispielalgorithmus.
• Best Practices für Memcached: Hier erfahren Sie, wie Sie Anwendungen auf Cache-Fehler ausgelegt werden, wie Sie direkte Verbindung zu IP-Adressen von Knoten herstellen und den Auto Discovery-Dienst von Memcached verwenden. Außerdem eine Anleitung zum Konfigurieren des Parameters max-item-size, zum Ausgleichen von Clustern und zur Verwendung von Cloud Monitoring zur Überwachung wichtiger Messwerte.
• Best Practices für die Memcached-Speicherverwaltung – Konfigurieren von Arbeitsspeicher für eine Memcache-Instanz, Konfiguration des reservierten Speichers, wann reservierter Speicher zu erhöhen ist und Messwerte für die Speichernutzung.

Leitfaden zur Cloud DNS-Zuverlässigkeit

Cloud DNS ist ein Domainnamesystem mit niedriger Latenz, mit dem Sie Ihre Domains registrieren, verwalten und bereitstellen können. Cloud DNS skaliert auf große Zahlen von DNS-Zonen und -Datensätzen und Millionen von DNS-Datensätzen können über eine Benutzeroberfläche erstellt und aktualisiert werden.

Best Practices

• Best Practices für Cloud DNS: Private Zonen verwalten, die DNS-Weiterleitung konfigurieren und DNS-Serverrichtlinien erstellen. Enthält Informationen zur Verwendung von Cloud DNS in einer Hybridumgebung.

Leitfaden zur Zuverlässigkeit für Cloud Load Balancing

Cloud Load Balancing ist ein vollständig verteilter, softwarebasierter verwalteter Dienst für Ihren gesamten Traffic. Cloud Load Balancing bietet außerdem nahtloses Autoscaling, Layer-4- und Layer-7-Load-Balancing sowie Unterstützung für Features wie das globale IPv6--Load-Balancing.

Best Practices

• Best Practices für die Leistung: Wie Sie die Last auf die Anwendungsinstanzen verteilen, um eine optimale Leistung zu erzielen. Zu den Strategien gehören Backend-Platzierung in Regionen, die dem Traffic am nächsten sind, Caching, Protokollauswahl für Weiterleitungsregeln und Konfigurieren der Sitzungsaffinität.
• Load-Balancing für hochverfügbare Anwendungen verwenden – wie Sie Cloud Load Balancing mit Compute Engine verwenden, um Hochverfügbarkeit auch bei einem Zonenausfall zu gewährleisten

Leitfaden zur Zuverlässigkeit von Cloud CDN

Cloud CDN (Content Delivery Network) ist ein Dienst, der die Bereitstellung von Internetinhalten mithilfe des Edge-Netzwerks von Google beschleunigt, um Inhalte so nah wie möglich am Nutzer zu platzieren. Cloud CDN verringert die Latenz, die Kosten und die Last und vereinfacht die Skalierung von Diensten für Nutzer.

Best Practices

• Best Practices für die Inhaltsübermittlung: Hier erfahren Sie, wie Sie die Cache-Trefferquote mithilfe von Cache-Schlüsseln optimieren, HTTP/3 für optimale Leistung aktivieren und die Monitoring-Messwerte mit dem benutzerdefinierten Cloud CDN-Monitoring-Dashboard prüfen. Außerdem erfahren Sie, wie Sie Berichte zur Verfügbarkeit, Latenz und zum Durchsatz von Leistungstests von Drittanbietern überprüfen können.

Leitfaden zur BigQuery-Zuverlässigkeit

BigQuery ist die Data-Warehouse-Plattform von Google Cloud zum Speichern und Analysieren von Daten im großen Maßstab.

Best Practices

• Einführung in Zuverlässigkeit: Best Practices zur Zuverlässigkeit und eine Einführung in Konzepte wie Verfügbarkeit, Langlebigkeit und Datenkonsistenz.
• Verfügbarkeit und Langlebigkeit: Die Arten fehlerhafter Domains, die in Google Cloud-Rechenzentren auftreten können, wie BigQuery Speicherredundanz auf Basis des Speicherorts der Daten bietet und warum regionenübergreifende Datasets die Notfallwiederherstellung verbessern.
• Best Practices für mehrmandantenfähige Arbeitslasten in BigQuery: Gängige Muster für mehrmandantenfähige Datenplattformen. Zu diesen Mustern gehören die Gewährleistung der Zuverlässigkeit und Isolation von Kunden von SaaS-Anbietern (Software as a Service), wichtige BigQuery-Kontingente und Limits für die Kapazitätsplanung, der Einsatz des BigQuery Data Transfer Service zum Kopieren relevanter Datasets in eine andere Region und vieles mehr.
• Materialisierte Ansichten verwenden: Wie Sie materialisierte Ansichten in BigQuery verwenden können, um schnellere Abfragen zu niedrigeren Kosten zu erreichen, einschließlich der Abfrage von materialisierten Ansichten, der Ausrichtung von Partitionen und dem Verständnis des Smart-Tuning (automatisches Neuschreiben von Abfragen).

Leitfaden zur Dataflow-Zuverlässigkeit

Dataflow ist ein vollständig verwalteter Datenverarbeitungsdienst, der eine schnelle, vereinfachte Entwicklung von Streamingdaten-Pipelines mit Apache Beam-Bibliotheken im Open-Source-Format ermöglicht. Dataflow minimiert Latenz, Verarbeitungszeit und Kosten durch Autoscaling und Batchverarbeitung.

Best Practices

Produktionsbereite Datenpipelines mit Dataflow erstellen: eine Dokumentreihe zur Verwendung von Dataflow, einschließlich Planung, Entwicklung, Bereitstellung und Monitoring von Dataflow-Pipelines.

• Übersicht: Einführung in Dataflow-Pipelines.
• Planung: Messung der SLOs, der Auswirkung von Datenquellen und -senken auf die Skalierbarkeit und Leistung der Pipeline und Berücksichtigung von Hochverfügbarkeit, Notfallwiederherstellung und Netzwerkleistung bei der Angabe von Regionen zum Ausführen Ihrer Dataflow-Jobs.
• Entwicklung und Tests: Einrichten von Bereitstellungsumgebungen, Vermeiden von Datenverlusten durch Verwendung von Dead-Letter-Warteschlangen für die Fehlerbehandlung und Reduzieren von Latenz und Kosten durch Minimieren von teuren Vorgängen pro Element. Außerdem: Nutzung der Batchverarbeitung zur Reduzierung des Leistungsaufwands, ohne die externen Dienste zu überlasten, Aufheben falsch zusammengeführter Schritte, damit die Schritte für eine bessere Leistung getrennt werden, und Ausführen von End-to-End-Tests in der Vorproduktion, damit die Pipeline Ihre SLOs und andere Produktionsanforderungen weiterhin erfüllt.
• Bereitstellung: Continuous Integration (CI) sowie Continuous Delivery und kontinuierliche Bereitstellung (CD) mit besonderen Überlegungen zur Bereitstellung neuer Versionen von Streaming-Pipelines. Außerdem eine CI/CD-Beispiel-Pipeline und einige Features zur Optimierung der Ressourcennutzung. Abschließend eine Betrachtung von Hochverfügbarkeit, geografischer Redundanz und Best Practices für die Pipeline-Zuverlässigkeit, einschließlich regionaler Isolierung, Verwendung von Snapshots, Verarbeitung von Fehlern beim Senden von Jobs und Wiederherstellung nach Fehlern und Ausfällen, die sich auf laufende Pipelines auswirken.
• Monitoring: Beobachten der Service Level Indicators (SLIs), die wichtige Indikatoren für die Pipeline-Leistung sind, und Definieren und Messen von Service Level Objectives (SLOs).

Leitfaden zur Dataproc-Zuverlässigkeit

Dataproc ist ein vollständig verwalteter, skalierbarer Dienst zum Ausführen von Apache Hadoop- und Spark-Jobs. Mit Dataproc können virtuelle Maschinen nach Bedarf angepasst und skaliert werden. Dataproc ist nahtlos in Cloud Storage, BigQuery, Bigtable und andere Google Cloud-Dienste eingebunden.

Best Practices

• Dataproc-Hochverfügbarkeitsmodus: Vergleichen Sie den Hadoop-Modus für hohe Verfügbarkeit mit dem Standardmodus ohne Hochverfügbarkeit in Bezug auf Instanznamen, Apache ZooKeeper, Hadoop Distributed File System (HDFS) und Yet Another Resource Negotiator. YARN) Außerdem erstellen Sie einen Hochverfügbarkeitscluster.
• Autoscaling-Cluster: Verwendung von Dataproc-Autoscaling, Erstellung einer Autoscaling-Richtlinie, Verwendung von Multi-Cluster-Richtlinien, Best Practices für die Zuverlässigkeit der Konfiguration von Autoscaling sowie Messwerte und Logs.
• Dataproc Enhanced Flexibility Mode (EFM): Beispiele für die Verwendung des Enhanced Flexibility Mode, um Verzögerungen beim Jobfortschritt, erweiterte Konfigurationen wie Partitionierung und Parallelität und die ordnungsgemäße Außerbetriebnahme von YARN in EFS-Clustern zu minimieren.
• Ordnungsgemäße Außerbetriebnahme: Verwenden Sie eine ordnungsgemäße Außerbetriebnahme, um die Auswirkungen des Entfernens von Workern aus einem Cluster zu minimieren, diese Funktion mit sekundären Workern zu verwenden und Befehlsbeispiele für die ordnungsgemäße Außerbetriebnahme zu verwenden.
• Neustartfähige Jobs: Mit optionalen Einstellungen können Sie Jobs so einrichten, dass sie bei einem Fehler neu gestartet werden, um häufige Arten von Jobfehlern zu vermeiden, einschließlich Problemen aufgrund fehlenden Speichers und eines unerwarteten Neustarts von virtuellen Compute Engine-Maschinen.

Google Cloud-Architektur-Framework: Kostenoptimierung

Diese Kategorie des Google Cloud-Architektur-Frameworks enthält Designempfehlungen und beschreibt Best Practices für Architekten, Entwickler, Administratoren und andere Cloud-Experten für die Kostenoptimierung von Arbeitslasten in Google Cloud.

Durch das Verschieben Ihrer IT-Arbeitslasten in die Cloud können Sie umfangreiche Innovationen umsetzen, Features schneller bereitstellen und auf sich ändernde Kundenanforderungen reagieren. Wenn Sie vorhandene Arbeitslasten migrieren oder Anwendungen für die Cloud bereitstellen möchten, benötigen Sie eine Topologie, die für Sicherheit, Robustheit, operative Exzellenz, Kosten und Leistung optimiert ist.

In der Kategorie zur Kostenoptimierung des Architektur-Frameworks lernen Sie Folgendes:

• Einführung und Implementierung von FinOps: Strategien, um Mitarbeiter dabei zu unterstützen, die Auswirkungen auf die Kosten bei der Bereitstellung und Verwaltung von Ressourcen in Google Cloud zu berücksichtigen.
• Kosten beobachten und steuern: Best Practices, Tools und Techniken zum Verfolgen und Steuern der Kosten Ihrer Ressourcen in Google Cloud.
• Kosten optimieren: Computing, Container und serverlos: Dienstspezifische Steuerelemente für die Kostenoptimierung in Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions und App Engine.
• Kosten optimieren: Speicher: Steuerelemente zur Kostenoptimierung für Cloud Storage, Persistent Disk und Filestore.
• Kosten optimieren: Datenbanken und intelligente Analysen: Steuerelemente zur Kostenoptimierung für BigQuery, Cloud Bigtable, Spanner, Cloud SQL, Dataflow und Dataproc.
• Kostenoptimierung: Netzwerk: Steuerelemente zur Kostenoptimierung für Ihre Netzwerkressourcen in Google Cloud.
• Kosten optimieren: Cloud-Vorgänge: Empfehlungen zur Optimierung der Kosten für das Monitoring und die Verwaltung Ihrer Ressourcen in Google Cloud.

FinOps einführen und implementieren

In diesem Dokument im Google Cloud-Architektur-Framework werden Strategien beschrieben, mit denen Sie die Kostenauswirkungen Ihrer Aktionen und Entscheidungen bei der Bereitstellung und Verwaltung von Ressourcen in Google Cloud verstehen können. Diskutiert wird FinOps, eine Methode, die Personen, Prozesse und Technologien kombiniert, um die finanzielle Rechenschaftspflicht und die Disziplin der Kostenoptimierung in einer Organisation zu fördern, unabhängig von deren Größe oder Reife in der Cloud.

Die Anleitung in diesem Abschnitt richtet sich an CTOs, CIOs und Führungskräfte, die für die Kontrolle der Ausgaben ihrer Organisation in der Cloud verantwortlich sind. Die Anleitung hilft auch einzelnen Cloud-Operatoren, FinOps zu verstehen und anzuwenden.

Jeder Mitarbeiter Ihrer Organisation kann dazu beitragen, die Kosten Ihrer Ressourcen in Google Cloud zu reduzieren, unabhängig von der Rolle (Analyst, Architekt, Entwickler oder Administrator). In Teams, die in der Vergangenheit Infrastrukturkosten nicht erfassen mussten, müssen Sie Mitarbeiter möglicherweise über die Notwendigkeit der kollektiven Verantwortung informieren.

Ein gängiges Modell ist ein zentrales FinOps-Team oder ein Cloud Center of Excellence (CCoE) zur Standardisierung des Prozesses zur Kostenoptimierung über alle Cloud-Arbeitslasten hinweg. Bei diesem Modell wird davon ausgegangen, dass das zentrale Team über das erforderliche Wissen und die erforderlichen Kenntnisse verfügt, um zentrale Möglichkeiten zur Verbesserung der Effizienz zu identifizieren.

Eine zentralisierte Kostenkontrolle kann in den ersten Phasen der Cloud-Einführung, während die Nutzung niedrig ist, gut funktionieren, sie lässt sich aber nicht gut skalieren, wenn Akzeptanz und Nutzung der Cloud zunehmen. Das zentrale Team hat dann möglicherweise Schwierigkeiten mit der Skalierung, und eventuell werden Projektteams keine Entscheidungen von Personen außerhalb ihrer Teams akzeptieren.

Wir empfehlen, dass das zentrale Team die Entscheidung zur Ressourcenoptimierung an die Projektteams delegiert. Das zentrale Team kann umfassendere Maßnahmen ergreifen, um die Einführung von FinOps in der gesamten Organisation zu fördern. Damit die einzelnen Projektteams FinOps üben können, muss das zentrale Team den Prozess, die Berichte und die Tools für die Kostenoptimierung standardisieren. Das zentrale Team muss eng mit Teams zusammenarbeiten, die nicht mit FinOps-Praktiken vertraut sind, und ihnen bei der Berücksichtigung von Kosten bei ihren Entscheidungsprozessen helfen. Das zentrale Team muss auch als Vermittler zwischen dem Finanzteam und den einzelnen Projektteams fungieren.

In den nächsten Abschnitten werden die Designprinzipien beschrieben, die Ihr zentrales Team fördern sollte.

Individuelle Verantwortlichkeit fördern

Jeder Mitarbeiter, der Cloud-Ressourcen erstellt und verwendet, hat Auswirkungen auf die Nutzung und die Kosten dieser Ressourcen. Damit eine Organisation FinOps erfolgreich implementieren kann, muss das zentrale Team Mitarbeiter dazu hinführen, Kosten nicht mehr als Verantwortung anderer Personen zu sehen, sondern als eigene Verantwortung zu empfinden. Durch diese Umstellung können Mitarbeiter für ihre Arbeitslasten, ihr Team und die Organisation geeignete Kostenentscheidungen treffen. Diese Eigentümerschaft erstreckt sich auch auf die Implementierung datengestützter Kostenoptimierungsaktionen.

Um die Übernahme der Kostenverantwortung zu fördern, kann das zentrale Team folgende Maßnahmen ergreifen:

• Nutzer über Möglichkeiten und Techniken zur Kostenoptimierung informieren.
• Belohnen Sie Mitarbeiter, die Kosten optimieren, und feiern sie deren Erfolge.
• Kosten im gesamten Unternehmen sichtbar machen.

Kosten sichtbar machen

Damit Mitarbeiter die Kosten bei der Bereitstellung und Verwaltung von Ressourcen in der Cloud berücksichtigen können, benötigen sie eine vollständige Ansicht relevanter Daten in Fast-Echtzeit. Daten in Berichten und Dashboards müssen die Kosten und die geschäftlichen Auswirkungen der Entscheidungen der Teammitglieder darstellen, sobald die relevanten Auswirkungen auftreten. Nutzungs- und Kostendaten anderer Teams können als Grundlage zur Identifizierung effizienter Bereitstellungsmuster dienen. Diese Daten können dabei helfen, ein gemeinsames Verständnis der besten Arten der Verwendung von Cloud-Diensten zu entwickeln.

Wenn eine Organisation die Freigabe von Kostendaten nicht ermutigt und umsetzt, kann es sein, dass Mitarbeiter ungern Daten teilen. Manchmal ist es aus geschäftlichen Gründen unmöglich, dass eine Organisation die Freigabe grundlegender Kostendaten erlaubt. Selbst in diesen Fällen empfehlen wir es, die Nutzung einer Standardrichtlinie zu vermeiden, die den Zugriff auf Kosteninformationen einschränkt.

Um die Kosten im gesamten Unternehmen sichtbar zu machen, kann das zentrale Team folgendes tun:

• Eine einzige, klar definierte Methode zur Berechnung der vollen Kosten von Cloud-Ressourcen nutzen. Beispielsweise kann diese Methode die Gesamtkosten für die Cloud ergeben, wobei erworbene Rabatte und gemeinsame Kosten berücksichtigt werden, z. B. Kosten für gemeinsam genutzte Datenbanken.
• Richten Sie Dashboards ein, mit denen Mitarbeiter ihre Cloud-Ausgaben nahezu in Echtzeit verfolgen können.
• Damit Teammitglieder die Verantwortung für ihre Kosten übernehmen, sollten Sie die Cloud-Ausgaben übergreifend über alle Teams hinweg sichtbar machen.

Kollaboratives Verhalten stärken

Für ein effektives Kostenmanagement der Cloud-Ressourcen müssen die Teams ihre technischen und operativen Prozesse gemeinsam optimieren. Eine Kultur der Zusammenarbeit unterstützt Teams dabei, kosteneffektive Bereitstellungsmuster auf Grundlage konsistenter Geschäftsziele und Faktoren zu entwerfen.

Um das kollaborative Verhalten zu ermöglichen, kann das zentrale Team folgendes tun:

• Einen Onboarding-Prozess für Arbeitslasten entwickeln, der die Kosteneffizienz in der Designphase durch Peer-Rezensionen vorgeschlagener Architekturen durch andere Entwickler garantiert.
• Eine teamübergreifende Wissensdatenbank mit kostengünstigen Architekturmustern entwickeln.

Kultur ohne Beschuldigungen etablieren

Fördern Sie eine Lern- und Wachstumskultur, in der es sich sicher anfühlt, Risiken einzugehen, bei Bedarf Korrekturen vorzunehmen und Innovationen durchzuführen. Machen Sie klar, dass Fehler, manchmal auch kostspielige, während des IT-Design- und Bereitstellungszyklus vorkommen können, wie in jedem anderen Geschäftsbereich.

Anstatt Menschen, die zu viel ausgegeben oder unnötige Elemente eingeführt haben, Schuld zuzuordnen, sollten Sie eine Kultur ohne Schuldzuweisungen fördern, die zur Ermittlung der Ursache von Kostenüberschreitungen und Fehlberechnungen beitragen kann. In einer solchen Umgebung ist es wahrscheinlicher, dass Teammitglieder Ansichten und Erfahrungen teilen. Fehler werden anonymisiert und im gesamten Unternehmen diskutiert, um deren Wiederholung zu verhindern.

Verwechseln Sie eine Kultur ohne Beschuldigungen nicht mit einer fehlenden Rechenschaftspflicht. Mitarbeiter sind weiterhin für ihre Entscheidungen und ihre Ausgaben verantwortlich. Wenn Fehler jedoch auftreten, liegt der Fokus auf der Möglichkeit aus diesen zu lernen, um zu verhindern, dass Fehler noch einmal auftreten.

Zur Einführung einer Kultur ohne Beschuldigungen kann das zentrale Team folgendes tun:

• Postmortems ohne Schuldzuweisung bei größeren Kostenproblemen durchführen, wobei der Fokus auf den systemischen Ursache der Probleme statt auf den beteiligten Personen liegt.
• Teammitglieder feiern, die auf Kostenüberschreitungen reagieren und Erkenntnisse teilen. Andere Teammitglieder ermutigen, Fehler, ergriffene Aktionen und gewonnene Erkenntnisse zu teilen.

Fokus auf den geschäftlichen Nutzen

Obwohl FinOps-Praktiken oft auf Kostensenkungen ausgerichtet sind, muss ein zentrales Team darauf achten, dass Projektteams Entscheidungen treffen, die den geschäftlichen Wert ihrer Cloud-Ressourcen maximieren. Es kann verlockend sein, Entscheidungen zu treffen, mit denen die Kosten bis zu dem Punkt gesenkt werden, an dem nur die Mindestdienststufen erfüllt werden. Durch solche Entscheidungen werden jedoch häufig Kosten in andere Ressourcen verlagert, was höhere Wartungskosten und höhere Gesamtbetriebskosten bedingen kann. Beispiel: Wenn Sie die Kosten senken möchten, können Sie virtuelle Maschinen (VMs) anstelle eines verwalteten Dienstes verwenden. Der Wartungsbedarf einer VM-basierten Lösung ist im Vergleich zu einem verwalteten Dienst jedoch höher, sodass der verwaltete Dienst möglicherweise einen höheren Nettowert für das Unternehmen bietet.

FinOps-Verfahren können Projektteams die Sichtbarkeit und Informationen zur Verfügung stellen, die sie benötigen, um Architektur- und Betriebsentscheidungen zur Maximierung des Geschäftswerts ihrer Cloud-Ressourcen zu treffen.

Damit sich die Mitarbeiter auf den geschäftlichen Nutzen konzentrieren können, kann das zentrale Team folgendes tun:

• Mit verwalteten Diensten und serverlosen Architekturen senken Sie die Gesamtbetriebskosten Ihrer Computing-Ressourcen. Weitere Informationen finden Sie unter Computing-Plattform auswählen.

• Verknüpfen Sie die Cloudnutzung mit Messwerten zum Geschäftswert wie Kosteneffizienz, Robustheit, Merkmalsgeschwindigkeit und Innovationen, die Entscheidungen zur Kostenoptimierung erleichtern. Weitere Informationen zu Messwerten für Geschäftswerte finden Sie im Whitepaper zu Cloud FinOps.

• Einheitenkosten für alle in der Cloud ausgeführten Anwendungen und Dienste implementieren.

Nächste Schritte

• Weitere Informationen zu FinOps:
  • Geschäftswert mit Cloud FinOps maximieren
  • Erste Schritte mit FinOps in Google Cloud
  • FinOps Foundation
  • Einheitenkosten in der Cloud
• Kosten im Blick behalten und kontrollieren
• Kosten für Google Cloud-Dienste optimieren:
  • Kosten optimieren: Computing, Container und serverloses Computing
  • Kosten optimieren: Speicher
  • Kosten optimieren: Datenbanken und intelligente Analysen
  • Kosten optimieren: Netzwerk
  • Kosten optimieren: Cloud-Vorgänge
• Weitere Kategorien des Google Cloud-Architektur-Frameworks entdecken

Kosten im Blick behalten und kontrollieren

In diesem Dokument im Google Cloud-Architektur-Framework werden Best Practices, Tools und Techniken beschrieben, mit denen Sie die Kosten Ihrer Ressourcen in Google Cloud verfolgen und kontrollieren können.

Die Anleitung in diesem Abschnitt richtet sich an Nutzer, die Ressourcen in der Cloud bereitstellen oder verwalten.

Schwerpunkte der Kostenverwaltung

Die Kosten für Ihre Ressourcen in Google Cloud hängen von der Menge der verwendeten Ressourcen und dem Preis ab, mit dem Ihnen die Ressourcen in Rechnung gestellt werden.

Sie sollten sich auf die folgenden Bereiche konzentrieren, um die Kosten von Cloud-Ressourcen zu verwalten:

• Kostentransparenz
• Ressourcenoptimierung
• Tarifoptimierung

Kostentransparenz

Verfolgen Sie Ihre Ausgaben und die Abrechnung Ihrer Ressourcen und Dienste, damit Sie die Auswirkungen der Kosten auf die Geschäftsergebnisse analysieren können. Wir empfehlen, dass Sie dem FinOps-Betriebsmodell folgen, das die folgenden Aktionen vorschlägt, um Kosteninformationen in Ihrer Organisation sichtbar zu machen:

• Zuweisen: Jedem Kostenelement einen Inhaber zuweisen.
• Bericht: Kostendaten verfügbar, nutzbar und verwertbar machen.
• Prognose: Zukünftige Ausgaben schätzen und verfolgen.

Ressourcenoptimierung

Passen Sie die Anzahl und Größe Ihrer Cloud-Ressourcen an die Anforderungen Ihrer Arbeitslast an. Wenn möglich, sollten Sie verwaltete Dienste verwenden oder Ihre Anwendungen neu strukturieren. In der Regel haben einzelne Entwicklerteams mehr Kontext als das zentrale FinOps-Team (Financial Operations) hinsichtlich Möglichkeiten und Techniken zur Optimierung der Ressourcenbereitstellung. Wir empfehlen, dass das FinOps-Team mit den einzelnen Entwicklungsteams zusammenarbeitet, um Möglichkeiten zur Ressourcenoptimierung zu ermitteln, die in der gesamten Organisation angewendet werden können.

Tarifoptimierung

Das FinOps-Team trifft häufig Entscheidungen zur Tarifoptimierung zentral. Wir empfehlen, dass die einzelnen Entwicklerteams mit dem zentralen FinOps-Team zusammenarbeiten, um umfassende Rabatte für Reservierungen, zugesicherte Nutzung, Spot VMs, Pauschalpreise sowie Volumen- und Vertragsrabatte zu nutzen.

Designempfehlungen

In diesem Abschnitt werden Ansätze vorgeschlagen, mit denen Sie die Kosten überwachen und kontrollieren können.

Abrechnung und Ressourcenverwaltung konsolidieren

Um die Abrechnung und Ressourcen in Google Cloud effizient zu verwalten, empfehlen wir, dass Sie ein einziges Rechnungskonto für Ihre Organisation verwenden und interne Mechanismen zur Rückbuchung für die Kostenzuweisung verwenden. Verwenden Sie mehrere Rechnungskonten für lose strukturierte Konglomerate und Organisationen mit Entitäten, die sich nicht aufeinander auswirken. Beispielsweise benötigen Reseller möglicherweise für jeden Kunden separate Konten. Wenn Sie separate Rechnungskonten verwenden, können Sie möglicherweise auch die länderspezifischen Steuervorschriften besser einhalten.

Eine weitere empfohlene Best Practice besteht darin, alle von Ihnen verwalteten Projekte in Ihre Organisation zu verschieben. Wir empfehlen, mit Resource Manager eine Ressourcenhierarchie zu erstellen, mit der Sie die folgenden Ziele erreichen können:

• Einrichten einer Hierarchie der Ressourceninhaberschaft basierend auf der Beziehung der einzelnen Ressourcen zu ihrem unmittelbar übergeordneten Element.
• Steuern, wie Zugriffsrichtlinien und Tags oder Labels für die Kostenzuweisung an die Ressourcen in Ihrer Organisation angehängt und von diesen übernommen werden.

Darüber hinaus empfehlen wir Ihnen, die Kosten für gemeinsam genutzte Dienste anteilig nach dem Verbrauch zu verteilen. Prüfen und passen Sie die Parameter für die Kostenzuweisung regelmäßig an, wenn sich Ihre Geschäftsziele und Prioritäten ändern.

Kosten über Tags oder Labels verfolgen und zuweisen

Tags und Labels sind zwei verschiedene Methoden, mit denen Sie Ihre Google Cloud-Ressourcen annotieren können. Tags bieten mehr Funktionen als Labels. Sie können beispielsweise eine detaillierte Kontrolle über Ressourcen implementieren und dafür IAM-Richtlinien (Identity and Access Management) erstellen, die davon abhängig sind, ob ein Tag an eine unterstützte Ressource angehängt ist. Darüber hinaus werden die Tags, die einer Ressource zugeordnet sind, von allen untergeordneten Ressourcen in der Hierarchie übernommen. Weitere Informationen zu den Unterschieden zwischen Tags und Labels finden Sie unter Übersicht: Tags.

Wenn Sie ein neues Framework für die Kostenzuordnung und -verfolgung erstellen, empfehlen wir die Verwendung von Tags.

Um die Kostendaten mit der erforderlichen Granularität zu kategorisieren, sollten Sie ein Labeling-Schema erstellen, das zum Rückbuchungsmechanismus Ihrer Organisation passt und Ihnen die entsprechende Zuweisung von Kosten ermöglicht. Sie können Tags auf Organisations- oder Projektebene definieren. Sie können Labels auf Projektebene zuweisen und eine Reihe von Labels definieren, die standardmäßig auf alle Projekte angewendet werden können.

Definieren Sie einen Prozess, um Tagging- und Labeling-Anomalien und Projekte ohne Label zu erkennen und zu korrigieren. Von Cloud Asset Inventory können Sie beispielsweise ein Inventar (.csv-Datei) aller Ressourcen in einem Projekt herunterladen und das Inventar analysieren, um Ressourcen zu identifizieren, denen weder Tags noch Labels zugeordnet sind.

Um die Kosten für gemeinsam genutzte Ressourcen und Dienste zu verfolgen (z. B. gängige Datenspeicher, mehrmandantenfähige Cluster und Supportabos), sollten Sie ein spezielles Tag oder Label nutzen, um Projekte zu identifizieren, die freigegebene Ressourcen enthalten.

Zugriffssteuerung für die Abrechnung konfigurieren

Zur Steuerung des Zugriffs auf Cloud Billing sollten Sie die Rolle „Rechnungskontoadministrator“ nur den Nutzern zuweisen, die Informationen zum Abrechnungskontakt verwalten. Beispielsweise könnten Mitarbeiter in den Bereichen Finanzen, Buchhaltung und Betrieb diese Rolle benötigen.

Um einen Single Point of Failure für den Abrechnungssupport zu vermeiden, weisen Sie die Rolle "Rechnungskontoadministrator" mehreren Nutzern oder einer Gruppe zu. Nur Nutzer mit der Rolle eines Rechnungskontoadministrators können den Support kontaktieren. Detaillierte Anleitungen finden Sie unter Beispiele für die Zugriffssteuerung in Cloud Billing und Wichtige Rollen.

Nehmen Sie die folgenden Konfigurationen vor, um den Zugang zur Abrechnung zu verwalten:

• Mitglieder müssen die Rolle „Rechnungskontonutzer“ für das Rechnungskonto und die Rolle „Administrator für die Projektabrechnung“ für das Projekt haben, damit ein Rechnungskonto mit einem Projekt verknüpft werden kann.
• Um Teams die Möglichkeit zu geben, Abrechnungskonten manuell mit Projekten zu verknüpfen, können Sie auf Organisationsebene die Rolle „Administrator für die Projektabrechnung“ und auf dem Abrechnungskonto die Rolle „Rechnungskontonutzer“ zuweisen. Sie können die Verknüpfung von Rechnungskonten während der Projekterstellung automatisieren, indem Sie die Rollen „Administrator für die Projektabrechnung“ und „Rechnungskontonutzer“ einem Dienstkonto zuweisen. Wir empfehlen, die Rolle „Rechnungskonto-Ersteller“ einzuschränken oder alle Zuweisungen dieser Rolle zu entfernen.
• Sie können die Verknüpfung zwischen dem Projekt und dessen Rechnungskonto sperren, um Ausfälle zu vermeiden, die durch unbeabsichtigte Änderungen am Abrechnungsstatus eines Projekts verursacht werden. Weitere Informationen finden Sie unter Verknüpfung zwischen einem Projekt und seinem Rechnungskonto sichern.

Abrechnungsberichte konfigurieren

Richten Sie Abrechnungsberichte ein, um Daten für die wichtigsten Messwerte bereitzustellen, die Sie verfolgen müssen. Wir empfehlen die Erfassung der folgenden Messwerte:

• Kostentrends
• Größte Ausgabenverursacher (nach Projekt und Produkt)
• Bereiche mit unregelmäßigen Ausgaben
• Wichtige organisationsweite Informationen wie:
  • Anomalieerkennung
  • Trends im Laufe der Zeit
  • Trends, die nach einem bestimmten Muster auftreten (z. B. Monat für Monat)
  • Kostenvergleich und Benchmarkanalyse zwischen internen und externen Arbeitslasten
  • Tracking von Geschäftsfällen und Wertschöpfung (z. B. Cloud-Kosten im Vergleich zu den Kosten ähnlicher lokaler Ressourcen)
  • Validierung, ob die Google Cloud-Abrechnungen wie erwartet und korrekt sind

Trends analysieren und Kosten prognostizieren

Sie können Kostenberichte mit dem BigQuery-Abrechnungsexport anpassen und analysieren und Kostendaten mit Looker Studio visualisieren. Mit dem Prognosetool können Sie den Trend der tatsächlichen Kosten und die voraussichtlichen Ausgaben abschätzen.

Ressourcennutzung und -kosten optimieren

In diesem Abschnitt werden Best Practices empfohlen, mit denen Sie die Nutzung und Kosten Ihrer Ressourcen in Google Cloud-Diensten optimieren können.

Um Budgetüberschreitungen zu vermeiden, sollten Sie Standardbudgets und -benachrichtigungen mit hohen Grenzwerten für alle Ihre Projekte konfigurieren. Damit die Budgets eingehalten werden, sollten Sie Folgendes tun:

• Budgets und Benachrichtigungen für Projekte konfigurieren, bei denen absolute Nutzungslimits erforderlich sind (z. B. Trainings- oder Sandbox-Projekte)

• Budgets basierend auf den Finanzbudgets definieren, die Sie verfolgen müssen. Wenn eine Abteilung beispielsweise über ein Cloud-Gesamtbudget verfügt, legen Sie den Umfang des Google Cloud-Budgets so fest, dass er die spezifischen Projekte umfasst, die Sie verfolgen müssen.

• Damit die Budgets eingehalten werden, delegieren Sie die Verantwortung für die Konfiguration von Budgets und Benachrichtigungen an die Teams, die für die Arbeitslasten verantwortlich sind.

Darüber hinaus empfehlen wir Folgendes, um die Kosten zu optimieren:

• Deckeln Sie die API-Nutzung, wenn sie nur minimale oder keine geschäftlichen Auswirkungen hat. Die Obergrenze kann für Sandbox- oder Trainingsprojekte und für Projekte mit festen Budgets (z. B. Ad-hoc-Analysen in BigQuery) nützlich sein. Durch die Kostendeckelung werden nicht alle Ressourcen und Daten aus den zugehörigen Projekten entfernt.
• Verwenden Sie Kontingente, um harte Limits für die Drosselung der Ressourcenbereitstellung festzulegen. Mit Kontingenten können Sie die Kosten kontrollieren und böswillige Verwendungen oder Missbrauch von Ressourcen verhindern. Kontingente gelten auf Projektebene pro Ressourcentyp und Standort.
• Sehen Sie sich die Empfehlungen zur Kostenoptimierung im Recommendation Hub an und implementieren Sie sie.
• Mit Rabatten für zugesicherte Nutzung (Committed Use Discounts, CUD) können Sie Geld bei Ressourcen für Arbeitslasten mit vorhersehbaren Ressourcenanforderungen sparen.

Tools und Techniken

Durch die On-Demand-Bereitstellung und die nutzungsabhängige Abrechnung der Cloud können Sie Ihre IT-Ausgaben optimieren. In diesem Abschnitt werden Tools beschrieben, die Google Cloud bietet, sowie Techniken, mit denen Sie Kosten Ihrer Ressourcen in der Cloud verfolgen und kontrollieren können. Machen Sie sich mit den grundlegenden Cloud Billing-Konzepten vertraut, bevor Sie diese Tools und Techniken verwenden.

Abrechnungsberichte

Google Cloud bietet Abrechnungsberichte in der Google Cloud Console, in denen Sie sich Ihre aktuellen und prognostizierten Ausgaben ansehen können. Mit den Abrechnungsberichten können Sie sich Kostendaten auf einer einzigen Seite ansehen, Trends erkennen und analysieren, die Kosten am Ende des Zeitraums prognostizieren und bei Bedarf Korrekturmaßnahmen ergreifen.

Abrechnungsberichte liefern die folgenden Daten:

• Die Kosten und Kostentrends für einen bestimmten Zeitraum sind so gegliedert:
  • Nach Rechnungskonto
  • Nach Projekt
  • Nach Produkt (z. B. Compute Engine)
  • Nach SKU (z. B. statische IP-Adressen)
• Die potenziellen Kosten, wenn Rabatte oder Aktionsgutschriften ausgeschlossen werden
• Prognostizierte Ausgaben

Datenexport nach BigQuery

Sie können Abrechnungsberichte nach BigQuery exportieren und Kosten mithilfe detaillierter und historischer Ansichten von Daten, einschließlich Daten, die mithilfe von Labels kategorisiert sind, analysieren. Sie können erweiterte Analysen mit BigQuery ML ausführen. Wir empfehlen, den Export von Abrechnungsberichten nach BigQuery zu aktivieren, wenn Sie das Cloud-Rechnungskonto erstellen. Ihr BigQuery-Dataset enthält Abrechnungsdaten ab dem Datum, an dem Sie den Cloud Billing-Export eingerichtet haben. Das Dataset enthält keine Daten für den Zeitraum vor der Aktivierung des Exports.

Hinweis: Exportierte Abrechnungsdaten können aufgrund von verspätet gemeldeten Daten, Zeitstempelabweichungen, Fehlern und Korrekturen sowie Steuern von den Daten auf den Abrechnungsrechnungen abweichen. Weitere Informationen finden Sie unter Unterschiede zwischen exportierten Daten und Rechnungen.

Zum Visualisieren von Kostendaten können Sie benutzerdefinierte Dashboards erstellen, die sich in BigQuery einbinden lassen (Beispielvorlagen: Looker, Looker Studio).

Sie können Tags und Labels als Kriterien für das Filtern der exportierten Abrechnungsdaten verwenden. Der Abrechnungsexport enthält nur eine begrenzte Anzahl von Labels. Bis zu 1.000 Labelzuordnungen innerhalb eines Zeitraums von einer Stunde bleiben erhalten. Labels werden nicht in der PDF- oder CSV-Rechnung angezeigt. Ziehen Sie in Betracht, Ressourcen mithilfe von Tags oder Labels zu kennzeichnen, die auf die Geschäftseinheit, die interne Rückbuchungseinheit und andere relevante Metadaten hinweisen.

Zugriffssteuerung auf die Abrechnung

Sie können den Zugriff auf Cloud Billing für bestimmte Ressourcen steuern, indem Sie für die Ressourcen IAM-Richtlinien (Identity and Access Management) definieren. Um den Zugriff auf Cloud Billing zu gewähren oder zu beschränken, können Sie eine IAM-Richtlinie auf Organisationsebene, Cloud-Rechnungskontoebene oder Projektebene festlegen.

Hinweis: Rechnungskonten sind zwar mit Projekten verknüpft, sind bei IAM aber nicht Projekten übergeordnet. Projekte übernehmen keine Berechtigungen vom Rechnungskonto, mit dem sie verknüpft sind.

Die Zugriffssteuerung für die Abrechnung und Ressourcenverwaltung folgt dem Grundsatz der Aufgabentrennung. Jeder Nutzer hat nur die Berechtigungen, die für seine geschäftliche Rolle erforderlich sind. Die Rollen "Organisationsadministrator" und "Abrechnungsadministrator" haben nicht dieselben Berechtigungen.

Sie können abrechnungsbezogene Berechtigungen auf Rechnungskonto- und Organisationsebene festlegen. Die gängigen Rollen sind "Rechnungskontoadministrator", "Rechnungskontonutzer" und "Rechnungskontobetrachter".

Wir empfehlen, die Rechnungsstellung zu verwenden oder eine sekundäre Zahlungsmethode zu konfigurieren. Verwalten Sie die Kontakt- und Benachrichtigungseinstellungen für die Abrechnung und Zahlung.

Budgets, Benachrichtigungen und Kontingente

Mit Budgets können Sie die tatsächlichen Google Cloud-Kosten mit den geplanten Ausgaben vergleichen. Wenn Sie ein Budget erstellen, können Sie Benachrichtigungsregeln konfigurieren, um E-Mail-Benachrichtigungen auszulösen, wenn die tatsächlichen oder prognostizierten Ausgaben einen definierten Grenzwert überschreiten. Mit Budgets können Sie auch die Antworten zur Kostenkontrolle automatisieren.

Budgets können Benachrichtigungen auslösen, die Sie über Ressourcennutzung und Kostentrends informieren und zur Durchführung von Kostenoptimierungsaktionen auffordern. Budgets verhindern jedoch nicht die Nutzung oder Abrechnung Ihrer Dienste, wenn die tatsächlichen Kosten das Budget oder den Grenzwert erreichen oder überschreiten. Zur automatischen Kostenkontrolle können Sie Cloud Billing mithilfe von Budgetbenachrichtigungen programmatisch für ein Projekt deaktivieren. Sie können auch die API-Nutzung begrenzen, um Kosten nach einem definierten Nutzungsgrenzwert zu verhindern.

Sie können Benachrichtigungen für Rechnungskonten und Projekte konfigurieren. Konfigurieren Sie mindestens ein Budget für ein Konto.

Wenn Sie die Bereitstellung von Ressourcen über ein vordefiniertes Niveau hinaus verhindern oder das Volumen bestimmter Vorgänge begrenzen möchten, können Sie Kontingente auf Ressourcen- oder API-Ebene festlegen. Im Folgenden finden Sie Beispiele für die Verwendung von Kontingenten:

• Anzahl der API-Aufrufe pro Sekunde steuern.
• Anzahl der erstellten VMs beschränken.
• Menge der pro Tag abgefragten Daten in BigQuery einschränken.

Projektinhaber können die Kontingente verringern, die auf ein Kontingentlimit angerechnet werden, indem sie mithilfe der Service Usage API Nutzerüberschreibungen auf bestimmte Kontingentlimits anwenden. Weitere Informationen finden Sie unter Nutzerkontingentüberschreibung erstellen.

Verbesserung der Arbeitslasteffizienz

Wir empfehlen die folgenden Strategien, um Ihre Arbeitslasten in Google Cloud kosteneffizient zu gestalten:

• Optimieren Sie die Ressourcennutzung, indem Sie die Produkteffizienz verbessern.
• Senken Sie die Rate, mit der Ihnen Ressourcen in Rechnung gestellt werden.
• Kontrollieren und begrenzen Sie Ressourcennutzung und Ausgaben.

Berücksichtigen Sie bei der Auswahl von Techniken zur Kostensenkung und von Google Cloud-Features den erforderlichen Aufwand und die erwarteten Einsparungen, wie in der folgenden Grafik dargestellt:

Im Folgenden finden Sie eine Zusammenfassung der in der vorherigen Grafik gezeigten Techniken:

• Die folgenden Techniken erzielen möglicherweise hohe Einsparungen mit geringem Aufwand:
  • Rabatte für zugesicherte Nutzung
  • Autoscaling
  • BigQuery-Slots
• Die folgenden Techniken können mit mittlerem bis hohem Aufwand zu hohen Einsparungen führen:
  • Spot-VMs
  • Als serverlose oder containerisierte Anwendungen einrichten
  • Neue Plattform für die Verwendung verwalteter Dienste
• Die folgenden Techniken ermöglichen moderate Einsparungen bei moderatem Aufwand:
  • Benutzerdefinierte Maschinentypen
  • Verwaltung des Cloud Storage-Lebenszyklus
  • Größe anpassen
  • Inaktive Ressourcen zurückgewinnen

Die in den folgenden Abschnitten erläuterten Techniken können Ihnen helfen, die Effizienz Ihrer Arbeitslasten zu verbessern.

Refaktorieren oder Umstrukturierung

Sie können erhebliche Kosteneinsparungen erzielen, wenn Sie Ihre Arbeitslast für die Verwendung von Google Cloud-Produkten refaktorieren oder einrichten. Durch den Wechsel zu serverlosen Diensten wie Cloud Storage, Cloud Run, BigQuery und Cloud Functions, die die Skalierung auf null unterstützen, kann beispielsweise die Effizienz verbessert werden. Sie können die Kosten dieser Produkte mit dem Preisrechner bewerten und vergleichen.

Größe anpassen

Mit dieser Technik können Sie dafür sorgen, dass die Skalierung Ihrer Infrastruktur mit der beabsichtigten Nutzung übereinstimmt. Diese Strategie ist hauptsächlich für IaaS-Lösungen (Infrastructure as a Service) relevant, bei denen Sie für die zugrunde liegende Infrastruktur bezahlen. Beispiel: Sie haben 50 VMs bereitgestellt, die VMs sind jedoch nicht vollständig ausgelastet und Sie stellen fest, dass die Arbeitslasten auf weniger (oder kleineren) VMs effektiv ausgeführt werden können. In diesem Fall können Sie einige der VMs entfernen oder ihre Größe anpassen. Google Cloud bietet Größenempfehlungen, mit denen Sie Möglichkeiten zur Kosteneinsparung erkennen können, ohne die Leistung zu beeinträchtigen. Die Größenanpassung erfordert weniger Aufwand, wenn sie während der Designphase statt nach der Bereitstellung von Ressourcen für die Produktion erfolgt.

Autoscaling

Wenn die von Ihnen verwendeten Produkte dynamisches Autoscaling unterstützen, sollten Sie die Arbeitslasten eventuell dafür konfigurieren, das Autoscaling zu nutzen, um von den Kosten- und Leistungsvorteilen zu profitieren. Für rechenintensive Arbeitslasten können Sie beispielsweise verwaltete Instanzgruppen in Compute Engine verwenden oder die Anwendungen containerisieren und in einem Google Kubernetes Engine-Cluster bereitstellen.

Active Assist-Empfehlungen

Active Assist nutzt Daten, Informationen und maschinelles Lernen, um die Cloud-Komplexität und den Verwaltungsaufwand zu verringern. Mit Active Assist können Sie die Sicherheit, Leistung und Kosten Ihrer Cloud-Topologie einfach optimieren. Sie erhalten intelligente Empfehlungen zur Optimierung von Kosten und Nutzung. Sie können diese Empfehlungen anwenden, um sofortige Kosteneinsparungen und eine höhere Effizienz zu erzielen.

Im Folgenden finden Sie Beispiele für Empfehlungen von Active Assist:

• Compute Engine-Ressourcen auf die richtige Größe anpassen: Größe Ihrer VM-Instanzen anpassen, um die Kosten und Leistung nutzungsbasiert zu optimieren. Sie können inaktive VMs und nichtflüchtige Speicher erkennen, löschen oder sichern, um Ihre Infrastrukturkosten zu optimieren.
• Rabatt für zugesicherte Nutzung: Google Cloud analysiert Ihre bisherige Nutzung, ermittelt die optimale Zusicherungsmenge für Ihre Arbeitslasten und bietet leicht verständliche, praktisch nutzbare Empfehlungen für Kosteneinsparungen. Weitere Informationen finden Sie unter Recommender für Rabatte für zugesicherte Nutzung.
• Unbeaufsichtigte Projekte: Ermitteln Sie unbeaufsichtigte Projekte in Ihrer Organisation und entfernen oder rufen Sie sie zurück. Weitere Informationen finden Sie unter Recommender für unbeaufsichtigtes Projekt.

Eine vollständige Liste finden Sie unter Recommender.

Nächste Schritte

• Cloud Billing-Konzepte
• Budgets und Budgetbenachrichtigungen festlegen
• Optimieren Sie die Kosten für Computing-Dienste, Speicherung, Datenbanken, Netzwerke und Vorgänge:
  • Kosten optimieren: Computing, Container und serverloses Computing
  • Kosten optimieren: Speicher
  • Kosten optimieren: Datenbanken und intelligente Analysen
  • Kosten optimieren: Netzwerk
  • Kosten optimieren: Cloud-Vorgänge
• Weitere Kategorien des Google Cloud-Architektur-Frameworks entdecken

Kosten optimieren: Computing, Container und serverloses Computing

Dieses Dokument des Google Cloud-Architektur-Frameworks enthält Empfehlungen zur Kostenoptimierung Ihrer virtuellen Maschinen (VMs), Container und serverlosen Ressourcen in Google Cloud.

Die Anleitung in diesem Abschnitt richtet sich an Architekten, Entwickler und Administratoren, die für die Bereitstellung und Verwaltung von Rechenressourcen für Arbeitslasten in der Cloud verantwortlich sind.

Rechenressourcen sind der wichtigste Teil Ihrer Cloud-Infrastruktur. Wenn Sie Ihre Arbeitslasten zu Google Cloud migrieren, ist eine typische erste Wahl Compute Engine, womit Sie VMs effizient in der Cloud bereitstellen und verwalten können. Compute Engine bietet eine breite Palette von Maschinentypen und ist global in allen Google Cloud-Regionen verfügbar. Mit den vordefinierten und benutzerdefinierten Maschinentypen von Compute Engine können Sie VMs bereitstellen, die ähnliche Rechenkapazität wie Ihre lokale Infrastruktur bieten, sodass Sie den Migrationsprozess beschleunigen können. Compute Engine bietet Ihnen den Preisvorteil, dass Sie nur für die verwendete Infrastruktur bezahlen. Sie profitieren außerdem von erheblichen Einsparungen, wenn Sie mehr Rechenressourcen mit Rabatten für kontinuierliche Nutzung verwenden.

Neben Compute Engine bietet Google Cloud Container und serverlose Rechendienste. Der serverlose Ansatz kann für neue Dienste, die nicht immer ausgeführt werden, kostengünstiger sein (z. B. APIs, Datenverarbeitung und Ereignisverarbeitung).

Neben allgemeinen Empfehlungen enthält dieses Dokument eine Anleitung zum Optimieren der Kosten Ihrer Rechenressourcen, wenn Sie die folgenden Produkte verwenden:

• Compute Engine
• Google Kubernetes Engine (GKE)
• Cloud Run
• Cloud Functions
• App Engine

Allgemeine Empfehlungen

Die folgenden Empfehlungen gelten für alle Rechen-, Container- und serverlosen Dienste in Google Cloud, die in diesem Abschnitt erörtert werden.

Nutzung und Kosten verfolgen

Verwenden Sie die folgenden Tools und Techniken, um die Ressourcennutzung und -kosten zu überwachen:

• Empfehlungen zur Kostenoptimierung im Recommendation Hub ansehen und umsetzen.
• E-Mail-Benachrichtigungen erhalten, wenn sich die Ressourcennutzung und -kosten erhöhen, indem Sie Budgetbenachrichtigungen konfigurieren.
• Benachrichtigungen programmatisch mit den Pub/Sub- und Cloud Functions-Diensten verwalten und auf sie reagieren.

Bereitstellung von Ressourcen steuern

Verwenden Sie die folgenden Empfehlungen, um die Menge der in der Cloud bereitgestellten Ressourcen und den Standort, an dem die Ressourcen erstellt werden, zu steuern:

• Ressourcenkontingente verwenden, um sicherzustellen, dass der Ressourcenverbrauch und die Kosten die Prognose nicht überschreiten.
• Ressourcen in der Region mit den niedrigsten Kosten bereitstellen, die den Latenzanforderungen Ihrer Arbeitslast entspricht. Einschränkung der Organisationsrichtlinie gcp.resourceLocations verwenden, um zu steuern, wo Ressourcen bereitgestellt werden.

Rabatte für zugesicherte Nutzung erhalten

Rabatte für zugesicherte Nutzung sind ideal für Arbeitslasten mit vorhersehbarem Ressourcenbedarf. Ermitteln Sie nach der Migration Ihrer Arbeitslast zu Google Cloud die Baseline für die erforderlichen Ressourcen und erhalten Sie höhere Rabatte für die zugesicherte Nutzung. Wenn Sie beispielsweise eine Zusicherung für 1 oder 3 Jahre erwerben, erhalten Sie einen erheblichen Rabatt auf die Preise von Compute Engine-VMs.

Kostenverfolgung mithilfe von Labels automatisieren

Definieren Sie Labels und weisen Sie sie konsistent zu. Im Folgenden finden Sie Beispiele dazu, wie Sie mithilfe von Labels die Kostenverfolgung automatisieren können:

• Weisen Sie für VMs, die nur Entwickler während der Geschäftszeiten verwenden, das Label env: development zu. Mit Cloud Scheduler können Sie eine serverlose Cloud Functions-Funktion einrichten, um diese VMs nach den Geschäftszeiten herunterzufahren und bei Bedarf neu zu starten.

• Weisen Sie bei einer Anwendung, die mehrere Cloud Run-Dienste und Cloud Functions-Instanzen hat, allen Cloud Run- und Cloud Functions-Ressourcen ein konsistentes Label zu. Identifizieren Sie die teuren Bereiche und ergreifen Sie Maßnahmen zur Kostensenkung.

Abrechnungsberichte anpassen

Konfigurieren Sie Ihre Cloud Billing-Berichte, indem Sie die erforderlichen Filter einrichten und die Daten nach Bedarf gruppieren (z. B. nach Projekten, Diensten oder Labels).

Kultur der Kosteneinsparung fördern

Schulen Sie Ihre Entwickler und Operatoren bezüglich Ihrer Cloud-Infrastruktur. Erstellen und fördern Sie Lernprogramme mit Präzenz- oder Onlinekursen, Foren, Begutachtungen durch Kollegen, gemeinsamer Programmierung und Kosteneinsparungsspielen. Wie in der DORA-Studie von Google gezeigt, ist die Organisationskultur ein wichtiger Faktor, um die Leistung zu verbessern, Nacharbeit und Burnout zu reduzieren und die Kosten zu optimieren. Durch Einblick in die Kosten ihrer Ressourcen können Mitarbeiter ihre Prioritäten und Aktivitäten an Geschäftszielen und Einschränkungen ausrichten.

Compute Engine

Dieser Abschnitt enthält Anleitungen zur Kostenoptimierung Ihrer Compute Engine-Ressourcen. Zusätzlich zu dieser Anleitung empfehlen wir, dass Sie den zuvor erläuterten allgemeinen Empfehlungen folgen.

Informationen zum Abrechnungsmodell

Weitere Informationen zu den Abrechnungsoptionen für Compute Engine finden Sie unter Preise.

Ressourcenverbrauch analysieren

Damit Sie den Ressourcenverbrauch in Compute Engine nachvollziehen können, müssen Sie Nutzungsdaten nach BigQuery exportieren. Fragen Sie den BigQuery-Datenspeicher ab, um die Trends der vCPU-Nutzung Ihres Projekts zu analysieren und die Anzahl der vCPUs zu ermitteln, die Sie zurückerhalten können. Wenn Sie Grenzwerte für die Anzahl der Kerne pro Projekt definiert haben, analysieren Sie Nutzungstrends, um Anomalien zu erkennen und Korrekturmaßnahmen zu ergreifen.

Inaktive Ressourcen zurückgewinnen

Orientieren Sie sich an den folgenden Empfehlungen, wenn Sie nicht verwendete VMs und Laufwerke identifizieren und zurückerhalten möchten, z. B. VMs für Proof-of-Concept-Projekte, die mittlerweile keine Priorität mehr haben:

• Mit dem Recommender für inaktive VMs können Sie inaktive VMs und nichtflüchtige Speicher anhand von Nutzungsmesswerten identifizieren.
• Bevor Sie Ressourcen löschen, prüfen Sie die möglichen Auswirkungen der Aktion und planen Sie, die Ressourcen bei Bedarf neu zu erstellen.
• Erstellen Sie einen Snapshot, bevor Sie eine VM löschen. Wenn Sie eine VM löschen, werden die angehängten Laufwerke gelöscht, sofern Sie nicht die Option Laufwerk behalten ausgewählt haben.
• Wenn möglich, sollten Sie VMs beenden, anstatt sie zu löschen. Wenn Sie eine VM beenden, wird die Instanz zwar beendet, Laufwerke und IP-Adressen bleiben jedoch erhalten, bis Sie sie trennen oder löschen.

Kapazität an den Bedarf anpassen

VMs so planen, dass sie automatisch gestartet und beendet werden Wenn eine VM beispielsweise nur an fünf Tagen pro Woche acht Stunden pro Tag für verwendet wird (also 40 Stunden pro Woche), können Sie möglicherweise die Kosten um 75 % reduzieren, indem Sie die VM während der 128 Stunden in der Woche, in denen die VM nicht verwendet wird, beenden.

Führen Sie ein Autoscaling von Rechenkapazität anhand des Bedarfs mithilfe von verwalteten Instanzgruppen durch. Sie können die Kapazität anhand der für Ihr Unternehmen relevanten Parameter (z. B. CPU-Nutzung oder Load-Balancing-Kapazität) automatisch skalieren.

Geeignete Maschinentypen auswählen

Passen Sie die Größe Ihrer VMs entsprechend den Rechenanforderungen Ihrer Arbeitslast an. Verwenden Sie dazu den Recommender für den VM-Maschinentyp.

Bei Arbeitslasten mit vorhersehbaren Ressourcenanforderungen können Sie den Maschinentyp mithilfe von benutzerdefinierten VMs an Ihre Anforderungen anpassen und Kosten sparen.

Ziehen Sie für fehlertolerante Batchverarbeitungsarbeitslasten die Verwendung von Spot-VMs in Erwägung. Hochleistungs-Computing (HPC), Big Data, Medientranscodierung, Continuous Integration und Continuous Delivery (CI/CD) sowie zustandslose Webanwendungen sind Beispiele für Arbeitslasten, die auf Spot VMs bereitgestellt werden können. Ein Beispiel dafür, wie Descartes Labs die Analysekosten über VMs auf Abruf (der älteren Version von Spot-VMs) zur Verarbeitung von Satellitenbildern senken kann, finden Sie in der Fallstudie zu Descartes Labs.

Lizenzierungsoptionen bewerten

Wenn Sie Arbeitslasten von Drittanbietern zu Google Cloud migrieren, können Sie die Kosten senken, indem Sie Ihre eigenen Lizenzen (BYOL) verwenden. Wenn Sie beispielsweise Microsoft Windows Server-VMs bereitstellen möchten, können Sie anstelle eines Premium-Images, das zusätzliche Kosten für die Drittanbieterlizenz verursacht, ein benutzerdefiniertes Windows-BYOL-Image erstellen und verwenden. Sie zahlen dann nur für die VM-Infrastruktur, die Sie in Google Cloud verwenden. Mit dieser Strategie können Sie Ihre bestehenden Investitionen in Drittanbieterlizenzen weiter nutzen.

Wenn Sie sich für einen BYOL-Ansatz entscheiden, empfehlen wir Folgendes:

• Stellen Sie die erforderliche Anzahl von Rechen-CPU-Kernen unabhängig vom Arbeitsspeicher mithilfe von benutzerdefinierten Maschinentypen bereit und begrenzen Sie die Lizenzkosten von Drittanbietern auf die Anzahl der CPU-Kerne, die Sie benötigen.
• Reduzieren Sie die Anzahl der vCPUs pro Kern von 2 auf 1, indem Sie das gleichzeitige Multithreading (SMT) deaktivieren und Ihre Lizenzkosten um 50 % reduzieren.

Wenn Ihre Drittanbieter-Arbeitslasten dedizierte Hardware für die Erfüllung von Sicherheits- oder Compliance-Anforderungen benötigen, können Sie eigene Lizenzen auf Knoten für einzelne Mandanten verwenden.

Google Kubernetes Engine

Dieser Abschnitt enthält eine Anleitung zum Optimieren der Kosten Ihrer GKE-Ressourcen.

Zusätzlich zu den folgenden Empfehlungen finden Sie weitere Informationen in den zuvor erläuterten Allgemeinen Empfehlungen:

• Verwenden Sie GKE Autopilot, damit GKE die Effizienz der Clusterinfrastruktur maximieren kann. Sie müssen nicht den Zustand Ihrer Knoten überwachen, kein Bin-Packing vornehmen und nicht die für Ihre Arbeitslasten erforderliche Kapazität berechnen.
• Führen Sie die Feinabstimmung von GKE-Autoscaling mit dem horizontalen Pod-Autoscaler (HPA), vertikalen Pod-Autoscaler (VPA), Cluster Autoscaler (CA) oder der automatischen Knotenbereitstellung basierend auf den Anforderungen Ihrer Arbeitslast durch.
• Verwenden Sie für Batcharbeitslasten, die nicht anfällig für Startlatenz sind, das Autoscaling-Profil optimization-utilization, um die Auslastung des Clusters zu verbessern.
• Verwenden Sie die automatische Knotenbereitstellung, um das GKE-Cluster-Autoscaling zu erweitern und Knotenpools gemäß den Spezifikationen für ausstehende Pods ohne Überdimensionierung effizient zu erstellen und zu löschen.
• Verwenden Sie separate Knotenpools: ein statischer Knotenpool für statisches Laden und dynamische Knotenpools mit Cluster-Autoscaling-Gruppen für dynamisches Laden.
• Verwenden Sie Spot VMs für Kubernetes-Knotenpools, wenn Ihre Pods fehlertolerant sind und in weniger als 25 Sekunden ordnungsgemäß beendet werden können. In Kombination mit dem GKE-Cluster-Autoscaler können Sie mit dieser Strategie dafür sorgen, dass der Knotenpool mit kostengünstigeren VMs (in diesem Fall der Knotenpool mit Spot-VMs) zuerst skaliert wird.
• Wählen Sie kostengünstige Maschinentypen aus, z. B. E2, N2D, T2D), die ein bis zu 40 % besseres Preis-Leistungs-Verhältnis bieten.
• Verwenden Sie die GKE-Nutzungsmessung, um die Nutzungsprofile Ihrer Cluster nach Namespaces und Labels zu analysieren. Identifizieren Sie das Team oder die Anwendung, die am meisten ausgibt, die Umgebung oder Komponente, die Nutzungsspitzen oder Kostenspitzen verursacht hat, und das Team, das Ressourcen verschwendet.
• Verwenden Sie Ressourcenkontingente in mehrmandantenfähigen Clustern, um zu verhindern, dass ein Mandant mehr als den ihm zugewiesenen Anteil an Clusterressourcen nutzt.
• Planen Sie ein automatisches Herunterskalieren von Entwicklungs- und Testumgebungen nach Geschäftszeiten.
• Befolgen Sie die Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE.

Cloud Run

Dieser Abschnitt enthält Anleitungen zur Kostenoptimierung Ihrer Cloud Run-Ressourcen.

Zusätzlich zu den folgenden Empfehlungen finden Sie weitere Informationen in den zuvor erläuterten Allgemeinen Empfehlungen:

• Passen Sie die Nebenläufigkeitseinstellung (Standard: 80) an, um die Kosten zu senken. Cloud Run bestimmt die Anzahl der Anfragen, die an eine Instanz gesendet werden sollen, basierend auf der CPU- und Arbeitsspeichernutzung. Wenn Sie die Nebenläufigkeit von Anfragen erhöhen, können Sie die Anzahl der erforderlichen Instanzen reduzieren.
• Legen Sie ein Limit für die Anzahl der Instanzen fest, die bereitgestellt werden können.
• Schätzen Sie die Anzahl der erforderlichen Instanzen mithilfe des Messwerts der abrechenbaren Instanzzeit. Wenn der Messwert beispielsweise 100s/s anzeigt, wurden etwa 100 Instanzen geplant. Fügen Sie einen Puffer von 30 % hinzu, um die Leistung beizubehalten, also 130 Instanzen für 100 s/s an Traffic.
• Konfigurieren Sie eine Mindestanzahl von Instanzen, um die Auswirkungen von Kaltstarts zu reduzieren. Wenn diese Instanzen inaktiv sind, werden sie zu einem Zehntel des Preises abgerechnet.
• Verfolgen Sie die CPU-Nutzung und passen Sie die CPU-Limits entsprechend an.
• Verwenden Sie die Trafficverwaltung, um eine kostenoptimierte Konfiguration zu bestimmen.
• Erwägen Sie die Verwendung von Cloud CDN oder Firebase Hosting zum Bereitstellen statischer Inhalte.
• Erwägen Sie für Cloud Run-Anwendungen, die Anfragen global verarbeiten, die Anwendung in mehreren Regionen bereitzustellen, da interkontinentale Datenübermittlung teuer sein kann. Dieses Design wird empfohlen, wenn Sie einen Load-Balancer und CDN verwenden.
• Reduzieren Sie die Startzeiten für Ihre Instanzen, da die Startzeit auch kostenpflichtig ist.
• Erwerben Sie Rabatte für zugesicherte Nutzung und sparen Sie bis zu 17 % des On-Demand-Preises für eine einjährige Nutzungszusicherung.

Cloud Functions

Dieser Abschnitt enthält Anleitungen zur Kostenoptimierung Ihrer Cloud Functions-Ressourcen.

Zusätzlich zu den folgenden Empfehlungen finden Sie weitere Informationen in den zuvor erläuterten Allgemeinen Empfehlungen:

• Beobachten Sie die Ausführungszeit Ihrer Funktionen. Experimentieren Sie und führen Sie Benchmark-Tests durch, um die kleinste Funktion zu entwerfen, die noch den erforderlichen Leistungsgrenzwert erreicht.
• Wenn Ihre Cloud Functions-Arbeitslasten ständig ausgeführt werden, sollten Sie eventuell GKE oder Compute Engine verwenden, um die Arbeitslasten zu verarbeiten. Container oder VMs sind möglicherweise kostengünstigere Optionen für immer ausgeführte Arbeitslasten.
• Beschränken Sie die Anzahl der Funktionsinstanzen, die gleichzeitig vorhanden sein können.
• Vergleichen Sie die Laufzeitleistung der Cloud Functions-Programmiersprachen mit der Arbeitslast Ihrer Funktion. Programme in kompilierten Sprachen haben längere Kaltstarts, werden jedoch schneller ausgeführt. Programme in interpretierten Sprachen sind langsamer, haben aber einen geringeren Kaltstartaufwand. Kurze, einfache Funktionen, die häufig ausgeführt werden, können in einer interpretierten Sprache weniger kosten.
• Löschen Sie temporäre Dateien, die auf das lokale Laufwerk geschrieben wurden. Dabei handelt es sich um ein speicherinternes Dateisystem. Temporäre Dateien belegen Arbeitsspeicher, der Ihrer Funktion zugewiesen ist, und bleiben manchmal zwischen Aufrufen bestehen. Wenn Sie diese Dateien nicht löschen, kann ein Fehler aufgrund fehlenden Arbeitsspeichers auftreten und einen Kaltstart auslösen, was die Ausführungszeit und Kosten erhöht.

App Engine

Dieser Abschnitt enthält Anleitungen zur Kostenoptimierung Ihrer App Engine-Ressourcen.

Zusätzlich zu den folgenden Empfehlungen finden Sie weitere Informationen in den zuvor erläuterten Allgemeinen Empfehlungen:

• Legen Sie die maximale Anzahl von Instanzen auf der Grundlage Ihres Traffics und der Anfragelatenz fest. App Engine skaliert die Kapazität normalerweise auf Basis des Traffics, den die Anwendungen erhalten. Sie können die Kosten kontrollieren, indem Sie die Anzahl der Instanzen begrenzen, die App Engine erstellen kann.
• Wenn Sie den für Ihre Anwendung verfügbaren Arbeitsspeicher oder die CPU begrenzen möchten, legen Sie eine Instanzklasse fest. Weisen Sie für CPU-intensive Anwendungen mehr CPU zu. Testen Sie einige Konfigurationen, um die optimale Größe zu ermitteln.
• Vergleichen Sie Ihre App Engine-Arbeitslast in mehreren Programmiersprachen. Beispielsweise benötigt eine in einer bestimmten Sprache implementierte Arbeitslast vielleicht weniger Instanzen und verursacht geringere Kosten, um Aufgaben rechtzeitig auszuführen, als dieselbe Arbeitslast, die in einer anderen Sprache programmiert ist.
• Optimieren Sie für weniger Kaltstarts. Verringern Sie nach Möglichkeit die CPU-intensiven oder lang andauernden Aufgaben im globalen Bereich. Versuchen Sie, die Aufgabe in kleinere Vorgänge aufzuteilen, die im Kontext einer Anfrage "verzögert geladen" werden können.
• Wenn Sie stoßweisen Traffic erwarten, konfigurieren Sie eine Mindestanzahl inaktiver Instanzen, die vorbereitet werden. Wenn Sie keinen Traffic erwarten, können Sie die Mindestanzahl inaktiver Instanzen auf null festlegen.
• Wenn Sie Leistung und Kosten ausbalancieren möchten, führen Sie einen A/B-Test durch, indem Sie den Traffic auf zwei Versionen aufteilen, die jeweils eine andere Konfiguration haben. Überwachen Sie die Leistung und die Kosten der einzelnen Versionen, passen Sie sie bei Bedarf an und wählen Sie die Konfiguration aus, an die der Traffic gesendet werden soll.
• Konfigurieren Sie die Nebenläufigkeit von Anfragen und legen Sie für die maximale Anzahl gleichzeitiger Anfragen einen höheren Wert als den Standardwert fest. Je mehr Anfragen jede Instanz gleichzeitig verarbeiten kann, desto effizienter können Sie vorhandene Instanzen zur Bereitstellung von Traffic verwenden.

Nächste Schritte

• Weitere Informationen zum Optimieren der Kosten von GKE-Ressourcen:
  • Kostenoptimierte Kubernetes-Anwendungen in GKE ausführen: Best Practices
  • Best Practices zur Reduzierung der GKE-Überdimensionierung
  • Ressourcennutzung in einem GKE-Cluster mit mehreren Mandanten mithilfe der automatischen Knotenbereitstellung optimieren
  • Kostensenkung durch Herunterskalieren von GKE-Clustern außerhalb der Spitzenzeiten
  • Webanwendungen in GKE mit kostenoptimierten Spot-VMs ausführen
  • GKE-Kosten am Anfang des Entwicklungszyklus mit GitLab schätzen
  • Videoreihe: GKE-Kostenoptimierung
  • Training: Kosten für GKE optimieren
• Weitere Informationen zur Kostenoptimierung von Cloud Run- und Cloud Functions-Ressourcen:
  • Managing cost and reliability in fully managed applications
  • Optimizing for long-term cost management in fully managed applications
  • Nutzen Ihrer Cloud Run-Investitionen mit neuen Rabatten für zugesicherte Nutzung maximieren
• Kosten für Speicher, Datenbanken, Netzwerke und Vorgänge optimieren:
  • Kosten optimieren: Speicher
  • Kosten optimieren: Datenbanken und intelligente Analysen
  • Kosten optimieren: Netzwerk
  • Kosten optimieren: Cloud-Vorgänge
• Weitere Kategorien des Google Cloud-Architektur-Frameworks entdecken

Kosten optimieren: Speicher

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Optimierung der Nutzung und Kosten Ihrer Cloud Storage-, nichtflüchtigen Speicher- und Filestore-Ressourcen.

Die Informationen in diesem Abschnitt richten sich an Architekten und Administratoren, die für die Bereitstellung und Verwaltung von Speicher für Arbeitslasten in der Cloud zuständig sind.

Hinweis: Eine Anleitung zur Auswahl von Speicherdiensten, die für Ihre Arbeitslast geeignet sind, finden Sie unter Optimale Speicherstrategie für Ihre Cloud-Arbeitslast entwerfen.

Cloud Storage

Berücksichtigen Sie bei der Planung von Cloud Storage für Ihre Arbeitslasten Ihre Anforderungen an Leistung, Datenaufbewahrung und Zugriffsmuster.

Speicherklasse

Wählen Sie eine Speicherklasse aus, die den Anforderungen an die Datenaufbewahrung und die Zugriffshäufigkeit Ihrer Arbeitslasten entspricht, wie in der folgenden Tabelle empfohlen:

Speicheranforderung	Empfehlung
Daten, auf die häufig zugegriffen wird (Analysen mit hohem Durchsatz oder Data Lakes, Websites, Streamingvideos und mobile Apps).	Standard Storage
Kostengünstiger Speicher für selten aufgerufene Daten, die mindestens 30 Tage gespeichert werden sollten, z. B. Sicherungen und Longtail-Multimedia-Inhalte.	Nearline Storage
Selten aufgerufene Daten, die mindestens 90 Tage gespeichert werden sollten (z. B. Datenreplikate für die Notfallwiederherstellung).	Coldline Storage
Günstigste Speicher für Daten, auf die selten zugegriffen wird und die mindestens 365 Tage gespeichert werden sollten (z. B. rechtlich und regulatorisch erforderliche Archive).	Archive Storage

Hinweis: Die Speicherklassen Nearline, Coldline und Archive sind günstiger als Standard Storage, jedoch fallen Gebühren für den Datenabruf und ein Abzug für das vorzeitige Löschen an.

Ort

Wählen Sie den Standort für Ihre Buckets basierend auf Ihren Anforderungen an Leistung, Verfügbarkeit und Datenredundanz aus.

• Regionen werden empfohlen, wenn sich die Region in der Nähe Ihrer Endnutzer befindet. Sie können eine bestimmte Region auswählen und erhalten so eine garantierte Redundanz innerhalb der Region. Regionen bieten einen schnellen, redundanten und kostengünstigen Speicher für Datasets, die Nutzer innerhalb eines bestimmten geografischen Bereichs häufig aufrufen.
• Multiregionen bieten eine hohe Verfügbarkeit für verteilte Nutzer. Die Speicherkosten sind jedoch höher als bei Regionen. Multiregionale Buckets werden für Anwendungsfälle für die Inhaltsbereitstellung und für niedrige Analysearbeitslasten empfohlen.
• Dual-Regionen bieten Hochverfügbarkeit und Datenredundanz. Google empfiehlt Buckets mit zwei Regionen für Hochleistungs-Analysearbeitslasten und für Anwendungsfälle, bei denen echte Aktiv-Aktiv-Buckets mit Computing und Speicher an mehreren Standorten erforderlich sind. Mit Dual-Regionen können Sie auswählen, wo Ihre Daten gespeichert werden, sodass Sie die Complianceanforderungen erfüllen können. Sie können beispielsweise einen Bucket mit zwei Regionen verwenden, um branchenspezifische Anforderungen in Bezug auf die physische Entfernung zwischen Kopien Ihrer Daten in der Cloud zu erfüllen.

Lebenszyklusrichtlinien

Optimieren Sie die Speicherkosten für Ihre Objekte in Cloud Storage durch das Definieren von Lebenszyklusrichtlinien. Mit diesen Richtlinien können Sie Geld sparen. Dazu führen Sie ein automatisches Downgrade der Speicherklasse bestimmter Objekte oder löschen Objekte, die auf den von Ihnen festgelegten Bedingungen basieren.

Konfigurieren Sie Lebenszyklusrichtlinien basierend darauf, wie häufig auf Objekte zugegriffen wird und wie lange Sie diese aufbewahren müssen. Im Folgenden finden Sie Beispiele für Lebenszyklusrichtlinien:

• Downgrade-Richtlinie: Sie gehen davon aus, dass häufig auf Datasets zugegriffen wird, jedoch nur für etwa drei Monate. Verwenden Sie Standard Storage und konfigurieren Sie eine Lebenszyklusrichtlinie, um ein Downgrade von Objekten auf einen Coldline Storage durchzuführen, um die Speicherkosten für dieses Dataset zu optimieren.

• Löschrichtlinie: Ein Dataset muss 365 Tage lang aufbewahrt werden, um bestimmte rechtliche Anforderungen zu erfüllen. Nach diesem Zeitraum kann das Dataset gelöscht werden. Konfigurieren Sie eine Richtlinie, um alle Objekte zu löschen, die älter als 365 Tage sind.

  Sie können dafür sorgen, dass Daten, die eine bestimmte Periode aufbewahrt werden müssen, aus rechtlichen oder regulatorischen Gründen, keinesfalls vor diesem Datum oder dieser Uhrzeit gelöscht werden. Dazu konfigurieren Sie Sperren von Aufbewahrungsrichtlinien.

Hinweis: Bei den Langzeitspeicherklassen (Nearline, Coldline und Archive) fallen Gebühren für den Datenabruf und ein Abzug für das vorzeitige Löschen im Vergleich zu Standard Storage an. Wenn auf Daten, die in einer Langzeitspeicherklasse gespeichert sind, häufig zugegriffen werden muss, können Sie die Daten in einen Cloud Storage-Standard-Bucket kopieren, um höhere Zugriffsgebühren zu vermeiden.

Rechenschaftspflicht

Bei Bedarf können Sie die Verteilung der Betriebskosten, Netzwerkgebühren und Kosten für den Datenabruf steuern, wenn Sie die Konfiguration Anforderer bezahlt verwenden. Bei dieser Konfiguration werden die Kosten der Abteilung oder dem Team berechnet, das die Daten verwendet, und nicht dem Inhaber.

Definieren und weisen Sie Kostenverfolgungslabels für alle Buckets und Objekte konsistent zu. Automatisieren Sie die Labelerstellung, wenn möglich.

Redundanz

Verwenden Sie die folgenden Techniken, um die erforderliche Speicherredundanz ohne Datenduplizierung aufrechtzuerhalten:

• Sie können die Datenausfallsicherheit mit einer Single Source of Truth aufrechterhalten. Dazu verwenden Sie einen Dual-Region- oder ulti-Region-Bucket anstelle von redundanten Datenkopien in verschiedenen Buckets. Dual- und multiregionale Buckets bieten regionsübergreifende Redundanz. Die Daten werden asynchron über zwei oder mehr Standorte repliziert und vor regionalen Ausfällen geschützt.
• Wenn Sie die Objektversionsverwaltung aktivieren, sollten Sie Lebenszyklusrichtlinien definieren, um die älteste Version eines Objekts zu entfernen und neuere Versionen als nicht mehr aktuell zu definieren. Jede nicht aktuelle Version eines Objekts wird zum gleichen Preis abgerechnet wie die Live-Version des Objekts.
• Deaktivieren Sie die Richtlinien zur Objektversionsverwaltung, wenn sie nicht mehr benötigt werden.
• Prüfen Sie Ihre Sicherungs- und Snapshot-Aufbewahrungsrichtlinien regelmäßig und passen Sie sie an, um unnötige Sicherungen und Datenaufbewahrung zu vermeiden.

Persistent Disk

Jede VM-Instanz, die Sie in Compute Engine bereitstellen, hat ein Bootlaufwerk und (optional) ein oder mehrere Datenlaufwerke. Je nach bereitgestellter Größe, Region und Laufwerkstyp fallen Kosten für jedes Laufwerk an. Für Snapshots, die von Ihren Laufwerken erstellt werden, fallen Kosten an, die auf der Größe des Snapshots basieren.

Beachten Sie die folgenden Empfehlungen für Design und Betrieb, um die Kosten Ihrer nichtflüchtigen Speicher zu optimieren:

• Weisen Sie nicht zu viel Speicherplatz zu. Nach der Bereitstellung können Sie die Laufwerkskapazität nicht mehr reduzieren. Beginnen Sie mit einem kleinen Laufwerk und erhöhen Sie bei Bedarf die Größe. Nichtflüchtige Speicher werden nach der bereitgestellten Kapazität abgerechnet, nicht nach den auf den Laufwerken gespeicherten Daten.

• Wählen Sie einen Laufwerkstyp aus, der den Leistungsmerkmalen Ihrer Arbeitslast entspricht. SSD-Speicher bieten einen hohen IOPS-Wert und Durchsatz, kosten jedoch mehr als nichtflüchtige Standardspeicher.

• Verwenden Sie regionale nichtflüchtige Speicher nur, wenn Sie Daten vor zonalen Ausfällen schützen. Regionale nichtflüchtige Speicher werden in eine andere Zone innerhalb der Region repliziert, sodass die Kosten der entsprechenden zonalen Laufwerke verdoppelt werden.

• Verfolgen Sie die Nutzung Ihrer nichtflüchtigen Speicher mit Cloud Monitoring und richten Sie Benachrichtigungen für Laufwerke mit geringer Nutzung ein.

• Löschen Sie nicht mehr benötigte Websites

• Für Laufwerke, die möglicherweise Daten in Zukunft benötigen, sollten Sie die Daten in einem kostengünstigen Cloud Storage archivieren und dann die Laufwerke löschen.

• Suchen Sie nach den Empfehlungen im Recommendation Hub und beantworten Sie diese.

Ziehen Sie auch die Verwendung von Hyperdisks für Hochleistungsspeicher und flüchtigen Laufwerken (lokalen SSDs) für temporären Speicher in Betracht.

Snapshots von Laufwerken sind standardmäßig inkrementell und werden automatisch komprimiert. Beachten Sie die folgenden Empfehlungen für die Optimierung der Kosten Ihrer Laufwerk-Snapshots:

• Organisieren Sie Ihre Daten nach Möglichkeit in separaten nichtflüchtigen Speichern. Sie können dann Laufwerke selektiv sichern und die Kosten für Laufwerk-Snapshots reduzieren.
• Wählen Sie beim Erstellen eines Snapshots einen Standort anhand Ihrer Verfügbarkeitsanforderungen und der zugehörigen Netzwerkkosten aus.
• Wenn Sie einen Snapshot eines Bootlaufwerks zum Erstellen mehrerer VMs verwenden möchten, erstellen Sie ein Image aus dem Snapshot und verwenden Sie das Image dann zum Erstellen Ihrer VMs. Mit diesem Ansatz können Sie Netzwerkgebühren für Daten vermeiden, die zwischen dem Standort des Snapshots und dem Standort der Wiederherstellung übertragen werden.
• Erwägen Sie die Einrichtung einer Aufbewahrungsrichtlinie, um die langfristigen Speicherkosten für Laufwerk-Snapshots zu minimieren.
• Löschen Sie nicht mehr benötigte Laufwerk-Snapshots. Jeder Snapshot in einer Kette kann von den Daten abhängen, die in einem vorherigen Snapshot gespeichert sind. Beim Löschen eines Snapshots werden also nicht unbedingt alle Daten im Snapshot gelöscht. Sie müssen alle Snapshots in der Kette löschen, um Daten endgültig aus Snapshots zu löschen.

Filestore

Die Kosten einer Filestore-Instanz hängen von ihrer Dienststufe, der bereitgestellten Kapazität und der Region ab, in der die Instanz bereitgestellt wird. Im Folgenden finden Sie Empfehlungen zum Design und zum Betrieb, um die Kosten Ihrer Filestore-Instanzen zu optimieren:

• Wählen Sie eine Dienststufe und einen Speichertyp (HDD oder SSD) aus, die Ihren Speicheranforderungen entsprechen.
• Weisen Sie keine übermäßige Kapazität zu. Beginnen Sie mit einer kleinen Größe und erhöhen Sie die Kapazität später bei Bedarf. Die Filestore-Abrechnung basiert auf der bereitgestellten Kapazität, nicht auf den gespeicherten Daten.
• Organisieren Sie Ihre Daten nach Möglichkeit in separaten Filestore-Instanzen. Sie können dann Instanzen selektiv sichern und die Kosten von Filestore-Sicherungen reduzieren.
• Bei der Auswahl der Region und Zone sollten Sie erwägen, die Instanzen in derselben Zone wie die Clients zu erstellen. Ihnen wird der Datenübertragungs-Traffic aus der Zone der Filestore-Instanz in Rechnung gestellt.
• Berücksichtigen Sie bei der Entscheidung für die Region, in der die Filestore-Sicherungen gespeichert werden sollen, die Gebühren für die Datenübertragung zum Speichern von Sicherungen in einer anderen Region als der Quellinstanz.
• Verfolgen Sie die Nutzung Ihrer Filestore-Instanzen mit Cloud Monitoring und richten Sie Benachrichtigungen für Instanzen mit geringer Nutzung ein.
• Skalieren Sie die zugewiesene Kapazität für Filestore-Instanzen herunter, die wenig verwendet werden. Sie können die Kapazität von Instanzen mit Ausnahme der Basis-Stufe reduzieren.

Nächste Schritte

• Lesen Sie den Blog Best practices for Cloud Storage cost optimization
• Optimieren Sie die Kosten für Computing-Dienste, Datenbanken, Netzwerke und Vorgänge:
  • Kosten optimieren: Computing, Container und serverloses Computing
  • Kosten optimieren: Datenbanken und intelligente Analysen
  • Kosten optimieren: Netzwerk
  • Kosten optimieren: Cloud-Vorgänge
• Weitere Kategorien des Google Cloud-Architektur-Frameworks entdecken

Kosten optimieren: Datenbanken und intelligente Analysen

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Minimierung der Kosten Ihrer Datenbanken und Analysearbeitslasten in Google Cloud.

Die Anleitung in diesem Abschnitt richtet sich an für die Bereitstellung und Verwaltung von Datenbanken und Analysearbeitslasten in der Cloud verantwortliche Architekten, Entwickler und Administratoren.

Dieser Abschnitt enthält Empfehlungen zur Kostenoptimierung für folgende Produkte:

• Cloud SQL
• Spanner
• Bigtable
• BigQuery
• Dataflow
• Dataproc

Cloud SQL

Cloud SQL ist ein vollständig verwalteter relationaler Datenbankdienst für MySQL, PostgreSQL und SQL Server.

Nutzung überwachen

Prüfen Sie die Messwerte im Monitoring-Dashboard und bewerten Sie, ob Ihre Bereitstellung die Anforderungen Ihrer Arbeitslast erfüllt.

Ressourcen optimieren

Im Folgenden finden Sie Empfehlungen zur Optimierung Ihrer Cloud SQL-Ressourcen:

• Entwerfen Sie eine Strategie für Hochverfügbarkeit und Notfallwiederherstellung, die Ihrem Recovery Time Objective (RTO) und dem Recovery Point Objective (RPO) entspricht. Je nach Arbeitslast empfehlen wir Folgendes:
  • Verwenden Sie für Arbeitslasten, die ein kurzes RTO/RPO benötigen, die Hochverfügbarkeitskonfiguration und Replikate für regionale Failovers.
  • Verwenden Sie für Arbeitslasten, die einen längeren RTO/RPO-Wert erlauben, automatische und On-Demand-Sicherungen, die nach einem Fehler etwas länger zur Wiederherstellung benötigen können.
• Stellen Sie die Datenbank mit der erforderlichen Mindestspeicherkapazität bereit.
• Soll die Speicherkapazität bei wachsender Datenmenge automatisch skaliert werden, aktivieren Sie die Funktion Automatische Speichererweiterung.
• Wählen Sie einen für Ihren Anwendungsfall geeigneten Speichertyp: SSD (Solid State Drives) oder HDD (Festplattenlaufwerke). SSDs sind die effizienteste und kostengünstigste Wahl für die meisten Anwendungsfälle. HDDs eignen sich eher für große Datasets (>10 TB), die nicht latenzempfindlich sind und auf die nur selten zugegriffen wird.

Preise optimieren

Erwägen Sie den Kauf von Rabatten für die zugesicherte Nutzung für Arbeitslasten mit vorhersehbarem Ressourcenbedarf. Bei einer einjährigen Nutzungszusicherung können Sie 25 % des On-Demand-Preises sparen, bei einer dreijährigen Zusicherung 52 %.

Spanner

Spanner ist eine cloudnative, frei skalierbare Datenbank mit strikter Konsistenz, die eine Verfügbarkeit von bis zu 99,999 % bietet.

Nutzung überwachen

Im Folgenden finden Sie Empfehlungen zur Verfolgung der Nutzung Ihrer Spanner-Ressourcen:

• Überwachen Sie die Bereitstellung und konfigurieren Sie die Knotenzahl basierend auf CPU-Empfehlungen.
• Legen Sie Benachrichtigungen für Ihre Bereitstellungen fest, um Speicherressourcen zu optimieren. Informationen zur Bestimmung der entsprechenden Konfiguration finden Sie in den empfohlenen Limits pro Knoten.

Ressourcen optimieren

Im Folgenden finden Sie Empfehlungen zur Optimierung Ihre Spanner-Ressourcen:

• Führen Sie in Spanner kleinere Arbeitslasten zu wesentlich geringeren Kosten aus. Stellen Sie dazu Ressourcen mit Verarbeitungseinheiten statt mit Knoten bereit. Ein Spanner-Knoten entspricht 1.000 Verarbeitungseinheiten.
• Verbessern Sie die Leistung der Abfrageausführung mit dem Abfrageoptimierer.
• Erstellen Sie SQL-Anweisungen mit Best Practices zum Erstellen effizienter Ausführungspläne.
• Nutzung und Leistung von Spanner-Bereitstellungen mit dem Autoscaling-Tool verwalten Das Tool überwacht Instanzen, fügt Knoten automatisch hinzu oder entfernt sie und sorgt dafür, dass die Instanzen innerhalb der empfohlenen CPU- und Speicherlimits bleiben.
• Schützen Sie sich vor versehentlichen Lösch- oder Schreibvorgängen mit der PITR (Point-In-Time Recovery, PITR). Datenbanken mit längeren Aufbewahrungszeiten (insbesondere Datenbanken, die Daten häufig überschreiben) verwenden mehr Systemressourcen und benötigen mehr Knoten.
• Prüfen Sie Ihre Sicherungsstrategie und wählen Sie eine der folgenden Optionen:
  • Sichern und wiederherstellen
  • Export und Import

Preise optimieren

Berücksichtigen Sie bei der Entscheidung zum Standort Ihrer Spanner-Knoten die Kostenunterschiede zwischen Google Cloud-Regionen. Beispiel: Ein Knoten, der in der us-central1-Region bereitgestellt wird, kostet pro Stunde deutlich weniger als ein Knoten in der southamerica-east1-Region.

Bigtable

Bigtable ist ein cloudnativer NoSQL-Speicher für große Arbeitslasten mit niedriger Latenz.

Nutzung überwachen

Im Folgenden finden Sie Empfehlungen zur Verfolgung der Nutzung Ihrer Bigtable-Ressourcen:

• Analysieren Sie Nutzungsmesswerte, um Möglichkeiten zur Ressourcenoptimierung zu finden.
• Mit dem Diagnosetool Key Visualizer können Sie Hotspots und Hotkeys im Bigtable-Cluster identifizieren.

Ressourcen optimieren

Im Folgenden finden Sie Empfehlungen zur Optimierung Ihre Bigtable-Ressourcen:

• Um eine CPU- und Laufwerknutzung zu garantieren, die ein Gleichgewicht zwischen Latenz und Speicherkapazität bietet, sollten Sie die Knotenzahl und die Größe Ihres Bigtable-Clusters bewerten und anpassen.
• Um die Leistungskosten zu minimieren, lassen Sie Ihren Bigtable-Cluster programmatisch skalieren, um die Knotenzahl automatisch anzupassen.

• Bestimmen Sie den kostengünstigsten Speichertyp (HDD oder SSD) für Ihren Anwendungsfall anhand folgender Aspekte:

  • HDD-Speicher kostet weniger als SSDs, bietet aber eine geringere Leistung.
  • SSD-Speicher kosten mehr als HDDs, ist aber schneller und bietet eine vorhersehbare Leistung.

  Die Kostenersparnis von HDDs ist im Vergleich zu den Kosten für die Knoten in Ihrem Bigtable-Cluster minimal, außer Sie speichern große Datenmengen. HDD-Speicher ist manchmal angemessen für große Datensätze (>10 TB), die nicht latenzempfindlich sind und auf die nur selten zugegriffen wird.

• Entfernen Sie abgelaufene und veraltete Daten unter Einsatz der automatischen Speicherbereinigung.

• Wenden Sie Best Practices für das Design von Zeilenschlüsseln an, um Hotspots zu vermeiden.

• Entwerfen Sie einen kostengünstigen Sicherungsplan, der Ihrem RPO entspricht.

• Um die Cluster-Nutzung zu verringern und die Knotenzahl zu reduzieren können Sie einen Kapazitäts-Cache für cachefähige Abfragen mit Memorystore hinzufügen.

Weitere Informationen

• Übersicht über die Kostenoptimierung für Bigtable
• Blog: Best Practices für die Leistungs- und Kostenoptimierung in Bigtable

BigQuery

BigQuery ist ein serverloses, höchst skalierbares und kostengünstiges Multi-Cloud Data Warehouse, das speziell für geschäftliche Agilität konzipiert ist

Nutzung überwachen

Im Folgenden finden Sie Empfehlungen zur Verfolgung der Nutzung Ihrer BigQuery-Ressourcen:

• BigQuery-Kosten visualisieren, aufgeschlüsselt nach Projekten und Nutzern. Identifizieren Sie die teuersten Abfragen und optimieren Sie sie.
• Analysieren Sie mit INFORMATION_SCHEMA-Metadatentabellen die Slot-Auslastung über Projekte, Jobs und Reservierungen hinweg.

Ressourcen optimieren

Im Folgenden finden Sie Empfehlungen zur Optimierung Ihrer BigQuery-Ressourcen:

• Richten Sie auf Basis Ihrer Compliance-Strategie Ablaufzeiten für Daten auf Dataset-, Tabellen- oder Partitionsebene ein.
• Begrenzen Sie Abfragekosten durch die Beschränkung der Anzahl der pro Abfrage abgerechneten Byte. Aktivieren Sie die Kostenkontrolle auf Nutzer- und Projektebene, um menschliche Fehler zu vermeiden.
• Abfrage nur der benötigten Daten Vermeiden Sie vollständige Abfragescans. Verwenden Sie die kostenlosen Datenvorschauoptionen, um die Datensemantik zu erforschen und zu verstehen.
• Um die Verarbeitungskosten reduzieren und die Leistung zu verbessern partitionieren und clustern Sie Ihre Tabellen, sofern möglich.
• Filtern Sie Ihre Abfrage so früh wie möglich.
• Vermeiden Sie bei der Verarbeitung von Daten aus mehreren Quellen (Bigtable, Cloud Storage, Google Drive, Cloud SQL usw.) das Duplizieren von Daten mit einem Datenmodell für den föderierten Zugriff und der Datenabfrage direkt aus den Quellen.
• Nutzen Sie die Vorteile der Sicherung von BigQuery, anstatt Daten zu duplizieren. Siehe Szenarien der Notfallwiederherstellung von Daten.

Preise optimieren

Im Folgenden finden Sie Empfehlungen, mit denen Sie die Abrechnungstarife für Ihre BigQuery-Ressourcen reduzieren können:

• Bewerten Sie, wie Sie Daten bearbeiten, und profitieren Sie von niedrigeren langfristigen Speicherpreisen.
• Machen Sie sich mit den Unterschieden zwischen den Pauschal- und On-Demand-Tarifen vertraut und wählen Sie eine Option, die Ihren Anforderungen entspricht.
• Prüfen Sie, ob Sie für Ihre Datenworkflows anstelle von Streaming-Insert-Anweisungen Batchladevorgänge verwenden können. Verwenden Sie Streaming-Insert-Anweisungen, wenn die in BigQuery geladenen Daten sofort verarbeitet werden.
• Verwenden Sie im Cache gespeicherte Abfrageergebnisse, um die Leistung zu erhöhen und die Kosten für das Abrufen von Daten zu senken.

Weitere Informationen

• BigQuery-Kosten kontrollieren
• Best Practices für die BigQuery-Kostenoptimierung
• Prinzipien der Kostenoptimierung verstehen (PDF)

Dataflow

Dataflow ist ein schneller und preiswerter serverloser Dienst für die einheitliche Verarbeitung von Stream- und Batchdaten.

Nutzung überwachen

Im Folgenden finden Sie Empfehlungen zur Verfolgung der Nutzung Ihrer Dataflow-Ressourcen:

• Zur Vorhersage der Kosten von Dataflow-Jobs führen Sie kleine Lasttests aus, ermitteln die optimale Leistung Ihres Jobs und rechnen den Durchsatzfaktor hoch.
• Beobachtbarkeits-Dashboards bieten bessere Einblicke in Durchsatz und CPU-Auslastung.
• Beobachten Sie Leistung, Ausführung und zustandsbezogene Pipelinemesswerte über die Dataflow-Monitoring-Oberfläche.

Ressourcen optimieren

Im Folgenden finden Sie Empfehlungen zur Optimierung Ihrer Dataflow-Ressourcen:

• Erwägen Sie die Nutzung von Dataflow Prime für eine effiziente Verarbeitung von Big Data.
• Um die Kosten für die Batchverarbeitung zu reduzieren, nutzen Sie FlexRS (Flexible Resource Scheduling) für automatisch skalierte Batchpipelines. FlexRS verwendet fortschrittliche Planungs- und Dataflow Shuffle-Techniken und eine Kombination aus vorzeitig beendbaren und regulären VMs, um die Kosten für Batchpipelines zu senken.
• Verbessern Sie die Leistung unter Einsatz des speicherinternen Shuffle-Dienstes anstelle von Persistent Disk und Worker-Knoten.
• Verwenden Sie Streaming Engine, um das Autoscaling zu verbessern und den Ressourcenverbrauch zu reduzieren. Dabei wird die Pipelineausführung aus den Worker-VMs in das Backend des Dataflow-Dienstes verschoben.
• Wenn die Pipeline keinen Zugang auf und aus dem Internet und anderen Google Cloud-Netzwerken benötigt, deaktivieren Sie öffentliche IP-Adressen. Das Deaktivieren des Internetzugriffs senkt die Netzwerkkosten und verbessert die Pipelinesicherheit.
• Befolgen Sie die Best Practices für eine effiziente Pipeline mit Dataflow.

Dataproc

Dataproc ist ein verwalteter Apache Spark- und Apache Hadoop-Dienst für Batchverarbeitung, Abfragen, Streaming und maschinelles Lernen.

Im Folgenden finden Sie Empfehlungen, mit denen Sie die Kosten Ihrer Dataproc-Ressourcen optimieren können:

• Wählen Sie Maschinentypen aus, die für Ihre Arbeitslast geeignet sind.
• Mit Autoscaling-Clustern können Sie die Skalierung automatisch an den Bedarf anpassen und nur die Ressourcen bezahlen, die Sie benötigen.
• Wenn ein Cluster nach Abschluss eines Jobs gelöscht werden kann, können Sie einen sitzungsspezifischen Cluster mit einer Workflowvorlage für verwaltete Cluster bereitstellen.
• Um Gebühren für inaktive Cluster zu vermeiden nutzen Sie das geplante Löschen, mit dem Sie Cluster nach einer bestimmten Zeit der Untätigkeit, zu einer bestimmten Zeit oder nach Ablauf einer bestimmten Zeit löschen können.
• Befolgen Sie die Best Practices für das Erstellen von Clustern mit langer Ausführungszeit auf Dataproc.
• Erwerben Sie für immer aktive Arbeitslasten Rabatte für die zugesicherte Nutzung.

Nächste Schritte

• Optimieren Sie die Kosten für Computing-Dienste, Speicher, Netzwerke und Vorgänge:
  • Kosten optimieren: Computing, Container und serverloses Computing
  • Kosten optimieren: Speicher
  • Kosten optimieren: Netzwerk
  • Kosten optimieren: Cloud-Vorgänge
• Weitere Kategorien des Google Cloud-Architektur-Frameworks entdecken

Kosten optimieren: Netzwerk

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Optimierung der Kosten Ihrer Netzwerkressourcen in Google Cloud.

Die Informationen in diesem Abschnitt richten sich an Architekten und Administratoren, die für die Bereitstellung und Verwaltung von Netzwerken für Arbeitslasten in der Cloud zuständig sind.

Überlegungen zum Design

Ein grundlegender Unterschied zwischen lokalen und Cloud-Netzwerken ist das dynamische, nutzungsbasierte Kostenmodell in der Cloud im Vergleich zu den festen Kosten von Netzwerken in herkömmlichen Rechenzentren.

Bei der Planung von Cloud-Netzwerken ist es wichtig, das Preismodell zu verstehen, das auf der Trafficrichtung basiert:

• Für eingehenden Traffic in Google Cloud fallen keine Gebühren an. Für Ressourcen, die eingehenden Traffic verarbeiten, wie z. B. Cloud Load Balancing, fallen Kosten an.
• Für ausgehenden Traffic, der sowohl Traffic zwischen virtuellen Maschinen (VMs) in Google Cloud als auch Traffic von Google Cloud zum Internet und zu lokalen Hosts umfasst, basieren die Preise auf den folgenden Faktoren:
  • Ob der Traffic eine interne oder externe IP-Adresse verwendet
  • Ob der Traffic Zonen- oder Regionsgrenzen überschreitet
  • Ob der Traffic Google Cloud verlässt
  • Die Entfernung, die der Traffic zurücklegt, bevor er Google Cloud verlässt

Wenn zwei VMs oder Cloud-Ressourcen innerhalb von Google Cloud miteinander kommunizieren, wird der Traffic in jeder Richtung an der Quelle als ausgehende Datenübertragung und als eingehende Datenübertragung am Ziel festgelegt und entsprechend berechnet.

Berücksichtigen Sie beim Entwerfen kosteneffizienter Cloud-Netzwerke die folgenden Faktoren:

• Standortbestimmung
• Netzwerk-Layout
• Verbindungsoptionen
• Netzwerkdienststufen
• Logging

Diese Faktoren werden in den folgenden Abschnitten ausführlicher erläutert.

Standortbestimmung

Die Netzwerkkosten können je nach Google Cloud-Region, in der Ihre Ressourcen bereitgestellt werden, variieren. Zum Analysieren der Netzwerkbandbreite zwischen Regionen können Sie VPC-Flusslogs und das Network Intelligence Center verwenden. Bei Traffic, der zwischen Google Cloud-Regionen fließt, können die Kosten je nach Standort der Regionen variieren, auch wenn der Traffic nicht über das Internet geleitet wird.

Berücksichtigen Sie neben der Google Cloud-Region die Zonen, in denen Ihre Ressourcen bereitgestellt werden. Je nach Verfügbarkeitsanforderungen können Sie Ihre Anwendungen unter Umständen so gestalten, dass sie innerhalb einer Zone kostenlos über interne IP-Adressen kommunizieren. Wenn Sie eine Architektur mit einer einzelnen Zone in Betracht ziehen, sollten Sie mögliche Einsparungen bei den Netzwerkkosten berücksichtigen, die sich auf die Verfügbarkeit auswirken.

Netzwerk-Layout

Analysieren Sie Ihr Netzwerklayout, den Traffic zwischen Ihren Anwendungen und Nutzern sowie die von jeder Anwendung oder jedem Nutzer verbrauchte Bandbreite. Das Netzwerktopologie-Tool bietet einen umfassenden Einblick in Ihre globale Google Cloud-Bereitstellung und ihre Interaktion mit dem öffentlichen Internet, einschließlich einer organisationsweiten Ansicht der Topologie. und zugehörige Messwerte zur Netzwerkleistung. Sie können ineffiziente Bereitstellungen identifizieren und erforderliche Maßnahmen zur Optimierung der regionalen und interkontinentalen Datenübertragungskosten ergreifen.

Verbindungsoptionen

Wenn Sie große Datenmengen (TB oder PBs) häufig aus lokalen Umgebungen zu Google Cloud übertragen müssen, sollten Sie die Verwendung vonDedicated Interconnect oder Partner Interconnect in Erwägung ziehen. Eine dedizierte Verbindung kann im Vergleich zu den Kosten, die mit der Nutzung des öffentlichen Internets oder eines VPN verbunden sind, günstiger sein.

Verwenden Sie nach Möglichkeit den privaten Google-Zugriff, um die Kosten zu senken und Ihren Sicherheitsstatus zu verbessern.

Netzwerkdienststufen

Die Premium-Netzwerkinfrastruktur von Google (Premium-Stufe) wird standardmäßig für alle Dienste verwendet. Für Ressourcen, die nicht die hohe Leistung und niedrige Latenz der Premium-Stufe benötigen, können Sie die Standardstufe auswählen. Diese kostet weniger.

Berücksichtigen Sie bei der Auswahl einer Dienststufe die Unterschiede zwischen den Stufen und die Einschränkungen der Standardstufe. Passen Sie das Netzwerk an die Anforderungen Ihrer Anwendung an und senken Sie möglicherweise die Netzwerkkosten für Dienste, die mehr Latenzzeiten vertragen und keine SLAs erfordern.

Logging

Mit VPC-Flusslogs, Firewallregel-Logging und Cloud NAT-Logging können Sie Netzwerklogs analysieren und Möglichkeiten zur Kostenoptimierung erkennen.

Für VPC-Flusslogs und Cloud Load Balancing können Sie auch Folgendes aktivieren:Stichprobenerfassung Dadurch kann die Anzahl der geschriebenen Logs in der Datenbank reduziert werden. Sie können die Abtastrate von 1,0 (alle Logeinträge werden beibehalten) bis 0,0 (keine Logs bleiben) ändern. Für die Fehlerbehebung oder benutzerdefinierte Anwendungsfälle können Sie wählen, ob Sie Telemetriedaten für ein bestimmtes VPC-Netzwerk oder Subnetz immer erfassen oder eine bestimmte VM-Instanz oder virtuelle Schnittstelle überwachen.

Designempfehlungen

Zur Optimierung des Netzwerktraffics empfehlen wir Folgendes:

• Entwerfen Sie Ihre Lösungen, um Anwendungen näher an Ihre Nutzer zu bringen. Verwenden Sie Cloud CDN, um das Trafficvolumen und die Latenz zu reduzieren und die günstigeren Preise von CDN zu nutzen, um Inhalte bereitzustellen, auf die viele Nutzer häufig zugreifen werden.
• Synchronisieren Sie Daten nicht global über Regionen hinweg, die vom Endnutzer weit entfernt sind oder hohe Netzwerkkosten verursachen können. Wenn eine Anwendung nur innerhalb einer Region verwendet wird, sollten Sie die regionsübergreifende Datenverarbeitung vermeiden.
• Achten Sie darauf, dass die Kommunikation zwischen VMs innerhalb einer Zone über ihre internen IP-Adressen und nicht extern weitergeleitet wird.
• Reduzieren Sie die Datenübertragungskosten und die Clientlatenz durch Komprimieren der Datenausgabe.
• Analysieren Sie Ausgabenmuster und identifizieren Sie Möglichkeiten zur Kostenkontrolle, indem Sie mithilfe von VPC-Flusslogs den eingehenden und ausgehenden Traffic für kritische Projekte beobachten.
• Berücksichtigen Sie beim Entwerfen Ihrer Netzwerke in der Cloud den Kompromiss zwischen der hohen Verfügbarkeit eines verteilten Netzwerks und den Kosteneinsparungen, die durch die Zentralisierung des Traffics innerhalb einer einzelnen Zone oder Region entstehen.

So optimieren Sie den Preis für Netzwerkdienste:

• Wenn der Serverstandort keine Einschränkung ist, bewerten Sie die Kosten in verschiedenen Regionen und wählen Sie die kostengünstigste Region aus. Bei allgemeinem ausgehenden Traffic, z. B. bei von einer Gruppe von Webservern bereitgestellten Inhalten, können die Preise je nach Region, in der die Server bereitgestellt werden, variieren.
• Verwenden Sie eine direkte Verbindung zwischen dem lokalen Netzwerk und den Google Cloud-Netzwerken, um die Kosten für das häufige Verschieben großer Datenmengen in die Cloud zu reduzieren. Prüfen Sie den Einsatz von Dedicated Interconnect oder Partner Interconnect.
• Wählen Sie für jede Umgebung eine geeignete Dienststufe aus, d. h. eine Standardstufe für Entwicklungs- und Testumgebungen und eine Premiumstufe für die Produktion.

Nächste Schritte

• Informationen zu Netzwerkpreisen prüfen
• Best Practices für die Optimierung von Netzwerkkosten
• Kosten für Computing-Dienste, Speicher, Datenbanken und Vorgänge optimieren:
  • Kosten optimieren: Computing, Container und serverloses Computing
  • Kosten optimieren: Speicher
  • Kosten optimieren: Datenbanken und intelligente Analysen
  • Kosten optimieren: Cloud-Vorgänge
• Weitere Kategorien des Google Cloud-Architektur-Frameworks entdecken

Kosten optimieren: Cloud-Vorgänge

Dieses Dokument des Google Cloud-Architektur-Frameworks enthält Empfehlungen zur Optimierung der Kosten für das Monitoring und die Verwaltung Ihrer Ressourcen in Google Cloud.

Die Anleitung in diesem Abschnitt richtet sich an Cloud-Nutzer, die innerhalb ihrer Organisation für die Überwachung und Kontrolle der Nutzung und Kosten der Ressourcen in der Cloud verantwortlich sind.

Die Operations-Suite von Google Cloud ist eine Sammlung verwalteter Dienste, mit denen Sie die Leistung Ihrer Arbeitslasten in Google Cloud überwachen, debuggen und verbessern können. Zu diesen Diensten gehören Cloud Monitoring, Cloud Logging, Error Reporting, Cloud Trace und Cloud Profiler. Einer der Vorteile von verwalteten Diensten in Google Cloud ist, dass die Dienste nutzungsbasiert sind. Sie zahlen nur für die tatsächliche Nutzung und nach der Datenmenge. Dafür haben Sie kostenlose monatliche Datennutzungskontingente und unbegrenzten Zugriff auf Google Cloud-Messwerte und -Audit-Logs.

Cloud Logging

Im Folgenden finden Sie Empfehlungen, mit denen Sie die Kosten Ihrer Logging-Vorgänge optimieren können:

• Filtern Sie Abrechnungsberichte, um Logging-Kosten anzuzeigen
• Reduzieren Sie das Volumen der aufgenommenen und gespeicherten Logs, indem Sie unnötige Logeinträge ausschließen oder filtern.
• Prüfen Sie, ob die Ausschlussfilter geeignet sind. Beobachten Sie dazu die Messwerte billing/bytes_ingested und billing/monthly_bytes_ingested in der Google Cloud Console.
• Übertragen und exportieren Sie Logs auf kostengünstigere Speicher
• Reduzieren Sie beim Streaming von Logs von Drittanbieteranwendungen die Logvolumen, indem Sie den Logging-Agent nur auf Produktionsinstanzen verwenden oder so konfigurieren, dass weniger Daten gesendet werden.

Cloud Monitoring

Im Folgenden finden Sie Empfehlungen, mit denen Sie die Kosten Ihrer Monitoring-Vorgänge optimieren können:

• Optimieren Sie Messwerte und Labelverwendung, indem Sie die Anzahl der Labels begrenzen. Vermeiden Sie Labels mit hoher Kardinalität. Wenn Sie beispielsweise eine IP-Adresse als Label verwenden, hat jede IP-Adresse eine Labelreihe mit einem Element, was zu vielen Labels führt, wenn Sie viele VMs haben.
• Reduzieren Sie die Anzahl detaillierter Messwerte für Anwendungen, die diese Messwerte nicht benötigen, oder entfernen Sie den Monitoring-Agent, insbesondere bei irrelevanten Umgebungen.
• Minimieren Sie das Aufnahmevolumen, indem Sie die Anzahl der benutzerdefinierten Messwerte reduzieren, die von Ihrer Anwendung gesendet werden.

Cloud Trace

Im Folgenden finden Sie Empfehlungen, mit denen Sie die Kosten Ihrer Trace-Vorgänge optimieren können:

• Wenn Sie Trace als Exportziel für OpenCensus-Traces verwenden, reduzieren Sie die Menge der aufgenommenen Traces mithilfe des Stichprobenfeatures in OpenCensus.
• Beschränken Sie die Nutzung von Trace und kontrollieren Sie die Kosten mithilfe von Kontingenten. Span-Kontingente werden auf der API-spezifischen Kontingentenseite in der Google Cloud Console durchgesetzt.

Nächste Schritte

• Kosten für die Operations-Suite von Google Cloud optimieren
• Video: Manage costs for Google Cloud's operations suite
• Kosten für Computing-Dienste, Speicher, Datenbanken und Netzwerke optimieren:
  • Kosten optimieren: Computing, Container und serverloses Computing
  • Kosten optimieren: Speicher
  • Kosten optimieren: Datenbanken und intelligente Analysen
  • Kosten optimieren: Netzwerk
• Weitere Kategorien des Google Cloud-Architektur-Frameworks entdecken

Google Cloud-Architektur-Framework: Leistungsoptimierung

Diese Kategorie im Google Cloud Architecture Framework beschreibt die Leistungsoptimierung und die Best Practices zur Optimierung der Leistung von Arbeitslasten in Google Cloud.

Die Informationen in diesem Dokument richten sich an Architekten, Entwickler und Administratoren, die Arbeitslasten in Google Cloud planen, entwerfen, bereitstellen und verwalten.

Die Optimierung der Leistung von Arbeitslasten in der Cloud kann Ihrem Unternehmen helfen, effizient zu arbeiten, die Kundenzufriedenheit zu verbessern, den Umsatz zu steigern und die Kosten zu senken. Beispiel: Wenn die Backend-Verarbeitungszeit einer Anwendung abnimmt, genießen Nutzer schnellere Antwortzeiten, was zu einer höheren Nutzerbindung und mehr Umsatz führen kann.

Es kann zu einem Kompromiss zwischen Leistung und Kosten kommen. Manchmal kann die Leistungsoptimierung jedoch helfen, die Kosten zu senken. Beispiel: Autoscaling bietet eine vorhersagbare Leistung, wenn die Last zunimmt, da die Ressourcen nicht überlastet werden. Außerdem können Sie in Zeiten geringer Last mit Autoscaling nicht verwendete Ressourcen entfernen und so die Kosten senken.

In dieser Kategorie des Architektur-Frameworks lernen Sie Folgendes:

• Implementieren Sie den Prozess der Leistungsoptimierung.
• Leistung überwachen und analysieren.
• Computing-Leistung optimieren.
• Speicherleistung optimieren.
• Netzwerkleistung optimieren.
• Leistung von Datenbanken optimieren.
• Analyseleistung optimieren.

Leistungsoptimierung

Dieses Dokument im Google Cloud-Architektur-Framework bietet einen Überblick über die Leistungsoptimierung.

Die Leistungsoptimierung ist ein kontinuierlicher Prozess, keine einmalige Aktivität. Das folgende Diagramm zeigt die Phasen des Leistungsoptimierungsprozesses:

Im Folgenden finden Sie eine Übersicht über die Phasen des Leistungsoptimierungsprozesses:

Leistungsanforderungen definieren

Bestimmen Sie vor dem Entwerfen und Entwickeln der Anwendungen, die Sie bereitstellen oder in die Cloud migrieren möchten, die Leistungsanforderungen. Definieren Sie die Anforderungen für jede Schicht des Anwendungspakets so detailliert wie möglich: Frontend-Load-Balancing, Web- oder Anwendungsserver, Datenbank und Speicher. Legen Sie beispielsweise für die Speicherebene des Stacks den Durchsatz und die E/A-Vorgänge pro Sekunde (IOPS) fest, die Ihre Anwendungen benötigen.

Anwendungen entwerfen und bereitstellen

Gestalten Sie Ihre Anwendungen mit elastischen und skalierbaren Designmustern, mit denen Sie die Leistungsanforderungen erfüllen können. Beachten Sie die folgenden Richtlinien für das Entwerfen von Anwendungen, die elastisch und skalierbar sind:

• Arbeitslasten für eine optimale Inhaltsplatzierung planen.
• Lese- und Schreibzugriff isolieren.
• Statischen und dynamischen Traffic isolieren.
• Inhalts-Caching implementieren. Daten-Caches für interne Ebenen verwenden.
• Verwenden Sie verwaltete Dienste und serverlose Architekturen.

Google Cloud bietet Open-Source-Tools, mit denen Sie die Leistung von Google Cloud-Diensten mit anderen Cloud-Plattformen vergleichen können.

Leistung überwachen und analysieren

Nachdem Sie Ihre Anwendungen bereitgestellt haben, können Sie die Leistung mithilfe von Logs und Benachrichtigungen kontinuierlich überwachen, die Daten analysieren und Leistungsprobleme erkennen. Wenn Ihre Anwendungen wachsen und weiterentwickelt werden, müssen Sie Ihre Leistungsanforderungen neu bewerten. Möglicherweise müssen Sie einige Teile der Anwendungen neu gestalten, um die Leistung zu erhalten oder zu verbessern.

Leistung optimieren

Konfigurieren Sie die Cloud-Ressourcen auf der Grundlage der Leistung Ihrer Anwendungen und geänderter Anforderungen so, dass sie den aktuellen Leistungsanforderungen entsprechen. Beispielsweise können Sie die Größe der Ressourcen anpassen oder Autoscaling einrichten. Beim Konfigurieren der Ressourcen sollten Sie Möglichkeiten bewerten, wie Sie kürzlich veröffentlichte Google Cloud-Features und -Dienste nutzen können, um die Leistung weiter zu optimieren.

Die Leistungsoptimierung endet nicht an diesem Punkt. Fahren Sie mit dem Monitoring der Leistung fort, bewerten Sie bei Bedarf die Anforderungen neu und passen Sie die Cloud-Ressourcen an, um die Leistung aufrechtzuerhalten und zu verbessern.

Nächste Schritte

• Leistung überwachen und analysieren.
• Computing-Leistung optimieren.
• Speicherleistung optimieren.
• Netzwerkleistung optimieren.
• Leistung von Datenbanken optimieren.
• Analyseleistung optimieren.

Leistung überwachen und analysieren

In diesem Dokument im Google Cloud-Architektur-Framework werden die Dienste in der Operations-Suite von Google Cloud beschrieben, mit denen Sie die Leistung Ihrer Arbeitslasten aufzeichnen, überwachen und analysieren können.

Leistungsmesswerte überwachen

Mit Cloud Monitoring können Sie Trends in Leistungsmesswerten analysieren, die Auswirkungen von Tests analysieren, Benachrichtigungen für kritische Messwerte definieren und rückblickende Analysen durchführen.

Kritische Daten und Ereignisse protokollieren

Cloud Logging ist ein integrierter Logging-Dienst, mit dem Sie Benachrichtigungen für Logdaten und -ereignisse speichern, analysieren, überwachen und festlegen können. Cloud Logging kann Logs von den Diensten von Google Cloud und anderen Cloud-Anbietern erfassen.

Codeleistung analysieren

Code, der schlecht funktioniert, kann die Latenz Ihrer Anwendungen und die Kosten für deren Ausführung erhöhen. Mit Cloud Profiler können Sie Leistungsprobleme erkennen und beheben. Analysieren Sie dazu kontinuierlich die Leistung von CPU-intensiven oder speicherintensiven Funktionen, die eine Anwendung verwendet.

Latenzdaten erfassen

In komplexen Anwendungspaketen und auf Mikrodiensten basierenden Architekturen kann die Bewertung der Latenz in der Kommunikation zwischen Diensten und das Identifizieren von Leistungsengpässen schwierig sein. Die Tools Cloud Trace und OpenTelemetry unterstützen Sie beim Erfassen von Latenzdaten aus Ihren Bereitstellungen in großem Maßstab. Mithilfe dieser Tools können Sie die Latenzdaten auch effizient analysieren.

Netzwerkleistung überwachen

Das Dashboards zur Leistungsüberwachung des Network Intelligence Center bietet eine umfassende Ansicht der Leistungsmesswerte für das Google-Netzwerk und die Ressourcen in Ihrem Projekt. Mithilfe dieser Messwerte können Sie die Ursache für netzwerkbezogene Leistungsprobleme ermitteln. Sie können beispielsweise feststellen, ob ein Leistungsproblem durch ein Problem in Ihrem Projekt oder im Google-Netzwerk verursacht wurde.

Nächste Schritte

• Best Practices für das Monitoring Ihrer Cloud-Ressourcen
• Sehen Sie sich die Best Practices zur Optimierung der Leistung Ihrer Google Cloud-Ressourcen an:
  • Computing-Leistung optimieren.
  • Speicherleistung optimieren.
  • Netzwerkleistung optimieren.
  • Leistung von Datenbanken optimieren.
  • Analyseleistung optimieren.

Computing-Leistung optimieren

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Optimierung der Leistung Ihrer Compute Engine-, Google Kubernetes Engine- und serverlosen Ressourcen.

Compute Engine

Dieser Abschnitt enthält Anleitungen zur Leistungsoptimierung Ihrer Compute Engine-Ressourcen.

Ressourcen automatisch skalieren

Mit verwalteten Instanzgruppen (Managed Instance Groups, MIGs) können Sie zustandslose Anwendungen effizient skalieren, die auf Compute Engine-VMs bereitgestellt werden. Mit Autoscaling können Ihre Anwendungen weiterhin eine vorhersagbare Leistung liefern, wenn die Last zunimmt. In einer MIG wird eine Gruppe von Compute Engine-VMs basierend auf einer von Ihnen definierten Vorlage gestartet. In der Vorlage konfigurieren Sie eine Autoscaling-Richtlinie, die ein oder mehrere Signale angibt, mit denen das Autoscaling die Gruppe skaliert. Die Autoscaling-Signale können zeitplanbasiert wie Startzeit oder Dauer oder basierend auf Zielmesswerten wie der durchschnittlichen CPU-Auslastung sein. Weitere Informationen finden Sie unter Autoscaling von Instanzgruppen.

SMT deaktivieren

Jede virtuelle CPU (vCPU), die Sie einer Compute Engine-VM zuweisen, wird als einzelner Hardware-Multithread implementiert. Standardmäßig teilen sich zwei vCPUs einen physischen CPU-Kern. Diese Architektur wird als gleichzeitiges Multi-Threading (SMT) bezeichnet.

Bei Arbeitslasten, die sehr parallel sind oder Gleitkommaberechnungen ausführen (z. B. Transcodierung, Monte-Carlo-Simulationen, genetische Sequenzanalyse und Finanzrisikomodellierung), kann die Leistung durch Deaktivieren von SMT verbessert werden. Weitere Informationen finden Sie unter Anzahl der Threads pro Kern festlegen.

GPUs verwenden

Für Arbeitslasten wie maschinelles Lernen und Visualisierung können Sie Ihren VMs GPUs (Graphical Processing Units) hinzufügen. NVIDIA-GPUs werden in Compute Engine im Passthrough-Modus bereitgestellt, sodass Ihre VMs die GPUs und den zugehörigen Arbeitsspeicher direkt steuern können. Für grafikintensive Arbeitslasten wie 3D-Visualisierung können Sie virtuelle NVIDIA RTX-Workstations verwenden. Nach dem Bereitstellen der Arbeitslasten müssen Sie die GPU-Nutzung überwachen und die Optionen zur Optimierung der GPU-Leistung prüfen.

Computing-optimierte Maschinentypen verwenden

Arbeitslasten wie Gaming, Medientranscodierung und Hochleistungs-Computing (HPC) erfordern eine konsistent hohe Leistung pro CPU-Kern. Google empfiehlt für die VMs, auf denen solche Arbeitslasten ausgeführt werden, computing-optimierte Maschinentypen zu verwenden. Computing-optimierte VMs basieren auf einer Architektur, die für eine optimale und zuverlässige Leistung Funktionen wie uneinheitlichen Speicherzugriff (NUMA) verwendet.

Für eng gekoppelte HPC-Arbeitslasten gelten spezielle Anforderungen, um die Spitzeneffizienz zu erreichen. Weitere Informationen erhalten Sie in dieser Dokumentation:

• Parallele Dateisysteme für HPC-Arbeitslasten
• Architektur: Lustre-Dateisystem in Google Cloud mit DDN EXAScaler

Geeigneten Speicher auswählen

Google Cloud bietet eine Vielzahl von Speicheroptionen für Compute Engine-VMs: nichtflüchtige Speicher, lokale SSD-Laufwerke (Solid-State Drive), Filestore und Cloud Storage. Designempfehlungen und Best Practices zur Optimierung der Leistung jeder dieser Speicheroptionen finden Sie unter Speicherleistung optimieren.

Google Kubernetes Engine

Dieser Abschnitt enthält Anleitungen zum Optimieren der Leistung Ihrer Google Kubernetes Engine-Ressourcen (GKE).

Ressourcen automatisch skalieren

Mit dem Feature Cluster Autoscaler können Sie die Größe der Knotenpools in einem GKE-Cluster automatisch an die aktuelle Auslastung anpassen. Mit Autoscaling können Ihre Anwendungen weiterhin eine vorhersagbare Leistung liefern, wenn die Last zunimmt. Cluster Autoscaler passt die Größe von Knotenpools automatisch an die Ressourcenanforderungen (anstelle der tatsächlichen Ressourcennutzung) der Pods an, die auf den Knoten ausgeführt werden. Wenn Sie Autoscaling verwenden, können Sie Kompromisse zwischen Leistung und Kosten eingehen. Lesen Sie die Best Practices zur effizienten Konfiguration von Cluster-Autoscaling.

Hinweis: Bei Autopilot-Clustern müssen Sie sich keine Gedanken über die Bereitstellung von Knoten oder die Verwaltung von Knotenpools machen. Die Knotenpools werden automatisch gemäß den Anforderungen Ihrer Arbeitslasten bereitgestellt und skaliert.

C2D-VMs verwenden

Sie können die Leistung rechenintensiver Containerarbeitslasten mithilfe von C2D-Maschinentypen verbessern. Sie können C2D-Knoten zu Ihren GKE-Clustern hinzufügen, wenn Sie einen C2D-Maschinentyp in Ihren Knotenpools auswählen.

SMT deaktivieren

Das gleichzeitige Multi-Threading (SMT) kann den Anwendungsdurchsatz für allgemeine Computing-Aufgaben und für Arbeitslasten, die hohe E/A-Vorgänge benötigen, erheblich erhöhen. Bei Arbeitslasten, bei denen beide virtuellen Kerne rechengebunden sind, kann SMT zu einer inkonsistenten Leistung führen. Wenn Sie eine bessere und vorhersagbare Leistung erzielen möchten, können Sie die SMT für Ihre GKE-Knoten deaktivieren. Dazu setzen Sie die Anzahl der vCPUs pro Kern auf 1.

GPUs verwenden

Bei rechenintensiven Arbeitslasten wie Bilderkennung und Videotranscodierung können Sie die Leistung beschleunigen. Erstellen Sie dazu Knotenpools, die GPUs verwenden. Weitere Informationen finden Sie unter GPUs ausführen.

Containernatives Load-Balancing verwenden

Containernatives Load-Balancing ermöglicht es Load-Balancern, Traffic direkt und gleichmäßig auf Pods zu verteilen. Dieser Ansatz bietet eine bessere Netzwerkleistung und eine bessere Sichtbarkeit der Netzwerklatenz zwischen dem Load-Balancer und den Pods. Aufgrund dieser Vorteile ist das containernative Load-Balancing die empfohlene Lösung für das Load-Balancing über Ingress.

Kompakte Platzierungsrichtlinie definieren

Für eng gekoppelte Batcharbeitslasten ist eine niedrige Netzwerklatenz zwischen den Knoten im GKE-Knotenpool erforderlich. Sie können solche Arbeitslasten in Einzelzonen-Knotenpools bereitstellen und dafür sorgen, dass die Knoten physisch nahe beieinander liegen. Definieren Sie dazu eine kompakte Platzierungsrichtlinie. Weitere Informationen finden Sie unter Kompakte Platzierung für GKE-Knoten definieren.

Serverlose Computing-Dienste

Dieser Abschnitt enthält Anleitungen zum Optimieren der Leistung Ihrer serverlosen Computing-Dienste in Google Cloud: Cloud Run und Cloud Functions. Diese Dienste bieten Autoscaling-Funktionen, bei denen die zugrunde liegende Infrastruktur automatisch skaliert wird. Mit diesen serverlosen Diensten können Sie den Aufwand für die Skalierung Ihrer Mikrodienste und Funktionen reduzieren und sich auf die Optimierung der Leistung auf Anwendungsebene konzentrieren.

Weitere Informationen erhalten Sie in dieser Dokumentation:

• Leistung in Cloud Run-Diensten optimieren
• Java-Anwendungen für Cloud Run optimieren
• Leistung in Cloud Functions optimieren

Nächste Schritte

Hier finden Sie Best Practices zur Optimierung der Leistung Ihrer Speicher-, Netzwerk-, Datenbank- und Analyseressourcen:

• Speicherleistung optimieren.
• Netzwerkleistung optimieren.
• Leistung von Datenbanken optimieren.
• Analyseleistung optimieren.

Speicherleistung optimieren

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Optimierung der Leistung Ihrer Speicherressourcen in Google Cloud.

Cloud Storage

Dieser Abschnitt enthält Best Practices zur Optimierung der Leistung Ihrer Cloud Storage-Vorgänge.

Bucket-Leistung bewerten

Prüfen Sie die Leistung Ihrer Cloud Storage-Buckets mit dem Befehl gsutil perfdiag. Dieser Befehl testet die Leistung des angegebenen Buckets, wenn eine Reihe von Lese- und Schreibanfragen mit Dateien verschiedener Größen gesendet wird. Sie können den Test optimieren, um ihn an das Nutzungsmuster Ihrer Anwendungen anzupassen. Verwenden Sie den Diagnosebericht, den der Befehl generiert, um die Leistungserwartungen festzulegen und potenzielle Engpässe zu identifizieren.

Häufig aufgerufene Objekte im Cache speichern

Um die Leselatenz für öffentlich zugängliche Objekte zu verbessern, können Sie diese Objekte so konfigurieren, dass sie im Cache gespeichert werden. Obwohl das Caching die Leistung verbessern kann, können veraltete Inhalte bereitgestellt werden, wenn ein Cache die alte Version eines Objekts hat.

Anfragen effizient skalieren

Mit zunehmender Anfragerate für einen Bucket erhöht Cloud Storage automatisch die E/A-Kapazität für den Bucket. Dazu wird die Anfragelast auf mehrere Server verteilt. Befolgen Sie die Best Practices zum Erhöhen der Anfrageraten und zur gleichmäßigen Verteilung der Last, um eine optimale Leistung beim Skalieren von Anfragen zu erzielen.

Multithreading und Multiprocessing aktivieren

Wenn Sie gsutil zum Hochladen zahlreicher kleiner Dateien verwenden, können Sie die Leistung des Vorgangs mithilfe der Option -m verbessern. Diese Option bewirkt, dass die Uploadanfrage als verarbeiteter, paralleler (d. h. Multithreading und Multiprocessing) Vorgang implementiert wird. Verwenden Sie diese Option nur, wenn Sie Vorgänge über eine schnelle Netzwerkverbindung ausführen. Weitere Informationen finden Sie in der Dokumentation zur Option -m unter Globale Befehlszeilenoptionen.

Große Dateien als zusammengesetzte Daten hochladen

Zum Hochladen großer Dateien können Sie eine Strategie namens parallele zusammengesetzte Uploads verwenden. Bei dieser Strategie wird die große Datei in Blöcke unterteilt, die parallel hochgeladen und dann in der Cloud neu zusammengesetzt werden. Parallele zusammengesetzte Uploads können schneller sein als reguläre Uploadvorgänge, wenn Netzwerkbandbreite und Laufwerksgeschwindigkeit keine einschränkenden Faktoren darstellen. Diese Strategie hat jedoch einige Einschränkungen und Auswirkungen auf die Kosten. Weitere Informationen finden Sie unter Parallele zusammengesetzte Uploads.

Nichtflüchtige Speicher und lokale SSDs

Dieser Abschnitt enthält Best Practices zur Optimierung der Leistung Ihrer angehängten nichtflüchtigen Speicher und lokalen SSDs, die an Compute Engine-VMs angehängt sind.

Die Leistung von nichtflüchtigen Speichern und lokalen SSDs hängt vom Laufwerkstyp und der Größe, dem VM-Maschinentyp und der Anzahl der vCPUs ab. Verwenden Sie die folgenden Richtlinien, um die Leistung Ihrer nichtflüchtigen Speicher und lokalen SSDs zu verwalten:

• Wenn Sie Blockspeicher für Ihre VMs bereitstellen, wählen Sie Laufwerkstypen und Laufwerksgrößen aus, die für Ihre Arbeitslast geeignet sind. Weitere Informationen finden Sie unter Laufwerke so konfigurieren, dass sie die Leistungsanforderungen erfüllen.
• Benchmarking der Blockspeicherleistung Weitere Informationen erhalten Sie in dieser Dokumentation:
  • Benchmarking der Leistung nichtflüchtiger Speicher
  • Benchmarking der lokalen SSD-Leistung
• Optimieren Sie die Leistung Ihrer nichtflüchtigen Speicher und lokalen SSDs. Weitere Informationen erhalten Sie in dieser Dokumentation:
  • Leistung des nichtflüchtigen Speichers optimieren
  • Leistung lokaler SSD optimieren

Filestore

Dieser Abschnitt enthält Best Practices zur Optimierung der Leistung Ihrer Filestore-Instanzen. Sie können Filestore verwenden, um vollständig verwaltete NFS-Dateiserver (Network File System) für Compute Engine-VMs und GKE-Cluster bereitzustellen.

• Wählen Sie beim Bereitstellen einer Filestore-Instanz eine Dienststufe aus, die die Leistungs- und Kapazitätsanforderungen Ihrer Arbeitslast erfüllt.
• Verwenden Sie für Client-VMs, auf denen Cache-abhängige Arbeitslasten ausgeführt werden, einen Maschinentyp, mit dem die Netzwerkleistung der Filestore-Instanz optimiert werden kann. Weitere Informationen finden Sie unter Empfohlener Client-Maschinentyp.
• Zur Optimierung der Leistung von Filestore-Instanzen für Client-VMs, auf denen Linux ausgeführt wird, empfiehlt Google bestimmte NFS-Bereitstellungseinstellungen. Weitere Informationen finden Sie unter Linux-Client-Bereitstellungsoptionen.
• Stellen Sie Ihre Filestore-Instanzen in Regionen und Zonen bereit, die sich in der Nähe der geplanten Verwendung befinden, um die Netzwerklatenz zu minimieren.
• Überwachen Sie die Leistung Ihrer Filestore-Instanzen und richten Sie mit Cloud Monitoring Benachrichtigungen ein.

Nächste Schritte

Best Practices zur Optimierung der Leistung Ihrer Computing-, Netzwerk-, Datenbank- und Analyseressourcen:

• Computing-Leistung optimieren.
• Netzwerkleistung optimieren.
• Leistung von Datenbanken optimieren.
• Analyseleistung optimieren.

Netzwerk- und API-Leistung optimieren

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Optimierung der Leistung Ihrer Netzwerkressourcen und APIs in Google Cloud.

Netzwerkdienststufen

Mit Netzwerkdienststufen können Sie die Netzwerkkosten und Leistung Ihrer Arbeitslasten optimieren. Sie können zwischen den folgenden Stufen wählen:

• Die Premium-Stufe verwendet das äußerst zuverlässige globale Backbone von Google, um einen minimalen Paketverlust und eine minimale Latenz zu erreichen. Der Traffic erreicht und verlässt das Google-Netzwerk an einem globalen Edge-Point of Presence (PoP), der sich in der Nähe Ihres Endnutzers befindet. Wir empfehlen die Premiumstufe als Standardstufe, um eine optimale Leistung zu erzielen. Die Premium-Stufe unterstützt sowohl regionale als auch globale externe IP-Adressen für VMs und Load-Balancer.
• Die Standardstufe ist nur für Ressourcen verfügbar, die regionale externe IP-Adressen verwenden. Der Traffic betritt und verlässt das Google-Netzwerk an einem Edge-PoP, der dem Google Cloud-Standort am nächsten ist, an dem Ihre Arbeitslast ausgeführt wird. Die Preise für die Standardstufe sind niedriger als die Premiumstufe. Die Standardstufe eignet sich für Traffic, der nicht empfindlich auf Paketverluste reagiert und keine niedrigen Latenzanforderungen hat.

Sie können die Netzwerklatenz für die Standard- und Premiumstufe für jede Cloudregion im Dashboard zur Leistungsüberwachung von Network Intelligence Center Performance aufrufen.

Jumbo Frames

VPC-Netzwerke (Virtual Private Cloud) haben eine standardmäßige maximale Übertragungseinheit (MTU) von 1.460 Byte. Sie können die VPC-Netzwerke jedoch so konfigurieren, dass sie eine MTU von bis zu 8896 (Jumbo Frames) unterstützen.

Bei einer höheren MTU benötigt das Netzwerk weniger Pakete, um die gleiche Datenmenge zu senden, wodurch die von TCP/IP-Headern verwendete Bandbreite reduziert wird. Dies führt zu einer höheren effektiven Bandbreite für das Netzwerk.

Weitere Informationen zur Intra-VPC-MTU und zur maximalen MTU anderer Verbindungen finden Sie in der VPC-Dokumentation auf der Seite Maximale Übertragungseinheit.

VM-Leistung

Compute Engine-VMs haben eine maximale Bandbreite für ausgehenden Traffic, die teilweise vom Maschinentyp abhängt. Bei der Auswahl eines geeigneten Maschinentyps muss berücksichtigt werden, wie viel Traffic die VM generieren soll.

Die Seite Netzwerkbandbreite enthält eine Diskussion und eine Tabelle der Netzwerkbandbreiten für Compute Engine-Maschinentypen.

Wenn Ihre Bandbreitenanforderungen für VMs sehr hoch sind, sollten Sie VMs berücksichtigen, die Tier_1-Netzwerke unterstützen.

Cloud Load Balancing

Dieser Abschnitt enthält Best Practices zur Optimierung der Leistung Ihrer Cloud Load Balancing-Instanzen.

Anwendungen in der Nähe Ihrer Nutzer bereitstellen

Stellen Sie die Anwendungs-Back-Ends in der Nähe des Standorts bereit, an dem der Nutzertraffic beim Load-Balancer ankommen soll. Je näher Ihre Nutzer oder Clientanwendungen an Ihren Arbeitslastservern liegen, desto geringer ist die Netzwerklatenz zwischen den Nutzern und der Arbeitslast. Um die Latenz für Clients in verschiedenen Teilen der Welt zu minimieren, müssen Sie die Back-Ends möglicherweise in mehreren Regionen bereitstellen. Weitere Informationen finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.

Geeigneten Load-Balancer-Typ auswählen

Der für Ihre Anwendung ausgewählte Typ des Load-Balancers kann die Latenz bestimmen, die bei Ihren Nutzern auftritt. Informationen zum Messen und Optimieren der Anwendungslatenz für verschiedene Load-Balancer-Typen finden Sie unter Anwendungslatenz durch Load-Balancing optimieren.

Caching aktivieren

Aktivieren Sie Caching und Cloud CDN als Teil Ihrer standardmäßigen externen HTTP-Load-Balancer-Konfiguration, um die Inhaltsbereitstellung zu beschleunigen. Achten Sie darauf, dass die Backend-Server so konfiguriert sind, dass die Antwortheader gesendet werden, die für das Speichern statischer Antworten erforderlich sind.

HTTP verwenden, wenn HTTPS nicht erforderlich ist

Google verschlüsselt den Traffic zwischen Proxy-Load-Balancern und Back-Ends automatisch auf Paketebene. Durch die Verschlüsselung auf Paketebene wird die Layer-7-Verschlüsselung mit HTTPS zwischen dem Load-Balancer und den Back-Ends für die meisten Zwecke redundant. Verwenden Sie für den Traffic zwischen dem Load-Balancer und Ihren Back-Ends HTTP und nicht HTTPS oder HTTP/2. Mit HTTP können Sie auch die CPU-Auslastung Ihrer Backend-VMs reduzieren. Wenn das Backend jedoch eine Internetnetzwerk-Endpunktgruppe (NEG) ist, verwenden Sie HTTPS oder HTTP/2 für den Traffic zwischen dem Load-Balancer und dem Backend. So wird sichergestellt, dass Ihr Traffic über das öffentliche Internet sicher ist. Für eine optimale Leistung empfehlen wir das Benchmarking der Traffic-Muster Ihrer Anwendung.

Network Intelligence Center

Das Network Intelligence Center von Google Cloud bietet einen umfassenden Überblick über die Leistung des Google Cloud-Netzwerks für alle Regionen. Mit Network Intelligence Center können Sie feststellen, ob Latenzprobleme durch Probleme in Ihrem Projekt oder im Netzwerk verursacht werden. Sie können diese Informationen auch verwenden, um die Regionen und Zonen auszuwählen, in denen Sie Ihre Arbeitslasten bereitstellen möchten, um die Netzwerkleistung zu optimieren.

Verwenden Sie die folgenden Tools, die vom Network Intelligence Center bereitgestellt werden, um die Netzwerkleistung für Ihre Arbeitslasten in Google Cloud zu überwachen und zu analysieren:

• Im Dashboard zur Leistungsüberwachung wird die Latenz zwischen Google Cloud-Regionen und einzelnen Regionen und Standorten im Internet angezeigt. Mithilfe des Dashboards zur Leistungsüberwachung können Sie feststellen, wo Arbeitslasten für eine optimale Latenz platziert werden sollen, und ermitteln, wann ein Anwendungsproblem möglicherweise auf zugrunde liegende Netzwerkprobleme zurückzuführen ist.

• Netzwerktopologie bietet eine visuelle Ansicht Ihrer VPC-Netzwerke (Virtual Private Cloud), die Hybridkonnektivität mit Ihren lokalen Netzwerken und die Konnektivität zu von Google verwalteten Diensten. Netzwerktopologie bietet operative Echtzeitmesswerte, mit denen Sie die Netzwerkleistung analysieren und verstehen sowie ungewöhnliche Traffic-Muster erkennen können.

• Network Analyzer ist ein automatisches Konfigurations-Monitoring- und Diagnosetool. Es prüft VPC-Netzwerkkonfigurationen für Firewallregeln, Routen, Konfigurationsabhängigkeiten und Konnektivität für Dienste und Anwendungen. Sie können Netzwerkfehler erkennen und eine Ursachenanalyse sowie Empfehlungen bereitstellen. Network Analyzer bietet priorisierte Informationen, mit denen Sie Probleme bei der Netzwerkkonfiguration analysieren können, z. B. eine hohe Auslastung von IP-Adressen in einem Subnetz.

API Gateway und Apigee

Dieser Abschnitt enthält Empfehlungen zur Optimierung der Leistung der APIs, die Sie mithilfe von API-Gateway undApigee in Google Cloud bereitstellen.

Mit API Gateway können Sie APIs für serverlose Google Cloud-Back-Ends, einschließlich Cloud Functions, Cloud Run und App Engine, erstellen und verwalten. Diese Dienste sind verwaltete Dienste und werden automatisch skaliert. Wenn die Anwendungen, die auf diesen Diensten bereitgestellt werden, skaliert werden, müssen Sie jedoch die Kontingente und Ratenbegrenzungen für API Gateway erhöhen.

Hinweis: Wenn Sie Ihre Anwendungen oder Infrastruktur für mehr Traffic freigeben, kann es zu Leistungsengpässen auf der nächsten Ebene im Anwendungspaket kommen.

Apigee bietet die folgenden Analyse-Dashboards, mit denen Sie die Leistung Ihrer verwalteten APIs überwachen können:

• API-Proxy-Leistungsdashboard: Überwachen Sie API-Proxy-Trafficmuster und -Verarbeitungszeiten.
• Dashboard zur Leistungsüberwachung: Trafficmuster und Leistungsmesswerte für API-Proxy-Backend-Ziele visualisieren.
• Dashboard zur Cache-Leistung: Überwachen Sie Leistungsmesswerte für den Apigee-Cache, z. B. die durchschnittliche Cache-Trefferquote und die durchschnittliche Zeit im Cache.

Wenn Sie die Apigee-Integration nutzen, beachten Sie beim Erstellen und Verwalten Ihrer Integrationen die Limits für die Systemkonfiguration.

Nächste Schritte

Hier finden Sie Best Practices zur Optimierung der Leistung Ihrer Computing-, Speicher-, Datenbank- und Analyseressourcen:

• Computing-Leistung optimieren.
• Speicherleistung optimieren.
• Leistung von Datenbanken optimieren.
• Analyseleistung optimieren.

Leistung von Datenbanken optimieren

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Optimierung der Leistung Ihrer Datenbanken in Google Cloud.

Cloud SQL

Die folgenden Empfehlungen helfen Ihnen, die Leistung Ihrer Cloud SQL-Instanzen zu optimieren, auf denen SQL Server-, MySQL- und PostgreSQL-Datenbanken ausgeführt werden.

• Für SQL Server-Datenbanken empfiehlt Google, bestimmte Parameter zu ändern und die Standardwerte für einige Parameter beizubehalten.
• Berücksichtigen Sie bei der Wahl des Speichertyps für MySQL- oder PostgreSQL-Datenbanken den Kosten-/Leistung-Kompromiss zwischen SSD- und HDD-Speicher.
• Verwenden Sie das Cloud SQL Insights-Dashboard, um Leistungsprobleme mit PostgreSQL-Datenbanken zu identifizieren und zu analysieren.
• Verwenden Sie die EXPLAIN-Anweisung, um beim Ausführen von SQL-Abfragen eine schlechte Leistung zu diagnostizieren.

Weitere Informationen erhalten Sie in dieser Dokumentation:

• Leistung optimieren: SQL Server
• Leistung optimieren: MySQL
• Leistung optimieren: PostgreSQL

Bigtable

Dieser Abschnitt enthält Empfehlungen zur Optimierung der Leistung Ihrer Bigtable-Instanzen.

Kapazität anhand von Leistungsanforderungen planen

Sie können Bigtable für verschiedenste Anwendungen verwenden, die jeweils andere Optimierungsziele haben. Beispielsweise kann bei Batchdatenverarbeitungsjobs der Durchsatz wichtiger sein als die Latenz. Bei einem Onlinedienst, der Nutzeranfragen verarbeitet, müssen Sie möglicherweise eine geringere Latenz vor dem Durchsatz priorisieren. Berücksichtigen Sie bei der Planung der Kapazität für Ihre Bigtable-Cluster die Durchsatz-/Latenz-Kompromisse. Weitere Informationen finden Sie unter Bigtable-Kapazität planen.

Orientieren Sie sich an den Best Practices für Schemadesign

Ihre Tabellen können auf Milliarden von Zeilen und Tausende von Spalten skaliert werden, sodass Sie Petabyte an Daten speichern können. Berücksichtigen Sie beim Entwerfen des Schemas für Ihre Bigtable-Tabellen die Best Practices für das Schemadesign.

Leistung überwachen und Anpassungen vornehmen

Überwachen Sie die CPU- und Laufwerknutzung für Ihre Instanzen, analysieren Sie die Leistung der einzelnen Cluster und prüfen Sie die Größenempfehlungen, die in den Monitoring-Diagrammen angezeigt werden.

Spanner

Dieser Abschnitt enthält Empfehlungen zur Optimierung der Leistung Ihrer Spanner-Instanzen.

Primärschlüssel wählen, der einen Hotspot verhindert

Ein Hotspot ist ein einzelner Server, der zur Verarbeitung vieler Anfragen gezwungen wird. Wenn Sie den Primärschlüssel für Ihre Datenbank wählen, folgen Sie den Best Practices für das Schemadesign, um einen Hotspot zu verhindern.

Best Practices für SQL-Codierung

Der SQL-Compiler in Spanner konvertiert jede deklarative SQL-Anweisung, die Sie in einen imperativen Abfrageausführungsplan schreiben. Spanner verwendet den Ausführungsplan, um die SQL-Anweisung auszuführen. Befolgen Sie beim Erstellen von SQL-Anweisungen die Best Practices für SQL, damit Spanner Ausführungspläne verwendet, die eine optimale Leistung erzielen.

Abfrageoptionen zur Verwaltung des SQL-Abfrageoptimierungstools verwenden

Spanner verwendet ein SQL-Abfrageoptimierungstool, um SQL-Anweisungen in effiziente Abfrageausführungspläne umzuwandeln. Der Abfrageausführungsplan, den das Optimierungsprogramm erstellt, kann sich geringfügig ändern, wenn sich das Abfrageoptimierungstool weiterentwickelt oder die Datenbankstatistiken aktualisiert werden. Mit den Abfrageoptionen können Sie das Risiko einer Leistungsregression minimieren, wenn sich das Abfrageoptimierungstool oder die Datenbankstatistik ändern.

Struktur der Abfrageausführungspläne visualisieren und optimieren

Zum Analysieren von Problemen mit der Abfrageleistung können Sie die Struktur der Abfrageausführungspläne mit der Visualisierung für Abfragepläne visualisieren und optimieren.

Vorgangs-APIs verwenden, um lang andauernde Vorgänge zu verwalten

Für bestimmte Methodenaufrufe erstellt Spanner Vorgänge mit langer Ausführungszeit, deren Abschluss sehr lange dauern kann. Beispiel: Wenn Sie eine Datenbank wiederherstellen, erstellt Spanner einen Vorgang mit langer Ausführungszeit, um den Wiederherstellungsfortschritt zu verfolgen. Damit Sie Vorgänge mit langer Ausführungszeit überwachen und verwalten können, bietet Spanner Vorgangs-APIs. Weitere Informationen finden Sie unter Vorgänge mit langer Ausführungszeit verwalten.

Best Practices für das Laden im Bulk befolgen

Spanner unterstützt mehrere Optionen zum Laden großer Datenmengen im Bulk. Die Leistung eines Bulk-Ladevorgangs hängt von Faktoren wie Partitionierung, Anzahl der Schreibanfragen und der Größe pro Anfrage ab. Wenn Sie große Datenmengen effizient laden möchten, folgen Sie den Best Practices für Bulk-Ladungen.

CPU-Auslastung überwachen und steuern

Die CPU-Auslastung Ihrer Spanner-Instanz kann sich auf die Anfragelatenzen auswirken. Ein überlasteter Backend-Server kann zu höheren Anfragelatenzen führen. Spanner bietet CPU-Auslastungsmesswerte, mit denen Sie eine hohe CPU-Auslastung untersuchen können. Bei leistungsabhängigen Anwendungen müssen Sie möglicherweise die CPU-Auslastung durch Erhöhen der Rechenkapazität verringern.

Latenzprobleme analysieren und lösen

Wenn ein Client einen Remote-Prozeduraufruf an Spanner sendet, wird zuerst die API-Anfrage von den Clientbibliotheken vorbereitet. Die Anfrage durchläuft dann das Google Front End und das Spanner API-Frontend, bevor sie die Spanner-Datenbank erreicht. Zum Analysieren und Lösen von Latenzproblemen müssen Sie die Latenz für jedes Segment des Pfads, das die API-Anfrage durchläuft, messen und analysieren. Weitere Informationen finden Sie im Leitfaden zur End-to-End-Latenz von Spanner.

Anwendungen starten, wenn die Datenbank einen einsatzbereiten Zustand erreicht

Während Ihre Spanner-Datenbank wächst, teilt sie den Schlüsselbereich Ihrer Daten in Splits auf. Jeder Split ist ein Bereich an Zeilen, der eine Teilmenge Ihrer Tabelle enthält. Um die Gesamtlast der Datenbank auszugleichen, verschiebt Spanner eigenständig und dynamisch einzelne Splits und weist sie verschiedenen Servern zu. Wenn die Splits auf mehrere Server verteilt sind, wird davon ausgegangen, dass sich die Datenbank im einsatzbereiten Zustand befindet. Eine einsatzbereite Datenbank kann die Parallelität maximieren und eine verbesserte Leistung liefern. Bevor Sie Ihre Anwendungen starten, empfehlen wir es, Ihre Datenbank mit Testdatenladevorgängen aufzuwärmen.

Nächste Schritte

Hier finden Sie Best Practices zur Optimierung der Leistung Ihrer Computing-, Speicher-, Netzwerk- und Analyseressourcen:

• Computing-Leistung optimieren.
• Speicherleistung optimieren.
• Optimieren Sie die Netzwerkleistung.
• Analyseleistung optimieren.

Analyseleistung optimieren

Dieses Dokument im Google Cloud-Architektur-Framework enthält Empfehlungen zur Optimierung der Leistung Ihrer Arbeitslasten zur Datenanalyse in Google Cloud.

BigQuery

Dieser Abschnitt enthält Empfehlungen zur Optimierung der Leistung von Abfragen in BigQuery.

Abfragedesign optimieren

Die Abfrageleistung hängt von Faktoren wie der Anzahl der Bytes, die Ihre Abfragen lesen und schreiben ab, und vom Datenvolumen, das zwischen Slots übergeben wird. Zur Optimierung der Leistung Ihrer Abfragen in BigQuery wenden Sie die Best Practices an, die in der folgenden Dokumentation beschrieben werden:

• Einführung in die Optimierung der Abfrageleistung
• Eingabedaten und Datenquellen verwalten
• Kommunikation zwischen Slots optimieren
• Abfrageleistung optimieren
• Ausgabe von Abfragen verwalten
• SQL-Anti-Muster vermeiden

Materialisierte Ansichten effizient definieren und verwenden

Sie können materialisierte Ansichten verwenden, um die Leistung von Arbeitslasten zu verbessern, die allgemeine und wiederkehrende Abfragen verwenden. Die Anzahl der materialisierten Ansichten, die Sie erstellen können, ist begrenzt. Erstellen Sie nicht pro Variante einer Abfrage eine separate materialisierte Ansicht. Definieren Sie stattdessen materialisierte Ansichten, die Sie für mehrere Abfragemuster nutzen können.

JOIN-Performance verbessern

Sie können materialisierte Ansichten verwenden, um die Kosten und Latenz einer Abfrage zu reduzieren, die eine Aggregation zusätzlich zu einem JOIN durchführt. Stellen Sie sich einen Fall vor, in dem Sie eine große Faktentabelle mit einigen kleinen Dimensionstabellen verknüpfen und dann zusätzlich zum Join eine Aggregation anordnen. Sie sollten eventuell die Abfrage neu schreiben, um zuerst die Aggregation über der Faktentabelle mit Fremdschlüsseln als Gruppierungsschlüssel durchzuführen. Führen Sie dann das Ergebnis mit den Dimensionstabellen zusammen. Führen Sie abschließend eine Post-Aggregation durch.

Dataflow

Dieser Abschnitt enthält Empfehlungen zur Optimierung der Abfrageleistung Ihrer Dataflow-Pipelines.

Wenn Sie Pipelines erstellen und bereitstellen, können Sie Ausführungsparameter wie den Compute Engine-Maschinentyp konfigurieren, der für die Dataflow-Worker-VMs verwendet werden soll. Weitere Informationen finden Sie unter Pipelineoptionen.

Nachdem Sie Pipelines bereitgestellt haben, verwaltet Dataflow die Compute Engine- und Cloud Storage-Ressourcen, die zum Ausführen Ihrer Jobs erforderlich sind. Darüber hinaus helfen folgende Funktionen von Dataflow bei der Optimierung der Leistung der Pipelines:

• Parallelisierung: Dataflow partitioniert die Daten automatisch und verteilt den Worker-Code zur parallelen Verarbeitung auf Compute Engine-Instanzen. Weitere Informationen finden Sie unter Parallelisierung und Verteilung.
• Optimierung: Dataflow verwendet Ihren Pipelinecode zum Erstellen einer Ausführungsgrafik, die PCollection-Objekte in der Pipeline darstellt und transformiert. Anschließend wird die Grafik für die effizienteste Leistung und Ressourcennutzung optimiert. Dataflow optimiert darüber hinaus automatisch potenziell kostspielige Vorgänge wie etwa Datenzusammenfassungen. Weitere Informationen finden Sie unter Zusammenführung optimieren und Kombination optimieren.
• Automatische Abstimmung: Dataflow optimiert Jobs dynamisch während ihrer Ausführung. Dazu verwendet es horizontales Autoscaling ,vertikales Autoscaling und den dynamischen Aufgabenausgleich.

Sie können die Leistung von Dataflow-Pipelines mit der webbasierten Monitoring-Oberfläche oder der Dataflow gcloud CLI überwachen.

Hinweis: Sie können Cloud Profiler auch verwenden, um die Teile des Pipelinecodes zu identifizieren, die die meisten Ressourcen verbrauchen. Weitere Informationen finden Sie unter Leistung der Pipeline überwachen.

Dataproc

In diesem Abschnitt werden Best Practices zur Optimierung der Leistung von Dataproc-Clustern beschrieben.

Cluster automatisch skalieren

Damit Ihre Dataproc-Cluster eine vorhersagbare Leistung liefern, können Sie Autoscaling aktivieren. Dataproc verwendet Hadoop YARN-Speichermesswerte und eine Autoscaling-Richtlinie, die Sie definieren, um die Anzahl der Worker-VMs in einem Cluster automatisch anzupassen. Weitere Informationen zur Verwendung und Konfiguration von Autoscaling finden Sie unter Cluster automatisch skalieren.

Geeigneten Speicher bereitstellen

Wählen Sie basierend auf Ihren Leistungs- und Kostenanforderungen eine geeignete Speicheroption für Ihren Dataproc-Cluster aus:

• Verwenden Sie Cloud Storage, wenn Sie ein kostengünstiges Hadoop-kompatibles Dateisystem (Hadoop Compatible File System, HCFS) benötigen, aus dem Hadoop- und Spark-Jobs mit minimalen Änderungen lesen und schreiben können. Die in Cloud Storage gespeicherten Daten sind dauerhaft und können von anderen Dataproc-Clustern und anderen Produkten wie BigQuery aufgerufen werden.
• Wenn Sie ein Hadoop Distributed File System (HDFS) mit niedriger Latenz für Ihren Dataproc-Cluster benötigen, verwenden Sie nichtflüchtigen, an den Worker-Knoten angehängten Compute Engine-Speicher. Die im HDFS-Speicher gespeicherten Daten sind flüchtig und die Speicherkosten sind höher als die der Cloud Storage-Option.
• Sie können beide Speicheroptionen kombinieren, um den Leistungsvorteil der nichtflüchtigen Speicher von Compute Engine und die Kosten- und Langlebigkeitsvorteile von Cloud Storage zu kombinieren. Beispielsweise könnten Sie die Quell- und die endgültigen Datasets in Cloud Storage speichern und eine begrenzte HDFS-Kapazität für die Zwischen-Datasets bereitstellen. Beachten Sie die Empfehlungen im Abschnitt Nichtflüchtige Speicher und lokale SSDs, wenn Sie Größe und Typ der Laufwerke für HDFS-Speicher bestimmen.

Latenz bei der Verwendung von Cloud Storage verringern

Um die Latenz beim Zugriff auf in Cloud Storage gespeicherte Daten zu reduzieren, empfehlen wir Folgendes:

• Erstellen Sie Ihren Cloud Storage-Bucket in der Region, in der auch ihr Dataproc-Cluster ist.
• auto.purge für von Apache Hive verwaltete Tabellen deaktivieren, die in Cloud Storage gespeichert sind.
• Wenn Sie Spark SQL verwenden, sollten Sie Dataproc-Cluster mit den neuesten Versionen der verfügbaren Images erstellen. Mit den neuesten Versionen können Sie Leistungsprobleme vermeiden, die in älteren Versionen auftreten können, z. B. eine langsame INSERT OVERWRITE-Leistung in Spark 2.x.
• Wenn Sie die Möglichkeit minimieren möchten, viele Dateien mit unterschiedlichen oder kleinen Größen in Cloud Storage zu schreiben, können Sie die Spark SQL-Parameter spark.sql.shuffle.partitions und spark.default.parallelism oder den Hadoop-Parameter mapreduce.job.reduces konfigurieren.

Speicherlast und Kapazität überwachen und anpassen

Die nichtflüchtigen Speicher, die an die Worker-Knoten in einem Dataproc-Cluster angehängt sind, enthalten Shuffle-Daten. Um eine optimale Leistung zu erzielen, benötigen die Worker-Knoten ausreichend Speicherplatz. Wenn die Knoten nicht genügend Speicherplatz haben, werden sie im YARN NodeManager-Log als UNHEALTHY markiert. Wenn dieses Problem auftritt, erhöhen Sie entweder die Laufwerkgröße für die betroffenen Knoten oder führen weniger Jobs gleichzeitig aus.

EFM aktivieren

Wenn Worker-Knoten aus einem laufenden Dataproc-Cluster entfernt werden, z. B. aufgrund des Herunterskalierens oder des vorzeitigen Beendens, können Shuffle-Daten verloren gehen. Zur Minimierung von Jobverzögerungen in solchen Szenarien empfehlen wir die Aktivierung des Enhanced Flexibility Mode (EFM) für Cluster, die VMs auf Abruf nutzen oder nur die sekundäre Worker-Gruppe automatisch skalieren.

Nächste Schritte

Sehen Sie sich die Best Practices zur Optimierung der Leistung Ihrer Computing-, Speicher-, Netzwerk- und Datenbankressourcen an:

• Computing-Leistung optimieren.
• Speicherleistung optimieren.
• Netzwerkleistung optimieren.
• Leistung von Datenbanken optimieren.

Neuerungen im Architecture Framework

In diesem Dokument werden wichtige Änderungen am Google Cloud-Architektur-Framework aufgeführt.

28. November 2023

• Zuverlässigkeitskategorie:
  • Der Inhalt wurde neu organisiert, um die Lesbarkeit und die Konsistenz zu verbessern:
  • SLOs definieren: Der Abschnitt "Terminologie" wurde auf die neue Seite verschoben: Terminologie.
  • SLOs übernehmen: Der Abschnitt "SLOs und Benachrichtigungen" wurde auf die neue Seite verschoben: SLOs und Benachrichtigungen.

9. November 2023

• Kategorie des Systemdesigns:
  • Cloud-Architekten für die Auswahl von Deployment-Archetypen für Arbeitslasten in Google Cloud unterstützen.

8. September 2023

• Kategorie der Kostenoptimierung:

  • Es wurden Informationen zur Verwendung von Tags für Kostenzuordnung und Governance hinzugefügt.
  • Die Anleitung zum Identifizieren von Anomalien bei Labels wurde aktualisiert.

  Weitere Informationen finden Sie unter Kosten über Tags oder Labels verfolgen und zuweisen.

28. August 2023

• Kategorie des Systemdesigns:
  • Die Liste der KI- und ML-Dienste in Google Cloud wurde aktualisiert.

23. August 2023

• Kategorie der Kostenoptimierung:
  • Anleitung zur Optimierung der Spanner-Ressourcennutzung für kleine Arbeitslasten mithilfe von Verarbeitungseinheiten anstelle von Knoten hinzugefügt.

18. August 2023

• Kategorie Sicherheit, Datenschutz und Compliance:
  • Es wurden HIPAA-bezogene Informationen hinzugefügt.
• Kategorie der operativen Exzellenz:
  • Die Best Practices für die Planung von Traffic-Spitzenereignissen wurden aktualisiert.

9. August 2023

• Zuverlässigkeitskategorie:
  • Es wurden Links zur dokumentationsbezogenen Dokumentation für die folgenden Produkte hinzugefügt:
    • Dataproc
    • Bigtable
    • Cloud SQL
    • Spanner

13. Juli 2023

• Systemdesign:
  • AlloyDB for PostgreSQL wurde der Liste der Datenbankdienste in Google Cloud hinzugefügt.
• Kostenoptimierung:
  • Im Abschnitt Nichtflüchtiger Speicher wurden Anleitungen zu Google Cloud Hyperdisk und lokalen SSDs hinzugefügt.

23. Juni 2023

• Leistungsoptimierung:
  • Es wurde eine Anleitung zur Optimierung der Bandbreitennutzung mit Jumbo Frames und entsprechenden Maschinentypen für VMs hinzugefügt.

15. Juni 2023

• Sicherheit, Datenschutz und Compliance:
  • Anleitung zum Sichern von Verbindungen zu lokalen und Multi-Cloud-Umgebungen mit Cross-Cloud Interconnect hinzugefügt.
  • Es wurde eine Anleitung zum Sichern des Perimeters von Cloud-Arbeitslasten mithilfe von Firewallrichtlinien und -regeln und Secure Web Proxy hinzugefügt.

30. März 2023 .

• Dem Framework wurden zwei zusätzliche SLO-Artikel hinzugefügt:
  • SLOs definieren
  • SLOs übernehmen

16. September 2022

• Größere Erweiterung der Kategorie Leistungsoptimierung.

10. August 2022

• Änderungen in der Kategorie Systemdesign:
  • Es wurden Kernprinzipien des Systemdesigns hinzugefügt.
  • Es wurden Empfehlungen hinzugefügt, um Google Cloud-Beratungsdienstleistungen zu nutzen und mit unseren Partnern zu interagieren.

4. August 2022

• Informationen zu den folgenden Funktionen wurden in der Kategorie Kostenoptimierung hinzugefügt:

  • Ausfälle aufgrund von Abrechnungsproblemen verhindern, indem Sie die Verknüpfung zwischen einem Projekt und seinem Rechnungskonto sperren Weitere Informationen finden Sie unter Zugriffssteuerung für die Abrechnung konfigurieren.

  • Kontingente über die Service Usage API reduzieren Weitere Informationen finden Sie unter Budgets, Benachrichtigungen und Kontingente.

  • Unbeaufsichtigte Projekte identifizieren und entfernen Weitere Informationen finden Sie unter Active Assist-Empfehlungen.

13. Juli 2022

• Änderungen in der Kategorie „Operative Exzellenz”:

  • Es wurde eine Best Practice zum Erstellen eines Kompetenzzentrums hinzugefügt.
  • Es wurde eine Best Practice zum Einrichten eines Audit-Trails hinzugefügt.

(27. Juni 2022).

• Im Kategorie Sicherheit wurden Informationen zu gemeinsamen Verantwortlichkeiten und Fate-Sharing in Google Cloud hinzugefügt.

13. Juni 2022

• In der Kategorie Systemdesign wurden Empfehlungen hinzugefügt, um Sie bei der Entwicklung von Cloud-Arbeitslasten für klimafreundliche Nachhaltigkeit zu unterstützen.

1. Juni 2022

• Informationen zu Spot-VMs wurden im Abschnitt Kosten optimieren: Computing, Container und serverloses Computing hinzugefügt.

7. Mai 2022

• Informationen zu Standorten mit zwei Regionen wurden in den Best Practices zur Kostenoptimierung für Cloud Storage hinzugefügt.

04. Mai 2022

• Es wurden Leitfäden zur Produktzuverlässigkeit hinzugefügt. Diese Leitfäden enthalten Best Practices für die Zuverlässigkeit der folgenden Produkte:

  • Computing: Compute Engine, Cloud Run, Cloud Functions und Google Kubernetes Engine

  • Speicher und Datenbanken: Cloud Storage, Firestore

  • Netzwerk: Cloud DNS und Cloud Load Balancing

  • Datenanalyse: BigQuery

25. Februar 2022

• Änderungen an der Sicherheitskategorie:

  • Die Best Practices für Compliance wurden aktualisiert, um die Automatisierung zu besprechen.

15. Dezember 2021

• Start des Architektur-Framework-Bereichs in der Google Cloud Community

25. Oktober 2021

• Änderungen in der Kategorie Zuverlässigkeit:

  • Es wurden Best Practices für das Replizieren von Daten aus verschiedenen Regionen für die Notfallwiederherstellung und den Aufbau einer multiregionalen Architektur für Ausfallsicherheit bei regionalen Ausfällen hinzugefügt.
  • Es wurde ein Beispiel für die Berechnung von Fehlerbudgets hinzugefügt.
  • Es wurden Best Practices zur Auswahl geeigneter Namen für Anwendungen und Dienste hinzugefügt.

7. Oktober 2021

• Große Aktualisierung aller Kategorien

---

1. Anna Berenberg und Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Band 55, Ausgabe 3, Artikelnr.: 61, Seiten 1-48 ↩