Travailler dur pour augmenter la disponibilité

Le mois dernier, la plateforme a subi quelques pannes. L'une d'elles était plus importante et a conduit à un article de blog post-mortem pour expliquer à nos clients ce qui s'est passé https://scalingo.com/articles/2015/07/29/outage-of-wed-29th-july-postmortem. Après quelques semaines de réflexion, nous avons établi une liste de tâches à accomplir pour améliorer la disponibilité globale de la plateforme. Cet article détaillera les actions qui ont suivi la panne et ce qui est prévu maintenant.

Fait : Notification d'alertes critiques

Tout d'abord, nous ne pouvions pas manquer une autre alerte serveur comme nous l'avons fait le 29 juillet. C'est pourquoi nous avons intégré PagerDuty comme service de notification. PagerDuty est déclenché chaque fois qu'une erreur considérée comme ‘critique’ est levée. Les notifications d'alerte ne s'arrêtent pas tant qu'un membre de l'équipe ne les a pas reconnues.

Fait : Monitoring de bout en bout de l'infrastructure

Une nouvelle entité, externe à l'infrastructure, déploie désormais des applications plusieurs fois par heure. Grâce à cela, nous pouvons être sûrs que la chaîne de production complète fonctionne comme prévu. Si quelque chose ne va pas, une alerte est déclenchée et l'équipe est prévenue immédiatement.

En cours : Pour plus de transparence, une page de statut arrive

https://scalingostatus.com/ est en cours, ici nous pourrons afficher plus transparently les problèmes que l'infrastructure rencontre. Cela nous permettra également de donner des informations en temps réel sur le processus de récupération de l'infrastructure ainsi que sur les fenêtres de maintenance qui peuvent perturber la plateforme.

Externaliser les builds

Nous avons détecté que la partie la plus sensible de l'infrastructure est le processus de construction. Le build est le processus qui se produit lorsque vous commencez un nouveau déploiement. Il télécharge, décompresse, compile (parfois) de nombreux fichiers et cela peut consommer beaucoup de ressources.

Jusqu'à présent, les builds étaient effectués dans des conteneurs sur les mêmes serveurs qui exécutent effectivement les applications des utilisateurs, mais nous avons découvert que cela pourrait dégrader les performances des applications plus que nous le pensions. Nous avons d'abord décidé de limiter les ressources du conteneur de build, mais cela nous a conduits à un taux élevé d'erreurs impactant l'ensemble du serveur. (Voir la prochaine partie concernant BTRFS)

Backend de stockage Docker BTRFS, le temps du changement ?

Ce n'est un secret pour personne que nous avons fait le choix d'utiliser Docker comme technologie d'isolation pour les applications de nos utilisateurs. Depuis le début de son développement jusqu'à nos jours, trois systèmes de fichiers ont été expédiés comme “stables”. Nous les avons tous utilisés et nous avons des sentiments mitigés à leur égard.

Tout d'abord, nous n'avions pas le choix, nos serveurs utilisaient AUFS comme backend de stockage pour Docker, puis lorsque Red Hat a poussé Docker à supporter ext4-devicemapper, comme nous avions quelques bugs ennuyeux avec AUFS, nous avons décidé de migrer notre infrastructure vers ce backend.

Avec le mappage de périphériques, les performances de création/suppression de conteneurs ont chuté considérablement, mais dans l'ensemble, nous avons rencontré des problèmes de blocage sérieux avec ce backend de stockage. (exemples : https://github.com/docker/docker/pull/4951, https://github.com/docker/docker/issues/5653)

Nous étions plutôt heureux lorsque BTRFS a été intégré à Docker et considéré comme stable car c'était un autre choix prometteur. Au début, il nous semblait que c'était le pilote le plus efficace pour Docker, rapide et stable. Mais au fur et à mesure de notre montée en charge, le nombre d'opérations appliquées sur la partition a entraîné de nouveaux problèmes. Récemment, deux pannes d'un serveur impactant certaines applications clientes étaient liées à ce qui semble être un blocage de BTRFS.

Jusqu'à présent, aucun système de fichiers ne nous semblait parfait. Récemment, avec Docker 1.7+, deux nouveaux backends ont été intégrés au produit, overlayfs et ZFS (toujours étiqueté comme expérimental https://github.com/docker/docker/pull/9411). Nous allons probablement les essayer afin de trouver une meilleure alternative et d'améliorer la stabilité globale de la plateforme.

Toutes les choses doivent être distribuées et tolérantes aux pannes

Certains de nos composants fonctionnent encore avec redis comme backend pour gérer les files d'attente de messages (Sidekiq, go-workers). Même si redis est une excellente base de données avec des fonctionnalités intéressantes pour gérer les queues, ce n'est pas une base de données distribuée. Redis sentinel et cluster valent la peine d'être examinés, mais ils ne sont pas conçus pour être un moteur de file d'attente de messages sans temps d'arrêt. C'est pourquoi, nous allons migrer tous les composants pour utiliser NSQ http://nsq.io/. Ce logiciel, une fois installé sur plusieurs nœuds, est hautement disponible et ne contient aucun point de défaillance unique. Cela nous aidera à gérer plus sereinement les pannes de nœuds.

Améliorer l'isolement et la récupération des serveurs dysfonctionnels

Il existe plusieurs cas où les serveurs peuvent être considérés comme dysfonctionnels. Quel que soit le problème, matériel, réseau, bugs logiciels ou gel du noyau, la priorité est de l'isoler. Peu importe si toutes les applications d'un nœud ou seulement une sont affectées, cela doit être détecté et géré. Les problèmes importants sont faciles à détecter, il est beaucoup plus difficile de détecter des anomalies mineures. Une partie de cela devrait et peut être faite automatiquement, les applications doivent être déplacées immédiatement. 

Stocker les images des applications dans une solution de stockage d'objets

Aujourd'hui, le registre des images est hébergé aux côtés du nœud d'applications, cela génère beaucoup d'IO disque et réseau pour distribuer des images à l'ensemble de l'infrastructure. Même si le stockage est redondant et hautement disponible, nous savons qu'à une certaine échelle, cela ne sera tout simplement pas suffisamment efficace.

Une partie de ce problème peut être résolu en utilisant une solution de stockage externe, plus particulièrement, une solution de stockage d'objets. Elle a l'avantage d'abstraire complètement le backend de stockage, sa capacité ainsi que sa capacité à évoluer et à être facilement interfacée avec n'importe quelle technologie.

Haute disponibilité des bases de données

Aujourd'hui, les addons que nous proposons sont à nœud unique. Il n'est pas possible de créer une haute disponibilité sans redondance. C'est pourquoi l'un de nos grands objectifs aujourd'hui est de vous permettre de choisir et/ou de mettre à niveau des bases de données hautement disponibles, avec l'assurance que le cluster de bases de données sera situé près de votre application et conservera de bonnes performances comme aujourd'hui. Nous sommes actuellement à la recherche du meilleur modèle qui serait facile à intégrer dans vos projets. Notre objectif est de le faire complètement de manière transparente pour vous et vos applications.

Conclusion pour aujourd'hui

Notre priorité est de fournir la meilleure qualité de service possible. Il n'y a pas de solution miracle pour cela, de nombreuses décisions et actions doivent être envisagées et appliquées. Comme détaillé dans cet article, nous avons commencé à travailler pour améliorer la stabilité globale de la plateforme. Cette liste est loin d'être exhaustive, et nous communiquerons dans d'autres articles nos progrès dans ce domaine.