Connettività privata per applicazioni di AI generativa compatibili con RAG

Last reviewed 2026-11-03 UTC

Questo documento fornisce un'architettura di riferimento che puoi utilizzare per proteggere l'infrastruttura di rete per le applicazioni con Retrieval-Augmented Generation (RAG). Un'architettura RAG in genere contiene sottosistemi separati per gestire i flussi di trattamento dati e recupero dei contenuti. Questa architettura di riferimento mostra come utilizzare il VPC condiviso per:

  • Crea una separazione tra i sottosistemi utilizzando le autorizzazioni Identity and Access Management (IAM).
  • Connettere i componenti dell'applicazione utilizzando indirizzi IP privati.

Il pubblico di destinazione di questo documento include architetti, sviluppatori e amministratori di rete e della sicurezza. Il documento presuppone che tu abbia una conoscenza di base del networking. Questo documento non descrive la creazione di un'applicazione basata su RAG.

Architettura

Il seguente diagramma mostra l'architettura di networking presentata in questo documento:

Architettura di networking per le applicazioni con RAG.

Connessioni e flusso di traffico per l'architettura di networking.

L'architettura nel diagramma precedente mostra i seguenti componenti:

Rete esterna, on-premise o in un altro cloud

Una rete esterna che svolge le seguenti funzioni:

  • Fornisce la connettività di rete ai data engineer che caricano dati RAG non elaborati.
  • Termina la connettività di rete esterna.
  • Ospita router esterni.
  • Fornisce la connettività all'endpoint Private Service Connect nella rete Virtual Private Cloud (VPC) di routing Google Cloud .
  • Contiene i server DNS che puntano all'endpoint Private Service Connect.
Progetto di routing

Un progetto Google Cloud che esegue le seguenti funzioni:

  • Ospita la rete VPC di routing, che si connette alla rete esterna tramite una connessione Cloud Interconnect o Cloud VPN.
  • Ospita un hub di Network Connectivity Center (NCC) che connette la rete esterna, la rete VPC di routing e le reti VPC condivise.
  • Ospita un endpoint Private Service Connect che si connette a un endpoint Cloud Storage regionale. Questo endpoint consente ai data engineer di caricare i dati RAG nel bucket Cloud Storage.
Progetto host VPC condiviso RAG

Ospita una rete VPC condiviso che ospita il bilanciatore del carico delle applicazioni interno del servizio di frontend e qualsiasi altro servizio che richiede una rete VPC. Tutti i progetti di servizio hanno accesso alla rete VPC condiviso.

Progetto di servizio di acquisizione dei dati

Contiene un bucket Cloud Storage per l'input dei dati non elaborati. Contiene il sottosistema di importazione dei dati, che include i seguenti componenti:

  • Elaborazione dell'importazione: legge i dati non elaborati e li elabora.
  • Output di importazione: scrive nel datastore finale.
Progetto di servizio di pubblicazione

Contiene il sottosistema di gestione, che include i seguenti componenti che forniscono i servizi e le funzioni per l'inferenza e l'interazione:

  • Datastore RAG che contiene l'output del sottosistema di importazione dati.
  • Processi di pubblicazione che alimentano il modello combinando la query di inferenza con i dati del datastore RAG.
  • Il modello utilizzato dal sottosistema di gestione per creare vettori dai dati RAG caricati e per elaborare la richiesta dell'utente finale.
Progetto di servizio frontend

Contiene il sottosistema di frontend, che è un bilanciatore del carico delle applicazioni davanti a un servizio di interazione con l'utente in esecuzione su Cloud Run o Google Kubernetes Engine (GKE).

Il progetto contiene anche Google Cloud Armor, che aiuta a limitare l'accesso al servizio. Se vuoi fornire l'accesso da internet, puoi aggiungere un bilanciatore del carico delle applicazioni esterno regionale.

Perimetro dei Controlli di servizio VPC

Contribuisce a proteggere dall'esfiltrazione di dati. I dati archiviati nei bucket Cloud Storage non possono essere copiati in nessun luogo al di fuori del perimetro e le operazioni del control plane sono protette.

Le sezioni seguenti descrivono le connessioni e i flussi di traffico presenti nell'architettura.

Connessioni tra i componenti

Questa sezione descrive le connessioni tra i componenti e le reti in questa architettura.

Da rete esterna a rete VPC di routing

Le reti esterne si connettono alla rete VPC di routing Google Cloud tramite Cloud Interconnect o Cloud VPN, che sono spoke ibridi di un hub NCC.

I router Cloud nella rete VPC di routing e i router esterni nella rete esterna scambiano route BGP (Border Gateway Protocol):

  • I router nelle reti esterne annunciano le route per le subnet esterne al router Cloud VPC di routing. Puoi esprimere la preferenza delle route utilizzando metriche e attributi BGP.
  • I router Cloud nella rete VPC di routing annunciano le route per i prefissi nei VPC di Google Cloudalle reti esterne.

Rete VPC di routing alla rete VPC condiviso

Puoi connettere la rete VPC di routing e la rete VPC RAG utilizzando gli spoke VPC NCC dell'hub NCC. L'hub ospita anche gli spoke ibridi verso la rete esterna.

Da risorsa a risorsa all'interno della rete VPC condiviso

In questo design, un bucket Cloud Storage riceve i dati dalla rete esterna. Le richieste di inferenza vengono inviate tramite un bilanciatore del carico delle applicazioni interno regionale. Per il resto dell'impianto, hai le seguenti opzioni:

  • Ospita tutto nell'infrastruttura SaaS di Google, come i bucket Cloud Storage, Gemini Enterprise Agent Platform, Cloud Run e Pub/Sub. In questo caso, i componenti comunicano tramite l'infrastruttura Google privata.
  • Ospita tutto nei workload eseguiti nelle VM di Compute Engine, nei cluster GKE, nei database Cloud SQL o in altri componenti eseguiti nelle reti VPC. In questo caso, i sistemi comunicano utilizzando indirizzi IP privati tra reti che colleghi tramite NCC o il peering di rete VPC.
  • Utilizza una combinazione di servizi completamente gestiti, di piattaforma e di infrastruttura. In questo caso, puoi stabilire connessioni tra una rete VPC e un servizio completamente gestito utilizzando i seguenti metodi:
    • Accesso privato Google: con questo metodo, i workload che non hanno indirizzi IP esterni e che vengono eseguiti in reti VPC possono accedere alle API di Google. Questo accesso avviene internamente tramite l'infrastruttura di Google e questo processo non espone il traffico a internet.
    • Private Service Connect: con questo metodo, puoi creare un endpoint nel tuo progetto di servizio per servizi come AlloyDB per PostgreSQL ospitati in reti VPC gestite.

Bilanciatore del carico delle applicazioni dal servizio di rete esterno al frontend

L'endpoint del bilanciatore del carico delle applicazioni interno regionale è un indirizzo IP nella rete RAG. La rete RAG, la rete di routing e le connessioni ibride alla rete esterna sono tutte spoke dello stesso hub NCC. Pertanto, puoi indicare a NCC di esportare tutti i subrange dello spoke nell'hub, che poi li riesporta nelle altre reti spoke. Gli utenti finali del sistema possono quindi raggiungere il servizio con bilanciamento del carico dalla rete esterna.

Flussi di traffico

I flussi di traffico in questa architettura di riferimento includono un flusso di dati RAG e un flusso di inferenza.

Flusso di popolazione RAG

Questo flusso descrive il modo in cui i dati RAG fluiscono attraverso il sistema dai data engineer allo spazio di archiviazione vettoriale.

  1. Dalla rete esterna, i data engineer caricano i dati non elaborati tramite la connessione Cloud Interconnect o Cloud VPN. I dati vengono caricati nell'endpoint Private Service Connect nella rete VPC di routing.
  2. I dati viaggiano attraverso l'infrastruttura interna di Google fino al bucket Cloud Storage nel progetto del servizio di importazione dati.

  3. All'interno del progetto di servizio di importazione dati, i dati viaggiano tra i sistemi utilizzando uno dei seguenti metodi:

    • Accesso privato Google
    • Endpoint di Private Service Connect
    • Infrastruttura Google diretta

    Il metodo dipende dal fatto che i sistemi siano ospitati in reti VPCGoogle Cloud o direttamente inGoogle Cloud. Nell'ambito di questo flusso, il sottosistema di importazione dati fornisce i dati RAG suddivisi in blocchi al modello, che produce vettori per ogni blocco.

  4. Il sottosistema di importazione dati scrive i dati vettoriali e i dati suddivisi in blocchi nel datastore appropriato.

Flusso di inferenza

Questo flusso descrive le richieste dei clienti.

  1. Dalla rete esterna, un cliente invia una richiesta all'indirizzo IP del servizio.
  2. La richiesta viaggia sulla connessione Cloud Interconnect o Cloud VPN fino alla rete VPC di routing.
  3. La richiesta viaggia attraverso la connessione dello spoke VPC alla rete VPC RAG.
  4. La richiesta del cliente arriva al bilanciatore del carico delle applicazioni, che la passa al sottosistema di frontend.
  5. Il sottosistema di frontend inoltra la richiesta al sottosistema di gestione.
  6. Il sottosistema di gestione migliora la richiesta utilizzando i dati contestuali pertinenti del datastore.
  7. Il sottosistema di gestione invia il prompt migliorato al modello di AI, che genera una risposta.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud :

  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di networking globali e scalabili per i tuoi workload Google Cloud . VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e il VPC condiviso.
  • VPC condiviso: una funzionalità di Virtual Private Cloud che consente di connettere risorse di più progetti a una rete VPC comune utilizzando indirizzi IP interni di quella rete.
  • Private Service Connect: una funzionalità che consente ai consumer di accedere ai servizi gestiti privatamente dall'interno della propria rete VPC.
  • Accesso privato Google: una funzionalità che consente alle istanze VM senza indirizzi IP esterni di raggiungere gli indirizzi IP esterni delle API di Google e dei servizi Google.
  • Cloud Interconnect: un servizio che estende la tua rete esterna alla rete Google tramite una connessione ad alta affidabilità e bassa latenza.
  • Cloud VPN: un servizio che estende in modo sicuro la tua rete peer alla rete di Google tramite un tunnel VPN IPsec.
  • router Cloud: un'offerta distribuita e completamente gestita che fornisce funzionalità di speaker e responder del protocollo BGP (Border Gateway Protocol). Router Cloud funziona con Cloud Interconnect, Cloud VPN e le appliance router per creare route dinamiche nelle reti VPC in base alle route apprese personalizzate e ricevute tramite BGP.
  • Network Connectivity Center: un framework di orchestrazione che semplifica la connettività di rete tra le risorse spoke connesse a una risorsa di gestione centrale chiamata hub.
  • Controlli di servizio VPC: una funzionalità di networking gestita che riduce al minimo i rischi di esfiltrazione di dati per le tue risorse Google Cloud .
  • Cloud Load Balancing: un portfolio di bilanciatori del carico globali e regionali scalabili e ad alte prestazioni.
  • Model Armor: un servizio che protegge le tue risorse di AI generativa e agentica da prompt injection, fughe di dati sensibili e contenuti dannosi.
  • Google Cloud Armor: un servizio di sicurezza di rete che offre regole di web application firewall (WAF) e aiuta a proteggersi dagli attacchi DDoS e alle applicazioni.
  • Cloud Storage: un archivio di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono replicati in più località per la ridondanza.

Casi d'uso

Questa architettura è progettata per scenari aziendali in cui l'input, l'output e le comunicazioni interne del sistema complessivo devono utilizzare indirizzi IP privati e non devono attraversare internet:

  • Input privato: i dati caricati non vengono trasmessi su internet. Invece, ospiti il bucket Cloud Storage dietro un endpoint Private Service Connect nella tua rete VPC di routing Google Cloud. Copia i dati RAG sulla tua connessione Cloud Interconnect o Cloud VPN utilizzando solo indirizzi IP privati.
  • Connettività privata tra servizi: i servizi comunicano tra loro tramite le interfacce interne di Google o tramite indirizzi privati interni alle tue reti VPC.
  • Output privato: i risultati dell'inferenza non sono raggiungibili su internet, a meno che tu non scelga di configurare l'accesso. Per impostazione predefinita, solo gli utenti della rete esterna designata possono raggiungere l'endpoint privato del tuo servizio.

Alternative di design

Questa sezione presenta approcci alternativi alla progettazione della rete che puoi prendere in considerazione per la tua applicazione compatibile con RAG in Google Cloud.

Rendi il servizio disponibile pubblicamente

Nell'architettura mostrata in questo documento, solo gli utenti della tua rete interna possono inviare query alla tua applicazione. Se la tua applicazione deve essere accessibile ai client su internet, utilizza un bilanciatore del carico delle applicazioni esterno regionale.

Utilizza GKE Inference Gateway

Se il sottosistema di frontend viene eseguito su GKE, puoi utilizzare GKE Inference Gateway anziché un bilanciatore del carico delle applicazioni.

Considerazioni sulla progettazione

Questa sezione fornisce indicazioni aggiuntive per aiutarti a eseguire il deployment del networking per supportare la connettività privata per un'architettura con funzionalità RAG. Queste indicazioni possono aiutarti a soddisfare i tuoi requisiti specifici in termini di sicurezza, privacy e conformità, affidabilità, ottimizzazione dei costi, efficienza operativa e ottimizzazione delle prestazioni. Le indicazioni in questa sezione non sono esaustive. Per il tuo deployment specifico, potresti dover considerare altri fattori di progettazione non trattati in questa sezione.

Sicurezza, privacy e conformità

Per proteggere l'architettura compatibile con RAG e soddisfare i requisiti di privacy e conformità, tieni presente i seguenti suggerimenti:

  • Screening di prompt e risposte: implementa Model Armor davanti al modello di AI per valutare sia i prompt in entrata sia i risultati in uscita rispetto a prompt injection, tentativi di jailbreak, fughe di dati sensibili e violazioni delle policy di AI responsabile. Puoi integrare Model Armor direttamente con Gemini Enterprise Agent Platform o collegare Model Armor al bilanciatore del carico delle applicazioni utilizzando le estensioni di traffico di Service Extensions per rifiutare le richieste inappropriate prima che raggiungano il sottosistema di distribuzione. Per accedere privatamente agli endpoint regionali di Model Armor dall'interno di una rete VPC senza errori di certificato quando utilizzi l'accesso privato Google o i Controlli di servizio VPC, crea un endpoint Private Service Connect regionale per le API Model Armor.
  • Microsegmentazione di perimetro e rete: questa architettura utilizza i Controlli di servizio VPC per contribuire a impedire l'esfiltrazione di dati non autorizzata tra i progetti di servizio. Oltre ai perimetri di servizio, utilizza le policy del firewall di rete e gerarchiche di Cloud Next Generation Firewall con tag regolati da IAM per limitare il traffico est-ovest tra i workload di importazione dati, pubblicazione e frontend nella rete VPC condiviso.
  • Identità e accesso zero trust: applica controllo dell'accesso zero trust al bilanciatore del carico delle applicazioni interno di frontend o al bilanciatore del carico delle applicazioni esterno regionale abilitando Identity-Aware Proxy (IAP) in modo che solo gli utenti autenticati e autorizzati possano eseguire query sull'applicazione RAG. Combina i service account con privilegi minimi con le policy sul confine di accesso dell'entità per limitare le risorse a cui può accedere ogni entità del sottosistema. Se il tuo sottosistema di gestione orchestra agenti autonomi o strumenti Model Context Protocol (MCP) su reti private, utilizza Agent Identity e Agent Gateway per autenticare e gestire il traffico da agente a strumento.
  • Privacy e crittografia dei dati: utilizza Sensitive Data Protection nel sottosistema di importazione dati per ispezionare, classificare e anonimizzare le informazioni che consentono l'identificazione personale (PII) nei documenti non elaborati caricati nel bucket Cloud Storage prima di generare gli embedding e scrivere nel datastore RAG. Se la conformità legale richiede il controllo sulle chiavi di crittografia, configura le chiavi di crittografia gestite dal cliente (CMEK) in Cloud Key Management Service (Cloud KMS) per il bucket Cloud Storage, il datastore vettoriale e gli endpoint del modello.

Questo design utilizza principi di sicurezza consolidati per proteggere i tuoi workload RAG. Per i principi e i suggerimenti di sicurezza specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: sicurezza nel Well-Architected Framework.

Affidabilità

Per creare e gestire un'infrastruttura di networking affidabile per la tua applicazione compatibile con RAG, tieni presente i seguenti suggerimenti:

  • Connettività ibrida ridondante: configura collegamenti VLAN di Cloud Interconnect o tunnel VPN ad alta affidabilità ridondanti in più domini di disponibilità perimetrale e regioni, abbinati a router Cloud ridondanti per il failover BGP dinamico tra la tua rete esterna e la rete VPC di routing.
  • Bilanciamento del carico e archiviazione multiregionali: per un'alta affidabilità tra le regioni, utilizza un bilanciatore del carico delle applicazioni interno tra regioni per distribuire il traffico di inferenza tra i backend di frontend e di distribuzione in più regioni e utilizza bucket Cloud Storage a due regioni o multiregionali con datastore vettoriali replicati.
  • Importazione asincrona e resilienza delle quote: disaccoppia i caricamenti di dati non elaborati nel bucket Cloud Storage dalla pipeline di elaborazione dell'importazione utilizzando Pub/Sub con argomenti di messaggi non recapitabili o policy di ripetizione dei tentativi di Eventarc in modo che gli errori di incorporamento o indicizzazione temporanei possano essere ritentati senza perdita di dati. Per una latenza e una capacità prevedibili durante la generazione e l'inferenza di embedding ad alto volume, prenota il throughput riservato e implementa il backoff esponenziale per le risposte HTTP 429.

Per i principi e i suggerimenti di affidabilità specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: affidabilità nel Well-Architected Framework.

Ottimizzazione dei costi

Per ottimizzare i costi di creazione ed esecuzione dell'architettura compatibile con RAG, considera i seguenti suggerimenti:

  • Selezione del traffico in uscita dalla rete e degli endpoint: posiziona la rete VPC di routing, gli endpoint Private Service Connect, il bucket Cloud Storage, il datastore RAG e gli endpoint del modello nella stessa regione per evitare addebiti per il trasferimento di dati tra regioni tra gli spoke NCC. Consolida gli endpoint Private Service Connect condivisi nella rete VPC di routing o host per ridurre i costi orari degli endpoint e del trattamento dati.
  • Gestione del ciclo di vita dello spazio di archiviazione: configura Gestione del ciclo di vita degli oggetti o Autoclass di Cloud Storage sul bucket di importazione dati non elaborati per trasferire i documenti di origine elaborati a classi di archiviazione più fredde o eliminare i file di gestione temporanea dopo la scrittura dei vettori nel datastore RAG.
  • Embedding in batch e memorizzazione nella cache del contesto: per aggiornamenti di grandi dimensioni e non urgenti del corpus RAG nel sottosistema di importazione dati, utilizza la previsione in batch per gli embedding o l'inferenza in batch a un costo inferiore rispetto alle richieste online. Nel sottosistema di pubblicazione, attiva la memorizzazione nella cache del contesto per le istruzioni di sistema ricorrenti e i documenti di riferimento recuperati di frequente per ridurre i costi dei token di input.

Per i principi e i suggerimenti di ottimizzazione dei costi specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: ottimizzazione dei costi nel Well-Architected Framework.

Efficienza operativa

Per gestire e utilizzare in modo efficiente l'infrastruttura di networking e RAG, considera i seguenti suggerimenti:

  • Infrastructure as Code (IaC): automatizza il provisioning del progetto di routing, dei progetti host e di servizio del VPC condiviso, degli hub e degli spoke NCC, degli endpoint Private Service Connect e dei perimetri dei Controlli di servizio VPC utilizzando i moduli Terraform del progetto di base aziendale e di Infrastructure Manager.
  • Risoluzione DNS privata centralizzata: semplifica la gestione del DNS nella tua rete esterna e negli spoke VPC utilizzando le zone private di Cloud DNS e le policy di forwarding in entrata o in uscita nella rete VPC di routing, in modo che i client on-premise e i progetti di servizio risolvano automaticamente l'endpoint Private Service Connect e gli indirizzi IP del bilanciatore del carico delle applicazioni interno.
  • Osservabilità della rete e dell'AI: monitora la connettività ibrida, il traffico degli spoke NCC e i rifiuti delle policy dei Controlli di servizio VPC utilizzando Network Intelligence Center (tra cui Connectivity Tests e Flow Analyzer), Cloud Logging e Cloud Monitoring. Valuta continuamente la pertinenza e la fondatezza del recupero nel sottosistema di gestione utilizzando il Gen AI evaluation service.

Per i principi e i suggerimenti di eccellenza operativa specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: eccellenza operativa nel framework Well-Architected.

Ottimizzazione delle prestazioni

Per ottimizzare le prestazioni dei workload di networking e RAG, tieni presente i seguenti suggerimenti:

  • Larghezza di banda ibrida e co-location regionale: dimensiona i collegamenti VLAN di Cloud Interconnect o i tunnel Cloud VPN per gestire i volumi di caricamento dei dati non elaborati di picco dalla rete esterna senza saturare la larghezza di banda condivisa con le richieste di inferenza interattive. Colloca l'endpoint Private Service Connect regionale, il bucket Cloud Storage, il datastore vettoriale (come Vector Search o AlloyDB per PostgreSQL) e gli endpoint del modello nella regione più vicina al punto di presenza dell'interconnessione ibrida per ridurre al minimo la latenza di round trip della rete.
  • Scalabilità del computing e routing dell'inferenza: se il tuo frontend o il tuo sottosistema di gestione viene eseguito su Cloud Run, configura il numero minimo di istanze e ottimizza le impostazioni di contemporaneità per eliminare la latenza dell'avvio a freddo durante i picchi di traffico. Se pubblichi modelli aperti su GKE, utilizza Inference Gateway per eseguire il routing basato sulla cache KV e sul carico tra i server di modelli.

Per i principi e i suggerimenti di ottimizzazione delle prestazioni specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: ottimizzazione delle prestazioni nel Well-Architected Framework.

Deployment

Questa sezione descrive i passaggi per creare l'applicazione:

  1. Identifica la regione per i workload.
  2. Crea Google Cloud progetti e reti VPC.
  3. Connetti le tue reti esterne alla rete VPC di routing.
  4. Collega le reti utilizzando NCC.
  5. Identifica i componenti per il deployment RAG e crea i service account.
  6. Configura i Controlli di servizio VPC.
  7. Crea il importazione dati dati.
  8. Crea il sottosistema di pubblicazione.
  9. Crea il sottosistema di frontend.
  10. Rendi l'applicazione raggiungibile da internet.

Identifica la regione per i workload

In generale, è consigliabile posizionare la connettività, le subnet VPC e i workload Google Cloud in prossimità delle reti on-premise o di altri client cloud. Per saperne di più su come scegliere una regione per i tuoi workload, consulta Google Cloud Selettore delle regioni e Best practice per la scelta delle regioni di Compute Engine.

Crea Google Cloud progetti e reti VPC

Se la tua organizzazione ha già configurato Cross-Cloud Network per le applicazioni distribuite, il progetto di routing e la rete VPC di routing dovrebbero già esistere.

Crea i progettiGoogle Cloud e una rete VPC nel seguente ordine:

  1. Crea il progetto di routing.
  2. Crea la rete VPC di routing con l'accesso privato Google abilitato.
  3. Crea il progetto RAG.
  4. Promuovi il progetto RAG in modo che diventi un progetto host del VPC condiviso.
  5. Crea il progetto di servizio di importazione dati.
  6. Crea il progetto di servizio di pubblicazione.
  7. Crea il progetto di servizio frontend.
  8. Crea la rete RAG VPC condiviso con l'accesso privato Google abilitato.
  9. Concedi ai progetti di servizio l'autorizzazione per utilizzare la rete RAG.

Connetti le tue reti esterne alla rete VPC di routing

Puoi saltare questo passaggio se hai già configurato la Cross-Cloud Network per le applicazioni distribuite.

Configura la connettività tra le reti esterne e la tua rete di routing. Per comprendere le tecnologie pertinenti, consulta Connettività esterna e ibrida. Per indicazioni su come scegliere un prodotto per la connettività, consulta Scelta di un prodotto per la connettività di rete.

  1. Nel progetto di routing, crea un hub NCC.
  2. Aggiungi le connessioni Cloud Interconnect come spoke di collegamento VLAN o aggiungi le connessioni Cloud VPN come spoke VPN.
  3. Aggiungi la rete VPC RAG e la rete VPC di routing all'hub come spoke VPC.

Identifica i componenti per il deployment RAG e crea i service account

  1. Scegli un deployment RAG e crea un elenco dei componenti necessari.
  2. Identifica l'accesso necessario per ogni componente.
  3. Per ogni componente, crea un service account con le autorizzazioni appropriate. In alcuni casi, ciò significa che concedi a un componente l'autorizzazione di lettura o scrittura in un progetto di servizio diverso.

Questo design presuppone che tu utilizzi un bucket Cloud Storage come componente di input dei dati e un bilanciatore del carico delle applicazioni nel frontend di inferenza. Il resto del design può variare in base alle esigenze.

In teoria, ogni componente viene eseguito come account di servizio autonomo. Assicurati che ogni componente disponga solo delle autorizzazioni IAM minime necessarie per eseguire le funzioni richieste. Ad esempio, un job Cloud Run nel sottosistema di importazione dati deve leggere dal bucket Cloud Storage di input, ma non deve scrivere nel bucket. In questo esempio, il progetto di servizio che esegue il job Cloud Run deve avere l'autorizzazione di sola lettura per il bucket, senza autorizzazione in scrittura.

Configurazione dei Controlli di servizio VPC

  1. Crea un perimetro dei Controlli di servizio VPC attorno al tuo deployment.
  2. Configura le regole di accesso.

Crea il sottosistema di importazione dati

Il sottosistema di importazione dati prende i dati non elaborati dai data engineer e li elabora per l'utilizzo da parte del sottosistema di pubblicazione.

  1. Nel progetto del servizio di importazione dati, crea un bucket Cloud Storage.
  2. Nella rete VPC di routing, crea un endpoint Private Service Connect regionale e connettilo al bucket.
  3. Nella rete esterna, aggiungi una voce DNS per l'endpoint utilizzando l'indirizzo IP e l'URL generati nel passaggio precedente.
  4. Aggiorna le regole firewall di rete esterne per consentire l'accesso all'indirizzo IP dell'endpoint.
  5. Nel progetto di servizio di importazione dati, crea il resto della pipeline di acquisizione in base all'architettura RAG scelta.
  6. Concedi le autorizzazioni IAM in modo che la risorsa pertinente nella pipeline di importazione possa accedere al modello che produce i vettori.
  7. Concedi le autorizzazioni IAM in modo che la risorsa pertinente nella pipeline di importazione possa scrivere nel datastore vettoriale.

Crea il sottosistema di pubblicazione

  1. Nel progetto di servizio di pubblicazione, crea la pipeline di pubblicazione.
  2. Concedi le autorizzazioni IAM in modo che il account di servizio nel sistema di frontend possa accedere all'output del sottosistema di gestione dei servizi.

Crea il sottosistema di frontend

Questa sezione presuppone che tu utilizzi un bilanciatore del carico delle applicazioni interno regionale che utilizza un NEG serverless davanti a Cloud Run. Tuttavia, puoi utilizzare un bilanciatore del carico e un backend diversi.

  1. Crea il codice per il tuo sistema di frontend.
  2. Nel progetto di servizio frontend, esegui il deployment del sistema frontend con bilanciamento del carico, che include il passaggio facoltativo per configurare una policy di sicurezza di Cloud Armor.
  3. Configura il router Cloud nella rete VPC di routing per inoltrare le route dalla rete VPC RAG ai router on-premise. Questa configurazione consente ai client di raggiungere il bilanciatore del carico delle applicazioni.
  4. Nella tua rete esterna, configura le regole firewall per rendere raggiungibile il frontend del bilanciatore del carico dalla tua rete esterna.
  5. Nella tua rete esterna, aggiorna il DNS in modo che punti alla regola di forwarding del bilanciatore del carico delle applicazioni.

Rendi la tua applicazione raggiungibile da internet

Questa sezione è facoltativa.

Questo design presuppone che tu voglia che il tuo servizio sia raggiungibile solo dalla tua rete esterna, ma puoi anche renderlo raggiungibile da internet.

Per rendere il servizio raggiungibile da internet, completa i seguenti passaggi:

  1. Crea un bilanciatore del carico delle applicazioni esterno regionale che punti allo stesso backend a cui punta il bilanciatore del carico delle applicazioni interno. Completa il passaggio facoltativo per configurare una policy di sicurezza di Cloud Armor.
  2. Aggiorna i Controlli di servizio VPC per consentire ai clienti del servizio di raggiungere i servizi di backend.

Passaggi successivi

Collaboratori

Autori:

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

Altri collaboratori: