En este documento se proporciona una arquitectura de referencia que puedes usar para proteger la infraestructura de red de aplicaciones con generación aumentada por recuperación (RAG). Una arquitectura RAG suele contener subsistemas independientes para gestionar los flujos de procesamiento de datos y recuperación de contenido. Esta arquitectura de referencia muestra cómo usar la VPC compartida para hacer lo siguiente:
- Crea una separación entre los subsistemas mediante permisos de gestión de identidades y accesos (IAM).
- Conecta los componentes de la aplicación mediante direcciones IP privadas.
Este documento está dirigido a arquitectos, desarrolladores y administradores de redes y seguridad. Se presupone que el lector tiene conocimientos básicos sobre redes. En este documento no se describe la creación de una aplicación basada en RAG.
Arquitectura
En el siguiente diagrama se muestra la arquitectura de red que se describe en este documento:
La arquitectura del diagrama anterior muestra los siguientes componentes:
| Componente | Finalidad |
|---|---|
| Red externa, ya sea on-premise o en otra nube |
|
| Proyecto de enrutamiento |
|
| Proyecto host de VPC compartida de RAG | Aloja una red de VPC compartida que aloja el balanceador de carga del servicio frontend y cualquier otro servicio que necesite una red de VPC. Todos los proyectos de servicio tienen acceso a esa red de VPC compartida. |
| Proyecto de servicio de ingestión de datos |
Contiene un segmento de Cloud Storage para la entrada de datos sin procesar. Contiene el subsistema de ingestión de datos, que incluye los siguientes componentes:
|
| Proyecto de servicio de publicación |
Contiene el subsistema de publicación, que incluye los siguientes componentes que proporcionan los servicios y las funciones de inferencia e interacción:
|
| Proyecto de servicio de frontend |
Contiene el subsistema de servicio, que es un balanceador de carga situado delante de un servicio de interacción con el usuario que se ejecuta en Cloud Run o Google Kubernetes Engine (GKE). El proyecto también contiene Google Cloud Armor, que ayuda a limitar el acceso a tu servicio. Si quieres proporcionar acceso desde Internet, puedes añadir un balanceador de carga de aplicación externo regional. |
| Perímetro de Controles de Servicio de VPC | Ayuda a proteger contra la filtración externa de datos. Los datos almacenados en segmentos de Cloud Storage no se pueden copiar a ningún lugar fuera del perímetro y las operaciones del plano de control están protegidas. |
En las siguientes secciones se describen las conexiones y los flujos de tráfico que se incluyen en la arquitectura.
Conexiones entre componentes
En esta sección se describen las conexiones entre los componentes y las redes de esta arquitectura.
Red externa a la red de VPC de enrutamiento
Las redes externas se conectan a la red de VPC de Google Cloud routing a través de Cloud Interconnect o de una VPN de alta disponibilidad, que son radios híbridos de un centro de conectividad de redes.
Los routers de Cloud Router de la red de VPC de enrutamiento y los routers externos de la red externa intercambian rutas del protocolo de pasarela fronteriza (BGP):
- Los routers de las redes externas anuncian las rutas de las subredes externas al router de Cloud Router de la VPC de enrutamiento. Puedes expresar la preferencia de las rutas mediante métricas y atributos de BGP.
- Los routers de Cloud Router de la red de VPC de enrutamiento anuncian las rutas de los prefijos de las VPC de Google Clouda las redes externas.
Ruta de la red de VPC a la red de VPC compartida
Conecta la red de VPC de enrutamiento y la red de VPC de RAG mediante los radios de VPC de Network Connectivity Center del hub de Network Connectivity Center. El centro también aloja los radios híbridos de la red externa.
De un recurso a otro en la red de VPC compartida
En este diseño, un segmento de Cloud Storage recibe datos de la red externa. Las solicitudes de inferencia se envían a través de un balanceador de carga de aplicación interno regional. Para el resto del sistema, tienes las siguientes opciones:
- Aloja todo en la infraestructura de SaaS de Google, como los segmentos de Cloud Storage, Vertex AI, Cloud Run y Pub/Sub. En este caso, los componentes se comunican a través de la infraestructura privada de Google.
- Aloja todo en cargas de trabajo que se ejecuten en máquinas virtuales de Compute Engine, clústeres de GKE, bases de datos de Cloud SQL u otros componentes que se ejecuten en redes de VPC. En este caso, los sistemas se comunican mediante direcciones IP privadas en redes que vinculas a través de Network Connectivity Center o del emparejamiento entre redes de VPC.
- Usa una combinación de servicios totalmente gestionados, de plataforma y de infraestructura. En este caso, puedes establecer conexiones entre una red de VPC y un servicio totalmente gestionado mediante los siguientes métodos:
- Acceso privado de Google: con este método, las cargas de trabajo que no tienen direcciones IP externas y que se ejecutan en redes de VPC pueden acceder a las APIs de Google. Este acceso se produce internamente a través de la infraestructura de Google y este proceso no expone dicho tráfico a Internet.
- Private Service Connect: con este método, puedes crear un endpoint en tu proyecto de servicio para servicios como AlloyDB para PostgreSQL, que están alojados en redes de VPC gestionadas.
Balanceador de carga de red externa a servicio de frontend
El endpoint del balanceador de carga de aplicación interno regional es una dirección IP de la red RAG. La red RAG, la red de enrutamiento y las conexiones híbridas a la red externa son radios del mismo hub de Network Connectivity Center. Por lo tanto, puede indicar a Network Connectivity Center que exporte todos los subintervalos de las redes de tipo spoke al hub, que, a su vez, vuelve a exportar esos subintervalos a las otras redes de tipo spoke. Los usuarios finales del sistema podrán acceder al servicio con balanceo de carga desde la red externa.
Flujos de tráfico
Los flujos de tráfico de esta arquitectura de referencia incluyen un flujo de datos RAG y un flujo de inferencia.
Flujo de población de RAG
En este flujo se describe cómo fluyen los datos de RAG por el sistema, desde los ingenieros de datos hasta el almacenamiento de vectores.
- Desde la red externa, los ingenieros de datos suben datos sin procesar a través de la conexión de Cloud Interconnect o de Cloud VPN. Los datos se suben al punto final de Private Service Connect en la red de VPC de enrutamiento.
- Los datos se transfieren a través de la infraestructura interna de Google al segmento de Cloud Storage del proyecto de servicio de ingestión de datos.
En el proyecto de servicio de ingestión de datos, los datos se desplazan entre sistemas mediante uno de los siguientes métodos:
- Acceso privado de Google
- Endpoints de Private Service Connect
- Infraestructura directa de Google
El método depende de si los sistemas están alojados en Google Cloud redes de VPC o directamente en Google Cloud. Como parte de este flujo, el subsistema de ingestión de datos proporciona datos de RAG fragmentados al modelo, que genera vectores para cada fragmento.
El subsistema de ingestión de datos escribe los datos vectoriales y los datos fragmentados en el almacén de datos correspondiente.
Flujo de inferencia
En este flujo se describen las solicitudes de los clientes.
- Desde la red externa, un cliente envía una solicitud a la dirección IP del servicio.
- La solicitud se transmite a través de la conexión de Cloud Interconnect o de Cloud VPN a la red de VPC de enrutamiento.
- La solicitud se transmite a través de la conexión de la VPC de radio a la red de VPC de RAG.
- La solicitud del cliente llega al balanceador de carga, que la envía al subsistema frontend.
- El subsistema de frontend reenvía la solicitud al subsistema de servicio.
- El subsistema de servicio aumenta la solicitud mediante el uso de los datos contextuales relevantes del almacén de datos.
- El subsistema de servicio envía la petición ampliada al modelo de IA, que genera una respuesta.
Productos usados
Esta arquitectura de referencia usa los siguientes Google Cloud productos:
- Nube privada virtual (VPC): un sistema virtual que proporciona funciones de red globales y escalables para tus Google Cloud cargas de trabajo. VPC incluye el intercambio de tráfico entre redes de VPC, Private Service Connect, el acceso a servicios privados y la VPC compartida.
- VPC compartida: una función de la nube privada virtual que te permite conectar recursos de varios proyectos a una red de VPC común mediante direcciones IP internas de esa red.
- Private Service Connect: una función que permite a los consumidores acceder de forma privada a servicios gestionados desde su red de VPC.
- Acceso privado de Google: una función que permite que las instancias de VM sin direcciones IP externas lleguen a las direcciones IP externas de las APIs y los servicios de Google.
- Cloud Interconnect: un servicio que amplía tu red externa a la red de Google a través de una conexión de alta disponibilidad y baja latencia.
- Cloud VPN: un servicio que amplía de forma segura tu red de emparejamiento a la red de Google a través de un túnel VPN IPsec.
- Cloud Router: una oferta distribuida y totalmente gestionada que proporciona funciones de altavoz y de respuesta del protocolo de pasarela fronteriza (BGP). Cloud Router funciona con Cloud Interconnect, Cloud VPN y los dispositivos router para crear rutas dinámicas en redes de VPC basadas en rutas aprendidas personalizadas y recibidas por BGP.
- Network Connectivity Center: un marco de orquestación que simplifica la conectividad de red entre los recursos de radio que están conectados a un recurso de gestión central llamado eje.
- Controles de Servicio de VPC: una función de red gestionada que minimiza los riesgos de filtración externa de datos de tus recursos de Google Cloud .
- Cloud Load Balancing: una cartera de balanceadores de carga de alto rendimiento, escalables, globales y regionales.
- Model Armor: un servicio que protege tus recursos de IA generativa y de agentes frente a la inyección de peticiones, las filtraciones de datos sensibles y el contenido dañino.
- Google Cloud Armor: un servicio de seguridad de red que ofrece reglas de cortafuegos de aplicaciones web (WAF) y ayuda a protegerse frente a ataques DDoS y a aplicaciones.
- Cloud Storage: un almacén de objetos ilimitado y a un coste bajo para diversos tipos de datos. Se puede acceder a los datos desde dentro y fuera de Google Cloud, y se replican en varias ubicaciones para ofrecer redundancia.
Casos prácticos
Esta arquitectura se ha diseñado para escenarios empresariales en los que las comunicaciones internas, de entrada y de salida del sistema general deben usar direcciones IP privadas y no deben atravesar Internet:
- Entrada privada: los datos subidos no se transfieren a través de Internet. En su lugar, aloja su segmento de Cloud Storage detrás de un endpoint de Private Service Connect en su Google Cloudred de VPC de enrutamiento. Copias los datos de RAG a través de tu conexión de Cloud Interconnect o Cloud VPN usando solo direcciones IP privadas.
- Conectividad privada entre servicios: los servicios se comunican entre sí a través de las interfaces internas de Google o mediante direcciones privadas que son internas a tus redes de VPC.
- Salida privada: no se puede acceder a los resultados de inferencia a través de Internet, a menos que decidas configurar ese acceso. De forma predeterminada, solo los usuarios de la red externa designada pueden acceder al endpoint privado de tu servicio.
Alternativas de diseño
En esta sección se presentan enfoques alternativos de diseño de redes que puedes tener en cuenta para tu aplicación compatible con RAG en Google Cloud.
Hacer que el servicio esté disponible públicamente
En la arquitectura que se muestra en este documento, solo los usuarios de su red interna pueden enviar consultas a su aplicación. Si tu aplicación debe ser accesible para los clientes en Internet, usa un balanceador de carga de aplicación externo regional.
Usar GKE Inference Gateway
Si tu subsistema de frontend se ejecuta en GKE, puedes usar una Inference Gateway en lugar de un balanceador de carga de aplicaciones.
Factores del diseño
En esta sección se ofrecen directrices adicionales para ayudarte a implementar la red de forma que se admita la conectividad privada de una arquitectura compatible con RAG. Estas directrices pueden ayudarte a cumplir tus requisitos específicos de seguridad, cumplimiento, fiabilidad, coste y rendimiento. Las directrices de esta sección no son exhaustivas. En tu caso, puede que tengas que tener en cuenta otros factores de diseño que no se mencionan en esta sección.
Seguridad, privacidad y cumplimiento
En la mayoría de los casos, se implementa Model Armor delante del modelo de IA para evaluar tanto las peticiones entrantes como los resultados salientes. Model Armor ayuda a prevenir posibles riesgos y a garantizar prácticas de IA responsables.
Para rechazar las solicitudes inapropiadas antes de que lleguen al subsistema de servicio, puedes asociar Model Armor al balanceador de carga.
Esta arquitectura usa Controles de Servicio de VPC, lo que ayuda a evitar la exfiltración de datos no autorizada.
Este diseño utiliza principios de seguridad consolidados para proteger tus cargas de trabajo de RAG. Para consultar principios y recomendaciones de seguridad específicos de las cargas de trabajo de IA y aprendizaje automático, consulta el artículo Perspectiva de IA y aprendizaje automático: seguridad del framework Well-Architected.
Optimización de costes
Para consultar los principios y las recomendaciones de optimización de costes específicos de las cargas de trabajo de IA y aprendizaje automático, consulta el artículo Perspectiva de IA y aprendizaje automático: optimización de costes del framework Well-Architected.
Optimización del rendimiento
Para consultar los principios y las recomendaciones de optimización del rendimiento específicos de las cargas de trabajo de IA y aprendizaje automático, consulte el artículo Perspectiva de la IA y el aprendizaje automático: optimización del rendimiento del marco de trabajo Well-Architected.
Implementación
En esta sección se describen los pasos para crear tu aplicación:
- Identifica la región de las cargas de trabajo.
- Crea Google Cloud proyectos y redes de VPC.
- Conecta tus redes externas a tu red de VPC de enrutamiento.
- Vincula redes con Network Connectivity Center.
- Identificar los componentes para la implementación de RAG y crear cuentas de servicio.
- Configura Controles de Servicio de VPC.
- Crea el subsistema de ingestión de datos.
- Crea el subsistema de servicio.
- Crea el subsistema de frontend.
- Haz que tu aplicación sea accesible desde Internet.
Identificar la región de las cargas de trabajo
En general, te recomendamos que coloques la conectividad, las subredes de VPC y las Google Cloud cargas de trabajo cerca de tus redes on-premise u otros clientes de la nube. Para obtener más información sobre cómo elegir una región para tus cargas de trabajo, consulta Google Cloud Selector de regiones y Prácticas recomendadas para seleccionar regiones de Compute Engine.
Crear Google Cloud proyectos y redes de VPC
Si tu organización ya ha configurado Cross-Cloud Network para aplicaciones distribuidas, el proyecto de enrutamiento y la red de VPC de enrutamiento ya deberían existir.
Crea los Google Cloud proyectos y una red de VPC en el siguiente orden:
- Crea el proyecto de enrutamiento.
- Crea la red VPC de enrutamiento con la función Acceso privado de Google habilitada.
- Crea el proyecto RAG.
- Promueve el proyecto de RAG para que sea un proyecto host de VPC compartida.
- Crea el proyecto de servicio de ingestión de datos.
- Crea el proyecto de servicio de publicación.
- Crea el proyecto de servicio de frontend.
- Crea la red de RAG de VPC compartida con el acceso privado de Google habilitado.
- Concede a los proyectos de servicio permiso para usar la red RAG.
Conectar tus redes externas a tu red de VPC de enrutamiento
Puedes saltarte este paso si ya has configurado redes en varias nubes para aplicaciones distribuidas.
Configura la conectividad entre las redes externas y tu red de enrutamiento. Para conocer las tecnologías pertinentes, consulta Conectividad externa e híbrida. Para obtener información sobre cómo elegir un producto de conectividad de red, consulta el artículo Elegir un producto de conectividad de red.
Vincular redes mediante Network Connectivity Center
- En el proyecto de enrutamiento, crea un eje de Network Connectivity Center.
- Añade las conexiones de Cloud Interconnect como radios de vinculación de VLAN o las conexiones de Cloud VPN como radios de VPN.
- Añade la red de VPC de RAG y la red de VPC de enrutamiento al hub como radios de VPC.
Identificar los componentes de la implementación de RAG y crear cuentas de servicio
- Elige una implementación de RAG y haz una lista de los componentes que necesita.
- Identifica el acceso que necesita cada componente.
- Para cada componente, crea una cuenta de servicio con los permisos adecuados. En algunos casos, esto significa que das permiso a un componente para leer o escribir en un proyecto de servicio diferente.
Este diseño presupone que usas un segmento de Cloud Storage como componente de entrada de datos y que usas un balanceador de carga en tu frontend de inferencia. El resto del diseño puede variar según sea necesario.
Lo ideal es que cada componente se ejecute como su propia cuenta de servicio. Asegúrate de que cada componente tenga solo los permisos de IAM mínimos necesarios para llevar a cabo las funciones que requiere. Por ejemplo, un trabajo de Cloud Run del subsistema de ingestión de datos necesita leer datos del segmento de Cloud Storage de entrada, pero no necesita escribir en él. En este ejemplo, el proyecto de servicio que ejecuta el trabajo de Cloud Run debe tener permiso para leer el segmento, pero no para escribir en él.
Configurar Controles de Servicio de VPC
- Crea un perímetro de Controles de Servicio de VPC alrededor de tu implementación.
- Configurar reglas de acceso.
Crear el subsistema de ingestión de datos
El subsistema de ingestión de datos toma los datos sin procesar de los ingenieros de datos y los procesa para que los utilice el subsistema de servicio.
- En el proyecto de servicio de ingestión de datos, crea un segmento de Cloud Storage.
- En la red de VPC de enrutamiento, crea un endpoint regional de Private Service Connect y conéctalo al bucket.
- En la red externa, añade una entrada DNS para el endpoint con la dirección IP y la URL que se han generado en el paso anterior.
- Actualiza las reglas de cortafuegos de la red externa para permitir el acceso a la dirección IP del endpoint.
- En el proyecto de servicio de ingestión de datos, desarrolla el resto de la canalización de ingestión según la arquitectura RAG que hayas elegido.
- Concede permisos de IAM para que el recurso correspondiente de la canalización de ingestión pueda acceder al modelo que genera los vectores.
- Concede permisos de gestión de identidades y accesos para que el recurso correspondiente de la canalización de ingestión pueda escribir en el almacén de datos de vectores.
Compilar el subsistema de publicación
- En el proyecto de servicio de publicación, crea tu flujo de publicación.
- Concede permisos de gestión de identidades y accesos para que la cuenta de servicio del sistema frontend pueda acceder a la salida del subsistema de servicio.
Compilar el subsistema de frontend
En esta sección se da por hecho que usas un balanceador de carga de aplicaciones interno regional que utiliza un NEG sin servidor delante de Cloud Run. Sin embargo, puedes usar otro balanceador de carga y otro backend.
- Crea el código de tu sistema frontend.
- En el proyecto de servicio frontend, despliega tu sistema frontend con balanceo de carga, que incluye el paso opcional de configurar una política de seguridad de Cloud Armor.
- Configura Cloud Router en la red de VPC de enrutamiento para reenviar rutas desde la red de VPC de RAG a los routers on‐premise. Esta configuración permite que los clientes accedan al balanceador de carga.
- En tu red externa, configura las reglas de cortafuegos para que se pueda acceder al frontend del balanceador de carga desde tu red externa.
- En tu red externa, actualiza el DNS para que dirija a la regla de reenvío del balanceador de carga.
Hacer que tu aplicación sea accesible desde Internet
Esta sección es opcional.
Este diseño presupone que quieres que se pueda acceder a tu servicio solo desde tu red externa, pero también puedes hacer que se pueda acceder a él desde Internet.
Para que se pueda acceder al servicio desde Internet, sigue estos pasos:
- Crea un balanceador de carga de aplicación externo regional que apunte al mismo backend al que apunta el balanceador de carga interno. Completa el paso opcional para configurar una política de seguridad de Cloud Armor.
- Actualiza Controles de Servicio de VPC para permitir que los clientes de servicios accedan a los servicios backend.
Siguientes pasos
- Consulta información sobre la Red Multinube para aplicaciones distribuidas.
- Consulta cómo alojar aplicaciones y agentes de IA en Cloud Run.
- Consulta las prácticas recomendadas de IA responsable y los filtros de seguridad de Vertex AI.
- Consulta las prácticas recomendadas para usar modelos de lenguaje extenso (LLMs).
- Para obtener una descripción general de los principios y las recomendaciones de arquitectura específicos de las cargas de trabajo de IA y aprendizaje automático en Google Cloud, consulta la sección Perspectiva de IA y aprendizaje automático del marco de trabajo Well-Architected.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.
Colaboradores
Autores:
- Deepak Michael | Ingeniero de clientes especialista en redes
- Mark Schlagenhauf | Redactor técnico de redes
Otros colaboradores:
- Kumar Dhanagopal | Desarrollador de soluciones entre productos
- Víctor Moreno | Product Manager, Cloud Networking
- Samantha He | Redactora técnica
- Ammett Williams | Ingeniero de Relaciones con Desarrolladores
- Aspen Sherrill | Arquitecto de seguridad en la nube