Les Patterns des Grands du Web – Design for failure

le 26/09/2012 par David Alia
Tags: Software Engineering

Description

« Everything fails all the time » est l’aphorisme célèbre de Werner Vogels, CTO d’Amazon : il est en effet impossible de prévoir toutes les défaillances qui peuvent se produire sur un système informatique, à toutes les couches : une règle de gestion incohérente, des ressources systèmes non relâchées après une transaction, une panne de disque dur...

Et c’est sur ce principe simple que se basent les architectures techniques des Géants du Web aujourd’hui, rassemblées sous le pattern design for failure, « conçu pour supporter la défaillance » : une application informatique doit être capable de supporter la panne de n’importe quel composant logiciel ou matériel sous-jacent.

Ainsi, le hardware n’est jamais 100% fiable : il est essentiel d’abstraire les composants et les applications du matériel (grille de données, HDFS...) pour garantir une continuité permanente du service.

Chez Amazon par exemple, on évalue que 30 disques durs sont changés chaque jour dans un datacenter. Coût à mettre en regard à une disponibilité quasi-totale du site amazon.fr (moins de 0,3s d’indisponibilité par an) sur lequel, rappelons-le, une minute d’interruption correspond à plus de 50.000 euros de manque à gagner.

On oppose généralement le modèle traditionnel de gestion de la continuité de service au modèle « design for failure » en illustrant par ces cinq stades de redondance :

  • Stade 1 : redondance physique (réseau, disque, datacenter). Ici s’arrête le modèle traditionnel
  • Stade 2 : redondance virtuelle : une application est distribuée sur plusieurs machines virtuelles identiques au sein d’un cluster de VMs
  • Stade 3 : redondance des clusters de VMs (ou Availability Zone sur AWS). Ces clusters sont répartis en clusters de clusters
  • Stade 4 : redondance des clusters de clusters (ou Region sur AWS). Un fournisseur unique gère ces régions
  • Stade 5 : redondance des fournisseurs d’accès (ex : AWS et Rackspace) au cas, improbable, où AWS serait complètement arrêté

Évidemment, vous l’aurez compris, plus on s’élève dans les stades de redondance, plus les mécanismes de déploiement et de bascule sont automatisés.

Les applications conçues en design for failure continuent à fonctionner malgré les défaillances des systèmes ou des applications connectées, quitte à offrir un fonctionnement dégradé aux utilisateurs et si possible, uniquement aux nouveaux utilisateurs qui s’y connectent pour conserver une qualité acceptable du service.

En découlent par exemple deux déclinaisons applicatives de designs for failure :

  • Eventual consistency : au lieu de rechercher systématiquement la consistance à chaque transaction, avec des mécanismes souvent coûteux type XA, la consistance est assurée à la fin (eventual), lorsque les services défaillants sont à nouveau disponibles
  • Graceful degradation (à ne pas confondre avec le pattern IHM web du même nom) : en cas de pics de charge intempestifs, les fonctionnalités coûteuses en performance sont désactivées à chaud

Chez Netflix, le service de streaming n’est jamais interrompu, bien que leur système de recommandation soit arrêté, en panne ou très lent : toujours répondre, malgré les défaillances connexes.

D’ailleurs, pour parvenir à ce niveau de disponibilité, Netflix utilise des outils de tests automatisés comme Chaos Monkey (récemment open-sourcé), Latency Monkey ou encore Chaos Gorilla qui vérifient que les applications répondent toujours correctement malgré la défaillance aléatoire de, respectivement, une ou plusieurs VM, la latence réseau, une Availability Zone.

Netflix  illustre ainsi par les actes sa devise : “The best way to avoid failure is to fail constantly”.

Chez qui ça fonctionne ?

Evidemment, Amazon qui fournit les briques de bases AWS.

Evidemment, Google, Facebook qui communiquent beaucoup sur ces sujets.

Mais également Netflix, SmugMug, Twilio, Etsy...

En France, même si certains sites ont des taux de disponibilité très élevés, peu communiquent sur leurs méthodes et, à notre connaissance, peu sont capables d’étendre leur niveau de redondance au-delà du stade 1 (physique) ou 2 (machines virtuelles). Citons tout de même Critéo, Amadeus, Viadeo, les gros opérateurs téléphoniques (SFR, Bouygues, Orange) pour leurs besoins temps réel. Si vous lisez ces lignes et que vous appartenez à une société française qui contredit ces propos, n'hésitez pas à commenter :)

Et chez moi ?

La redondance physique, les PRA, sites DRP etc. ne sont pas des mécanismes de design for failure mais des stades de redondance.

Le pattern design for failure implique de changer de paradigmes, de passer de « prévenir toutes les défaillances » à « les défaillances font partie du jeu », passer de « la peur du crash » à « analyser et améliorer ».

En effet, les applications construites sur le mode design for failure ne génèrent plus ce sentiment d’urgence puisque toute défaillance est maîtrisée naturellement : cela laisse du temps pour l’analyse froide (post-mortems) et l’amélioration (PDCA). C’est, pour reprendre un terme du théâtre d’improvisation, la « décontraction dans l’urgence ».

Cela implique deux actions, l’une technique et l’autre humaine :

Sur la conception d’application :

  • Les composants d’une application ou d’un ensemble d’applications doivent être décentralisés et redondés par VM, par Zone, par Région (sur le Cloud. Même principe si vous hébergez vous-même votre SI) sans zone commune de défaillance. Le cas le plus complexe est la synchronisation des bases de données
  • Tout composant doit être prêt pour une panne d’infrastructure sous-jacente
  • Les applications doivent supporter des ruptures de communication ou des latences réseau fortes
  • Il faut automatiser toute la chaîne de production de ces applications

Sur l’organisation :

  • Sortir de la culture de l’Agence Tous Risques (rappelez-vous : « la dernière chance au dernier moment ») pour automatiser les traitements en cas de défaillance des systèmes. Chez Google, on compte 1 administrateur système pour plus de 3 000 machines.
  • Analyser et résoudre les défaillances avec méthode : en amont (approche par les risques via FMEA : Failure Mode and Effects Analysis) et en aval (Post-mortems, PDCA)

Dépendances à d’autres patterns

Exceptions

  • Les applications totalement déconnectées, avec peu d’utilisateurs, ou peu d’enjeux business : la redondance doit être simple, voire absente.
  • L’arbitrage entre chaque stade de redondance est ensuite effectué sur des critères de ROI (coûts et complexité vs pertes estimées si indisponibilités).

Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l'ouvrage à télécharger, vidéo et compte-rendu de la présentation "Décrypter les secrets des Géants du Web"

Sources