Cette page présente les bonnes pratiques à suivre pour créer une architecture mutualisée afin 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 un "code non fiable" est un code fourni par ces locataires pour être exécuté sur votre plate-forme.
Cas d'utilisation
Les cas d'utilisation de ces architectures sont les suivants :
- Plate-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).
- Plateformes d'hébergement d'agents : vos clients utilisent des SDK pour créer des agents 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 exploitant 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 API Gateway et souhaitez permettre aux clients de filtrer ou de modifier les requêtes en fonction de leur propre logique personnalisée.
- Extensibilité du 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 clients deGoogle Cloud utilisent avec succès Cloud Run en production pour ces cas d'utilisation.
Défis des plates-formes mutualisées
Les défis typiques de la création d'une telle architecture sont les suivants :
- 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é suffisante. Le code doit également être limité dans ce qu'il peut faire en appliquant le principe du moindre privilège.
- Rentabilité : une telle architecture peut devenir coûteuse si chaque locataire entraîne des coûts fixes pour votre plate-forme.
- Gestion des locataires : la gestion de centaines de milliers de locataires peut s'avérer 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 garantit une isolation stricte entre les instances de conteneur, qu'elles appartiennent au même service ou à des services différents 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 la sécurité.
- Mises à jour de sécurité : les mises à jour de sécurité automatiques des images de base peuvent être activées afin de maintenir à jour et de corriger le système d'exploitation et l'environnement d'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 placer les conteneurs dans un bac à sable, il fournit également une pile réseau mutualisée.
- Identité de service : les charges de travail Cloud Run peuvent être configurées pour disposer d'identités dédiées avec des autorisations restreintes.
Rentabilité
- Scaling à zéro instance et paiement à l'utilisation : les instances Cloud Run effectuent automatiquement un scaling à zéro instance lorsqu'elles ne sont pas utilisées, ce qui garantit que les charges de travail hébergées ne sont facturées que lorsqu'elles doivent s'exécuter. Cela permet une utilisation très efficace des ressources par rapport aux architectures exploitant des machines virtuelles "toujours actives".
- Facturation par requête : en plus de la réduction à 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 de réduire encore plus les coûts.
- À la demande et démarrage rapide : lorsqu'ils sont réduits, les services Cloud Run peuvent rapidement effectuer un scaling à la hausse, ce qui entraîne une faible latence perçue par l'utilisateur final de l'application déployée.
- Étiquetage automatisé des coûts : tous les coûts signalés par Cloud Run sont étiqueté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 des 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 de gérer les 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 l'équipe chargée de votre compte pour l'informer que vous agissez en tant que compte revendeur.Google Cloud peut collaborer avec vous pour s'assurer que des canaux de communication appropriés sont mis en place pour limiter les abus.
Vous devez utiliser des dossiers pour organiser vos projets Google Cloud . En particulier, il est essentiel de placer dans des dossiers différents les projets exécutant votre code propriétaire et les projets exécutant du 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 s'accompagne de 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 doit accéder à plusieurs ressourcesGoogle Cloud , telles que plusieurs services Cloud Run ou un bucket Cloud Storage, vous pouvez utiliser le projet comme périmètre sécurisé.
- Moins limité :
- 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 et peut être augmenté. Il n'y a pas de limite à ce nombre pour une organisation Google Cloud . Il existe une limite souple de 100 000 projets par compte de facturation, qui peut être multipliée en contactant Google. Votre organisation peut également créer de nombreux comptes de facturation et les regrouper dans un "groupe de comptes" (actuellement en version preview privée).
- Surveillance et gestion simplifiées :
- L'utilisation d'un projet par locataire facilite les processus de suppression des données, où la suppression des données d'un locataire se résume à la suppression du projet correspondant.
- Google Cloud Monitoring et Logging fonctionnent sur plusieurs projets et vous permettent 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é, en alignant potentiellement 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 processeur/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 si nécessaire.
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 applique 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 projets Google Cloud , ce qui augmentera globalement la complexité de la gestion des locataires. Du 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 d'être plus prudent en matière de sécurité. Par exemple, en utilisant des comptes de service dédiés et des autorisations précises.
Déployer dans plusieurs régions
Pour des raisons de fiabilité et d'évolutivité, Google recommande de répartir les déploiements de locataires sur plusieurs régionsGoogle Cloud . Chaque application de locataire est déployée dans une seule région, mais vous pouvez utiliser différentes régions pour différents locataires. La sélection de la région peut être aléatoire ou prendre en compte l'emplacement du locataire pour optimiser la latence.
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 global avec Service Extensions 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 de manière intégrée au traitement des requêtes) ou en tant que callouts (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 exploitant Cloud CDN et une protection supplémentaire contre les attaques par déni de service distribué (DDoS) à votre plate-forme à l'aide de Cloud Armor.
Réputation et abus
Toute plate-forme d'hébergement autorisée à exécuter du code non fiable est susceptible d'être utilisée de manière abusive.
Nous vous recommandons d'utiliser un compte de facturation Cloud différent pour chaque niveau de réputation que vous proposez. Par exemple, vos locataires du niveau sans frais ne doivent pas être associés au même compte de facturation que vos clients payants. Google peut considérer ces comptes de facturation comme ayant des niveaux de réputation différents.
Comme décrit dans Organiser vos projets Google Cloud , en plus de séparer les comptes de facturation, vous devez utiliser des dossiers pour organiser les projets. 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 consigner les événements de détection d'abus dans Cloud Logging, sur lesquels vous pouvez ensuite agir.