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 de 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 le VPC partagé pour effectuer les opérations suivantes :
- Créez une séparation entre les sous-systèmes à l'aide des autorisations Identity and Access Management (IAM).
- Connectez les composants de l'application à l'aide d'adresses IP privées.
Ce document s'adresse aux architectes, aux développeurs, ainsi qu'aux administrateurs réseau et de sécurité. Dans ce document, nous partons du principe que vous avez des connaissances de base sur les réseaux. Ce document ne décrit pas la création d'une application basée sur la RAG.
Architecture
Le schéma suivant illustre l'architecture réseau présentée dans ce document :
L'architecture du diagramme précédent est constituée des composants suivants :
| Composant | Objectif |
|---|---|
| Réseau externe, sur site ou dans un autre cloud |
|
| Projet de routage |
|
| Projet hôte de VPC partagé RAG | Héberge un réseau VPC partagé qui héberge l'équilibreur de charge du service d'interface et tous les autres services qui ont besoin d'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 les données brutes en entrée. Contient le sous-système d'ingestion de données, qui inclut les composants suivants :
|
| Projet de service de diffusion |
Contient le sous-système de diffusion, qui inclut les composants suivants qui fournissent les services et les fonctions d'inférence et d'interaction :
|
| Projet de service de frontend |
Contient le sous-système de diffusion, qui est un équilibreur de charge 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 les 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 VPN haute disponibilité, qui sont des spokes hybrides d'un hub Network Connectivity Center.
Les routeurs cloud 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 VPC de routage. Vous pouvez exprimer la préférence des routes à l'aide des métriques et des attributs BGP.
- Les routeurs cloud du réseau VPC de routage annoncent les routes pour les préfixes des VPC de Google Cloudaux réseaux externes.
Router un réseau VPC 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 Network Connectivity Center du hub Network Connectivity Center. Le hub héberge également les spokes hybrides vers le réseau externe.
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 transitent 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, Vertex AI, Cloud Run et Pub/Sub. Dans ce cas, les composants communiquent via l'infrastructure Google privée.
- Hébergez tout dans les charges de travail exécutées dans des VM Compute Engine, des clusters GKE, des bases de données Cloud SQL ou d'autres composants exécutés 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 Network Connectivity Center ou l'appairage de réseaux VPC.
- Utilisez un mélange 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 : cette méthode permet aux charges de travail qui n'ont pas d'adresses IP externes et qui s'exécutent dans des réseaux VPC d'accéder aux API Google. Cet accès se fait en interne via 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, qui sont hébergés dans des réseaux VPC gérés.
Équilibreur de charge réseau externe vers le service de frontend
Le point de terminaison de l'équilibreur de charge d'application interne régional est une adresse IP dans le 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 Network Connectivity Center. Par conséquent, vous pouvez demander à Network Connectivity Center d'exporter toutes les plages de sous-réseaux de spoke vers le hub, qui les réexporte ensuite vers les autres réseaux de spoke. Les utilisateurs finaux du système peuvent ensuite accéder au service à équilibrage de charge depuis le 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.
- Depuis le réseau externe, les ingénieurs des données importent les données brutes via la connexion Cloud Interconnect ou Cloud VPN. Les données sont importées dans le point de terminaison Private Service Connect du réseau VPC de routage.
- Les données transitent par l'infrastructure interne de Google vers le bucket Cloud Storage du projet de service d'ingestion de données.
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 ce flux, le sous-système d'ingestion de données fournit des données RAG segmentées au modèle, qui produit des vecteurs pour chaque segment.
Le sous-système d'ingestion de données écrit les données vectorielles et les données segmentées dans le datastore approprié.
Flux d'inférence
Ce flux décrit les demandes des clients.
- Depuis le réseau externe, un client envoie une requête à l'adresse IP du service.
- La requête transite par la connexion Cloud Interconnect ou Cloud VPN vers le réseau VPC de routage.
- La requête transite par la connexion spoke du VPC vers le réseau VPC RAG.
- La requête du client arrive à l'équilibreur de charge, qui la transmet au sous-système de l'interface.
- Le sous-système d'interface transfère la requête au sous-système de mise en service.
- Le sous-système de diffusion augmente la requête en utilisant les données contextuelles pertinentes du datastore.
- Le sous-système de mise en service envoie la requête augmentée au modèle d'IA, qui génère une réponse.
Produits utilisés
Cette architecture de référence utilise les produits suivants : Google Cloud
- 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 Virtual Private Cloud qui vous permet de connecter des ressources provenant de plusieurs projets à un réseau VPC commun en utilisant les 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'accéder aux 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 de manière sécurisée votre réseau de pairs au réseau de Google 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 appliances de routeur pour créer des routes dynamiques dans les réseaux VPC en fonction des routes reçues par BGP et des routes apprises personnalisées.
- 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é 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 agentive contre l'injection de requêtes, 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 où 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 sur Internet. À la place, 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 utilisant uniquement des adresses IP privées.
- Connectivité privée entre les services : les services communiquent entre eux via les interfaces internes de Google ou à l'aide d'adresses privées internes à vos réseaux VPC.
- Sortie privée : les résultats de l'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 accéder au 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 au public
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 de frontend s'exécute sur GKE, vous pouvez utiliser une passerelle d'inférence 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 RAG. Ces conseils peuvent vous aider à répondre à vos exigences spécifiques en termes de sécurité et de conformité, de fiabilité, de coût et de performances. Les conseils de cette section ne sont pas exhaustifs. Pour votre déploiement spécifique, 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é
Dans la plupart des cas, vous déployez Model Armor devant le modèle d'IA pour évaluer à la fois les requêtes entrantes et les résultats sortants. Model Armor permet d'éviter les risques potentiels et de garantir des pratiques d'IA responsable.
Pour rejeter les requêtes inappropriées avant qu'elles n'atteignent le sous-système de diffusion, vous pouvez associer Model Armor à l'équilibreur de charge.
Cette architecture utilise VPC Service Controls, qui permet d'empêcher l'exfiltration non autorisée de données.
Cette conception utilise des principes de sécurité établis pour 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 framework Well-Architected.
Optimisation des coûts
Pour obtenir des principes et des 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 framework Well-Architected.
Optimisation des performances
Pour obtenir des principes et des 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 framework Well-Architected.
Déploiement
Cette section décrit les étapes à suivre pour créer votre application :
- Identifiez la région des charges de travail.
- Créez des projets Google Cloud et des réseaux VPC.
- Connectez vos réseaux externes à votre réseau VPC de routage.
- Associez des réseaux à l'aide de Network Connectivity Center.
- Identifiez les composants pour le déploiement RAG et créez des comptes de service.
- Configurez VPC Service Controls.
- Créez le sous-système d'ingestion de données.
- Créez le sous-système de diffusion.
- Créez le sous-système de l'interface.
- Rendez votre application accessible depuis Internet.
Identifier la région des 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 le sélecteur de régionsGoogle Cloud et les bonnes pratiques pour la sélection des régions Compute Engine.
Créer des projets et des réseaux VPC Google Cloud
Si votre organisation a déjà configuré un réseau multicloud 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 :
- Créez le projet de routage.
- Créez le réseau VPC de routage avec l'accès privé à Google activé.
- Créez le projet RAG.
- Définissez le projet RAG comme projet hôte de VPC partagé.
- Créez le projet de service d'ingestion de données.
- Créez le projet de service de diffusion.
- Créez le projet de service de frontend.
- Créez le réseau RAG VPC partagé avec l'accès privé à Google activé.
- 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 obtenir des conseils sur le choix d'un produit de connectivité, consultez Choisir un produit de connectivité réseau.
Associer des réseaux à l'aide de Network Connectivity Center
- Dans le projet de routage, créez un hub Network Connectivity Center.
- Ajoutez les connexions Cloud Interconnect en tant que spokes de rattachement de VLAN ou ajoutez les connexions Cloud VPN en tant que spokes de VPN.
- 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 RAG et créer des comptes de service
- Choisissez un déploiement RAG et dressez la liste des composants dont il a besoin.
- Identifiez l'accès dont chaque composant a besoin.
- Pour chaque composant, créez un compte de service avec les autorisations appropriées. Dans certains cas, cela signifie que vous accordez à un composant l'autorisation de lire ou d'é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 un équilibreur de charge dans votre frontend 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 n'a pas besoin d'y écrire. Dans cet exemple, le projet de service qui exécute le job Cloud Run ne doit disposer que de l'autorisation de lecture du bucket, et non de l'autorisation d'écriture.
Configurez VPC Service Controls
- Créez un périmètre VPC Service Controls autour de votre déploiement.
- Configurer 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 prend les données brutes des ingénieurs de données et les traite pour qu'elles puissent être utilisées par le sous-système de mise en service.
- Dans le projet de service d'ingestion de données, créez un bucket Cloud Storage.
- Dans le réseau VPC de routage, créez un point de terminaison Private Service Connect régional et connectez-le au bucket.
- Dans le réseau externe, ajoutez une entrée DNS pour le point de terminaison en utilisant l'adresse IP et l'URL générées à l'étape précédente.
- Mettez à jour les règles de pare-feu du réseau externe pour autoriser l'accès à l'adresse IP du point de terminaison.
- Dans le projet de service d'ingestion de données, développez le reste de votre pipeline d'ingestion en fonction de l'architecture RAG choisie.
- Accordez des autorisations IAM afin que la ressource concernée du pipeline d'ingestion puisse accéder au modèle qui produit les vecteurs.
- Accordez des autorisations IAM pour que la ressource concernée du pipeline d'ingestion puisse écrire dans le datastore vectoriel.
Créer le sous-système de diffusion
- Dans le projet de service de diffusion, créez votre pipeline de diffusion.
- Accordez des autorisations IAM afin que le compte de service du système frontend puisse accéder à la sortie du sous-système de diffusion.
Créer le sous-système de l'interface
Cette section suppose 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 autre équilibreur de charge et un autre backend.
- Créez le code pour votre système d'interface.
- Dans le projet de service de frontend, déployez votre système de frontend à équilibrage de charge, qui inclut l'étape facultative de configuration d'une stratégie de sécurité Cloud Armor.
- 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.
- Dans votre réseau externe, configurez les règles de pare-feu pour rendre le frontend de l'équilibreur de charge accessible depuis votre réseau externe.
- Dans votre réseau externe, mettez à jour le DNS pour qu'il pointe vers la règle de transfert de l'équilibreur de charge.
Rendre votre application accessible depuis Internet
Cette rubrique est facultative.
Cette conception suppose que vous souhaitez que votre service soit accessible uniquement depuis votre réseau externe, mais vous pouvez également le rendre accessible depuis Internet.
Pour rendre le service accessible depuis Internet, procédez comme suit :
- Créez un équilibreur de charge d'application externe régional qui pointe vers le même backend que l'équilibreur de charge interne. Suivez l'étape facultative pour configurer une stratégie de sécurité Cloud Armor.
- Mettez à jour VPC Service Controls pour permettre aux clients du service d'accéder aux services de backend.
Étapes suivantes
- Découvrez Cross-Cloud Network pour les applications distribuées.
- Découvrez comment héberger des applications et des agents d'IA sur Cloud Run.
- Découvrez les bonnes pratiques d'IA responsable et les filtres de sécurité de Vertex AI.
- Découvrez les bonnes pratiques concernant les grands modèles de langage (LLM).
- Pour obtenir une présentation des principes et des recommandations d'architecture spécifiques aux charges de travail d'IA et de ML dans Google Cloud, consultez la perspective de l'IA et du ML dans le framework Well-Architected.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.
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 :
- Kumar Dhanagopal Développeur de solutions multiproduits
- Victor Moreno | Responsable produit, Mise en réseau cloud
- Samantha He | Rédactrice technique
- Ammett Williams | Ingénieur relations avec les développeurs
- Aspen Sherrill | Architecte en sécurité cloud