Cette architecture de référence utilise Azure Integration Services pour orchestrer des appels aux systèmes principaux d’entreprise. Les systèmes principaux peuvent inclure des systèmes SaaS (software as a service), des services Azure et des services web existants dans votre entreprise.
Architecture
Téléchargez un fichier Visio de cette architecture.
Workflow
application. L’application est un client qui appelle la passerelle d’API après l’authentification auprès de Microsoft Entra. L’application peut être une application web, une application mobile ou tout autre client capable d’effectuer des requêtes HTTP.
Microsoft Entra ID. Permet d’authentifier l’application cliente. L’application cliente obtient un jeton d’accès à partir de l’ID Microsoft Entra et l’inclut dans la demande adressée à la passerelle d’API.
Azure API Management : Gestion des API se compose de deux composants associés :
Passerelle API. La passerelle d’API accepte l’appel HTTP de l’application cliente, valide le jeton de Microsoft Entra ID et transfère la requête au service principal. La passerelle d’API peut également transformer des demandes et des réponses et mettre en cache des réponses.
Portail des développeurs. Le portail des développeurs est utilisé par les développeurs pour découvrir et interagir avec les API. Le portail des développeurs peut être personnalisé pour correspondre à la personnalisation de votre organisation.
Azure Logic Apps. Logic Apps est utilisé pour orchestrer les appels aux services principaux. Logic Apps peut être déclenché par divers événements et appeler divers services. Dans cette solution, Logic Apps est utilisé pour appeler les services principaux et fournir une connectivité facile via connecteurs réduire le besoin de code personnalisé.
services principaux. Les services back-end peuvent être n’importe quel service ou application métier, comme une base de données, un service web ou une application SaaS. Les services back-end peuvent être hébergés dans Azure ou localement.
Composants
-
Services d’intégration est une collection de services que vous pouvez utiliser pour intégrer des applications, des données et des processus. Dans cette solution, deux de ces services sont utilisés : Logic Apps et Gestion des API. Logic Apps est utilisé pour faciliter l’intégration basée sur les messages entre les systèmes et faciliter la connectivité avec les connecteurs. Gestion des API est utilisée pour fournir une façade aux services principaux, ce qui permet aux clients d’interagir avec une interface cohérente.
- Logic Apps est une plateforme serverless pour la création de workflows d’entreprise qui intègrent des applications, des données et des services. Dans cette solution, Logic Apps est utilisé pour orchestrer les appels aux services back-end et fournir une connectivité facile via des connecteurs réduisant le besoin de code personnalisé.
- Gestion des API est un service managé pour la publication de catalogues ou d’API HTTP. Vous pouvez l’utiliser pour promouvoir la réutilisation et la détectabilité de vos API et pour déployer une passerelle d’API sur des demandes d’API de proxy. Dans cette solution, Gestion des API fournit des fonctionnalités supplémentaires telles que la limitation de débit, l’authentification et la mise en cache sur les services principaux. En outre, Gestion des API fournit un portail de développement pour que les clients découvrent et interagissent avec les API.
- Azure DNS est un service d’hébergement pour les domaines DNS. Azure DNS héberge les enregistrements DNS publics pour le service Gestion des API. Cela permet aux clients de résoudre le nom DNS en adresse IP du service Gestion des API.
- Microsoft Entra ID est un service de gestion des identités et des accès basé sur le cloud. Les employés de l’entreprise peuvent utiliser Microsoft Entra ID pour accéder aux ressources externes et internes. Ici Entra ID est utilisé pour sécuriser le service Gestion des API à l’aide de OAuth 2.0 et du portail des développeurs à l’aide de Entra B2C.
Détails du scénario
Services d’intégration est une collection de services que vous pouvez utiliser pour intégrer des applications, des données et des processus pour votre entreprise. Cette architecture utilise deux de ces services : Logic Apps pour orchestrer des workflows, et Gestion des API pour créer des catalogues d’API.
Dans cette architecture, les API composites sont générées par l’importation d’applications logiques en tant qu’API. Vous pouvez également importer des services web existants grâce à l’importation de spécifications OpenAPI (Swagger) ou l’importation d’API SOAP à partir de spécifications WSDL.
La passerelle API permet de découpler les clients frontaux depuis le serveur principal. Par exemple, elle peut réécrire les URL, ou transformer des requêtes avant qu’elles atteignent le serveur principal. Elle gère également les nombreux problèmes transversaux comme l’authentification, la prise en charge du partage des ressources cross-origin (CORS) et la mise en cache des réponses.
Cas d’usage potentiels
Cette architecture est suffisante pour des scénarios d’intégration de base dans lesquels le workflow est déclenché par des appels synchrones à des services back-end. Une architecture plus sophistiquée utilisant des files d’attente et des événements s’appuie sur cette architecture de base.
Recommandations
Vos exigences spécifiques peuvent différer de l’architecture générique indiquée ici. Utilisez les recommandations de cette section comme point de départ.
Gestion des API
Utilisez les niveaux De base, Standard ou Premium de Gestion des API. Ces niveaux offrent un contrat de niveau de service de production et prennent en charge le scale-out au sein de la région Azure. La capacité de débit pour Gestion des API est mesurée en unités. Chaque niveau tarifaire a un scale-out maximal. Le niveau Premium prend également en charge le scale-out dans plusieurs régions Azure. Choisissez votre niveau en fonction de votre ensemble de fonctionnalités et du niveau de débit requis. Pour plus d’informations, consultez Tarification de Gestion des API et la Capacité d’une instance du service Gestion des API Azure.
Le niveau Consommation de gestion des API n’est pas recommandé pour cette solution, car il ne prend pas en charge le portail des développeurs requis pour cette architecture. Le niveau développeur est spécifiquement destiné aux environnements hors production et n’est pas recommandé pour les charges de travail de production. Une matrice de caractéristiques détaillant les différences entre les niveaux se trouve ici.
Chaque instance du service Gestion des API Azure a un nom de domaine par défaut, qui est un sous-domaine de azure-api.net, par exemple contoso.azure-api.net. Envisagez de configurer un domaine personnalisé pour votre organisation.
Logic Apps
Logic Apps fonctionne mieux dans les scénarios qui ne nécessitent pas de latence faible pour une réponse, par exemple les appels d’API asynchrones ou à exécution semi-longue. Si une latence faible est nécessaire, par exemple dans un appel qui bloque une interface utilisateur, utilisez une autre technologie. Par exemple, utilisez Azure Functions ou une API web déployée sur Azure App Service. Utilisez Gestion des API pour proposer l’API à vos consommateurs d’API.
Région
Pour réduire la latence du réseau, placez Gestion des API et Logic Apps dans la même région. En général, choisissez la région la plus proche de vos utilisateurs (ou la plus proche de vos services principaux).
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 Microsoft Azure Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
Passez en revue les contrats SLA pour chaque service ici
Si vous déployez la Gestion des API sur deux régions ou plus avec un niveau Premium, ce service est éligible pour un contrat SLA supérieur. Voir Tarification de Gestion des API.
Sauvegardes
Sauvegardez régulièrement votre configuration de Gestion des API. Stockez vos fichiers de sauvegarde dans un emplacement ou une région Azure qui diffère de celle où le service est déployé. Selon votre RTO, choisissez une stratégie de récupération d’urgence :
Dans un événement de reprise d’activité, provisionnez une nouvelle instance Gestion des API, restaurez la sauvegarde dans la nouvelle instance et redirigez les enregistrements DNS.
Conservez une instance passive du service Gestion des API dans une autre région Azure. Restaurez régulièrement des sauvegardes sur cette instance, pour la maintenir synchronisée avec le service actif. Pour restaurer le service durant un événement de reprise d’activité, vous devez uniquement rediriger les enregistrements DNS. Cette approche entraîne des coûts supplémentaires, car vous payez pour l’instance passive ; mais elle réduit cependant le temps de récupération.
Pour les applications logiques, nous recommandons une approche de configuration sous forme de code pour effectuer la sauvegarde et la restauration. Étant donné que les applications logiques sont sans serveur, vous pouvez les recréer rapidement à partir de modèles Azure Resource Manager. Enregistrez les modèles dans le contrôle de code source, intégrez les modèles à votre processus de déploiement continu/intégration continue (CI/CD). Dans un événement de récupération d’urgence, déployez le modèle dans une nouvelle région.
Si vous déployez une application logique dans une autre région, mettez à jour la configuration de Gestion des API. Vous pouvez mettre à jour la propriété back-end de l’API à l’aide d’un script PowerShell de base.
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 plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Bien que la liste ci-après ne décrive pas complètement toutes les bonnes pratiques liées à la sécurité, vous y trouverez quelques considérations sur la sécurité qui s’appliquent spécifiquement à cette architecture :
Le service Gestion des API Azure a une adresse IP publique fixe. Limitez l’accès pour appeler des points de terminaison Logic Apps uniquement à l’adresse IP de Gestion des API. Pour plus d’informations, consultez Limiter les adresses IP entrantes.
Pour attribuer aux utilisateurs les niveaux d’accès appropriés, utilisez le contrôle d’accès en fonction du rôle Azure (RBAC Azure).
Sécurisez les points de terminaison des API publiques dans Gestion des API à l’aide d’OAuth ou d’OpenID Connect. Pour sécuriser les points de terminaison des API publiques, configurez un fournisseur d’identité et ajoutez une stratégie de validation de jeton JSON Web Token (JWT). Pour plus d’informations, consultez Guide pratique pour protéger une API à l’aide d’OAuth 2.0 avec Microsoft Entra ID et Gestion des API.
Connectez-vous aux services principaux à partir de Gestion des API à l’aide de certificats mutuels.
Appliquez le protocole HTTPS sur les API de Gestion des API.
Stockage des secrets
Ne recherchez jamais des mots de passe, clés d’accès ou chaînes de connexion dans un contrôle de code source. Si ces valeurs sont nécessaires, sécurisez-les et déployez-les à l’aide des méthodes appropriées.
Si une application logique fonctionne avec des données sensibles, consultez Sécuriser l’accès et les données pour les flux de travail dans Azure Logic Apps pour obtenir des conseils détaillés.
Gestion des API gère les secrets à l’aide d’objets appelés valeurs nommées ou propriétés nommées. Ces objets stockent de manière sécurisée les valeurs auxquelles vous pouvez accéder par le biais des stratégies de Gestion des API. Pour plus d’informations, consultez Guide pratique pour utiliser des valeurs nommées dans les stratégies Gestion des API Azure.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
DevOps
Créez des groupes de ressources distincts pour les environnements de production, de développement et de test. Des groupes de ressources distincts simplifient la gestion des déploiements, la suppression des déploiements de tests et l’attribution des droits d’accès.
Lorsque vous attribuez des ressources à des groupes de ressources, considérez les facteurs suivants :
Cycle de vie. D’une façon générale, placez les ressources dotées d’un même cycle de vie dans un même groupe de ressources.
Accès. Pour appliquer des stratégies d’accès aux ressources d’un groupe, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (RBAC Azure).
Facturation. Vous pouvez afficher les coûts cumulés pour le groupe de ressources.
Niveau tarifaire pour Gestion des API. Utilisez le niveau Développeur pour les environnements de développement et de test. Pour réduire les coûts durant la préproduction, déployez un réplica de votre environnement de production, exécutez vos tests, puis arrêtez.
Déploiement
Utilisez les modèles Azure Resource Manager pour déployer les ressources Azure en suivant le processus IaC (Infrastructure as Code). Les modèles facilitent l’automatisation des déploiements à l'aide d'Azure DevOps Services, ou d'autres solutions de CI/CD.
Staging
Envisagez la mise en lots de vos charges de travail, à savoir le déploiement à différentes étapes et l’exécution de validations à chaque étape avant de passer à la suivante. Si vous utilisez cette approche, vous pouvez envoyer (push) des mises à jour vers vos environnements de production de manière hautement contrôlée et limiter les problèmes de déploiement imprévus.
Déploiement Blue-Green et Mises en production Canary sont les stratégies de déploiement recommandées pour mettre à jour les environnements de production. Envisagez également d’avoir une bonne stratégie de restauration en cas d’échec d’un déploiement. Par exemple, vous pouvez automatiquement relancer un déploiement antérieur réussi à partir de votre historique de déploiement. Le paramètre d’indicateur --rollback-on-error dans Azure CLI est un bon exemple.
Isolation des charges de travail
Placez Gestion des API Azure et toutes les applications logiques individuelles dans leurs propres modèles Resource Manager distincts. En utilisant des modèles distincts, vous pouvez stocker les ressources dans les systèmes de contrôle de code source. Vous pouvez déployer les modèles, ensemble ou individuellement, dans le cadre d’un processus CI/CD.
Versions
Chaque fois que vous changez la configuration d’une application logique ou que vous déployez une mise à jour par le biais d’un modèle Resource Manager, Azure conserve une copie de cette version et conserve toutes les versions qui ont un historique d’exécution. Vous pouvez utiliser ces versions pour suivre les modifications historiques ou pour promouvoir une version en tant que configuration actuelle de l’application logique. Par exemple, vous pouvez restaurer une application logique vers une version antérieure.
Gestion des API prend en charge deux concepts de contrôle de version distincts, mais complémentaires :
Les versions offrent aux consommateurs d’API la possibilité de choisir une version d’API en fonction de leurs besoins, par exemple, v1, v2, bêta ou production.
Les révisions permettent aux administrateurs d’API d’apporter des modifications mineures dans une API et de déployer ces modifications, ainsi que d’un journal des modifications pour informer des consommateurs de l’API des modifications.
Vous pouvez effectuer une révision dans un environnement de développement et déployer cette modification entre d’autres environnements à l’aide de modèles Resource Manager. Pour plus d’informations, consultez Publier plusieurs versions de votre API
Vous pouvez également utiliser des révisions pour tester une API avant de valider et de rendre les modifications accessibles aux utilisateurs. Toutefois, cette méthode n’est pas recommandée pour les tests de charge ou les tests d’intégration. Au lieu de cela, utilisez des environnements de préproduction et de test distincts.
Diagnostics et surveillance
Utilisez Azure Monitor pour la supervision opérationnelle dans Gestion des API et Logic Apps. Azure Monitor fournit des informations basées sur les métriques configurées pour chaque service, et est activé par défaut. Pour plus d'informations, consultez les pages suivantes :
- Surveiller les API publiées
- Surveiller l’état, configurer la journalisation des diagnostics et activer les alertes pour Azure Logic Apps
Chaque service a également ces options :
Pour une analyse approfondie et la création de tableaux de bord, envoyez les journaux d’activité Logic Apps à Azure Log Analytics.
Pour la supervision DevOps, configurez Azure Application Insights pour le service Gestion des API.
Gestion des API prend en charge le modèle de solution Power BI pour l’analyse personnalisée d’API. Vous pouvez utiliser ce modèle de solution pour créer votre propre solution d’analytique. Pour les utilisateurs professionnels, Power BI met des rapports à disposition.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.
Pour augmenter la scalabilité de Gestion des API, ajoutez des stratégies de mise en cache quand cela est nécessaire. La mise en cache permet également de réduire la charge sur les services principaux.
Pour offrir une plus grande capacité, vous pouvez faire monter en charge les niveaux De base, Standard et Premium de Gestion des API Azure au sein d’une région Azure. Pour analyser l’utilisation de votre service, sélectionnez Métrique de capacité dans le menu Métriques, puis effectuez un scale-up ou un scale-down selon le cas. Le processus de mise à niveau ou de mise à l’échelle peut durer entre 15 et 45 minutes.
Recommandations pour la mise à l’échelle d’un service Gestion des API :
Prenez en compte les modèles de trafic pendant une mise à l’échelle. Les clients utilisant des modèles de trafic plus volatiles ont besoin de davantage de capacité.
Une capacité constante supérieure à 66 % peut indiquer un besoin de monter en puissance.
Une capacité constante inférieure à 20 % peut indiquer une opportunité de descendre en puissance.
Avant d’activer la charge en production, effectuez toujours un test de charge de votre service Gestion des API avec une charge représentative.
Avec le niveau Premium, vous pouvez faire évoluer une instance de Gestion des API dans plusieurs régions Azure. Cela permet à la Gestion des API de profiter d’un contrat SLA plus élevé et vous permet d’approvisionner des services à proximité des utilisateurs dans plusieurs régions.
Le modèle serverless de Logic Apps signifie que les administrateurs n’ont pas besoin de planifier la scalabilité des services. Le service s’ajuste automatiquement pour répondre à la demande.
Optimisation des coûts
En règle générale, utilisez la calculatrice de prix Azure pour estimer les coûts. Voici quelques autres éléments à prendre en compte :
Gestion des API
Vous êtes facturé pour toutes les instances de Gestion des API en cours d’exécution. Si vous avez effectué un scale-up et que vous n’avez pas besoin de ce niveau de performances tout le temps, faites un scale-down manuellement ou configurez l’autoscaling.
Logic Apps
Logic Apps utilise un modèle serverless. La facturation est calculée en fonction de l’action et de l’exécution du connecteur. Pour plus d’informations, consultez Tarifs Logic Apps.
Pour plus d’informations, consultez la section sur les coûts dans Microsoft Azure Well-Architected Framework.
Étapes suivantes
Ressources associées
Pour une fiabilité et une scalabilité supérieures, utilisez des files d’attente de messages et des événements pour découpler les systèmes back-end. Cette architecture est illustrée dans le prochain article de cette série :
Vous pouvez également être intéressé par ces articles suivants du Centre des architectures Azure :