Déploiement d’entreprise haute disponibilité avec App Services Environment

Les zones de disponibilité sont des regroupements de centres de données séparés physiquement dans une région donnée. Le déploiement de ressources sur plusieurs zones garantit que les pannes limitées à une zone n’affectent pas la disponibilité de vos applications. Cette architecture décrit comment améliorer la résilience d’un déploiement App Service Environment en le déployant dans une architecture redondante interzone. Ces zones ne sont pas liées à la proximité. Elles peuvent être mappées à différents emplacements physiques pour différents abonnements. Cette architecture suppose un déploiement avec un seul abonnement.

Quand vous configurez la redondance de zone pour App Service Environment, la plateforme déploie automatiquement les instances du plan Azure App Service sur les trois zones de la région sélectionnée. Par conséquent, le nombre minimal d’instances du plan App Service est toujours de trois.

Les services Azure qui prennent en charge les zones de disponibilité peuvent être zonaux et/ou redondants interzones. Les services zonaux peuvent être affectés à une zone en particulier. Les services redondants interzones peuvent être automatiquement déployés entre les zones. Pour obtenir des conseils et des recommandations détaillés, consultez l’article sur la prise en charge des zones de disponibilité. La précédente version d’App Service Environment (v2) ne prenait en charge que les déploiements zonaux. L’actuelle version (v3) prend en charge les déploiements redondants interzones.

Une implémentation de référence de cette architecture est disponible sur GitHub.

Architecture

Téléchargez un fichier Visio de cette architecture.

Les ressources dans les sous-réseaux App Service Environment de cette implémentation de référence sont les mêmes que celles de l’architecture de déploiement App Service Environment standard. Cette implémentation de référence utilise les fonctionnalités redondantes interzones d’App Service Environment v3 et Azure Cache pour Redis pour fournir une disponibilité plus élevée. Notez que l’étendue de cette architecture de référence est limitée à une seule région.

Workflow

La section suivante décrit la nature de la disponibilité des services utilisés dans cette architecture :

• App Service Environment v3 peut être configuré pour la redondance de zone. Vous pouvez configurer la redondance de zone uniquement lors de la création d’App Service Environment et seulement dans les régions qui prennent en charge toutes les dépendances App Service Environment v3. Chaque plan App Service d’un App Service Environment redondant interzone doit avoir au minimum trois instances pour être déployé dans trois zones. Le coût minimal est prévu pour neuf instances. Pour plus d’informations, consultez le guide de tarification. Pour obtenir des instructions et des recommandations détaillées, consultez l’article Prise en charge d’App Service Environment pour les zones de disponibilité.

• Le réseau virtuel Azure couvre toutes les zones de disponibilité qui se trouvent dans une même région. Les sous-réseaux du réseau virtuel traversent également les zones de disponibilité. Pour plus d’informations, consultez la configuration réseau requise pour App Service Environment.

• Application Gateway v2 est redondant interzone. À l’instar du réseau virtuel, il s’étend sur plusieurs zones de disponibilité par région. De ce fait, une seule passerelle d’application est suffisante pour un système à haut niveau de disponibilité, comme indiqué dans l’architecture de référence. L’architecture de référence utilise la référence SKU WAF d’Application Gateway, qui offre une protection accrue contre les menaces et vulnérabilités courantes basée sur une implémentation de l’ensemble de règles de base (CRS) du projet OWASP (Open Web Application Security Project). Pour plus d’informations, consultez l’article Mettre à l’échelle Application Gateway v2 et WAF v2.

• Le Pare-feu Azure offre une prise en charge intégrée de la haute disponibilité. Elle peut traverser plusieurs zones sans aucune configuration supplémentaire.

  Si nécessaire, vous pouvez également configurer une zone de disponibilité spécifique lorsque vous déployez le pare-feu. Pour plus d’informations, consultez l’article Pare-feu et zones de disponibilité Azure. (Cette configuration n’est pas utilisée dans l’architecture de référence.)

• Microsoft Entra ID est un service global hautement disponible et hautement redondant, couvrant des zones de disponibilité et des régions. Pour plus d’informations, consultez Progression de la disponibilité de Microsoft Entra.

• GitHub Actions fournit des fonctionnalités d’intégration continue et de déploiement continu (CI/CD) dans cette architecture. App Service Environment se trouve dans le réseau virtuel. Une machine virtuelle doit donc être utilisée comme jumpbox dans le réseau virtuel pour déployer les applications dans les plans App Service. L’action génère les applications en dehors du réseau virtuel. Pour une sécurité renforcée et une connectivité RDP/SSH fluide, envisagez d’utiliser la nouvelle version d’Azure Bastion pour la jumpbox.

• Azure Cache pour Redis est un service redondant interzone. Un cache redondant interzone s’exécute sur des machines virtuelles déployées dans plusieurs zones de disponibilité. Ce service offre une résilience et une disponibilité plus élevées.

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.

Disponibilité

Environnement App Service

Vous pouvez déployer App Service Environment sur plusieurs zones de disponibilité pour assurer la résilience et la fiabilité de vos charges de travail vitales pour l’entreprise. Cette configuration est également appelée redondance de zone.

Quand vous implémentez la redondance de zone, la plateforme déploie automatiquement les instances du plan App Service sur les trois zones de la région sélectionnée. Par conséquent, le nombre minimal d’instances du plan App Service est toujours de trois. Si vous spécifiez une capacité supérieure à trois et que le nombre d’instances est divisible par trois, les instances sont déployées de manière égale. Sinon, les instances restantes sont toutes ajoutées à la zone restante ou déployées sur les deux autres zones.

• Vous configurez des zones de disponibilité lorsque vous créez votre environnement App Service Environment.
• Tous les plans App Service créés dans cet App Service Environment nécessitent au moins trois instances. Ils seront automatiquement redondants interzones.
• Vous pouvez spécifier les zones de disponibilité uniquement lors de la création d’un App Service Environment. Vous ne pouvez pas convertir un App Service Environment préexistant pour utiliser des zones de disponibilité.
• Les zones de disponibilité ne sont prises en charge que dans un sous-ensemble de régions.

Pour plus d’informations, consultez Migrer un environnement App Service Environment vers la prise en charge des zones de disponibilité.

Résilience

Les applications qui s’exécutent dans App Service Environment forment le pool back-end pour Application Gateway. Lorsqu’une requête adressée à l’application provient de l’Internet public, la passerelle la transfère à l’application en cours d’exécution dans App Service Environment. Cette architecture de référence implémente des contrôles d’intégrité dans le serveur web front-end principal, votingApp. Cette sonde d’intégrité vérifie si l’API Web et le cache Redis sont intègres. Vous pouvez afficher le code qui implémente cette sonde dans Startup.cs :

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

L’extrait de code suivant décrit comment le script commands_ha.azcli configure les pools back-end et la sonde d’intégrité pour la passerelle applicative :

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Si l’un des composants (le serveur web front-end, l’API ou le cache) échoue à la sonde d’intégrité, Application Gateway achemine la requête vers l’autre application du pool back-end. Cette configuration garantit que la requête est toujours routée vers l’application dans un sous-réseau App Service Environment entièrement disponible.

La sonde d’intégrité est également implémentée dans l’implémentation de référence standard. La passerelle renvoie simplement une erreur en cas d’échec de la sonde d’intégrité. Toutefois, une implémentation hautement disponible améliore la résilience de l’application et la qualité de l’expérience utilisateur.

Optimisation des coûts

L’optimisation des coûts consiste à réduire les dépenses inutiles et à améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Les considérations relatives au coût de l’architecture de haute disponibilité sont similaires à celles du déploiement standard.

Les différences suivantes peuvent avoir une incidence sur le coût :

• Vous serez facturé pour un minimum de neuf instances de plan App Service dans un App Service Environment redondant interzone. Pour plus d’informations, consultez les tarifs App Service Environment.
• Azure Cache pour Redis est un service redondant interzone. Un cache redondant interzone s’exécute sur des machines virtuelles déployées sur plusieurs zones de disponibilité pour assurer un niveau élevé de résilience et de disponibilité.

Le compromis pour un système hautement disponible, résilient et hautement sécurisé est un coût accru. Utilisez la calculatrice de prix pour évaluer vos besoins en termes de tarification.

Considérations en matière de déploiement

Cette implémentation de référence utilise le même pipeline CI/CD de production que le déploiement standard, avec une seule machine virtuelle jumpbox. Toutefois, vous pouvez décider d’utiliser une seule jumpbox pour chacune des trois zones. Cette architecture utilise une seule jumpbox, car elle n’affecte pas la disponibilité de l’application. La jumpbox est utilisée uniquement pour le déploiement et les tests.

Déployer ce scénario

Pour en savoir plus sur le déploiement de l’implémentation de référence de cette architecture, consultez le fichier Readme de GitHub. Utilisez le script pour le déploiement à haute disponibilité.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Deep Bhattacharya | Architecte de solutions cloud
• Suhas Rao | Architecte de solutions cloud

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Vous pouvez modifier cette architecture et mettre à l’échelle horizontalement vos applications dans la même région ou dans plusieurs régions, en fonction de la capacité de charge maximale attendue. La réplication de vos applications sur plusieurs régions peut aider à atténuer les risques de défaillance des centres de données géographiques plus larges, comme ceux liés aux tremblements de terre ou autres catastrophes naturelles. Pour en savoir plus sur la mise à l’échelle horizontale, consultez l’article Mise à l’échelle géolocalisée avec App Service Environment. Pour une solution de routage globale et hautement disponible, envisagez d’utiliser Azure Front Door.