Applications cloud évolutives et ingénierie de fiabilité du site (SRE)

Azure Front Door
Gestion des API Azure
Azure Kubernetes Service (AKS)
Application Gateway Azure

Le succès de votre solution cloud dépend de sa fiabilité. La fiabilité est la probabilité que le système fonctionne comme prévu, dans des conditions spécifiées, dans un délai spécifié. L’ingénierie de fiabilité du site (SRE) est un ensemble de principes et de pratiques pour créer des systèmes logiciels évolutifs et hautement fiables. SRE est une approche standard pour concevoir des services numériques afin de prendre en charge les objectifs de fiabilité dans votre charge de travail.

Cet article montre comment appliquer des principes SRE à une plateforme d’API évolutive. Cette architecture définit des indicateurs de niveau de service (SLA) et des objectifs de niveau de service (SLA), des modèles de mise à l’échelle et des attentes en matière de performances, et établit des pratiques de surveillance. Ces techniques permettent de garantir une fiabilité mesurable et réalisable.

Pour plus d’informations, consultez Développer une stratégie SRE.

Architecture

Diagramme montrant une plateforme d’API évolutive.

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

Flux de données

Le flux de données suivant correspond au diagramme précédent :

  1. Les applications clientes telles que les applications web, les applications mobiles et les applications de service envoient des demandes au point de terminaison https://api.contoso.comunifié.

  2. Azure Front Door reçoit toutes les demandes entrantes et fournit la terminaison SSL (Secure Sockets Layer) et la protection de pare-feu d'application web Azure.

  3. Azure Front Door achemine les requêtes vers Gestion des API Azure, qui applique des stratégies pour le contrôle d’accès, la limitation du débit, la mise en cache et la transformation de requête.

  4. Gestion des API transfère les demandes à Application Gateway pour conteneurs, qui équilibrent la charge du trafic sur le cluster AKS.

  5. Le microservice approprié dans AKS traite la requête. Les microservices incluent des services de produit, de profil, de commandes et de paiement et de contenu. Chaque microservice émet des données de télémétrie qui contribuent aux calculs SLI pour la disponibilité, la latence et le débit.

  6. Les microservices accèdent aux magasins de données principaux en fonction des besoins :

    • Azure Cosmos DB pour les données à faible latence distribuées à l’échelle mondiale
    • Azure SQL pour les données relationnelles
    • Stockage Azure et Azure Data Lake Storage pour le contenu et les fichiers non structurés

  7. Microsoft Entra ID authentifie et autorise les utilisateurs et les principaux de service tout au long du flux de requête.

  8. Azure Monitor et Application Insights collectent les données de télémétrie indépendamment à chaque couche :

    • Métriques de requête Azure Front Door
    • Exécution de la stratégie Gestion des API
    • Répartition de charge de l'Application Gateway pour conteneurs
    • Métriques au niveau du pod AKS
    • Temps de réponse du stockage de données

    Les équipes SRE utilisent une collecte par niveau pour calculer les SLIs composites, identifier les sources de dégradation et suivre le respect des SLO.

  9. La réponse traverse par le même chemin jusqu'à l’application cliente.

Cette architecture représente une plateforme d’API évolutive. La solution comprend plusieurs microservices qui utilisent différentes bases de données et services de stockage.

L’exemple de scénario couvre les cas d’usage de la place de marché et du commerce électronique de haut niveau :

  • Navigation du produit
  • Inscription et connexion
  • Affichage de contenu, tel que des articles d’actualités
  • Gestion des commandes et des abonnements

Les applications clientes telles que les applications web, les applications mobiles et les applications de service consomment les services de plateforme d’API par le biais d’un chemin d’accès unifié. https://api.contoso.com

Composants

  • Azure Front Door est un service de réseau de distribution de contenu cloud moderne qui utilise le réseau de périphérie mondial Microsoft pour créer des applications web évolutives. Dans cette architecture, elle sert de point d’entrée unique pour toutes les demandes clientes. Il fournit une terminaison SSL et applique des règles de pare-feu d’applications web Azure avant d’acheminer le trafic vers gestion des API. Pour plus d’informations, consultez Vue d’ensemble de l’architecture de routage.

  • Gestion des API est un service de passerelle d’API managé qui fournit une plateforme de gestion hybride multicloud pour les API dans tous les environnements. Dans cette architecture, elle fonctionne comme passerelle d’API. Il applique des stratégies de contrôle d’accès, applique la limitation du débit, met en cache les réponses à l’aide d’Azure Managed Redis en tant que cache externe et transforme les demandes avant de les transférer aux services principaux. API Management prend en charge l’autoscaling dans les niveaux Standard et Premium.

  • AKS est un service d’orchestration de conteneurs managé qui fournit une plateforme Kubernetes pour l’exécution d’applications conteneurisées. Dans cette architecture, elle héberge tous les microservices, y compris les services de produit, de profil, de commandes et de paiement et de contenu. Azure gère le plan de contrôle et vous gérez les nœuds de l’agent.

  • Application Gateway pour conteneurs est un équilibreur de charge d’application qui fournit une gestion dynamique du trafic pour les charges de travail qui s’exécutent dans un cluster Kubernetes. Dans cette architecture, elle fournit un équilibrage de charge de couche 7 pour le trafic qui entre dans le cluster AKS. Il distribue les requêtes de Gestion des API sur les pods de microservice.

  • Azure Cosmos DB est un service de base de données noSQL et relationnel managé qui dispose d’une distribution globale et d’une scalabilité automatique. Dans cette architecture, il stocke le catalogue de produits et les données de profil qui nécessitent un accès à faible latence et distribué globalement. La mise à l’échelle automatique du débit ajuste les capacités en fonction de la demande.

  • Azure SQL est une famille de services de base de données relationnelle managés qui utilisent le moteur de base de données SQL Server dans Azure. Dans cette architecture, elle stocke les données relationnelles pour les commandes, les abonnements et les enregistrements transactionnels.

  • Stockage Azure est un service de stockage cloud qui comprend des objets, des fichiers, des disques, une file d’attente et un stockage de tables. Azure Data Lake Storage est un service data lake hautement évolutif pour les charges de travail d’analytique hautes performances. Dans cette architecture, ces services stockent du contenu non structuré, tel que des ressources multimédias, des documents et des fichiers.

  • Microsoft Entra ID est un service de gestion des identités et des accès cloud qui authentifie et autorise les utilisateurs à accéder aux ressources. Dans cette architecture, elle fournit une gestion centralisée des identités et des accès pour les utilisateurs et les principaux de service dans tous les services.

  • Azure Monitor est un service d’observabilité permettant de collecter, d’analyser et de répondre aux données de surveillance à partir de vos environnements cloud et locaux. Application Insights est une extension d’Azure Monitor qui fournit des fonctionnalités de surveillance des performances des applications (APM). Dans cette architecture, ces services collectent les données de télémétrie entre toutes les couches. Ils calculent les SLA, effectuent le suivi de la conformité SLO et fournissent des tableaux de bord pour les alertes proactives. Azure Monitor prend en charge OpenTelemetry et s’intègre à Azure Managed Grafana pour le suivi et la visualisation distribués.

  • Azure Chaos Studio est un service d’ingénierie de chaos managé qui permet de mesurer, de comprendre et d’améliorer votre application cloud et votre résilience de service. Dans cette architecture, elle injecte des erreurs et valide la résilience du système pendant les tests de résilience et de récupération.

Autres solutions

Pour le plan de calcul, envisagez les éléments suivants :

  • Azure Container Apps pour les microservices et les charges de travail pilotées par les événements. Il prend en charge les conteneurs serverless et la mise à l’échelle automatique basée sur KEDA sans nécessiter la gestion du cluster Kubernetes. Ce choix remplace AKS et Application Gateway pour conteneurs, car Container Apps fournit une entrée intégrée.

  • Application web pour conteneurs pour les équipes familiarisées avec App Service qui n’ont besoin que d’une entrée HTTP/HTTPS. Ce choix remplace AKS et Application Gateway pour conteneurs par une plateforme entièrement managée, mais fournit un contrôle de mise à l’échelle moins granulaire.

  • Azure Functions pour les services d’API serverless où vous pouvez déployer des points de terminaison d’API individuels en tant que fonctions indépendantes. Ce choix remplace le modèle de microservice par des fonctions par point de terminaison et convient aux API pilotées par les événements ou à faible trafic.

Pour la couche de données, envisagez Microsoft Fabric avec la mise en miroir Azure Cosmos DB lorsque vous avez besoin d’analyses sur les données opérationnelles. Fabric ajoute une couche de rapports et d'analytique aux côtés des magasins transactionnels existants sans consommer d’unités de requête.

Détails du scénario

Cet exemple de scénario montre comment appliquer des pratiques SRE à une plateforme d’API évolutive qui gère les cas d’usage de la Place de marché et du commerce électronique. L’article se concentre sur la façon de définir les SLIs et SLOs, modeler les attentes en matière de mise à l'échelle et de performance, et utiliser ces résultats pour établir la surveillance et l'alerte.

Cas d’usage potentiels

Les concepts décrits dans cet article s’appliquent aux éléments suivants :

  • Services cloud basés sur des API.
  • Applications web accessibles au public.
  • Charges de travail basées sur Internet des objets (IoT) ou basées sur des événements.
  • Plateformes de commerce électronique avec navigation, inscription et gestion des commandes de produits.
  • Applications de distribution de contenu pour les articles d’actualités et les médias.

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 Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

Votre contexte métier détermine vos exigences de fiabilité. Les pratiques SRE vous aident à atteindre le niveau de fiabilité approprié. Vous mesurez la fiabilité par le biais des SLO, qui définissent des cibles exprimées sous forme de pourcentages sur des périodes de temps. Les Indicateurs de Niveau de Service (SLI) sont les métriques que vous mesurez pour déterminer les Objectifs de Niveau de Service (SLO), en fonction de l'expérience client. Pour plus d’informations, consultez Définir des métriques SLI pour calculer des SLO.

Cette architecture intègre plusieurs modèles de fiabilité :

  • Redondance de zone : Azure Front Door, Application Gateway pour conteneurs et AKS prennent en charge le déploiement de zones de disponibilité pour la haute disponibilité au sein d’une région.

  • Mise à l’échelle automatique : Azure Front Door est mis à l’échelle automatiquement en fonction du volume de trafic. Application Gateway pour conteneurs ajuste automatiquement ses unités de capacité. AKS utilise l'autoscaler de cluster pour les nœuds et l'autoscaler horizontal de pods pour les pods. API Management prend en charge l’autoscaling dans les niveaux Standard et Premium. Le débit de mise à l’échelle automatique d’Azure Cosmos DB s’ajuste en fonction de la consommation d’unités de requête. Ces fonctionnalités aident le système à gérer les variations de charge sans intervention manuelle.

  • Surveillance de l’intégrité : Utilisez Azure Monitor et Application Insights pour suivre les SLI et les SLO et identifier proactivement les problèmes de fiabilité.

  • Test de résilience et de récupération : Utilisez Chaos Studio pour valider la tolérance de panne et les procédures de récupération.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

Cette architecture traite de la sécurité via plusieurs couches :

  • Gestion des identités et des accès : Microsoft Entra ID fournit une gestion centralisée des identités pour les utilisateurs et les principaux de service.

  • Sécurité réseau : Le Pare-feu d’applications web Azure, intégré à Azure Front Door, offre une protection contre les attaques web courantes, y compris les 10 principales vulnérabilités du projet OWASP (Open Worldwide Application Security Project). Gestion des API applique des contrôles d’accès au niveau du réseau, tels que le filtrage d’adresses IP et la limitation du débit.

  • Sécurité de la passerelle d’API : Gestion des API applique l’authentification et l’autorisation au niveau de l’application via la validation de jeton OAuth 2.0 et l’authentification par certificat. Ces stratégies valident l’identité de l’appelant au niveau de la demande d’API, distinctes des protections au niveau du réseau que le pare-feu d’applications web et le filtrage d’adresses IP fournissent.

  • Protection des données : Utilisez des identités managées pour l’authentification de service à service. Activez le chiffrement au repos pour tous des entrepôts de données.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.

Du point de vue de l’analyse des coûts, l’optimisation des coûts est directement liée à la façon dont vous approvisionnez l’infrastructure de surveillance, définissez des seuils de mise à l’échelle automatique et allouez le budget d’erreur. Le surprovisionnement dégrade l’efficacité des coûts. Le sous-provisionnement dégrade la fiabilité.

Les principaux facteurs de coût liés au SRE dans cette architecture comprennent :

  • Surveillance et observabilité : Azure Monitor, Application Insights et Azure Managed Grafana entraînent des coûts en fonction du volume d’ingestion des données, des stratégies de rétention et du nombre de règles d’alerte. Ajustez les taux d’échantillonnage et les périodes de rétention pour équilibrer la profondeur de l’observabilité par rapport aux coûts.

  • Surcharge de mise à l’échelle automatique : Les ressources de calcul telles que les pools de nœuds AKS et les unités d’échelle Gestion des API représentent la variable de coût la plus importante. Définissez soigneusement les seuils minimaux de mise à l’échelle automatique. Définir des seuils trop élevés gaspille des ressources, tandis que les définir trop bas risque de provoquer des violations des SLO lors des pics de trafic. Utilisez les données de surveillance pour étalonner les seuils.

  • Investissement dans le budget d’erreur : Lorsque les pannes restent dans votre budget d'erreur, investissez dans le développement de nouvelles fonctionnalités. Lorsque les défaillances consomment votre budget, investissez dans la fiabilité. Cette pratique empêche les dépenses inutiles en matière d'améliorations de fiabilité lorsque le système répond déjà à ses objectifs de SLO.

Voici d’autres facteurs de coût :

  • Gestion des API : Les coûts varient selon le niveau. Les niveaux Standard et Premium prennent en charge la mise à l’échelle automatique, mais à des coûts de base plus élevés par rapport aux niveaux Développeur et De base, qui ne prennent pas en charge la mise à l’échelle automatique.

  • Services de données : Les coûts d’Azure Cosmos DB dépendent du débit et du stockage provisionnés. Utilisez le débit autoscalé pour optimiser les charges de travail fluctuantes.

  • Réseautage: Azure Front Door et Application Gateway pour conteneurs entraînent des coûts en fonction du volume de trafic et des fonctionnalités actives.

Pour optimiser les coûts :

  • Utilisez des recommandations Azure Advisor pour les instances réservées et les plans d’épargne Azure.
  • Rightsize des pools de nœuds AKS en fonction de l’utilisation réelle.
  • Configurez des seuils de mise à l’échelle automatique pour équilibrer les performances et les coûts.
  • Utilisez la mise à l’échelle automatique d’Azure Cosmos DB pour éviter le surprovisionnement.

Utilisez la calculatrice de prix Azure pour estimer les coûts de cette architecture.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez Liste de vérification de la conception pour l'excellence opérationnelle.

Créez un processus de gouvernance holistique des performances pour gérer les performances tout au long du cycle de vie du service.

  • Objectifs de performances : Définissez des SLO ambitieux en fonction des besoins de l’entreprise.

  • Modélisation des performances : Identifiez les flux de travail et les performances attendues des modèles critiques pour l’entreprise.

  • Instrumentation: Utilisez Azure Monitor et Application Insights pour l’analyse APM, la télémétrie et les métriques. Azure Monitor prend en charge OpenTelemetry et s’intègre à Azure Managed Grafana pour le suivi et la visualisation distribués.

  • Tests de performances : Effectuez des tests de charge et de contrainte à l’aide d’outils tels que K6, Karate et JMeter. Intégrer des tests automatisés dans des pipelines de déploiement continu.

  • Surveillance continue : Configurez des alertes basées sur des seuils SLI et suivez la conformité SLO.

  • Déploiement en anneau : Utilisez des stratégies de déploiement progressif pour réduire l’impact des modifications.

Suivez les objectifs de performance en tant que récits utilisateur granulaires dans votre backlog pour vous assurer que vous hiérarchisez les activités de gouvernance parallèlement au travail sur les fonctionnalités.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Concevoir des applications afin que les ressources soient mises à l’échelle automatiquement pour répondre à la charge. Cette conception inclut l’infrastructure de calcul, de stockage et de messagerie.

Appliquez des techniques de modélisation de la scalabilité et des performances pour affiner l’architecture et la conception :

  • Identifiez les exigences de scalabilité.
  • Charge attendue du modèle.
  • Définissez des SLA et des SLO pour les scénarios utilisateur.

Capturer les exigences de scalabilité

Supposons les métriques de charge maximale suivantes :

  • Nombre de consommateurs : 1,5 million
  • Consommateurs actifs toutes les heures (30%) : 450 000
  • Distribution de charge :
    • Parcourir les produits : 75%
    • Inscription et connexion : 10%
    • Commandes et abonnements : 10%
    • Affichage du contenu : 5%

Exigences de mise à l’échelle de l’API en cas de charge maximale normale :

  • Microservice de produit : environ 500 demandes par seconde (RPS)
  • Microservice de profil : environ 100 requêtes par seconde
  • Microservice de commandes et de paiement : environ 100 RPS
  • Microservice de contenu : environ 50 RPS

Lors d’événements spéciaux, les exigences de mise à l’échelle peuvent atteindre 10 fois la charge maximale normale.

Définir les métriques de SLI pour calculer les SLO

Les métriques SLI indiquent le degré auquel un service offre une expérience satisfaisante, exprimée en tant que ratio d’événements corrects par rapport aux événements totaux.

Le tableau suivant montre des exemples de métriques SLI.

Métrique Descriptif
Disponibilité Indique si l’API a serviceé la requête
Latence Temps nécessaire pour que l’API traite la demande et la réponse
Débit Nombre de demandes gérées
Taux de réussite Nombre de demandes gérées avec succès
Taux d’erreur Nombre d’erreurs pour les demandes gérées
Fraîcheur Nombre de fois où l’utilisateur a reçu les données les plus récentes

Pour chaque SLI, vous calculez le rapport entre les événements de bonne qualité et le total des événements, comme observé par le client. Les exemples suivants illustrent ce calcul pour différents scénarios utilisateur :

  • Latence SLI pour la navigation du produit : Nombre de requêtes effectuées avec succès en <1 000 ms divisées par le nombre de requêtes. Ce SLI suit si le microservice produit répond au seuil de latence acceptable.

  • Freshness SLI pour la recherche : Nombre de résultats de recherche retournés dans les trois secondes divisé par le nombre de recherches. Cette SLI mesure la fréquence à laquelle l’expérience de recherche répond à la cible de fraîcheur après les mises à jour du catalogue.

Après avoir défini des SLA, déterminez les données de télémétrie à capturer à chaque couche de l’architecture, notamment Azure Front Door, Gestion des API, Application Gateway, pods AKS et magasins de données. Pour les services HTTP, utilisez des codes d’état pour classifier la réussite et l’échec. Azure Monitor et Application Insights fournissent une prise en charge de diagnostic et de surveillance pour toutes les couches.

Utilisez des distributions de centiles pour calculer certains SLI et exclure les valeurs aberrantes. Par exemple, si la latence du 95e centile respecte la limite, le système répond à l'Objectif de Niveau de Service (SLO).

Définissez les périodes de mesure SLO pour capturer l’activité, et non l’inactivité. La fenêtre peut aller de cinq minutes à 24 heures.

Établir des SLO ambitieux pour la solution cible

Prenons l’exemple suivant d’exemples de SLA aspirationnels :

  • Les requêtes READ répondent dans un délai d’une seconde pour 95% d’appels.
  • Les requêtes CREATE et UPDATE répondent dans les trois secondes pendant 95% d’appels.
  • Toutes les demandes répondent en cinq secondes sans échec pour 99% d’appels.
  • Toutes les requêtes réussissent sans erreur pour 99,9% d’appels.
  • Pendant les heures de pointe, moins de 1% de requêtes entraînent des erreurs.

Adapter les SLO à vos besoins en fonction des exigences de votre application.

Mesurer les SLO initiaux en fonction des données de journal

Supposons une semaine de données :

  • Demandes : 123 456
  • Demandes fructueuses : 123 204
  • Latence à 90e centile : 497 ms
  • Latence à 95e centile : 870 ms
  • Latence au 99e centile : 1 024 ms

SLIs initiaux :

  • Disponibilité = (123 204 / 123 456) = 99,8%.
  • Les demandes sont traitées dans un délai de 500 ms pour 90% d’appels.
  • Les demandes sont traitées dans un délai de 1 000 ms pour 98% d’appels.

Comparez les données de journal aux cibles SLO pour évaluer la conformité.

Conseils pour l’atténuation des risques techniques

Suivez ces pratiques recommandées :

  • Conception pour la mise à l’échelle et les performances.

    • Capturez les exigences de mise à l’échelle pour tous les scénarios, y compris les pics.
    • Performances du modèle pour identifier les contraintes.

  • Gérez la dette technique.

    • Tracez les métriques de performances.
    • Utilisez des outils tels que K6, Karate et JMeter pour les tests de charge.
    • Intégrer des tests automatisés au déploiement continu.

  • Adoptez un état d’esprit de production.

    • Ajustez les seuils de mise à l’échelle automatique en fonction des statistiques de santé.
    • Préférez la mise à l’échelle horizontale.
    • Utilisez le déploiement en anneau.
    • Utilisez des budgets d’erreur pour déterminer quand investir dans des améliorations de fiabilité par rapport aux nouvelles fonctionnalités. Un budget d’erreur est la différence entre 100% et votre cible SLO. Par exemple, un SLO de 99,9 % autorise un budget d’erreur de 0,1 %. Si les défaillances réelles consomment ce budget, hiérarchiser le travail de fiabilité pour réduire les taux d’échec. Si les défaillances restent dans le budget, investissez dans l’expérimentation et dans la livraison des fonctionnalités.
    • Utilisez Chaos Studio pour les tests de résilience.

Contributeurs

Microsoft maintient cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

Autre contributeur :

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

Étapes suivantes