Qu’est-ce que la résilience des applications ?

Les applications sont omniprésentes dans le monde moderne des affaires, qu’il s’agisse du traitement des transactions client, de la gestion des chaînes d’approvisionnement, de la collaboration entre employés ou de l’analyse des données en temps réel.

Or, lorsque ces applications tombent en panne, les conséquences peuvent être graves. Les temps d’arrêt, c’est-à-dire les périodes pendant lesquelles une application n’est pas disponible ou ne fonctionne pas correctement, peuvent nuire à la réputation de l’entreprise, dégrader l’expérience utilisateur et entraîner des pertes financières importantes.

En effet, 98 % des entreprises déclarent aujourd’hui que les coûts liés aux temps d’arrêt dépassent les 100 000 dollars par heure, un tiers d’entre elles estimant leurs pertes entre 1 et 5 millions de dollars.

Mais il est possible de réduire considérablement ces désagréments en concevant et en déployant des applications résilientes.

La résilience des applications repose sur deux grands principes :

• La tolérance aux pannes : la capacité d’une application à continuer de fonctionner lorsqu’une partie de celle-ci tombe en panne.

• La haute disponibilité : la capacité d’un système à être accessible et fiable presque 100 % du temps. 

Les applications résilientes contribuent à réduire les vulnérabilités au niveau de l’architecture sous-jacente, à améliorer l’efficacité opérationnelle et à garantir une expérience utilisateur cohérente, même en cas de perturbations imprévues.

Pour créer et déployer des applications résilientes, les développeurs et les équipes informatiques disposent de plusieurs outils et pratiques tout au long du cycle de vie des applications.

Les composants que l’on retrouve le plus souvent dans les applications résilientes sont les suivants :

• Redondance
• Equilibrage de charge
• Confinement des défaillances
• Observabilité
• Automatisation
• Dégradation progressive
• Évolutivité

La redondance consiste à disposer de versions de sauvegarde des systèmes critiques. En cas de défaillance d’un système, la sauvegarde prend le relais, ce qui permet de garantir le fonctionnement continu du système.

Par exemple, dans le cas d’un service de traitement des paiements, il est probable que plusieurs copies du service soient exécutées sur différents serveurs. Si un serveur plante, les copies sur les autres serveurs peuvent automatiquement prendre le relais, de sorte que les clients ne remarquent rien.

Les entreprises mettent souvent en place une redondance dans les domaines clés suivants :

• Bases de données : stockage de plusieurs copies des données à différents emplacements afin de garantir qu’aucune perte ne se produise en cas de défaillance d’un système.

• Centres de données : hébergement d’applications sur plusieurs sites physiques afin que les opérations puissent se poursuivre même si un site tombe en panne.

• Environnements cloud : distribution des applications entre plusieurs régions ou fournisseurs, tels qu’Amazon Web Services (AWS), Microsoft Azure et IBM® Cloud, afin d’éliminer les points de défaillance uniques.

• Connexions réseau : utilisation de plusieurs fournisseurs d’accès Internet ou de services de télécommunications pour maintenir la connectivité en cas de panne.

L’équilibrage de charge consiste à répartir efficacement le trafic réseau entre plusieurs serveurs afin d’optimiser la disponibilité des applications. Il est essentiel à la résilience des applications, car il permet aux systèmes de maintenir leurs performances et leur disponibilité même lorsque certains composants tombent en panne ou sont surchargés.

Par exemple, si un serveur ne répond plus, l’équilibreur de charge peut automatiquement rediriger le trafic vers d’autres serveurs opérationnels et ainsi maintenir l’application en ligne.

Le confinement des défaillances est une pratique de conception qui isole les composants critiques d’un système distribué et empêche les problèmes localisés de se propager à l’ensemble du système.

Cette pratique est particulièrement importante dans les architectures de microservices, où la défaillance d’un service peut rapidement avoir des répercussions sur de nombreuses autres dépendances si elle n’est pas correctement confinée.

Les maillages de services sont particulièrement utiles pour contenir les erreurs. Ces couches d’infrastructure facilitent la gestion des communications entre les microservices dans les applications distribuées, grâce aux capacités suivantes :

• Nouvelles tentatives automatiques : lorsqu’une requête échoue en raison d’un problème temporaire (comme un bref dysfonctionnement du réseau), le maillage effectue automatiquement une nouvelle tentative au lieu d’abandonner immédiatement.

• Coupure de circuit : le maillage surveille l’état de santé des services et cesse temporairement d’envoyer des requêtes aux services en difficulté, leur laissant le temps de se rétablir tout en empêchant les pannes à l’échelle du système.

• Traçage distribué : le maillage suit les requêtes lorsqu’elles transitent entre différents services, aidant les équipes à repérer les ralentissements et à localiser précisément l’origine des problèmes.

Ensemble, ces capacités permettent de garantir que les défaillances d’un service ne se propagent pas aux autres. Par exemple, supposons qu’un moteur de recommandation de produits tombe en panne sur un site d’e-commerce. Un maillage de services peut alors détecter cette défaillance, empêcher les requêtes d’atteindre le service défaillant et rediriger le trafic en conséquence. Les utilisateurs peuvent continuer à naviguer et à faire des achats sans interruption.

L’observabilité permet aux équipes de surveiller l’état du système en temps réel à l’aide de trois types de données clés : les indicateurs de performance (tels que les temps de réponse), les journaux (enregistrements d’événements tels que les erreurs ou les pannes) et les traces (le parcours complet d’une requête à travers un système).

En recueillant et en analysant ces signaux, les équipes peuvent détecter les anomalies, diagnostiquer rapidement les problèmes et réduire les temps d’arrêt. Par exemple, si un client signale un chargement lent d’une page Web, les ingénieurs peuvent utiliser des outils d’observabilité pour suivre la requête et remonter jusqu’au service à l’origine du retard afin de corriger le problème avant qu’il n’affecte d’autres utilisateurs.

L’automatisation joue un rôle essentiel dans la résilience des applications en permettant aux systèmes de réagir aux problèmes sans intervention manuelle.

Par exemple, les outils d’observabilité détectent les problèmes et la redondance fournit des ressources de secours, tandis que l’automatisation relie ces capacités et orchestre le processus de récupération. Une automatisation efficace peut réduire considérablement le temps de récupération, d’un dépannage manuel de plusieurs heures à une réponse automatisée en quelques secondes.

Voici quelques réponses automatisées cruciales dans le domaine de la résilience des applications :

• Basculements scriptés : séquences d’actions prédéterminées qui transfèrent automatiquement les opérations d’un système défaillant vers des systèmes de secours identifiés grâce à la planification de la redondance. Par exemple, si la base de données principale tombe en panne, le système bascule automatiquement vers une base de données de secours et y redirige tout le trafic en quelques secondes.

• Réapprovisionnement des ressources : approvisionnement automatique de nouvelles instances ou réaffectation des ressources en cas de défaillance de composants, par exemple en créant de nouvelles machines virtuelles pour remplacer celles qui sont défectueuses sans que personne n’ait à intervenir.

• Workflows d’auto-réparation : coordination entre les alertes de surveillance et les actions de récupération pour restaurer le service sans intervention humaine. Par exemple, si une application commence à utiliser trop de mémoire, le système la redémarre automatiquement avant que les utilisateurs ne remarquent un ralentissement.

Des outils tels que Kubernetes, un système open source de gestion des applications conteneurisées, démontrent comment l’automatisation relie les composants qui assurent la résilience. Kubernetes peut détecter les défaillances grâce à des contrôles intégrés de l’état, réorganiser les workloads entre les nœuds sains et maintenir la continuité du service au moyen de workflows automatisés.

La dégradation progressive consiste à maintenir les fonctionnalités essentielles tout en supprimant les fonctionnalités non essentielles en cas de surcharge. Par exemple, lors des pics de trafic du Black Friday, un détaillant peut temporairement désactiver les avis de clients et les listes de souhaits afin de garantir le bon fonctionnement du panier et du processus de paiement.

Les applications évolutives peuvent ajuster automatiquement les ressources en fonction de la charge de travail. Cette capacité permet de garantir des performances et une disponibilité optimales, même en cas de fluctuations du trafic.

Il existe plusieurs façons d’assurer l’évolutivité. Par exemple, les plateformes cloud ont recours notamment à des équilibreurs de charge intégrés, à la mise à l’échelle automatique et à la réplication multirégionale, c’est-à-dire la copie des données et des services sur plusieurs sites physiques afin d’améliorer les performances et la fiabilité. Ces fonctionnalités permettent aux services de répartir intelligemment le trafic, de maintenir le temps de fonctionnement et de réduire au minimum le temps de récupération en réponse à des conditions changeantes.

Par exemple, une plateforme de diffusion en continu hébergée dans le cloud fonctionne habituellement sur, disons, 100 serveurs. Cependant, lors d’un événement mondial en direct, elle peut automatiquement passer à 10 000 serveurs dans plusieurs régions, offrant ainsi une lecture fluide à des millions de spectateurs simultanés.

Les applications logicielles étant devenues essentielles tant pour les activités professionnelles que pour la vie quotidienne des consommateurs, il est impératif qu’elles résistent aux perturbations imprévues et continuent de fonctionner dans presque toutes les conditions.

L’importance croissante accordée à la résilience des applications s’explique notamment par quatre facteurs.

• Attentes élevées des consommateurs
• Coût des temps d’arrêt
• Complexité architecturale
• Pression réglementaire

Les clients s’attendent à ce que les services numériques fonctionnent en permanence. Selon Google, 53 % des visiteurs abandonnent une page sur mobile si son chargement prend plus de trois secondes.

Qu’il s’agisse d’une application bancaire, d’une plateforme d’e-commerce ou d’un portail de santé, les temps d’arrêt peuvent entraîner une perte de clients, des réactions négatives sur les réseaux sociaux et une atteinte durable à l’image de marque. La disponibilité des applications n’est pas seulement un indicateur technique, mais une exigence métier fondamentale.

Les pannes d’applications peuvent coûter cher aux entreprises de toutes tailles. Prenons un scénario courant : un détaillant lance une promotion très attendue, mais le service de paiement ne parvient pas à faire face au surplus de demandes. En quelques minutes, des milliers de transactions sont bloquées, les clients sont frustrés et l’entreprise subit une perte de revenus.

Au-delà du manque à gagner, les pannes peuvent entraîner une cascade de coûts secondaires, allant des frais de résolution et des violations des accords de niveau de service (SLA) aux sanctions réglementaires, en passant par les indemnités versées aux clients et l’atteinte à long terme à l’image de marque.

Des incidents récents très médiatisés montrent à quel point les conséquences peuvent être importantes :

• Transport : en 2016, la panne d’un centre de données a entraîné l’annulation de 2 000 vols et coûté 150 millions de dollars de pertes à une grande compagnie aérienne.

• E-commerce : lors d’une période de soldes intense en 2018, des perturbations techniques ont coûté à un détaillant en ligne entre 72 et 99 millions de dollars de pertes de revenus.

• Réseaux sociaux : en 2021, une interruption de service de six heures a entraîné une perte de revenus publicitaires d’environ 100 millions de dollars pour un géant de l’Internet.

Les architectures d’application modernes comportent de nombreux éléments mobiles : microservices, environnements multicloud, bibliothèques de codes, etc. Si ces composants modulaires améliorent l’évolutivité, ils augmentent également le nombre de points de défaillance potentiels.  

Sans une conception et une mise en œuvre résilientes, même les problèmes mineurs peuvent s’aggraver.La défaillance d’un seul microservice peut se répercuter sur des dizaines de dépendances. Par exemple, si un service de base de données qui stocke des informations sur les produits cesse de fonctionner, cela peut perturber d’autres fonctionnalités, telles que la recherche, les recommandations ou le paiement.

Les perturbations du réseau entre les régions cloud peuvent également fragmenter les services et entraîner des incohérences dans les données. Contrairement à une défaillance de microservice où un composant cesse complètement de fonctionner, ces problèmes de connectivité créent un scénario de « split-brain » : différentes parties de l’application continuent de fonctionner, mais ne peuvent plus communiquer entre elles.

Par exemple, le système de commande d’une application de trading financier peut être déconnecté des données de prix en temps réel, ce qui entraîne l’affichage de cotations incorrectes ou l’échec des transactions pour les utilisateurs.

Les pannes d’API peuvent également perturber des fonctionnalités essentielles. Alors que le dysfonctionnement des microservices affecte les composants internes contrôlés par l’entreprise, les pannes d’API impliquent des services tiers dont dépend l’application, mais qu’elle ne peut pas réparer directement. Par exemple, si le service de cartographie d’une application de livraison tombe en panne, les utilisateurs ne peuvent plus suivre les chauffeurs et ces derniers ne peuvent plus trouver leur itinéraire, ce qui perturbe l’expérience même si l’application principale continue de fonctionner.

Dans certains secteurs et certaines régions, les organismes de réglementation ont fixé des exigences strictes en matière de disponibilité des données, de capacités de récupération des applications, d’atténuation des pertes de données et de temps de fonctionnement. La résilience des applications, auparavant un objectif technique, est désormais une question de conformité.

Certaines lois sur la protection des données et la vie privée incluent dorénavant des normes de disponibilité en plus des exigences de sécurité. Par exemple, le règlement général sur la protection des données (RGPD) exige que les données personnelles restent à la fois protégées et accessibles. En cas de défaillance du système, les entreprises sont tenues de récupérer les données perdues.

Les secteurs hautement réglementés, en particulier, sont soumis à certaines des normes les plus rigoureuses.

Bien que la loi américaine Sarbanes-Oxley (SOX) n’impose pas explicitement de plans de reprise après sinistre, de nombreuses entreprises disposent de systèmes de sauvegarde et de procédures de récupération formelles pour se conformer à la loi et prouver leur conformité.

Les institutions financières sont également soumises à des réglementations spécifiques à leur secteur et à des recommandations émanant d’organismes tels que le Federal Financial Institutions Examination Council (FFIEC) aux États-Unis, qui fournit des conseils détaillés sur la planification de la continuité des activités et les objectifs de temps de récupération.

En vertu de la loi américaine HIPAA (Health Insurance Portability and Accountability Act), les entités concernées doivent mettre en œuvre des mesures de protection administratives, physiques et techniques afin de garantir la disponibilité et l’intégrité des données de santé électroniques protégées. Bien que la loi HIPAA n’impose pas un accès 24 heures sur 24 et 7 jours sur 7, elle exige des établissements de santé qu’ils maintiennent l’accès aux données des patients lorsque cela est nécessaire pour leur traitement.

La règle de sécurité HIPAA exige la mise en place de plans de sauvegarde des données, de procédures de reprise après sinistre et de modes de fonctionnement d’urgence, ce qui incite de nombreuses entreprises à investir dans des stratégies avancées de basculement et de réplication des données.

Afin de s’assurer que les systèmes peuvent résister à des perturbations réelles, les entreprises valident la résilience des applications grâce à une combinaison de mesures continues et de tests proactifs. Ces approches permettent aux équipes de surveiller les performances, d’identifier les vulnérabilités et de confirmer si les applications peuvent se rétablir rapidement et efficacement.

Les équipes DevOps, en particulier, intègrent fréquemment des pratiques de résilience dans les pipelines CI/CD. Cela leur permet d’automatiser les tests des procédures de basculement, de valider les changements de configuration et de revenir en arrière en cas de déploiements instables afin de détecter les problèmes à un stade précoce et d’empêcher les perturbations d’atteindre les utilisateurs.

Les entreprises s’appuient sur plusieurs indicateurs clés pour évaluer la résilience des applications. 

Les entreprises se tournent de plus en plus vers les tests pour obtenir une vision plus réaliste. Si les indicateurs peuvent fournir une base, les tests peuvent aider les entreprises à passer de la théorie à la pratique. 

L’intelligence artificielle (IA) et le machine learning (ML) redéfinissent la manière dont les entreprises abordent la résilience. Ces technologies apportent de nouveaux outils puissants pour prévenir les temps d’arrêt, mais elles introduisent également des défis uniques.

L’un des plus grands défis est que les workloads d’IA sont gourmands en ressources. De nombreux modèles s’appuient sur des processeurs graphiques (GPU), qui sont à la fois coûteux et difficiles à dupliquer dans les différentes régions cloud. La redondance, élément essentiel de la résilience, est donc plus difficile à mettre en place.

Les systèmes d’IA peuvent également connaître des défaillances inattendues. Au fil du temps, leur précision peut se dégrader, un problème connu sous le nom de dérive du modèle. Ils peuvent également être confrontés à des entrées adverses, c’est-à-dire des données malveillantes conçues pour tromper le système. Ces types de défaillances peuvent être plus difficiles à prévoir et à contenir.

De plus, lorsque les fonctionnalités d’IA ralentissent ou cessent de fonctionner (un problème courant dans les environnements cloud en raison des contraintes de ressources ou de la latence), le reste de l’application doit continuer à fonctionner de manière fiable, ce qui exerce une pression supplémentaire sur les stratégies de dégradation progressive.

Dans le même temps, l’IA présente des cas d’utilisation importants pour améliorer la résilience :

• L’analyse prédictive prévoit les défaillances futures en analysant les modèles et les tendances historiques. Les équipes peuvent ainsi remplacer de manière proactive le matériel ou ajuster les ressources avant que les problèmes ne surviennent, par exemple en prédisant les défaillances au niveau des disques plusieurs jours à l’avance en fonction des tendances de température et de taux d’erreur.

• La résolution intelligente utilise l’IA pour prendre des décisions plus judicieuses en matière de récupération. Alors que les systèmes automatisés traditionnels peuvent simplement redémarrer un service défaillant, dans le cadre de la résolution alimentée par l’IA, les modèles sont analysés afin de choisir la stratégie de récupération optimale, par exemple en redirigeant le trafic vers des régions moins chargées ou en adaptant les ressources en fonction de la demande prévue.

• La détection des anomalies permet à l’IA d’identifier en temps réel des irrégularités subtiles qui pourraient échapper à une surveillance basée sur des règles, telles que des combinaisons inhabituelles d’indicateurs qui signalent un problème émergent même lorsque les différents indicateurs semblent normaux.

• Les tests pilotés par l’IA permettent aux équipes DevOps de simuler des scénarios de défaillance plus complexes à un stade plus précoce du processus de développement logiciel.

En résumé, si l’IA introduit une nouvelle complexité, elle permet également de procéder à des rétablissements plus rapides, d’assurer une surveillance plus intelligente et de renforcer globalement la résilience des applications, en particulier lorsqu’elle est intégrée à des environnements cloud natifs et à des pipelines DevOps.