Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Best Practices für App Engine-Netzwerke

Auf dieser Seite werden die Best Practices für die Konfiguration von Netzwerkoptionen für App Engine-Ressourcen erläutert. Wir empfehlen Ihnen, alle Abschnitte auf dieser Seite zu lesen, um die von App Engine unterstützten Netzwerkoptionen und ihre Auswirkungen zu verstehen.

Best Practices:

IP-Adressverwaltung
IP-Adressnutzung überwachen
IP-Adressen außerhalb von RFC 1918 verwenden.
IPv4- und IPv6-Subnetze (Dual-Stack) verwenden.
Verbindungs-Pooling verwenden und Verbindungen wiederverwenden.
Unterstützte Laufzeiten verwenden
Schnellerer externer Durchsatz zum Internet.
Schnellerer interner Durchsatz zu einer Google API.

IP-Verwaltung

Sie müssen Ihre IP-Adressen verwalten, da jede Instanz Ihres App Engine-Dienstes IP-Adressen aus Ihrem Subnetz belegt. Verwenden Sie die folgenden Strategien, um Ihre IP-Adressen zu verwalten:

Alternative IP-Zuweisung: Weisen Sie standardmäßige private Bereiche oder alternative IP-Bereiche zu, um die Erschöpfung von IP-Adressen zu vermeiden. Weitere Informationen finden Sie unter Strategien für die Erschöpfung von IP-Adressen.
Subnetzgröße: Der IPv4-Adressbereich Ihres Subnetzes muss mindestens /26 betragen, damit genügend IP-Adressen für die Skalierung vorhanden sind.
IP-Adressen überdimensionieren: Wir empfehlen, die Anzahl der verfügbaren IP-Adressen in Ihrem Subnetz zu überdimensionieren, um eine Erschöpfung zu vermeiden. Ähnlich wie bei anderen App Engine-Diensten sollten Sie in der Regel viermal so viele IP-Adressen (zweimal für den stabilen Zustand und zweimal während der Bereitstellung) wie die Anzahl der ausgeführten Instanzen verwenden, um eine reibungslose Skalierung und Aktualisierung zu ermöglichen.

IP-Adressnutzung überwachen

Wenn Sie ausgehenden Direct VPC-Traffic verwenden, müssen Sie Ihrem Subnetz genügend IP-Adressen zuweisen. Die Anzahl der verwendeten IP-Adressen hängt von der Anzahl der Instanzen ab, auf denen Ihre Arbeitslasten ausgeführt werden. Wir empfehlen daher, die Verwendung Ihrer IP-Adressen zu überwachen. Achten Sie darauf, dass Ihre IP-Nutzung im Laufe der Zeit innerhalb der vom Subnetz unterstützten Grenzen bleibt.

So schätzen Sie die Nutzung Ihrer IP-Adressen:

Rufen Sie in der Google Cloud Console die Seite „Metrics Explorer“ auf:

Zum Metrics Explorer
Suchen Sie die Anzahl der Instanzen in Ihrem Projekt mithilfe des Messwerttyps appengine.googleapis.com/system/instance_count. Mit diesem Messwert werden alle App Engine-Instanzen im Projekt gezählt. Filtern Sie bei Versionen, die mit ausgehendem Direct VPC-Traffic konfiguriert sind, nach dem Label module_id, das den Dienst identifiziert, oder nach dem Label version_id. Mit Cloud Monitoring können Sie den Wert dieses Messwerts im Zeitverlauf ansehen.
Multiplizieren Sie den Wert des Messwerts für die Instanzanzahl mit 2, um eine Schätzung der Anzahl der verwendeten IP-Adressen zu erhalten.

Strategien zur Vermeidung von IP-Adressmangel

Eine große Anzahl von App Engine-Arbeitslasten kann zu Problemen mit der IP-Erschöpfung führen, wenn der private RFC 1918-IP-Adressbereich mit ausgehendem Direct VPC-Traffic verwendet wird. Mit den folgenden Strategien können Sie die Erschöpfung von IP-Adressen durch die Verwendung alternativer IP-Adressbereiche verwalten.

IPv4-Adressen außerhalb von RFC 1918 verwenden

Neben den RFC 1918-IPv4-Adressbereichen unterstützt App Engine auch die Bereiche RFC 6598 und Klasse E/RFC 5735. AlleGoogle Cloud -Dienste und -Funktionen funktionieren mit diesen Nicht-RFC-1918-Bereichen, einschließlich VPC-Netzwerken, Cloud Load Balancing und Private Service Connect.

Für eine optimale Kompatibilität empfehlen wir, mit dem RFC 6598-Bereich (100.64.0.0/10) zu beginnen. Wenn Sie diesen Bereich bereits an anderer Stelle verwenden, sollten Sie stattdessen Klasse E/RFC 5735 (240.0.0.0/4) in Betracht ziehen. Klasse E ist ein riesiger Bereich mit über 268 Millionen verfügbaren IP-Adressen, der Ihr Wachstum für lange Zeit unterstützen wird. Für die Klasse E gelten jedoch einige Einschränkungen. Es wird beispielsweise unter Windows und auf einigen lokalen Hardwaregeräten nicht unterstützt. IPv4-Adressraum der Klasse E nutzen, um Probleme mit der IPv4-Erschöpfung in GKE zu beheben

Cloud NAT oder Private Service Connect verwenden

Wenn sich Ihre App Engine-Arbeitslast in einem Bereich außerhalb des RFC 1918-Bereichs befindet und ein lokales Ziel erreichen muss, das nur RFC 1918 akzeptiert, wählen Sie eine der folgenden Lösungen:

Verwenden Sie Hybrid NAT, um die Adressübersetzung und den ausgehenden Traffic über einen kleinen RFC 1918-Bereich durchzuführen.
Stellen Sie den lokalen Dienst als Private Service Connect-Hybriddienst bereit.

IPv4- und IPv6-Subnetze (Dual-Stack) verwenden

Auch wenn dadurch die IPv4-Erschöpfung nicht verringert wird, sollten Sie Ihre Anwendungen auf IPv6 umstellen. Um Probleme mit der IPv4-Erschöpfung in Zukunft zu vermeiden, richten Sie Dual-Stack-Ressourcen ein.

Strategien zur Reduzierung der Portauslastung

Im folgenden Abschnitt werden Strategien zur Reduzierung der Port-Erschöpfung mit App Engine beschrieben.

Verbindungs-Pooling verwenden und Verbindungen wiederverwenden

Wenn Sie eine große Anzahl von Anfragen von Ihrer App Engine-Anwendung an eine einzelne Ziel-IP-Adresse senden, verwenden Sie Verbindungs-Pooling, um Verbindungen zum Ziel aufrechtzuerhalten und wiederzuverwenden. Hohe Verbindungsraten zu einer einzelnen IP-Adresse können ausgehende Ports erschöpfen und Fehler vom Typ „Verbindung abgelehnt“ verursachen.

Leistungs- und Durchsatzstrategien

In diesem Abschnitt werden skalierbare Optionen zur Verbesserung der Netzwerkleistung und des Durchsatzes zum Internet und zu Google-Diensten behandelt.

Unterstützte Laufzeiten verwenden

Ausgehender Direct VPC-Traffic wird nur für Standardlaufzeiten der zweiten Generation unterstützt. Unterstützte Laufzeiten führen Standardsprachimplementierungen aus, unterstützen moderne Bibliothekseinbindungen und bieten eine schnellere, robustere Netzwerkleistung.

Ausgehenden Direct VPC-Traffic für schnelleren ausgehenden Netzwerkdurchsatz verwenden

Um einen schnelleren Durchsatz für ausgehende Netzwerkverbindungen zu erreichen, können Sie ausgehenden Direct VPC-Traffic nutzen, um den Traffic über Ihr VPC-Netzwerk zu leiten.

Beispiel 1: Externer Traffic zum Internet

Wenn Sie externen Traffic an das öffentliche Internet senden, leiten Sie den gesamten Traffic über das VPC-Netzwerk weiter. Setzen Sie dazu in der Datei app.yaml das Feld vpc_egress auf all-traffic. Bei diesem Ansatz müssen Sie Cloud NAT einrichten, um das öffentliche Internet zu erreichen.

Informationen zum Einrichten von Cloud NAT für Ihren App Engine-Dienst finden Sie unter Statische ausgehende IP-Adresse einrichten. Informationen zu den Cloud NAT-Gateway-Einstellungen, die mit ausgehendem Direct VPC-Traffic für Public NAT oder Private NAT verwendet werden sollen, finden Sie unter Interaktionen mit ausgehendem Direct VPC-Traffic von Cloud NAT.

Beispiel 2: Interner Traffic zu einer Google API

Wenn Sie ausgehenden Direct VPC-Traffic verwenden, um Traffic an eine Google API wie Cloud Storage zu senden, wählen Sie eine der folgenden Optionen:

Geben Sie private-ranges-only (Standard) mit Privater Google-Zugriff an:
1. Legen Sie vpc_egress: private-ranges-only in Ihrer app.yaml-Datei fest.
2. Privaten Google-Zugriff aktivieren
3. DNS für den privaten Google-Zugriff konfigurieren Achten Sie darauf, dass Ihre Zieldomain (z. B. storage.googleapis.com) einem der folgenden internen IP-Adressbereiche zugeordnet ist:
  - 199.36.153.8/30
  - 199.36.153.4/30
Geben Sie all-traffic mit privatem Google-Zugriff an:
1. Legen Sie vpc_egress: all-traffic in Ihrer app.yaml-Datei fest.
2. Privaten Google-Zugriff aktivieren

Standard-MTU-Einstellung für App Engine verwenden

Ändern Sie die Einstellung für die maximale Übertragungseinheit (MTU) eines VPC-Netzwerk nicht, wenn Sie es mit App Engine verwenden. Verwenden Sie stattdessen die Standard-MTU von 1.460 Byte.

Kostengesichtspunkte

Beachten Sie beim Konfigurieren der Netzwerkoptionen für Ihre Ressourcen Folgendes:

Ressourcen am selben Ort platzieren: Versuchen Sie, Ihre App Engine-Ressourcen in derselben Region wie Ihre Backend-Datenbanken bereitzustellen, z. B. Cloud SQL-, Firestore- und Cloud Storage-Buckets. Die Datenübertragung zwischen Google Cloud -Ressourcen innerhalb derselben Region ist kostenlos.
Zu Direct VPC-Traffic wechseln: Wenn Sie Traffic sicher an interne VPC-Netzwerkressourcen weiterleiten, sollten Sie von Connectors für Serverloser VPC-Zugriff zu Direct VPC-Traffic wechseln. Für ausgehenden Direct VPC-Traffic fallen keine grundlegenden Compute-Gebühren an. Dadurch entfallen die grundlegenden Compute-Overhead- und Leerlaufkosten, die mit Connector-Instanzen verbunden sind.
Cloud CDN verwenden: Lagern Sie statische Assets und gut cachefähige Inhalte aus, indem Sie Cloud CDN vor Ihren App Engine-Ressourcen platzieren. Die Bereitstellung von Daten über den Edge-Standort ist deutlich günstiger als die Bezahlung für ausgehenden Internet-Traffic direkt von App Engine. Sie können Cloud CDN nicht direkt für die Standard-URL appspot.com aktivieren. Leiten Sie Anfragen stattdessen über einen externen Application Load Balancer mit einem serverlosen NEG-Backend (Netzwerk-Endpunktgruppe) weiter. Weitere Informationen finden Sie unter Globalen externen Application Load Balancer mit App Engine einrichten.
Ausgehenden Internet-Traffic überwachen: Für ausgehenden Traffic, der Regionsgrenzen überschreitet oder ins öffentliche Internet geleitet wird, fallen Standardgebühren an. Konzentrieren Sie sich beim Monitoring auf ausgehenden Traffic, der die Grenzen der Region überschreitet.

Weitere Informationen finden Sie unter App Engine-Preise. Sie können die Kosten auch mit dem Preisrechner schätzen.

Best Practices für App Engine-Netzwerke Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.