Private Verbindungen für RAG-fähige generative KI-Anwendungen

In diesem Dokument wird eine Referenzarchitektur vorgestellt, mit der Sie die Netzwerkinfrastruktur für Anwendungen mit Retrieval Augmented Generation (RAG) schützen können. Eine RAG-Architektur enthält in der Regel separate Subsysteme für die Verarbeitung von Daten und den Abruf von Inhalten. In dieser Referenzarchitektur wird gezeigt, wie Sie mit einer freigegebene VPC Folgendes tun können:

  • Trennen Sie die Subsysteme mithilfe von IAM-Berechtigungen (Identity and Access Management).
  • Verbinden Sie die Anwendungskomponenten über private IP-Adressen.

Die Zielgruppe für dieses Dokument umfasst Architekten, Entwickler sowie Netzwerk- und Sicherheitsadministratoren. In diesem Dokument wird davon ausgegangen, dass Sie Grundkenntnisse im Bereich Networking haben. In diesem Dokument wird nicht beschrieben, wie eine RAG-basierte Anwendung erstellt wird.

Architektur

Das folgende Diagramm zeigt die in diesem Dokument beschriebene Netzwerkarchitektur:

Netzwerkarchitektur für Anwendungen mit RAG. Verbindungen und Traffic-Fluss für die Netzwerkarchitektur.

Die Architektur im vorherigen Diagramm besteht aus folgenden Komponenten:

Komponente Zweck
Externes Netzwerk, entweder lokal oder in einer anderen Cloud
  • Bietet Netzwerkverbindungen für Data Engineers, die RAG-Rohdaten hochladen.
  • Beendet die Verbindung zu externen Netzwerken.
  • Hostet externe Router.
  • Stellt die Verbindung zum Private Service Connect-Endpunkt im VPC-Netzwerk Google Cloud routing Google Cloud her.
  • Enthält DNS-Server, die auf den Private Service Connect-Endpunkt verweisen.
Routing-Projekt
  • Hostet das Routing-VPC-Netzwerk, das über eine Cloud Interconnect- oder HA VPN-Verbindung mit dem externen Netzwerk verbunden ist.
  • Hostet einen Network Connectivity Center-Hub, der das externe Netzwerk, das Routing-VPC-Netzwerk und die freigegebene VPC-Netzwerke miteinander verbindet.
  • Hostet einen Private Service Connect-Endpunkt, der eine Verbindung zu einem regionalen Cloud Storage-Endpunkt herstellt. Mit diesem Endpunkt können Data Engineers RAG-Daten in den Cloud Storage-Bucket hochladen.
RAG-Hostprojekt mit freigegebener VPC Hostet ein freigegebene VPC-Netzwerk, das den Load Balancer für den Frontend-Dienst und alle anderen Dienste hostet, die ein VPC-Netzwerk benötigen. Alle Dienstprojekte haben Zugriff auf dieses freigegebene VPC-Netzwerk.
Dienstprojekt für die Datenaufnahme

Enthält einen Cloud Storage-Bucket für die Eingabe von Rohdaten. Enthält das Subsystem für die Datenerfassung, das die folgenden Komponenten umfasst:

  • Verarbeitung der Aufnahme: Liest Rohdaten und verarbeitet sie.
  • Aufnahmeausgabe: Schreibt in den endgültigen Datenspeicher.
Dienstprojekt für die Bereitstellung

Enthält das Serving-Subsystem, das die folgenden Komponenten umfasst, die die Dienste und Funktionen für Inferenz und Interaktion bereitstellen:

  • RAG-Datenspeicher, der die Ausgabe des Datenaufnahmesubsystems enthält.
  • Bereitstellungsprozesse, die das Modell mit Daten aus dem RAG-Datenspeicher füttern, indem sie die Inferenzanfrage mit diesen Daten kombinieren.
  • Das Modell, das vom Serving-Subsystem verwendet wird, um Vektoren aus den hochgeladenen RAG-Daten zu erstellen und die Endnutzeranfrage zu verarbeiten.
Frontend-Dienstprojekt

Enthält das Serving-Subsystem, das ein Load Balancer vor einem Dienst für Nutzerinteraktionen ist, der in Cloud Run oder Google Kubernetes Engine (GKE) ausgeführt wird.

Das Projekt enthält auch Google Cloud Armor, mit dem der Zugriff auf Ihren Dienst eingeschränkt werden kann. Wenn Sie Zugriff aus dem Internet ermöglichen möchten, können Sie einen regionalen externen Application Load Balancer hinzufügen.
VPC Service Controls-Perimeter Schutz vor Daten-Exfiltration Daten, die in Cloud Storage-Buckets gespeichert sind, können nicht an einen Ort außerhalb des Perimeters kopiert werden. Steuerungsebenevorgänge sind geschützt.

In den folgenden Abschnitten werden die Verbindungen und Traffic-Flüsse in der Architektur beschrieben.

Verbindungen zwischen Komponenten

In diesem Abschnitt werden die Verbindungen zwischen den Komponenten und Netzwerken in dieser Architektur beschrieben.

Externes Netzwerk zum Routing-VPC-Netzwerk

Die externen Netzwerke werden über Cloud Interconnect oder HA VPN mit dem Google Cloud Routing-VPC-Netzwerk verbunden. Dabei handelt es sich um Hybrid-Spokes eines Network Connectivity Center-Hubs.

Cloud Router im Routing-VPC-Netzwerk und die externen Router im externen Netzwerk tauschen BGP-Routen (Border Gateway Protocol) aus:

  • Router in externen Netzwerken geben die Routen für externe Subnetze an den Cloud Router des Routing-VPC-Netzwerks weiter. Sie können die bevorzugten Routen mithilfe von BGP-Messwerten und ‑Attributen angeben.
  • Cloud Router im Routing-VPC-Netzwerk bewerben die Routen für Präfixe in den VPCs von Google Cloudfür die externen Netzwerke.

VPC-Netzwerk an freigegebene VPC-Netzwerk weiterleiten

Sie verbinden das Routing-VPC-Netzwerk und das RAG-VPC-Netzwerk über die Network Connectivity Center-VPC-Spokes des Network Connectivity Center-Hubs. Der Hub hostet auch die Hybrid-Spokes zum externen Netzwerk.

Ressource-zu-Ressource innerhalb des freigegebene VPC-Netzwerks

Bei diesem Design werden Daten aus dem externen Netzwerk in einem Cloud Storage-Bucket empfangen. Anfragen für die Inferenz werden über einen regionalen internen Application Load Balancer gesendet. Für den Rest Ihres Systems haben Sie folgende Optionen:

  • Hosten Sie alles in der Google SaaS-Infrastruktur, z. B. Cloud Storage-Buckets, Vertex AI, Cloud Run und Pub/Sub. In diesem Fall kommunizieren die Komponenten über die private Google-Infrastruktur.
  • Hosten Sie alles in Arbeitslasten, die in Compute Engine-VMs, GKE-Clustern, Cloud SQL-Datenbanken oder anderen Komponenten ausgeführt werden, die in VPC-Netzwerken ausgeführt werden. In diesem Fall kommunizieren Systeme über private IP-Adressen in Netzwerken, die Sie über Network Connectivity Center oder VPC-Netzwerk-Peering verknüpfen.
  • Verwenden Sie eine Mischung aus vollständig verwalteten Diensten, Plattformdiensten und Infrastrukturdiensten. In diesem Fall können Sie Verbindungen zwischen einem VPC-Netzwerk und einem vollständig verwalteten Dienst mit den folgenden Methoden herstellen:
    • Privater Google-Zugriff: Mit dieser Methode können Arbeitslasten, die keine externen IP-Adressen haben und in VPC-Netzwerken ausgeführt werden, auf Google APIs zugreifen. Dieser Zugriff erfolgt intern über die Google-Infrastruktur und bei diesem Vorgang wird solcher Traffic nicht dem Internet ausgesetzt.
    • Private Service Connect: Mit dieser Methode können Sie einen Endpunkt in Ihrem Dienstprojekt für Dienste wie AlloyDB for PostgreSQL erstellen, die in verwalteten VPC-Netzwerken gehostet werden.

Externes Netzwerk zum Load Balancer für den Frontend-Dienst

Der Endpunkt des regionalen internen Application Load Balancer ist eine IP-Adresse im RAG-Netzwerk. Das RAG-Netzwerk, das Routingnetzwerk und die Hybridverbindungen zum externen Netzwerk sind alle Spokes desselben Network Connectivity Center-Hubs. Daher können Sie Network Connectivity Center anweisen, alle Spoke-Unterbereiche in den Hub zu exportieren, der diese Unterbereiche dann in die anderen Spoke-Netzwerke reexportiert. Endnutzer des Systems können dann über das externe Netzwerk auf den Load-Balanced-Dienst zugreifen.

Trafficabläufe

Die Trafficflüsse in dieser Referenzarchitektur umfassen einen RAG-Datenfluss und einen Inferenzfluss.

RAG-Populationsfluss

In diesem Ablauf wird beschrieben, wie RAG-Daten von Data Engineers zum Vektorspeicher durch das System fließen.

  1. Aus dem externen Netzwerk laden Data Engineers Rohdaten über die Cloud Interconnect- oder Cloud VPN-Verbindung hoch. Die Daten werden in das Routing-VPC-Netzwerk zum Private Service Connect-Endpunkt hochgeladen.
  2. Die Daten werden über die interne Infrastruktur von Google zum Cloud Storage-Bucket im Projekt des Datenerfassungsdienstes übertragen.

  3. Im Projekt für die Datenaufnahme werden Daten zwischen Systemen mit einer der folgenden Methoden übertragen:

    • Privater Google-Zugriff
    • Private Service Connect-Endpunkte
    • Direkte Google-Infrastruktur

    Die Methode hängt davon ab, ob die Systeme inGoogle Cloud VPC-Netzwerken oder direkt inGoogle Cloudgehostet werden. Im Rahmen dieses Ablaufs führt das Datenaufnahmesubsystem dem Modell in Chunks aufgeteilte RAG-Daten zu, die Vektoren für jeden Chunk erzeugen.

  4. Das Subsystem für die Datenaufnahme schreibt die Vektordaten und die in Chunks aufgeteilten Daten in den entsprechenden Datenspeicher.

Inferenzablauf

In diesem Ablauf werden Kundenanfragen beschrieben.

  1. Ein Kunde sendet aus dem externen Netzwerk eine Anfrage an die IP-Adresse des Dienstes.
  2. Die Anfrage wird über die Cloud Interconnect- oder Cloud VPN-Verbindung an das Routing-VPC-Netzwerk gesendet.
  3. Die Anfrage wird über die VPC-Spoke-Verbindung an das RAG-VPC-Netzwerk gesendet.
  4. Die Kundenanfrage erreicht den Load-Balancer, der die Anfrage an das Frontend-Subsystem weiterleitet.
  5. Das Frontend-Subsystem leitet die Anfrage an das Subsystem für die Bereitstellung weiter.
  6. Das Bereitstellungssubsystem ergänzt die Anfrage mit den relevanten Kontextdaten aus dem Datenspeicher.
  7. Das Subsystem für die Bereitstellung sendet den angereicherten Prompt an das KI-Modell, das eine Antwort generiert.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:

  • Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPC.
  • Freigegebene VPC: Ein Feature von Virtual Private Cloud, mit dem Sie Ressourcen aus mehreren Projekten über interne IP-Adressen dieses Netzwerks mit einem gemeinsamen VPC-Netzwerk verbinden können.
  • Private Service Connect: Eine Funktion, mit der Nutzer privat aus ihrem VPC-Netzwerk auf verwaltete Dienste zugreifen können.
  • Privater Google-Zugriff: Eine Funktion, mit der VM-Instanzen ohne externe IP-Adressen die externen IP-Adressen von Google APIs und Google-Diensten erreichen können.
  • Cloud Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
  • Cloud VPN: Ein Dienst, mit dem Sie Ihr Peer-Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen können.
  • Cloud Router: Ein verteiltes und vollständig verwaltetes Angebot, das BGP-Speaker- und Responder-Funktionen (Border Gateway Protocol) bietet. Cloud Router arbeitet mit Cloud Interconnect, Cloud VPN und Router-Appliances zusammen, um dynamische Routen in VPC-Netzwerken basierend auf empfangenen BGP-Routen und benutzerdefinierten erlernten Routen zu erstellen.
  • Network Connectivity Center: Ein Orchestrierungs-Framework, das Netzwerkverbindungen zwischen Spoke-Ressourcen vereinfacht, die mit einer zentralen Verwaltungsressource verbunden sind, die als Hub bezeichnet wird.
  • VPC Service Controls: Eine verwaltete Netzwerkfunktion, die das Risiko einer Daten-Exfiltration für Ihre Google Cloud Ressourcen minimiert.
  • Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern
  • Model Armor: Ein Dienst, der Ihre generativen und agentenbasierten KI-Ressourcen vor Prompt Injections, Datenlecks und schädlichen Inhalten schützt.
  • Google Cloud Armor: Ein Netzwerksicherheitsdienst, der WAF-Regeln (Web Application Firewall) bietet und vor DDoS- und Anwendungsangriffen schützt.
  • Cloud Storage: Ein kostengünstiger, unbegrenzter Objektspeicher für verschiedene Datentypen. Auf Daten kann von innerhalb und außerhalb von Google Cloudzugegriffen werden. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.

Anwendungsfälle

Diese Architektur ist für Unternehmensszenarien konzipiert, in denen für die Eingabe, Ausgabe und interne Kommunikation des Gesamtsystems private IP-Adressen verwendet werden müssen und die Kommunikation nicht über das Internet erfolgen darf:

  • Private Eingabe: Hochgeladene Daten werden nicht über das Internet übertragen. Stattdessen hosten Sie Ihren Cloud Storage-Bucket hinter einem Private Service Connect-Endpunkt in Ihrem Google CloudRouting-VPC-Netzwerk. Sie kopieren RAG-Daten über Ihre Cloud Interconnect- oder Cloud VPN-Verbindung und verwenden dabei nur private IP-Adressen.
  • Private Konnektivität zwischen Diensten: Dienste kommunizieren über interne Google-Schnittstellen oder über private Adressen, die für Ihre VPC-Netzwerke intern sind.
  • Private Ausgabe: Die Ergebnisse der Inferenz sind nicht über das Internet erreichbar, es sei denn, Sie richten diesen Zugriff ein. Standardmäßig können nur Nutzer im angegebenen externen Netzwerk den privaten Endpunkt Ihres Dienstes erreichen.

Designalternativen

In diesem Abschnitt werden alternative Netzwerkdesignansätze vorgestellt, die Sie für Ihre RAG-fähige Anwendung in Google Cloudin Betracht ziehen können.

Dienst öffentlich verfügbar machen

In der in diesem Dokument dargestellten Architektur können nur Nutzer in Ihrem internen Netzwerk Anfragen an Ihre Anwendung senden. Wenn Ihre Anwendung für Clients im Internet zugänglich sein muss, verwenden Sie einen regionalen externen Application Load Balancer.

GKE Inference Gateway verwenden

Wenn Ihr Frontend-Subsystem in GKE ausgeführt wird, können Sie anstelle eines Application Load Balancers ein Inference Gateway verwenden.

Designaspekte

In diesem Abschnitt finden Sie zusätzliche Informationen zur Bereitstellung von Netzwerken zur Unterstützung privater Verbindungen für eine RAG-fähige Architektur. Diese Anleitung kann Ihnen helfen, Ihre spezifischen Anforderungen an Sicherheit und Compliance, Zuverlässigkeit, Kosten und Leistung zu erfüllen. Die Anleitung in diesem Abschnitt ist nicht vollständig. Für Ihre spezielle Bereitstellung müssen Sie möglicherweise zusätzliche Designfaktoren berücksichtigen, die in diesem Abschnitt nicht behandelt werden.

Sicherheit, Datenschutz und Compliance

In den meisten Fällen stellen Sie Model Armor vor dem KI-Modell bereit, um sowohl eingehende Prompts als auch ausgehende Ergebnisse zu bewerten. Model Armor hilft, potenzielle Risiken zu vermeiden und für einen verantwortungsvollen Umgang mit KI zu sorgen.

Um unangemessene Anfragen abzulehnen, bevor sie das Serving-Subsystem erreichen, können Sie Model Armor an den Load Balancer anhängen.

In dieser Architektur werden VPC Service Controls verwendet, um eine nicht autorisierte Daten-Exfiltration zu verhindern.

Bei diesem Design werden bewährte Sicherheitsprinzipien verwendet, um Ihre RAG-Arbeitslasten zu schützen. Sicherheitsgrundsätze und ‑empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Sicherheit.

Kostenoptimierung

Kostenoptimierungsgrundsätze und ‑empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Kostenoptimierung.

Leistungsoptimierung

Grundsätze und Empfehlungen zur Leistungsoptimierung, die speziell auf KI- und ML-Arbeitslasten zugeschnitten sind, finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Leistungsoptimierung.

Bereitstellung

In diesem Abschnitt wird beschrieben, wie Sie Ihre Anwendung erstellen:

  1. Region für Arbeitslasten ermitteln:
  2. Google Cloud Projekte und VPC-Netzwerke erstellen
  3. Verbinden Sie Ihre externen Netzwerke mit Ihrem Routing-VPC-Netzwerk.
  4. Netzwerke mit Network Connectivity Center verknüpfen
  5. Komponenten für die RAG-Bereitstellung identifizieren und Dienstkonten erstellen
  6. VPC Service Controls konfigurieren.
  7. Subsystem für die Datenaufnahme erstellen
  8. Bereitstellungssubsystem erstellen:
  9. Frontend-Subsystem erstellen:
  10. Anwendung über das Internet erreichbar machen

Region für Arbeitslasten ermitteln

Im Allgemeinen sollten Sie Verbindungen, VPC-Subnetze und Google Cloud-Arbeitslasten in der Nähe Ihrer lokalen Netzwerke oder anderer Cloud-Clients platzieren. Weitere Informationen zum Auswählen einer Region für Ihre Arbeitslasten finden Sie unter Google Cloud Region Picker und Best Practices für die Auswahl der Region in Compute Engine.

Google Cloud Projekte und VPC-Netzwerke erstellen

Wenn Ihre Organisation bereits Cross-Cloud Network für verteilte Anwendungen eingerichtet hat, sollten Ihr Routing-Projekt und Ihr Routing-VPC-Netzwerk bereits vorhanden sein.

Erstellen Sie die Google Cloud -Projekte und ein VPC-Netzwerk in der folgenden Reihenfolge:

  1. Erstellen Sie das Routingprojekt.
  2. Erstellen Sie das Routing-VPC-Netzwerk mit aktiviertem privater Google-Zugriff.
  3. RAG-Projekt erstellen
  4. RAG-Projekt zum Hostprojekt der freigegebene VPC hochstufen.
  5. Erstellen Sie das Dienstprojekt für die Datenaufnahme.
  6. Erstellen Sie das Serviceprojekt für die Bereitstellung.
  7. Erstellen Sie das Frontend-Dienstprojekt.
  8. Erstellen Sie das freigegebene VPC-RAG-Netzwerk mit aktiviertem privater Google-Zugriff.
  9. Erteilen Sie den Dienstprojekten die Berechtigung, das RAG-Netzwerk zu verwenden.

Externe Netzwerke mit Ihrem Routing-VPC-Netzwerk verbinden

Sie können diesen Schritt überspringen, wenn Sie bereits ein cloudübergreifendes Netzwerk für verteilte Anwendungen eingerichtet haben.

Richten Sie die Verbindung zwischen den externen Netzwerken und Ihrem Routing-Netzwerk ein. Informationen zu den relevanten Technologien finden Sie unter Externe und Hybridkonnektivität. Eine Anleitung zur Auswahl eines Konnektivitätsprodukts finden Sie unter Netzwerkverbindungsprodukt auswählen.

  1. Erstellen Sie im Routing-Projekt einen Network Connectivity Center-Hub.
  2. Fügen Sie die Cloud Interconnect-Verbindungen als VLAN-Anhang-Spokes oder Cloud VPN-Verbindungen als VPN-Spokes hinzu.
  3. Fügen Sie das RAG-VPC-Netzwerk und das Routing-VPC-Netzwerk dem Hub als VPC-Spokes hinzu.

Komponenten für die RAG-Bereitstellung identifizieren und Dienstkonten erstellen

  1. Wählen Sie eine RAG-Bereitstellung aus und erstellen Sie eine Liste der Komponenten, die dafür erforderlich sind.
  2. Ermitteln Sie, welchen Zugriff jede Komponente benötigt.
  3. Erstellen Sie für jede Komponente ein Dienstkonto mit den entsprechenden Berechtigungen. In einigen Fällen bedeutet das, dass Sie einer Komponente die Berechtigung erteilen, Daten aus einem anderen Dienstprojekt zu lesen oder in ein anderes Dienstprojekt zu schreiben.

Bei diesem Design wird davon ausgegangen, dass Sie einen Cloud Storage-Bucket als Dateneingabekomponente und einen Load Balancer in Ihrem Inferenz-Frontend verwenden. Der Rest des Designs kann nach Bedarf variieren.

Im Idealfall wird jede Komponente mit einem eigenen Dienstkonto ausgeführt. Jede Komponente sollte nur die minimalen IAM-Berechtigungen haben, die für die Ausführung der erforderlichen Funktionen notwendig sind. Ein Cloud Run-Job im Subsystem für die Datenerfassung muss beispielsweise Daten aus dem Cloud Storage-Eingabe-Bucket lesen, aber nicht in den Bucket schreiben. In diesem Beispiel sollte das Dienstprojekt, in dem der Cloud Run-Job ausgeführt wird, nur die Berechtigung zum Lesen aus dem Bucket haben, nicht aber zum Schreiben.

VPC Service Controls konfigurieren

  1. Erstellen Sie einen VPC Service Controls-Perimeter für Ihre Bereitstellung.
  2. Zugriffsregeln konfigurieren

Subsystem für die Datenaufnahme erstellen

Das Subsystem für die Datenaufnahme übernimmt Rohdaten von Data Engineers und verarbeitet sie für die Verwendung durch das Subsystem für die Bereitstellung.

  1. Erstellen Sie im Projekt des Dienstes zur Datenaufnahme einen Cloud Storage-Bucket.
  2. Erstellen Sie im Routing-VPC-Netzwerk einen regionalen Private Service Connect-Endpunkt und verbinden Sie den Endpunkt mit dem Bucket.
  3. Fügen Sie im externen Netzwerk einen DNS-Eintrag für den Endpunkt mit der IP-Adresse und URL hinzu, die im vorherigen Schritt generiert wurden.
  4. Aktualisieren Sie die Firewallregeln für externe Netzwerke, um den Zugriff auf die IP-Adresse des Endpunkts zuzulassen.
  5. Erstellen Sie im Dienstprojekt für die Datenaufnahme den Rest Ihrer Aufnahmepipeline entsprechend der von Ihnen ausgewählten RAG-Architektur.
  6. Gewähren Sie IAM-Berechtigungen, damit die entsprechende Ressource in der Erfassungspipeline auf das Modell zugreifen kann, mit dem die Vektoren erstellt werden.
  7. Gewähren Sie IAM-Berechtigungen, damit die entsprechende Ressource in der Erfassungspipeline in den Vektordatenspeicher schreiben kann.

Subsystem für die Bereitstellung erstellen

  1. Erstellen Sie die Bereitstellungspipeline im Dienstprojekt für die Bereitstellung.
  2. Gewähren Sie IAM-Berechtigungen, damit das Dienstkonto im Frontend-System auf die Ausgabe des Serving-Subsystems zugreifen kann.

Frontend-Subsystem erstellen

In diesem Abschnitt wird davon ausgegangen, dass Sie einen regionalen internen Application Load Balancer verwenden, der ein serverloses NEG vor Cloud Run verwendet. Sie können jedoch einen anderen Load-Balancer und ein anderes Backend verwenden.

  1. Erstellen Sie den Code für Ihr Frontend-System.
  2. Stellen Sie im Frontend-Dienstprojekt Ihr Load-Balancing-Frontend-System bereit. Dieser Schritt umfasst auch die optionale Konfiguration einer Cloud Armor-Sicherheitsrichtlinie.
  3. Konfigurieren Sie den Cloud Router im Routing-VPC-Netzwerk so, dass Routen aus dem RAG-VPC-Netzwerk an die lokalen Router weitergeleitet werden. Diese Konfiguration ermöglicht es Clients, den Load-Balancer zu erreichen.
  4. Konfigurieren Sie in Ihrem externen Netzwerk die Firewallregeln so, dass das Load-Balancer-Frontend von Ihrem externen Netzwerk aus erreichbar ist.
  5. Aktualisieren Sie das DNS in Ihrem externen Netzwerk, sodass es auf die Weiterleitungsregel des Load-Balancers verweist.

Anwendung über das Internet erreichbar machen

Dieser Abschnitt ist optional.

Bei diesem Design wird davon ausgegangen, dass Ihr Dienst nur über Ihr externes Netzwerk erreichbar sein soll. Sie können den Dienst aber auch über das Internet erreichbar machen.

So machen Sie den Dienst über das Internet erreichbar:

  1. Erstellen Sie einen regionalen externen Application Load Balancer, der auf dasselbe Backend verweist wie der interne Load Balancer. Führen Sie den optionalen Schritt zum Konfigurieren einer Cloud Armor-Sicherheitsrichtlinie aus.
  2. VPC Service Controls aktualisieren, damit Dienstkunden Backend-Dienste erreichen können.

Nächste Schritte

Beitragende

Autoren:

  • Deepak Michael | Networking Specialist Customer Engineer
  • Mark Schlagenhauf | Technical Writer, Netzwerk

Weitere Beitragende: