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 (Logiciel en tant que service), des services Azure et des services web existants dans votre entreprise.
Azure Integration Services est une collection de services pour intégrer des applications et des données. Cette architecture utilise deux de ces services : Logic Apps pour orchestrer des workflows, et Gestion des API pour créer des catalogues d’API. Cette architecture est suffisante pour les scénarios d’intégration de base où 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.
Téléchargez un fichier Visio de cette architecture.
Architecture
Elle comporte les composants suivants :
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. Il peut s’agir de systèmes SaaS, d’autres services Azure, ou de services web qui exposent des points de terminaison REST ou SOAP.
Azure Logic Apps. 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 architecture, les 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 est un service managé pour la publication de catalogues d’API HTTP, qui promeut la réutilisation et la découvrabilité. 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.
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.
Azure DNS. Azure DNS est un service d’hébergement pour les domaines DNS. Azure DNS offre une résolution de noms à l’aide de l’infrastructure Microsoft 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.
Azure Active Directory (Azure AD) . Utilisez Azure AD pour authentifier des clients qui appellent la passerelle API. Azure AD prend en charge le protocole OpenID Connect (OIDC). Les clients obtiennent un jeton d’accès à partir d’Azure AD et la passerelle API valide le jeton pour autoriser la requête. Lorsque vous utilisez le niveau Standard ou Premium de Gestion des API, Azure AD peut également sécuriser l’accès au portail des développeurs.
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 relatives à l’extensibilité
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, dans le menu Métriques, sélectionnez l’option Métrique de capacité, puis effectuez une montée ou descente en puissance 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 à Gestion des API de profiter d’un contrat de niveau de service plus élevé et vous permet de provisionner 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.
Considérations relatives à la disponibilité
Passez en revue le contrat de niveau de service pour chaque service :
Si vous déployez 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 ; 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.
Considérations relatives à 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 d'échelonner vos charges de travail, ce qui implique de déployer à différentes étapes et d’exécuter des validations à chaque étape avant de passer à la suivante ; vous pourrez ainsi envoyer (push) les mises à jour de vos environnements de production de manière hautement contrôlée tout en réduisant 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. Prévoyez également une bonne stratégie de restauration en cas d'échec d'un déploiement ; par exemple, vous pouvez relancer automatiquement un déploiement antérieur réussi à partir de votre historique de déploiement. Le paramètre --rollback-on-error d'Azure CLI en 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 les 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.
Considérations relatives à la 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 Azure Active Directory 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.
Considérations relatives au coût
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 lorsqu’elles sont 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
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. Ce modèle est illustré dans le prochain article de cette série.