Modèle de déploiement d'applications colocatif sur OCI

Dans le monde d'aujourd'hui axé sur le cloud, les entreprises et les fournisseurs de logiciels indépendants (ISV) transforment de plus en plus les applications traditionnelles en offres de logiciels en tant que services (SaaS). Le modèle de déploiement colocatif est un composant essentiel de cette transformation. Il permet à plusieurs clients de partager la même application tout en garantissant la sécurité, les performances et la rentabilité. Oracle Cloud Infrastructure (OCI) fournit un ensemble robuste de services qui facilitent la fourniture d'applications SaaS à l'aide d'approches hybrides et de location partagées.

A propos des locations

Il est important de ne pas confondre la location OCI avec le concept de locataire dans une application SaaS.

Location OCI : compte que vous recevez lors de votre inscription aux services OCI. Il représente votre compte root et sert de partition sécurisée et isolée dans laquelle vous organisez et gérez vos ressources OCI.

Un locataire (dans un contexte SaaS) : supposons qu'un ISV crée une plate-forme SaaS sur OCI. Lorsque l'ISV provisionne ses propres clients sur la plate-forme, chacun de ces clients est considéré comme un locataire. Un locataire dans ce sens représente une organisation client, et chaque locataire peut avoir plusieurs utilisateurs associés.

En bref, un Emplacement OCI fait référence au compte OCI lui-même, tandis qu'un locataire fait référence à une organisation (comme un client SaaS) qui utilise une application hébergée sur OCI par une autre entité, telle qu'un ISV.

Architecture

Cette architecture représente un modèle de déploiement d'applications colocatives sur OCI, à un niveau élevé.

Le diagramme suivant illustre cette architecture de référence :


Illustration de l'image multi-tenant-app-oci.png
Description de l'illustration multi-tenant-app-oci.png

multi-tenant-app-oci-oracle.zip

Cette architecture flexible est organisée en trois couches :

Couche Description Action clé
Authentification initiale (OCI IAM) Vérifier l'identité globale Emettre un jeton Web JSON (JWT) après la validation des informations d'identification
Middleware d'authentification Vérifier l'identité par demande Extraire le contexte utilisateur et locataire à partir de JWT
Couche d'accès aux données ou crochets ORM Imposer l'isolement des données Filtrer automatiquement toutes les requêtes par tenant_id

Chaque couche est décrite ci-dessous :

Authentification initiale et établissement du contexte du locataire

  • Service d'authentification : l'utilisateur se connecte, généralement à l'aide d'une URL propre au locataire (par exemple, mycompany.app.com) ou en sélectionnant un locataire lors de la connexion.
  • OCI Identity and Access Management (OCI IAM) en tant que fournisseur d'identités : OCI IAM (en particulier, un domaine d'identité dédié) valide les informations d'identification de l'utilisateur. Il confirme que l'utilisateur n'est pas seulement valide, mais qu'il est également membre du groupe de locataires spécifique (par exemple, les utilisateurs mycompany) auquel ils tentent d'accéder.
  • Emission JWT : une fois l'authentification réussie, le domaine d'identité OCI IAM émet un jeton Web JSON signé. Ce token inclut les revendications critiques suivantes :
    • sub : Identificateur unique de l'utilisateur.
    • groups : tableau d'OCID des groupes IAM auxquels l'utilisateur appartient. Il s'agit de la clé permettant d'identifier le locataire.
    • Une revendication personnalisée telle que tenant_id ou tenant_name peut être ajoutée à l'aide d'attributs personnalisés dans OCI IAM. (facultatif).

Authentification Middleware – couche "Qui"

Le back-end doit être conçu pour extraire et propager le contexte du locataire en toute sécurité. Cette architecture prend en charge l'utilisation d'OCI API Gateway ou d'OCI Load Balancer pour effectuer une authentification par demande et une propagation de contexte de locataire.

  • Passerelle API OCI : il s'agit du point d'entrée recommandé. Il peut effectuer lui-même la validation JWT, en déchargeant cette responsabilité de votre code d'application. Vous la configurez pour valider la signature par rapport à l'adresse JWKS de votre domaine d'identité OCI IAM.
  • Equilibreur de charge OCI : peut gérer la terminaison et le routage SSL, mais transmet le jeton JWT au middleware d'authentification pour validation.

Action : OCI API Gateway valide la signature et l'expiration du jeton JWT. Si elle n'est pas valide, la demande est immédiatement rejetée. S'il est valide, il transmet la demande au service en amont, en transmettant souvent le jeton validé ou les demandes extraites dans des en-têtes (par exemple, X-USER-ID, X-TENANT-ID).

Si vous utilisez OCI Load Balancer au lieu d'OCI API Gateway, le premier composant de votre back-end d'application doit être le middleware d'authentification.

Action : extrayez le jeton JWT de l'en-tête Authorization: Bearer <token>, vérifiez sa signature à l'aide des clés publiques d'OCI IAM, décodez les demandes et injectez les éléments user_id et tenant_id (dérivés de la demande de groupes) dans le contexte de demande pour toutes les couches suivantes à utiliser.

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

Cette couche injecte automatiquement l'ID de locataire dans chaque requête SQL.

  • Exemple : un appel vers getAllInvoices() est transformé en SELECT * FROM invoices WHERE tenant_id = :tenant_id.
  • Application : il est préférable de l'appliquer par une couche d'accès aux données centralisée ou par un hook ORM (tel que Hibernate) ou un pool de connexions "tenant-aware" pour éviter les erreurs humaines.
  • Hooks ORM : mécanisme qui permet une véritable isolation implicite des locataires en interceptant et en modifiant les opérations de base de données au niveau de la structure d'application.

Stratégies d'isolement des données des locataires :

Cette architecture prend en charge deux options pour isoler et protéger les données de vos locataires :

Option 1 : niveau application

Hooks/portées ORM : les structures telles que Hibernate (Java), Django ORM (Python) ou Eloquent (PHP) vous permettent de définir des portées globales qui ajoutent automatiquement le filtre de locataire à toutes les requêtes pour un modèle spécifique.

ou

Option 2 : niveau de base de données

Vous pouvez utiliser une colonne de discriminateur, un schéma distinct par locataire ou une base de données distincte par locataire :

  • Colonne du discriminateur (la plus courante) :

    Une colonne tenant_id est ajoutée à chaque table ou document propre au locataire.

    La couche d'accès aux données (DAL) ou ORM de l'application est chargée d'ajouter automatiquement la clause WHERE tenant_id = ? à chaque requête. Pour ce faire, il faut :

    • Modèle de référentiel : tous les flux d'accès à la base de données via une classe centrale ou un ensemble de classes. Ce référentiel ajoute automatiquement le filtre de locataire à chaque opération SELECT, INSERT, UPDATE et DELETE en fonction de tenant_id dans le contexte de demande en cours.
    • Contexte de connexion : pour certaines bases de données SQL (telles qu'Oracle HeatWave MySQL), l'application peut définir une variable de session (par exemple, SET @tenant_id = 'mycompany123';), puis l'utiliser dans des vues ou des procédures stockées. Toutefois, la couche d'application est toujours responsable de la définition de cette valeur par connexion.
  • Schéma par locataire :

    Chaque locataire possède un schéma de base de données dédié au sein de la même instance de base de données.

    La logique d'application, basée sur l'ID de locataire, doit changer le schéma en cours de la connexion de base de données.

    • Pool de connexions par locataire : conservez un pool de connexions distinct pour chaque locataire, où chaque connexion est préconfigurée pour utiliser le schéma du locataire (par exemple, USE tenant_mycompany;).
    • Commutation de connexion dynamique : utilisez un pool de connexions qui définit le schéma lors de l'extraction en fonction de l'élément tenant_id en cours (par exemple, en utilisant une commande SET search_path TO tenant_mycompany; pour PostgreSQL).
  • Base de données par locataire :

    Chaque locataire possède sa propre instance de base de données physiquement distincte avec le cryptage avec vos propres clés pour les entreprises.

    L'application a besoin d'un service de recherche de données de locataire pour mettre en correspondance une valeur tenant_id avec la chaîne de connexion de base de données correcte.

    • L'application contient des pools de connexions vers plusieurs bases de données.
    • Le DAL utilise l'ID de locataire du contexte de demande pour obtenir la connexion correcte à partir du pool et exécuter l'interrogation sur la base de données de locataires dédiée.

    Cette option présente des avantages et des inconvénients :

    • Problèmes : isolation maximale, sécurité et performances. Les locataires peuvent même être sur des versions de base de données ou des types de moteur différents.
    • Consommations : frais généraux opérationnels, coûts et complexité les plus élevés. Les migrations de base de données et les patches doivent être exécutés sur chaque base de données locataire.

Cette architecture implémente les composants suivants :

  • Tenancy

    Une location est une partition sécurisée et isolée qu'Oracle configure dans Oracle Cloud lorsque vous souscrivez à OCI. Vous pouvez créer, organiser et administrer vos ressources sur OCI dans votre location. Une location est synonyme d'entreprise ou d'organisation. Habituellement, une entreprise aura une seule location et reflétera sa structure organisationnelle au sein de cette location. Une location unique est généralement associée à un seul abonnement, et un seul abonnement n'a généralement qu'une seule location.

  • OCI Identity and Access Management

    Oracle Cloud Infrastructure Identity and Access Management (IAM) fournit un contrôle d'accès utilisateur pour OCI et Oracle Cloud Applications. L'API IAM et l'interface utilisateur vous permettent de gérer les domaines d'identité et les ressources qu'ils contiennent. Chaque domaine d'identité OCI IAM représente une solution autonome de gestion des identités et des accès ou une population d'utilisateurs différente.

  • Equilibreur de charge

    Oracle Cloud Infrastructure Load Balancer fournit une distribution automatisée du trafic d'un point d'entrée unique à plusieurs serveurs.

  • Passerelle d'API OCI

    Oracle Cloud Infrastructure API Gateway vous permet de publier des API avec des adresses privées accessibles à partir de votre réseau, et que vous pouvez exposer au réseau Internet public si nécessaire. Les adresses prennent en charge la validation d'API, la transformation des demandes et des réponses, la spécification CORS, l'authentification et l'autorisation, ainsi que l'autorisation des demandes.

  • Oracle Key Management Cloud Service

    OCI Key Management Service Oracle Cloud Infrastructure (OCI) Key Management Service (KMS) est un service cloud qui fournit une gestion et un contrôle centralisés des clés de cryptage pour les données stockées dans OCI. OCI KMS est un cryptage géré par le client et offre des services OCI Vault (Virtual Vault et Private Vault), OCI Dedicated KMS et OCI External KMS.

  • Calcul OCI

    Avec Oracle Cloud Infrastructure Compute, vous pouvez provisionner et gérer des hôtes de calcul dans le cloud. Vous pouvez lancer des instances de calcul avec des formes qui répondent à vos besoins en ressources pour l'UC, la mémoire, la bande passante réseau et le stockage. Après avoir créé une instance de calcul, vous pouvez y accéder en toute sécurité, la redémarrer, attacher et détacher des volumes, et y mettre fin lorsque vous n'en avez plus besoin.

  • Fonctions OCI

    Oracle Cloud Infrastructure Functions est une plate-forme de fonctions en tant que service (FaaS) entièrement gérée, colocative, hautement évolutive et à la demande. Il est optimisé par le moteur open source du projet Fn. OCI Functions vous permet de déployer votre code, l'appeler directement ou le déclencher en réponse à des événements. OCI Functions utilise des conteneurs Docker hébergés dans Oracle Cloud Infrastructure Registry.

  • OCI Kubernetes Engine

    Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine ou OKE) est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications en conteneur vers le cloud. Vous indiquez les ressources de calcul dont vos applications ont besoin, et OKE les provisionne sur OCI dans une location existante. OKE utilise Kubernetes pour automatiser le déploiement, la mise à l'échelle et la gestion des applications en conteneur dans les clusters d'hôtes.

  • Oracle HeatWave MySQL

    Oracle MySQL Database Service est un service de base de données entièrement géré qui permet aux développeurs de développer et de déployer rapidement des applications cloud natives sécurisées à l'aide de la base de données open source la plus populaire au monde. Oracle HeatWave MySQL est un nouvel accélérateur de requêtes en mémoire intégré et hautes performances pour Oracle MySQL Database Service qui accélère les performances MySQL pour les analyses et les requêtes transactionnelles.

  • Oracle NoSQL Database Cloud Service

    Oracle NoSQL Database Cloud Service permet aux développeurs de créer facilement des applications à l'aide de modèles de base de données de type document, schéma fixe et clé-valeur, offrant des temps de réponse prévisibles à un chiffre en millisecondes avec réplication de données pour une haute disponibilité. Ce service propose une réplication régionale active-active, des transactions ACID, une mise à l'échelle sans serveur, une sécurité complète et des tarifs de faible paiement à l'utilisation pour les modes de capacité à la demande et provisionnée, avec une compatibilité à 100 % avec Oracle NoSQL Database sur site.

  • OCI Object Storage

    OCI Object Storage fournit un accès à des quantités importantes de informations structurées et non, de tout type de contenu, y compris les sauvegardes de base de donnée, les données analytiques et le contenu enrichi tel que des images et des vidéos. Vous pouvez stocker des données en toute sécurité directement à partir des applications ou de la plate-forme cloud. Vous pouvez redimensionner le stockage sans dégradation des performances ni de la fiabilité de services.

    Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archive pour le stockage "à froid" que vous conservez durant de longues périodes et auquel il est rare d'y accéder.

  • Oracle Autonomous Database Serverless

    Oracle Autonomous Database Serverless est une solution Oracle Autonomous Database. Vous disposez d'une base de données entièrement élastique où Oracle opère en toute autonomie tous les aspects du cycle de vie de la base, du placement de la base de données à la sauvegarde et aux mises à jour.

  • Cryptage transparent des données

    Le cryptage transparent des données (TDE) crypte de manière transparente les données inactives dans une Oracle AI Database. TDE est entièrement intégré à Oracle AI Database et peut crypter des sauvegardes de base de données complètes (RMAN), des exports Data Pump, des tablespaces d'application entiers ou des colonnes confidentielles spécifiques. Les données cryptées restent cryptées dans la base de données, qu'il s'agisse de fichiers de stockage de tablespace, de tablespaces temporaires, de tablespaces d'annulation ou d'autres fichiers tels que les fichiers de journalisation. Cela empêche les tentatives non autorisées d'accéder aux données de la base de données sans affecter la façon dont les applications accèdent aux données à l'aide de SQL.

Recommandations

Utilisez les recommandations suivantes comme point de départ pour concevoir votre architecture. Vos exigences peuvent différer de l'architecture décrite ici.
  • VCN

    Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux dans le VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adressage IP privé standard.

    Sélectionnez des blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) sur lequel vous prévoyez de configurer des connexions privées.

    Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.

    Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Associez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.

  • Listes de sécurité

    Utilisez des listes de sécurité pour définir des règles entrantes et sortantes qui s'appliquent à l'ensemble du sous-réseau.

  • Groupes de sécurité réseau

    Vous pouvez utiliser des groupes de sécurité réseau pour définir un ensemble de règles entrantes et sortantes qui s'appliquent à des cartes d'interface réseau virtuelles spécifiques. Nous vous recommandons d'utiliser des groupes de sécurité réseau plutôt que des listes de sécurité, car les groupes de sécurité réseau vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de votre application.

  • Cloud Guard

    Clonez et personnalisez les recettes par défaut fournies par Oracle pour créer des recettes personnalisées de détecteur et de répondeur. Ces recettes vous permettent d'indiquer le type de violation de sécurité qui génère un avertissement et les actions autorisées à y être effectuées. Par exemple, vous pouvez détecter les buckets OCI Object Storage dont la visibilité est définie sur Public.

    Appliquez Oracle Cloud Guard au niveau de la location pour couvrir la portée la plus large et réduire la charge administrative liée à la maintenance de plusieurs configurations.

    Vous pouvez également utiliser la fonctionnalité de liste gérée pour appliquer certaines configurations aux détecteurs.

  • Security Zones

    Pour les ressources nécessitant une sécurité maximale, Oracle recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de stratégies de sécurité définie par Oracle basée sur les meilleures pratiques. Par exemple, les ressources d'une zone d'accès ne doivent pas être accessibles à partir du réseau Internet public et elles doivent être cryptées à l'aide de clés gérées par un client. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, OCI valide les opérations par rapport aux stratégies de la recette et empêche les opérations qui violent l'une des stratégies.

Points à prendre en compte

Lors du déploiement de cette architecture, tenez compte de ces options.

  • Performances:
    • Définir une limitation de débit basée sur le locataire sur les API
    • Utiliser les quotas de ressources Kubernetes par espace de noms dans OKE pour limiter les pods, l'UC et la mémoire par locataire
    • Exploiter des pools de noeuds dédiés pour les locataires à forte demande
    • Définir une taille de pool par locataire sur la connexion de base de données
  • Sécurité (Security):
    • Les groupes OCI IAM contrôlent le locataire auquel un utilisateur peut accéder. Ceci est appliqué par le jeton JWT.
    • Activer Oracle Cloud Guard pour détecter les erreurs de configuration
  • Coût:

    Évaluez en fonction des besoins de votre entreprise, que vous ayez besoin d'une table, d'un schéma ou d'une base de données dédiée pour les clients de l'entreprise. Exemple :

    • Niveau 1 : standard (colonne discriminatrice) : les locataires partagent les mêmes tables/schéma.
    • Niveau 2 : Premium (schéma par locataire) : les locataires obtiennent un schéma dédié dans la même base de données.
    • Niveau 3 : Enterprise (base de données par locataire) : les locataires obtiennent une instance de base de données dédiée.
  • Application de patches et mises à jour d'application

    Dans une architecture SaaS à instance unique et colocative, vous ne pouvez pas appliquer de patches à un locataire sans tous les appliquer. Tous vos clients partagent la même base de code d'application, la même exécution et la même infrastructure. Cette réalité crée un défi important : comment déployer les mises à jour en toute sécurité, efficacement et sans provoquer de temps d'arrêt perturbant pour l'ensemble de votre base d'utilisateurs ? La réponse réside dans les stratégies de déploiement DevOps modernes conçues spécifiquement à cet effet : utilisez des stratégies de déploiement sans temps d'arrêt pour permettre des transitions transparentes entre les versions sans forcer les utilisateurs à se déconnecter.

    • Déploiement bleu-vert : cela implique la maintenance de deux environnements de production identiques : un "Bleu" (exécution de la version en cours) et un "Vert" (exécution de la nouvelle version). Après avoir déployé et testé la nouvelle version dans Green, vous passez facilement de Blue à Green. Si quelque chose ne va pas, vous revenez instantanément en arrière, ce qui fait de la restauration un non-événement. L'ancien environnement bleu est ensuite mis hors service.
    • Déploiement canari : cette stratégie réduit les risques en effectuant un déploiement progressif. La nouvelle version est déployée sur un petit sous-ensemble contrôlé d'utilisateurs (les "canaries"). Vous surveillez de près ce groupe pour détecter les erreurs ou les problèmes de performances. Si les mesures semblent correctes, vous déployez progressivement la mise à jour vers plus d'utilisateurs jusqu'à ce que tout le monde soit sur la nouvelle version.

    Vous informez les utilisateurs d'une fenêtre de mise à niveau obligatoire (par exemple, "Si aucune date de mise à niveau n'est indiquée, la mise à niveau aura lieu automatiquement à 12h00 le dimanche, mm/dd/yyyy"). Après la fenêtre, vous mettez fin aux sessions de l'ancienne version et redirigez tout le trafic vers la nouvelle version. L'ancien code de l'application est alors complètement arrêté.

  • Considérations relatives à la base de données

    Vous ne pouvez pas changer de schéma de base de données au moment exact où vous changez de version d'application. La plupart des entreprises SaaS évitent cela en utilisant :

    • Modifications de schéma de base de données rétrocompatibles
    • Indicateurs/toggles de fonctionnalité
    • Contrôle de version basé sur les métadonnées du locataire

    Cela permet au nouveau code de fonctionner en toute sécurité sur les anciennes versions de schéma lors du déploiement, ce qui permet des migrations sans temps d'arrêt et une annulation instantanée.

En savoir plus

En savoir plus sur le déploiement d'applications colocatives.

Consultez les ressources supplémentaires suivantes :

Accusés de réception

  • Auteur : Gururaj Mohan, Enterprise Cloud Architect
  • Contributeurs : Joshua Stanley