Modelo de despliegue de aplicaciones multiinquilino en OCI

En el mundo actual centrado en la nube, las empresas y los proveedores de software independientes (ISV) están transformando cada vez más las aplicaciones tradicionales en ofertas de software como servicio (SaaS). Un componente fundamental de esta transformación es el modelo de despliegue multiinquilino, que permite a varios clientes compartir la misma aplicación al tiempo que garantiza la seguridad, el rendimiento y la rentabilidad. Oracle Cloud Infrastructure (OCI) proporciona un sólido conjunto de servicios que facilitan el suministro de aplicaciones SaaS mediante enfoques híbridos y de arrendamiento compartido.

Acerca de los arrendamientos

Es importante no confundir el arrendamiento de OCI con el concepto de inquilino en una aplicación SaaS.

Arrendamiento de OCI: esta es la cuenta que recibe cuando se registra en los servicios de OCI. Representa su cuenta raíz y sirve como partición segura y aislada donde organiza y gestiona sus recursos de OCI.

Un inquilino (en un contexto SaaS): suponga que un ISV crea una plataforma SaaS en OCI. Cuando el ISV aprovisiona a sus propios clientes en la plataforma, cada uno de esos clientes se considera un inquilino. En este sentido, un inquilino representa una organización de cliente y cada inquilino puede tener varios usuarios asociados.

En resumen, un arrendamiento de OCI hace referencia a la propia cuenta de OCI, mientras que un inquilino hace referencia a una organización (como un cliente SaaS) que utiliza una aplicación alojada en OCI por otra entidad, como un ISV.

Arquitectura

Esta arquitectura representa un modelo de despliegue de aplicaciones multiinquilino en OCI, a un alto nivel.

El siguiente diagrama ilustra esta arquitectura de referencia:

Descripción de la ilustración multicliente-app-oci.png

multi-tenant-app-oci-oracle.zip

Esta arquitectura flexible se organiza en tres capas:

Capa	Finalidad	Acción clave
Autenticación inicial (OCI IAM)	Verificar identidad global	Emitir token web JSON (JWT) después de la validación de credenciales
Middleware de autenticación	Verificar identidad por solicitud	Extraer contexto de usuario e inquilino de JWT
Capa de acceso a datos o enlaces de ORM	Aplique aislamiento de datos	Filtrar automáticamente todas las consultas por tenant_id

Cada capa se describe a continuación:

Autenticación inicial y establecimiento de contexto de inquilino

• Servicio de autenticación: el usuario se conecta, normalmente mediante una URL específica del inquilino (por ejemplo, mycompany.app.com) o seleccionando un inquilino durante la conexión.
• OCI Identity and Access Management (OCI IAM) como proveedor de identidad: OCI IAM (específicamente, un dominio de identidad dedicado) valida las credenciales del usuario. Fundamentalmente, confirma que el usuario no solo es válido, sino que también es miembro del grupo de inquilinos específico (por ejemplo, usuarios de mycompany) al que están tratando de acceder.
• Emisión de JWT: tras la autenticación correcta, el dominio de identidad de OCI IAM emite un token web JSON firmado (JWT). Este token incluye las siguientes afirmaciones críticas:
  • sub: identificador único del usuario.
  • grupos: matriz de OCID de los grupos de IAM a los que pertenece el usuario. Esta es la clave para identificar al inquilino.
  • Se puede agregar una reclamación personalizada, como tenant_id o tenant_name, mediante atributos personalizados en OCI IAM. (Optional)

Middleware de Autenticación: Capa "Who"

El backend debe estar diseñado para extraer y propagar el contexto de inquilino de forma segura. Esta arquitectura soporta el uso de OCI API Gateway o OCI Load Balancer para realizar la autenticación por solicitud y la propagación de contexto de inquilino.

• Gateway de API de OCI: este es el punto de entrada recomendado. Puede realizar la validación de JWT en sí, descargando esta responsabilidad del código de la aplicación. La configura para validar la firma en el punto final de JWKS del dominio de identidad de OCI IAM.
• Equilibrador de carga de OCI: puede manejar la terminación y el enrutamiento de SSL, pero transferiría el JWT al middleware de autenticación para la validación.

Acción: OCI API Gateway valida la firma y la caducidad del JWT. Si no es válida, rechaza la solicitud inmediatamente. Si es válido, reenvía la solicitud al servicio ascendente, a menudo transfiriendo el token validado o las reclamaciones extraídas en cabeceras (por ejemplo, X-USER-ID, X-TENANT-ID).

Si utiliza Equilibrador de carga de OCI en lugar de OCI API Gateway, el primer componente del backend de la aplicación debe ser middleware de autenticación.

Acción: extraiga el JWT de la cabecera Authorization: Bearer <token>, verifique su firma mediante las claves públicas de OCI IAM, descodifique las reclamaciones e inyecte user_id y tenant_id (derivados de la reclamación de grupos) en el contexto de solicitud para que se utilicen todas las capas posteriores.

Capa de acceso a datos o gancho de asignador relacional de objetos (ORM): capa "What"

Esta capa inyecta automáticamente el ID de inquilino en cada consulta SQL.

• Ejemplo: una llamada a getAllInvoices() se transforma en SELECT * FROM invoices WHERE tenant_id = :tenant_id.
• Aplicación: lo mejor es que se aplique mediante una capa de acceso a datos centralizada o un enlace ORM (como Hibernate) o un pool de conexiones "conscientes del inquilino" para evitar errores humanos.
• Enganches deORM: mecanismo que permite el verdadero aislamiento implícito de inquilinos mediante la interceptación y modificación de operaciones de base de datos en el nivel de marco de aplicación.

Estrategias de aislamiento de datos de inquilinos:

Esta arquitectura admite dos opciones para aislar y proteger los datos de los inquilinos:

Opción 1: Nivel de aplicación

Enganches/ámbitos deORM: marcos como Hibernate (Java), Django ORM (Python) o Eloquent (PHP) permiten definir ámbitos globales que agregan automáticamente el filtro de inquilino a todas las consultas de un modelo específico.

o bien,

Opción 2: nivel de base de datos

Puede utilizar una columna de discriminador, un esquema independiente por inquilino o una base de datos independiente por inquilino:

• Columna Discriminador (más común):

  Se agrega una columna tenant_id a cada tabla o documento específico del inquilino.

  La capa de acceso a datos (DAL) u ORM de la aplicación es responsable de agregar automáticamente la cláusula WHERE tenant_id = ? a cada consulta. Esto se consigue mediante:

  • Patrón de repositorio: todos los flujos de acceso a la base de datos a través de una clase central o un juego de clases. Este repositorio agrega automáticamente el filtro de inquilino a cada operación SELECT, INSERT, UPDATE y DELETE en función de tenant_id en el contexto de solicitud actual.
  • Contexto de conexión: para algunas bases de datos SQL (como Oracle HeatWave MySQL), la aplicación puede definir una variable de sesión (por ejemplo, SET @tenant_id = 'mycompany123';) y, a continuación, utilizarla en vistas o procedimientos almacenados. Sin embargo, la capa de aplicación sigue siendo responsable de definir este valor por conexión.
• Esquema por inquilino:

  Cada inquilino tiene un esquema de base de datos dedicado en la misma instancia de base de datos.

  La lógica de aplicación, basada en el ID de inquilino, debe cambiar el esquema actual de la conexión a la base de datos.

  • Pool de conexiones por inquilino: mantenga un pool de conexiones independiente para cada inquilino, donde cada conexión está preconfigurada para utilizar el esquema del inquilino (por ejemplo, USE tenant_mycompany;).
  • Conmutación de conexión dinámica: utilice un pool de conexiones que defina el esquema en la desprotección según el tenant_id actual (por ejemplo, mediante un comando SET search_path TO tenant_mycompany; para PostgreSQL).
• Base de datos por inquilino:

  Cada inquilino tiene su propia instancia de base de datos físicamente independiente con Cifrado de claves Traiga sus propias claves para empresas.

  La aplicación necesita un servicio de consulta de datos de inquilino para asignar un tenant_id a la cadena de conexión de base de datos correcta.

  • La aplicación contiene pools de conexiones a varias bases de datos.
  • El DAL utiliza el ID de inquilino del contexto de solicitud para obtener la conexión correcta del pool y ejecutar la consulta en la base de datos de inquilinos dedicada.

  Esta opción tiene ventajas y desventajas:

  • Pros: máximo aislamiento, seguridad y rendimiento. Los inquilinos pueden incluso estar en diferentes versiones de base de datos o tipos de motor.
  • Cons: los mayores gastos operativos, costos y complejidad. Las migraciones y los parches de base de datos se deben ejecutar en todas las bases de datos de inquilinos.

Esta arquitectura implementa los siguientes componentes:

• Tenancy

  Un arrendamiento es una partición segura y aislada que Oracle configura en Oracle Cloud cuando se registra en OCI. Puede crear, organizar y administrar sus recursos en OCI dentro de su arrendamiento. Un arrendamiento es sinónimo de una compañía u organización. Normalmente, una compañía tendrá un único arrendamiento y reflejará su estructura organizativa dentro de ese arrendamiento. Un único arrendamiento suele estar asociado a una única suscripción y una única suscripción suele tener un solo arrendamiento.

• OCI Identity and Access Management

  Oracle Cloud Infrastructure Identity and Access Management (IAM) proporciona control de acceso de usuario para OCI y Oracle Cloud Applications. La API de IAM y la interfaz de usuario le permiten gestionar los dominios de identidad y los recursos que contienen. Cada dominio de identidad de OCI IAM representa una solución de gestión de identidad y acceso independiente o un grupo de usuarios diferente.

• Equilibrador de carga

  Oracle Cloud Infrastructure Load Balancer proporciona la distribución automatizada de tráfico desde un único punto para acceder a varios servidores.

• Gateway de API de OCI

  Oracle Cloud Infrastructure API Gateway permite publicar API con puntos finales privados a los que se puede acceder desde la red y que, si es necesario, se pueden exponer a la red pública de Internet. Los puntos finales soportan las validaciones de API, las transformaciones de solicitud y respuesta, CORS, la autenticación y autorización, y la limitación de solicitudes.

• Oracle Key Management Cloud Service

  Servicio de gestión de claves de OCI El servicio de gestión de claves de Oracle Cloud Infrastructure (OCI) (KMS) es un servicio basado en la nube que proporciona gestión y control centralizados de claves de cifrado para los datos almacenados en OCI. OCI KMS es un cifrado gestionado por el cliente y ofrece servicios OCI Vault (tanto de almacén virtual como de almacén privado), OCI Dedicated KMS y OCI External KMS.

• Computación de OCI

  Con Oracle Cloud Infrastructure Compute, puede aprovisionar y gestionar hosts informáticos en la nube. Puede iniciar instancias informáticas con unidades que cumplan los requisitos de recursos para CPU, memoria, ancho de banda de red y almacenamiento. Después de crear una instancia informática, puede acceder a ella de forma segura, reiniciarla, asociar y desasociar volúmenes, y terminarla cuando ya no la necesite.

• Funciones de OCI

  Oracle Cloud Infrastructure Functions es una plataforma de funciones como servicio (FaaS) totalmente gestionada, multiinquilino, altamente escalable y a demanda. Se basa en el motor de código abierto Fn Project. OCI Functions le permite desplegar su código y llamarlo directamente o dispararlo en respuesta a eventos. OCI Functions utiliza contenedores de Docker alojados en Oracle Cloud Infrastructure Registry.

• OCI Kubernetes Engine

  Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine o OKE) es un servicio totalmente gestionado, escalable y de alta Disponibilidad que puede utilizar para desplegar aplicaciones de contenedores en la nube. Especifique los recursos informáticos que necesitan sus aplicaciones y OKE los aprovisiona en OCI en un arrendamiento existente. OKE utiliza Kubernetes para automatizar el despliegue, la ampliación y la gestión de aplicaciones en contenedores en clusters de hosts.

• Oracle HeatWave MySQL

  Oracle MySQL Database Service es un servicio a base de Datos totalmente gestionado que permite a los desarrolladores desarrollar e implementar rápidamente aplicaciones nativas en la nube seguras usando la base de Datos de Código Abierto más popular en el mundo. Oracle HeatWave MySQL es un nuevo acelerador de consultas en memoria integrado y de alto rendimiento para Oracle MySQL Database Service que acelera el rendimiento de MySQL para análisis y consultas transaccionales.

• Oracle NoSQL Database Cloud Service

  Oracle NoSQL Database Cloud Service facilita a los desarrolladores la creación de aplicaciones mediante modelos de base de datos de documentos, esquemas fijos y clave-valor, lo que ofrece tiempos de respuesta predecibles en milisegundos de un solo dígito con replicación de datos para una alta disponibilidad. El servicio ofrece replicación regional activa-activa, transacciones ACID, escalado sin servidor, seguridad completa y precios de pago por uso bajos para los modos de capacidad bajo demanda y aprovisionada, incluida una compatibilidad del 100% con Oracle NoSQL Database local.

• OCI Object Storage

  OCI Object Storage proporciona acceso a grandes cantidades de datos estructurados y no estructurados de cualquier tipo de contenido, incluidas copias de seguridad en bases de datos, datos analíticos y contenido enriquecido como imágenes y vídeos. Puede almacenar datos de forma segura directamente desde las aplicaciones o desde la plataforma en la nube. Puedes ampliar el almacenamiento sin experimentar ninguna degradación del rendimiento o la fiabilidad del servicio.

  Utilice el almacenamiento estandar para el almacenamiento "caliente" al que debe acceder de forma rápida, inmediata y frecuente. Utilice este tipo de almacenamiento para el almacenamiento "frío" que conserva durante largos períodos de tiempo y a los a los que rara vez accede.

• Oracle Autonomous Database Serverless

  Oracle Autonomous Database Serverless es una Oracle Autonomous Database. Tiene una base de datos totalmente flexible en la que Oracle opera de forma autónoma todos los aspectos del ciclo de vida de la base de datos, desde la colocación de la base de datos hasta la copia de seguridad y las actualizaciones.

• Cifrado de datos transparente

  Cifrado de datos transparente (TDE) cifra de forma transparente los datos estáticos en una instancia de Oracle AI Database. TDE está totalmente integrado con Oracle AI Database y puede cifrar copias de seguridad de bases de datos completas (RMAN), exportaciones de pump de datos, tablespaces de aplicación completos o columnas confidenciales específicas. Los datos cifrados permanecen cifrados en la base de datos, tanto si se encuentran en archivos de almacenamiento de tablespace como en tablespaces temporales, tablespaces de deshacer u otros archivos como redo logs. Esto evita intentos no autorizados de acceder a los datos de la base de datos sin afectar a la forma en que las aplicaciones acceden a los datos mediante SQL.

Recomendaciones

Utilice las siguientes recomendaciones como punto de partida para diseñar la arquitectura. Sus requisitos pueden diferir de la arquitectura que se describe aquí.

• VCN

  Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que tenga previsto asociar a las subredes de la VCN. Utilice bloques CIDR que se encuentren dentro del espacio de direcciones IP privadas estándar.

  Seleccione bloques CIDR que no se solapen con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) en la que desee configurar conexiones privadas.

  Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.

  Al diseñar las subredes, tenga en cuenta los requisitos de seguridad y el flujo de tráfico. Asocie todos los recursos de un nivel o rol específico a la misma subred, lo que puede servir como límite de seguridad.

• Listas de seguridad

  Utilice listas de seguridad para definir las reglas de entrada y salida que se aplican a toda la subred.

• Grupos de seguridad de red (NSG)

  Puede utilizar los NSG para definir un juego de reglas de entrada y salida que se aplican a VNIC específicas. Recomendamos utilizar NSG en lugar de listas de seguridad, ya que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de la aplicación.

• Cloud Guard

  Clone y personalice las recetas por defecto proporcionadas por Oracle para crear recetas personalizadas de detector y responsable de respuesta. Estas recetas le permiten especificar qué tipo de violaciones de seguridad generan una advertencia y qué acciones se pueden realizar en ellas. Por ejemplo, puede que desee detectar cubos de OCI Object Storage que tengan visibilidad definida como pública.

  Aplique Oracle Cloud Guard en el nivel de arrendamiento para abarcar el ámbito más amplio y reducir la carga administrativa que supone mantener varias configuraciones.

  También puede utilizar la función Managed List para aplicar determinadas configuraciones a los detectores.

• Security Zones

  Para los recursos que requieren la máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta de políticas de seguridad definida por Oracle que se basa en las mejores prácticas. Por ejemplo, los recursos de una zona no deben ser accesibles desde la red pública de Internet y deben estar cifrados mediante claves gestionadas por los clientes. Al crear y actualizar recursos en una zona de seguridad, OCI valida las operaciones con respecto a las políticas de la receta y evita las operaciones que violan cualquiera de las políticas.

Consideraciones

Al desplegar esta arquitectura, tenga en cuenta estas opciones.

• Rendimiento:
  • Definir límite de frecuencia basado en inquilinos en API
  • Utilizar cuotas de recursos de Kubernetes por espacio de nombres en OKE para limitar los pods, la CPU y la memoria por inquilino
  • Uso de pools de nodos dedicados para inquilinos de alta demanda
  • Definir un tamaño de pool por inquilino en la conexión de base de datos
• Seguridad:
  • Los grupos de OCI IAM controlan a qué inquilino puede acceder un usuario. Esto lo aplica el JWT.
  • Activar Oracle Cloud Guard para detectar configuraciones incorrectas
• Costo:

  Evalúe en función de las necesidades de su negocio tanto si necesita un nivel de tabla, de esquema o una base de datos dedicada para clientes de nivel empresarial. Por ejemplo:

  • Nivel 1: estándar (columna discriminadora): los inquilinos comparten las mismas tablas/esquemas.
  • Nivel 2: Premium (Esquema por inquilino): los inquilinos obtienen un esquema dedicado dentro de la misma base de datos.
  • Nivel 3: Enterprise (base de datos por inquilino): los inquilinos obtienen una instancia de base de datos dedicada.
• Aplicación de parches y actualizaciones de aplicaciones

  En una arquitectura SaaS de instancia única y multiinquilino, no puede aplicar parches a un inquilino sin aplicar parches a todos ellos. Todos sus clientes comparten la misma base de código de aplicación, tiempo de ejecución e infraestructura. Esta realidad crea un desafío significativo: ¿cómo implementas las actualizaciones de forma segura, eficiente y sin causar un tiempo de inactividad disruptivo para toda tu base de usuarios? La respuesta se encuentra en las modernas estrategias de despliegue de DevOps diseñadas específicamente para este propósito: utilizar estrategias de despliegue sin tiempo de inactividad para permitir transiciones fluidas entre versiones sin forzar a los usuarios a estar fuera de línea.

  • Despliegue azul-verde: implica el mantenimiento de dos entornos de producción idénticos: uno "azul" (que ejecuta la versión actual) y otro "verde" (que ejecuta la nueva versión). Después de desplegar y probar la nueva versión en verde, puede cambiar sin problemas todo el tráfico de azul a verde. Si algo sale mal, se vuelve a cambiar instantáneamente, lo que hace que el rollback no sea un evento. El antiguo entorno azul se desmantela.
  • Despliegue de canario: esta estrategia reduce el riesgo mediante la realización de una implementación gradual. La nueva versión se despliega en un pequeño subconjunto controlado de usuarios (los "canarios"). Este grupo se controla de cerca en busca de errores o problemas de rendimiento. Si las métricas se ven bien, gradualmente implementará la actualización a más usuarios hasta que todos estén en la nueva versión.

  Se notifica a los usuarios una ventana de actualización obligatoria (por ejemplo, "Si no se especifica ninguna fecha de actualización, la actualización se realizará automáticamente a las 12:00 del domingo, mm/dd/yyyy"). Después de la ventana, terminará las sesiones para la versión anterior y redirigirá todo el tráfico a la nueva versión. El código de aplicación antiguo se cierra por completo.

• Consideraciones sobre la base de datos

  No puede cambiar el esquema de base de datos en el momento exacto en que cambia la versión de la aplicación. La mayoría de las compañías SaaS evitan esto mediante:

  • Cambios de esquema de base de datos compatibles con versiones anteriores
  • Indicadores/actualizaciones de funciones
  • Control de versión basado en metadatos de inquilino

  Esto permite que el código nuevo funcione de forma segura con versiones de esquema antiguas durante la implementación, lo que permite realizar migraciones sin tiempo de inactividad y realizar rollback instantáneo.

Explorar más

Obtenga más información sobre el despliegue de aplicaciones multiinquilino.

Revise estos recursos adicionales:

• Configurar la infraestructura para alojar varias aplicaciones SaaS de inquilino único
• Oracle Private Cloud Appliance Escritura de políticas para acceder a recursos en distintos arrendamientos
• Acceso entre arrendamientos: AssumeRole en OCI (blog)
• Oracle Multitenant
• Documentación deOracle Cloud Infrastructure
• Marco bien diseñado para Oracle Cloud Infrastructure
• Marco de adopción de la nube

Acuses de recibo

• Autor: Gururaj Mohan, Enterprise Cloud Architect
• Contributors: Joshua Stanley