Cette page présente les bonnes pratiques pour créer une architecture multitenant permettant d'héberger du code non fiable avec Cloud Run. En tant que client Google Cloud , un "locataire" est défini comme l'un de vos propres clients, et le "code non fiable" est le code fourni par ces locataires pour être exécuté sur votre plate-forme.
Cas d'utilisation
Voici quelques cas d'utilisation de ces architectures :
- Plates-formes d'hébergement d'applications : vous fournissez une plate-forme sur laquelle vos clients déploient leur code. Par exemple, une plate-forme d'hébergement Web (les clients fournissent un serveur Web) ou une plate-forme Functions-as-a-Service (les clients fournissent une fonction).
- Plates-formes d'hébergement d'agents : vos clients utilisent des SDK pour créer des agents d'IA, et votre plate-forme les exécute en arrière-plan.
- Plates-formes de modèles affinés : vous offrez la possibilité de personnaliser les modèles d'IA pour chaque client. Votre plate-forme les exécute ensuite à la demande en utilisant des GPU.
- Fonctions définies par l'utilisateur : votre logiciel permet à ses clients de définir une logique personnalisée à l'aide de code. Par exemple, vous fournissez un moteur d'analyse et souhaitez permettre aux clients d'écrire des fonctions personnalisées, ou vous fournissez une passerelle API et souhaitez permettre aux clients de filtrer ou de modifier les requêtes en fonction de leur propre logique personnalisée.
- Extensibilité Software as a Service (SaaS) : vous proposez peut-être un SaaS et souhaitez permettre aux clients d'étendre ses fonctionnalités à l'aide d'extensions. Ces extensions peuvent être écrites par des clients ou des partenaires.
Les clientsGoogle Cloud utilisent Cloud Run en production pour ces cas d'utilisation.
Défis des plates-formes mutualisées
Voici quelques-uns des défis typiques liés à la création d'une telle architecture :
- Sécurité : il est impossible d'analyser ou de nettoyer le code fourni. Le code non fiable peut inclure des actions malveillantes ou des dépendances vulnérables. S'il n'est pas correctement isolé, le code non approuvé peut potentiellement accéder aux données sensibles appartenant à d'autres locataires. Le simple fait d'empaqueter le code dans un conteneur ne constitue pas une limite de sécurité suffisamment solide. Le code doit également être limité dans ce qu'il peut faire en appliquant le principe des autorisations du moindre privilège.
- Rentabilité : une telle architecture peut devenir coûteuse si chaque locataire engendre des coûts fixes pour votre plate-forme.
- Gestion des locataires : la gestion de centaines de milliers de locataires peut être difficile, notamment en ce qui concerne la suppression des données.
Avantages de Cloud Run
Une architecture basée sur Cloud Run offre une solution aux défis courants, avec de nombreux avantages tels que la sécurité, la rentabilité et la gestion des locataires.
Sécurité
Cloud Run fournit les fonctionnalités de sécurité prêtes à l'emploi pertinentes pour cette architecture :
- Isolation du calcul : Cloud Run assure une isolation stricte entre les instances de conteneur, qu'il s'agisse du même service ou de services différents provenant de projets différents. Pour en savoir plus sur la sécurité des conteneurs et les environnements d'exécution, consultez Présentation de la conception de sécurité.
- Mises à jour de sécurité : les mises à jour de sécurité automatiques des images de base peuvent être activées pour maintenir à jour et corriger le système d'exploitation et l'exécution des charges de travail déployées sans nécessiter de redéploiements à grande échelle.
- Isolation du réseau : Cloud Run ne se contente pas de mettre les conteneurs en bac à sable, il fournit également une pile réseau multilocataire.
- Identité de service : les charges de travail Cloud Run peuvent être configurées pour disposer d'identités dédiées avec des autorisations limitées.
Rentabilité
- Scaling à zéro instance et paiement à l'utilisation : les instances Cloud Run passent automatiquement à zéro instance lorsqu'elles ne sont pas utilisées. Les charges de travail hébergées ne sont donc facturées que lorsqu'elles doivent s'exécuter. Cela permet une utilisation très efficace des ressources par rapport aux architectures qui utilisent des machines virtuelles "toujours activées".
- Facturation par requête : en plus de la mise à l'échelle à zéro, vous pouvez bénéficier d'un modèle de facturation encore plus précis qui ne facture que lorsque les requêtes sont traitées, ce qui permet une efficacité encore plus élevée en termes de coûts.
- Démarrage rapide et à la demande : lorsque les services Cloud Run sont réduits, ils peuvent rapidement être réaugmentés, ce qui entraîne une faible latence perçue par l'utilisateur final de l'application déployée.
- Libellés de coûts automatiques : tous les coûts signalés par Cloud Run sont libellés, ce qui vous permet d'automatiser l'attribution et le suivi des coûts de vos locataires.
- Engagements pour réduire les coûts globaux : au niveau du compte de facturation, vous pouvez utiliser les remises sur engagement d'utilisation flexibles pour optimiser les dépenses pour toute utilisation de base de Cloud Run.
Gestion des locataires
En raison de sa nature à la demande, les coûts de Cloud Run ne sont pas plus élevés lorsque vous utilisez plusieurs projets Google Cloud , ce qui permet la gestion des locataires comme décrit dans Organiser vos projets Google Cloud .
Architecture cible pour les plates-formes mutualisées
Voici l'architecture recommandée :
Organiser vos projets Google Cloud
Vous devez configurer une organisation Google Cloud , la facturation hors connexion et contacter votre équipe chargée du compte pour l'informer que vous agissez en tant que compte revendeur.Google Cloud pourra collaborer avec vous pour s'assurer que les canaux de communication appropriés sont mis en place pour limiter les utilisations abusives.
Vous devez utiliser des dossiers pour organiser vos projets Google Cloud . Il est notamment essentiel de placer dans des dossiers différents les projets exécutant votre code propriétaire et ceux exécutant le code non fiable de vos locataires. Vous devez automatiser l'intégration des locataires afin que la création des projets et des ressources d'un locataire ne nécessite pas d'intervention humaine.
Google recommande d'utiliser un projet Google Cloud par locataire. Il est également possible d'héberger plusieurs locataires dans le même projet, mais cela entraîne des limites supplémentaires :
Un seul locataire par projet Google Cloud (recommandé)
Dans cette architecture, chaque locataire de votre plate-forme est hébergé dans un projetGoogle Cloud dédié, ce qui présente de nombreux avantages :
- Sécurité simplifiée : le projet Google Cloud constitue une limite stricte pour toutes les ressources qu'il contient. Cela signifie que si un locataire a besoin d'accéder à plusieurs ressourcesGoogle Cloud , comme plusieurs services Cloud Run ou un bucket Cloud Storage, vous pouvez utiliser le projet comme périmètre sécurisé.
- Moins de limites :
- Le nombre de ressources dans un projet donné est limité. Par exemple, Cloud Run n'autorise la création que de 1 000 services par région dans un projet. Des limites similaires s'appliquent au nombre de comptes de service et d'autres ressources associées.
- Le nombre de projets est lui-même un quota qui peut être augmenté. Il n'y a pas de limite à ce nombre pour une organisation Google Cloud . Il existe une limite flexible de 100 000 projets par compte de facturation, qui peut être multipliée en contactant Google. Votre organisation peut également créer plusieurs comptes de facturation et les regrouper dans un "groupe de comptes" (actuellement en aperçu privé).
- Surveillance et gestion simplifiées :
- L'utilisation d'un projet par locataire facilite les processus de suppression des données, car la suppression des données d'un locataire se résume à la suppression du projet correspondant.
- La surveillance et la journalisationGoogle Cloud fonctionnent dans tous les projets et peuvent vous permettre de surveiller l'ensemble de votre parc.
- Les quotas au niveau du projet vous permettent de limiter l'utilisation des ressources Cloud Run pour un locataire donné, ce qui peut vous aider à aligner les limites sur vos propres niveaux de tarification.
- Règles d'administration personnalisées vous permettent d'appliquer des restrictions spécifiques à tous les projets d'un dossier, telles que les régions disponibles ou l'allocation maximale de processeurs/de mémoire.
La création d'un projet Google Cloud et l'initialisation des API et des ressources peuvent entraîner une latence. Google vous recommande d'utiliser un pool de projets précréés que vous attribuez à vos locataires en cas de besoin.
Plusieurs locataires par projet Google Cloud (non recommandé)
Il est possible d'héberger plusieurs de vos locataires dans le même projet Google Cloud, mais Google ne recommande pas cette architecture.
De nombreux services Google Cloud ont des limites de ressources par projet. Par exemple, Cloud Run impose une limite non ajustable de 1 000 services Cloud Run par région dans un projet. Par conséquent, l'hébergement de plusieurs locataires par projet vous obligera toujours à gérer un parc de Google Cloud projets, ce qui augmentera globalement la complexité de la gestion des locataires. D'un point de vue de la sécurité, les projetsGoogle Cloud sont conçus comme une limite de sécurité. L'hébergement de deux locataires distincts dans les mêmes projets nécessite une plus grande vigilance en matière de sécurité. Par exemple, en utilisant des comptes de service dédiés et des autorisations précises.
Routage des requêtes et domaines personnalisés
Si vous souhaitez exposer les services Cloud Run de votre locataire aux utilisateurs finaux, vous devez ajouter votre propre domaine et utiliser votre propre logique de routage. Par exemple, pour mapper un sous-domaine au projet Google Cloud hébergeant le service du locataire.
Vous pouvez implémenter votre service de routage personnalisé, mais Google recommande d'utiliser un équilibreur de charge d'application externe mondial avec des extensions de service pour la logique de routage. Les extensions de service peuvent être implémentées en tant que plug-ins (où la logique est exécutée en ligne avec le traitement des requêtes) ou en tant qu'appels (la logique de routage est déléguée à un service Cloud Run distinct qui peut appeler l'une des bases de données multirégionales évolutives deGoogle Cloud, comme Spanner).
L'utilisation d'un équilibreur de charge d'application vous permettra également d'ajouter une couche de mise en cache en tirant parti de Cloud CDN et d'une protection supplémentaire contre les attaques par déni de service distribué (DDoS) pour votre plate-forme à l'aide de Cloud Armor.
Réputation et utilisation abusive
Toute plate-forme d'hébergement autorisée à exécuter du code non fiable sera sujette à une utilisation abusive.
Nous vous recommandons d'utiliser un compte de facturation Cloud différent pour chacun des niveaux de réputation que vous proposez. Par exemple, vos locataires de niveau sans frais ne doivent pas être associés au même compte de facturation que vos clients à fort potentiel. Google peut considérer ces comptes de facturation à différents niveaux de réputation.
Comme décrit dans Organiser vos projets, en plus de les séparer par compte de facturation, vous devez utiliser des dossiers pour les organiser. Google Cloud Google peut vous aider à définir des quotas au niveau des dossiers pour vous assurer que toutes les ressources d'un dossier ne consomment jamais plus qu'un maximum défini, ce qui vous permet de mieux gérer les coûts de votre plate-forme.
Par défaut, Google supprime automatiquement les charges de travail abusives conformément aux Conditions d'utilisation deGoogle Cloud . Google peut également enregistrer les événements de détection d'abus dans Cloud Logging, sur lesquels vous pouvez ensuite agir.