Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Disponibilité
La disponibilité (ou disponibilité du service) est à la fois une métrique couramment utilisée pour mesurer quantitativement la résilience, ainsi qu’un objectif de résilience cible.
-
La disponibilité correspond au pourcentage de temps pendant lequel une charge de travail est disponible à’ l’utilisation.
Disponible à l’utilisation signifie que la charge de travail exécute bien sa fonction chaque fois que nécessaire.
Ce pourcentage se calcule sur une période, par exemple un mois, un an ou les trois dernières années. Dans son interprétation la plus stricte, la disponibilité est réduite chaque fois que l’application ne fonctionne pas normalement, y compris pendant les interruptions planifiées et non planifiées. Nous définissons la disponibilité comme suit :
-
La disponibilité est un pourcentage de temps de fonctionnement (par exemple, 99,9 %) sur une période (généralement un mois ou un an)
-
Un raccourci courant consiste à parler du « nombre de neuf ». Par exemple, « cinq 9 » correspond à une disponibilité de 99,999 %.
-
Certains clients choisissent d’exclure les temps d’arrêt programmés (par exemple, la maintenance planifiée) de la durée totale dans la formule. Cependant, cela n’est pas conseillé, car vos utilisateurs voudront probablement utiliser votre service pendant ces périodes.
Voici un tableau des objectifs courants de disponibilité des applications et de la durée maximale des interruptions qui peuvent se produire sur une année, tout en continuant d’atteindre l’objectif. Le tableau contient des exemples des types d’applications généralement rencontrées à chaque niveau de disponibilité. Tout au long de ce document, nous ferons référence à ces valeurs.
| Disponibilité | Indisponibilité maximale (par an) | Catégories d’applications |
|---|---|---|
| 99 % | 3 jours 15 heures | Tâches de traitement par lots, d’extraction de données, de transfert et de chargement |
| 99,9 % | 8 heures 45 minutes | Outils internes, tels que la gestion des connaissances, le suivi des projets |
| 99,95 % | 4 heures 22 minutes | Commerce en ligne, point de vente |
| 99,99 % | 52 minutes | Diffusion vidéo, charges de travail de diffusion |
| 99,999 % | 5 minutes | ATMtransactions, charges de travail liées aux télécommunications |
Mesurez la disponibilité en fonction des demandes. Pour votre service, il peut être plus facile de compter les demandes ayant réussi ou échoué au lieu du « temps disponible pour utilisation ». Dans ce cas, le calcul suivant peut être utilisé :
Cette mesure porte souvent sur des périodes d’une minute ou de cinq minutes. Un pourcentage de disponibilité mensuelle (mesure de la disponibilité sur la base du temps) peut être calculé à partir de la moyenne de ces périodes. Si aucune demande n’est reçue au cours d’une période donnée, elle est comptée comme étant disponible à 100 % pour cette période.
Calcul de disponibilité avec des dépendances strictes. De nombreux systèmes ont des dépendances strictes avec d’autres systèmes. Dans ce cas, une interruption dans un système dépendant se traduit directement par une interruption du système appelant. Cette notion s’oppose à celle de dépendance souple, où une défaillance du système dépendant est compensée dans l’application. Quand de telles dépendances strictes se produisent, la disponibilité du système appelant est le produit de la disponibilité des systèmes dépendants. Par exemple, si un système conçu pour offrir une disponibilité de 99,99 % a une dépendance stricte avec deux autres systèmes indépendants, qui sont chacun conçus pour offrir une disponibilité de 99,99 %, la charge de travail peut théoriquement atteindre 99,97 % de disponibilité :
Availinvok × Availdep1 × Availdep2 = Availworkload
99,99 % × 99,99 % × 99,99 % = 99,97 %
Il est donc important de comprendre vos dépendances et leurs objectifs de conception de disponibilité dans votre propre calcul de disponibilité.
Calcul de disponibilité avec des composants redondants. Lorsqu’un système implique l’utilisation de composants redondants et indépendants (par exemple, des ressources redondantes dans des zones de disponibilité redondantes), la disponibilité théorique est calculée à hauteur de 100 %, moins le produit des taux de défaillance des composants. Par exemple, si un système utilise deux composants indépendants, chacun avec une disponibilité de 99,9 %, la disponibilité effective de cette dépendance est > 99,9999 % :
Availeffective = AvailMAX − ((100%−Availdependency)×(100%−Availdependency))
99,9999 % = 100 % − (0,1 % × 0,1 %)
Calcul de raccourci : si les disponibilités de tous les composants de votre calcul contiennent uniquement le chiffre neuf, vous pouvez additionner le nombre de neuf pour obtenir votre réponse. Dans l’exemple ci-dessus, deux composants redondants et indépendants avec trois neuf disponibles donnent six neuf.
Calcul de la disponibilité d’une dépendance. Certaines dépendances fournissent des informations sur leur disponibilité, y compris les objectifs de conception de disponibilité pour de nombreux services AWS Mais dans les cas où cela n'est pas disponible (par exemple, s'il s'agit d'un composant pour lequel le fabricant ne publie pas d'informations de disponibilité), l'une des méthodes d'estimation consiste à déterminer le temps moyen entre une panne (MTBF) et le temps moyen de restauration (MTTR). Une estimation de disponibilité peut être établie par la formule suivante :
Par exemple, s'il s'MTBFagit de 150 jours et d'une heure, l'MTTRestimation de disponibilité est de 99,97 %.
Pour plus de détails, consultez Availability and Beyond : Understanding and improving the resilience of distributed systems on AWS, qui peut vous aider à calculer votre disponibilité.
Coûts liés à la disponibilité. La conception d’applications pour de plus hauts niveaux de disponibilité est généralement synonyme de coûts accrus. Par conséquent, il est nécessaire d’identifier les vrais besoins de disponibilité avant de démarrer la conception de votre application. Un haut niveau de disponibilité impose des exigences plus strictes pour les tests et la validation dans des scénarios de défaillance exhaustifs. L’automatisation est nécessaire pour la récupération à partir de toutes sortes de défaillances, et tous les aspects des opérations système doivent être conçus et testés selon les mêmes normes. Par exemple, l’ajout ou la suppression de capacité, le déploiement ou la restauration des mises à jour logicielles ou des modifications de configuration ou la migration des données système doivent être réalisées en fonction de l’objectif de disponibilité souhaité. Outre le coût de développement du logiciel, les très hauts niveaux de disponibilité sont un frein à l’innovation, car ils nécessitent de déployer beaucoup plus lentement les systèmes. Il est donc recommandé d’être minutieux dans l’application des normes et dans la sélection d’un objectif de disponibilité adapté pour tout le cycle de vie de l’exploitation du système.
La sélection de dépendances est un autre facteur d’augmentation des coûts pour les systèmes opérant avec des objectifs de conception de disponibilité élevés. Avec ces objectifs plus élevés, l’ensemble de logiciels ou services qui peuvent être choisis en tant que dépendances diminue en fonction des services qui ont bénéficié des investissements importants décrits précédemment. Quand l’objectif de conception de disponibilité augmente, les services multifonctions (par exemple, les bases de données relationnelles) sont moins nombreux par rapport aux services plus spécialisés. Ces derniers sont en effet plus faciles à évaluer, tester et automatiser, et ils sont moins susceptibles de présenter des interactions imprévues avec des fonctionnalités incluses, mais non utilisées.
