Architecture de référence de référence de conversation Azure AI Foundry dans une zone d’atterrissage Azure
Cet article fait partie d’une série qui s’appuie sur l’architecture de référence de référence de conversation AI Foundry de référence. Passez en revue l’architecture de base afin de pouvoir identifier les ajustements nécessaires avant de le déployer dans un abonnement de zone d’atterrissage d’application Azure.
Cet article décrit une architecture de charge de travail IA générative qui déploie l’application de conversation de référence, mais utilise des ressources qui se trouvent en dehors de l’étendue de l’équipe de charge de travail. Les équipes de plateforme gèrent de manière centralisée les ressources et plusieurs équipes de charge de travail les utilisent. Les ressources partagées incluent des ressources réseau pour les connexions intersite, les systèmes de gestion des accès aux identités et les stratégies. Ces conseils aident les organisations qui utilisent des zones d’atterrissage Azure à maintenir une gouvernance cohérente et une efficacité des coûts.
Azure AI Foundry utilise des comptes et des projets pour organiser le développement et le déploiement d’IA. Par exemple, une implémentation de zone d’atterrissage peut utiliser un compte comme ressource centralisée au niveau d’un groupe d’entreprise et des projets en tant que ressource déléguée pour chaque charge de travail de ce groupe d’entreprise. En raison des facteurs de l’organisation des ressources et des limitations d’allocation des coûts, nous ne recommandons pas cette topologie, et cet article ne fournit pas de conseils sur celui-ci. Au lieu de cela, cette architecture traite la charge de travail comme propriétaire de l’instance Azure AI Foundry, qui est l’approche recommandée.
En tant que propriétaire de charge de travail, vous délèguez la gestion des ressources partagées aux équipes de plateforme afin de pouvoir vous concentrer sur les efforts de développement de charge de travail. Cet article présente la perspective de l’équipe de charge de travail et spécifie les recommandations pour l’équipe de plateforme.
Important
Qu’est-ce que les zones d’atterrissage Azure ?
Les zones d’atterrissage Azure divisent l’empreinte cloud de votre organisation en deux domaines clés :
Une zone d’atterrissage d’application est un abonnement Azure dans lequel une charge de travail s’exécute. Une zone d’atterrissage d’application se connecte aux ressources de plateforme partagée de votre organisation. Cette connexion fournit à la zone d’atterrissage un accès à l’infrastructure qui prend en charge la charge de travail, comme la mise en réseau, la gestion des accès aux identités, les stratégies et la surveillance.
Une zone d'atterrissage de plateforme est une collection de divers abonnements que plusieurs équipes de plateforme peuvent gérer. Chaque abonnement a une fonction spécifique. Par exemple, un abonnement de connectivité fournit une résolution DNS (Domain Name System) centralisée, une connectivité intersite et des appliances virtuelles réseau (NVA) pour les équipes de plateforme.
Pour vous aider à implémenter cette architecture, comprenez les zones d’atterrissage Azure, leurs principes de conception et leurs domaines de conception.
Disposition de l’article
| Architecture | Choix de conception | L’approche Azure Well-Architected Framework |
|---|---|---|
| ▪ Diagramme d’architecture ▪ Ressources de charge de travail ▪ Ressources fédérées |
▪ Paramétrage de l’abonnement ▪ Mise en réseau ▪ Accès pour les data scientists ▪ Surveiller les ressources ▪ Gouvernance organisationnelle ▪ Gestion des changements |
▪ Fiabilité ▪ Sécurité ▪ Optimisation des coûts ▪ Excellence opérationnelle ▪ Efficacité du niveau de performance |
Conseil / Astuce
L’implémentation de référence de référence de la base de référence du service Azure AI Foundry Agent illustre les meilleures pratiques décrites dans cet article. Passez en revue et essayez ces ressources de déploiement avant de choisir et d’implémenter vos décisions de conception.
Architecture
Téléchargez un fichier Visio de cette architecture.
Composants
Toutes les architectures de zone d’atterrissage Azure séparent la propriété entre l’équipe de plateforme et l’équipe de charge de travail, appelée démocratisation des abonnements. Les architectes d’applications, les scientifiques des données et les équipes DevOps doivent clairement comprendre cette division pour déterminer ce qui relève de leur influence directe ou de leur contrôle et de ce qui ne le fait pas.
Comme la plupart des implémentations de zone d’atterrissage d’application, l’équipe de charge de travail gère principalement la configuration, le déploiement et la supervision des composants de charge de travail, y compris les services IA dans cette architecture.
Ressources appartenant à l’équipe chargée de la charge de travail
Les ressources suivantes ne changent pratiquement pas par rapport à l’architecture de référence.
Les comptes et projets Azure AI Foundry permettent à l’équipe de charge de travail d’héberger des modèles IA génératifs en tant que service, d’implémenter la sécurité du contenu et d’établir des connexions spécifiques à la charge de travail aux sources et outils de connaissances.
Si le Centre d’excellence ia de votre organisation limite l’accès aux déploiements de modèles IA, l’équipe de charge de travail peut ne pas héberger de modèles dans des projets et des comptes. Au lieu de cela, ils peuvent avoir besoin d’utiliser des ressources IA centralisées. Dans ce scénario, toutes les consommations de modèles transitent généralement par une passerelle que votre équipe de plateforme IA fournit.
Cet article suppose que les modèles IA génératifs dans ce scénario sont des ressources appartenant à la charge de travail. Si ce n’est pas le cas, l’hôte de modèle ou une passerelle vers les modèles devient une dépendance de charge de travail. L’équipe de plateforme doit maintenir une connectivité réseau fiable aux API.
Le service De l’agent Foundry traite les dépendances de modèle d’une manière spécifique, de sorte que les défis peuvent se produire lorsque vous consommez des modèles hébergés de manière centralisée. Vous devrez peut-être utiliser un autre orchestrateur.
Le service De l’agent Foundry fournit la couche d’orchestration pour les interactions de conversation. Il héberge et gère l’agent de conversation qui traite les demandes utilisateur.
Utilisez la configuration de l’agent standard dans cette architecture. Connectez votre agent à un sous-réseau dédié dans votre réseau virtuel spoke et routez le trafic de sortie via votre abonnement de connectivité.
L’équipe de charge de travail fournit des ressources Azure dédiées pour l’état de l’agent, l’historique des conversations et le stockage de fichiers. Ces ressources sont Azure Cosmos DB pour NoSQL, Stockage Azure et Recherche d’IA Azure. Votre instance du service De l’agent Foundry gère ces ressources et leurs données exclusivement. Les autres composants d’application de votre charge de travail ou d’autres charges de travail de votre organisation ne doivent pas les utiliser.
Azure App Service héberge l’application web qui contient l’interface utilisateur de conversation. App Service a trois instances dans différentes zones Azure.
Un compte de stockage Azure héberge le code de l’application web en tant que fichier ZIP, qui se monte dans App Service.
Ai Search récupère les données indexées pertinentes pour les requêtes utilisateur d’application. La recherche IA sert de magasin de connaissances de charge de travail pour le modèle de génération augmentée de récupération. Ce modèle extrait une requête appropriée à partir d’une invite, interroge ai Search et utilise les résultats comme données de base pour un modèle de base d’IA générative.
Azure Application Gateway sert de proxy inverse pour acheminer les demandes des utilisateurs vers l’interface utilisateur de conversation hébergée dans App Service. La référence SKU sélectionnée héberge également un pare-feu d’applications web Azure pour protéger l’application frontale contre le trafic potentiellement malveillant.
Azure Key Vault stocke le certificat TLS (Transport Layer Security) de la passerelle d’application.
Azure Monitor, les journaux Azure Monitor et Application Insights collectent, stockent et visualisent les données d’observabilité.
Azure Policy applique des stratégies spécifiques à la charge de travail pour aider à régir, sécuriser et appliquer des contrôles à grande échelle.
L’équipe de charge de travail gère également les ressources suivantes :
Les sous-réseaux de réseau virtuel spoke et les groupes de sécurité réseau (NSG) sur ces sous-réseaux gèrent la segmentation et contrôlent le flux de trafic.
Les points de terminaison privés sécurisent la connectivité aux solutions PaaS (Platform as a Service).
Les ressources de la plate-forme appartenant à l’équipe
L’équipe de plateforme possède et gère les ressources centralisées suivantes. Cette architecture suppose que ces ressources sont préprovisionnées et qu’elles sont traitées comme des dépendances.
Pare-feu Azure dans les itinéraires réseau hub , inspecte et restreint le trafic de sortie provenant de la charge de travail, y compris le trafic de l’agent. Le trafic sortant de la charge de travail va vers l'internet, des destinations entre différents locaux ou vers d'autres zones d'atterrissage d'application.
Changez de la base de référence : Dans l’architecture de base, l’équipe de charge de travail possède ce composant. Dans cette architecture, l’équipe de plateforme la gère sous l’abonnement de connectivité.
Azure Bastion dans le réseau hub fournit un accès opérationnel sécurisé aux composants de charge de travail et autorise l’accès aux composants Azure AI Foundry.
Changez de la base de référence : Dans l’architecture de base, l’équipe de charge de travail possède ce composant.
Le réseau virtuel Spoke est l’emplacement où la charge de travail est déployée.
Changez de la base de référence : Dans l’architecture de base, l’équipe de charge de travail possède ce réseau.
Les itinéraires définis par l’utilisateur appliquent le tunneling au réseau hub.
Changez de la base de référence : Dans l’architecture de base, l’équipe de charge de travail possède ce réseau.
Les contraintes de gouvernance basées sur Azure Policy et
DeployIfNotExistsles stratégies DINE s’appliquent à l’abonnement de charge de travail. Vous pouvez appliquer ces stratégies au niveau du groupe d’administration appartenant à l’équipe de plateforme ou à l’abonnement de la charge de travail directement.Changement par rapport à la base : Ces politiques sont nouvelles dans cette architecture. L’équipe de plateforme applique des stratégies qui limitent votre charge de travail. Certaines stratégies peuvent dupliquer des contraintes de charge de travail existantes ou introduire de nouvelles contraintes.
Enregistrements hôtes des
Apour les points de terminaison privés. Pour plus d’informations, consultez Azure Private Link et intégration DNS à grande échelle.Changez de la base de référence : Dans l’architecture de base, l’équipe de charge de travail possède ce réseau. Dans cette architecture, l’équipe de plateforme gère ce composant sous l’abonnement de connectivité.
Le service de résolution DNS prend en charge les réseaux virtuels spoke et les stations de travail intersite. Ce service utilise généralement le Pare-feu Azure en tant que proxy DNS ou programme de résolution privé Azure DNS. Dans cette architecture, le service résout les enregistrements DNS de point de terminaison privé pour toutes les requêtes DNS du spoke. Dns Private Resolver et les ensembles de règles liés sont la méthode recommandée pour l’équipe de plateforme afin d’activer ces exigences de résolution d’architecture en raison des caractéristiques de résolution DNS du service De l’agent Foundry.
Azure DDoS Protection permet de protéger les adresses IP publiques contre les attaques distribuées.
Changez de la base de référence : Dans l’architecture de base, l’équipe de charge de travail achète DDoS Protection.
Important
Les zones d’atterrissage Azure fournissent certaines des ressources précédentes dans le cadre des abonnements de zone d’atterrissage de la plateforme. Votre abonnement à la charge de travail fournit d’autres ressources. La plupart de ces ressources résident dans l’abonnement de connectivité, qui inclut également Azure ExpressRoute, la passerelle VPN Azure et le programme de résolution privé DNS. Ces ressources fournissent un accès entre différents locaux et une résolution des noms. La gestion de ces ressources se situe en dehors de l’étendue de cet article.
Paramétrage de l’abonnement
L’équipe de charge de travail doit informer l’équipe de plateforme des exigences spécifiques en matière de zone d’atterrissage pour implémenter cette architecture. Et l’équipe de plateforme doit communiquer ses exigences à l’équipe de charge de travail.
Par exemple, l’équipe de charge de travail doit fournir des informations détaillées sur l’espace réseau requis. L’équipe de plateforme utilise ces informations pour allouer les ressources nécessaires. L’équipe de charge de travail définit les exigences et l’équipe de plateforme affecte les adresses IP appropriées au sein du réseau virtuel.
L’équipe de plateforme affecte un groupe d’administration en fonction de la critique métier et des besoins techniques de la charge de travail. Par exemple, si la charge de travail est exposée à Internet, comme cette architecture, l’équipe de plateforme sélectionne un groupe d’administration approprié. Pour établir la gouvernance, l’équipe de plateforme configure et implémente également des groupes d’administration. L’équipe de charge de travail doit concevoir et exploiter la charge de travail dans les contraintes de cette gouvernance. Pour plus d’informations sur les distinctions de groupe d’administration classiques, consultez Personnaliser l’architecture de la zone d’atterrissage Azure.
L’équipe de plateforme configure l’abonnement pour cette architecture. Les sections suivantes fournissent des conseils sur la configuration initiale de l’abonnement.
Exigences de la charge de travail et exécution
L’équipe de charge de travail et l’équipe de plateforme doivent collaborer sur des détails tels que l’attribution de groupe d’administration, la gouvernance Azure Policy et la configuration réseau. Préparez une liste de contrôle des exigences pour initier la discussion et la négociation avec l'équipe de la plateforme. La liste de contrôle suivante sert d’exemple.
| Considérations relatives à la conception | Exigences de la charge de travail pour cette architecture | |
|---|---|---|
| ☐ | Nombre de réseaux virtuels spoke et leur taille : L’équipe de plateforme crée et configure le réseau virtuel, puis l’associe au hub régional pour le désigner en tant que spoke. Ils doivent également s’assurer que le réseau peut prendre en charge la croissance future de la charge de travail. Pour effectuer efficacement ces tâches, elles doivent connaître le nombre de spokes requis. | Déployez toutes les ressources dans un seul réseau virtuel spoke dédié. Demandez /22 un espace d’adressage contigu pour prendre en charge les opérations à grande échelle et les scénarios tels que les déploiements côte à côte. Les facteurs suivants déterminent la plupart des besoins d’adresse IP : - Exigences d'Application Gateway pour la taille du sous-réseau (taille fixe). - Points de terminaison privés avec des adresses IP uniques pour les services PaaS (taille fixe). - Taille du sous-réseau pour les agents de construction (taille fixe). - Le service De l’agent Foundry nécessite un sous-réseau dans un /24 préfixe. |
| ☐ | Préfixes d’adresses de réseau virtuel : En règle générale, l’équipe de la plateforme attribue des adresses IP basées sur des conventions existantes, évitez le chevauchement avec les réseaux appairés et la disponibilité dans le système de gestion des adresses IP (IPAM). | Le sous-réseau d’intégration de l’agent doit utiliser un préfixe d’adresse qui commence par 172. ou 192. tel que 192.168.45.1/24. Une restriction d’exécution dans l’hôte de capacité du service Foundry Agent applique cette exigence. Le service De l’agent Foundry ne prend pas en charge les sous-réseaux qui utilisent 10.. Demandez à votre équipe de plateforme de fournir un spoke qui a un préfixe d’adresse valide pour votre sous-réseau d’agent. |
| ☐ | Région de déploiement : L’équipe de plateforme doit déployer un hub dans la même région que les ressources de charge de travail. | Communiquez la région sélectionnée pour la charge de travail et les régions pour les ressources de calcul sous-jacentes. Assurez-vous que les régions prennent en charge les zones de disponibilité. Azure OpenAI dans Les modèles Foundry a une disponibilité régionale limitée. |
| ☐ | Type, volume et modèle de trafic : L’équipe de plateforme doit déterminer les exigences d’entrée et de sortie des ressources partagées de votre charge de travail. | Fournissez des informations sur les facteurs suivants : - Comment les utilisateurs doivent consommer cette charge de travail. - Comment cette charge de travail consomme ses ressources environnantes. - Le protocole de transport configuré. - Le modèle de trafic et les heures de pointe et creuses attendues. Communiquez quand vous attendez un grand nombre de connexions simultanées à Internet (chatteuse) et lorsque vous attendez que la charge de travail génère un trafic réseau minimal (bruit d’arrière-plan). |
| ☐ | Configuration du pare-feu : L’équipe de plateforme doit définir des règles pour autoriser le trafic de sortie légitime. | Partagez des détails sur le trafic sortant à partir du réseau spoke, y compris le trafic de l’agent. Les machines de l’agent de build et de la zone de rebond ont besoin de correctifs de système d’exploitation réguliers. Les agents peuvent avoir besoin d’interagir avec des sources, des outils ou d’autres agents hébergés en dehors de la charge de travail. |
| ☐ | Trafic d’entrée à partir de rôles spécialisés : L’équipe de plateforme doit fournir les rôles spécifiés avec un accès réseau à la charge de travail et implémenter une segmentation appropriée. | Collaborez avec l’équipe de plateforme pour déterminer la meilleure façon d’autoriser l’accès autorisé pour les rôles suivants : - Scientifiques des données et développeurs qui accèdent au portail Azure AI Foundry à partir de leurs stations de travail sur les connexions réseau d’entreprise - Opérateurs qui accèdent à la couche de calcul via une zone de rebond gérée par la charge de travail |
| ☐ |
Accès Internet public à la charge de travail : L’équipe de plateforme utilise ces informations pour l’évaluation des risques, qui détermine plusieurs décisions : - Placement de la charge de travail dans un groupe d’administration avec des garde-fous appropriés - Protection par déni de service distribué (DDoS) pour l’adresse IP publique signalée par l’équipe de charge de travail - Approvisionnement et gestion des certificats TLS |
Informez l'équipe de la plateforme sur le profil du trafic d'entrée: - Trafic source Internet qui cible l’adresse IP publique sur Application Gateway - Noms de domaine complets (FQDN) associés à l’adresse IP publique pour l’approvisionnement de certificats TLS |
| ☐ | Utilisation du point de terminaison privé : L’équipe de plateforme doit configurer des zones DNS privées Azure pour les points de terminaison privés et s’assurer que le pare-feu du réseau hub effectue correctement la résolution DNS. | Informez l’équipe de plateforme sur toutes les ressources qui utilisent des points de terminaison privés, y compris les ressources suivantes : - AI Search - Azure Cosmos DB pour NoSQL - Key Vault - Azure AI Foundry - Comptes de stockage Découvrez comment le hub gère la résolution DNS et définit les responsabilités de l’équipe de charge de travail pour la gestion des enregistrements de zone DNS privés et la liaison de règles DNS Private Resolver. |
| ☐ |
Ressources IA centralisées : L’équipe de plateforme doit comprendre l’utilisation attendue des modèles et des plateformes d’hébergement. Ils utilisent ces informations pour établir la mise en réseau vers des ressources IA centralisées au sein de votre organisation. Chaque organisation définit ses propres plans d’adoption et de gouvernance de l’IA, et l’équipe de charge de travail doit fonctionner dans ces contraintes. |
Informez l’équipe de plateforme sur les ressources IA et Machine Learning que vous envisagez d’utiliser. Cette architecture utilise Azure AI Foundry, Foundry Agent Service et les modèles de base générative hébergés dans Azure AI Foundry. Comprenez clairement les services IA centralisés que vous devez utiliser et comment ces dépendances affectent votre charge de travail. |
Important
L’équipe de plateforme doit suivre un processus de distribution d’abonnement qui utilise un ensemble structuré de questions pour collecter des informations à partir de l’équipe de charge de travail. Ces questions peuvent varier entre les organisations, mais l’objectif est de recueillir les entrées nécessaires pour implémenter efficacement les abonnements. Pour plus d’informations, voir Distributeur d’abonnements.
Calculer
La couche orchestration et l’hébergement de l’interface utilisateur de conversation restent identiques à l’architecture de base.
Réseautage
Dans l’architecture de référence, la charge de travail est provisionnée dans un seul réseau virtuel.
Changez de la base de référence : Cette architecture divise la charge de travail sur deux réseaux virtuels. Un réseau héberge des composants de charge de travail. L’autre réseau gère internet et la connectivité hybride. L’équipe de plateforme détermine comment le réseau virtuel de la charge de travail s’intègre à l’architecture réseau plus grande de l’organisation, qui suit généralement une topologie hub-spoke.
Téléchargez un fichier Visio de cette architecture.
Réseau virtuel hub : Ce réseau virtuel sert de hub régional qui contient des services centralisés et souvent partagés qui communiquent avec les ressources de charge de travail dans la même région. Le hub réside dans l’abonnement de connectivité. L'équipe de la plateforme possède les ressources dans ce réseau.
Réseau virtuel spoke : Dans cette architecture, le réseau virtuel unique de l’architecture de base devient essentiellement le réseau virtuel spoke. L’équipe de plateforme paire ce réseau spoke sur le réseau hub. Ils possèdent et gèrent le réseau spoke, y compris son peering et sa configuration DNS. L’équipe responsable de la charge de travail possède les ressources de ce réseau, y compris ses sous-réseaux. Ce réseau contient de nombreuses ressources de charge de travail.
En raison de cette division de gestion et de propriété, l’équipe de charge de travail doit communiquer clairement les exigences de la charge de travail à l’équipe de plateforme.
Important
Pour l’équipe de plateforme : N’appairez pas directement le réseau spoke à un autre réseau spoke, sauf si la charge de travail l’exige spécifiquement. Cette pratique protège les objectifs de segmentation de la charge de travail. Votre équipe doit faciliter toutes les connexions de réseau virtuel transitif. Toutefois, si les équipes de zone d’atterrissage d’application connectent directement leurs réseaux à l’aide de points de terminaison privés auto-gérés, votre équipe ne gère pas ces connexions.
Comprendre les ressources de charge de travail que les équipes externes gèrent. Par exemple, comprenez la connectivité réseau entre les agents de conversation et une base de données de vecteur de contexte de base gérée par une autre équipe.
Sous-réseaux du réseau virtuel
Dans le réseau virtuel spoke, vous créez et allouez les sous-réseaux en fonction des exigences de charge de travail. Pour fournir une segmentation, appliquez des contrôles qui limitent le trafic vers et hors des sous-réseaux. Cette architecture n’ajoute pas de sous-réseaux au-delà des sous-réseaux de l’architecture de base. Toutefois, l’architecture réseau ne nécessite plus les AzureBastionSubnet sous-réseaux, AzureFirewallSubnet car l’équipe de plateforme héberge probablement cette fonctionnalité dans leurs abonnements.
Vous devez toujours mettre en œuvre des contrôles réseau locaux lorsque vous déployez votre charge de travail dans une zone d'accueil Azure. Votre organisation peut imposer d’autres restrictions réseau pour protéger contre l’exfiltration des données et garantir la visibilité du centre d’opérations de sécurité centrale et de l’équipe du réseau informatique.
Trafic d’entrée
Le flux de trafic d’entrée reste identique à l’architecture de base.
Vous gérez les ressources liées à l’entrée d’Internet public dans la charge de travail. Par exemple, dans cette architecture, Application Gateway et son adresse IP publique résident dans le réseau spoke plutôt que dans le réseau hub. Certaines organisations placent des ressources entrantes dans un abonnement de connectivité à l’aide d’un réseau de périmètre centralisé (également appelé DMZ, zone démilitarisée et sous-réseau filtré). L’intégration à cette topologie spécifique se situe en dehors de l’étendue de cet article.
Approche alternative pour inspecter le trafic entrant
Cette architecture n’utilise pas le Pare-feu Azure pour inspecter le trafic entrant, mais parfois la gouvernance organisationnelle l’exige. Dans ce cas, l’équipe de plateforme prend en charge l’implémentation pour fournir aux équipes de charge de travail une couche supplémentaire de détection et de prévention des intrusions. Cette couche permet de bloquer le trafic entrant indésirable. Pour prendre en charge cette topologie, cette architecture nécessite davantage de configurations UDR. Pour plus d’informations, consultez Le réseau Confiance Zéro pour les applications web avec pare-feu Azure et Application Gateway.
Configuration de DNS
Dans l’architecture de référence, tous les composants utilisent Directement Azure DNS pour la résolution DNS.
Changez de la base de référence : Dans cette architecture, généralement un ou plusieurs serveurs DNS dans le hub effectuent une résolution DNS. Lorsque le réseau virtuel est créé, les propriétés DNS du réseau virtuel doivent déjà être définies en conséquence. L’équipe de charge de travail n’a pas besoin de comprendre les détails de l’implémentation du service DNS.
Cette architecture configure les composants de charge de travail avec DNS de la manière suivante.
| Composant | Configuration de DNS |
|---|---|
| Application Gateway | Hérité du réseau virtuel |
| App Service (UI de chat) | Hérité du réseau virtuel |
| Recherche AI | Impossible de remplacer, utilise Azure DNS |
| Azure AI Foundry | Impossible de remplacer, utilise Azure DNS |
| Service d’agent de la fonderie | Impossible de remplacer, utilise Azure DNS |
| Base de données Azure Cosmos DB | Impossible de remplacer, utilise Azure DNS |
| Boîte de saut | Hérité du réseau virtuel |
| Agents de build | Hérité du réseau virtuel |
Cette architecture ne configure pas les paramètres DNS pour les composants qui ne lancent pas la communication sortante. Ces composants ne nécessitent pas de résolution DNS.
De nombreux composants de cette architecture s’appuient sur les enregistrements DNS hébergés dans les serveurs DNS du hub pour résoudre les points de terminaison privés de cette charge de travail. Pour plus d’informations, consultez zones DNS privées Azure.
Lorsque la résolution DNS basée sur hub n’est pas possible, ces composants sont confrontés aux limitations suivantes :
L’équipe de plateforme ne peut pas consigner les requêtes DNS, ce qui peut violer les exigences de l’équipe de sécurité de l’organisation.
La résolution des services exposés par liaison privée dans votre zone d’atterrissage ou d’autres zones d’atterrissage d’application peut être impossible.
Nous vous recommandons de vous familiariser avec la manière dont l'équipe de la plateforme gère le DNS. Pour plus d’informations, consultez Private Link et intégration DNS à grande échelle. Lorsque vous ajoutez des fonctionnalités de composants qui dépendent directement d'Azure DNS, vous pourriez introduire des complexités dans la topologie DNS fournie par la plateforme. Vous pouvez redéfinir les composants ou négocier des exceptions pour minimiser la complexité.
Trafic de sortie
Dans l’architecture de référence, tous les itinéraires de trafic de sortie vers Internet via le Pare-feu Azure.
Changez de la base de référence : Dans cette architecture, la plateforme fournit un UDR qui pointe vers une instance de pare-feu Azure qu’elle héberge. Appliquez cet UDR aux mêmes sous-réseaux dans l’architecture de base.
Tout le trafic qui quitte le réseau virtuel spoke, y compris le trafic à partir du sous-réseau d’intégration de l’agent, effectue un itinéraire via le réseau hub appairé via un pare-feu de sortie.
Téléchargez un fichier Visio de cette architecture.
La communication client est-ouest vers les points de terminaison privés pour Key Vault, Azure AI Foundry et d’autres services restent identiques à l’architecture de base. Le diagramme précédent n’inclut pas ce chemin d’accès.
Router le trafic internet vers le pare-feu
Tous les sous-réseaux du réseau spoke incluent un itinéraire qui dirige tout le trafic lié à Internet ou 0.0.0.0/0 le trafic vers l’instance du pare-feu Azure du hub.
| Composant | Mécanisme pour forcer le trafic internet à travers le hub |
|---|---|
| Application Gateway | Aucun. Le trafic lié à Internet provenant de ce service ne peut pas être forcé via le pare-feu de l’équipe de plateforme. |
| App Service (UI de chat) | L’intégration du réseau virtuel régional et le paramètre vnetRouteAllEnabled sont activés. |
| Recherche AI | Aucun. Le trafic provenant de ce service ne peut pas être forcé à travers un pare-feu. Cette architecture n'utilise pas de compétences. |
| Service d’agent de la fonderie | UDR appliqué au sous-réseau snet-agentsEgress. |
| Serveurs de rebond | UDR appliqué au sous-réseau snet-jumpbox. |
| Agents de build | UDR appliqué au sous-réseau snet-agents. |
Cette architecture ne configure pas le tunneling forcé pour les composants qui ne lancent pas la communication sortante.
Pour les composants ou fonctionnalités qui ne peuvent pas acheminer le trafic de sortie via le hub, votre équipe de charge de travail doit s’aligner sur les exigences de l’organisation. Pour répondre à ces exigences, utilisez des contrôles de compensation, remaniez la charge de travail pour exclure les fonctionnalités non prises en charge ou demander des exceptions formelles. Vous êtes responsable de l’atténuation de l’exfiltration et de l’abus des données.
Appliquez l’itinéraire Internet fourni par la plateforme à tous les sous-réseaux, même si vous ne vous attendez pas à ce que le sous-réseau dispose d’un trafic sortant. Cette approche garantit que les déploiements inattendus dans ce sous-réseau passent par le filtrage de sortie de routine. Pour les sous-réseaux qui contiennent des points de terminaison privés, activez les stratégies réseau pour prendre en charge le routage complet et le contrôle NSG.
Cette configuration de routage garantit que toutes les connexions sortantes à partir d’App Service, d’Azure AI Foundry et de ses projets, ainsi que tous les autres services provenant du réseau virtuel de la charge de travail sont inspectés et contrôlés.
Zones DNS privées Azure
Les charges de travail qui utilisent des points de terminaison privés pour le trafic est-ouest nécessitent des enregistrements de zone DNS dans le fournisseur DNS configuré. Pour prendre en charge Private Link, cette architecture s’appuie sur de nombreux enregistrements de zone DNS pour les services tels que Key Vault, Azure AI Foundry et Stockage Azure.
Changez de la base de référence : Dans l’architecture de référence, l’équipe de charge de travail gère directement les zones DNS privées. Dans cette architecture, l’équipe de plateforme gère généralement des zones DNS privées. L’équipe de charge de travail doit comprendre clairement les exigences et les attentes de l’équipe de plateforme pour la gestion des enregistrements de zone DNS privé. L’équipe de plateforme peut utiliser d’autres technologies au lieu d’enregistrements de zone DNS privés.
Dans cette architecture, l’équipe de plateforme doit configurer DNS pour les points de terminaison d’API FQDN Azure AI Foundry suivants :
privatelink.services.ai.azure.comprivatelink.openai.azure.comprivatelink.cognitiveservices.azure.com
L’équipe de plateforme doit également configurer DNS pour les noms de domaine complets suivants, qui sont les dépendances du service De l’agent Foundry :
privatelink.search.windows.netprivatelink.blob.core.windows.netprivatelink.documents.azure.com
Important
La résolution DNS doit fonctionner correctement à partir de la virtuelle spoke avant de déployer l’hôte de capacité pour le service De l’agent Foundry et pendant l’opération du service De l’agent Foundry. La fonctionnalité Service de l’agent Foundry n’utilise pas la configuration DNS de votre réseau virtuel spoke. Par conséquent, il est recommandé que votre équipe de plateforme configure un ensemble de règles pour les zones DNS privées de la charge de travail dans DNS Private Resolver, en liant ces règles au spoke de la zone d’atterrissage de votre application.
Avant de déployer Azure AI Foundry et sa fonctionnalité d’agent, vous devez attendre que les dépendances du service De l’agent Foundry soient entièrement résolvables sur leurs points de terminaison privés à partir du réseau spoke. Cette exigence est particulièrement importante si les stratégies DINE gèrent les mises à jour des zones privées DNS. Si vous tentez de déployer la fonctionnalité Service de l’agent Foundry avant que les enregistrements DNS privés ne soient résolus à partir de votre sous-réseau, le déploiement échoue.
L’équipe de plateforme doit également héberger les zones DNS privées pour d’autres dépendances de charge de travail dans cette architecture :
privatelink.vaultcore.azure.netprivatelink.azurewebsites.net
Accès aux développeurs de scientifiques et d’agents de données
Comme l’architecture de référence, cette architecture désactive l’accès public à l’entrée au portail Azure AI Foundry et à d’autres expériences basées sur un navigateur. L’architecture de base déploie une zone de rebond pour fournir un navigateur avec une adresse IP source à partir du réseau virtuel utilisé par différents rôles de charge de travail.
Lorsque votre charge de travail se connecte à une zone d’atterrissage Azure, votre équipe bénéficie d’options d’accès supplémentaires. Collaborez avec l’équipe de plateforme pour voir si vous pouvez obtenir un accès privé à différents portails Azure AI Foundry basés sur un navigateur sans gérer et gérer une machine virtuelle. Cet accès peut être possible via le routage transitif à partir d’une connexion ExpressRoute ou passerelle VPN existante.
L'accès natif depuis une station de travail nécessite un routage inter-sites et une résolution DNS, que l'équipe plateforme peut aider à fournir. Incluez cette exigence dans votre demande de vente de l’abonnement.
La fourniture d’un accès natif basé sur les stations de travail à ces portails améliore la productivité et simplifie la maintenance par rapport à la gestion des sauts de machine virtuelle.
Le rôle de la jump box
La zone de rebond de cette architecture fournit une valeur pour la prise en charge opérationnelle, et non à des fins d’exécution, ni pour le développement d’IA et de Machine Learning. La jump box peut dépanner les problèmes de DNS et de routage réseau car elle fournit un accès réseau interne aux composants autrement inaccessibles de l'extérieur.
Dans l’architecture de base, Azure Bastion accède à la zone de rebond que vous gérez.
Dans cette architecture, Azure Bastion est déployé dans l’abonnement de connectivité en tant que ressource régionale partagée gérée par l’équipe de plateforme. Pour illustrer ce cas d’utilisation dans cette architecture, Azure Bastion se trouve dans l’abonnement de connectivité et votre équipe ne le déploie pas.
La machine virtuelle qui sert de jump box doit respecter les exigences de l’organisation pour les machines virtuelles. Ces exigences peuvent inclure des éléments tels que des identités d'entreprise dans Microsoft Entra ID, des images de base spécifiques et des régimes de mise à jour.
Surveiller les ressources
La plateforme de zone d’atterrissage Azure fournit des ressources d’observabilité partagées dans le cadre des abonnements de gestion. Nous vous recommandons toutefois de provisionner vos propres ressources de surveillance afin de faciliter l’appropriation des responsabilités de la charge de travail. Cette approche s’aligne sur l’architecture de base.
Vous approvisionnez les ressources de surveillance suivantes :
Application Insights sert de service de gestion des performances des applications (APM) pour votre équipe. Vous configurez ce service dans l’interface utilisateur de conversation, le service De l’agent Foundry et les modèles.
L’espace de travail Journaux Azure Monitor sert de récepteur unifié pour tous les journaux et métriques provenant de ressources Azure appartenant à la charge de travail.
Comme pour l’architecture de base, toutes les ressources doivent envoyer des journaux de diagnostic Azure à l’espace de travail Journaux Azure Monitor approvisionné par votre équipe. Cette configuration fait partie du déploiement d’infrastructure en tant que code (IaC) des ressources. Vous devrez peut-être également envoyer des journaux à un espace de travail Azure Monitor Logs central. Dans les zones d’atterrissage Azure, cet espace de travail réside généralement dans l’abonnement de gestion.
L’équipe de plateforme peut avoir davantage de processus qui affectent les ressources dans la zone d’atterrissage de l’application. Par exemple, ils peuvent utiliser des stratégies DINE pour configurer des diagnostics et envoyer des journaux à des abonnements de gestion centralisés. Ils peuvent également appliquer des alertes de base Azure Monitor par le biais de la stratégie. Vérifiez que votre implémentation ne bloque pas ces flux de journalisation et d’alerte supplémentaires.
Azure Policy
L’architecture de base recommande des stratégies générales pour aider à régir la charge de travail. Lorsque vous déployez cette architecture dans une zone d’atterrissage d’application, vous n’avez pas besoin d’ajouter ou de supprimer des stratégies supplémentaires. Pour renforcer la gouvernance et améliorer la sécurité de cette charge de travail, continuez à appliquer des stratégies à votre abonnement, à vos groupes de ressources ou ressources.
Attendez-vous que l’abonnement de zone d’atterrissage de l’application dispose de stratégies existantes, même avant de déployer la charge de travail. Certaines politiques aident à la gouvernance organisationnelle en auditant ou en bloquant des configurations spécifiques dans les déploiements.
Les exemples de stratégies suivants peuvent entraîner des complexités de déploiement de charge de travail :
Policy :Secrets [dans Key Vault] doit avoir la période de validité maximale spécifiée.
Complication: Azure AI Foundry peut stocker des secrets liés aux connexions de connaissances et d’outils dans un coffre de clés connecté. Ces secrets n’ont pas de date d’expiration définie par le service. L’architecture de base n’utilise pas ces types de connexions, mais vous pouvez étendre l’architecture pour les prendre en charge.
Policy :AI Search services doit utiliser des clés gérées par le client pour chiffrer les données au repos.
Complication: Cette architecture ne nécessite pas de clés gérées par le client. Mais vous pouvez étendre l’architecture pour les prendre en charge.
Les modèles Policy :AI Foundry ne doivent pas être en préversion.
Complication: Vous pouvez être en développement à l’aide d’un modèle en préversion que vous prévoyez d’être en disponibilité générale au moment où vous activez la fonctionnalité d’agent dans votre charge de travail de production.
Les équipes plateformes peuvent appliquer des politiques DINE pour gérer les déploiements automatisés dans un abonnement de zone d'atterrissage d'application. Incorporez et testez de manière proactive les restrictions et modifications initiées par la plateforme dans vos modèles IaC. Si l’équipe de plateforme utilise des stratégies Azure qui sont en conflit avec les exigences de l’application, vous pouvez négocier une résolution.
Gestion des changements au fil du temps
Dans cette architecture, les services et opérations fournis par la plateforme servent de dépendances externes. L'équipe plateforme continue d'appliquer des modifications, d'embarquer des zones d'atterrissage et d'appliquer des contrôles de coûts. L’équipe de plateforme peut ne pas hiérarchiser les charges de travail individuelles. Les modifications de ces dépendances, telles que les modifications du pare-feu, peuvent affecter plusieurs charges de travail.
Vous devez communiquer avec les équipes de plateforme de manière efficace et en temps voulu pour gérer toutes les dépendances externes. Il est important de tester les modifications à l'avance afin qu'elles n'affectent pas négativement les charges de travail.
Modifications de plateforme qui affectent la charge de travail
Dans cette architecture, l’équipe de plateforme gère les ressources suivantes. Les modifications apportées à ces ressources sont susceptibles d’affecter la fiabilité, la sécurité, les opérations et les objectifs de performance de la charge de travail. Évaluez ces modifications avant que l’équipe de plateforme ne les implémente pour déterminer comment elles affectent la charge de travail.
Stratégies Azure : les changements apportées aux stratégies Azure peuvent affecter les ressources de charge de travail et leurs dépendances. Ces modifications peuvent inclure des mises à jour de stratégie directes ou un déplacement de la zone d’atterrissage dans une nouvelle hiérarchie de groupe d’administration. Ces modifications peuvent passer inaperçues jusqu’à ce qu’un nouveau déploiement se produise. Vous devez donc les tester soigneusement.
Exemple: Une stratégie n’autorise plus le déploiement d’instances Azure Cosmos DB qui nécessitent un chiffrement de clé géré par le client, et votre architecture utilise le chiffrement de clé managée par Microsoft.
Règles de pare-feu : les changements apportés aux règles de pare-feu peuvent affecter le réseau virtuel de la charge de travail ou les règles qui s’appliquent à l’ensemble du trafic. Ces modifications peuvent entraîner un trafic bloqué et même des échecs de processus silencieux. Ces problèmes potentiels s'appliquent à la fois au pare-feu de sortie et aux règles NSG appliquées par Azure Virtual Network Manager.
Exemple: Le trafic bloqué vers les API Bing entraîne l’échec des appels d’outils d’agent pour les données de base Internet.
Routage dans le réseau hub : Les modifications de la nature transitive du routage dans le hub sont susceptibles d’affecter la fonctionnalité de la charge de travail si celle-ci dépend du routage vers d’autres réseaux virtuels.
Exemple: Une modification de routage empêche les agents Azure AI Foundry d’accéder à un magasin vectoriel géré par une autre équipe ou empêche les équipes de science des données d’accéder au portail AI Foundry à partir de leurs stations de travail.
Hôte Azure Bastion : Modifications de la disponibilité ou de la configuration de l'hôte Azure Bastion.
Exemple : une modification de configuration empêche l’accès aux zones de saut et aux machines virtuelles de l’agent de génération.
Changements au niveau de la charge de travail qui affectent la plateforme
Les exemples suivants décrivent les modifications de charge de travail que vous devez communiquer à l’équipe de plateforme. L’équipe de plateforme doit valider la fiabilité, la sécurité, les opérations et les objectifs de performances du service de plateforme par rapport à vos nouvelles modifications avant qu’elles ne soient appliquées.
Sortie réseau : surveillez toute augmentation significative de la sortie réseau afin d’éviter que la charge de travail ne devienne un voisin bruyant pour les périphériques du réseau. Ce problème peut affecter les cibles de performances ou de fiabilité d’autres charges de travail. Cette architecture est principalement autonome et est peu susceptible d’expérimenter un changement significatif dans les modèles de trafic sortant.
Accès public : Les modifications apportées à l’accès public pour les composants de charge de travail peuvent nécessiter des tests supplémentaires. L’équipe de plateforme peut déplacer la charge de travail vers un autre groupe d’administration.
Exemple : Dans cette architecture, si vous supprimez l'adresse IP publique de l'Application Gateway et rendez cette application uniquement interne, l'exposition de la charge de travail à Internet change. Un autre exemple montre comment exposer les portails IA basés sur le navigateur à Internet, ce que nous vous déconseillons.
Évaluation de la criticité de l’entreprise : Les modifications apportées aux contrats de niveau de service (SLA) de la charge de travail peuvent nécessiter une nouvelle approche de collaboration entre les équipes de plateforme et de charge de travail.
Exemple: Votre charge de travail peut passer d’une activité faible à élevée en raison d’une adoption et d’une réussite accrues.
Équipe d’architecture d’entreprise
Certaines organisations ont une équipe d’architecture d’entreprise qui peut influencer la conception de votre charge de travail et de son architecture. Cette équipe comprend la stratégie d’adoption de l’IA de l’entreprise et les principes et recommandations dans les charges de travail IA sur la conception Azure. Collaborez avec cette équipe pour vous assurer que cette charge de travail de conversation répond aux objectifs spécifiques au scénario et s’aligne sur la stratégie et les recommandations organisationnelles.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.
Cette architecture conserve les garanties de fiabilité dans l’architecture de base. Il n’introduit pas de nouvelles considérations de fiabilité pour les composants de charge de travail de base.
Dépendances critiques
Traitez toutes les fonctionnalités que la charge de travail effectue dans la plateforme et la zone d’atterrissage de l’application en tant que dépendances. Conservez des plans de réponse aux incidents qui incluent des méthodes de contact et des chemins d’escalade pour chaque dépendance. Incluez ces dépendances dans l’analyse du mode d’échec de la charge de travail (FMA).
Tenez compte des dépendances de charge de travail suivantes et des exemples de scénarios susceptibles de se produire :
Pare-feu de sortie : Le pare-feu de sortie centralisé subit des modifications non liées à la charge de travail. Plusieurs charges de travail partagent le pare-feu.
Résolution DNS : Cette architecture utilise DNS fourni par l’équipe de plateforme pour la plupart des ressources, combinées à Azure DNS et aux ensembles de règles dns privés liés pour le service De l’agent Foundry. Par conséquent, la charge de travail dépend des mises à jour en temps opportun des enregistrements DNS pour les points de terminaison privés et la disponibilité des services DNS.
Stratégies DINE : Les stratégies DINE pour les zones DNS privées Azure, ou toute autre dépendance fournie par la plateforme, fonctionnent de manière optimale et n’incluent pas de contrat SLA. Par exemple, un retard dans la configuration DNS pour les points de terminaison privés de cette architecture peut empêcher l’interface utilisateur de conversation de devenir prêt pour le trafic ou de bloquer les agents de terminer des requêtes de service de l’agent Foundry.
Stratégies de groupe d’administration : Les stratégies cohérentes entre les environnements prennent en charge la fiabilité. Assurez-vous que les environnements de préproduction correspondent aux environnements de production pour fournir des tests précis et empêcher des écarts spécifiques à l’environnement qui peuvent bloquer un déploiement ou une mise à l’échelle. Pour plus d’informations, consultez la section Gérer les environnements de développement d’applications dans les zones d’atterrissage Azure.
La plupart de ces considérations peuvent exister sans zones d’atterrissage Azure. Vous devez collaborer avec les équipes de plateforme pour résoudre ces problèmes et vous assurer que vous répondez à toutes les exigences. Pour plus d’informations, consultez Identifier les dépendances.
Sécurité
La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.
Contrôle du trafic d'entrée
Pour isoler votre charge de travail d’autres spokes de charge de travail au sein de votre organisation, appliquez des groupes de sécurité réseau sur vos sous-réseaux et utilisez la nature ou les contrôles nontransitifs dans le hub régional. Construisez des groupes de sécurité réseau complets qui autorisent uniquement les exigences du réseau entrant de votre application et de son infrastructure. Nous vous recommandons de ne pas compter uniquement sur la nature non transitive du réseau du hub pour assurer votre sécurité.
L'équipe plateforme implémente des politiques Azure pour la sécurité. Par exemple, une politique peut s'assurer qu'Application Gateway a un pare-feu d'application web réglé sur mode refuser, ce qui restreint le nombre d'adresses IP publiques disponibles pour votre abonnement. En plus de ces stratégies, vous devez déployer des stratégies plus centrées sur la charge de travail qui renforcent la posture de sécurité d’entrée.
Le tableau suivant présente des exemples de contrôles d’entrée dans cette architecture.
| Origine | Objectif | Contrôle de la charge de travail | Contrôle de la plateforme |
|---|---|---|---|
| Internet | Flux de trafic d'application | Entonnoir toutes les demandes de charge de travail via un groupe de sécurité réseau, un pare-feu d’applications web et des règles de routage avant d’autoriser le trafic public à passer au trafic privé pour l’interface utilisateur de conversation. | Aucun |
| Internet | Accès au portail Azure AI Foundry et accès à l’API REST du plan de données | Refuser tout accès via la configuration au niveau du service. | Aucun |
| Internet | Accès au plan de données à tous les services, à l’exception d’Application Gateway | Refuser tout accès via des règles de groupe de sécurité réseau et une configuration au niveau du service. | Aucun |
| Azure Bastion | Accès à la jump box et à l'agent de construction | Appliquez un groupe de sécurité réseau sur le sous-réseau de zone de rebond qui bloque tout le trafic vers les ports d’accès distant, sauf si la source est le sous-réseau Azure Bastion désigné de la plateforme. | Aucun |
| Réseau entre | Accès au portail Azure AI Foundry et accès à l’API REST du plan de données | Refuser tout accès. Si vous n’utilisez pas la zone de rebond, autorisez l’accès uniquement à partir de stations de travail dans des sous-réseaux autorisés pour les scientifiques des données. | Appliquer le routage nontransitif ou utiliser le pare-feu Azure dans un hub sécurisé Azure Virtual WAN |
| Autres spokes | Aucun | Bloqué via des règles NSG. | Appliquer le routage nontransitif ou utiliser le Pare-feu Azure dans un hub sécurisé Virtual WAN |
Contrôle du trafic de sortie
Applique des règles de groupe de sécurité réseau qui expriment les exigences de connectivité sortante requises de votre solution et refuse tout le reste. Ne vous reposez pas uniquement sur les contrôles réseau hub. En tant qu’opérateur de charge de travail, vous devez arrêter le trafic de sortie non souhaité aussi près de la source que possible.
Vous êtes propriétaire des sous-réseaux de votre charge de travail au sein du réseau virtuel, mais l’équipe de plateforme a probablement créé des règles de pare-feu pour représenter spécifiquement vos exigences capturées dans le cadre du processus de vente de votre abonnement. Assurez-vous que les modifications apportées aux sous-réseaux et au placement des ressources pendant la durée de vie de votre architecture restent compatibles avec votre demande d’origine. Travaillez avec votre équipe réseau pour assurer la continuité du contrôle de sortie à accès restreint.
Le tableau suivant présente des exemples de contrôles de sortie dans cette architecture.
| Point de terminaison | Objectif | Contrôle de la charge de travail | Contrôle de la plateforme |
|---|---|---|---|
| Sources Internet publiques | Votre agent peut nécessiter une recherche Internet pour mettre en place une requête Azure OpenAI dans Foundry Models | Appliquer des groupes de sécurité réseau sur le sous-réseau d’intégration de l’agent | Appliquer des règles d’application de pare-feu pour les magasins et outils de connaissances externes |
| Plan de données Azure AI Foundry | L’interface utilisateur de conversation interagit avec l’agent de conversation | Autoriser TCP/443 à partir du sous-réseau d’intégration App Service vers le sous-réseau de point de terminaison privé Azure AI Foundry | Aucun |
| Base de données Azure Cosmos DB | Pour accéder à la base de données mémoire à partir du service Foundry Agent | Autoriser TCP sur chaque port vers le sous-réseau de point de terminaison privé Azure Cosmos DB | Aucun |
Pour le trafic qui quitte le réseau virtuel de la charge de travail, cette architecture applique des contrôles au niveau de la charge de travail via des groupes de sécurité réseau et au niveau de la plateforme via un pare-feu réseau hub. Les groupes de sécurité réseau fournissent des règles de trafic réseau initiales et étendues. Dans le hub de la plateforme, le pare-feu applique des règles plus spécifiques pour renforcer la sécurité.
Cette architecture ne nécessite pas de trafic est-ouest entre les composants internes, tels que Foundry Agent Service et son instance de recherche IA dépendante, pour acheminer le réseau hub.
Protection contre les DDoS
Déterminez qui doit appliquer le plan de protection DDoS qui couvre les adresses IP publiques de votre solution. L’équipe de plateforme peut utiliser des plans de protection des adresses IP ou utiliser Azure Policy pour appliquer des plans de protection de réseau virtuel. Cette architecture nécessite une couverture de protection DDoS, car elle a une adresse IP publique pour l’entrée à partir d’Internet. Pour plus d’informations, consultez Recommandations pour la mise en réseau et la connectivité.
Gestion de l’identité et de l’accès
Sauf si l’automatisation de la gouvernance de l’équipe de plateforme nécessite des contrôles supplémentaires, cette architecture n’introduit pas de nouvelles exigences d’autorisation en raison de l’implication de l’équipe de plateforme. Le contrôle d’accès en fonction du rôle Azure (RBAC) doit continuer à respecter le principe du privilège minimum, qui accorde un accès limité uniquement aux personnes qui en ont besoin et uniquement si nécessaire. Pour plus d'informations, veuillez consulter la section Recommandations pour la gestion des identités et des accès.
Certificats et chiffrement
Votre équipe fournit généralement le certificat TLS pour l’adresse IP publique sur Application Gateway. Collaborez avec l’équipe de plateforme pour comprendre comment les processus d’approvisionnement et de gestion des certificats doivent s’aligner sur les attentes organisationnelles.
Tous les services de stockage de données de cette architecture prennent en charge les clés de chiffrement gérées par Microsoft ou gérées par le client. Utilisez des clés de chiffrement gérées par le client si la conception de votre charge de travail ou l'organisation nécessite un contrôle accru. Les zones d’atterrissage Azure elles-mêmes n’imposent pas de méthode spécifique.
Optimisation des coûts
L’optimisation des coûts se concentre sur 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.
Toutes les stratégies d’optimisation des coûts de l’architecture de référence s’appliquent aux ressources de charge de travail de cette architecture.
Cette architecture bénéficie grandement des ressources de plateforme des zones d'atterrissage Azure. Par exemple, les ressources telles que le Pare-feu Azure et la protection DDoS passent de la charge de travail aux ressources de plateforme. Même si vous utilisez ces ressources par le biais d’un modèle de rétrofacturation, la sécurité et la connectivité intersite ajoutées sont plus rentables que la gestion automatique de ces ressources. Tirez parti d’autres offres centralisées de votre équipe de plateforme pour étendre ces avantages à votre charge de travail sans compromettre son objectif de niveau de service, son objectif de temps de récupération ou son objectif de point de récupération.
Important
N’essayez pas d’optimiser les coûts en consolidant les dépendances Azure AI Foundry en tant que ressources de plateforme. Ces services doivent rester des ressources de charge de travail.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.
Vous restez responsable de toutes les considérations relatives à l’excellence opérationnelle de l’architecture de base. Ces responsabilités incluent la surveillance, GenAIOps, l’assurance qualité et les pratiques de déploiement sécurisées.
Mise en corrélation des données issues de plusieurs récepteurs
L’espace de travail Journaux Azure Monitor de la charge de travail stocke les journaux et les métriques de la charge de travail et ses composants d’infrastructure. Toutefois, un espace de travail Azure Monitor Logs central stocke souvent les journaux et les métriques des services centralisés, tels que le Pare-feu Azure, le programme de résolution privé DNS et Azure Bastion. La corrélation des données issues de plusieurs récepteurs peut être une tâche complexe.
Les données corrélées permettent de prendre en charge la réponse aux incidents. Le runbook de triage de cette architecture doit résoudre cette situation et inclure les informations de contact de l’organisation si le problème s’étend au-delà des ressources de charge de travail. Les administrateurs de la charge de travail peuvent avoir besoin de l’aide des administrateurs de plateforme pour corréler les entrées de journal provenant des services de réseau d’entreprise, de sécurité ou d’autres services de la plateforme.
Important
Pour l’équipe de plateforme : Si possible, accordez des autorisations RBAC pour interroger et lire des récepteurs de journaux pour les ressources de plateforme pertinentes. Activez les journaux de pare-feu pour les évaluations des règles réseau et d'application et le proxy DNS. Les équipes applicatives peuvent utiliser ces informations pour les tâches de dépannage. Pour plus d'informations, veuillez consulter la section Recommandations pour la surveillance et la détection des menaces.
Agents de build
De nombreux services dans cette architecture utilisent des points de terminaison privés. Comme pour l’architecture de base, cette conception peut nécessiter des agents de build. Votre équipe déploie les agents de build de manière sécurisée et fiable. L’équipe de plateforme n’est pas impliquée dans ce processus.
Assurez-vous que la gestion de l’agent de build est conforme aux normes organisationnelles. Ces normes peuvent inclure l’utilisation d’images de système d’exploitation approuvées par la plateforme, de planifications de mise à jour correctives, de rapports de conformité et de méthodes d’authentification utilisateur.
Efficacité des performances
L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances
Les considérations relatives à l’efficacité des performances dans l’architecture de base s’appliquent également à cette architecture. Votre équipe conserve le contrôle des ressources dans les flux d’application, et non l’équipe de plateforme. Mettez à l’échelle l’hôte de l’interface utilisateur de conversation, les modèles de langage et d’autres composants en fonction des contraintes de charge de travail et de coût. Selon l’implémentation finale de votre architecture, tenez compte des facteurs suivants lorsque vous mesurez vos performances par rapport aux objectifs de performances :
- Latence de sortie et entre différents locaux
- Limitations de la référence SKU de la gouvernance de l’endiguement des coûts
Déployer ce scénario
Déployez une implémentation de zone d’atterrissage de cette architecture de référence.
Contributeurs
Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.
Auteurs principaux :
- Bilal Amjad | Architecture de solution Microsoft Cloud
- Freddy Ayala | Architecte de solution cloud chez Microsoft
- Chad Kittel | Ingénieur logiciel principal - Modèles et pratiques Azure
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étape suivante
Découvrez comment collaborer sur des détails techniques avec l’équipe de plateforme.
Ressource associée
- Perspective Well-Architected Framework sur les charges de travail d’IA sur Azure