Parfois, la meilleure voie vers le succès est d'apprendre comment éviter l'échec. Parce qu'il s'est préparé à cette éventualité, Netflix a pu continuer à servir ses clients alors que son fournisseur d'hébergement dans le cloud, Amazon Web Services (AWS), redémarrait ses serveurs pour corriger un bug dans Xen « Quand nous avons été informés du redémarrage d'urgence des serveurs d'Elastic Cloud Compute EC2, nous n'en avons pas cru nos oreilles. Quand nous sommes avons vu combien de noeuds Cassandra seraient affectés par le reboot, nous avons tourné de l'oeil », a déclaré dans un blog de Netflix consacré à la panne Christos Kalantzis, directeur de l'ingénierie et responsable de la base de données dans le cloud de Netflix. C'est le 25 septembre dernier qu'Amazon a annoncé à ses clients EC2 qu'il devait mettre à jour ses serveurs et qu'il devait en redémarrer un petit nombre, avec des répercussions possibles sur les services à la clientèle, sans préciser quels hôtes virtuels seraient redémarrés, ni à quel moment. Plus tard, certaines informations ont révélé que ce reboot avait pour but de corriger une vulnérabilité dans l'hyperviseur Xen, sur lequel tourne EC2. Netflix est l'un des plus gros clients d'Amazon. Et ses 50 millions de clients payent un abonnement mensuel pour regarder des séries TV, des films et d'autres contenus à tout moment. Si Netflix ne s'était pas préparé à limiter l'impact des pannes potentielles, c'est l'entreprise - et non le fournisseur de services cloud - qui aurait eu à répondre à la colère des clients. Mais Netflix a fait en sorte de rendre son service résilient, de façon à ce que, en cas de panne d'un datacenter d'Amazon, la charge soit transférée vers un autre centre de calcul, avec un impact à peine visible pour les clients.

Avec ses outils Simian Army, Netflix attaque ses SGBD dans EC2

Le service de streaming a également cherché des solutions permettant de minimiser le temps d'arrêt quand ses services ont dû être redémarrés. Pour être prêt à toute éventualité, Netflix est même allé plus loin en perturbant ses propres services avec un ensemble d'outils nommés Simian Army qui interrompent périodiquement et de façon aléatoire ses services. L'objectif étant de faire en sorte que tout service Netflix soit suffisamment élastique pour continuer à fonctionner quand il subit l'attaque d'un de ces outils. Si ce n'est pas le cas, les ingénieurs de Netflix modifient l'architecture du service pour le rendre plus fiable. Mais, même si les systèmes avaient été préparés pour répondre à des attaques d'outils comme Monkey Chaos et Simian Army, les ingénieurs étaient toujours préoccupés par le redémarrage d'AWS. En particulier, par le redémarrage des 2 700 bases de données Cassandra utilisées par Netflix sur EC2.

Comme l'explique le blog de Netflix, les bases de données sont « les petites princesses du monde de l'application ». Elles tournent sur le meilleur matériel, sont chouchoutées par les ingénieurs de base de données et se comportent comme des créatures capricieuses. Netflix a délibérément préféré le SGBD Cassandra à d'autres bases de données plus traditionnelles comme celles d'Oracle parce que, en tant que base de données NoSQL, Cassandra peut être dispersée sur plusieurs serveurs, de sorte que, si l'un des noeuds ne répond pas, la base peut quand même continuer à fonctionner. Pendant l'année, Netflix a soumis Cassandra aux attaques de Monkey Chaos, et ses résultats étaient prometteurs. Mais, le redémarrage d'AWS a été le premier vrai test de fiabilité de Cassandra, et toute l'équipe d'ingénierie chargée de la base de données dans le cloud était en état d'alerte.

22 noeuds Cassandra hors service sur 218

Finalement, grâce aux tests effectués avec Monkey Chaos, la plupart des noeuds de Cassandra son restés en ligne. Sur les 218 noeuds Cassandra qui ont subi le reboot, seuls 22 ne sont pas revenus à un état pleinement opérationnel, et ont été remis en route avec succès après une intervention humaine minimale. « Dans son plan de résilience, toute entreprise devrait tester plusieurs fois et régulièrement la fiabilité de son architecture, y compris dans la couche de persistance », conclut le blog. « Si nous n'avions pas mis Cassandra à l'épreuve avec Monkey Chaos, la fin de cette histoire aurait été très différente ».