Nesta página, você encontra as práticas recomendadas para criar uma arquitetura multilocatária para hospedar código não confiável com o Cloud Run. Como cliente do Google Cloud , um "locatário" é definido como um dos seus próprios clientes, e "código não confiável" é o código fornecido por esses locatários para ser executado na sua plataforma.
Casos de uso
Os casos de uso para essas arquiteturas incluem:
- App Hosting: você oferece uma plataforma em que os clientes implantam o código deles. Por exemplo, uma plataforma de hospedagem na Web (os clientes fornecem um servidor da Web) ou uma plataforma de funções como serviço (os clientes fornecem uma função).
- Plataformas de hospedagem de agentes: seus clientes usam SDKs para criar agentes de IA, e sua plataforma os executa em segundo plano.
- Plataformas de modelos ajustados: você oferece a capacidade de personalizar modelos de IA para cada cliente. Sua plataforma os executa sob demanda usando GPUs.
- Funções definidas pelo usuário: seu software permite que os clientes definam uma lógica personalizada usando código. Por exemplo, você fornece um mecanismo de análise e quer permitir que os clientes escrevam funções personalizadas ou fornece um gateway de API e quer permitir que os clientes filtrem ou modifiquem solicitações com base na própria lógica personalizada.
- Extensibilidade de software como serviço (SaaS): talvez você ofereça um SaaS e queira permitir que os clientes ampliem os recursos dele usando extensões. Essas extensões podem ser escritas por clientes ou parceiros.
Google Cloud clientes estão usando o Cloud Run em produção para esses casos de uso.
Desafios das plataformas multilocatário
Os desafios típicos de criar essa arquitetura incluem:
- Segurança: é impossível verificar ou limpar o código fornecido. O código não confiável pode incluir ações maliciosas ou dependências vulneráveis. Se não for isolado corretamente, o código não confiável poderá acessar dados sensíveis de outros locatários. Apenas empacotar o código em um contêiner não é um limite de segurança forte o suficiente. O código também precisa ser restrito no que pode fazer, aplicando o princípio de privilégio mínimo.
- Custo-benefício: essa arquitetura pode se tornar cara se cada locatário gerar custos fixos para sua plataforma.
- Gerenciamento de locatários: gerenciar centenas de milhares de locatários pode ser um desafio, principalmente quando se trata da exclusão de dados.
Benefícios do Cloud Run
Uma arquitetura baseada no Cloud Run oferece uma solução para desafios comuns com muitos benefícios, como segurança, economia e gerenciamento de locatários.
Segurança
O Cloud Run oferece os recursos de segurança prontos para uso relevantes para esta arquitetura:
- Isolamento de computação: o Cloud Run garante um isolamento estrito entre instâncias de contêiner, sejam do mesmo serviço ou de serviços diferentes de projetos diferentes. Para mais informações sobre segurança de contêineres e ambientes de execução, consulte Visão geral do design de segurança.
- Atualizações de segurança: as atualizações de segurança automatizadas de imagens de base podem ser ativadas para manter o sistema operacional e o ambiente de execução das cargas de trabalho implantadas atualizados e corrigidos sem exigir reimplantações em grande escala.
- Isolamento de rede: o Cloud Run não apenas coloca os contêineres em sandbox, mas também fornece uma pilha de rede multilocatário.
- Identidade de serviço: as cargas de trabalho do Cloud Run podem ser configuradas para ter identidades dedicadas com permissões restritas.
Economia
- Redução da escala a zero e pagamento por uso: as instâncias do Cloud Run são reduzidas automaticamente a zero quando não estão em uso, garantindo que as cargas de trabalho hospedadas sejam cobradas apenas quando precisarem ser executadas. Isso resulta em uma utilização de recursos muito eficiente em comparação com arquiteturas que usam máquinas virtuais "sempre ativas".
- Faturamento por solicitação: além da redução da escala a zero, você pode se beneficiar de um modelo de faturamento ainda mais granular que cobra apenas quando as solicitações são processadas, proporcionando uma eficiência de custo ainda maior.
- Sob demanda e inicialização rápida: quando reduzidos, os serviços do Cloud Run podem ser escalonados verticalmente de maneira rápida, o que resulta em pouca latência percebida pelo usuário final do aplicativo implantado.
- Rotulagem de custos automatizada: todos os custos informados pelo Cloud Run são rotulados, permitindo automatizar a atribuição de custos e o rastreamento dos locatários.
- Compromissos para reduzir os custos agregados: no nível da conta de faturamento, é possível usar descontos por compromisso de uso flexíveis para otimizar os gastos com qualquer uso de referência do Cloud Run.
Gestão de locatários
Devido à natureza sob demanda, os custos do Cloud Run não são maiores ao usar vários projetos do Google Cloud , o que permite o gerenciamento de locatários, conforme descrito em Como organizar seus projetos do Google Cloud .
Arquitetura de destino para plataformas multilocatárias
De modo geral, esta é a arquitetura recomendada:
Como organizar seus projetos do Google Cloud
É necessário configurar uma organização do Google Cloud , o faturamento off-line e entrar em contato com sua equipe de conta para informar que você está agindo como uma conta de revendedor. OGoogle Cloud pode trabalhar com você para garantir que os canais de comunicação adequados sejam estabelecidos para mitigar abusos.
É preciso usar pastas para organizar seus projetos do Google Cloud . É essencial colocar em pastas diferentes os projetos que executam seu código próprio e os projetos que executam código não confiável dos seus locatários. É preciso automatizar a integração de locatários para que a criação de projetos e recursos de um locatário não exija intervenção humana.
O Google recomenda usar um projeto do Google Cloud por locatário. Também é possível hospedar vários locatários no mesmo projeto, mas isso traz outras limitações:
Locatário único por Google Cloud projeto (recomendado)
Nessa arquitetura, cada locatário da plataforma é hospedado em um projeto dedicado doGoogle Cloud , o que traz muitos benefícios:
- Segurança mais simples: o projeto do Google Cloud é um limite estrito para todos os recursos que ele contém. Isso significa que, se um locatário precisar de acesso a vários recursos doGoogle Cloud , como vários serviços do Cloud Run, um bucket do Cloud Storage, você poderá usar o projeto como um perímetro seguro.
- Menos limitado:
- O número de recursos em um determinado projeto é limitado. Por exemplo, o Cloud Run só permite criar 1.000 serviços por região em um projeto. Há limites semelhantes no número de contas de serviço e em outros recursos relacionados.
- O número de projetos é uma cota e pode ser aumentado. Não há limites para esse número em uma organização do Google Cloud . Há um limite flexível de 100.000 projetos por conta de faturamento, que pode ser multiplicado ao falar com o Google. Sua organização também pode criar várias contas de faturamento e agrupá-las em um "grupo de contas" (atualmente em pré-lançamento particular).
- Monitoramento e gerenciamento mais simples:
- O uso de um projeto por locatário facilita os processos de exclusão de dados, em que a exclusão de dados de um locatário se resume à exclusão do respectivo projeto.
- Google Cloud O Monitoring e o Logging funcionam em vários projetos e permitem que você monitore toda a frota.
- As cotas no nível do projeto permitem limitar a utilização de recursos do Cloud Run para um determinado locatário, possivelmente alinhando os limites aos seus próprios níveis de preços.
- Com as políticas personalizadas da organização, é possível aplicar a todos os projetos de uma pasta restrições específicas, como regiões disponíveis ou alocação máxima de CPU/memória.
A criação de um projeto do Google Cloud e a inicialização de APIs e recursos podem ter latência. O Google recomenda que você use um pool de projetos pré-criados que você atribui aos locatários quando necessário.
Vários locatários por projeto do Google Cloud (não recomendado)
É possível hospedar vários locatários no mesmo projeto do Google Cloud, mas o Google não recomenda essa arquitetura.
Muitos serviços do Google Cloud têm limites de recursos por projeto. Por exemplo, o Cloud Run tem um limite não ajustável de 1.000 serviços por região em um projeto. Consequentemente, hospedar vários locatários por projeto ainda exigirá que você gerencie uma frota de projetos do Google Cloud , o que aumentará a complexidade do gerenciamento de locatários. Do ponto de vista da segurança, os projetos doGoogle Cloud são projetados como um limite de segurança. Hospedar dois locatários distintos nos mesmos projetos exige mais cuidado quando se trata de segurança. Por exemplo, usando contas de serviço dedicadas e permissões refinadas.
Implantação em várias regiões
Para confiabilidade e escalonabilidade, o Google recomenda distribuir as implantações de locatários em várias regiões doGoogle Cloud . Cada aplicativo de locatário é implantado em uma única região, mas é possível usar regiões diferentes para locatários diferentes. A seleção da região pode ser aleatória ou considerar o local do locatário para otimizar a latência.
Roteamento de solicitações e domínios personalizados
Se você quiser expor os serviços do Cloud Run do locatário aos usuários finais, adicione seu próprio domínio e use sua própria lógica de roteamento. Por exemplo, para mapear um subdomínio para o projeto do Google Cloud que hospeda o serviço do locatário.
É possível implementar seu serviço de roteamento personalizado, mas o Google recomenda usar um balanceador de carga de aplicativo externo global com extensões de serviço para a lógica de roteamento. As extensões de serviço podem ser implementadas como plug-ins (em que a lógica é executada inline com o processamento de solicitações) ou chamadas (a lógica de roteamento é delegada a um serviço separado do Cloud Run que pode chamar um dos bancos de dados multirregionais escalonáveis doGoogle Cloud, como o Spanner).
O uso de um balanceador de carga de aplicativo também permite adicionar uma camada de armazenamento em cache com o Cloud CDN e proteção extra contra ataques distribuídos de negação de serviço (DDoS) à plataforma usando o Cloud Armor.
Reputação e abuso
Qualquer plataforma de hospedagem que permita a execução de código não confiável está sujeita a abuso.
Recomendamos usar uma conta do Cloud Billing diferente para cada um dos níveis de reputação que você oferece. Por exemplo, os locatários do nível sem custo financeiro não devem ser anexados à mesma conta de faturamento que os compradores que pagam mais. O Google pode considerar essas contas de faturamento em diferentes níveis de reputação.
Conforme descrito em Como organizar seus projetos do Google Cloud , além de separar por contas de faturamento, use pastas para organizar os projetos. O Google pode ajudar você a definir cotas no nível da pasta para garantir que todos os recursos em uma pasta nunca consumam mais do que um máximo definido, permitindo que você gerencie melhor o custo da sua plataforma.
Por padrão, o Google remove automaticamente as cargas de trabalho abusivas de acordo com os termos de serviço doGoogle Cloud . O Google também pode registrar eventos de detecção de abuso no Cloud Logging, que podem ser usados para entrar em ação.