Conectividade particular para aplicativos de IA generativa com capacidade de RAG

Last reviewed 2026-11-03 UTC

Neste documento, apresentamos uma arquitetura de referência que pode ser usada para ajudar a proteger a infraestrutura de rede para aplicativos com geração aumentada por recuperação (RAG). Uma arquitetura RAG normalmente contém subsistemas separados para lidar com os fluxos de processamento de dados e recuperação de conteúdo. Esta arquitetura de referência demonstra como usar a VPC compartilhada para fazer o seguinte:

  • Crie uma separação entre os subsistemas usando as permissões do Identity and Access Management (IAM).
  • Conectar os componentes de aplicativo usando endereços IP particulares.

O público-alvo deste documento inclui arquitetos, desenvolvedores e administradores de rede e segurança. No documento, pressupomos que você tenha uma compreensão básica de rede. Este documento não descreve a criação de um aplicativo baseado em RAG.

Arquitetura

O diagrama a seguir mostra a arquitetura de rede apresentada neste documento:

Arquitetura de rede para aplicativos com RAG.

Conexões e fluxo de tráfego para a arquitetura de rede.

A arquitetura no diagrama anterior mostra os seguintes componentes:

Rede externa, no local ou em outra nuvem

Uma rede externa que executa as seguintes funções:

  • Fornece conectividade de rede aos engenheiros de dados que fazem upload de dados brutos de RAG.
  • Encerra a conectividade de rede externa.
  • Hospeda roteadores externos.
  • Fornece conectividade ao endpoint do Private Service Connect na rede VPC de roteamento Google Cloud .
  • Contém servidores DNS que apontam para o endpoint do Private Service Connect.
Projeto de roteamento

Um projeto do Google Cloud que executa as seguintes funções:

  • Hospeda a rede VPC de roteamento, que se conecta à rede externa por uma conexão do Cloud Interconnect ou do Cloud VPN.
  • Hospeda um hub do Network Connectivity Center (NCC) que conecta a rede externa, a rede VPC de roteamento e as redes VPC compartilhadas.
  • Hospeda um endpoint do Private Service Connect que se conecta a um endpoint regional do Cloud Storage. Esse endpoint permite que os engenheiros de dados façam upload de dados de RAG para o bucket do Cloud Storage.
Projeto de host de VPC compartilhada do RAG

Hospeda uma rede VPC compartilhada que hospeda o balanceador de carga de aplicativo interno do serviço de front-end e qualquer outro serviço que precise de uma rede VPC. Todos os projetos de serviço têm acesso a essa rede VPC compartilhada.

Projeto de serviço de ingestão de dados

Contém um bucket do Cloud Storage para entrada de dados brutos. Contém o subsistema de ingestão de dados, que inclui os seguintes componentes:

  • Processamento de ingestão: lê e processa dados brutos.
  • Saída de ingestão: grava no repositório de dados final.
Projeto de serviço de exibição

Contém o subsistema de exibição, que inclui os seguintes componentes que fornecem os serviços e as funções para inferência e interação:

  • Repositório de dados RAG que contém a saída do subsistema de ingestão de dados.
  • Processos de disponibilização que alimentam o modelo combinando a consulta de inferência com dados do repositório de dados RAG.
  • O modelo que o subsistema de veiculação usa para criar vetores com base nos dados de RAG enviados e processar a solicitação do usuário final.
Projeto de serviço de front-end

Contém o subsistema de front-end, que é um balanceador de carga de aplicativo na frente de um serviço de interação do usuário executado no Cloud Run ou no Google Kubernetes Engine (GKE).

O projeto também contém o Google Cloud Armor, que ajuda a limitar como o serviço é acessado. Se você quiser fornecer acesso pela Internet, adicione um balanceador de carga de aplicativo externo regional.

Perímetro dos VPC Service Controls

Ajuda a proteger contra a exfiltração de dados. Os dados armazenados em buckets do Cloud Storage não podem ser copiados para fora do perímetro, e as operações do plano de controle são protegidas.

As seções a seguir descrevem as conexões e os fluxos de tráfego que estão na arquitetura.

Conexões entre componentes

Nesta seção, descrevemos as conexões entre os componentes e as redes nessa arquitetura.

Rede externa para rede VPC de roteamento

As redes externas se conectam à rede VPC de roteamento do Google Cloud pelo Cloud Interconnect ou pelo Cloud VPN, que são spokes híbridos de um hub do NCC.

Os Cloud Routers na rede VPC de roteamento e os roteadores externos na rede externa trocam rotas do protocolo de gateway de borda (BGP):

  • Os roteadores em redes externas anunciam as rotas de sub-redes externas para o Cloud Router da VPC de roteamento. É possível expressar a preferência das rotas usando métricas e atributos do BGP.
  • Os Cloud Routers na rede VPC de roteamento anunciam as rotas para prefixos nas VPCs de Google Cloudpara as redes externas.

Rede VPC de roteamento para rede VPC compartilhada

Conecte a rede VPC de roteamento e a rede VPC de RAG usando os spokes VPC do NCC do hub do NCC. O hub também hospeda os spokes híbridos para a rede externa.

De recurso para recurso na rede VPC compartilhada

Nesse design, um bucket do Cloud Storage recebe dados da rede externa. As solicitações de inferência passam por um balanceador de carga de aplicativo interno regional. Para o restante do sistema, você tem as seguintes opções:

  • Hospede tudo na infraestrutura de SaaS do Google, como buckets do Cloud Storage, Gemini Enterprise Agent Platform, Cloud Run e Pub/Sub. Nesse caso, os componentes se comunicam pela infraestrutura privada do Google.
  • Hospede tudo em cargas de trabalho executadas em VMs do Compute Engine, clusters do GKE, bancos de dados do Cloud SQL ou outros componentes executados em redes VPC. Nesse caso, os sistemas se comunicam usando endereços IP privados em redes que você vincula por meio do NCC ou do peering de rede VPC.
  • Usar uma combinação de serviços totalmente gerenciados, de plataforma e de infraestrutura. Nesse caso, é possível fazer conexões entre uma rede VPC e um serviço totalmente gerenciado usando os seguintes métodos:
    • Acesso privado do Google: com esse método, as cargas de trabalho que não têm endereços IP externo e que são executadas em redes VPC podem acessar as APIs do Google. Esse acesso ocorre internamente pela infraestrutura do Google, e esse processo não expõe o tráfego à Internet.
    • Private Service Connect: com esse método, é possível criar um endpoint no projeto de serviço para serviços como o AlloyDB para PostgreSQL, que são hospedados em redes VPC gerenciadas.

Rede externa para o balanceador de carga de aplicativo do serviço de front-end

O endpoint do balanceador de carga de aplicativo interno regional é um endereço IP na rede RAG. A rede RAG, a rede de roteamento e as conexões híbridas com a rede externa são todas spokes do mesmo hub do NCC. Portanto, é possível instruir o NCC a exportar todos os subintervalos do spoke para o hub, que, em seguida, reexporta esses subintervalos para as outras redes spoke. Os usuários finais do sistema podem acessar o serviço com balanceamento de carga pela rede externa.

Fluxos de tráfego

Os fluxos de tráfego nessa arquitetura de referência incluem um fluxo de dados de RAG e um fluxo de inferência.

Fluxo de população da RAG

Esse fluxo descreve como os dados de RAG passam pelo sistema, desde os engenheiros de dados até o armazenamento de vetores.

  1. Na rede externa, os engenheiros de dados fazem upload de dados brutos pela conexão do Cloud Interconnect ou pela conexão Cloud VPN. Os dados são enviados para o endpoint do Private Service Connect na rede VPC de roteamento.
  2. Os dados são transmitidos pela infraestrutura interna do Google para o bucket do Cloud Storage no projeto de serviço de ingestão de dados.

  3. No projeto de serviço de ingestão de dados, os dados são transferidos entre sistemas usando um dos seguintes métodos:

    • Acesso privado do Google
    • Endpoints do Private Service Connect
    • Infraestrutura direta do Google

    O método depende de os sistemas estarem hospedados em redes VPC doGoogle Cloud ou diretamente noGoogle Cloud. Como parte desse fluxo, o subsistema de ingestão de dados alimenta dados de RAG em blocos para o modelo, que produz vetores para cada bloco.

  4. O subsistema de ingestão de dados grava os dados vetoriais e em blocos no repositório de dados apropriado.

Fluxo de inferência

Este fluxo descreve as solicitações do cliente.

  1. Na rede externa, um cliente envia uma solicitação para o endereço IP do serviço.
  2. A solicitação é enviada pela conexão do Cloud Interconnect ou conexão Cloud VPN para a rede VPC de roteamento.
  3. A solicitação viaja pela conexão do spoke de VPC até a rede VPC do RAG.
  4. A solicitação do cliente chega ao balanceador de carga de aplicativo, que a transmite ao subsistema de front-end.
  5. O subsistema de front-end encaminha a solicitação para o subsistema de exibição.
  6. O subsistema de disponibilização aumenta a solicitação usando os dados contextuais relevantes do repositório de dados.
  7. O subsistema de veiculação envia o comando aumentado para o modelo de IA, que gera uma resposta.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos do Google Cloud :

  • Nuvem privada virtual (VPC): um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho do Google Cloud . A VPC inclui peering de rede VPC, Private Service Connect, acesso a serviços particulares e VPC compartilhada.
  • VPC compartilhada: um recurso da nuvem privada virtual que permite conectar recursos de vários projetos a uma rede VPC comum usando endereços IP internos dessa rede.
  • Private Service Connect: um recurso que permite que os consumidores acessem serviços gerenciados de maneira particular na rede VPC deles.
  • Acesso privado do Google: um recurso que permite que instâncias de VM sem endereços IP externos alcancem os endereços IP externo de APIs e serviços do Google.
  • Cloud Interconnect: um serviço que estende sua rede externa para a rede do Google por meio de uma conexão de alta disponibilidade e baixa latência.
  • Cloud VPN: um serviço que estende com segurança a rede de peering para a rede do Google por meio de um túnel de VPN IPsec.
  • Cloud Router: uma oferta distribuída e totalmente gerenciada que oferece recursos de alto-falante e resposta do protocolo de gateway de borda (BGP, na sigla em inglês). O Cloud Router funciona com o Cloud Interconnect, o Cloud VPN e os dispositivos roteadores para criar rotas dinâmicas em redes VPC com base em rotas recebidas pelo BGP e rotas aprendidas de forma personalizada.
  • Network Connectivity Center: um framework de orquestração que simplifica a conectividade de rede entre recursos spoke conectados a um recurso de gerenciamento central chamado de hub.
  • VPC Service Controls: uma funcionalidade de rede gerenciada que minimiza os riscos de exfiltração de dados para seus recursos do Google Cloud .
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Model Armor: um serviço que protege seus recursos de IA generativa e agêntica contra injeção de comandos, vazamentos de dados sensíveis e conteúdo prejudicial.
  • Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicativos da Web (WAF) e ajuda a proteger contra ataques DDoS e de aplicativos.
  • Cloud Storage: um repositório de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e fora do Google Cloude são replicados entre locais para redundância.

Casos de uso

Essa arquitetura foi projetada para cenários corporativos em que as comunicações de entrada, saída e internas do sistema geral precisam usar endereços IP privados e não podem atravessar a Internet:

  • Entrada particular: os dados enviados não trafegam pela Internet. Em vez disso, você hospeda o bucket do Cloud Storage atrás de um endpoint do Private Service Connect na sua rede VPC de roteamento Google Cloud. Você copia os dados de RAG pela conexão do Cloud Interconnect ou pela conexão Cloud VPN usando apenas endereços IP privados.
  • Conectividade privada entre serviços: os serviços se comunicam entre si pelas interfaces internas do Google ou por endereços privados que são internos às suas redes VPC.
  • Saída privada: os resultados da inferência não podem ser acessados pela Internet, a menos que você configure esse acesso. Por padrão, apenas os usuários na rede externa designada podem acessar o endpoint particular do serviço.

Alternativas de design

Nesta seção, apresentamos abordagens alternativas de design de rede que podem ser consideradas para seu aplicativo com capacidade de RAG no Google Cloud.

Disponibilizar o serviço publicamente

Na arquitetura mostrada neste documento, somente os usuários na sua rede interna podem enviar consultas ao aplicativo. Se o aplicativo precisar ser acessível para clientes na Internet, use um balanceador de carga de aplicativo externo regional.

Usar o GKE Inference Gateway

Se o subsistema de front-end for executado no GKE, use o GKE Inference Gateway em vez de um balanceador de carga de aplicativo.

Considerações sobre o design

Esta seção fornece mais orientações para ajudar você a implantar a rede para oferecer conectividade privada a uma arquitetura compatível com RAG. Essas orientações podem ajudar você a atender aos requisitos específicos de segurança, privacidade e conformidade, confiabilidade, otimização de custos, eficiência operacional e otimização de desempenho. As orientações desta seção não são completas. Para sua implantação específica, talvez seja necessário considerar outros fatores de design que não são abordados nesta seção.

segurança, privacidade e conformidade

Para proteger sua arquitetura compatível com RAG e atender aos requisitos de privacidade e compliance, considere as seguintes recomendações:

  • Triagem de comandos e respostas: implante o Model Armor na frente do modelo de IA para avaliar os comandos de entrada e os resultados de saída em relação à injeção de comandos, tentativas de jailbreak, vazamentos de dados sensíveis e violações da política de IA responsável. É possível integrar o Model Armor diretamente à Gemini Enterprise Agent Platform ou anexar o Model Armor ao balanceador de carga de aplicativo usando as extensões de tráfego do Service Extensions para rejeitar solicitações inadequadas antes que elas cheguem ao subsistema de veiculação. Para acessar os endpoints regionais do Model Armor de forma particular em uma rede VPC sem erros de certificado ao usar o Acesso Privado do Google ou o VPC Service Controls, crie um endpoint regional do Private Service Connect para as APIs do Model Armor.
  • Microsegmentação de perímetro e rede: essa arquitetura usa o VPC Service Controls para ajudar a evitar a exfiltração não autorizada de dados nos projetos de serviço. Além dos perímetros de serviço, use as políticas de firewall hierárquicas e de rede do Cloud Next Generation Firewall com tags governadas pelo IAM para restringir o tráfego leste-oeste entre as cargas de trabalho de ingestão de dados, de disponibilização e de front-end na rede VPC compartilhada.
  • Identidade e acesso de confiança zero: aplique o controle de acesso de confiança zero no balanceador de carga de aplicativo interno de front-end ou no balanceador de carga de aplicativo externo regional ativando o Identity-Aware Proxy (IAP), para que apenas usuários autenticados e autorizados possam consultar o aplicativo RAG. Combine contas de serviço de privilégio mínimo com políticas de limite de acesso de principal para restringir quais recursos cada principal de subsistema pode acessar. Se o subsistema de disponibilização orquestrar agentes autônomos ou ferramentas do Protocolo de Contexto de Modelo (MCP) em redes privadas, use a Identidade do Agente e o Gateway de Agente para autenticar e controlar o tráfego entre agentes e ferramentas.
  • Privacidade e criptografia de dados: use a Proteção de Dados Sensíveis no subsistema de ingestão de dados para inspecionar, classificar e desidentificar informações de identificação pessoal (PII) em documentos brutos enviados para o bucket do Cloud Storage antes de gerar embeddings e gravar no repositório de dados da RAG. Se o compliance regulatório exigir controle sobre as chaves de criptografia, configure chaves de criptografia gerenciadas pelo cliente (CMEK) no Cloud Key Management Service (Cloud KMS) para o bucket do Cloud Storage, o repositório de dados vetoriais e os endpoints do modelo.

Esse design usa princípios de segurança estabelecidos para ajudar a proteger suas cargas de trabalho de RAG. Para princípios e recomendações de segurança específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: segurança no Well-Architected Framework.

Confiabilidade

Para criar e operar uma infraestrutura de rede confiável para seu aplicativo com capacidade de RAG, considere as seguintes recomendações:

  • Conectividade híbrida redundante: configure anexos da VLAN do Cloud Interconnect ou túneis de VPN de alta disponibilidade redundantes em vários domínios e regiões de disponibilidade de borda, pareados com Cloud Routers redundantes para failover dinâmico do BGP entre sua rede externa e a rede VPC de roteamento.
  • Balanceamento de carga e armazenamento multirregionais: para alta disponibilidade entre regiões, use um balanceador de carga de aplicativo interno entre regiões para distribuir o tráfego de inferência entre back-ends de exibição e de front-end em várias regiões e use buckets birregionais ou multirregionais do Cloud Storage com repositórios de dados vetoriais replicados.
  • Ingestão assíncrona e resiliência de cota: separe os uploads de dados brutos para o bucket do Cloud Storage do pipeline de processamento de ingestão usando o Pub/Sub com tópicos de mensagens inativas ou políticas de repetição do Eventarc, para que as falhas transitórias de incorporação ou indexação possam ser repetidas sem perda de dados. Para latência e capacidade previsíveis durante a geração e inferência de embeddings de alto volume, reserve a Capacidade de Processamento Provisionada e implemente a espera exponencial para respostas HTTP 429.

Para princípios e recomendações de confiabilidade específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: confiabilidade no Well-Architected Framework.

Otimização de custos

Para otimizar o custo de criação e execução da arquitetura compatível com RAG, considere as seguintes recomendações:

  • Saída de rede e seleção de endpoint: coloque a rede VPC de roteamento, os endpoints do Private Service Connect, o bucket do Cloud Storage, o repositório de dados RAG e os endpoints do modelo na mesma região para evitar cobranças de transferência de dados entre regiões nos spokes do NCC. Consolide os endpoints compartilhados do Private Service Connect na rede VPC de roteamento ou host para reduzir as cobranças por hora de endpoint e de processamento de dados.
  • Gerenciamento do ciclo de vida do armazenamento: configure o Gerenciamento do ciclo de vida de objetos do Cloud Storage ou a Autoclass no bucket de ingestão de dados brutos para transferir documentos de origem processados para classes de armazenamento mais frias ou excluir arquivos de preparo depois que os vetores forem gravados no repositório de dados do RAG.
  • Embedding em lote e armazenamento em cache de contexto: para atualizações grandes e não urgentes do corpus de RAG no subsistema de ingestão de dados, use previsão em lote para embeddings ou inferência em lote a um custo menor do que as solicitações on-line. No subsistema de veiculação, ative o armazenamento em cache de contexto para instruções recorrentes do sistema e documentos de referência recuperados com frequência para reduzir os custos de tokens de entrada.

Para princípios e recomendações de otimização de custos específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: otimização de custos no Well-Architected Framework.

Eficiência operacional

Para operar e gerenciar com eficiência sua infraestrutura de rede e RAG, considere as seguintes recomendações:

  • Infraestrutura como código (IaC): automatize o provisionamento do projeto de roteamento, dos projetos de host e serviço da VPC compartilhada, do hub e dos spokes do NCC, dos endpoints do Private Service Connect e dos perímetros do VPC Service Controls usando módulos do Terraform do blueprint de bases empresariais e do Infrastructure Manager.
  • Resolução de DNS particular centralizada: simplifique o gerenciamento de DNS na rede externa e nos spokes de VPC usando zonas particulares do Cloud DNS e políticas de encaminhamento de entrada ou saída na rede VPC de roteamento para que os clientes locais e os projetos de serviço resolvam automaticamente o endpoint do Private Service Connect e os endereços IP internos do balanceador de carga de aplicativo.
  • Observabilidade de rede e IA: monitore a conectividade híbrida, o tráfego de spoke do NCC e as negações de política do VPC Service Controls usando o Network Intelligence Center (incluindo testes de conectividade e o Flow Analyzer), o Cloud Logging e o Cloud Monitoring. Avalie continuamente a relevância e o embasamento da recuperação no subsistema de veiculação usando o serviço de avaliação de IA generativa.

Para princípios e recomendações de excelência operacional específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: excelência operacional no Well-Architected Framework.

Otimização de desempenho

Para otimizar o desempenho das cargas de trabalho de rede e RAG, considere as seguintes recomendações:

  • Largura de banda híbrida e colocalização regional: dimensione os anexos da VLAN do Cloud Interconnect ou os túneis de VPN do Cloud VPN para lidar com volumes de pico de upload de dados brutos da rede externa sem saturar a largura de banda compartilhada com solicitações de inferência interativas. Coloque o endpoint regional do Private Service Connect, o bucket do Cloud Storage, o repositório de dados vetoriais (como Vector Search ou AlloyDB para PostgreSQL) e os endpoints do modelo na região mais próxima do ponto de presença da interconexão híbrida para minimizar a latência de ida e volta da rede.
  • Escalonamento de computação e roteamento de inferência: se o front-end ou o subsistema de exibição for executado no Cloud Run, configure instâncias mínimas e ajuste as configurações de simultaneidade para eliminar a latência de inicialização a frio durante picos de tráfego. Se você disponibiliza modelos abertos no GKE, use o Gateway de inferência para realizar roteamento com reconhecimento de cache de KV e de carga em servidores de modelos.

Para princípios e recomendações de otimização de desempenho específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: otimização de desempenho no Well-Architected Framework.

Implantação

Nesta seção, descrevemos as etapas para criar seu aplicativo:

  1. Identifique a região das cargas de trabalho.
  2. Crie Google Cloud projetos e redes VPC.
  3. Conecte as redes externas à rede VPC de roteamento.
  4. Vincular redes usando o NCC.
  5. Identifique os componentes para a implantação da RAG e crie contas de serviço.
  6. Configurar o VPC Service Controls.
  7. Criar o subsistema de ingestão de dados.
  8. Crie o subsistema de veiculação.
  9. Crie o subsistema de front-end.
  10. Torne seu aplicativo acessível pela Internet.

Identificar a região das cargas de trabalho

Em geral, é recomendável colocar a conectividade, as sub-redes VPC e as cargas de trabalho do Google Cloud próximas às redes locais ou a outros clientes de nuvem. Para mais informações sobre como escolher uma região para suas cargas de trabalho, consulte Seletor de região doGoogle Cloud e Práticas recomendadas para a seleção de regiões do Compute Engine.

Criar Google Cloud projetos e redes VPC

Se a organização já tiver configurado a Cross-Cloud Network para aplicativos distribuídos, o projeto de roteamento e a rede VPC de roteamento já deverão existir.

Crie os projetos doGoogle Cloud e uma rede VPC na seguinte ordem:

  1. Crie o projeto de roteamento.
  2. Crie a rede VPC de roteamento com o Acesso Privado do Google ativado.
  3. Crie o projeto de RAG.
  4. Promova o projeto de RAG para ser um projeto host da VPC compartilhada.
  5. Crie o projeto de serviço de ingestão de dados.
  6. Crie o projeto de serviço de veiculação.
  7. Crie o projeto de serviço de front-end.
  8. Crie a rede RAG de VPC compartilhada com o Acesso privado do Google ativado.
  9. Conceda aos projetos de serviço permissão para usar a rede RAG.

Conectar as redes externas à rede VPC de roteamento

Pule esta etapa se você já tiver configurado a Cross-Cloud Network para aplicativos distribuídos.

Configure a conectividade entre as redes externas e sua rede de roteamento. Para entender as tecnologias relevantes, consulte Conectividade externa e híbrida. Para orientações sobre como escolher um produto de conectividade, consulte Como escolher um produto de conectividade de rede.

  1. No projeto de roteamento, crie um hub do NCC.
  2. Adicione as conexões do Cloud Interconnect como spokes de anexo da VLAN ou adicione conexões VPN do Cloud VPN como spokes de VPN.
  3. Adicione a rede VPC de RAG e a rede VPC de roteamento ao hub como spokes de VPC.

Identificar componentes para implantação de RAG e criar contas de serviço

  1. Escolha uma implantação de RAG e faça uma lista dos componentes necessários.
  2. Identifique o acesso que cada componente precisa.
  3. Para cada componente, crie uma conta de serviço com as permissões adequadas. Em alguns casos, isso significa que você concede a um componente permissão para ler ou gravar em um projeto de serviço diferente.

Esse design pressupõe que você use um bucket do Cloud Storage como componente de entrada de dados e um balanceador de carga de aplicativo no front-end de inferência. O restante do design pode variar conforme necessário.

O ideal é que cada componente seja executado como uma conta de serviço própria. Verifique se cada componente tem apenas as permissões mínimas do IAM necessárias para executar as funções exigidas. Por exemplo, um job do Cloud Run no subsistema de ingestão de dados precisa ler o bucket de entrada do Cloud Storage, mas não precisa gravar nele. Neste exemplo, o projeto de serviço que executa o job do Cloud Run precisa ter permissão apenas para ler o bucket, sem permissão de gravação.

Configurar o VPC Service Controls

  1. Crie um perímetro do VPC Service Controls em torno da implantação.
  2. Configurar regras de acesso.

Criar o subsistema de ingestão de dados

O subsistema de ingestão de dados recebe dados brutos de engenheiros de dados e os processa para uso pelo subsistema de disponibilização.

  1. No projeto de serviço de ingestão de dados, crie um bucket do Cloud Storage.
  2. Na rede VPC de roteamento, crie um endpoint regional do Private Service Connect e conecte o endpoint ao bucket.
  3. Na rede externa, adicione uma entrada DNS para o endpoint usando o endereço IP e o URL gerados na etapa anterior.
  4. Atualize as regras de firewall de rede externa para permitir o acesso ao endereço IP do endpoint.
  5. No projeto de serviço de ingestão de dados, crie o restante do pipeline de ingestão de acordo com a arquitetura de RAG escolhida.
  6. Conceda permissões do IAM para que o recurso relevante no pipeline de ingestão possa acessar o modelo que produz os vetores.
  7. Conceda permissões do IAM para que o recurso relevante no pipeline de ingestão possa gravar no repositório de dados vetoriais.

Criar o subsistema de disponibilização

  1. No projeto de serviço de veiculação, crie o pipeline de veiculação.
  2. Conceda permissões do IAM para que a conta de serviço no sistema de front-end possa acessar a saída do subsistema de exibição.

Criar o subsistema de front-end

Nesta seção, presumimos que você use um balanceador de carga de aplicativo interno regional que use um NEG sem servidor na frente do Cloud Run. No entanto, é possível usar um balanceador de carga e um back-end diferentes.

  1. Crie o código para o sistema de front-end.
  2. No projeto de serviço de front-end, implante o sistema de front-end com balanceamento de carga, que inclui a etapa opcional de configurar uma política de segurança do Cloud Armor.
  3. Configure o Cloud Router na rede VPC de roteamento para encaminhar rotas da rede VPC do RAG para os roteadores locais. Essa configuração permite que os clientes acessem o balanceador de carga de aplicativo.
  4. Na rede externa, configure as regras de firewall para que o front-end do balanceador de carga seja acessível pela rede externa.
  5. Na rede externa, atualize o DNS para apontar para a regra de encaminhamento do balanceador de carga de aplicativo.

Tornar o aplicativo acessível pela Internet

Esta seção é opcional.

Esse design pressupõe que você quer que seu serviço seja acessível apenas pela rede externa, mas também é possível torná-lo acessível pela Internet.

Para tornar o serviço acessível pela Internet, siga estas etapas:

  1. Crie um balanceador de carga de aplicativo externo regional que aponte para o mesmo back-end que o balanceador de carga de aplicativo interno. Conclua a etapa opcional para configurar uma política de segurança do Cloud Armor.
  2. Atualize o VPC Service Controls para permitir que os clientes de serviço acessem os serviços de back-end.

A seguir

Colaboradores

Autores:

  • Deepak Michael | Engenheiro de clientes especialista em rede
  • Mark Schlagenhauf | Redator técnico, Rede

Outros colaboradores: