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
Systèmes principaux. Les différents systèmes back-end déployés par l’entreprise ou dont elle dépend se trouvent du côté droit du diagramme. Ces systèmes peuvent inclure des systèmes SaaS, d’autres services Azure, ou de services web qui exposent des points de terminaison REST ou SOAP.
Azure Logic Apps. Dans cette architecture, des applications logiques sont déclenchées par des requêtes HTTP. Vous pouvez également imbriquer des workflows pour une orchestration plus complexe. Logic Apps utilise des connecteurs pour s’intégrer à des services couramment utilisés. Logic Apps propose des centaines de connecteurs, et vous pouvez créer des connecteurs personnalisés.
Azure API Management : Gestion des API se compose de deux composants associés :
Passerelle API. La passerelle API accepte des appels HTTP et les dirige vers le serveur principal.
Portail des développeurs. Chaque instance de Gestion des API Azure fournit un accès au portail des développeurs. Ce portail permet aux développeurs un accès à la documentation et à des exemples de code pour appeler les API. Vous pouvez également tester les API dans le portail des développeurs.
Azure DNS. Azure DNS offre une résolution de noms à l’aide de l’infrastructure Azure. En hébergeant vos domaines dans Azure, vous pouvez gérer vos enregistrements DNS en utilisant les mêmes informations d’identification, les mêmes API, les mêmes outils et la même facturation que pour vos autres services Azure. Pour utiliser un nom de domaine personnalisé, tel que contoso.com, créez des enregistrements DNS qui mappent le nom de domaine personnalisé sur l’adresse IP. Pour plus d’informations, consultez Configurer un nom de domaine personnalisé dans Gestion des API.
Microsoft Entra ID. Utilisez Microsoft Entra ID pour authentifier des clients qui appellent la passerelle API. Microsoft Entra ID prend en charge le protocole OpenID Connect (OIDC). Les clients obtiennent un jeton d’accès à partir de Microsoft Entra ID et la passerelle API valide le jeton pour autoriser la requête. Si vous utilisez le niveau Standard ou Premium de Gestion des API, Microsoft Entra ID peut également sécuriser l’accès au portail des développeurs.
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.
- 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.
- 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.
- Azure DNS est un service d’hébergement pour les domaines DNS.
- 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.
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.
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 le contrat de niveau de service pour chaque service :
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 en utilisant des 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 nécessite des valeurs sensibles que vous ne pouvez pas créer dans un connecteur, stockez ces valeurs dans Azure Key Vault et référencez-les à partir d’un modèle Resource Manager. Utilisez des paramètres de modèle de déploiement, ainsi que des fichiers de paramètres pour chaque environnement. Pour plus d’informations, consultez Sécuriser les paramètres et les entrées dans un flux de travail.
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 :