Architecture stratégique d’Azure Data Factory
Cet article décrit comment fournir une solution analytique avancée stratégique avec Azure Data Factory. Cette architecture est une extension de l’architecture de référence et de l’architecture renforcée de l’entreprise. Cet article fournit des conseils spécifiques sur les changements recommandés pour gérer une charge de travail en tant qu’opération stratégique.
Cette architecture s’aligne sur les bonnes pratiques de Cloud Adoption Framework pour Azure et les instructions et recommandations relatives aux charges de travail stratégiques.
Créer une architecture stratégique
Dans l’architecture de référence, Contoso exploite un médaillon lakehouse qui prend en charge leurs premières charges de travail de données pour le département financier. Contoso renforce et étend ce système pour répondre aux besoins de l’entreprise en matière de données analytiques. Cette stratégie fournit des fonctionnalités de science des données et des fonctionnalités en libre-service.
Dans l’architecture renforcée de l’entreprise, Contoso a implémenté une architecture de médaillon lakehouse qui prend en charge leurs besoins en données analytiques d’entreprise et permet aux utilisateurs professionnels d’utiliser un modèle de domaine. Alors que Contoso poursuit son expansion mondiale, le département financier a utilisé Azure Machine Learning pour créer un modèle de fraude aux transactions. Ce modèle doit maintenant être affiné pour fonctionner comme un service opérationnel stratégique.
Conditions clés
Plusieurs conditions essentielles sont requises pour fournir une solution analytique avancée stratégique à l’aide de Data Factory :
Le modèle de machine learning doit être conçu comme un service opérationnel stratégique, disponible à l’échelle mondiale pour les différents systèmes opérationnels de transaction.
Les résultats du modèle de machine learning et les métriques de performance doivent être disponibles pour le réentraînement et l’audit.
Les pistes d’audit du modèle de machine learning doivent être conservées pendant 10 ans.
Le modèle de machine learning cible actuellement les États-Unis, l’Europe et l’Amérique du Sud, avec des plans d’expansion en Asie à l’avenir. La solution doit respecter les exigences en matière de conformité des données, notamment le règlement général sur la protection des données pour les pays ou les régions d’Europe.
Le modèle de machine learning devrait prendre en charge jusqu’à 1 000 utilisateurs simultanés dans une région donnée pendant les heures de pointe. Pour réduire les coûts, le traitement de machine Learning doit être réduit lorsqu’il n’est pas utilisé.
Choix de conception clés
Une exigence ne justifie pas le coût et la complexité liés à la refonte de la plateforme pour répondre à des spécifications stratégiques. Le modèle de machine learning doit plutôt être conteneurisé, puis déployé dans une solution stratégique. Cette approche réduit les coûts et la complexité en isolant le service de modèle et en respectant les instructions stratégiques. Cette conception requiert le développement du modèle sur la plateforme, puis sa mise en conteneur pour le déploiement.
Une fois le modèle conteneurisé, il peut être délivré via une API à l’aide d’une architecture d’unité d’échelle dans les régions Azure américaines, européennes et sud-américaines. Seules les régions jumelées qui ont des zones de disponibilité sont incluses dans le champ d’application, ce qui répond aux exigences de redondance.
En raison de la simplicité d’un seul service d’API, nous vous recommandons d’utiliser la fonctionnalité web app pour conteneurs pour héberger l’application. Cette fonctionnalité simplifie les choses. Vous pouvez également utiliser Azure Kubernetes Service (AKS), qui offre plus de contrôle, mais augmente la complexité.
Le modèle est déployé via une infrastructure MLOps. Data Factory est utilisé pour déplacer des données dans et hors de l’implémentation stratégique.
Pour effectuer la conteneurisation, vous avez besoin des éléments suivants :
Une API frontal pour traiter les résultats du modèle.
Décharger les métriques d’audit et de performances vers un compte de stockage, qui peuvent ensuite être transférées vers la plateforme principale via Data Factory au moyen d’une tâche planifiée.
Les pipelines de déploiement et de retour en arrière, qui permettent à chaque déploiement régional de se synchroniser avec la version actuelle correcte du modèle.
Modélisation de l’intégrité du service pour mesurer et gérer l’intégrité globale d’une charge de travail.
Les pistes d’audit peuvent être initialement stockées dans un espace de travail Log Analytics pour une analyse en temps réel et un support opérationnel. Après 30 jours, ou 90 jours si vous utilisez Microsoft Sentinel, les pistes d’audit peuvent être automatiquement transférées vers Azure Data Explorer pour une conservation à long terme. Cette approche permet des requêtes interactives allant jusqu’à deux ans au sein de l’espace de travail Log Analytics et de conserver les données plus anciennes et peu utilisées à un coût réduit pendant une période pouvant aller jusqu’à 12 ans. Utilisez Azure Data Explorer pour votre stockage de données pour exécuter des requêtes multiplateformes et visualiser des données à la fois sur Azure Data Explorer et sur Microsoft Sentinel. Cette approche constitue une solution rentable pour répondre aux exigences de stockage à long terme tout en conservant la prise en charge facultative. S’il n’est pas nécessaire de conserver une quantité de données excessive, vous devriez envisager de les supprimer.
Architecture
Flux de travail
Le workflow suivant correspond au diagramme précédent :
Le modèle de machine learning est développé sur la plateforme de données. Cette modification de conception nécessite les mises à jour suivantes de l’architecture :
Azure Container Registry permet de créer, de stocker et de gérer des images et des artefacts de conteneurs Docker dans un registre privé qui prend en charge le déploiement de modèles de machine learning.
La fonctionnalité web app pour conteneurs permet les activités d’intégration et de déploiement continus qui sont nécessaires pour fournir les résultats du modèle de machine learning sous la forme d’un service API.
Data Factory permet de migrer toutes les données nécessaires au fonctionnement du modèle et d’ingérer les données de sortie et les métriques de performance du modèle à partir de l’implémentation stratégique.
La structure de répertoires de la couche bronze du lac de données (ou la couche brute) stocke les métriques de sortie et de performances du modèle à l’aide du niveau archive pour répondre aux exigences de conservation des données.
Azure DevOps orchestre le déploiement du code de base du modèle ainsi que la création et le retrait des déploiements régionaux pour tous les services de support.
Le modèle de machine learning est déployé en tant que charge de travail stratégique dédiée au sein de son propre abonnement défini. Cette approche garantit que le modèle évite les limites de composants ou de services que la plateforme pourrait imposer.
Un ensemble de ressources partagées couvre l’ensemble de la solution et est donc défini comme global :
Container Registry permet la distribution de la version actuelle du modèle de machine learning dans tous les déploiements régionaux.
Azure Front Door fournit des services d’équilibrage de charge pour distribuer le trafic dans tous les déploiements régionaux.
Une fonctionnalité de surveillance utilise Log Analytics et Azure Data Lake Storage.
L’empreinte de déploiement régionale est un ensemble de composants de solution que vous pouvez déployer dans n’importe quelle région cible. Cette approche assure la mise à l’échelle, la résilience du service et un service spécifique à la région.
Selon la nature du modèle de machine learning, certaines exigences régionales en matière de conformité des données peuvent imposer au modèle de machine learning d’adhérer à des règles de souveraineté. Cette conception prend en charge ces exigences.
Chaque déploiement régional est fourni avec sa propre pile de surveillance et de stockage, qui fournit une isolation du reste de la solution.
L’unité d’échelle de la solution comporte les composants suivants :
La fonctionnalité web app pour conteneurs héberge le modèle de machine learning et sert ses sorties. En tant que composant de service principal dans cette solution, vous devez considérer les limites d’échelle pour Web App pour conteneurs comme des contraintes clés. Si ces limites ne sont pas compatibles avec les exigences de la solution, il faut envisager d’utiliser AKS à la place.
Azure Key Vault applique les contrôles appropriés aux secrets, aux certificats et aux clés à l’échelle régionale, sécurisés par Azure Private Link.
Data Lake Storage fournit un stockage de données sécurisé via Private Link.
Azure DNS fournit une résolution de noms qui assure la résilience du service et simplifie l’équilibrage des charges dans la solution.
Pour faciliter la prise en charge et la résolution des problèmes de la solution, les composants suivants sont également inclus :
Azure Bastion fournit une connexion sécurisée aux hôtes de saut sans nécessiter une adresse IP publique.
Les machines virtuelles Azure agissent comme des hôtes de sauts pour la solution, ce qui permet une meilleure posture de sécurité.
Les agents de build auto-hébergés fournissent une mise à l’échelle et des performances pour prendre en charge les déploiements de solutions.
Conception du réseau
Téléchargez un fichier Visio de cette architecture.
Vous devriez utiliser un pare-feu de nouvelle génération comme le Pare-feu Azure pour sécuriser la connectivité du réseau entre votre infrastructure locale et votre réseau virtuel Azure.
Vous pouvez déployer un runtime d’intégration auto-hébergé (SHIR) sur une machine virtuelle dans votre environnement local ou dans Azure. Pour simplifier la gouvernance et la sécurité, envisagez de déployer la machine virtuelle dans Azure dans le cadre de la zone d’atterrissage des ressources de prise en charge partagée. Vous pouvez utiliser le SHIR pour vous connecter en toute sécurité à des sources de données locales et effectuer des tâches d’intégration de données dans Data Factory.
L’étiquetage des données assisté par le machine learning ne prend pas en charge les comptes de stockage par défaut, car ils sont sécurisés derrière un réseau virtuel. Commencez par créer un compte de stockage pour l’étiquetage des données assistées par le machine learning. Appliquez ensuite l’étiquetage et sécurisez-le derrière le réseau virtuel.
Les points de terminaison privés fournissent une adresse IP privée à partir de votre réseau virtuel à un service Azure. Ce processus place concrètement le service dans votre réseau virtuel. Cette fonctionnalité rend le service accessible uniquement à partir de votre réseau virtuel ou de réseaux connectés, ce qui garantit une connexion plus sécurisée et privée. Les points de terminaison privés utilisent Private Link, qui sécurise la connexion à la solution PaaS (Platform as a Service). Si votre charge de travail utilise des ressources qui ne prennent pas en charge les points de terminaison privés, vous pouvez peut-être utiliser des points de terminaison de service. Nous vous recommandons d’utiliser, dans la mesure du possible, des points de terminaison privés pour les charges de travail stratégiques.
Pour en savoir plus, consultez Mise en réseau et connectivité.
Important
Déterminez si votre cas d’usage est opérationnel, comme ce scénario, ou s’il est lié à la plateforme de données. Si votre cas d’usage inclut la plateforme de données, notamment la science des données ou l’analytique, elle peut ne pas être considérée comme stratégique. Les charges de travail critiques nécessitent des ressources importantes et devraient uniquement être définies comme telles si elles justifient l’investissement en ressources.
Autres solutions
Vous pouvez utiliser AKS pour héberger les conteneurs. Pour ce cas d’usage, la charge de gestion requise pour AKS en fait une option moins idéale.
Vous pouvez utiliser Azure Container Apps au lieu de la fonctionnalité Web Apps pour conteneurs. Les points de terminaison privés ne sont actuellement pas pris en charge pour Container Apps, mais le service peut être intégré à un réseau virtuel existant ou nouveau.
Vous pouvez utiliser Azure Traffic Manager comme solution de rechange pour l’équilibrage de charge. Azure Front Door est préféré pour ce scénario en raison des fonctionnalités supplémentaires disponibles et d’une performance de basculement plus rapide.
Si le modèle nécessite des fonctionnalités de lecture et d’écriture dans le cadre de son traitement des données, envisagez d’utiliser Azure Cosmos DB.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.
Par rapport à l’architecture de base de référence, cette architecture :
S’aligne sur l’architecture de référence stratégique.
Respecte les orientations énoncées dans les considérations stratégiques relatives à la conception de la fiabilité.
Déploie un modèle d’intégrité initial pour la solution afin d’optimiser la fiabilité.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.
Par rapport à l’architecture de base de référence, cette architecture :
Respecte les orientations énoncées dans les considérations stratégiques relatives à la conception de la sécurité.
Implémente les conseils en matière de sécurité définis dans l’architecture de référence stratégique.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.
Les conceptions stratégiques sont coûteuses, ce qui rend la mise en œuvre des contrôles importants. Les contrôles sont notamment les suivants :
Alignement de la sélection de la référence SKU du composant sur les limites de l’unité d’échelle de la solution afin d’éviter le surapprovisionnement.
Avantages disponibles et pratiques en matière de réduction des dépenses d’exploitation, tels que les réservations Azure pour les charges de travail stables, les plans d’économies pour les charges de travail dynamiques et les niveaux d’engagement Log Analytics.
Alertes de coût et de budget via Microsoft Cost Management.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.
Par rapport à l’architecture de base de référence, cette architecture :
Respecte les instructions des considérations stratégiques relatives à la conception de l’excellence opérationnelle.
Sépare les ressources de surveillance globales et régionales pour empêcher un point de défaillance unique dans l’observabilité.
Implémente les instructions de déploiement et de test et les procédures opérationnelles à partir de l’architecture de référence stratégique.
Aligne la solution avec les feuilles de route d’ingénierie Azure et les déploiements régionaux pour tenir compte des services en constante évolution dans Azure.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à répondre aux demandes qu’elle impose aux utilisateurs de manière efficace. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances
Par rapport à l’architecture de base de référence, cette architecture :
Respecte les instructions définis dans les considérations stratégiques relatives à la conception de l’efficacité des performances.
Termine une évaluation Well-Architected pour les charges de travail stratégiques afin de fournir une base de référence de préparation pour la solution. Révisez régulièrement cette évaluation dans le cadre d’un cycle proactif de mesures et de gestion.
Antimodèles
L’approche de la liste d’achats : les parties prenantes de l’entreprise sont souvent présentées avec une liste d’achats de fonctionnalités et de niveaux de service, sans contexte de coût ou de complexité. Il est important de s’assurer que toutes les solutions sont basées sur des exigences validées et que la conception de la solution s’appuie sur une modélisation financière avec des options. Cette approche permet aux parties prenantes de prendre des décisions éclairées et de changer de cap si nécessaire.
Sans remise en question des exigences : les conceptions stratégiques peuvent être coûteuses et complexes à mettre en œuvre et à entretenir. Les parties prenantes doivent être interrogées sur leurs exigences pour s’assurer que la conception « stratégique » est vraiment nécessaire.
Déployer et oublier : le modèle est déployé sans surveillance, mise à jour ou mécanismes de support continus. Une fois le modèle déployé, il ne nécessite que peu ou pas de maintenance permanente et peut fonctionner de manière isolée. Cette négligence peut entraîner une dégradation des performances, une dérive de la précision du modèle et une vulnérabilité aux nouveaux modèles de données. En fin de compte, la négligence nuit à la fiabilité et à l’efficacité du modèle dans l’accomplissement de sa mission.