Netflix nous donne une leçon de cloud computing

Il y a quelques semaines, Netflix est resté up alors qu’une maintenance, à l’initiative de son hébergeur Amazon, privait son infrastructure de plus de 8% de ses nœuds de base de données.

Qui ne connaît pas Netflix ? Le buzz de ces derniers mois avec leur arrivée en France a fini de faire connaître ce service de streaming vidéo basé sur le principe des micro-abonnements ou micro-loyers. Du point de vue IT, la particularité de ce service est qu’il est entièrement hébergé sur AWS, le service de cloud computing d’Amazon.

Le cœur du système de Netflix, comme beaucoup d’autres services d’ailleurs, est la base de données. Netflix annonce gérer plus de 420 To de données et plus d’un billion de requêtes par jour. Pour encaisser cette charge, pas moins de 2700 nœuds actifs en production sont nécessaires ! Chiffres impressionnants tout de même, et on ne parle ici que de la partie database. Ils ajoutent que tout ça fonctionne grâce au très populaire système de base de données réparties, j’ai nommé Cassandra.

La particularité de Cassandra est d’être entre autres decentralized, fault tolerant et elastic. Que voulez vous de plus ? C’est le combo gagnant pour une application dans le cloud.

A côté de ça, le 24 septembre dernier, Amazon prévient ses clients par mail qu’une maintenance est nécessaire sur ses hyperviseurs Xen et que près de 10% de ses hosts vont rebooter entre le 26 septembre et le 1er octobre pour prendre en compte l’upgrade. Il n’est pas question ici de remettre en cause le procédé d’Amazon. Le débat visant à dire que la plateforme de IaaS devrait gérer ce genre de cas et n’engendrer aucune coupure n’est pas de circonstance. Cette question se résume à des histoires de contrat et de SLA. Ici, Amazon annonce un SLA de 99,95% sur son service et les phases d’upgrade font partie du downtime accepté. Le client est au courant du fonctionnement du service et choisit d’y souscrire en toute connaissance.

Plus encore, Netflix a construit son application pour prendre en compte ce genre de cas et quand l’annonce d’Amazon arrive chez eux, Christos Kalantzis (Engineering Manager, Cloud Database Engineering) lance un « même pas peur » sur twitter.

Le jour venu, la maintenance des hyperviseurs est effectuée comme prévu et les database nodes de Netflix commencent à tomber comme des mouches.

1, 2, 15, 83, jusqu’à 218 nodes HS, soit un peu plus de 8% du parc base de données. De quoi donner quelques sueurs aux admins d’astreinte, quoique… Avec 218 nodes à terre, le service tient toujours, Netflix n’affiche aucun downtime. Comme nous l’avons vu, Cassandra sait très bien gérer la perte de membres dans le cluster et la répartition des requêtes a été redirigée automatiquement vers les nœuds actif en excluant du pool ceux qui ne répondaient plus.

Mieux, Netflix avait un système de reprise sur incident qui redémarrait les nodes qui ne répondaient plus et l’ordonnanceur d’Amazon se chargeait de choisir de nouveaux hosts à jour pour démarrer les nœuds.

Out of our 2700+ production Cassandra nodes, 218 were rebooted. 22 Cassandra nodes were on hardware that did not reboot successfully. This led to those Cassandra nodes not coming back online. Our automation detected the failed nodes and replaced them all, with minimal human intervention. Netflix experienced 0 downtime that weekend.

En découvrant cette news le lendemain sur twitter, une vague d’émotion m’a traversé… Pourquoi une simple annonce de ce genre me rend-elle tout chose ? Ce n’est pas la première fois que je vois un mécanisme de HA répondre présent quand on a besoin de lui.

Au-delà du fait que pour un sysadmin, voir des mécanismes de ce genre fonctionner dans la vraie vie est toujours réjouissant, il y a surtout le fait que ce nous a montré Netflix est qu’ils ont construit une application que j’appelle cloud ready. C’est le fameux fonctionnement en mode troupeau. Je peux en perdre une partie, mon application sait gérer ce cas, et je suis capable de retrouver une partie de mon troupeau aussi simplement.

Vous aurez remarqué que sur ce scénario Netflix, la haute disponibilité est de manière classique répartie en trois chaines de responsabilité :

  • la répartition de charge : 2700 noeuds, il faut étaler les requêtes sur tout les nœuds et savoir enlever du pool les nœuds qui ne répondent pas mais également les ajouter quand ils reviennent ;
  • la cohérence des données : le système de base de données Cassandra a à charge de conserver une cohérence des données même en cas de perte d’un nœud en plein travail ;
  • la reprise sur incident : un système permet de lancer un scénario de reprise quand un problème est détecté, ici il s’agit de redémarrer les nœuds ailleurs.

Ces trois chaines de responsabilités répondent ensembles aux prérequis d’une application « cloud ready » :

  • l’application doit être REPARTIE ;
  • elle doit être SCALABLE (capable de faire de la mise à l’échelle en bon français) ;
  • l’application doit être AUTO-REPARANTE.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *