Die richtige Architektur für die globale Datenverteilung auswählen

Diese Lösung stellt drei Beispielarchitekturen vor, mit denen Sie Daten auf Google Cloud-Regionen verteilen können.

Viele Unternehmen arbeiten mit Daten aus geografisch verteilten Standorten, wenn sie Clientanfragen nahezu in Echtzeit beantworten. Ein Beispiel ist eine Demand-Side-Plattform (DSP) für digitale Werbung, deren Kunden unabhängig von ihrem geografischen Standort oder der aktuellen Netzwerklast Datenbankantwortzeiten unter 20 Millisekunden erwarten. Die Implementierung einer solchen DSP-Lösung ist aber unrealistisch, wenn die Netzwerkarchitektur auf einer einzigen zentralen Datenbank beruht, die aufgrund der physischen Entfernungen anfällig für Latenzen ist und die häufige Nutzungsspitzen bewältigen muss.

Solche Anforderungen bewältigen Sie am besten mit einer verteilten Architektur für die Datenspeicherung. Nicht jede Architektur ist für die jeweiligen geschäftlichen Anforderungen geeignet, da jede Architektur unterschiedliche Stärken und Schwächen hat. Diese Lösung bietet deshalb verschiedene Google Cloud-Alternativen, um die Umsetzung Ihrer allgemeinen Geschäftsstrategie zu unterstützen und Ihren Ansatz der Netzwerkimplementierung in der Praxis zu realisieren.

Vorteile von Google Cloud

Google Cloud bietet weltweit eine robuste und stabile Netzwerkbandbreite. Außerdem hat Google Cloud viele zusätzliche Vorteile:

Google Cloud ist äußerst flexibel. Sie können damit ein globales virtuelles Netzwerk erstellen, in dem Ihre Anwendungen mithilfe von privaten IP-Adressen sicherer zwischen den Regionen kommunizieren können. Sie haben zum Beispiel die Möglichkeit, Instanzen virtueller Maschinen (VMs) von Compute Engine in zwei Regionen einzurichten, etwa us-central1 und asia-east1. Sie können dabei festlegen, dass diese VM-Instanzen mithilfe privater IP-Adressen direkt miteinander kommunizieren. Dazu erstellen Sie ein VPC-Netzwerk (Virtual Private Cloud). Auf diese Weise kann Ihre Organisation zu einer sicheren Kommunikation zwischen Instanzen beitragen.

Mit einer Google Cloud-Anycast-IP-Adresse wird einem verwalteten Dienst wie dem Load-Balancing eine einzelne globale IP-Adresse zugewiesen. So können Sie mithilfe einer Anycast-IP-Adresse einen einzigen globalen Load-Balancer erstellen, statt Load-Balancer in jeder Region konfigurieren zu müssen. Der globale Load-Balancer leitet Clientanfragen an Anwendungen weiter, die in den nächstgelegenen Regionen ausgeführt werden, und skaliert automatisch, wenn sich die Nachfrage ändert.

Drei Beispiele für Architekturen der Datenverteilung

In diesem Abschnitt werden drei Bereitstellungsarchitekturen erläutert. Dabei wird gezeigt, für welche Konstellation diese jeweils geeignet sind. Es geht um folgende Architekturen und Anwendungsfälle:

  • Hybride Bereitstellung, bestehend aus Google Cloud und lokalen Diensten: Sie möchten einige Dienste lokal verwalten, aber auch die Vorteile von Google Cloud-Features nutzen. Google Cloud ist mit Ihrem aktuellen Netzwerk verknüpft und in Ihre laufenden Unternehmensprozesse eingebunden. Einige oder alle lokalen Daten sind in Google Cloud kopiert oder in Google Cloud eingebunden.

  • Hybride Bereitstellung, bestehend aus Google Cloud und anderen Plattformen von Cloud-Dienstanbietern: Sie möchten die aktuellen Prozesse Ihres derzeitigen Cloud-Dienstanbieters beibehalten, gleichzeitig aber einige Google Cloud-Features einbinden und die beiden Systeme für die Kommunikation miteinander konfigurieren.

  • Google Cloud unter Verwendung mehrerer Regionen: Sie möchten eine nahezu synchrone Datenübertragung vornehmen, wenn möglich im globalen Maßstab. Die Konfiguration von Google Cloud in mehreren Regionen ermöglicht eine extrem schnelle und nahezu gleichzeitige Datenübertragung weltweit.

Hybridbereitstellung: Google Cloud und lokale Dienste

Die Kombination von Google Cloud mit lokalen Diensten eignet sich für Anwendungen, die Daten lokal speichern und darüber hinaus Daten an Google Cloud weitergeben.

In der Einzelhandelsbranche werden z. B. primäre Daten (auch als Stammdaten bezeichnet) über neue Produkte in lokale Datenbanken eines veralteten Inventarverwaltungssystems eingepflegt. Das Unternehmen muss diese Daten eventuell auch an eine Google Cloud-Datenbank weitergeben, die für Web Stores verwendet wird. Mit einem hybriden Ansatz können Sie dafür ein neues System erstellen, das Google Cloud nutzt, ohne das vorhandene lokale System zu beeinträchtigen. In einer solchen Architektur wird Google Cloud im Wesentlichen parallel zu den lokalen Netzwerkstrukturen verwendet.

Bei der Entscheidung über die Implementierung einer hybriden Bereitstellung mit Google Cloud und lokalen Diensten sollten Sie diese Punkte berücksichtigen:

  • Wenn Daten sowohl lokal als auch in Google Cloud verfügbar sind, müssen Sie festlegen, welche dieser Daten als primäre Daten behandelt werden sollen und wo diese primären Daten gespeichert werden. Beispielsweise könnten Sie die Daten in Google Cloud als primäre Daten definieren. In diesem Fall verhält sich Google Cloud wie ein Daten-Hub, der eine oder mehrere lokale Umgebungen verbindet und Daten zwischen ihnen austauscht. Wenn Daten in der Google Cloud-Umgebung hinzugefügt oder aktualisiert wurden, werden sie an lokale Systeme übertragen. Alternativ können lokale Systeme die primären Daten enthalten und Google Cloud regelmäßig aktualisieren.
  • Beachten Sie bei der Entwicklung einer Anwendung für eine solche hybride Umgebung, dass verwaltete Dienste nur für die Ressourcen in Google Cloud verfügbar sind. Anwendungen, die sowohl lokal als auch in der Google Cloud-Umgebung ausgeführt werden, können möglicherweise keine verwalteten Dienste wie automatisierte Sicherung, Redundanz und Skalierbarkeit nutzen.
  • Damit die Daten portabel bleiben und die Verwaltungsvorgänge konsistent sind, ist es eventuell einfacher, plattformübergreifende Datenspeicher, z. B. MySQL, sowohl in der lokalen als auch in der Google Cloud-Bereitstellung auf virtuellen Maschinen zu hosten.

Beispiel für eine hybride Architektur

Das folgende Diagramm veranschaulicht ein Beispiel für eine hybride Architektur mit Google Cloud und lokalen Systemen.

Diagramm: Architektur eines hybriden Systems

Erläuterung der Beispielarchitektur:

  • Es werden Daten zwischen lokalen Dateiservern und Cloud Storage ausgetauscht. Dabei könnte es zum Beispiel darum gehen, lokale Dateien in Google Cloud zu sichern, Eingabedateien im Batch zu verarbeiten oder Dateien aus Google Cloud in lokale Netzwerke herunterzuladen.
  • Benutzerdefinierte Anwendungen in lokalen Rechenzentren verwenden REST APIs, um auf Anwendungen in App Engine zuzugreifen und Daten abzurufen oder zu senden. REST-Anfragen sind in der Regel synchron und blockieren Clients, bis Ergebnisse zurückgegeben werden. In dieser Architektur bietet App Engine eine automatische Skalierung, um die Kapazität je nach Bedarf zu erhöhen. Dadurch soll eine niedrige Latenz für diese synchronen Aufrufe gewährleistet werden.
  • Benutzerdefinierte Anwendungen senden Nachrichten direkt an Pub/Sub, um diese zur späteren Verarbeitung in einer replizierten Warteschlange zu speichern. Wenn bei Pub/Sub Nachrichten eintreffen, gibt Pub/Sub den Status sofort zurück und blockiert die Clients nicht. Die Nachrichten können mithilfe von Cloud Functions und Dataflow sowie mit in Compute Engine ausgeführten Anwendungen und anderen Verfahren asynchron abgerufen und verarbeitet werden. Mit Clientanwendungen in lokalen Umgebungen lassen sich die Nachrichten ebenfalls abrufen.
  • In lokalen Datenbanken gespeicherte Daten werden (eventuell als CSV-Dateien) exportiert und in einem Batchladevorgang in von Cloud SQL verwaltete Datenbanken in Google Cloud hochgeladen.
  • Eine Firebase-Datenbank wird für die Synchronisierung von Daten zwischen lokalen Systemen und Google Cloud verwendet. Anwendungen abonnieren Schlüssel in der Datenbank. Werden die entsprechenden Werte aktualisiert, erhalten die Anwendungen eine Benachrichtigung in Echtzeit und die aktualisierten Werte. Anwendungen, die mit Firebase kommunizieren, können lokal, in Google Cloud oder in beiden Systemen gespeichert sein.

Hybridbereitstellung: Google Cloud und andere Cloud-Anbieter

Sie möchten eventuell Google Cloud mit anderen Cloud-Anbietern kombinieren, um Ihre Daten effektiver verteilen, mehrere Sicherungsverfahren einsetzen oder die Vorteile bestimmter Google Cloud-Features nutzen zu können. Diese Architektur ist empfehlenswert, wenn Sie bereits Produktionsdienste anderer Cloud-Anbieter ausführen, aber die Vorteile von Google Cloud-Features nutzen möchten. Beispielsweise können Sie in einer solchen Architektur mit BigQuery Anwendungsdaten sowie Logs und Monitoring-Messwerte analysieren.

Diese Architektur entspricht der oben beschriebenen hybriden Architektur mit lokalen Diensten und Google Cloud. Bei der Implementierung einer hybriden Bereitstellung mit Google Cloud und anderen Cloud-Anbietern ist Folgendes zu beachten:

  • Mithilfe von Open-Source-Multi-Cloud-Clientbibliotheken wie jclouds und libcloud können Sie die APIs in Google Cloud und in anderen Cloud-Diensten übergreifend nutzen.
  • Google Cloud bietet Module zur Übertragung von Daten aus Amazon Web Services (AWS), z. B. Storage Transfer Service sowie Cloud Monitoring und Cloud Logging. Sie können die Logs zur weiteren Analyse nach BigQuery exportieren.
  • Pub/Sub ist ein globaler Dienst, d. h., für Ihre Anwendungen spielt es keine Rolle, in welcher Region Pub/Sub-Warteschlangen vorhanden sind. Sie können Nachrichten veröffentlichen oder global verfügbare Themen abonnieren. Bei Google Cloud müssen Clientanwendungen nur einen einzigen Satz von IP-Adressen und Ports berücksichtigen. Bei anderen Cloud-Anbietern sind Warteschlangen möglicherweise auf eine Region beschränkt. Wenn Sie in einem solchen Fall Anwendungen für mehrere Regionen entwickeln, müssen die Clientanwendungen die Endpunkte für jede Region kennen. Den Überblick über Endpunkte zu behalten, kann aber mühsam sein, insbesondere wenn Sie Dienste aus neuen Regionen hinzufügen.

Beispielarchitektur für Google Cloud in Kombination mit einem anderen Cloud-Anbieter

Das folgende Diagramm veranschaulicht eine hybride Architektur mit der GCP und anderen Cloudanbietern.

Diagramm: Architektur eines Systems mit Google Cloud und einem anderen Cloud-Anbieter

Erläuterung der Beispielarchitektur:

  • Nachrichten werden zwischen Pub/Sub und anderen öffentlichen Clouds ausgetauscht. Pub/Sub stellt einen globalen Endpunkt bereit. Es kann so als Nachrichten-Hub zwischen Clouds verwendet werden, da es für Anwendungen unerheblich ist, in welcher Region sich die Nachrichtenwarteschlangen tatsächlich befinden.
  • Es werden Cloud Monitoring-Instanzen auf virtuellen Maschinen anderer öffentlicher Clouds installiert, um Messwerte zur CPU-Auslastung, Arbeitsspeichernutzung, Informationsverarbeitung usw. zu erfassen. Cloud Monitoring überwacht die Ressourcennutzung in hybriden Cloud-Umgebungen.
  • Benutzerdefinierte Anwendungen, die auf virtuellen Maschinen in anderen Cloud-Umgebungen ausgeführt werden, verwenden REST APIs, um in App Engine gehostete Anwendungen zum Senden oder Abrufen von Daten aufzurufen.
  • Storage Transfer Service überträgt auf Anforderung oder regelmäßig Dateien direkt von Amazon S3. Übertragene Dateien können in Compute Engine verarbeitet werden, um sie in Cloud SQL zu laden.

Hybridbereitstellung: Google Cloud mit mehreren Regionen

Eine Architektur, die auf Google Cloud in mehreren Regionen beruht, ist eine gute Wahl, wenn Ihre Anwendung für Nutzer global bereitgestellt wird und Daten zwischen Regionen mit minimaler Latenz synchronisiert werden müssen. Ein Beispiel hierfür ist etwa ein internetfähiges Videospiel, dessen Spieleraktionen weltweit nahezu in Echtzeit synchronisiert werden müssen, damit es funktioniert.

Diese Architektur nutzt die Vorteile von mit Google Cloud verwalteten Diensten, um den Administrationsaufwand zu reduzieren und das Systemdesign zu vereinfachen. Mit Google Cloud können Sie Ihr Augenmerk auf Ihre Anwendungen richten, ohne Zeit für das Infrastrukturdesign aufwenden zu müssen. Bei der Implementierung einer hybriden Google Cloud-Bereitstellung in mehreren Regionen ist Folgendes zu beachten:

  • Sie können problemlos regionsübergreifende Datenverarbeitungsdienste implementieren, da sich Nachrichten-Publisher und -abonnenten in jeder Region ausführen lassen. Mit Pub/Sub können Sie Nachrichten zwischen Anwendungen austauschen, die in verschiedenen Regionen ausgeführt werden, ohne angeben zu müssen, in welcher Region die Anwendung ausgeführt wird. Die Pub/Sub-Nachrichten verbleiben in dieser Architektur vollständig innerhalb von Google Cloud und werden nicht über das Internet gesendet. Dadurch wird eine geringere Latenz garantiert.
  • Anwendungen in Compute Engine-Instanzen können direkt über Regionen hinweg kommunizieren, mithilfe privater IP-Adressen in einem Google Cloud-VPC-Netzwerk.
  • Sie haben die Möglichkeit, benutzerdefinierte Anwendungen mit REST APIs locker miteinander zu verknüpfen. Da sich die Architektur vollständig in der Google Cloud-Umgebung befindet, können Sie mit App Engine Anwendungen verwalten, bei denen nur geringfügige administrative Aufgaben zu erwarten sind.
  • Nachdem Sie Daten über Regionen verteilt haben, können Sie ETL (Extract, Transform, Load)- oder Analysearbeitslasten mit Dataflow oder Dataproc verarbeiten.

Beispiel für eine multiregionale Google Cloud-Architektur

Das folgende Diagramm veranschaulicht die Architektur einer Google Cloud-Bereitstellung mit mehreren Regionen.

Diagramm: Architektur eines Systems mit mehreren Google Cloud-Regionen

Erläuterung der Beispielarchitektur:

  • Wie bei der hybriden Cloud-Architektur überwacht Cloud Monitoring alle Rechenressourcen und zeigt eine konsolidierte globale Ansicht der Ressourcennutzung an. Die erfassten Logs und Messwerte werden zur weiteren Analyse nach BigQuery exportiert.
  • Wie bei der hybriden Cloud-Architektur wird Pub/Sub als Nachrichten-Hub verwendet. Pub/Sub ermöglicht unabhängig vom tatsächlichen Ausführungsort der Anwendung eine lockere Verknüpfung von Diensten.
  • Benutzerdefinierte Anwendungen, die in App Engine oder Compute Engine ausgeführt werden, tauschen mithilfe von REST APIs direkt Nachrichten mit anderen benutzerdefinierten Anwendungen aus. Dies ermöglicht eine enger gekoppelte Architektur als die hybride Architektur und daher eine besser vorhersehbare Latenz.
  • Storage Transfer Service wird zum Synchronisieren von Cloud Storage-Buckets verwendet. Alternativ kann das gsutil-Tool für On-Demand-Übertragungen zwischen Buckets über Regionen hinweg genutzt werden.

Weitere Informationen

Mehr über die Datenverwaltung in Google Cloud erfahren Sie unter den folgenden Links: