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

Last reviewed 2026-11-03 UTC

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 Datenverarbeitung und den Abruf von Inhalten. In dieser Referenzarchitektur wird gezeigt, wie Sie mit einer gemeinsam genutzten 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 ein grundlegendes Verständnis von Netzwerken haben. In diesem Dokument wird die Erstellung einer RAG-basierten Anwendung nicht beschrieben.

Architektur

Das folgende Diagramm zeigt die in diesem Dokument vorgestellte Netzwerkarchitektur:

Netzwerkarchitektur für Anwendungen mit RAG.

Verbindungen und Trafficfluss für die Netzwerkarchitektur.

Die Architektur im vorherigen Diagramm besteht aus folgenden Komponenten:

Externes Netzwerk, entweder lokal oder in einer anderen Cloud

Ein externes Netzwerk, das die folgenden Funktionen ausführt:

  • Bietet Netzwerkverbindungen für Data Engineers, die RAG-Rohdaten hochladen.
  • Beendet die externe Netzwerkverbindung.
  • Hostet externe Router.
  • Stellt eine Verbindung zum Private Service Connect-Endpunkt im Routing-VPC-Netzwerk (Virtual Private Cloud) von Google Cloud her.
  • Enthält DNS-Server, die auf den Private Service Connect-Endpunkt verweisen.
Routing-Projekt

Ein Google Cloud -Projekt, das die folgenden Funktionen ausführt:

  • Hostet das Routing-VPC-Netzwerk, das über eine Cloud Interconnect- oder Cloud VPN-Verbindung mit dem externen Netzwerk verbunden ist.
  • Hostet einen Network Connectivity Center-Hub (NCC), der das externe Netzwerk, das Routing-VPC-Netzwerk und die gemeinsam freigegebene VPC-Netzwerke miteinander verbindet.
  • Hostet einen Private Service Connect-Endpunkt, der eine Verbindung zu einem regionalen Cloud Storage-Endpunkt herstellt. Über diesen Endpunkt können Data Engineers RAG-Daten in den Cloud Storage-Bucket hochladen.
RAG-Hostprojekt mit gemeinsam genutzter VPC

Hostet ein freigegebene VPC-Netzwerk, das den internen Application Load Balancer des Frontend-Dienstes 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 Datenaufnahme, das die folgenden Komponenten umfasst:

  • Aufnahmeverarbeitung: Liest Rohdaten und verarbeitet sie.
  • Aufnahmeausgabe: Schreibt in den endgültigen Datenspeicher.
Bereitstellungsdienstprojekt

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

  • RAG-Datenspeicher, der die Ausgabe des Datenaufnahme-Subsystems enthält.
  • Bereitstellungsprozesse, die das Modell füttern, indem sie die Inferenzabfrage mit Daten aus dem RAG-Datenspeicher kombinieren.
  • Das Modell, das das Bereitstellungssubsystem verwendet, um Vektoren aus den hochgeladenen RAG-Daten zu erstellen und die Anfrage des Endnutzers zu verarbeiten.
Frontend-Dienstprojekt

Enthält das Frontend-Subsystem, das ein Application Load Balancer vor einem Nutzerinteraktionsdienst ist, der in Cloud Run oder der Google Kubernetes Engine (GKE) ausgeführt wird.

Das Projekt enthält auch Google Cloud Armor, mit dem Sie den Zugriff auf Ihren Dienst einschränken können. Wenn Sie Zugriff über das Internet ermöglichen möchten, können Sie einen regionalen externen Application Load Balancer hinzufügen.

VPC Service Controls-Perimeter

Schutz vor Daten-Exfiltration In Cloud Storage-Buckets gespeicherte Daten können nicht an Orte außerhalb des Perimeters kopiert werden und Vorgänge auf der Steuerungsebene sind geschützt.

In den folgenden Abschnitten werden die Verbindungen und Trafficflü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 stellen über Cloud Interconnect oder Cloud VPN eine Verbindung zum Routing-VPC-Netzwerk von Google Cloud her. Diese sind Hybrid-Spokes eines NCC-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 kündigen die Routen für externe Subnetze dem Routing-VPC-Cloud-Router an. Sie können die Präferenz der Routen mithilfe von BGP-Messwerten und -Attributen ausdrücken.
  • Cloud Router im Routing-VPC-Netzwerk bewerben die Routen für Präfixe in den VPCs von Google Cloudbei den externen Netzwerken.

VPC-Netzwerk an freigegebene VPC-Netzwerk weiterleiten

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

Ressource-zu-Ressource im freigegebene VPC-Netzwerk

In diesem Design empfängt ein Cloud Storage-Bucket Daten aus dem externen Netzwerk. Inferenzanfragen werden über einen regionalen internen Application Load Balancer weitergeleitet. Für den Rest deines Systems hast du folgende Möglichkeiten:

  • Hosten Sie alles in der Google-SaaS-Infrastruktur, z. B. Cloud Storage-Buckets, Gemini Enterprise Agent Platform, 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 NCC oder VPC-Netzwerk-Peering verknüpfen.
  • Verwenden Sie eine Mischung aus vollständig verwalteten Diensten, Plattformdiensten und Infrastrukturdiensten. In diesem Fall können Sie mit den folgenden Methoden Verbindungen zwischen einem VPC-Netzwerk und einem vollständig verwalteten Dienst 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 dieser Prozess macht den Traffic nicht im Internet verfügbar.
    • Private Service Connect: Mit dieser Methode können Sie in Ihrem Dienstprojekt einen Endpunkt für Dienste wie AlloyDB for PostgreSQL erstellen, die in verwalteten VPC-Netzwerken gehostet werden.

Externes Netzwerk zum Frontend-Dienst-Application Load Balancer

Der Endpunkt des regionalen internen Application Load Balancers ist eine IP-Adresse im RAG-Netzwerk. Das RAG-Netzwerk, das Routing-Netzwerk und die Hybridverbindungen zum externen Netzwerk sind alle Spokes desselben NCC-Hubs. Daher können Sie NCC anweisen, alle Spoke-Teilbereiche in den Hub zu exportieren, der diese Teilbereiche dann wieder in die anderen Spoke-Netzwerke exportiert. Endnutzer des Systems können dann über das externe Netzwerk auf den Dienst mit Load Balancing 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. Über das externe Netzwerk laden Data Engineers Rohdaten über die Cloud Interconnect- oder Cloud VPN-Verbindung hoch. Die Daten werden in das Routing-VPC-Netzwerk auf den Private Service Connect-Endpunkt hochgeladen.
  2. Die Daten werden über die interne Infrastruktur von Google an den Cloud Storage-Bucket im Dienstprojekt für die Datenaufnahme übertragen.

  3. Im Dienstprojekt für die Datenaufnahme werden Daten mit einer der folgenden Methoden zwischen Systemen ü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 werden dem Modell vom Datenaufnahme-Subsystem aufgeteilte RAG-Daten zugeführt, die Vektoren für jeden Chunk erzeugen.

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

Inferenzablauf

In diesem Ablauf werden Kundenanfragen beschrieben.

  1. Ein Kunde sendet eine Anfrage aus dem externen Netzwerk an die IP-Adresse des Dienstes.
  2. Die Anfrage wird über die Cloud Interconnect- oder Cloud VPN-Verbindung an das Routing-VPC-Netzwerk weitergeleitet.
  3. Die Anfrage wird über die VPC-Spoke-Verbindung an das RAG-VPC-Netzwerk weitergeleitet.
  4. Die Kundenanfrage geht beim Application Load Balancer ein, 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 Produkte von Google Cloud verwendet:

  • Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Arbeitslasten in Google Cloud bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPC.
  • Gemeinsam genutzte 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: Ein Feature, mit dem 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 über BGP empfangenen und benutzerdefinierten gelernten 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 agentischen KI-Ressourcen vor Prompt Injection, Lecks sensibler Daten 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 die Eingabe, Ausgabe und interne Kommunikation des Gesamtsystems private IP-Adressen verwenden und nicht über das Internet erfolgen müssen:

  • 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 Cloud-Routing-VPC-Netzwerk. Sie kopieren RAG-Daten über Ihre Cloud Interconnect- oder Cloud VPN-Verbindung und verwenden dabei nur private IP-Adressen.
  • Private Verbindung zwischen Diensten: Dienste kommunizieren über die internen Schnittstellen von Google oder über private Adressen, die intern in Ihren VPC-Netzwerken sind.
  • Private Ausgabe: Inferenz-Ergebnisse 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 gezeigten Architektur können nur Nutzer in Ihrem internen Netzwerk Abfragen 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 der GKE ausgeführt wird, können Sie anstelle eines Application Load Balancers das GKE Inference Gateway verwenden.

Designaspekte

Dieser Abschnitt enthält zusätzliche Informationen, die Ihnen helfen, Netzwerke bereitzustellen, um private Konnektivität für eine RAG-fähige Architektur zu unterstützen. Diese Anleitung kann Ihnen dabei helfen, Ihre spezifischen Anforderungen an Sicherheit, Datenschutz und Compliance, Zuverlässigkeit, Kostenoptimierung, betriebliche Effizienz und Leistungsoptimierung 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

Beachten Sie die folgenden Empfehlungen, um Ihre RAG-fähige Architektur zu schützen und Ihre Datenschutz- und Compliance-Anforderungen zu erfüllen:

  • Prompt- und Antwortprüfung: Stellen Sie Model Armor vor dem KI-Modell bereit, um sowohl eingehende Prompts als auch ausgehende Ergebnisse auf Prompt Injection, Jailbreaking-Versuche, Datenlecks mit sensiblen Daten und Verstöße gegen Richtlinien für verantwortungsbewusste KI zu prüfen. Sie können Model Armor direkt in die Gemini Enterprise Agent Platform einbinden oder Model Armor an den Application Load Balancer anhängen, indem Sie Traffic-Erweiterungen von Service Extensions verwenden, um unangemessene Anfragen abzulehnen, bevor sie das Bereitstellungssubsystem erreichen. Wenn Sie privat von einem VPC-Netzwerk aus auf regionale Model Armor-Endpunkte zugreifen möchten, ohne dass Zertifikatsfehler auftreten, wenn Sie den privater Google-Zugriff oder VPC Service Controls verwenden, erstellen Sie einen regionalen Private Service Connect-Endpunkt für die Model Armor APIs.
  • Perimeter- und Netzwerk-Mikrosegmentierung: Diese Architektur verwendet VPC Service Controls, um eine nicht autorisierte Daten-Exfiltration in Ihren Dienstprojekten zu verhindern. Verwenden Sie zusätzlich zu Dienstperimetern hierarchische und Netzwerk-Firewallrichtlinien der Cloud Next Generation Firewall mit IAM-gesteuerten Tags, um den Ost-West-Traffic zwischen den Arbeitslasten für Datenaufnahme, Bereitstellung und Frontend im freigegebene VPC-Netzwerk einzuschränken.
  • Identität und Zero-Trust-Zugriff: Erzwingen Sie die Zero-Trust-Zugriffssteuerung auf dem Frontend des internen Application Load Balancers oder des regionalen externen Application Load Balancers, indem Sie Identity-Aware Proxy (IAP) aktivieren, sodass nur authentifizierte und autorisierte Nutzer die RAG-Anwendung abfragen können. Kombinieren Sie Dienstkonten mit geringsten Berechtigungen mit Principal Access Boundary-Richtlinien, um einzuschränken, auf welche Ressourcen die einzelnen Subsystem-Hauptkonten zugreifen können. Wenn Ihr Bereitstellungssubsystem autonome Agenten oder MCP-Tools (Model Context Protocol) über private Netzwerke orchestriert, verwenden Sie Agent Identity und Agent Gateway, um den Traffic zwischen Agenten und Tools zu authentifizieren und zu verwalten.
  • Datenschutz und Verschlüsselung: Verwenden Sie Sensitive Data Protection im Subsystem für die Datenaufnahme, um personenidentifizierbare Informationen (PII) in Rohdokumenten, die in den Cloud Storage-Bucket hochgeladen wurden, zu prüfen, zu klassifizieren und zu de-identifizieren, bevor Sie Einbettungen generieren und in den RAG-Datenspeicher schreiben. Wenn die Einhaltung regulatorischer Anforderungen die Kontrolle über Verschlüsselungsschlüssel erfordert, konfigurieren Sie kundenverwaltete Verschlüsselungsschlüssel (CMEK) in Cloud Key Management Service (Cloud KMS) für den Cloud Storage-Bucket, den Vektordatenspeicher und die Modellendpunkte.

Dieses Design verwendet etablierte Sicherheitsprinzipien, 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.

Zuverlässigkeit

Beachten Sie die folgenden Empfehlungen, um eine zuverlässige Netzwerkinfrastruktur für Ihre RAG-fähige Anwendung zu erstellen und zu betreiben:

  • Redundante Hybridkonnektivität: Konfigurieren Sie redundante Cloud Interconnect-VLAN-Anhänge oder HA VPN-Tunnel über mehrere Edge-Verfügbarkeitsdomains und Regionen hinweg, kombiniert mit redundanten Cloud Routern für ein dynamisches BGP-Failover zwischen Ihrem externen Netzwerk und dem Routing-VPC-Netzwerk.
  • Multiregionales Load Balancing und multiregionaler Speicher: Verwenden Sie für Hochverfügbarkeit über Regionen hinweg einen regionenübergreifenden internen Application Load Balancer, um Inferenz-Traffic auf Frontend- und Bereitstellungs-Backends in mehreren Regionen zu verteilen. Verwenden Sie außerdem biregionale oder multiregionale Cloud Storage-Buckets mit replizierten Vektordatenspeichern.
  • Asynchrone Aufnahme und Kontingentresilienz: Entkoppeln Sie Rohdaten-Uploads in den Cloud Storage-Bucket von der Aufnahmepipeline, indem Sie Pub/Sub mit Themen für unzustellbare Nachrichten oder Eventarc-Wiederholungsrichtlinien verwenden. So können vorübergehende Einbettungs- oder Indexierungsfehler ohne Datenverlust wiederholt werden. Wenn Sie eine vorhersehbare Latenz und Kapazität bei der Generierung und Inferenz von Einbettungen mit hohem Volumen benötigen, reservieren Sie bereitgestellten Durchsatz und implementieren Sie einen exponentiellen Backoff für HTTP-429-Antworten.

Zuverlässigkeitsprinzipien und Empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Zuverlässigkeit.

Kostenoptimierung

Beachten Sie die folgenden Empfehlungen, um die Kosten für die Erstellung und Ausführung Ihrer RAG-fähigen Architektur zu optimieren:

  • Ausgehender Netzwerktraffic und Endpunktauswahl: Platzieren Sie das Routing-VPC-Netzwerk, die Private Service Connect-Endpunkte, den Cloud Storage-Bucket, den RAG-Datenspeicher und die Modellendpunkte in derselben Region, um Gebühren für die Datenübertragung zwischen Regionen über NCC-Spokes zu vermeiden. Konsolidieren Sie freigegebene Private Service Connect-Endpunkte im Routing- oder Host-VPC-Netzwerk, um die stündlichen Gebühren für Endpunkte und Datenverarbeitung zu reduzieren.
  • Verwaltung des Speicherlebenszyklus: Konfigurieren Sie die Verwaltung des Objektlebenszyklus oder Autoclass für den Bucket zur Aufnahme von Rohdaten, um verarbeitete Quelldokumente in kältere Speicherklassen zu verschieben oder Staging-Dateien zu löschen, nachdem Vektoren in den RAG-Datenspeicher geschrieben wurden.
  • Batch-Einbettung und Kontext-Caching: Verwenden Sie für große, nicht dringende RAG-Korpus-Updates im Datenaufnahmesubsystem die Batch-Vorhersage für Einbettungen oder die Batch-Inferenz zu geringeren Kosten als Online-Anfragen. Aktivieren Sie im Bereitstellungssubsystem das Kontext-Caching für wiederkehrende Systemanweisungen und häufig abgerufene Referenzdokumente, um die Kosten für Eingabe-Tokens zu senken.

Prinzipien und Empfehlungen zur Kostenoptimierung, die speziell für KI- und ML-Arbeitslasten gelten, finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Kostenoptimierung.

Betriebliche Effizienz

Beachten Sie die folgenden Empfehlungen, um Ihre Netzwerk- und RAG-Infrastruktur effizient zu betreiben und zu verwalten:

  • Infrastructure as Code (IaC): Automatisieren Sie die Bereitstellung des Routingprojekts, der freigegebene VPC-Host- und Dienstprojekte, der NCC-Hubs und -Spokes, der Private Service Connect-Endpunkte und der VPC Service Controls-Perimeter mithilfe von Terraform-Modulen aus dem Enterprise Foundations Blueprint und dem Infrastructure Manager.
  • Zentralisierte private DNS-Auflösung: Vereinfachen Sie die DNS-Verwaltung in Ihrem externen Netzwerk und Ihren VPC-Spokes, indem Sie private Cloud DNS-Zonen und Weiterleitungsrichtlinien für eingehenden oder ausgehenden Traffic im Routing-VPC-Netzwerk verwenden, damit lokale Clients und Dienstprojekte die Private Service Connect-Endpunkt- und internen Application Load Balancer-IP-Adressen automatisch auflösen.
  • Netzwerk- und KI-Beobachtbarkeit: Überwachen Sie Hybridkonnektivität, NCC-Spoke-Traffic und Ablehnungen von VPC Service Controls-Richtlinien mit Network Intelligence Center (einschließlich Konnektivitätstests und Flow Analyzer), Cloud Logging und Cloud Monitoring. Mit dem Gen AI Evaluation Service können Sie die Relevanz und Fundiertheit der Abrufe im Bereitstellungssubsystem kontinuierlich bewerten.

Informationen zu Prinzipien und Empfehlungen für die operative Exzellenz, die speziell für KI- und ML-Arbeitslasten gelten, finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Operative Exzellenz.

Leistungsoptimierung

Beachten Sie die folgenden Empfehlungen, um die Leistung Ihrer Netzwerk- und RAG-Arbeitslasten zu optimieren:

  • Hybridbandbreite und regionale Co-Location: Dimensionieren Sie Ihre Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel so, dass sie die maximalen Uploadvolumen für Rohdaten aus Ihrem externen Netzwerk bewältigen können, ohne die Bandbreite zu überlasten, die mit interaktiven Inferenzanfragen geteilt wird. Platzieren Sie den regionalen Private Service Connect-Endpunkt, den Cloud Storage-Bucket, den Vektordatenspeicher (z. B. Vektorsuche oder AlloyDB for PostgreSQL) und die Modellendpunkte in der Region, die Ihrem Hybrid Interconnect-Point of Presence am nächsten ist, um die Netzwerk-Roundtrip-Latenz zu minimieren.
  • Computing-Skalierung und Inferenzrouting: Wenn Ihr Frontend- oder Bereitstellungssubsystem in Cloud Run ausgeführt wird, konfigurieren Sie die Mindestanzahl von Instanzen und passen Sie die Einstellungen für die Nebenläufigkeit an, um die Kaltstartlatenz bei Traffic-Spitzen zu vermeiden. Wenn Sie offene Modelle in der GKE bereitstellen, verwenden Sie das Inference Gateway, um KV-Cache- und lastabhängiges Routing über Modellserver hinweg durchzuführen.

Prinzipien und Empfehlungen zur Leistungsoptimierung, die speziell für KI- und ML-Arbeitslasten gelten, finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Leistungsoptimierung.

Bereitstellung

In diesem Abschnitt werden die Schritte zum Erstellen Ihrer Anwendung beschrieben:

  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 über NCC 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 Konnektivität, 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 ein Cross-Cloud Network für verteilte Anwendungen eingerichtet hat, sollten Ihr Routingprojekt 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. Erstellen Sie das RAG-Projekt.
  4. RAG-Projekt zu einem Hostprojekt für eine freigegebene VPC hochstufen
  5. Erstellen Sie das Dienstprojekt für die Datenaufnahme.
  6. Erstellen Sie das Bereitstellungsdienstprojekt.
  7. Erstellen Sie das Frontend-Dienstprojekt.
  8. Erstellen Sie das gemeinsam genutzte VPC-RAG-Netzwerk mit aktiviertem privater Google-Zugriff.
  9. Gewähren Sie den Dienstprojekten die Berechtigung, das RAG-Netzwerk zu verwenden.

Externe Netzwerke mit dem Routing-VPC-Netzwerk verbinden

Sie können diesen Schritt überspringen, wenn Sie bereits Cross-Cloud Network für verteilte Anwendungen eingerichtet haben.

Richten Sie die Verbindung zwischen den externen Netzwerken und Ihrem Routingnetzwerk ein. Informationen zu den relevanten Technologien finden Sie unter Externe und Hybridkonnektivität. Informationen zur Auswahl eines Konnektivitätsprodukts finden Sie unter Network Connectivity-Produkt auswählen.

  1. Erstellen Sie im Routingprojekt einen NCC-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 ein RAG-Deployment aus und erstellen Sie eine Liste der erforderlichen Komponenten.
  2. Ermitteln Sie, welchen Zugriff die einzelnen Komponenten benötigen.
  3. Erstellen Sie für jede Komponente ein Dienstkonto mit den entsprechenden Berechtigungen. In einigen Fällen bedeutet dies, dass Sie einer Komponente die Berechtigung zum Lesen aus oder Schreiben in ein anderes Dienstprojekt erteilen.

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

Idealerweise wird jede Komponente als eigenes Dienstkonto ausgeführt. Achten Sie darauf, dass jede Komponente nur die IAM-Mindestberechtigungen hat, die für die Ausführung der erforderlichen Funktionen erforderlich sind. Beispielsweise muss ein Cloud Run-Job im Subsystem für die Datenaufnahme 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, aber keine Schreibberechtigung.

VPC Service Controls konfigurieren

  1. Erstellen Sie einen VPC Service Controls-Perimeter um Ihre Bereitstellung.
  2. Zugriffsregeln konfigurieren

Subsystem für die Datenaufnahme erstellen

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

  1. Erstellen Sie im Dienstprojekt für die 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 hinzu. Verwenden Sie dazu die IP-Adresse und die URL, die im vorherigen Schritt generiert wurden.
  4. Aktualisieren Sie die Firewallregeln für das externe Netzwerk, um den Zugriff auf die IP-Adresse des Endpunkts zuzulassen.
  5. Erstellen Sie im Dienstprojekt für die Datenaufnahme den Rest Ihrer Aufnahmepipeline gemäß der von Ihnen gewählten RAG-Architektur.
  6. Gewähren Sie IAM-Berechtigungen, damit die entsprechende Ressource in der Aufnahmepipeline auf das Modell zugreifen kann, das die Vektoren erzeugt.
  7. Gewähren Sie IAM-Berechtigungen, damit die relevante Ressource in der Aufnahmepipeline in den Vektordatenspeicher schreiben kann.

Subsystem für die Bereitstellung erstellen

  1. Erstellen Sie im Bereitstellungsdienstprojekt Ihre Bereitstellungspipeline.
  2. Gewähren Sie IAM-Berechtigungen, damit das Dienstkonto im Frontend-System auf die Ausgabe des Bereitstellungssubsystems zugreifen kann.

Frontend-Subsystem erstellen

In diesem Abschnitt wird davon ausgegangen, dass Sie einen regionalen internen Application Load Balancer verwenden, der eine serverlose 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 Frontend-System mit Load Balancing bereit. Dazu gehört auch der optionale Schritt, eine Cloud Armor-Sicherheitsrichtlinie zu konfigurieren.
  3. Konfigurieren Sie den Cloud Router im Routing-VPC-Netzwerk so, dass Routen vom RAG-VPC-Netzwerk an die lokalen Router weitergeleitet werden. Mit dieser Konfiguration können Clients den Application Load Balancer 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 in Ihrem externen Netzwerk das DNS so, dass es auf die Weiterleitungsregel des Application 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 Application Load Balancer. Führen Sie den optionalen Schritt zum Konfigurieren einer Cloud Armor-Sicherheitsrichtlinie aus.
  2. Aktualisieren Sie VPC Service Controls, damit Dienstkunden Backend-Dienste erreichen können.

Nächste Schritte

Beitragende

Autor*innen:

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

Weitere Beitragende: