Multiregionale Bereitstellungen für API Gateway erstellen

In dieser Anleitung erfahren Sie, wie Sie einen HTTP(S)-Load-Balancer konfigurieren, um multiregionale Bereitstellungen für API Gateway zu aktivieren.

Die Erstellung eines HTTP(S)-Load-Balancers zur Unterstützung von API Gateway-Bereitstellungen in mehreren Regionen kann die Verfügbarkeit Ihres Dienstes verbessern und die Latenzzeit verringern, indem er von mehr als einer Region aus bedient wird. Mit regionenübergreifendem Routing können Sie die Latenz weiter minimieren und die Verfügbarkeit maximieren. Dadurch werden Anfragen aus der verfügbaren Region verarbeitet, die Ihrem Nutzer am nächsten ist.

Für die Zwecke dieser Anleitung konfigurieren Sie ein einzelnes, nicht regionales URL-Schema, das überall auf der Welt funktioniert, aber Nutzeranfragen über die nächstgelegene API Gateway-Bereitstellung bedient. Mit dieser Konfiguration werden Anfragen idealerweise an die Region weitergeleitet, die dem Nutzer eine minimale Latenz bietet. Falls die nächstgelegene Region nicht verfügbar ist oder die Kapazität überschreitet, wird die Anfrage zu einer anderen Region geleitet, um die Verfügbarkeit zu gewährleisten.

Hinweise

Bevor Sie Ihre multiregionale Bereitstellung konfigurieren, folgen Sie der API Gateway-Kurzanleitung, um einen Cloud Run-Dienst bereitzustellen und ein Gateway zu erstellen, das auf diesen Dienst verweist.

In dieser Anleitung stellen Sie Ihren Dienst in zwei verschiedenen Regionen bereit. Sie können beispielsweise zwei API Gateway-Instanzen bereitstellen:

my-gateway-eu in einer Region in Europa
my-gateway-us in einer Region in den USA

Berechtigungen konfigurieren

In dieser Anleitung werden Sie eine serverlose Netzwerkendpunktgruppe (NEG) und einen externen HTTP(S)-Loadbalancer in einem Cloud-Projekt erstellen. Dies erfordert entweder die Rolle Inhaber oder Bearbeiter des Projekts oder die folgenden IAM-Rollen für Compute Engine:

Aufgabe	Erforderliche Rolle
Load-Balancer und Netzwerkkomponenten erstellen	Netzwerkadministrator
NEGs erstellen und ändern	Compute-Instanzadministrator
SSL-Zertifikate erstellen und ändern	Sicherheitsadministrator

SSL-Zertifikatsressource erstellen

Zum Erstellen eines HTTPS-Load-Balancers muss dem Frontend des Load-Balancers eine SSL-Zertifikatsressource hinzugefügt werden. Erstellen Sie eine SSL-Zertifikatsressource mit einem von Google verwalteten SSL-Zertifikat oder mit einem selbst verwalteten SSL-Zertifikat.

Von Google verwaltete Zertifikate. Es empfiehlt sich, von Google verwaltete Zertifikate zu verwenden, da Google Cloud diese Zertifikate automatisch abruft, verwaltet und verlängert. Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain und die zugehörigen DNS-Einträge, damit das Zertifikat bereitgestellt werden kann. Wenn Sie noch keine Domain haben, können Sie eine von Google Domains erhalten. Außerdem müssen Sie den DNS-A-Eintrag der Domain so aktualisieren, dass er auf die IP-Adresse des Load-Balancers verweist, die in einem späteren Schritt erstellt wird. Eine ausführliche Anleitung finden Sie unter Von Google verwaltete Zertifikate verwenden.
Selbst signierte Zertifikate. Wenn Sie derzeit keine Domain einrichten möchten, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.

In dieser Anleitung wird davon ausgegangen, dass Sie bereits eine SSL-Zertifikatsressource erstellt haben.

Wenn Sie diesen Prozess testen möchten, ohne eine SSL-Zertifikatsressource bzw. eine Domain (für von Google verwaltete Zertifikate erforderlich) zu erstellen, folgen Sie der Anleitung auf dieser Seite, um stattdessen einen HTTP-Load-Balancer einzurichten.

HTTP(S)-Load-Balancer erstellen

Erstellen Sie für jede API Gateway-Instanz eine serverlose NEG.

Eine Netzwerk-Endpunktgruppe (NEG) ist eine Gruppe von Backend-Endpunkten für einen Load-Balancer. Eine serverlose NEG ist ein Backend, das auf einen Dienst wie API Gateway verweist, wie in der folgenden Abbildung dargestellt:

Führen Sie den folgenden Befehl aus, um für jede Gateway-Instanz eine serverlose NEG zu erstellen. Dabei gilt:
- SERVERLESS_NEG_NAME ist der Name der serverlosen NEG, die erstellt werden soll.
- GATEWAY_ID gibt den Namen des Gateways an.
- REGION_ID ist die Bereitstellungsregion für die serverlose NEG. Diese sollte mit der Gateway-Region übereinstimmen.
```
gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
  --region=REGION_ID \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID
```
Beispiel:
```
gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg-eu \
  --region=europe-west1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway-eu
```
Wiederholen Sie diesen Befehl, um eine serverlose NEG für die nächste Gateway-Instanz zu erstellen. Verwenden Sie dazu die entsprechenden Werte für die zweite Gateway-Instanz, z. B. api-gateway-serverless-neg-us für my-gateway-us in der Region us-central1.
Erstellen Sie einen Backend-Dienst, um zu definieren, wie Cloud Load Balancing den Traffic verteilt.

Die Konfiguration des Backend-Dienstes enthält eine Reihe von Werten, z. B. das Protokoll, das für die Verbindung zu Backends verwendet wird, verschiedene Verteilungs- und Sitzungseinstellungen, Zustandsprüfungen und Zeitüberschreitungen, wie in der folgenden Abbildung dargestellt:

Führen Sie die folgenden Befehle aus, um einen Back-End-Dienst zu erstellen und ihm Ihre serverlose NEG als Back-End hinzuzufügen. Dabei gilt:
- BACKEND_SERVICE_NAME ist der Name Ihres Backend-Dienstes.
- SERVERLESS_NEG_NAME ist der Name der serverlosen NEG, die im vorherigen Schritt erstellt wurde.
- REGION_ID ist die Bereitstellungsregion für die serverlose NEG. Diese sollte mit der Gateway-Region übereinstimmen.
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --global \ 
```
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME \
  --network-endpoint-group-region=REGION_ID
```
Beispiel:
```
gcloud compute backend-services add-backend api-gateway-backend-service \
  --global \
  --network-endpoint-group=api-gateway-serverless-neg-eu \
  --network-endpoint-group-region=europe-west1
```
Wiederholen Sie diesen Befehl, um dem Backend-Dienst die zweite serverlose NEG hinzuzufügen. Verwenden Sie dazu die entsprechenden Werte für die zweite serverlose NEG, z. B. api-gateway-serverless-neg-us für my-gateway-us in der Region us-central1.
Erstellen Sie eine URL-Zuordnung, um eingehende Anfragen wie in der folgenden Abbildung an den Backend-Dienst weiterzuleiten:

Führen Sie den folgenden Befehl aus, um die URL-Zuordnung zu erstellen. Dabei gilt:
- URL_MAP_NAME ist der Name der zu erstellenden URL-Zuordnung.
- BACKEND_SERVICE_NAME ist der Name Ihres Backend-Dienstes.
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME
```
Beispiel:
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
Diese beispielhafte URL-Zuordnung zielt nur auf einen Backend-Dienst ab, der ein einzelnes Gateway repräsentiert, sodass keine Hostregeln oder Pfadabgleiche erforderlich sind. Wenn Sie mehr als einen Backend-Dienst haben, können Sie Host-Regeln verwenden, um Anfragen auf der Grundlage des Host-Namens an verschiedene Dienste weiterzuleiten. Verwenden Sie Pfad-Matcher, um Anfragen basierend auf dem Anfragepfad zu verschiedenen Diensten weiterzuleiten.

Beispiel:
```
gcloud compute url-maps add-path-matcher api-gateway-url-map \
  --path-matcher-name=my-pm2  \
  --default-service=my-host-default-backend \
  --path-rules="/video=video-service,/video/*=video-service" \
  --new-hosts my-hosts.com
```
```
gcloud compute url-maps add-host-rule api-gateway-url-map \
  --hosts=my-app-domain \
  --path-matcher-name=my-app-path-matcher
```
Weitere Informationen zu Hostregeln und Pfad-Matchern finden Sie in der Dokumentation zu URL-Zuordnungen.
Erstellen Sie ein SSL-Zertifikat für Ihren Zielproxy, wie in der folgenden Abbildung dargestellt:

Zum Erstellen eines HTTPS-Load-Balancers ist für den HTTPS-Zielproxy eine SSL-Zertifikatsressource erforderlich. Sie können eine SSL-Zertifikatsressource entweder mit einem von Google verwalteten SSL-Zertifikat oder mit einem selbst verwalteten SSL-Zertifikat erstellen. Es empfiehlt sich, von Google verwaltete Zertifikate zu verwenden.

Zum Erstellen eines von Google verwalteten Zertifikats benötigen Sie eine Domain. Wenn Sie keine Domain haben, können Sie ein selbst signiertes SSL-Zertifikat zu Testzwecken verwenden.

So erstellen Sie eine von Google verwaltete SSL-Zertifikatsressource:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN
```
So erstellen Sie eine selbstverwaltete SSL-Zertifikatressource:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate CRT_FILE_PATH \
  --private-key KEY_FILE_PATH
```
Erstellen Sie einen HTTP(S)-Zielproxy, um Anfragen an Ihre URL-Zuordnung weiterzuleiten, wie in der folgenden Abbildung dargestellt:

Erstellen Sie den Zielproxy mit dem folgenden Befehl. Dabei gilt:
- TARGET_HTTP_PROXY_NAME ist der Name des zu erstellenden Zielproxys.
- URL_MAP_NAME ist der Name der URL-Zuordnung, die in einem vorherigen Schritt erstellt wurde.
- Optional: SSL_CERT_NAME ist der Name des erstellten SSL-Zertifikats.
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME
  --url-map=URL_MAP_NAME
```
Beispiel:
```
gcloud compute target-http-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert
  --url-map=api-gateway-url-map
```
Erstellen Sie eine Weiterleitungsregel, um eingehende Anfragen an den Proxy weiterzuleiten, wie in der folgenden Abbildung dargestellt:

Verwenden Sie den folgenden Befehl, um die Weiterleitungsregel zu erstellen. Dabei gilt:
- HTTPS_FORWARDING_RULE_NAME ist der Name der zu erstellenden Regel.
- TARGET_HTTP_PROXY_NAME ist der Name des zu erstellenden Zielproxys.
```
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443
```
Beispiel:
```
gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443
```

DNS-Einträge mit IP-Adresse des Load-Balancers aktualisieren

Wenn Sie eine benutzerdefinierte Domain haben, müssen Sie diesen Schritt einrichten, um die DNS-Einstellungen für Ihre Domain so einzurichten, dass sie auf die neue IP-Adresse Ihres Dienstes verweisen. Dies ist auch erforderlich, wenn Sie einen HTTP(S)-Load-Balancer mit einem von Google verwalteten Zertifikat erstellt haben, das eine Domain erfordert. Bei Verwendung mit DNS wird eine statische IP-Adresse zugewiesen und verwendet. Die genaue Anleitung für diesen Schritt hängt von Ihrem DNS-Anbieter ab

Zum Senden von Traffic an den Load-Balancer muss der DNS-Eintrag Ihrer Domain (in dieser Anleitung "my-app-domain") auf die IP-Adresse(n) des Load-Balancers verweisen.

Ermitteln Sie die IP-Adresse Ihrer globalen Weiterleitungsregel mit dem folgenden Befehl:
```
gcloud compute forwarding-rules list
```
Aktualisieren Sie den DNS-A-Eintrag Ihrer Domain so, dass er auf die IP-Adresse des Load-Balancers verweist. Dann wird Traffic, der an die vorhandene benutzerdefinierte Domain-URL gesendet wird, stattdessen über den Load-Balancer weitergeleitet. Es kann nur wenige Sekunden oder mehrere Stunden dauern, bis DNS diese Änderung an den DNS-Server weitergibt.
Testen Sie, ob das Gateway Traffic empfängt. Verwenden Sie dazu curl oder rufen Sie die URL in Ihrem Browser auf. Beispiel: https://my-app-domain

Beim Testen sollte die vom Cloud Run-Dienst generierte Antwort angezeigt werden. Es kann sich beispielsweise um eine HTML-Seite "Hello World" oder eine andere erwartete Antwort handeln, die direkt vom Backend-Dienst generiert wird. Dies bedeutet, dass Ihre Anfrage den Load-Balancer durchläuft und der Backend-Dienst den Load-Balancer anweist, ihn an Ihr Gateway zu senden.

Hinweise

Berücksichtigen Sie vor der Implementierung einer multiregionalen Bereitstellung von API Gateway Folgendes:

API Gateway unterstützt derzeit keine Systemdiagnosen. Mit der oben beschriebenen regionsübergreifenden Routing-Konfiguration wird Ihr HTTP(S)-Loadbalancer den Traffic nicht in andere Regionen umleiten, wenn Ihr Gateway oder sein Backend-Dienst in einer Region Fehler zurückgibt, die gesamte API Gateway-Infrastruktur in der Region jedoch verfügbar ist und über Kapazität verfügt.
Wenn Sie verschiedene Regionen in einer Weiterleitungsregel kombinieren möchten, sind die Preise für die Premiumstufe erforderlich. Weitere Informationen zur Berechnung von Preisen und Nutzung finden Sie unter Preise für Netzwerkdienststufen.

Best Practices

Beim Einsatz von multiregionaler Bereitstellung empfehlen wir die Verwendung einer global replizierten verwalteten Datenspeicherlösung wie Cloud Spanner, damit alle Daten global verwaltet werden.