Projets SageMaker Unified Studio
SageMaker Unified Studio (SMUS) révolutionne la gestion de l'infrastructure des données et de l'IA en regroupant les environnements au sein de Profils de Projet cohérents. Cet article explore l'évolution architecturale depuis DataZone v1 et détaille le cycle de vie d'un projet SMUS, de sa configuration à son déploiement.
1. Différences Architecturales : DataZone v1 vs. SageMaker Unified Studio (SMUS)
Pour comprendre l'évolution architecturale de SageMaker Unified Studio (SMUS), nous devons examiner comment sa couche fondamentale de gouvernance des données—Amazon DataZone—structurait initialement ses environnements et les limites de ses projets.
Architecture des Environnements Amazon DataZone (v1)
Dans DataZone v1, chaque projet offrait des capacités fondamentales par défaut (telles que des bases de données Lakehouse, Amazon Redshift ou des ressources d'IA) et était étroitement lié à un ou plusieurs environnements.
- La Couche Environnement : Un environnement représente un espace de travail AWS cible défini par un compte AWS spécifique et une région. Le déploiement d'un environnement provisionne automatiquement les ressources requises. Par exemple, un blueprint standard de base de données Lakehouse provisionne à la fois une base de données de publication et une base de données de souscription, tout en automatisant les autorisations et le partage des ressources au sein de cet espace de travail.
- Flexibilité de l'Espace de Travail : Un projet DataZone unique peut héberger plusieurs environnements répartis sur des comptes AWS distincts. Bien que la prise en charge multi-régions ait été récemment introduite, la région d'exécution était historiquement contrainte par la région du domaine principal DataZone.
- Mécanisme de Configuration : Cette architecture s'appuie sur un Profil d'Environnement pour gérer les configurations des espaces de travail cibles et les attributions de souscriptions. Par conséquent, un projet contient souvent plusieurs profils d'environnement distincts pour gérer ses différents déploiements.
L'Évolution vers SMUS
SageMaker Unified Studio transforme fondamentalement ce paradigme en abstrayant la couche d'infrastructure une étape plus loin, remplaçant les profils d'environnement individuels par un concept unifié appelé Profil de Projet (Project Profile).
| Dimension Architecturale | Amazon DataZone (v1) | SageMaker Unified Studio (v2) |
|---|---|---|
| Cartographie des Profils | Multiplicité de Profils d'Environnement par projet. | Un et un seul Profil de Projet par projet. |
| Limites de l'Environnement | Liées à la configuration d'un seul espace de travail/compte. | Représentent des capacités déployées sur plusieurs espaces de travail. |
| Agrégation des Capacités | Codées en dur ou limitées par le blueprint d'environnement sélectionné. | S'étendent sur plusieurs comptes AWS et régions distincts au sein d'un seul profil. |
2. Description des Concepts : Projets et Profils de Projet
Un Profil de Projet sert de modèle centralisé pour définir les espaces de travail, les limites de gouvernance et les capacités architecturales qu'une équipe peut provisionner. Au lieu de configurer des profils d'environnement séparés sur plusieurs comptes, les administrateurs utilisent le Profil de Projet pour établir des paramètres globaux depuis une interface de configuration unique.
Découplage des Configurations et Paramètres Différés
Les Profils de Projet permettent aux administrateurs de définir des architectures par défaut tout en laissant variables certains paramètres environnementaux spécifiques. Les configurations de haut niveau de l'espace de travail, les régions cibles et les limites spécifiques des ressources peuvent être différées jusqu'au moment de la création du projet. Cette approche permet de créer des profils génériques hautement réutilisables qui s'adaptent dynamiquement aux différents cas d'usage selon les choix des utilisateurs.
Contrôles de Sécurité et de Gouvernance
Pour faire respecter la conformité et les garde-fous de l'infrastructure, le Profil de Projet agit comme une stricte couche de gouvernance. Les administrateurs peuvent marquer les paramètres de configuration sensibles comme non-modifiables (non-editable). Cela verrouille les variables contrôlées (telles que des groupes de sécurité spécifiques, des clés KMS ou des limites IAM) tout en laissant les paramètres opérationnels ouverts à la saisie par le développeur lors du provisionnement ou des mises à jour du projet.
Dans SMUS, la définition d'un Projet change significativement : ce n'est plus une définition d'environnement unique clonée sur plusieurs comptes. Au lieu de cela, un projet SMUS représente un écosystème agrégé de capacités, de configurations et d'outils définis qui s'étendent sur plusieurs espaces de travail AWS, mais qui sont déployés et gérés comme une seule unité cohérente.
3. Analyse Détaillée : Cycle de Vie du Projet et Mécaniques de Provisionnement
Comprendre comment ces couches d'abstraction interagissent nécessite une plongée approfondie dans le cycle de vie pratique (Création, Lecture, Mise à jour, Suppression - CRUD) d'un projet SMUS. La flexibilité de l'infrastructure est obtenue en empilant des blueprints CloudFormation sous la couche du Profil de Projet.
Phase 1 : Configuration du Profil de Projet
Avant qu'un utilisateur puisse déployer un projet, un administrateur doit créer et activer un Profil de Projet. Ce profil cartographie exactement les blueprints CloudFormation (CFN) sous-jacents qui sont disponibles.
Pour cette démonstration, nous examinerons un cas d'usage standard comprenant un blueprint de base de données de data lake géré par AWS, combiné à un blueprint de démonstration personnalisé.
Lors de la configuration des comptes cibles et des régions dans le profil, l'interface filtre la liste des comptes disponibles pour n'afficher que les domaines externes explicitement associés au domaine racine. Les déploiements multi-comptes requièrent cette association de domaine comme prérequis strict.
Le profil dicte également les configurations de stockage sous-jacentes (telles que les compartiments Amazon S3 dédiés) et les limites d'autorisation des utilisateurs, appliquant une couche de gouvernance localisée directement au profil lui-même.
Une fois configuré, le statut d'activation initial du profil peut être défini directement depuis l'assistant de création.
Après validation, le Profil de Projet actif affiche explicitement ses régions associées, ainsi que les blueprints assignés et leurs paramètres correspondants pour chaque zone de déploiement cible.
Les administrateurs peuvent effectuer des mises à jour structurelles sur le profil après sa création. Cela inclut la modification de la distribution régionale, le changement des comptes AWS cibles ou la modification de l'ordre de déploiement des blueprints sous-jacents.
Les paramètres spécifiques exposés par les blueprints intégrés peuvent également être reconfigurés ou verrouillés depuis l'interface d'édition du profil.
Phase 2 : Flux de Création et de Provisionnement du Projet
Avec un Profil de Projet actif en place, les utilisateurs peuvent initier le provisionnement d'un projet directement depuis le portail du domaine SMUS.
Le formulaire de création initial demande à l'utilisateur un nom de projet, une description facultative et un Profil de Projet cible. Le profil personnalisé créé à l'étape précédente apparaît comme une base sélectionnable.
Lors de la sélection du profil, le système génère un formulaire dynamique exigeant que l'utilisateur fournisse des valeurs pour toute variable vide ou écrase les paramètres par défaut du blueprint lorsque cela est autorisé.
Note sur la Visibilité : Si les paramètres d'un blueprint personnalisé n'apparaissent pas sur ce formulaire de création, c'est généralement parce qu'ils ont été explicitement cachés ou désactivés lors de la phase de configuration du Profil de Projet. Ils doivent être configurés comme modifiables (editable) dans le profil pour devenir visibles pour l'utilisateur final.
Une fois que l'utilisateur valide la configuration, le moteur d'orchestration de SMUS déclenche la séquence de déploiement. Le moteur initialise toujours l'environnement en provisionnant le blueprint d'outillage central (tooling blueprint - la pile d'infrastructure de base) avant de tenter d'y ajouter des fonctionnalités supplémentaires.
Une fois la pile d'outils de base déployée, les blueprints de capacités secondaires définis dans le profil sont déployés de manière séquentielle sur leurs espaces de travail cibles respectifs (comptes et régions).
Cette orchestration prend plusieurs minutes pour s'achever. Au minimum, un projet de base avec une seule capacité provisionnera deux piles CloudFormation distinctes : une pour l'outillage et une pour la capacité. Lors de la conception à grande échelle, vous devez prendre en compte ce multiplicateur de plus de 2 piles dans vos limites régionales de piles AWS CloudFormation.
Dès le déploiement réussi, le portail redirige vers le tableau de bord de vue d'ensemble du projet, fournissant un accès immédiat à la gestion des membres, aux catalogues d'actifs de données et aux espaces de travail analytiques partagés.
Phase 3 : Mutation du Projet & Mécanisme de Mise à Jour
Les projets SMUS sont mutables ; vous pouvez mettre à jour les métadonnées, ajuster les paramètres d'exécution et mettre à niveau les définitions de blueprints personnalisés. Cependant, la mutation des capacités nécessite de comprendre comment SMUS distingue les blueprints gérés des blueprints personnalisés :
- Blueprints gérés par AWS : Ces modèles sont immuables pour l'utilisateur final. Les mises à jour structurelles sont gérées directement par AWS, bien que les utilisateurs puissent modifier les paramètres exposés si le Profil de Projet le permet.
- Blueprints personnalisés : Ils sont entièrement configurables. Les structures centrales, les déclarations de ressources et les paramètres d'entrée peuvent être mis à jour directement au niveau de la définition du blueprint.
SMUS utilise un hook d'événement intégré pour détecter lorsqu'un projet s'écarte de ses définitions sous-jacentes. Le moteur écoute activement les modifications apportées soit au modèle de blueprint global, soit au Profil de Projet parent. Lorsqu'une dérive ou une mise à niveau de version est détectée, une bannière de notification apparaît en haut du tableau de bord du projet, accompagnée d'un bouton d'action explicite Update (Mettre à jour).
Cliquer sur le bouton de mise à jour ouvre un formulaire d'examen des paramètres, permettant aux utilisateurs de modifier les entrées ou de s'adapter aux nouvelles exigences du modèle avant d'appliquer les changements.
Une fois confirmée, SMUS exécute des mises à jour delta, ciblant uniquement les piles CloudFormation affectées par la modification.
Mises à Jour Pilotées par le Système : Étant donné qu'AWS met régulièrement à jour les blueprints gérés sous-jacents (y compris le blueprint d'outillage fondamental), une notification de mise à jour de projet peut apparaître même si vous n'avez apporté aucune modification locale. Cela indique qu'un correctif au niveau de la plateforme est disponible pour aligner vos piles de base sur la dernière version.
Une fois la mise à jour des piles terminée, le projet revient à un état actif et à jour sur le tableau de bord.
Phase 4 : Suppression & Conservation des Ressources
Pour démanteler un projet SMUS en toute sécurité, les bonnes pratiques imposent de nettoyer les dépendances externes—y compris les abonnements de données actifs, les listages publics d'actifs et les permissions de catalogue partagées—avant d'exécuter la commande de suppression.
La séquence de démantèlement reflète le processus de création en sens inverse : SMUS déprovisionne les piles de capacités une par une avant de détruire la pile d'outillage racine.
Avertissement Critique : Les magasins de données persistants sous-jacents, tels que les compartiments physiques Amazon S3 ou les bases de données AWS Glue/Redshift, appliquent fréquemment une politique de suppression
Retain(Conserver). SMUS détruit les piles d'orchestration logiques, mais les ressources de données physiques restent souvent intactes dans le compte cible. Vous devez tenir compte de ces ressources orphelines lors du nettoyage post-suppression.
4. Considérations Opérationnelles & Pièges à l'Échelle
Parce que SMUS coordonne l'infrastructure sur plusieurs services, maintenir une bonne visibilité exige une compréhension de ses dépendances sous-jacentes et des contraintes de la plateforme.
Le Maillage d'Infrastructure Sous-jacent
SMUS ne fonctionne pas de manière isolée ; il agit comme un orchestrateur à travers plusieurs services AWS de base :
- AWS CloudFormation (CFN) : Gère le provisionnement des ressources physiques.
- AWS Lake Formation (LF) : Gère les politiques d'accès aux données et les métadonnées de sécurité.
- AWS Resource Access Manager (RAM) : Pilote le partage inter-comptes et inter-régions.
- Services de Données/IA Complémentaires : Glue, Redshift, Amazon SageMaker et Amazon VPC.
Lors du déploiement de capacités personnalisées à l'échelle de l'entreprise, vous devez suivre activement les limites de ressources (soft et hard) sur tous les services intégrés. Soyez attentif aux capacités régionales des VPC/sous-réseaux, aux quotas de rôles IAM par compte, aux limites de piles CloudFormation simultanées et aux plafonds d'administrateurs Lake Formation.
Chaque nouveau projet étend automatiquement votre empreinte dans tous ces domaines :
- AWS CloudFormation (Min. 2 Piles par Projet/Capacité)
- Rôles IAM (Exécution, Outillage et Limites des Capacités)
- AWS Lake Formation (Permissions, Allocations, Inscriptions d'Admin)
- AWS RAM (Partages Inter-Comptes & Liens de Ressources Inter-Régions)
- Groupes de Sécurité Amazon VPC (Accès Privé & Inter-Régions)
- Points de Terminaison Données/IA (Catalogues Glue, Clusters Redshift, Instances SageMaker)
Isolation des Accès & Lake Formation v5
AWS recommande d'aligner votre domaine avec AWS Lake Formation v5, qui contient les contrôles d'accès les plus granulaires (utilisant des expressions régulières) et un groupe logique unifié pour les partages AWS RAM. Il est crucial de définir cela avant de passer à l'échelle pour éviter d'avoir plusieurs versions de souscriptions sur le même domaine.
Un inventaire des ressources gérées ou provisionnées via SMUS doit être maintenu pour répondre à deux points :
- Nettoyage sécurisé des projets.
- S'assurer que les services interagissant ne présentent pas d'erreurs d'intégration.
Responsabilité Partagée et Flexibilité
SMUS offre une large couche de personnalisation. Les paramètres du projet sont modifiables à trois niveaux distincts :
- Blueprint (si personnalisé)
- Profil de Projet
- Création / Mise à jour du Projet
Cette architecture laisse les choix ouverts. Si un blueprint géré est choisi, les administrateurs peuvent contraindre les paramètres administratifs au niveau du profil tout en laissant les paramètres opérationnels modifiables par l'utilisateur.
Cependant, cela signifie que vous êtes entièrement responsable de la conception d'une structure sûre et évolutive. Par exemple, vous devez être conscient de l'unicité des rôles cibles de souscription par projet sur SMUS. Le service restreint naturellement l'accès par projet et s'appuie sur des mécanismes de partage de domaine pour fournir un accès supplémentaire. Ceci est gérable en dehors de l'écosystème SMUS puisque vous pouvez manipuler directement les services de gouvernance sous-jacents (IAM, LF, RAM). C'est puissant mais cela nécessite des connaissances approfondies pour concevoir une architecture correcte.
Le Piège des Paramètres de Blueprints Personnalisés
Une autre considération majeure concerne les blueprints personnalisés. Lors de la sélection d'une pile de blueprints, SMUS ne compile ni ne valide entièrement la pile CFN—ce qui signifie qu'il ne vérifiera pas strictement si la pile CFN est structurellement valide pour une mise à jour.
Envisagez de pousser le modèle standard ci-dessous via un blueprint personnalisé, pour une mise à jour qui n'ajoute que le paramètre "test2" au modèle.
Exemple CFN de Blueprint
Sur CloudFormation natif, vous ne pouvez pas mettre à jour une pile si le seul changement est un nouveau paramètre dans la section des paramètres (l'API CloudFormation refuse la pile, signalant une utilisation invalide).
Cependant, si cette même mise à jour (uniquement de paramètre) est transmise à SMUS, elle ne générera aucune erreur sur les pages de destination ou dans l'interface utilisateur du domaine. Vous pourrez même déclencher une mise à jour de projet.
La mise à jour sera signalée comme réussie sur SMUS, et vous verrez le nouveau paramètre reflété dans l'interface utilisateur.
Cependant, sur la pile CFN sous-jacente, aucune mise à jour n'est réellement déclenchée, et le paramètre répertorié sur l'interface utilisateur de SMUS ne sera pas ajouté à la pile.
Si vous vérifiez AWS CloudTrail, vous trouverez les appels API entrants de SMUS (deux fois) utilisant les permissions correctes, mais rejetés par l'API CloudFormation simplement parce que la modification manquait d'une modification de ressource valide.
À ce stade, les paramètres du blueprint à l'intérieur du projet SMUS sont désynchronisés par rapport à la pile CFN réellement déployée. L'ajout ou la modification d'une ressource physique dans le modèle résoudra cette disparité.
Pour cette raison, une bonne pratique fondamentale consiste à valider et à provisionner votre blueprint personnalisé comme un test directement sur CloudFormation avant de mettre à jour SMUS, en particulier lorsque vous travaillez à grande échelle ou que vous exécutez des mises à jour par lots.
Cadre de Débogage
Ce scénario est susceptible de se produire avec des services intégrés. Pour maintenir la visibilité :
- Utilisez les outils de développement de votre navigateur (onglet Réseau) sur l'interface du domaine pour déterminer les appels API exacts en cours d'utilisation.
- Utilisez AWS CloudTrail sur le compte de l'espace de travail pour comprendre exactement ce qui ne va pas lors de la création du projet ou des opérations principales.
- Ayez une compréhension approfondie d'AWS Lake Formation et d'AWS RAM pour gérer fluidement les souscriptions entre les comptes et les régions.
Ce modèle de responsabilité partagée rend SMUS incroyablement puissant pour presque toutes les architectures de données, à condition de l'aborder avec une compréhension approfondie des subtilités de ses API sous-jacentes.