Skalierbare Webanwendungen mit Cloud Datastore erstellen

Dieser Artikel bietet einen Überblick über die Entwicklung umfangreicher Webanwendungen mit Datastore, einem skalierbaren, hochverfügbaren und vollständig verwalteten NoSQL-Hochleistungs-Datenbanksystem. Der Artikel enthält Szenarien für umfassende Webanwendungen, die Datastore gemeinsam mit anderen Produkten der Google Cloud (GCP) verwenden.

Infrastrukturadministratoren, die Datenbanksysteme für große Webanwendungen verwalten, stehen vor großen Herausforderungen. Insbesondere können Konfigurationsänderungen komplex und riskant sein, wenn aufgrund der zustandsorientierten Natur dieser Datenbanksysteme unvorhergesehene Situationen auftreten. Vor der Einführung einer neuen Anwendung müssen Administratoren häufig viel Zeit für die Kapazitätsplanung aufwenden. Beispielsweise müssen sie die Anzahl der virtuellen Maschinen (VMs), die Größe des Festplattenspeichers und die Netzwerkkonfiguration planen, um maximalen Durchsatz und minimale Latenz zu erzielen. Diese Art von Planung ist eine Herausforderung, da es viele unbekannte Faktoren gibt, so zum Beispiel die Menge und Häufigkeit offener Datenbankverbindungen und die Entwicklung von Nutzungsmustern im Laufe der Zeit. Regelmäßige Wartungsarbeiten sind ebenfalls erforderlich, um Datenbanksoftware zu aktualisieren und Ressourcen zu skalieren, damit die wachsende Nachfrage gedeckt werden kann.

Diese Planung und Wartung erfordern Zeit, Geld und Aufmerksamkeit, die von der Entwicklung neuer Anwendungsfeatures abgeht. Daher ist es wichtig, ein Gleichgewicht zwischen der Bereitstellung ausreichender Ressourcen zur Bewältigung großer Lasten und der Überschreitung ungenutzter Ressourcen zu finden. Mit Datastore können Infrastrukturadministratoren diese Herausforderungen minimieren, um sich auf die Entwicklung neuer Anwendungsfeatures zu konzentrieren.

Anwendungsfälle für Datastore

Auf übergeordneter Ebene eignet sich Datastore am besten zum Speichern hierarchischer Transaktionsdaten mit einem flexiblen, nicht relationalen Schema. Ziehen Sie Datastore insbesondere dann in Erwägung, wenn Sie für Ihre Webanwendung einige der folgenden Features benötigen:

  • Beliebige Speicherkapazität: Datastore ist unabhängig von der Menge der gespeicherten Daten. Kilobyte und Petabyte werden gleichermaßen effektiv verarbeitet, ohne die Leistung zu beeinträchtigen.
  • ACID-Konformität: Datastore unterstützt ACID-konforme Transaktionen (Atomicity, Consistency, Isolation, Durability – Atomarität, Konsistenz, Isolation, Langlebigkeit) mit mehreren Dokumenten.
  • Ausgewogene Konsistenz: Datastore bietet ein optimales Gleichgewicht zwischen strikter Konsistenz und Eventual Consistency. Ancestor-Abfragen und Entitätsabfragen nach Schlüssel weisen immer strikte Konsistenz auf, während sich alle anderen Abfragen letztendlich durch Eventual Consistency auszeichnen.
  • Indexierung: Datastore unterstützt neben primären Indexen auch sekundäre und zusammengesetzte Indexe.
  • Mandantenfähigkeit: Datastore unterstützt mandantenfähige Datenbanken. Dabei werden separate Datenpartitionen, sogenannte Namespaces, für mehrere Kundenorganisationen bereitgestellt.
  • Autoscaling: Datastore kann zehntausende Maschinen automatisch und ohne Ausfallzeiten skalieren. Dank dieses Skalierungsmechanismus, der seit über zehn Jahren in App Engine getestet wurde, kann Datastore Millionen von Anfragen pro Sekunde bearbeiten. Kunden bezahlen nur für die tatsächliche Nutzung basierend auf der Speichergröße und der Anzahl der Vorgänge. Hier finden Sie weitere Informationen zu Datastore-Preisen.
  • Sicherheit: Datastore verschlüsselt alle Daten automatisch, bevor sie auf das Laufwerk geschrieben werden. Datastore bietet außerdem Identitäts- und Zugriffsverwaltung, mit dem Sie den Zugriff auf bestimmte Ressourcen genauer steuern und unerwünschten Zugriff auf andere Ressourcen verhindern können.
  • Redundanz: Datastore bietet zwei Redundanzebenen, die auf zwei verschiedenen Replikationstypen an mehreren Standorten basieren:

    • Regionale Replikation: Daten werden in mindestens drei verschiedenen Zonen innerhalb derselben Region repliziert, wodurch die Datenbank gegen zonale Ausfälle resistent wird. Diese Art der Replikation ist ideal, wenn Ihre oberste Priorität eine niedrige Schreiblatenz ist. In diesem Fall sollten sich die Rechenmaschinen Ihrer Anwendung in derselben Region befinden.
    • Multiregionale Replikation: Daten werden in mehreren Zonen über mindestens zwei verschiedenen Regionen hinweg repliziert. Die Verfügbarkeit und Redundanz sind hierdurch zwar höher, doch auch die Schreiblatenz steigt. Ein Witness-Knoten wird in einer dritten Region bereitgestellt, um als Ausgleich zwischen den beiden replizierten Regionen zu dienen, wie im folgenden Diagramm veranschaulicht wird.

Grafik: Replikationsschema für eine multiregionale Datenbank in Datastore

Abbildung 1. Replikationsschema für eine multiregionale Datenbank in Datastore

Da Datastore alle oben genannten Anforderungen erfüllen kann, eignet sich diese Datenbank für eine Vielzahl von Anwendungsfällen, darunter:

  • Nutzerprofile zum Anpassen der Nutzererfahrung basierend auf Einstellungen und früheren Aktivitäten. Mit dem flexiblen Schema von Datastore lässt sich die Struktur von Nutzerprofilen nach und nach weiterentwickeln. Sie können beispielsweise neue Attribute hinzufügen, um neue Features in Ihrer Anwendung zu unterstützen. Schemaänderungen werden ohne Ausfallzeiten und Leistungsbeeinträchtigung ausgeführt, auch wenn die Anzahl der Nutzer zunimmt.
  • Echtzeitinventare wie Produktkataloge für Einzelhändler. Sie können die umfangreichen, verschachtelten Entitäten von Datastore verwenden, um große Mengen nicht homogener, dünnbesetzter Daten für diverse Produkte zu speichern, ohne die Struktur zu sehr zu spezialisieren.
  • Nutzersitzungsverwaltung, z. B. für Einkaufswagen im Einzelhandel oder für ein mehrteiliges Bearbeitungsformular für die Buchung von Veranstaltungen. Die Datastore-Unterstützung für ACID-Transaktionen sorgt dafür, dass Nutzer bestimmte Elemente für einen bestimmten Zeitraum sperren können, bis die Transaktion abgeschlossen ist.
  • Zustandsmutationen, z. B. in Spielen, um für alle Spieler einen einheitlichen Zustand zu gewährleisten. Sie können die ACID-Transaktionen von Datastore verwenden, um Mutationen über eine große Anzahl gleichzeitiger Nutzer zu verbreiten. Ein konkretes Beispiel finden Sie unter Schnelles und zuverlässiges Ranking in Datastore für einen großen Spieledienst.
  • Nichtflüchtiger Write-through-Cache, z. B. ein einfach zu verwendender Speicher für Schlüssel/Wert-Paare. Sie können die Hochverfügbarkeit und Langlebigkeit von Datastore nutzen, um den Zustand beizubehalten und Datenverluste bei einem Anwendungsabsturz zu verhindern.

Alternative Speicheroptionen

Achten Sie beim Bewerten von Datastore als potenzielle Datenbanklösung darauf, dass die Produktionslimits hinsichtlich der Anforderungen Ihrer Anwendung angemessen sind. Obwohl Datastore in vielen Fällen eine vielseitige und anwendbare Option darstellt, können andere Speicheroptionen in der GCP für bestimmte Szenarien besser geeignet sein.

Äußerst niedrige Latenz

Datastore priorisiert Langlebigkeit und Verfügbarkeit gegenüber Latenz mithilfe von regionsübergreifenden oder zonenübergreifenden synchronen Schreibvorgängen. Wenn Ihre Anwendung beim Lesen oder Schreiben von Daten eine Latenz von weniger als zehn Millisekunden erfordert, sollten Sie eine speicherinterne Datenbank wie Memcached oder Redis verwenden. Speicherinterne Datenbanken können für Datastore auch als Cache verwendet werden. Dieser Cache wird weiter unten im PaaS-Szenario (Platform as a Service) erläutert. Weitere Informationen zu Memcached finden Sie in der Dokumentation zur Verwendung mit App Engine und mit Google Kubernetes Engine.

Bewältigung hoher Lasten

Datastore kann Vorgänge in äußerst großem Maßstab ausführen. Zur Unterstützung komplexer Features wie Replikation und Transaktionen sind jedoch möglicherweise Kompromisse erforderlich. Die Leistung von Systemen, die bestimmte Arten extremer Lasten verarbeiten, kann hierdurch beeinträchtigt werden. Wenn Ihre Anwendung extrem aufwendige Schreibvorgänge generiert, wie z. B. kontinuierliche Datenaufnahme über Sensoren des Internets der Dinge, eignet sich die Verwendung von Cloud Bigtable. Sie erhalten dadurch leistungsfähigere Datenaufnahmefunktionen auf Kosten von Transaktionen und sekundären Indexen. Wenn Ihre Anwendung für Nutzer häufig dieselben Informationen anzeigt, z. B. eine Bestenliste für Spiele, empfiehlt sich das clientseitige Caching. Sie erzielen hierdurch eine Lastenreduzierung, da unnötige Anfragen an den Server vermieden werden.

SQL-Schema und Semantik

Datastore verwendet eine SQL-ähnliche Syntax, die GQL genannt wird, um komplexe und effiziente Abfragen durchzuführen. Die nicht relationale Datenbank Datastore unterstützt jedoch keine relationalen Schemas oder Abfragen, die SQL-Semantik verwenden. Insbesondere unterstützt Datastore keine Join-Vorgänge, Ungleichheitsfilter für mehrere Attribute oder Datenfiltervorgänge auf Basis der Ergebnisse einer Unterabfrage. Wenn Ihre Anwendung SQL-Unterstützung benötigt, verwenden Sie Cloud SQL für nicht horizontale Skalierungen oder Cloud Spanner für größere horizontale und globale Skalierungen.

Datenanalyse

Datastore ist für die Online-Transaktionsverarbeitung (Online Transaction Processing, OLTP) optimiert. Wenn Ihre Anwendung eine Speicheroption für das Scannen vollständiger Tabellen erfordert und interaktive Abfragen in einem System zur analytischen Onlineverarbeitung (Online Analytical Processing, OLAP) benötigt, verwenden Sie BigQuery. Wenn Ihre Anwendung sowohl OLTP- als auch OLAP-Systeme benötigt, verwenden Sie Datastore als OLTP-System und exportieren Datastore-Daten in BigQuery zur Analyse, wie weiter unten im Szenario der Datenanalyseplattform beschrieben.

Echtzeitfunktionen für mobile Anwendungen

Datastore ist darauf ausgelegt, große Datenmengen zu speichern, auf die serverseitig zugegriffen werden kann. Wenn Ihre Anwendung auf Mobilgeräten basiert und Echtzeitfunktionen erfordert, z. B. automatische Push-Updates, die durch Datenänderungen ausgelöst werden, sollten Sie vielleicht Firebase verwenden. Die Firebase-Plattform bietet viele auf Mobilgeräte ausgerichtete Features, einschließlich Absturzberichte, Nutzerverwaltung und -authentifizierung sowie Nutzerereignisanalysen.

Einbindung von Datastore in andere GCP-Produkte

Eine große Webanwendung erfordert mehr als nur ein skalierbares Datenbanksystem. Sie benötigt außerdem skalierbare Webserver, ein Caching-System, eine Speicherlösung für Datensicherungen und möglicherweise ein Data Warehouse mit einer ETL-Pipeline (Extrahieren, Transformieren, Laden), um Datenanalysen oder ML-Arbeitslasten zu unterstützen. Datastore eignet sich nicht nur zum Verwalten der Single Source of Truth (SSOT), die für Ihre Anwendung von zentraler Bedeutung ist, sondern kann auch in zahlreiche andere GCP-Produkte eingebunden werden, um eine Vielzahl von Anforderungen zu erfüllen. Das folgende Diagramm veranschaulicht diese Flexibilität.

Grafik: Einbinden von Datastore in andere GCP-Produkte

Abbildung 2. Einbinden von Datastore in andere GCP-Produkte

Programme, die mit Compute Engine, Google Kubernetes Engine, App Engine und Cloud Functions ausgeführt werden, können Datastore zum Lesen und Schreiben von Transaktionsdaten in großem Maßstab verwenden. Welche Laufzeitumgebung am besten geeignet ist, hängt von den Verwaltungs- und Anpassungsmöglichkeiten ab, die von Ihren Entwicklungs- und Infrastrukturteams benötigt werden. Beispiele:

  • Compute Engine bietet vollständige Kontrolle über virtuelle Maschinen (VMs).
  • GKE vereinfacht die Bereitstellung und Orchestrierung von Containern.
  • App Engine verwaltet die gesamte Infrastruktur, sodass Sie sich auf das Programmieren konzentrieren können.
  • Mit Cloud Functions können ereignisgesteuerte Mikrodienste bereitgestellt werden.

Programme interagieren mit Datastore mithilfe von REST APIs oder RPC APIs auf niedriger Ebene oder einer der plattformübergreifenden Clientbibliotheken, die für die Sprachen C#, Go, Java, Node.js, PHP, Python und Ruby verfügbar sind.

Datastore unterstützt Datenexporte nach Cloud Storage für die Archivierung oder Notfallwiederherstellung oder nach BigQuery zur Datenanalyse, entweder direkt oder über Cloud Storage. Sie können auch eine benutzerdefinierte Dataflow-Pipeline schreiben, um beispielsweise Entitäten mit einem Attribut zu filtern, das auf true gesetzt ist, oder um Daten vorab zu verarbeiten, bevor sie in BigQuery zur Analyse geladen werden. Für regelmäßige Datensicherungen können Sie die Ausführung einer Dataflow-Pipeline mithilfe von App Engine (nur flexible Umgebung) oder Cloud Functions planen oder Cronjobs mit Compute Engine verwenden.

Schließlich können Sie Datastore als Teil einer Pipeline für maschinelles Lernen verwenden. Die Pipeline kann beispielsweise Daten in AI Platform verarbeiten – entweder direkt unter Verwendung der Python-Bibliothek von Datastore oder indirekt durch Exportieren von Daten in Cloud Storage oder BigQuery.

Referenzarchitekturen

In diesem Abschnitt werden Szenarien zum Erstellen großer Webanwendungen beschrieben, die Datastore mit anderen GCP-Produkten kombinieren. Es werden verschiedene Funktionen behandelt, zum Beispiel tägliche Exporte, Caching, Datenverarbeitung und Trainingsmodelle für maschinelles Lernen. Außerdem wird für jedes Szenario eine Referenzarchitektur vorgestellt.

Die Szenarien und Architekturen sind nicht präskriptiv. Vielmehr sollen sie die Bandbreite der Einsatzmöglichkeiten von Datastore beim Erstellen skalierbarer Webanwendungen aufzeigen. Sie sollen auch dazu inspirieren, vielleicht Ihre eigene Webanwendung zu ändern, da Sie ihre Komponenten neu organisieren und an Ihre spezifischen Anforderungen anpassen können.

Szenario 1: Einfache Autoscaling-Infrastruktur mit täglichen Datenbank-Snapshots

In diesem Szenario wird eine verwaltete Instanzgruppe aus Compute Engine-VMs von einer großen Webanwendung genutzt. Die Instanzgruppe wird anhand der Ab- oder Zunahme der Last automatisch skaliert und der Cloud-HTTP(S)-Load-Balancer leitet eingehenden Traffic zwischen verfügbaren Instanzen weiter. Die VMs interagieren direkt mit Datastore, um Transaktionsdaten zu lesen und zu schreiben. Tägliche Snapshots der Datenbank werden in Cloud Storage gespeichert. Die Regeln zur Verwaltung des Objektlebenszyklus sorgen dafür, dass alte Snapshots regelmäßig in Cloud Storage Coldline verschoben werden, um die Kosten für die Speicherung archivierter Daten zu senken.

Grafik: Einfache Autoscaling-Infrastruktur mit täglichen Datenbank-Snapshots

Abbildung 3. Einfache Autoscaling-Infrastruktur mit täglichen Datenbank-Snapshots

Szenario 2: Containerbasierte Infrastruktur

In diesem Szenario unterstützt eine Spieleplattform den gleichzeitigen Zugriff durch Zehntausende von Spielern. Die Plattform besteht aus Hunderten von containerisierten Mikrodiensten, die in GKE gehostet werden. Die Plattform hat drei Schichten von Mikrodiensten, die alle als Autoscaling-Kubernetes-Pods bereitgestellt werden: NGINX-Controller-Pods, Front-End-Pods und Back-End-Pods.

Der Cloud-SSL-Proxy verteilt eingehenden TCP- und SSL-Traffic auf NGINX-Controller-Pods, die das HTTP-Load-Balancing zwischen Front-End-Pods mithilfe von Sitzungstreue verarbeiten. Dieser Ansatz sorgt dafür, dass Anfragen von einem bestimmten Client immer zum selben Front-End-Pod weitergeleitet werden. Zum Reduzieren der Latenz können Front-End-Pods clientspezifische Informationen und Spielerkonfigurationen lokal im Cache speichern. Back-End-Pods können die Latenz reduzieren, indem sie bestimmte Bereiche der Spielewelt verwalten und bereichsspezifische Informationen lokal im Cache speichern. Front-End- und Back-End-Pods schreiben die im Cache gespeicherten Informationen zur Langzeitspeicherung gleichzeitig in Datastore. So wird sichergestellt, dass kein Zustand verloren geht, wenn Front- und Back-End-Pods beendet werden.

Grafik: Containerbasierte Spieleplattform, die von Kubernetes Engine und Cloud Datastore betrieben wird

Abbildung 4. Containerbasierte Spieleplattform, die von Kubernetes Engine und Datastore betrieben wird

Weitere Informationen zum Bereitstellen von NGINX Controller auf der GCP finden Sie in der Anleitung. Eine alternative Referenzarchitektur für eine komplexe Spieleplattform wird in einer detaillierten Lösung beschrieben.

Szenario 3: Funktionsbasierte Infrastruktur

In diesem Szenario stellt eine Plattform für das Veranstaltungsmanagement eine API für mobile und desktopgestützte Nutzeranwendungen bereit. Jeder API-Endpunkt ist als Mikrodienst implementiert, der in Cloud Functions bereitgestellt wird. Jeder API-Endpunkt bietet einen spezifischen Dienst wie das Auflisten von Veranstaltungen, die Angabe von Informationen zu Veranstaltungsorten oder das Buchen von Tickets. Mikrodienste werden in JavaScript implementiert. Sie verwenden die Node.js-Clientbibliothek für Datastore, um nichtflüchtige Daten zu lesen und zu schreiben. Mit dieser vollständig entkoppelten, serverlosen Architektur können Sie jeden Dienst unabhängig skalieren.

Grafik: Serverlose funktionsbasierte Infrastruktur zum Schreiben nichtflüchtiger Daten in Datastore

Abbildung 5. Serverlose, funktionsbasierte Infrastruktur zum Schreiben nichtflüchtiger Daten in Datastore

Szenario 4: Platform as a Service (PaaS)

In diesem Szenario verwenden Sie die App Engine-Standardumgebung, die PaaS-Lösung von Google, um eine Anwendung für den Einzelhandel zu erstellen. Die Anwendung wird in unabhängige App Engine-Mikrodienste aufgeteilt, die jeweils ihren eigenen Verantwortungsbereich verwalten: Nutzerprofile, Datensätze der Käufe, Produktinformationen und Kundenservice.

App Engine übernimmt das Autoscaling jedes einzelnen Mikrodienstes und das automatische Load-Balancing zwischen Instanzen. Jeder Mikrodienst wird durch Verwendung der jeweils geeigneten unterstützten Programmiersprache (Java, Python, PHP und Go) implementiert. Jeder Mikrodienst verwendet die standardmäßigen Clientbibliotheken von App Engine für den Zugriff auf Datastore. App Engine speichert die Ergebnisse häufiger Datenbankabfragen in der integrierten Memcached-Komponente. Hierdurch werden Nutzerinteraktionen beschleunigt und Datenbanklasten verringert.

Grafik: Von der App Engine-Standardumgebung, Datastore und Memcached verwaltete Autoscaling-Webanwendung

Abbildung 6. Von der App Engine-Standardumgebung, Datastore und Memcached verwaltete Autoscaling-Webanwendung

Szenario 5: Datenanalyseplattform

In diesem Szenario wird eine Webplattform in zwei Hauptbereiche unterteilt: "Geschäftsvorgänge" und "Geschäftsanalysen". Der Bereich "Geschäftsvorgänge" besteht aus einer Webanwendung, die auf Clientanfragen reagiert. Die Anwendung wird mithilfe der Autoscaling-Gruppe von Compute Engine-Instanzen erstellt. Das Load-Balancing für diese Instanzen wird über den Cloud HTTP(S)-Load-Balancer bewältigt. Die Anwendung liest und schreibt Daten direkt in die Datenbank in Datastore. Snapshots der Datenbank werden täglich erstellt und in Cloud Storage gespeichert.

Der Bereich "Geschäftsanalysen" überwacht die Leistung der Geschäftsvorgänge und bietet entsprechende Einblicke, um zukünftige Verbesserungen zu planen und umzusetzen. Verlaufsdaten werden vom System täglich aus den in Cloud Storage gespeicherten Datenbank-Snapshots in BigQuery geladen. Darüber hinaus werden über Pub/Sub Live-Anwendungslogs von Compute Engine-Instanzen in Echtzeit in BigQuery geladen. Dieses Design bietet Datenanalysten die Möglichkeit, sowohl Verlaufsdaten als auch Live-Daten zu untersuchen und interaktive visuelle Dashboards in Google Data Studio zu laden, die dann von Business-Analysten und anderen Entscheidungsträgern verwendet werden können.

Grafik: Datenanalyseplattform, die sowohl Verlaufsdaten aus Datastore als auch Live-Echtzeitdaten über Pub/Sub verwaltet

Abbildung 7. Datenanalyseplattform, die sowohl Verlaufsdaten aus Datastore als auch Live-Echtzeitdaten über Pub/Sub verwaltet

Szenario 6: Plattform für maschinelles Lernen (ML)

In diesem Szenario bietet eine Onlineshop-Anwendung eine breite Palette von Produkten zum Verkauf an. Die Anwendung wird mithilfe der Autoscaling-Gruppe von Compute Engine-Instanzen erstellt. Das Load-Balancing für diese Instanzen wird über den Cloud HTTP(S)-Load-Balancer bewältigt. Alle Informationen zu Nutzern und Produkten werden in Datastore gespeichert.

Eine ML-Pipeline verwaltet ein Empfehlungssystem, das benutzerdefinierte Werbeaktionen für Nutzer bereitstellt. Verlaufsdaten werden regelmäßig aus Datastore extrahiert und von Dataflow im Batchmodus transformiert. Die transformierten Daten werden in Cloud Storage gespeichert und von AI Platform als Features verwendet, um das Modell des Empfehlungssystems zu trainieren. Jede Iteration des trainierten Modells wird in Cloud Storage gespeichert und in AI Platform geladen, um Live-Werbeangebote zu generieren, die auf der Benutzeroberfläche der Anwendung angezeigt werden. Der gesamte Prozess wird über Apache Airflow auf Compute Engine gesteuert. Data Scientists experimentieren über Datalab mit neuen ML-Modellen.

Grafik: ML-Plattform, die Verlaufsdaten aus Datastore verarbeitet, um Live-Werbeangebote für Nutzer zu generieren

Abbildung 8. ML-Plattform, die Verlaufsdaten aus Datastore verarbeitet, um Live-Werbeangebote für Nutzer zu generieren

Weitere Informationen