Connectivité privée pour les applications d'IA générative compatibles avec le RAG

Last reviewed 2026-11-03 UTC

Ce document fournit une architecture de référence que vous pouvez utiliser pour sécuriser l'infrastructure réseau des applications avec génération augmentée par récupération (RAG). Une architecture RAG contient généralement des sous-systèmes distincts pour gérer les flux de traitement des données et de récupération de contenu. Cette architecture de référence montre comment utiliser un VPC partagé pour effectuer les opérations suivantes :

  • Séparez les sous-systèmes à l'aide des autorisations IAM (Identity and Access Management).
  • Connectez les composants d'application à l'aide d'adresses IP privées.

Ce document s'adresse aux architectes, aux développeurs et aux administrateurs réseau et de sécurité. Dans ce document, nous partons du principe que vous avez des connaissances de base en mise en réseau. Ce document ne décrit pas la création d'une application basée sur le RAG.

Architecture

Le schéma suivant illustre l'architecture réseau présentée dans ce document :

Architecture Mise en réseau pour les applications avec RAG.

Connexions et flux de trafic pour l'architecture de mise en réseau.

L'architecture du diagramme précédent présente les composants suivants :

Réseau externe, sur site ou dans un autre cloud

Un réseau externe qui remplit les fonctions suivantes :

  • Fournit une connectivité réseau aux ingénieurs de données qui importent des données RAG brutes.
  • Met fin à la connectivité réseau externe.
  • Héberge des routeurs externes.
  • Fournit une connectivité au point de terminaison Private Service Connect dans le réseau cloud privé virtuel (VPC) de routage Google Cloud .
  • Contient des serveurs DNS qui pointent vers le point de terminaison Private Service Connect.
Projet de routage

Un projet Google Cloud qui effectue les fonctions suivantes :

  • Héberge le réseau VPC de routage, qui se connecte au réseau externe via une connexion Cloud Interconnect ou Cloud VPN.
  • Héberge un hub Network Connectivity Center (NCC) qui connecte le réseau externe, le réseau VPC de routage et les réseaux VPC partagés.
  • Héberge un point de terminaison Private Service Connect qui se connecte à un point de terminaison Cloud Storage régional. Ce point de terminaison permet aux ingénieurs de données d'importer des données RAG dans le bucket Cloud Storage.
Projet hôte de VPC partagé RAG

Héberge un réseau VPC partagé qui héberge l'équilibreur de charge d'application interne du service d'interface et tous les autres services nécessitant un réseau VPC. Tous les projets de service ont accès à ce réseau VPC partagé.

Projet de service d'ingestion de données

Contient un bucket Cloud Storage pour l'entrée de données brutes. Contient le sous-système d'ingestion de données, qui comprend les composants suivants :

  • Traitement de l'ingestion : lit les données brutes et les traite.
  • Sortie d'ingestion : écrit dans le datastore final.
Projet de service de diffusion

Contient le sous-système de mise en service, qui inclut les composants suivants fournissant les services et les fonctions d'inférence et d'interaction :

  • Datastore RAG contenant la sortie du sous-système d'ingestion de données.
  • Processus de mise en service qui alimentent le modèle en combinant la requête d'inférence avec les données du datastore RAG.
  • Modèle utilisé par le sous-système de diffusion pour créer des vecteurs à partir des données RAG importées et pour traiter la requête de l'utilisateur final.
Projet de service d'interface

Contient le sous-système d'interface, qui est un équilibreur de charge d'application devant un service d'interaction utilisateur qui s'exécute sur Cloud Run ou Google Kubernetes Engine (GKE).

Le projet contient également Google Cloud Armor, qui permet de limiter l'accès à votre service. Si vous souhaitez fournir un accès depuis Internet, vous pouvez ajouter un équilibreur de charge d'application externe régional.

Périmètre VPC Service Controls

Aide à protéger contre l'exfiltration de données. Les données stockées dans des buckets Cloud Storage ne peuvent pas être copiées en dehors du périmètre, et les opérations du plan de contrôle sont protégées.

Les sections suivantes décrivent les connexions et les flux de trafic de l'architecture.

Connexions entre les composants

Cette section décrit les connexions entre les composants et les réseaux de cette architecture.

Réseau externe vers le réseau VPC de routage

Les réseaux externes se connectent au réseau VPC de routage Google Cloud via Cloud Interconnect ou Cloud VPN, qui sont des spokes hybrides d'un hub NCC.

Les routeurs Cloud Router du réseau VPC de routage et les routeurs externes du réseau externe échangent des routes BGP (Border Gateway Protocol) :

  • Les routeurs des réseaux externes annoncent les routes des sous-réseaux externes au routeur Cloud Router du VPC de routage. Vous pouvez exprimer la préférence des routes à l'aide de métriques et d'attributs BGP.
  • Les routeurs Cloud Router du réseau VPC de routage annoncent les routes des préfixes des VPC de Google Cloudaux réseaux externes.

Réseau VPC de routage vers un réseau VPC partagé

Vous connectez le réseau VPC de routage et le réseau VPC RAG à l'aide des spokes VPC NCC du hub NCC. Le hub héberge également les spokes hybrides vers le réseau externe.

De ressource à ressource au sein du réseau VPC partagé

Dans cette conception, un bucket Cloud Storage reçoit des données du réseau externe. Les requêtes d'inférence passent par un équilibreur de charge d'application interne régional. Pour le reste de votre système, vous disposez des options suivantes :

  • Hébergez tout dans l'infrastructure SaaS de Google, comme les buckets Cloud Storage, Gemini Enterprise Agent Platform, Cloud Run et Pub/Sub. Dans ce cas, les composants communiquent via l'infrastructure Google privée.
  • Hébergez tout dans des charges de travail qui s'exécutent dans des VM Compute Engine, des clusters GKE, des bases de données Cloud SQL ou d'autres composants qui s'exécutent dans des réseaux VPC. Dans ce cas, les systèmes communiquent à l'aide d'adresses IP privées sur les réseaux que vous associez via NCC ou l'appairage de réseaux VPC.
  • Utilisez une combinaison de services entièrement gérés, de plate-forme et d'infrastructure. Dans ce cas, vous pouvez établir des connexions entre un réseau VPC et un service entièrement géré à l'aide des méthodes suivantes :
    • Accès privé à Google : avec cette méthode, les charges de travail qui n'ont pas d'adresse IP externe et qui s'exécutent dans des réseaux VPC peuvent accéder aux API Google. Cet accès s'effectue en interne sur l'infrastructure Google, et ce processus n'expose pas ce trafic à Internet.
    • Private Service Connect : cette méthode vous permet de créer un point de terminaison dans votre projet de service pour des services tels qu'AlloyDB pour PostgreSQL hébergés dans des réseaux VPC gérés.

Équilibreur de charge d'application du service d'interface externe au réseau

Le point de terminaison de l'équilibreur de charge d'application interne régional est une adresse IP du réseau RAG. Le réseau RAG, le réseau de routage et les connexions hybrides au réseau externe sont tous des spokes du même hub NCC. Par conséquent, vous pouvez demander à NCC d'exporter toutes les sous-plages du spoke vers le hub, qui les réexporte ensuite vers les autres réseaux spoke. Les utilisateurs finaux du système peuvent ensuite accéder au service à équilibrage de charge à partir du réseau externe.

Flux de trafic

Les flux de trafic de cette architecture de référence incluent un flux de données RAG et un flux d'inférence.

Flux de population RAG

Ce flux décrit comment les données RAG circulent dans le système, des ingénieurs de données au stockage vectoriel.

  1. Depuis le réseau externe, les ingénieurs de données importent des données brutes via la connexion Cloud Interconnect ou la connexion Cloud VPN. Les données sont importées vers le point de terminaison Private Service Connect dans le réseau VPC de routage.
  2. Les données transitent par l'infrastructure interne de Google jusqu'au bucket Cloud Storage du projet de service d'ingestion de données.

  3. Dans le projet de service d'ingestion de données, les données transitent entre les systèmes à l'aide de l'une des méthodes suivantes :

    • Accès privé à Google
    • Points de terminaison Private Service Connect
    • Infrastructure Google directe

    La méthode dépend de l'hébergement des systèmes dans des réseaux VPCGoogle Cloud ou directement dansGoogle Cloud. Dans le cadre de ce flux, le sous-système d'ingestion de données transmet des données RAG fragmentées au modèle, qui produit des vecteurs pour chaque fragment.

  4. Le sous-système d'ingestion de données écrit les données vectorielles et les données fragmentées dans le datastore approprié.

Flux d'inférence

Ce flux décrit les demandes des clients.

  1. Depuis le réseau externe, un client envoie une requête à l'adresse IP du service.
  2. La requête transite par la connexion Cloud Interconnect ou Cloud VPN vers le réseau VPC de routage.
  3. La requête transite par la connexion spoke VPC vers le réseau VPC RAG.
  4. La requête du client arrive au niveau de l'équilibreur de charge d'application, qui la transmet au sous-système d'interface.
  5. Le sous-système d'interface transfère la requête au sous-système de mise en service.
  6. Le sous-système de diffusion enrichit la requête en utilisant les données contextuelles pertinentes du datastore.
  7. Le sous-système de mise en service envoie le prompt augmenté au modèle d'IA, qui génère une réponse.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants :

  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud . Le VPC inclut l'appairage de réseaux VPC, Private Service Connect, l'accès aux services privés et le VPC partagé.
  • VPC partagé : fonctionnalité de cloud privé virtuel qui vous permet de connecter des ressources de plusieurs projets à un réseau VPC commun à l'aide d'adresses IP internes de ce réseau.
  • Private Service Connect : fonctionnalité qui permet aux clients d'accéder à des services gérés en mode privé depuis leur réseau VPC.
  • Accès privé à Google : fonctionnalité qui permet aux instances de VM sans adresse IP externe d'atteindre les adresses IP externes des API et services Google.
  • Cloud Interconnect : service qui étend votre réseau externe au réseau Google via une connexion à haute disponibilité et à faible latence.
  • Cloud VPN : service qui étend votre réseau de pairs au réseau Google de façon sécurisée, via un tunnel VPN IPsec.
  • Cloud Router : offre distribuée et entièrement gérée qui fournit des fonctionnalités de speaker et de répondeur BGP (Border Gateway Protocol). Cloud Router fonctionne avec Cloud Interconnect, Cloud VPN et les appareils de routeur pour créer des routes dynamiques dans les réseaux VPC en fonction des routes apprises personnalisées et reçues par BGP.
  • Network Connectivity Center : framework d'orchestration qui simplifie la connectivité réseau entre les ressources spoke connectées à une ressource de gestion centrale appelée hub.
  • VPC Service Controls : fonctionnalité de mise en réseau gérée qui minimise les risques d'exfiltration de données pour vos ressources Google Cloud .
  • Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
  • Model Armor : service qui protège vos ressources d'IA générative et d'IA agentique contre l'injection de prompt, les fuites de données sensibles et les contenus nuisibles.
  • Google Cloud Armor : service de sécurité réseau qui propose des règles de pare-feu d'application Web (WAF) et aide à se protéger contre les attaques DDoS et d'applications.
  • Cloud Storage : store d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis et en dehors de Google Cloud, et sont répliquées sur plusieurs emplacements à des fins de redondance.

Cas d'utilisation

Cette architecture est conçue pour les scénarios d'entreprise dans lesquels les communications d'entrée, de sortie et internes du système global doivent utiliser des adresses IP privées et ne doivent pas transiter par Internet :

  • Entrée privée : les données importées ne transitent pas par Internet. À la place, vous hébergez votre bucket Cloud Storage derrière un point de terminaison Private Service Connect dans votre réseau VPC de routage Google Cloud. Vous copiez les données RAG sur votre connexion Cloud Interconnect ou Cloud VPN en n'utilisant que des adresses IP privées.
  • Connectivité interservices privée : les services communiquent entre eux via les interfaces internes de Google ou via des adresses privées internes à vos réseaux VPC.
  • Sortie privée : les résultats d'inférence ne sont pas accessibles sur Internet, sauf si vous choisissez de configurer cet accès. Par défaut, seuls les utilisateurs du réseau externe désigné peuvent atteindre le point de terminaison privé de votre service.

Alternatives de conception

Cette section présente d'autres approches de conception de réseau que vous pouvez envisager pour votre application compatible RAG dans Google Cloud.

Rendre le service accessible publiquement

Dans l'architecture présentée dans ce document, seuls les utilisateurs de votre réseau interne peuvent envoyer des requêtes à votre application. Si votre application doit être accessible aux clients sur Internet, utilisez un équilibreur de charge d'application externe régional.

Utiliser GKE Inference Gateway

Si votre sous-système d'interface s'exécute sur GKE, vous pouvez utiliser GKE Inference Gateway au lieu d'un équilibreur de charge d'application.

Considérations de conception

Cette section fournit des conseils supplémentaires pour vous aider à déployer la mise en réseau afin de prendre en charge la connectivité privée pour une architecture compatible avec le RAG. Ces conseils peuvent vous aider à répondre à vos exigences spécifiques en termes de sécurité, de confidentialité, de conformité, de fiabilité, d'optimisation des coûts, d'efficacité opérationnelle et d'optimisation des performances. Les conseils de cette section ne sont pas exhaustifs. Pour votre déploiement particulier, vous devrez peut-être prendre en compte d'autres facteurs de conception qui ne sont pas abordés dans cette section.

Sécurité, confidentialité et conformité

Pour sécuriser votre architecture exploitant le RAG et répondre à vos exigences de confidentialité et de conformité, tenez compte des recommandations suivantes :

  • Filtrage des prompts et des réponses : déployez Model Armor devant le modèle d'IA pour évaluer les prompts entrants et les résultats sortants afin de détecter les injections de prompts, les tentatives de jailbreak, les fuites de données sensibles et les cas de non-respect des règles d'IA responsable. Vous pouvez intégrer Model Armor directement à Gemini Enterprise Agent Platform ou associer Model Armor à l'équilibreur de charge d'application en utilisant les extensions de trafic Service Extensions pour rejeter les requêtes inappropriées avant qu'elles n'atteignent le sous-système de diffusion. Pour accéder aux points de terminaison régionaux Model Armor de manière privée depuis un réseau VPC sans erreurs de certificat lors de l'utilisation de l'accès privé à Google ou de VPC Service Controls, créez un point de terminaison Private Service Connect régional pour les API Model Armor.
  • Microsegmentation du périmètre et du réseau : cette architecture utilise VPC Service Controls pour empêcher l'exfiltration non autorisée de données dans vos projets de service. En plus des périmètres de service, utilisez les stratégies de pare-feu hiérarchiques et réseau de Cloud Next Generation Firewall avec des tags régis par IAM pour limiter le trafic est-ouest entre les charges de travail d'ingestion, de diffusion et d'interface des données dans le réseau VPC partagé.
  • Identité et accès zéro confiance : appliquez un contrôle des accès zéro confiance sur l'équilibreur de charge d'application interne ou l'équilibreur de charge d'application externe régional d'interface en activant Identity-Aware Proxy (IAP) afin que seuls les utilisateurs authentifiés et autorisés puissent interroger l'application RAG. Combinez des comptes de service avec le moindre privilège avec des stratégies Limite d'accès des principaux pour limiter les ressources auxquelles chaque compte principal de sous-système peut accéder. Si votre sous-système de diffusion orchestre des agents autonomes ou des outils MCP (Model Context Protocol) sur des réseaux privés, utilisez Agent Identity et Agent Gateway pour authentifier et gérer le trafic entre les agents et les outils.
  • Confidentialité et chiffrement des données : utilisez Sensitive Data Protection dans le sous-système d'ingestion de données pour inspecter, classer et anonymiser les informations permettant d'identifier personnellement l'utilisateur dans les documents bruts importés dans le bucket Cloud Storage avant de générer des embeddings et d'écrire dans le datastore RAG. Si la conformité réglementaire nécessite de contrôler les clés de chiffrement, configurez des clés de chiffrement gérées par le client (CMEK) dans Cloud Key Management Service (Cloud KMS) pour le bucket Cloud Storage, le datastore vectoriel et les points de terminaison du modèle.

Cette conception utilise des principes de sécurité établis pour vous aider à sécuriser vos charges de travail RAG. Pour connaître les principes et recommandations de sécurité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : sécurité dans le Well-Architected Framework.

Fiabilité

Pour créer et exploiter une infrastructure réseau fiable pour votre application compatible avec le RAG, tenez compte des recommandations suivantes :

  • Connectivité hybride redondante : configurez des rattachements de VLAN Cloud Interconnect ou des tunnels VPN haute disponibilité redondants sur plusieurs domaines et régions de disponibilité de périphérie, associés à des routeurs Cloud Router redondants pour le basculement BGP dynamique entre votre réseau externe et le réseau VPC de routage.
  • Équilibrage de charge et stockage multirégionaux : pour une haute disponibilité entre les régions, utilisez un équilibreur de charge d'application interne interrégional pour répartir le trafic d'inférence entre les backends d'interface et de diffusion dans plusieurs régions, et utilisez des buckets Cloud Storage birégionaux ou multirégionaux avec des datastores vectoriels répliqués.
  • Ingestion asynchrone et résilience des quotas : dissociez les importations de données brutes dans le bucket Cloud Storage du pipeline de traitement d'ingestion en utilisant Pub/Sub avec des files d'attente de lettres mortes ou des stratégies de nouvelle tentative Eventarc afin que les échecs d'embedding ou d'indexation temporaires puissent être relancés sans perte de données. Pour une latence et une capacité prévisibles lors de la génération et de l'inférence d'embeddings à volume élevé, réservez un débit provisionné et implémentez un intervalle exponentiel entre les tentatives pour les réponses HTTP 429.

Pour connaître les principes et recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : fiabilité dans le Well-Architected Framework.

Optimisation des coûts

Pour optimiser le coût de création et d'exécution de votre architecture compatible avec le RAG, tenez compte des recommandations suivantes :

  • Sélection de la sortie réseau et des points de terminaison : placez le réseau VPC de routage, les points de terminaison Private Service Connect, le bucket Cloud Storage, le datastore RAG et les points de terminaison du modèle dans la même région pour éviter les frais de transfert de données interrégionaux entre les spokes NCC. Regroupez les points de terminaison Private Service Connect partagés dans le réseau VPC de routage ou hôte pour réduire les frais horaires de traitement des données et des points de terminaison.
  • Gestion du cycle de vie du stockage : configurez la gestion du cycle de vie des objets Cloud Storage ou la classe automatique sur le bucket d'ingestion des données brutes pour transférer les documents sources traités vers des classes de stockage plus froides ou supprimer les fichiers de préproduction une fois les vecteurs écrits dans le datastore RAG.
  • Embedding par lot et cache de contexte : pour les mises à jour volumineuses et non urgentes du corpus RAG dans le sous-système d'ingestion de données, utilisez la prédiction par lot pour les embeddings ou l'inférence par lot à un coût inférieur à celui des requêtes en ligne. Dans le sous-système de diffusion, activez la mise en cache du contexte pour les instructions système récurrentes et les documents de référence fréquemment récupérés afin de réduire les coûts des jetons d'entrée.

Pour connaître les principes et recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : optimisation des coûts dans le Well-Architected Framework.

Efficacité opérationnelle

Pour exploiter et gérer efficacement votre infrastructure réseau et RAG, tenez compte des recommandations suivantes :

  • Infrastructure as Code (IaC) : automatisez le provisionnement du projet de routage, des projets hôtes et de service de VPC partagé, du hub et des spokes NCC, des points de terminaison Private Service Connect et des périmètres VPC Service Controls à l'aide des modules Terraform du plan des fondations d'entreprise et d'Infrastructure Manager.
  • Résolution DNS privée centralisée : simplifiez la gestion DNS sur votre réseau externe et vos spokes VPC en utilisant des zones privées Cloud DNS et des règles de transfert entrant ou sortant dans le réseau VPC de routage afin que les clients sur site et les projets de service résolvent automatiquement le point de terminaison Private Service Connect et les adresses IP de l'équilibreur de charge d'application interne.
  • Observabilité du réseau et de l'IA : surveillez la connectivité hybride, le trafic des spokes NCC et les refus de règles VPC Service Controls à l'aide de Network Intelligence Center (y compris les tests de connectivité et Flow Analyzer), Cloud Logging et Cloud Monitoring. Évaluez en continu la pertinence et l'ancrage de la récupération dans le sous-système de diffusion à l'aide du service d'évaluation de l'IA générative.

Pour connaître les principes et recommandations d'excellence opérationnelle spécifiques aux charges de travail d'IA et de ML, consultez Perspective IA et ML : excellence opérationnelle dans le Well-Architected Framework.

Optimisation des performances

Pour optimiser les performances de vos charges de travail de mise en réseau et de RAG, tenez compte des recommandations suivantes :

  • Bande passante hybride et colocalisation régionale : dimensionnez vos rattachements de VLAN Cloud Interconnect ou vos tunnels Cloud VPN pour gérer les volumes d'importation de données brutes de pointe depuis votre réseau externe sans saturer la bande passante partagée avec les requêtes d'inférence interactives. Colocalisez le point de terminaison Private Service Connect régional, le bucket Cloud Storage, le datastore vectoriel (tel que Vector Search ou AlloyDB pour PostgreSQL) et les points de terminaison de modèle dans la région la plus proche de votre point de présence d'interconnexion hybride afin de minimiser la latence des allers-retours réseau.
  • Scaling du calcul et routage de l'inférence : si votre sous-système d'interface ou de diffusion s'exécute sur Cloud Run, configurez le nombre minimal d'instances et ajustez les paramètres de simultanéité pour éliminer la latence de démarrage à froid lors des pics de trafic. Si vous diffusez des modèles ouverts sur GKE, utilisez Inference Gateway pour effectuer un routage tenant compte du cache KV et de la charge sur les serveurs de modèles.

Pour connaître les principes et recommandations d'optimisation des performances spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : optimisation des performances dans le Well-Architected Framework.

Déploiement

Cette section décrit les étapes à suivre pour créer votre application :

  1. Identifiez la région des charges de travail.
  2. Créer Google Cloud des projets et des réseaux VPC.
  3. Connectez vos réseaux externes à votre réseau VPC de routage.
  4. Associez des réseaux à l'aide de NCC.
  5. Identifier les composants pour le déploiement de RAG et créer des comptes de service
  6. Configurez VPC Service Controls.
  7. Créer le sous-système d'ingestion de données
  8. Créer le sous-système de diffusion
  9. Créer le sous-système d'interface
  10. Rendre votre application accessible depuis Internet

Identifier la région pour les charges de travail

En général, vous devez placer la connectivité, les sous-réseaux VPC et les charges de travail Google Cloudà proximité de vos réseaux sur site ou d'autres clients cloud. Pour savoir comment choisir une région pour vos charges de travail, consultez Google Cloud Sélecteur de région et Bonnes pratiques pour la sélection des régions Compute Engine.

Créer des projets Google Cloud et des réseaux VPC

Si votre organisation a déjà configuré un réseau Cross-Cloud pour les applications distribuées, votre projet de routage et votre réseau VPC de routage devraient déjà exister.

Créez les projetsGoogle Cloud et un réseau VPC dans l'ordre suivant :

  1. Créez le projet de routage.
  2. Créez le réseau VPC de routage avec l'accès privé à Google activé.
  3. Créez le projet RAG.
  4. Promouvoir le projet RAG en tant que projet hôte de VPC partagé.
  5. Créez le projet de service d'ingestion de données.
  6. Créez le projet de service de diffusion.
  7. Créez le projet de service d'interface.
  8. Créez le réseau RAG VPC partagé avec l'accès privé à Google activé.
  9. Autorisez les projets de service à utiliser le réseau RAG.

Connecter vos réseaux externes à votre réseau VPC de routage

Vous pouvez ignorer cette étape si vous avez déjà configuré Cross-Cloud Network pour les applications distribuées.

Configurez la connectivité entre les réseaux externes et votre réseau de routage. Pour comprendre les technologies concernées, consultez Connectivité externe et hybride. Pour savoir comment choisir un produit de connectivité, consultez Choisir un produit de connectivité réseau.

  1. Dans le projet de routage, créez un hub NCC.
  2. Ajoutez les connexions Cloud Interconnect en tant que spokes de rattachement de VLAN ou ajoutez les connexions Cloud VPN en tant que spokes VPN.
  3. Ajoutez le réseau VPC RAG et le réseau VPC de routage au hub en tant que spokes VPC.

Identifier les composants pour le déploiement de RAG et créer des comptes de service

  1. Choisissez un déploiement RAG et dressez la liste des composants dont il a besoin.
  2. Identifiez l'accès dont chaque composant a besoin.
  3. Pour chaque composant, créez un compte de service avec les autorisations appropriées. Dans certains cas, cela signifie que vous autorisez un composant à lire ou à écrire dans un autre projet de service.

Cette conception suppose que vous utilisez un bucket Cloud Storage comme composant d'entrée de données et que vous utilisez un équilibreur de charge d'application dans votre interface d'inférence. Le reste de votre conception peut varier selon vos besoins.

Idéalement, chaque composant s'exécute en tant que compte de service distinct. Assurez-vous que chaque composant ne dispose que des autorisations IAM minimales nécessaires pour exécuter les fonctions requises. Par exemple, un job Cloud Run dans le sous-système d'ingestion de données doit lire le bucket Cloud Storage d'entrée, mais il n'a pas besoin d'écrire dans le bucket. Dans cet exemple, le projet de service qui exécute le job Cloud Run doit disposer d'une autorisation de lecture seule sur le bucket, sans autorisation d'écriture.

Configurez VPC Service Controls

  1. Créez un périmètre VPC Service Controls autour de votre déploiement.
  2. Configurez les règles d'accès.

Créer le sous-système d'ingestion de données

Le sous-système d'ingestion de données récupère les données brutes des ingénieurs de données et les traite pour qu'elles soient utilisées par le sous-système de mise en service.

  1. Dans le projet de service d'ingestion de données, créez un bucket Cloud Storage.
  2. Dans le réseau VPC de routage, créez un point de terminaison Private Service Connect régional, puis connectez-le au bucket.
  3. Dans le réseau externe, ajoutez une entrée DNS pour le point de terminaison à l'aide de l'adresse IP et de l'URL générées à l'étape précédente.
  4. Mettez à jour les règles de pare-feu du réseau externe pour autoriser l'accès à l'adresse IP du point de terminaison.
  5. Dans le projet de service d'ingestion de données, créez le reste de votre pipeline d'ingestion en fonction de l'architecture RAG que vous avez choisie.
  6. Accordez des autorisations IAM pour que la ressource concernée du pipeline d'ingestion puisse accéder au modèle qui produit les vecteurs.
  7. Accordez des autorisations IAM pour que la ressource concernée dans le pipeline d'ingestion puisse écrire dans le datastore vectoriel.

Créer le sous-système de mise en service

  1. Dans le projet de service de diffusion, créez votre pipeline de diffusion.
  2. Accordez des autorisations IAM pour que le compte de service du système d'interface puisse accéder au résultat du sous-système de diffusion.

Créer le sous-système d'interface

Cette section part du principe que vous utilisez un équilibreur de charge d'application interne régional qui utilise un NEG sans serveur devant Cloud Run. Toutefois, vous pouvez utiliser un équilibreur de charge et un backend différents.

  1. Créez le code de votre système d'interface.
  2. Dans le projet de service d'interface, déployez votre système d'interface à équilibrage de charge, qui inclut l'étape facultative de configuration d'une stratégie de sécurité Cloud Armor.
  3. Configurez Cloud Router dans le réseau VPC de routage pour transférer les routes du réseau VPC RAG vers les routeurs sur site. Cette configuration permet aux clients d'accéder à l'équilibreur de charge d'application.
  4. Dans votre réseau externe, configurez les règles de pare-feu pour que l'interface de l'équilibreur de charge soit accessible depuis votre réseau externe.
  5. Dans votre réseau externe, mettez à jour le DNS pour qu'il pointe vers la règle de transfert de l'équilibreur de charge d'application.

Rendre votre application accessible depuis Internet

Cette rubrique est facultative.

Cette conception suppose que vous souhaitez que votre service ne soit accessible qu'à partir de votre réseau externe, mais vous pouvez également le rendre accessible depuis Internet.

Pour rendre le service accessible depuis Internet, procédez comme suit :

  1. Créez un équilibreur de charge d'application externe régional qui pointe vers le même backend que l'équilibreur de charge d'application interne. Effectuez l'étape facultative pour configurer une stratégie de sécurité Cloud Armor.
  2. Mettez à jour VPC Service Controls pour permettre aux clients du service d'accéder aux services de backend.

Étapes suivantes

Contributeurs

Auteurs :

  • Deepak Michael | Ingénieur client spécialiste en gestion des réseaux
  • Mark Schlagenhauf | Rédacteur technique, Mise en réseau

Autres contributeurs :