Modelo de Implantação de Aplicativos Multitenant no OCI

No mundo atual que prioriza a nuvem, as empresas e os fornecedores independentes de software (ISVs) estão cada vez mais transformando os aplicativos tradicionais em ofertas de software como serviço (SaaS). Um componente crítico dessa transformação é o modelo de implementação multitenant, que permite que vários clientes compartilhem o mesmo aplicativo, garantindo segurança, desempenho e economia. A Oracle Cloud Infrastructure (OCI) fornece um conjunto robusto de serviços que facilitam o fornecimento de aplicativos SaaS usando tenancy compartilhada e abordagens híbridas.

Sobre Tenancies

É importante não confundir a Tenancy do OCI com o conceito de um tenant em um aplicativo SaaS.

Tenancy do OCI: Esta é a conta que você recebe quando se inscreve nos serviços do OCI. Ele representa sua conta raiz e serve como a partição segura e isolada na qual você organiza e gerencia seus recursos do OCI.

Um tenant (em um contexto SaaS): Suponha que um ISV crie uma plataforma SaaS na OCI. Quando o ISV provisiona seus próprios clientes na plataforma, cada um desses clientes é considerado um inquilino. Um tenant nesse sentido representa uma organização do cliente, e cada tenant pode ter vários usuários associados a ele.

Em suma, uma Tenancy da OCI se refere à própria conta da OCI, enquanto um tenant se refere a uma organização (como um cliente SaaS) que usa um aplicativo hospedado na OCI por outra entidade, como um ISV.

Arquitetura

Essa arquitetura representa um modelo de implantação de aplicativos multitenant na OCI, em um alto nível.

O diagrama a seguir ilustra essa arquitetura de referência:


Veja a seguir a descrição da aplicação multilocatário-oci.png
Descrição da ilustração multi-tenant-app-oci.png

multi-tenant-app-oci-oracle.zip

Essa arquitetura flexível é organizada em três camadas:

Camada Objetivo Ação-chave
Autenticação Inicial (OCI IAM) Verificar identidade global Emitir JWT (JSON Web Token) após a validação da credencial
Middleware de Autenticação Verificar identidade por solicitação Extrair o contexto do tenant e do usuário do JWT
Camada de Acesso a Dados ou Ganchos ORM Imponha o isolamento de dados Filtrar automaticamente todas as consultas por tenant_id

Cada camada é descrita abaixo:

Estabelecimento de Contexto de Tenant e Autenticação Inicial

  • Serviço de Autenticação: O usuário faz log-in, geralmente usando um URL específico do tenant (por exemplo, mycompany.app.com) ou selecionando um tenant durante o log-in.
  • O OCI Identity and Access Management (OCI IAM) como Provedor de Identidades: O OCI IAM (especificamente, um Domínio de Identidades dedicado) valida as credenciais do usuário. Crucialmente, ele confirma que o usuário não é apenas válido, mas também é membro do grupo de inquilinos específico (por exemplo, mycompany-users) que eles estão tentando acessar.
  • Emissão do JWT: Após a autenticação bem-sucedida, o Domínio de Identidades do IAM do OCI emite um JWT (JSON Web Token) assinado. Esse token inclui as seguintes reivindicações críticas:
    • sub: O identificador exclusivo do usuário.
    • grupos: Um array de OCIDs para os grupos do serviço IAM aos quais o usuário pertence. Esta é a chave para identificar o inquilino.
    • Uma reivindicação personalizada como tenant_id ou tenant_name pode ser adicionada usando atributos personalizados no OCI IAM. (Opcional)

Middleware de Autenticação - camada "Quem"

O backend deve ser projetado para extrair e propagar o contexto do tenant com segurança. Essa arquitetura suporta o uso do Gateway de API do OCI ou do Balanceador de Carga do OCI para executar autenticação por solicitação e propagação de contexto de tenant.

  • OCI API Gateway: Este é o ponto de entrada recomendado. Ele pode executar a própria validação do JWT, descarregando essa responsabilidade do código do seu aplicativo. Você o configura para validar a assinatura no ponto final JWKS do Domínio de Identidades do OCI IAM.
  • Balanceador de Carga do OCI: Pode tratar o encerramento e o roteamento de SSL, mas passaria o JWT para o middleware de autenticação para validação.

Ação: O OCI API Gateway valida a assinatura e a expiração do JWT. Se for inválido, ele rejeitará a solicitação imediatamente. Se for válido, ele encaminhará a solicitação ao serviço de upstream, geralmente informando o token validado ou as reivindicações extraídas em cabeçalhos (por exemplo, X-USER-ID, X-TENANT-ID).

Se você estiver usando o OCI Load Balancer em vez do OCI API Gateway, o primeiro componente do backend do seu aplicativo deverá ser o middleware de autenticação.

Ação: Extraia o JWT do cabeçalho Authorization: Bearer <token>, verifique sua assinatura usando as chaves públicas do OCI IAM, decodifique as reivindicações e injete o user_id e o tenant_id (derivado da reivindicação de grupos) no contexto de solicitação para que todas as camadas subsequentes sejam usadas.

Data Access Layer ou Object-Relational Mapper (ORM) Hook – Camada "What"

Essa camada injeta automaticamente o ID do tenant em cada consulta SQL.

  • Exemplo: Uma chamada para getAllInvoices() é transformada em SELECT * FROM invoices WHERE tenant_id = :tenant_id.
  • Imposição: é melhor imposta por uma camada centralizada de acesso a dados ou um gancho ORM (como Hibernate) ou pool de conexões "com reconhecimento de tenant" para evitar erros humanos.
  • Ganchos do ORM: O mecanismo que permite o isolamento de tenant implícito verdadeiro interceptando e modificando operações de banco de dados no nível da estrutura do aplicativo.

Estratégias de isolamento de dados do cliente:

Essa arquitetura oferece suporte a duas opções para isolar e proteger os dados de seus locatários:

Opção 1: Nível da Aplicação

Ganchos/Escopos do ORM: Estruturas como Hibernate (Java), Django ORM (Python) ou Eloquent (PHP) permitem que você defina escopos globais que adicionam automaticamente o filtro de tenant a todas as consultas de um modelo específico.

ou

Opção 2: Nível do Banco de Dados

Você pode usar uma coluna de discriminador, um esquema separado por tenant ou um banco de dados separado por tenant:

  • Coluna Discriminador (mais comum):

    Uma coluna tenant_id é adicionada a cada tabela ou documento específico do tenant.

    A Camada de Acesso a Dados (DAL) ou o ORM do aplicativo é responsável por anexar automaticamente a cláusula WHERE tenant_id = ? a cada consulta. Isto é conseguido através de:

    • Padrão de Repositório: todo o acesso ao banco de dados flui por uma classe central ou um conjunto de classes. Esse repositório adiciona automaticamente o filtro do tenant a cada operação SELECT, INSERT, UPDATE e DELETE com base no tenant_id no contexto da solicitação atual.
    • Contexto de Conexão: Para alguns bancos de dados SQL (como o Oracle HeatWave MySQL), o aplicativo pode definir uma variável de sessão (por exemplo, SET @tenant_id = 'mycompany123';) e, em seguida, usá-la em views ou procedimentos armazenados. No entanto, a camada do aplicativo ainda é responsável por definir esse valor por conexão.
  • Esquema por locatário:

    Cada tenant tem um esquema de banco de dados dedicado dentro da mesma instância de banco de dados.

    A lógica do aplicativo, com base no ID do tenant, deve alternar o esquema atual da conexão do banco de dados.

    • Pool de Conexões por Tenant: Mantenha um pool de conexões separado para cada tenant, em que cada conexão é pré-configurada para usar o esquema do tenant (por exemplo, USE tenant_mycompany;).
    • Chaveamento de Conexão Dinâmica: Use um pool de conexões que defina o esquema no check-out com base no tenant_id atual (por exemplo, usando um comando SET search_path TO tenant_mycompany; para PostgreSQL).
  • Banco de Dados por Tenant:

    Cada tenant tem sua própria instância de banco de dados separada fisicamente com a Criptografia Bring Your Own Keys para Empresas.

    O aplicativo precisa de um serviço de pesquisa de dados do tenant para mapear um tenant_id para a string de conexão de banco de dados correta.

    • O aplicativo mantém pools de conexão com vários bancos de dados.
    • O DAL usa o ID do tenant do contexto de solicitação para obter a conexão correta do pool e executar a consulta no banco de dados de tenant dedicado.

    Esta opção tem vantagens e desvantagens:

    • Prós: Máxima isolamento, segurança e desempenho. Os tenants podem até estar em diferentes versões de banco de dados ou tipos de mecanismo.
    • Cons: Maior sobrecarga operacional, custo e complexidade. As migrações e os patches do banco de dados devem ser executados em cada banco de dados de tenant.

Essa arquitetura implementa os seguintes componentes:

  • Tenancy

    Uma tenancy é uma partição segura e isolada que a Oracle configura no Oracle Cloud quando você se inscreve no OCI. Você pode criar, organizar e administrar seus recursos no OCI em sua tenancy. Uma tenancy é sinônimo de uma empresa ou organização. Normalmente, uma empresa terá uma única tenancy e refletirá sua estrutura organizacional dentro dessa tenancy. Uma única tenancy geralmente está associada a uma única assinatura, e uma única assinatura geralmente tem apenas uma tenancy.

  • OCI Identity and Access Management

    O Oracle Cloud Infrastructure Identity and Access Management (IAM) fornece controle de acesso do usuário para OCI e Oracle Cloud Applications. A API do IAM e a interface do usuário permitem gerenciar domínios de identidades e os recursos dentro deles. Cada domínio de identidades do OCI IAM representa uma solução independente de gerenciamento de identidades e acessos ou outra população de usuários.

  • Balanceador de carga

    O Oracle Cloud Infrastructure Load Balancer fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores.

  • Gateway de API do OCI

    O Oracle Cloud Infrastructure API Gateway permite que você publique APIs com pontos finais privados acessíveis de dentro da sua rede e que você pode expor à internet pública, se necessário. Os pontos finais suportam validação da API, transformação de solicitação e resposta, CORS, autenticação e autorização e limitação de solicitação.

  • Oracle Key Management Cloud Service

    O Serviço de Gerenciamento de Chaves (KMS) da Oracle Cloud Infrastructure (OCI) é um serviço baseado em nuvem que fornece gerenciamento centralizado e controle de chaves de criptografia para dados armazenados na OCI. O OCI KMS é uma criptografia gerenciada pelo cliente e oferece os serviços OCI Vault (Vault Virtual e Private Vault), OCI Dedicated KMS e OCI External KMS.

  • OCI Compute

    Com o Oracle Cloud Infrastructure Compute, você pode provisionar e gerenciar hosts de computação na nuvem. Você pode iniciar instâncias de computação com formas que atendam aos seus requisitos de recursos para CPU, memória, largura de banda de rede e armazenamento. Depois de criar uma instância de computação, você poderá acessá-la com segurança, reiniciá-la, anexar e desanexar volumes e encerrá-la quando não precisar mais dela.

  • Funções do OCI

    O Oracle Cloud Infrastructure Functions é uma plataforma Functions-as-a-Service (FaaS) totalmente gerenciada, multitenant, altamente escalável e sob demanda. Ele é alimentado pelo mecanismo de open source do Fn Project. O OCI Functions permite que você implante o código da sua conta e o chame diretamente ou o acione em resposta a eventos. O OCI Functions usa contêineres Docker hospedados no Oracle Cloud Infrastructure Registry.

  • Mecanismo do Kubernetes do OCI

    O Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine ou OKE) é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos conteinerizados na nuvem. Você especifica os recursos de computação necessários aos seus aplicativos e o OKE os provisiona no OCI em uma tenancy existente. O OKE usa o Kubernetes para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos em contêineres em clusters de hosts.

  • Oracle HeatWave MySQL

    O Oracle MySQL Database Service é um serviço completamente gerenciado que permite que os desenvolvedores desenvolvam e implantem rapidamente aplicativos seguros nativos da nuvem usando o banco de Dados de código-fonte aberto mais popular do mundo. O Oracle HeatWave MySQL é um acelerador de consultas novo, integrado e de alto desempenho na memória do Oracle MySQL Database Service que acelera o desempenho do MySQL para análises e consultas transacionais.

  • Oracle NoSQL Database Cloud Service

    O Oracle NoSQL Database Cloud Service facilita para os desenvolvedores a criação de aplicativos usando modelos de banco de dados de documento, esquema fixo e valor-chave, oferecendo tempos de resposta previsíveis de um dígito em milissegundos com replicação de dados para alta disponibilidade. O serviço oferece replicação regional ativa/ativa, transações ACID, dimensionamento sem servidor, segurança abrangente e baixo pagamento por uso para modos de capacidade sob demanda e provisionados, incluindo 100% de compatibilidade com o Oracle NoSQL Database on-premises.

  • OCI Object Storage

    O OCI Object Storage oferece acesso a grandes quantidades de dados estruturados e não estruturados de qualquer tipo de conteúdo, incluindo backups de banco de dados, dados analíticos e conteúdo avançado como imagens e vídeos. Você pode armazenar dados com segurança diretamente de aplicativos ou de dentro da plataforma de nuvem. Você pode dimensionar o armazenamento sem sofrer qualquer degradação no desempenho ou na confiabilidade de serviço.

    Use armazenamento padrão para armazenamento "quente" que você precisa acessar com rapidez, rapidez e frequência. Use armazenamento de arquivo compactado para armazenamento "frio" que você retém por longos períodos de tempo e acesso raro.

  • Oracle Autonomous Database sem Servidor

    O Oracle Autonomous Database Serverless é um Oracle Autonomous Database. Você tem um banco de dados totalmente elástico no qual a Oracle opera de forma autônoma todos os aspectos do ciclo de vida do banco de dados, desde o posicionamento do banco de dados até o backup e as atualizações.

  • Criptografia de Dados Transparentes

    A Criptografia Transparente de Dados (TDE) criptografa de forma transparente dados em repouso em um Oracle AI Database. A TDE é totalmente integrada ao Oracle AI Database e pode criptografar backups inteiros de banco de dados (RMAN), exportações do Data Pump, tablespaces inteiros de aplicativos ou colunas confidenciais específicas. Os dados criptografados permanecem criptografados no banco de dados, seja em arquivos de armazenamento de tablespace, tablespaces temporários, tablespaces de undo ou outros arquivos, como redo logs. Isso evita tentativas não autorizadas de acessar dados do banco de dados sem afetar a forma como os aplicativos acessam os dados usando SQL.

Recomendações

Use as recomendações a seguir como ponto de partida para projetar sua arquitetura. Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • VCN

    Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar às sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.

    Selecione blocos CIDR que não se sobreponham a qualquer outra rede (no Oracle Cloud Infrastructure, seu data center on-premises ou outro provedor de nuvem) para a qual você pretende configurar conexões privadas.

    Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.

    Ao projetar as sub-redes, considere o fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos dentro de uma camada ou atribuição específica à mesma sub-rede, que pode servir como um limite de segurança.

  • Listas de segurança

    Use listas de segurança para definir regras de entrada e saída que se aplicam a toda a sub-rede.

  • Grupos de segurança de rede (NSGs)

    Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos o uso de NSGs em vez de listas de segurança, pois os NSGs permitem separar a arquitetura de sub-rede da VCN dos requisitos de segurança do seu aplicativo.

  • Cloud Guard

    Clone e personalize as receitas padrão fornecidas pela Oracle para criar receitas personalizadas de detector e respondedor. Essas receitas permitem especificar quais tipos de violações de segurança geram uma advertência e quais ações podem ser executadas nelas. Por exemplo, talvez você queira detectar buckets do OCI Object Storage que tenham visibilidade definida como pública.

    Aplique o Oracle Cloud Guard no nível da tenancy para cobrir o escopo mais amplo e reduzir a carga administrativa de manutenção de várias configurações.

    Você também pode usar o recurso Lista gerenciada para aplicar determinadas configurações aos detectores.

  • Zonas de Segurança

    Para recursos que exigem segurança máxima, a Oracle recomenda o uso de zonas de segurança. Uma zona de segurança é um compartimento associado a uma receita de políticas de segurança definidas pela Oracle que se baseiam nas melhores práticas. Por exemplo, os recursos em uma zona de segurança não podem ser acessados pela internet pública e devem ser criptografados usando chaves gerenciadas pelo cliente. Quando você cria e atualiza recursos em uma zona de segurança, o OCI valida as operações em relação às políticas na receita e impede operações que violem qualquer uma das políticas.

Considerações

Ao implantar essa arquitetura, considere essas opções.

  • Desempenho:
    • Definir limitação de taxa baseada em tenant em APIs
    • Usar cotas de recursos do Kubernetes por namespace no OKE para limitar pods, CPU e memória por tenant
    • Aproveite pools de nós dedicados para tenants de alta demanda
    • Definir um tamanho de pool por tenant na conexão do Banco de Dados
  • Segurança:
    • Os grupos do OCI IAM controlam qual tenant um usuário pode acessar. Isso é imposto pelo JWT.
    • Ative o Oracle Cloud Guard para detectar configurações incorretas
  • Custo:

    Avalie com base nas suas necessidades de negócios, se você precisa de nível de tabela, nível de esquema ou um banco de dados dedicado para clientes de nível empresarial. Por exemplo:

    • Nível 1: Padrão (Coluna do Discriminador): Os inquilinos compartilham as mesmas tabelas/esquema.
    • Tier 2: Premium (Esquema por Tenant): Os tenants obtêm um esquema dedicado dentro do mesmo banco de dados.
    • Camada 3: Enterprise (Banco de Dados por Tenant): Os tenants obtêm uma instância de banco de dados dedicada.
  • Patches e atualizações de aplicativos

    Em uma arquitetura SaaS multitenant de instância única, você não pode aplicar patch a um tenant sem aplicar patch a todos eles. Todos os seus clientes compartilham a mesma base de código de aplicativo, tempo de execução e infraestrutura. Essa realidade cria um desafio significativo: como você implementa atualizações com segurança, eficiência e sem causar tempo de inatividade disruptivo para toda a sua base de usuários? A resposta está nas estratégias de implantação modernas do DevOps projetadas especificamente para esse fim: use estratégias de implantação com tempo de inatividade zero para permitir transições contínuas entre versões sem forçar os usuários off-line.

    • Implantação Azul/Verde: envolve a manutenção de dois ambientes de produção idênticos: um "Azul" (executando a versão atual) e um "Verde" (executando a nova versão). Depois de implementar e testar a nova versão em verde, você alterna perfeitamente todo o tráfego de azul para verde. Se algo der errado, você retornará instantaneamente, tornando o rollback um não evento. O antigo ambiente azul é então desativado.
    • Implantação Canária: essa estratégia reduz o risco ao realizar um lançamento gradual. A nova versão é implantada em um subconjunto pequeno e controlado de usuários (os "canários"). Você monitora este grupo atentamente quanto a erros ou problemas de desempenho. Se as métricas parecerem boas, você implementará gradualmente a atualização para mais usuários até que todos estejam na nova versão.

    Você notifica os usuários sobre uma janela de upgrade obrigatória (por exemplo, "Se nenhuma data de upgrade for especificada, a atualização ocorrerá automaticamente às 12:00 no Domingo, mm/dd/yyyy"). Após a janela, encerre as sessões da versão antiga e redirecione todo o tráfego para a nova versão. Em seguida, o código do aplicativo antigo é totalmente desativado.

  • Considerações sobre o banco de dados

    Não é possível alternar o esquema do banco de dados no momento exato em que você alterna a versão do aplicativo. A maioria das empresas do SaaS evita isso usando:

    • Alterações de esquema de banco de dados compatíveis com versões anteriores
    • Indicadores/alternações de recursos
    • Controle de versão baseado em metadados do tenant

    Isso permite que o novo código opere com segurança em relação às versões antigas do esquema durante o rollout, permitindo migrações sem tempo de inatividade e rollback instantâneo.

Explorar Mais

Saiba mais sobre a implantação de aplicativos multilocatários.

Revise estes recursos adicionais:

Confirmações

  • Autor: Gururaj Mohan, Arquiteto de Nuvem Empresarial
  • Colaboradores: Joshua Stanley