Partager via

Considérations relatives à la plateforme d’application pour les charges de travail stratégiques sur Azure

  • Article

Azure fournit de nombreux services de calcul pour l’hébergement d’applications hautement disponibles. Les services diffèrent par leur capacité et leur complexité. Nous vous recommandons de choisir des services en fonction des points suivants :

  • Exigences non fonctionnelles en matière de fiabilité, de disponibilité, de performances et de sécurité.
  • Facteurs de décision tels que la scalabilité, le coût, l’opérabilité et la complexité.

Le choix d’une plateforme d’hébergement d’applications est une décision critique qui affecte tous les autres domaines de conception. Par exemple, les logiciels de développement hérités ou propriétaires peuvent ne pas s’exécuter dans les services PaaS ou les applications conteneurisées. Cette limitation influence votre choix de plateforme de calcul.

Une application stratégique peut utiliser plusieurs services de calcul pour prendre en charge plusieurs charges de travail composites et microservices, chacun avec des exigences distinctes.

Cette zone de conception fournit des recommandations relatives aux options de sélection, de conception et de configuration du calcul. Nous vous recommandons également de vous familiariser avec l’arbre de décision calcul.

Important

Cet article fait partie de la série de charges de travail stratégiques Azure Well-Architected Framework . Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par Qu’est-ce qu’une charge de travail stratégique ?.

Distribution globale des ressources de la plateforme

Un modèle classique pour une charge de travail stratégique inclut les ressources globales et les ressources régionales.

Les services Azure, qui ne sont pas limités à une région Azure particulière, sont déployés ou configurés en tant que ressources globales. Certains cas d’usage incluent la distribution du trafic entre plusieurs régions, le stockage de l’état permanent pour une application entière et la mise en cache de données statiques globales. Si vous devez prendre en charge à la fois une architecture d’unité d’échelle et une distribution globale, réfléchissez à la façon dont les ressources sont distribuées ou répliquées de manière optimale dans les régions Azure.

D’autres ressources sont déployées au niveau régional. Ces ressources, qui sont déployées dans le cadre d’un tampon de déploiement, correspondent généralement à une unité de mise à l’échelle. Toutefois, une région peut avoir plusieurs empreintes, et une empreinte peut avoir plusieurs unités. La fiabilité des ressources régionales est cruciale, car elles sont responsables de l’exécution de la charge de travail main.

L’image suivante montre la conception de haut niveau. Un utilisateur accède à l’application via un point d’entrée global central qui redirige ensuite les demandes vers un tampon de déploiement régional approprié :

Diagramme montrant une architecture stratégique.

La méthodologie de conception stratégique nécessite un déploiement multirégion. Ce modèle garantit la tolérance de panne régionale, de sorte que l’application reste disponible même quand une région entière tombe en panne. Lorsque vous concevez une application multirégion, tenez compte de différentes stratégies de déploiement, comme active/active et active/passive, ainsi que des exigences d’application, car il existe des compromis importants pour chaque approche. Pour les charges de travail stratégiques, nous recommandons vivement le modèle actif/actif.

Toutes les charges de travail ne prennent pas en charge ou ne nécessitent pas l’exécution simultanée de plusieurs régions. Vous devez évaluer les exigences d’application spécifiques par rapport aux compromis pour déterminer une décision de conception optimale. Pour certains scénarios d’application qui ont des cibles de fiabilité inférieures, le partitionnement actif/passif ou le partitionnement peuvent être des alternatives appropriées.

Les zones de disponibilité peuvent fournir des déploiements régionaux hautement disponibles dans différents centres de données au sein d’une région. Presque tous les services Azure sont disponibles dans une configuration zonale, où le service est délégué à une zone spécifique, ou dans une configuration redondante interzone, où la plateforme garantit automatiquement que le service s’étend sur plusieurs zones et peut résister à une panne de zone. Ces configurations fournissent une tolérance de panne jusqu’au niveau du centre de données.

Considérations en matière de conception

  • Fonctionnalités régionales et zonales. Tous les services et fonctionnalités ne sont pas disponibles dans chaque région Azure. Cette considération peut affecter les régions que vous choisissez. En outre, les zones de disponibilité ne sont pas disponibles dans toutes les régions.

  • Paires régionales. Les régions Azure sont regroupées en paires régionales qui se composent de deux régions dans une même zone géographique. Certains services Azure utilisent des régions jumelées pour garantir la continuité de l’activité et fournir un niveau de protection contre la perte de données. Par exemple, le stockage géoredondant Azure (GRS) réplique automatiquement les données vers une région secondaire jumelée, garantissant ainsi que les données sont durables si la région primaire n’est pas récupérable. Si une panne affecte plusieurs régions Azure, au moins une région de chaque paire est prioritaire pour la récupération.

  • Cohérence des données. Pour les problèmes de cohérence, envisagez d’utiliser un magasin de données distribué à l’échelle mondiale, une architecture régionale marquée et un déploiement partiellement actif/actif. Dans un déploiement partiel, certains composants sont actifs dans toutes les régions, tandis que d’autres sont situés de manière centralisée dans la région primaire.

  • Déploiement sécurisé. L’infrastructure des pratiques de déploiement sécurisé (SDP) Azure garantit que toutes les modifications de code et de configuration (maintenance planifiée) de la plateforme Azure font l’objet d’un déploiement par phases. L’intégrité est analysée pour la dégradation pendant la mise en production. Une fois les phases canary et pilote terminées, les mises à jour de la plateforme sont sérialisées entre les paires régionales, de sorte qu’une seule région de chaque paire est mise à jour à un moment donné.

  • Capacité de la plateforme. Comme tout fournisseur de cloud, Azure a des ressources limitées. L’indisponibilité peut être le résultat de limitations de capacité dans les régions. En cas de panne régionale, la demande de ressources augmente à mesure que la charge de travail tente de se rétablir dans la région jumelée. La panne peut créer un problème de capacité, où l’offre ne répond temporairement pas à la demande.

Recommandations de conception

  • Déployez votre solution dans au moins deux régions Azure pour vous protéger contre les pannes régionales. Déployez-le dans des régions qui ont les fonctionnalités et les caractéristiques requises par la charge de travail. Les fonctionnalités doivent répondre aux objectifs de performances et de disponibilité tout en répondant aux exigences de résidence et de rétention des données.

    Par exemple, certaines exigences de conformité des données peuvent limiter le nombre de régions disponibles et éventuellement forcer des compromis de conception. Dans ce cas, nous vous recommandons vivement d’ajouter des investissements supplémentaires dans des wrappers opérationnels pour prédire, détecter et répondre aux défaillances. Supposons que vous êtes limité à une zone géographique avec deux régions, et qu’une seule de ces régions prend en charge les zones de disponibilité (modèle de centre de données 3 + 1). Créez un modèle de déploiement secondaire à l’aide de l’isolation de domaine d’erreur pour permettre aux deux régions d’être déployées dans une configuration active et assurez-vous que la région primaire héberge plusieurs empreintes de déploiement.

    Si les régions Azure appropriées n’offrent pas toutes les fonctionnalités dont vous avez besoin, préparez-vous à compromettre la cohérence des empreintes de déploiement régionaux pour hiérarchiser la distribution géographique et optimiser la fiabilité. Si une seule région Azure est appropriée, déployez plusieurs empreintes de déploiement (unités d’échelle régionales) dans la région sélectionnée pour atténuer certains risques et utilisez des zones de disponibilité pour fournir une tolérance de panne au niveau du centre de données. Toutefois, une telle compromission dans la distribution géographique limite considérablement le contrat SLA composite réalisable et la fiabilité globale.

    Important

    Pour les scénarios qui ciblent un SLO supérieur ou égal à 99,99 %, nous recommandons un minimum de trois régions de déploiement pour optimiser le contrat SLA composite et la fiabilité globale. Calculez le contrat SLA composite pour tous les flux utilisateur. Assurez-vous que le contrat SLA composite est aligné sur les cibles de l’entreprise.

  • Pour les scénarios d’application à grande échelle qui ont des volumes de trafic importants, concevez la solution pour effectuer une mise à l’échelle dans plusieurs régions afin de naviguer dans les contraintes de capacité potentielles au sein d’une même région. D’autres empreintes de déploiement régional permettront d’obtenir un contrat SLA composite plus élevé. L’utilisation de ressources globales limite l’augmentation du contrat SLA composite que vous obtenez en ajoutant d’autres régions.

  • Définissez et validez vos objectifs de point de récupération (RPO) et vos objectifs de temps de récupération (RTO).

  • Au sein d’une même zone géographique, hiérarchisez l’utilisation de paires régionales pour tirer parti des déploiements sérialisés SDP pour la maintenance planifiée et de la hiérarchisation régionale pour la maintenance non planifiée.

  • Colocalisez géographiquement des ressources Azure avec les utilisateurs pour réduire la latence du réseau et optimiser les performances de bout en bout.

  • Alignez la disponibilité actuelle du service sur les feuilles de route du produit lorsque vous choisissez des régions de déploiement. Certains services peuvent ne pas être disponibles immédiatement dans chaque région.

Mise en conteneur

Un conteneur inclut le code d’application et les fichiers de configuration, bibliothèques et dépendances associés que l’application doit exécuter. La conteneurisation fournit une couche d’abstraction pour le code d’application et ses dépendances et crée une séparation de la plateforme d’hébergement sous-jacente. Le package logiciel unique est hautement portable et peut s’exécuter de manière cohérente sur différentes plateformes d’infrastructure et fournisseurs de cloud. Les développeurs n’ont pas besoin de réécrire le code et peuvent déployer des applications plus rapidement et de manière plus fiable.

Important

Nous vous recommandons d’utiliser des conteneurs pour les packages d’applications stratégiques. Ils améliorent l’utilisation de l’infrastructure, car vous pouvez héberger plusieurs conteneurs sur la même infrastructure virtualisée. En outre, étant donné que tous les logiciels sont inclus dans le conteneur, vous pouvez déplacer l’application sur différents systèmes d’exploitation, quels que soient les runtimes ou les versions de bibliothèque. La gestion est également plus facile avec les conteneurs qu’avec l’hébergement virtualisé traditionnel.

Les applications stratégiques doivent être mises à l’échelle rapidement pour éviter les goulots d’étranglement des performances. Étant donné que les images conteneur sont prédéfinies, vous pouvez limiter le démarrage à se produire uniquement pendant le démarrage de l’application, ce qui offre une scalabilité rapide.

Considérations en matière de conception

  • Supervision. Il peut être difficile pour les services de surveillance d’accéder aux applications qui se trouvent dans des conteneurs. Vous avez généralement besoin de logiciels tiers pour collecter et stocker des indicateurs d’état de conteneur tels que l’utilisation du processeur ou de la RAM.

  • Sécurité. Le noyau du système d’exploitation de la plateforme d’hébergement est partagé entre plusieurs conteneurs, ce qui crée un point d’attaque unique. Toutefois, le risque d’accès à la machine virtuelle hôte est limité, car les conteneurs sont isolés du système d’exploitation sous-jacent.

  • État. Bien qu’il soit possible de stocker des données dans le système de fichiers d’un conteneur en cours d’exécution, les données ne sont pas conservées lorsque le conteneur est recréé. Au lieu de cela, conservez les données en montant un stockage externe ou en utilisant une base de données externe.

Recommandations de conception

  • Conteneurisez tous les composants d’application. Utilisez des images conteneur comme modèle principal pour les packages de déploiement d’applications.

  • Hiérarchisez les runtimes de conteneur linux lorsque cela est possible. Les images sont plus légères et de nouvelles fonctionnalités pour les nœuds/conteneurs Linux sont fréquemment publiées.

  • Rendre les conteneurs immuables et remplaçables, avec des cycles de vie courts.

  • Veillez à rassembler tous les journaux et métriques pertinents à partir du conteneur, de l’hôte de conteneur et du cluster sous-jacent. Envoyez les journaux et les métriques collectés à un récepteur de données unifié pour un traitement et une analyse supplémentaires.

  • Stockez des images conteneur dans Azure Container Registry. Utilisez la géoréplication pour répliquer des images conteneur dans toutes les régions. Activez Microsoft Defender pour les registres de conteneurs afin de fournir une analyse des vulnérabilités pour les images conteneur. Assurez-vous que l’accès au Registre est géré par Microsoft Entra ID.

Hébergement et orchestration de conteneurs

Plusieurs plateformes d’applications Azure peuvent héberger efficacement des conteneurs. Il existe des avantages et des inconvénients associés à chacune de ces plateformes. Comparez les options dans le contexte de vos besoins métier. Toutefois, optimisez toujours la fiabilité, la scalabilité et les performances. Pour plus d’informations, voir les articles suivants :

Important

Azure Kubernetes Service (AKS) et Azure Container Apps doivent faire partie de vos premiers choix pour la gestion des conteneurs en fonction de vos besoins. Bien que Azure App Service ne soit pas un orchestrateur, en tant que plateforme de conteneur à faible friction, il reste une alternative possible à AKS.

Considérations et recommandations relatives à la conception de Azure Kubernetes Service

AKS, un service Kubernetes managé, permet l’approvisionnement rapide des clusters sans nécessiter d’activités d’administration de cluster complexes et offre un ensemble de fonctionnalités qui inclut des fonctionnalités avancées de mise en réseau et d’identité. Pour obtenir un ensemble complet de recommandations, consultez Révision d’Azure Well-Architected Framework - AKS.

Important

Il existe des décisions de configuration fondamentales que vous ne pouvez pas modifier sans redéploiement du cluster AKS. Les exemples incluent le choix entre les clusters AKS publics et privés, l’activation d’Azure Network Policy, l’intégration Microsoft Entra et l’utilisation d’identités managées pour AKS au lieu de principaux de service.

Fiabilité

AKS gère le plan de contrôle Kubernetes natif. Si le plan de contrôle n’est pas disponible, la charge de travail subit un temps d’arrêt. Tirez parti des fonctionnalités de fiabilité offertes par AKS :

  • Déployez des clusters AKS dans différentes régions Azure en tant qu’unité de mise à l’échelle pour optimiser la fiabilité et la disponibilité. Utilisez des zones de disponibilité pour optimiser la résilience au sein d’une région Azure en répartissant le plan de contrôle AKS et les nœuds de l’agent entre des centres de données physiquement distincts. Toutefois, si la latence de colocalisation est un problème, vous pouvez effectuer un déploiement AKS dans une zone unique ou utiliser des groupes de placement de proximité pour réduire la latence entre les nœuds.

  • Utilisez le contrat SLA de durée de fonctionnement AKS pour les clusters de production afin d’optimiser les garanties de disponibilité du point de terminaison de l’API Kubernetes.

Scalabilité

Prenez en compte les limites de mise à l’échelle AKS, comme le nombre de nœuds, de pools de nœuds par cluster et de clusters par abonnement.

Isolation

Maintenir les limites entre l’infrastructure utilisée par la charge de travail et les outils système. Le partage d’infrastructure peut entraîner une utilisation élevée des ressources et des scénarios de voisinage bruyants.

  • Utilisez des pools de nœuds distincts pour les services système et de charge de travail. Les pools de nœuds dédiés pour les composants de charge de travail doivent être basés sur des exigences pour les ressources d’infrastructure spécialisées telles que les machines virtuelles GPU à mémoire élevée. En général, pour réduire la surcharge de gestion inutile, évitez de déployer un grand nombre de pools de nœuds.

  • Utilisez des teintes et des tolérances pour fournir des nœuds dédiés et limiter les applications gourmandes en ressources.

  • Évaluez les exigences d’affinité et d’anti-affinité des applications et configurez la colocalisation appropriée des conteneurs sur les nœuds.

Sécurité

Kubernetes vanilla par défaut nécessite une configuration importante pour garantir une posture de sécurité appropriée pour les scénarios stratégiques. AKS traite tous les risques de sécurité. Les fonctionnalités incluent les clusters privés, l’audit et la connexion à Log Analytics, les images de nœud renforcées et les identités managées.

  • Appliquez les conseils de configuration fournis dans la base de référence de sécurité AKS.

  • Utilisez les fonctionnalités AKS pour gérer la gestion des identités et des accès de cluster afin de réduire la surcharge opérationnelle et d’appliquer une gestion cohérente des accès.

  • Utilisez des identités managées au lieu des principaux de service pour éviter la gestion et la rotation des informations d’identification. Vous pouvez ajouter des identités managées au niveau du cluster. Au niveau du pod, vous pouvez utiliser des identités managées via ID de charge de travail Microsoft Entra.

  • Utilisez l’intégration Microsoft Entra pour la gestion centralisée des comptes et les mots de passe, la gestion de l’accès aux applications et la protection renforcée des identités. Utilisez le RBAC Kubernetes avec l’ID de Microsoft Entra pour les privilèges minimum et réduisez l’octroi de privilèges d’administrateur pour protéger la configuration et l’accès aux secrets. En outre, limitez l’accès au fichier de configuration du cluster Kubernetes à l’aide du contrôle d’accès en fonction du rôle Azure. Limitez l’accès aux actions que les conteneurs peuvent effectuer, fournissez le moins d’autorisations et évitez l’utilisation de l’escalade des privilèges racine.

Mises à niveau

Les clusters et les nœuds doivent être mis à niveau régulièrement. AKS prend en charge les versions de Kubernetes en alignement avec le cycle de publication de Kubernetes natif.

  • Abonnez-vous à la feuille de route et aux notes de publicationAKS publiques sur GitHub pour rester à jour sur les modifications à venir, les améliorations et, plus important encore, les versions et les dépréciations de version kubernetes.

  • Appliquez les conseils fournis dans la liste de contrôle AKS pour garantir l’alignement sur les meilleures pratiques.

  • Tenez compte des différentes méthodes prises en charge par AKS pour la mise à jour des nœuds et/ou des clusters. Ces méthodes peuvent être manuelles ou automatisées. Vous pouvez utiliser la maintenance planifiée pour définir des fenêtres de maintenance pour ces opérations. De nouvelles images sont publiées chaque semaine. AKS prend également en charge les canaux de mise à niveau automatique pour la mise à niveau automatique des clusters AKS vers des versions plus récentes de Kubernetes et/ou des images de nœud plus récentes lorsqu’elles sont disponibles.

Mise en réseau

Évaluez les plug-ins réseau qui correspondent le mieux à votre cas d’usage. Déterminez si vous avez besoin d’un contrôle granulaire du trafic entre les pods. Azure prend en charge kubenet, Azure CNI et apportez votre propre CNI pour des cas d’usage spécifiques.

Hiérarchiser l’utilisation d’Azure CNI après avoir évalué la configuration réseau requise et la taille du cluster. Azure CNI permet d’utiliser des stratégies réseau Azure ou Calico pour contrôler le trafic au sein du cluster.

Surveillance

Vos outils de supervision doivent être en mesure de capturer des journaux et des métriques à partir de pods en cours d’exécution. Vous devez également collecter des informations à partir de l’API métriques Kubernetes pour surveiller l’intégrité des ressources et charges de travail en cours d’exécution.

Gouvernance

Utilisez des stratégies pour appliquer des protections centralisées aux clusters AKS de manière cohérente. Appliquez des affectations de stratégie à une étendue d’abonnement ou supérieure pour assurer la cohérence entre les équipes de développement.

  • Contrôler les fonctions accordées aux pods et déterminer si l’exécution contredit la stratégie à l’aide de Azure Policy. Cet accès est défini par le biais de stratégies intégrées fournies par le module complémentaire Azure Policy pour AKS.

  • Établissez une base de référence cohérente en matière de fiabilité et de sécurité pour les configurations de cluster et de pod AKS à l’aide de Azure Policy.

  • Utilisez le module complémentaire Azure Policy pour AKS pour contrôler les fonctions de pod, comme les privilèges racine, et pour interdire les pods qui ne sont pas conformes à la stratégie.

Notes

Lorsque vous déployez dans une zone d’atterrissage Azure, les stratégies Azure pour vous aider à garantir une fiabilité et une sécurité cohérentes doivent être fournies par l’implémentation de la zone d’atterrissage.

Les implémentations de référence stratégiques fournissent une suite de stratégies de base pour piloter les configurations de fiabilité et de sécurité recommandées.

Considérations et recommandations relatives à la conception de Azure App Service

Pour les scénarios de charge de travail web et basés sur l’API, App Service peut être une alternative possible à AKS. Il fournit une plateforme de conteneurs à faible friction sans la complexité de Kubernetes. Pour obtenir un ensemble complet de recommandations, consultez Considérations relatives à la fiabilité pour App Service et l’excellence opérationnelle pour App Service.

Fiabilité

Évaluer l’utilisation des ports TCP et SNAT. Les connexions TCP sont utilisées pour toutes les connexions sortantes. Les ports SNAT sont utilisés pour les connexions sortantes vers des adresses IP publiques. L’épuisement du port SNAT est un scénario d’échec courant. Vous devez détecter ce problème de manière prédictive en testant la charge tout en utilisant Diagnostics Azure pour surveiller les ports. Si des erreurs SNAT se produisent, vous devez effectuer une mise à l’échelle sur des workers plus ou plus importants, ou implémenter des pratiques de codage pour aider à préserver et réutiliser les ports SNAT. Parmi les exemples de pratiques de codage que vous pouvez utiliser, citons le regroupement de connexions et le chargement paresseux des ressources.

L’épuisement des ports TCP est un autre scénario d’échec. Il se produit lorsque la somme des connexions sortantes d’un worker donné dépasse la capacité. Le nombre de ports TCP disponibles dépend de la taille du worker. Pour obtenir des recommandations, consultez Ports TCP et SNAT.

Scalabilité

Planifiez les futures exigences de scalabilité et la croissance des applications afin de pouvoir appliquer les recommandations appropriées dès le début. Ce faisant, vous pouvez éviter la dette de migration technique à mesure que la solution augmente.

  • Activez la mise à l’échelle automatique pour vous assurer que des ressources adéquates sont disponibles pour les demandes de service. Évaluez la mise à l’échelle par application pour l’hébergement à haute densité sur App Service.

  • N’oubliez pas que App Service a une limite réversible d’instances par défaut par App Service plan.

  • Appliquez des règles de mise à l’échelle automatique. Un plan de App Service est mis à l’échelle si une règle au sein du profil est respectée, mais n’est mise à l’échelle que si toutes les règles du profil sont remplies. Utilisez une combinaison de règles de scale-out et de scale-in pour vous assurer que la mise à l’échelle automatique peut prendre des mesures à la fois pour effectuer un scale-out et un scale-in. Comprendre le comportement de plusieurs règles de mise à l’échelle dans un seul profil.

  • N’oubliez pas que vous pouvez activer la mise à l’échelle par application au niveau du plan App Service pour permettre à une application de s’adapter indépendamment du plan App Service qui l’héberge. Les applications sont allouées aux nœuds disponibles via une approche optimale pour une distribution uniforme. Bien qu’une distribution uniforme ne soit pas garantie, la plateforme garantit que deux instances de la même application ne sont pas hébergées sur la même instance.

Surveillance

Surveillez le comportement de l’application et accédez aux journaux et aux métriques pertinents pour vous assurer que votre application fonctionne comme prévu.

  • Vous pouvez utiliser la journalisation des diagnostics pour ingérer des journaux au niveau de l’application et au niveau de la plateforme dans Log Analytics, Stockage Azure ou un outil tiers via Azure Event Hubs.

  • L’analyse des performances des applications avec Application Insights fournit des informations approfondies sur les performances des applications.

  • Les applications stratégiques doivent avoir la capacité d’autoréparer en cas de défaillances. Activez la réparation automatique pour recycler automatiquement les travailleurs défectueux.

  • Vous devez utiliser les contrôles d’intégrité appropriés pour évaluer toutes les dépendances critiques en aval, ce qui permet de garantir l’intégrité globale. Nous vous recommandons vivement d’activer le contrôle d’intégrité pour identifier les travailleurs non réactifs.

Déploiement

Pour contourner la limite par défaut d’instances par App Service plan, déployez App Service plans dans plusieurs unités d’échelle dans une seule région. Déployez App Service plans dans une configuration de zone de disponibilité pour vous assurer que les nœuds Worker sont distribués entre les zones d’une région. Envisagez d’ouvrir un ticket de support pour augmenter le nombre maximal de workers à deux fois le nombre instance dont vous avez besoin pour traiter la charge de pointe normale.

Registre de conteneurs

Les registres de conteneurs hébergent des images déployées dans des environnements d’exécution de conteneur comme AKS. Vous devez configurer soigneusement vos registres de conteneurs pour les charges de travail stratégiques. Une panne ne doit pas entraîner de retards dans l’extraction des images, en particulier pendant les opérations de mise à l’échelle. Les considérations et recommandations suivantes se concentrent sur Azure Container Registry et explorent les compromis associés aux modèles de déploiement centralisés et fédérés.

Considérations en matière de conception

  • Format. Envisagez d’utiliser un registre de conteneurs qui s’appuie sur le format et les normes fournis par Docker pour les opérations push et pull. Ces solutions sont compatibles et pour la plupart interchangeables.

  • Modèle de déploiement. Vous pouvez déployer le registre de conteneurs en tant que service centralisé qui est consommé par plusieurs applications au sein de votre organization. Vous pouvez également le déployer en tant que composant dédié pour une charge de travail d’application spécifique.

  • Registres publics. Les images conteneur sont stockées dans Docker Hub ou d’autres registres publics qui existent en dehors d’Azure et d’un réseau virtuel donné. Ce n’est pas nécessairement un problème, mais cela peut entraîner divers problèmes liés à la disponibilité du service, à la limitation et à l’exfiltration des données. Pour certains scénarios d’application, vous devez répliquer des images de conteneur public dans un registre de conteneurs privé pour limiter le trafic de sortie, augmenter la disponibilité ou éviter une limitation potentielle.

Recommandations de conception

  • Utilisez des instances de Registre de conteneurs qui sont dédiées à la charge de travail de l’application. Évitez de créer une dépendance sur un service centralisé, sauf si les exigences de disponibilité et de fiabilité de l’organisation sont entièrement alignées sur l’application.

    Dans le modèle d’architecture de base recommandé, les registres de conteneurs sont des ressources globales qui sont de longue durée de vie. Envisagez d’utiliser un registre de conteneurs global unique par environnement. Par exemple, utilisez un registre de production global.

  • Assurez-vous que le contrat SLA pour le registre public est aligné sur vos objectifs de fiabilité et de sécurité. Notez particulièrement les limites de limitation pour les cas d’usage qui dépendent de Docker Hub.

  • Hiérarchiser les Azure Container Registry pour l’hébergement d’images conteneur.

Considérations et recommandations relatives à la conception de Azure Container Registry

Ce service natif fournit une gamme de fonctionnalités, notamment la géoréplication, l’authentification Microsoft Entra, la génération automatisée de conteneurs et la mise à jour corrective via des tâches Container Registry.

Fiabilité

Configurez la géoréplication dans toutes les régions de déploiement pour supprimer les dépendances régionales et optimiser la latence. Container Registry prend en charge la haute disponibilité par le biais de la géoréplication dans plusieurs régions configurées, offrant ainsi une résilience contre les pannes régionales. Si une région devient indisponible, les autres régions continuent de traiter les demandes d’image. Lorsque la région est de nouveau en ligne, Container Registry récupère et réplique les modifications apportées à celle-ci. Cette fonctionnalité assure également une colocation du registre au sein de chaque région configurée, ce qui réduit la latence réseau et les coûts de transfert de données entre régions.

Dans les régions Azure qui fournissent une prise en charge des zones de disponibilité, le niveau Premium Container Registry prend en charge la redondance de zone pour fournir une protection contre les défaillances zonales. Le niveau Premium prend également en charge les points de terminaison privés pour empêcher l’accès non autorisé au Registre, ce qui peut entraîner des problèmes de fiabilité.

Héberger des images proches des ressources de calcul consommatrices, dans les mêmes régions Azure.

Verrouillage d’images

Les images peuvent être supprimées, par exemple à la suite d’une erreur manuelle. Container Registry prend en charge le verrouillage d’une version d’image ou d’un dépôt pour empêcher les modifications ou les suppressions. Lorsqu’une version d’image précédemment déployée est modifiée en place, les déploiements de même version peuvent fournir des résultats différents avant et après la modification.

Si vous souhaitez protéger le instance container Registry contre la suppression, utilisez des verrous de ressources.

Images étiquetées

Les images Conteneur Registry étiquetées sont mutables par défaut, ce qui signifie que la même balise peut être utilisée sur plusieurs images envoyées au Registre. Dans les scénarios de production, cela peut entraîner un comportement imprévisible qui pourrait affecter la durée de fonctionnement de l’application.

Gestion de l’identité et de l’accès

Utilisez Microsoft Entra’authentification intégrée pour envoyer et extraire des images au lieu de s’appuyer sur des clés d’accès. Pour une sécurité renforcée, désactivez entièrement l’utilisation de la clé d’accès d’administrateur.

Calcul serverless

L’informatique serverless fournit des ressources à la demande et élimine la nécessité de gérer l’infrastructure. Le fournisseur de cloud provisionne, met à l’échelle et gère automatiquement les ressources nécessaires pour exécuter le code d’application déployé. Azure fournit plusieurs plateformes de calcul serverless :

  • Azure Functions. Lorsque vous utilisez Azure Functions, la logique d’application est implémentée en tant que blocs de code distincts, ou fonctions, qui s’exécutent en réponse à des événements, comme une requête HTTP ou un message de file d’attente. Chaque fonction est mise à l’échelle en fonction des besoins pour répondre à la demande.

  • Azure Logic Apps. Logic Apps est le mieux adapté à la création et à l’exécution de workflows automatisés qui intègrent divers systèmes, applications, sources de données et services. Comme Azure Functions, Logic Apps utilise des déclencheurs intégrés pour le traitement piloté par les événements. Toutefois, au lieu de déployer du code d’application, vous pouvez créer des applications logiques à l’aide d’une interface utilisateur graphique qui prend en charge les blocs de code tels que les conditions et les boucles.

  • Azure API Management : Vous pouvez utiliser Gestion des API pour publier, transformer, gérer et surveiller les API de sécurité renforcée à l’aide du niveau Consommation.

  • Power Apps et Power Automate. Ces outils fournissent une expérience de développement à faible code ou sans code, avec une logique de flux de travail simple et des intégrations configurables via des connexions dans une interface utilisateur.

Pour les applications critiques, les technologies serverless fournissent un développement et des opérations simplifiés, ce qui peut être utile pour des cas d’usage métier simples. Toutefois, cette simplicité se fait au détriment de la flexibilité en termes de scalabilité, de fiabilité et de performances, ce qui n’est pas viable pour la plupart des scénarios d’application critiques.

Les sections suivantes fournissent des considérations et des recommandations de conception pour l’utilisation de Azure Functions et Logic Apps en tant que plateformes alternatives pour les scénarios de flux de travail non critiques.

Considérations et recommandations relatives à la conception de Azure Functions

Les charges de travail critiques ont des flux système critiques et non critiques. Azure Functions est un choix viable pour les flux qui n’ont pas les mêmes exigences métier strictes que les flux système critiques. Il est bien adapté aux flux pilotés par les événements qui ont des processus de courte durée, car les fonctions effectuent des opérations distinctes qui s’exécutent aussi rapidement que possible.

Choisissez une option d’hébergement Azure Functions adaptée au niveau de fiabilité de l’application. Nous recommandons le plan Premium, car il vous permet de configurer la taille de calcul instance. Le plan dédié est l’option serverless la moins. Il fournit une mise à l’échelle automatique, mais ces opérations de mise à l’échelle sont plus lentes que celles des autres plans. Nous vous recommandons d’utiliser le plan Premium pour optimiser la fiabilité et les performances.

Il existe des considérations relatives à la sécurité. Lorsque vous utilisez un déclencheur HTTP pour exposer un point de terminaison externe, utilisez un pare-feu d’applications web (WAF) pour fournir un niveau de protection pour le point de terminaison HTTP contre les vecteurs d’attaque externes courants.

Nous vous recommandons d’utiliser des points de terminaison privés pour restreindre l’accès aux réseaux virtuels privés. Ils peuvent également atténuer les risques d’exfiltration de données, comme les scénarios d’administration malveillants.

Vous devez utiliser des outils d’analyse du code sur Azure Functions code et intégrer ces outils à des pipelines CI/CD.

Considérations et recommandations relatives à la conception pour Azure Logic Apps

Comme Azure Functions, Logic Apps utilise des déclencheurs intégrés pour le traitement piloté par les événements. Toutefois, au lieu de déployer du code d’application, vous pouvez créer des applications logiques à l’aide d’une interface utilisateur graphique qui prend en charge les blocs tels que les conditions, les boucles et d’autres constructions.

Plusieurs modes de déploiement sont disponibles. Nous recommandons le mode Standard pour garantir un déploiement à locataire unique et atténuer les scénarios de voisins bruyants. Ce mode utilise le runtime Logic Apps monolocataire conteneurisé, qui est basé sur Azure Functions. Dans ce mode, l’application logique peut avoir plusieurs workflows avec état et sans état. Vous devez connaître les limites de configuration.

Migrations contraintes via IaaS

De nombreuses applications qui ont des déploiements locaux existants utilisent des technologies de virtualisation et du matériel redondant pour fournir des niveaux de fiabilité critiques. La modernisation est souvent entravée par des contraintes métier qui empêchent l’alignement complet avec le modèle d’architecture de base de référence native cloud (North Star) recommandé pour les charges de travail critiques. C’est pourquoi de nombreuses applications adoptent une approche progressive, avec des déploiements cloud initiaux utilisant la virtualisation et Azure Machines Virtuelles comme modèle d’hébergement d’application principal. L’utilisation de machines virtuelles IaaS peut être nécessaire dans certains scénarios :

  • Les services PaaS disponibles ne fournissent pas les performances ou le niveau de contrôle requis.
  • La charge de travail nécessite un accès au système d’exploitation, des pilotes spécifiques ou des configurations réseau et système.
  • La charge de travail ne prend pas en charge l’exécution dans les conteneurs.
  • Il n’existe aucun support fournisseur pour les charges de travail tierces.

Cette section se concentre sur les meilleures façons d’utiliser Azure Machines Virtuelles et les services associés pour optimiser la fiabilité de la plateforme d’application. Il met en évidence les aspects clés de la méthodologie de conception critique qui transposent les scénarios de migration natifs cloud et IaaS.

Considérations en matière de conception

  • Les coûts opérationnels liés à l’utilisation de machines virtuelles IaaS sont considérablement plus élevés que ceux liés à l’utilisation des services PaaS en raison des exigences de gestion des machines virtuelles et des systèmes d’exploitation. La gestion des machines virtuelles nécessite le déploiement fréquent de packages logiciels et de mises à jour.

  • Azure fournit des fonctionnalités permettant d’augmenter la disponibilité des machines virtuelles :

    • Les groupes à haute disponibilité peuvent vous protéger contre les pannes de réseau, de disque et d’alimentation en distribuant les machines virtuelles entre les domaines d’erreur et les domaines de mise à jour.
    • Les zones de disponibilité peuvent vous aider à atteindre des niveaux de fiabilité encore plus élevés en distribuant des machines virtuelles entre des centres de données physiquement séparés au sein d’une région.
    • Virtual Machine Scale Sets fournir des fonctionnalités permettant de mettre automatiquement à l’échelle le nombre de machines virtuelles d’un groupe. Ils fournissent également des fonctionnalités permettant de surveiller instance’intégrité et de réparer automatiquement les instances non saines.

Recommandations de conception

Important

Utilisez les services et conteneurs PaaS lorsque cela est possible pour réduire la complexité opérationnelle et les coûts. Utilisez des machines virtuelles IaaS uniquement lorsque vous en avez besoin.

  • Taille appropriée des tailles de référence SKU de machine virtuelle pour garantir une utilisation efficace des ressources.

  • Déployez au moins trois machines virtuelles sur des zones de disponibilité pour atteindre la tolérance de panne au niveau du centre de données.

    • Si vous déployez des logiciels commerciaux prêts à l’emploi, consultez l’éditeur de logiciels et testez correctement avant de déployer le logiciel en production.

  • Pour les charges de travail qui ne peuvent pas être déployées dans des zones de disponibilité, utilisez des groupes à haute disponibilité qui contiennent au moins trois machines virtuelles.

    • Considérez les groupes à haute disponibilité uniquement si les zones de disponibilité ne répondent pas aux exigences de charge de travail, par exemple pour les charges de travail bavardes avec des exigences de faible latence.

  • Hiérarchiser l’utilisation de Virtual Machine Scale Sets pour la scalabilité et la redondance de zone. Ce point est particulièrement important pour les charges de travail qui ont des charges variables. Par exemple, si le nombre d’utilisateurs actifs ou de demandes par seconde est une charge variable.

  • N’accédez pas directement aux machines virtuelles individuelles. Utilisez des équilibreurs de charge devant eux lorsque cela est possible.

  • Pour vous protéger contre les pannes régionales, déployez des machines virtuelles d’application dans plusieurs régions Azure.

  • Pour les charges de travail qui ne prennent pas en charge les déploiements actifs/actifs multirégions, envisagez d’implémenter des déploiements actifs/passifs à l’aide de machines virtuelles de secours à chaud/à chaud pour le basculement régional.

  • Utilisez des images standard de Place de marché Azure plutôt que des images personnalisées qui doivent être conservées.

  • Implémentez des processus automatisés pour déployer et déployer des modifications sur des machines virtuelles, en évitant toute intervention manuelle. Pour plus d’informations, consultez Considérations iaaS dans la zone de conception Procédures opérationnelles .

  • Implémentez des expériences de chaos pour injecter des erreurs d’application dans les composants de la machine virtuelle et observer l’atténuation des erreurs. Pour plus d’informations, consultez Validation et test continus.

  • Surveillez les machines virtuelles et assurez-vous que les journaux et les métriques de diagnostic sont ingérés dans un récepteur de données unifié.

  • Implémentez des pratiques de sécurité pour les scénarios d’application critiques, le cas échéant, et les meilleures pratiques de sécurité pour les charges de travail IaaS dans Azure.

Étape suivante

Passez en revue les considérations relatives à la plateforme de données.

Plateforme de données