Améliorer la fiabilité de vos applications dans Azure

Vous pouvez utiliser des contrats SLA pour évaluer la façon dont vos solutions Azure répondent aux exigences de l’entreprise ainsi qu’aux besoins de vos clients et utilisateurs. En créant vos propres contrats SLA, vous pouvez définir des cibles de performances en fonction de votre application Azure spécifique. Cette approche est appelée contrat SLA d’application.

Comprendre les besoins de vos applications

La création d’une solution Azure efficace et fiable nécessite de connaître les besoins de votre charge de travail. Vous pouvez ensuite sélectionner les produits et services Azure, et provisionner des ressources en fonction de ces exigences. Il est important de comprendre les contrats SLA Azure qui définissent les cibles de performances pour les produits et services Azure dans votre solution. Cette compréhension vous aide à créer des contrats SLA d’application réalisables.

Dans un système distribué, des défaillances peuvent se produire. Le matériel peut être défaillant. Le réseau peut subir des échecs temporaires. Il est rare pour l’intégralité d’un service ou d’une région de rencontrer des interruptions, mais même ces dernières doivent être planifiées.

Résilience

La résilience est la capacité d’un système à récupérer après des défaillances et à continuer de fonctionner. Il ne s’agit pas d’éviter les défaillances, mais d’y répondre en évitant les temps d’arrêt ou la perte de données. L’objectif de la résilience est que l’application retrouve un état entièrement fonctionnel suite à une défaillance. La haute disponibilité et la reprise d’activité sont deux aspects importants de la résilience.

Lors de la conception de votre architecture, vous devez penser à la conception pour la résilience et effectuer une analyse du mode d’échec. Cette analyse vise à identifier les points de défaillance possibles et à définir la manière dont l’application y répondra.

Coût/complexité et haute disponibilité

La disponibilité fait référence à la durée pendant laquelle le système est fonctionnel et opérationnel. L’optimisation de la disponibilité nécessite l’implémentation de mesures afin d’éviter les éventuels échecs de service. Toutefois, l’élaboration de mesures préventives peut être difficile et coûteuse, et aboutit généralement à des solutions complexes.

À mesure que votre solution gagne en complexité, de plus en plus de services dépendent les uns des autres. Par conséquent, vous pouvez négliger des points de défaillance possibles dans votre solution si vous avez plusieurs services interdépendants.

Conseil

Par exemple : Une charge de travail qui nécessite une durée de fonctionnement de 99,99 % ne doit pas dépendre d’un service avec un contrat SLA de 99,9 %.

La plupart des fournisseurs préfèrent optimiser la disponibilité de leurs solutions Azure en réduisant les temps d’arrêt. Toutefois, quand vous augmentez la disponibilité, vous augmentez également le coût et la complexité de votre solution.

Conseil

Par exemple : Un contrat SLA qui définit une durée de fonctionnement de 99,999 % autorise uniquement 5 minutes de temps d’arrêt total par année.

Le risque d’éventuels temps d’arrêt est cumulatif entre les différents niveaux de contrat SLA, ce qui signifie que des solutions complexes peuvent être confrontées à des défis plus importants en matière de disponibilité. Par conséquent, l’importance que vous accordez à la haute disponibilité détermine la façon de gérer l’ajout de la complexité et du coût aux contrats SLA de vos applications.

Éléments à prendre en compte pour la définition des contrats SLA d’application

  • Si le contrat SLA de votre application définit quatre 9 (99,99 %) comme cibles de performances, une intervention manuelle pour récupérer en cas de défaillances risque de ne pas suffire pour remplir le contrat. Votre solution Azure doit pouvoir effectuer des diagnostics et se réparer elle-même.
  • Au-delà de quatre 9, il devient difficile de détecter les pannes assez rapidement pour respecter les cibles de performances du contrat SLA.
  • Étudiez attentivement la fenêtre de temps par rapport à laquelle les cibles de performances du contrat SLA de votre application sont mesurées. Plus la fenêtre est petite, plus les tolérances seront strictes. Si vous définissez le contrat SLA de votre application en termes de durée de fonctionnement par heure ou par jour, vous devez comprendre que ces tolérances plus strictes ne permettent peut-être pas des cibles de performances réalisables.