J’ai eu l’opportunité d’assister à dotScale 2015, la “dot-conférence” dédiée à la scalabilité. Au programme, 11 talks dans un unique track. Résumé de cette journée…
Coordinating unattended server reboots – Matt Bostock – Web Operations Engineer at Gov.uk
Matt s’occupe de l’hébergement de Gov.uk, l’équivalent Anglais de service-public.fr, un site qui regroupe 300 sources de données et génère 12 millions de visites par jour. Il nous explique que les serveurs doivent être rebootés régulièrement, notamment pour installer des mises à jour de sécurité (Heartbleed…).
L’équipe s’est inspirée du fonctionnement de CoreOS qui :
- utilise deux partitions système : les mises à jour sont automatiquement installées sur la seconde partition et, lors d’un reboot, les partitions sont échangées (Cf. https://coreos.com/using-coreos/updates/)
- fait appel à un lock distribué pour rebooter une seule machine à la fois : locksmith qui repose sur etcd.
L’équipe de Gov.uk utilisant des serveurs sous Ubuntu, ils ont uniquement répliqué la stratégie de lock afin de répartir les reboots durant une plage horaire. Les reboots sont automatisés (“unattended”) ce qui était stressant au début. À noter que ces redémarrages sont uniquement effectués la nuit pour ne pas impacter la production pendant les heures pleines (de 8h à 21h).
Scaling Humans – David Mytton – Founder of Server Density
David débute sa présentation en citant le coût de l’uptime chez les grands de l’Internet sur le premier trimestre 2015 : 2,9 milliards de $ pour Google, 870 millions de $ pour Amazon, 4,1 milliards de $ pour Microsoft.
Garantir l’accès à l’information a un coût et il faut se préparer pour gérer les situations de crise. Des check-lists sont préparées à l’avance (c’est plus sûr quand un Ops doit intervenir en pleine nuit), un channel de War Room est prévu (sans distraction) et les incidents sont rapportés dans Jira. Après chaque incident, un post-mortem est réalisé.
Surtout, David donne de précieux conseils : vous devez avoir au moins 2 Ops et au moins l’un deux doit être disponible (pas d’absence simultanée). Ils ne doivent pas être chez le même FAI pour éviter que les deux soient injoignables en cas de panne d’infrastructure, et vos outils de communications ne doivent pas être hébergées sur les mêmes plateformes que vos serveurs de production…
Time series data is the worst and best use case in distributed databases – Paul Dix – Creator of InfluxDB
Le stockage de time series est un use case très particulier pour les bases de données : les données sont en append-only (jamais de modifications), les suppressions se font par blocs entiers et non élément par élément, la charge en écriture est importante, les lectures se font par range de timestamps… Les structures de stockage des bases de données généralistes ne sont pas adaptées à ce use case.
InfluxDB est une base de données open source spécialisée pour le stockage et le requêtage de time series. Le langage de requête est proche du SQL et dispose d’opérateurs permettant la manipulation de dates. Des requêtes d’aggrégation et des requêtes continues (“continuous queries”) sont possibles.
Le produit semble arriver à maturité, notamment avec les versions récentes qui visent à améliorer la stabilité.
Cluster management at Google with Borg – John Wilkes – Principal Software Engineer at Google
John est à l’origine de Borg, l’outil de gestion de cluster utilisé en interne par Google pour faire tourner ses applications. Il explique que de grands nombres de serveurs sont utilisés pour déployer de nombreuses instances d’applications. Chaque jour, sur 2000 serveurs, 10 applications s’arrêteront en raison d’un problème d’infrastructure : problème matériel, plus de mémoire sur le serveur, etc. Les erreurs (“failures”) doivent être considérées comme quelque chose de normal et doivent donc être anticipées dans l’architecture des applications.
Toute une part du travail de John consiste à utiliser au maximum les ressources disponibles sur les serveurs. En effet, chaque application consomme des ressources (mémoire, CPU, réseau…) et il faut combiner au mieux les applications pour répartir la charge sur les serveurs. Si trop peu d’applications sont déployées par serveur, les ressources sont sous-utilisées. À l’inverse, il peut y avoir des cas de sur-utilisation des ressources (les applications peuvent alors échouer pour cause d’OOM).
John termine en parlant de Kubernetes qui est l’équivalent open source de Borg pour faire tourner des containers Docker. Il indique notamment que l’expérience acquise sur Borg bénéficie à Kubernetes.
Consistency and Candy Crush – Neha Narula – PhD student at PDOS, ex-Googler
Neha évoque le problème de la consistence de la donnée et notamment les nombreux modèles, des plus forts (strict consistency, sequential consistency…) aux plus faibles (read-your-writes consistency, eventual consistency…). Elle rappelle que les modèles les plus stricts ne sont pas parallélisables et donc pas adaptés aux serveurs actuels disposants de nombreux coeurs.
Son conseil est surprenant : préférez le modèle “serializable” et ne relâchez la consistence que si vous rencontrez des problèmes de performance. En changeant de modèle, vérifiez l’impact sur vos données.
Internet sized computers – Ben Firshman – Co-founder of Orchard, Product Manager at Docker
Ben est le créateur de Fig, maintenant devenu Docker Compose. Il rappelle que les ordinateurs étaient au début très coûteux, que l’on est passé au stade du “commodity hardware” sur lequel on a virtualisé des serveurs, et que l’on utilise désormais des containers pour lancer des applications sur ces serveurs. Lancer un process dans un container est maintenant aussi simple (et presque aussi rapide) que de lancer un processus en local (via un fork-exec).
Ben indique qu’il est aisé de lancer une batterie de process sur un cluster de serveurs pour distribuer une charge de travail (Cf. la commande parallel). Et si Internet était un ordinateur géant sur lequel chaque requête HTTP lançait un container ? Une vision de l’avenir qui laisse songeur…
Databases, the long view – Simon Riggs – Major Contributor to PostgreSQL, Founder of 2ndQuadrant
Simon utilise des bases de données depuis 30 ans (!) et il indique de le langage SQL est une formidable avancée : vous – développeur – indiquez les données que vous souhaitez récupérer et la base de données se charge d’optimiser dynamiquement l’exécution de la requête pour vous (vous n’avez plus à optimiser statiquement la requête).
Simonl parle des options offertes dans PostgreSQL pour régler la consistence des requêtes et il insiste sur les travaux en cours et à venir : sharding, massive parallel query…
Le moins que l’on puisse dire est que PostgreSQL est extrêmement appréciée dans la communauté et est citée en référence par d’autres speakers.
Jepsen IV – Kyle Kingsbury aka Aphyr – Creator of Riemann & Jepsen
Un talk détonnant du créateur de Jepsen, l’outil permettant de tester le comportement des bases de données lors de partitions réseaux. Aphyr nous rappelle le théorème CAP en nous expliquant que, si un database vendor vous expose sa base de données comme ayant chacune des 3 propriétés du théorème à la fois, il vous ment probablement…
Un tour des différentes bases de données est effectué en citant leur problèmes de pertes de données (plus ou moins graves). À retenir absolument : toutes les bases de données ont des défauts, ne leur faites pas confiance, testez-les vous-mêmes…
Si vous ne connaissez pas les rapports “Call me maybe”, ils sont en ligne.
John Graham-Cumming – Programmer at CloudFlare
John parle de l’infrastructure de gestion des logs du CDN CloudFlare. L’entreprise dispose de serveurs répartis dans de nombreux datacenters dans le monde mais les logs sont centralisés et traités dans un datacenter unique.
Chaque jour, 400 TB de logs sont traités (mais pas stockés) et plus précisément 4 millions de logs par seconde ! Les logs sont générés par Nginx, sérialisés avec Cap’n Proto, et placés dans une file distribuée de 40 noeuds Kafka pour être traités. Des traitements en streaming sont effectués pour bloquer des DDoS et des agrégations sont effectuées pour fournir des métriques aux clients (stockage dans PostgreSQL et CitusDB).
Une infrastructure impressionnante ! Plus de détails sur ce post de blog.
Disque – Salvatore Sanfilippo aka antirez – Creator of Redis
Une fois n’est pas coutume, Antirez ne parle pas de Redis mais présente Disque, une file de messages distribuée. Disque repose sur une partie du code de Redis et garantie une sémantique “at least once delivery”. Les consommateurs doivent accuser réception des messages pour indiquer que ceux-ci ont été traités. L’ordre de livraison est en “best effort” car il n’est pas possible de garantir un ordre strict, notamment si un message re-rentre dans la file en cas de défaut d’acknowledge.
Disque semble être un projet prometteur et donc à suivre de près.
Jeremy Edberg – Former Reddit Chief Architect, First SRE at Netflix
Jeremy livre des conseils sur les différents aspects des architectures micro-services. Ils indiquent que de telles architectures sont compliquées à mettre en oeuvre et qu’il vaut mieux rester sur des systèmes monolithiques si cela est possible. Par ailleurs, Netflix a open sourcé ses outils mais il n’existe pas de plateforme standard pour construire des micro-services. Par exemple, la question du service discovery reste délicate : DNS n’est pas adapté et l’outil de la stack Netflix (Curator) reste complexe.
On connaissait bien le Chaos Monkey qui tue des services au hasard pour tester la résilience, mais Jeremy présente également le Chaos Gorilla qui tue des datacenters entiers, le Chaos Kong qui déplace du traffic réseau d’une zone vers une autre, et le Latency Monkey qui introduit de la latence de traitement dans les requêtes. De quoi tester la résilience de son infrastructure…
Le mot de la fin
Cette journée était riche en découverte et nous rappelle qu’il faut être humble face à des problèmes complexes de scalabilité.
Un big up à Sylvain Zimmer qui a brillamment animé cette journée et pour les interviews très pertinentes des speakers à la fin de chaque talk.
