Nesta página, apresentamos as práticas recomendadas para criar uma arquitetura multitenant e hospedar código não confiável com o Cloud Run. Como um cliente do Google Cloud , um "inquilino" é definido como um dos seus próprios clientes, e "código não confiável" é o código fornecido por esses inquilinos para ser executado na sua plataforma.
Casos de uso
Os casos de uso dessas arquiteturas incluem:
- Plataformas de hospedagem de apps: você oferece uma plataforma em que seus clientes implantam o código. 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 refinados: você oferece a capacidade de personalizar modelos de IA para cada cliente. Em seguida, a plataforma executa esses modelos 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 você 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ê esteja oferecendo 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árias
Os desafios típicos da criação dessa arquitetura incluem:
- Segurança: não é possível verificar ou limpar o código fornecido. 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. 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 ele pode fazer aplicando o princípio das permissões de privilégio mínimo.
- Eficiência de custos: essa arquitetura pode ficar cara se cada locatário gerar custos fixos para sua plataforma.
- Gerenciamento de locatários: gerenciar centenas de milhares de locatários pode ser difícil, principalmente quando se trata de 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, eficiência de custos e gerenciamento de locatários.
Segurança
O Cloud Run oferece os recursos de segurança prontos para uso relevantes para essa arquitetura:
- Isolamento de computação: o Cloud Run garante um isolamento estrito entre instâncias de contêiner, seja 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 das imagens de base podem ser ativadas para manter o sistema operacional e o ambiente de execução das cargas de trabalho implantadas atualizados e com patches sem exigir novas implantaçõ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 multitenant.
- Identidade do 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 escalonadas automaticamente para zero quando não estão em uso, garantindo que as cargas de trabalho hospedadas só sejam cobradas quando precisam ser executadas. Resultando 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 do escalonamento até zero, você pode aproveitar um modelo de faturamento ainda mais granular que cobra apenas quando as solicitações são processadas, oferecendo uma eficiência de custo ainda maior.
- Sob demanda e com inicialização rápida: quando reduzidos, os serviços do Cloud Run podem ser escalonados rapidamente, resultando em pouca latência percebida pelo usuário final do aplicativo implantado.
- Rotulagem automática de custos: todos os custos informados pelo Cloud Run são rotulados, permitindo automatizar a atribuição e o rastreamento de custos dos seus locatários.
- Compromissos para reduzir os custos agregados: no nível da conta de faturamento, é possível usar descontos por uso contínuo flexíveis para otimizar os gastos com qualquer uso básico 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 Google Cloud , permitindo o gerenciamento de locatários conforme descrito em Organizar seus projetos Google Cloud .
Arquitetura de destino para plataformas multilocatárias
Em um nível alto, esta é a arquitetura recomendada:
Como organizar seus projetos do Google Cloud
Você precisa configurar uma organização 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. AGoogle Cloud pode trabalhar com você para garantir que os canais de comunicação adequados sejam implementados para a mitigação de abusos.
Use pastas para organizar seus projetos Google Cloud . É essencial colocar em pastas diferentes os projetos que executam seu código de terceiros e os projetos que executam código não confiável dos locatários. Você precisa automatizar a integração de locatários para que a criação dos projetos e recursos de um locatário não exija intervenção humana.
O Google recomenda usar um Google Cloud projeto por locatário. Também é possível hospedar vários locatários no mesmo projeto, mas isso tem outras limitações:
Locatário único por projeto Google Cloud (recomendado)
Nessa arquitetura, cada locatário da plataforma é hospedado em umGoogle Cloud projeto dedicado, o que traz muitos benefícios:
- Segurança mais simples: o projeto 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 e 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 permite criar apenas 1.000 serviços por região em um projeto. Há limites semelhantes no número de contas de serviço e 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 conversar 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évia privada).
- Monitoramento e gerenciamento mais simples:
- Usar 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 projeto respectivo.
- OGoogle Cloud Monitoring e o Logging funcionam em todos os projetos e permitem monitorar toda a frota.
- Com as cotas no nível do projeto, é possível limitar a utilização de recursos do Cloud Run para um determinado locatário, 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 Google Cloud projeto e a inicialização de APIs e recursos podem ter latência. O Google recomenda usar um pool de projetos pré-criados que você atribui aos seus locatários quando necessário.
Vários locatários por projeto Google Cloud (não recomendado)
É possível hospedar vários locatários no mesmo projeto 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 do Cloud Run por região em um projeto. Consequentemente, hospedar vários locatários por projeto ainda exige que você gerencie uma frota de projetos Google Cloud , o que aumenta a complexidade do gerenciamento de locatários. Do ponto de vista da segurança, os projetos do Google 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.
Roteamento de solicitações e domínios personalizados
Se você quiser expor os serviços do Cloud Run do seu 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 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 Service Extensions para lógica de roteamento. As extensões de serviço podem ser implementadas como plug-ins (em que a lógica é executada em linha com o processamento de solicitações) ou como callouts (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).
Usar um balanceador de carga de aplicativo também permite adicionar uma camada de armazenamento em cache aproveitando o Cloud CDN e proteção adicional contra ataques distribuídos de negação de serviço (DDoS) à sua plataforma usando o Cloud Armor.
Reputação e abuso
Qualquer plataforma de hospedagem que possa executar 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 podem estar vinculados à mesma conta de faturamento dos clientes que pagam valores altos. O Google pode considerar essas contas de faturamento em diferentes níveis de reputação.
Conforme descrito em 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 Google Cloud Termos de Serviço. O Google também pode registrar eventos de detecção de abuso no Cloud Logging, para que você possa tomar medidas.