DotScale 2015

Place au rationnel et à la réalisation : robustesse, gestion du reboot, des incidents de productions et de l'analyse des logs

DotScale 2015 : la semaine dernière s’est tenue la 3ème saison de la conférence parisienne dédiée aux architectures techniques massivement distribuées et aux technologies s’y rapportant. Cette conférence d’une journée sur une seule track a pour ambition de réunir la communauté IT (française et au-delà), autour de sessions de 30 minutes, présentées, pour la plupart, par des acteurs reconnus du domaine (pour ne pas dire des rockstars).

Cette année, avons-nous eu droit à un rappel du théorème de CAP omniprésent dès qu’il s’agit d’architecture distribuée et grand vainqueur de l’acronyme le plus fréquemment cité durant la journée. De manière générale, la cohérence et la disponibilité des données persistées sur des architectures distribuées ont été au cœur de plusieurs talks dont ceux de Neha Narula, Sam Bessalah, et Aphyr.

Voici notre sélection de retours d’expérience intéressants.

  1. La gestion automatisée des reboots de serveurs sur un site 24/7, chez .gov.uk, par Matt Bostock.
  2. La gestion concise et pragmatique des incidents de production, par David Mytton,de Server Density
  3. L’infrastructure de collecte et d’analyse de logs chez CloudFlare, de John Graham-Cumming où 4 millions de lignes de log sont traitées chaque seconde.
  4. La robustesse de l’architecture technique de Netflix par Jérémy Edberg qui a présenté la célèbre Simian Army

Enfin, une dernière série de talks présentait quelques technologies modernes, en rapport avec la haute scalabilité (horizontale).

  • Le monde des containers et de l’architecture par microservices par John Wilkes, concepteur de Borg et Kubernetes (outils d’orchestration de containers) chez Google, et par Ben Firshmann, développeur de Fig (un outil de provisionning de containers docker).
  • Les bases de données distribuées dans les talks de Simon Riggs, commiter de PostgreSQL, qui défendait la pertinence du YeSQL face au noSQL, et dans la présentation d’InfluxDB, base noSQL dédiée aux données temporelles par Paul Dix.

De mon point de vue, cette occurrence de la conférence était celle de la maturité.
Les technologies sont défrichées. On était loin de l’effervescence qu’on pu créer, en leur temps, les premières sorties de bases noSQL ou le hype de docker, l’an passé.
Les architectures massivement distribuées ont des contraintes et des difficultés récurrentes connues. Reste maintenant à les prendre en compte dans les implémentations techniques et les organisations humaines.

dotScale 2015, c’était : place au rationnel… et à la réalisation.

Lire les comptes-rendus plus détaillés des talks.

Coordinating unattended server reboots — Matt Bostock, WebOps engineer @ .gov.uk

  • Le site .gov.uk est le point d’entrée unique pour 300 services gouvernementaux UK.
  • 12 millions d’utilisateurs uniques par semaine.
  • Pour maintenir ce site: 2 developpeurs et 1 WebOps.

Les reboots de serveurs sont inévitables de nos jours, même sous Linux:

  • Mises à jour de sécurité nécessitant un reboot du noyau
  • Remplacement de matériel
  • Simplement “nettoyer” le runtime du serveur de reliquats avec un reboot qui applique à nouveau la config. persiste sur disque

Question : comment coordonner le reboot des serveurs en production ?

  • Sans que cela n’impacte la qualité du service rendu aux utilisateurs
  • Sans que cela ne soit une douleur pour les WebOps.

Pour gérer ses updates, CoreOS s’appuie sur Omaha, une techno open-source issue de Google :

  • Double partitions système A et B,
  • On est sur A,
  • On fait une mise à jour sur B,
  • On reboot sur B

Sur Ubuntu, il n’existe pas d’équivalent. Matt a donc mis en place la solution suivante, en s’inspirant de ce qui est fait sur CoreOS :

  • etcd pour stocker un verrou mutex
  • locksmithctl, un cronjob
    • qui intègre une fenêtre de reboot
    • qui pose un flag sous forme de fichier dans /var/run/required_reboot.
    • qui check dans les outils de monitoring si tout est OK au niveau du service rendu par le cluster auquel appartient le serveur.
      exemple: si le serveur est un serveur Web, s’assure que les pages sont bien rendues avec le bon niveau de performance.
    • tente, régulièrement (toutes les 60sec) de récupérer le verrou mutex.
    • Quand les conditions sont réunies,
      • provoque le reboot du serveur
      • puis la suppression du flag
      • et la libération du verrou mutex

Le module puppet qu’ils ont développé pour cet usage : https://github.com/alphagov/puppet-unattended_reboot

(ndla: rien sur le passage en snooze du monitoring du serveur?)

Quelques trucs et astuces, raffinements à venir :

  • Patcher locksmith pour utiliser des multiples endpoints dans etcd.
  • Espacer les reboots de serveurs d’au moins 5 minutes, pour laisser aux services portés par les serveurs le temps de démarrer proprement.
  • Coordonner des reboots parallèles dans différents clusters de serveurs (i.e. 1 serveur Web en même temps qu’un serveur de stockage, par exemple).

Humans at scale, Ops team incident management – David Mytton, founder of server density

David nous présente, de manière condensée, les bonnes pratiques pour préparer et traiter un incident en production. Rien de bien nouveau là-dedans, mais une formalisation efficace et quelques bonnes astuces. D’abord un rappel : au 1er trimestre 2015, Google a dépensé $2,19 milliards pour son run. Amazon a dépensé $870 millions.

Le run a un coût. Et le downtime est inévitable. Il faut s’y préparer

Phase de préparation

  • Pour les astreintes téléphoniques, prévoir un contact primaire et un contact secondaire, avec des règles formelles de disponibilité.
  • Le contact primaire doit être disponible et intervenir sur l’incident en quelques minutes.
  • Le contact secondaire peut être disponible en quelques dizaines de minutes. Sa capacité à intervenir sur incident peut être plus longue.

Avoir compilé à disposition les informations clés :

  • Liste des contacts dans les équipes
  • Liste des contacts chez les fournisseurs, vendeurs, contrats de maintenance
  • Disposer des droits d’accès clés.

Le terme “à disposition” a son importance : quelque soit l’état de l’infrastructure que l’on manage, ces outillages doivent être disponibles. Un hébergement extérieur est donc recommandé. De la même manière, il est préférable que les contacts primaire et secondaires aient des FAIs différents.

Pour les situations imprévues:

  • Disposer d’un canal de communication dédié aux incidents et connu de toutes les parties prenantes

    • Liste de diffusion,
    • Room dans un outil de messagerie instantanée
    • Conférence téléphonique
  • Disposer d’un accès Internet… éventuellement redondé
  • Disposer des accès à tous les contrats de maintenance / support chez les vendeurs

Phase d’intervention

Premiers éléments d’intervention:

  • Récupérer la checklist qui détaille les étapes de réponse à incident
  • Ouvrir et se connecter au canal de communication dédié aux incidents
  • Logger l’incident dans JIRA
  • Commencer l’investigation en suivant la checklist

Les principes fondamentaux d’intervention:

  • Noter toutes les actions
  • Faire des mises à jour publiques du statut, publiquement
  • Constituer l’équipe d’intervention selon ses compétences et ses meilleures chances de succès
  • Escalader l’incident en cas de difficulté!

Post-mortem

Il s’agit d’un rituel qui se tient quelques jours après l’incident, on y raconte comment ça s’est passé

L’objectif est de fournir le bon niveau d’information et de détails techniques. Pas de précision excessive.

Les principales questions auxquelles il faut répondre sont :

  • Qu’est-ce qui n’a pas marché?
  • Pourquoi?
  • Comment peut-on fixer cela pour que ça ne se reproduise pas?

Timeseries data in distributed databases — Paul Dix, creator of InfluxDB

Probablement le talk le moins convaincant de mon point de vue… même si InfluxDB a le vent en poupe et une vraie pertinence.

Spécificités d’usage des données temporelles

Dans un premier temps, Paul nous explique pourquoi les données temporelles sont spécifiques et représentent le pire scénario pour un stockage distribué :

  • Des données en append,
  • Requêtes et suppressions par range et non par élément,
  • Beaucoup d’écritures avec une densité de stockage variable (selon que les données temporelles sont régulières ou irrégulières).

Stockage distribué inadapté

Dans un second temps, il nous explique pourquoi le stockage en base de données distribuée pose un problème : la dispersion du stockage des données temporelles pour une fenêtre de temps requêtée (en lecture ou en suppression) nécessite d’aller interroger tous les nœuds pour récupérer l’ensemble des données pour une agrégation finale sur le nœud de requête.

Solution : sharding par time range

Conclusion de la démonstration: il faut stocker les données temporelles en partitionnant le stockage par fenêtres temporelles. Ainsi le requêtage se fait en interrogeant les nœuds stockant les shards de ces fenêtres temporelles. CQFD

Pour plus de détail, on pourra lire: http://influxdb.com/docs/v0.8/introduction/getting_started.html

Et visionner cette présentation :

Google Borg Kubernetes — John Wilkes, co-author of Omega Borg @ Google

John nous a présenté l’architecture de Google Borg, l’orchestrateur de jobs containerizés qui est utilisé chez Google. L’avantage essentiel qu’il en retire, c’est la meilleure utilisation des ressources matérielles mises à disposition pour faire tourner des jobs. Il cite un papier sur Borg : http://goo.gl/1C4nuo : Large-scale cluster management at Google with Borg

Quelques petites anecdotes:

  • Quand John parle de petits clusters, il veut dire 5000 servers. :-0
  • Il préconise de ne pas spécialiser les clusters batches vs. jobs temps réel, cette spécialisation ayant tendance à consommer des ressources de manière sub-optimale.
  • Pour John, l’erreur fait partie du jeu. Quand il commande 10 000 jobs à Borg, il en obtient 9993 et ça lui va parfaitement. Seul le service rendu compte.
    Il monitore donc le k-eviction rates causes.

Lighting talks

Ces talks de 5 minutes ont pour seul ambition de nous faire découvrir quelques sujets de manière très rapide.

Docker in IDE — Mario Loriedo

Mario nous présentait l’intégration de l’usage de Docker dans Eclipse, via un plugin doclipser. Ce plug-in permet l’édition de Docker files dans Eclipse, avec coloration syntaxique et autocomplètement. De manière plus générale, le projet domeide sur Github a pour volonté de référencer toutes les intégrations de Docker à des IDE.

Aujourd’hui:

  • Eclipse
  • Sublime Text
  • vim
  • emacs
  • IntelliJ
  • Atom

Your system is distributed whatever you like it or not — Sam Bessalah

On ne présente plus Sam, chancre des architectures distribuées de l’IT parisienne. Organisateur du meetup Paris Datageeks. Il tape du poing sur la table et nous met face à une évidence. Les architectures distribuées sont notre quotidien. Dès lors, il est nécessaire de comprendre les bases académiques du sujet. En particulier, comprendre les principes du théorème de CAP, d’ACID, de PAXOS, etc. Pour joindre l’acte à la parole, il nous présente son nouveau meetup dédié au partage de connaissance sur ces travaux académiques: Papers we love — Paris.

Consistency and Candy Crush — Neha Narula, ex-googler

Neha revient sur les principaux principes de cohérence que l’on rencontre en informatique:

  • Au sens ACID (une cohérence applicative des données)
  • Au sens du théorème de CAP (une homogénéïté des données sur une population de persistance distribuée),
  • Du modèle

serializability != serial execution

Internet-sized computer — Ben Firshmann, creator of fig

Ben est le créateur de fig, premier mécanisme de coopération simple entre containers Docker. Depuis, fig a été racheté et est devenu Docker Compose.

Dans son talk, Ben explique les avantages des containers sur la virtualisation, de sa vélocité de mise en œuvre et de son caractère portable. En poussant un peu, il ose une analogie intéressante : un docker run serait une forme moderne de fork-exec, qui embarquerait son contexte d’exécution à un niveau système. Il conclue son talk sur une vision extrême: et si demain, le container avait une durée de vie de l’ordre de la requête ou de la session utilisateur ?

Databases, the long view — Simon Riggs, major contributor to PostgreSQL

Dans ce talk en forme de rétrospective, Simon Riggs aborde la pertinence renouvelée du modèle SQL. A ses débuts il fallait faire les optimisations dans les datasets à la main. Le standard SQL permet au moteur de procéder à des optimisations automatiques du stockage et du requêtage des données.

Certaines douleurs existantes ont été levées au fil du temps :

  • Le DML locking a cédé par l’introduction des locks non-bloquants avec Oracle 7
  • Les mises à jour de DDL trop lentes ont connu une réponse en 2010…

Bien sûr, les datawarehouses et les bases noSQL ont remis au goût du jour la règle de Stonebraker : pour chaque cas d’usage, il y a une manière optimale d’agencer la donnée.

Mais il établit aussi un état des lieux factuels et pragmatiques de la situation en entreprises :

  • Les plus grosses bases de données sont les bases d’audit
  • Puis les datawarehouses
  • On a ensuite ~50 autres bases de données
  • et 750 dépôts de données divers…
  • Mais 90% de ces bases font moins de 10Go
  • et 99% font moins de 100Go.

Il passe ensuite en revue les évolutions récentes et à venir de PostgreSQL:

  • Sur le sharding à échelle deux ans dans le trunk
  • Le parallel querying inspiré de Oracle
  • L’exécution d’une requête sur un échantillon du dataset (les données que l’on obtient durant un laps de temps défini, par exemple) via “TABLESAMPLE”

Un des slides de Simon est pour le «YeSQL !» (en opposition au NoSQL évidemment) et précise que «persistence is everything«.

Jepsen IV — Kyle Kingsbury aka Aphyr

Aphyr est un personnage bien connu, qui a mis au point une solution de test des architectures distribuées nommée Jepsen. Depuis 2013, il passe au banc de tests les moteurs de persistance distribuées que sont les bases noSQL et autres message brokers et en publie donc les résultats sur son blog… Son blog est une référence dans le domaine et bon nombre d’équipes suivent ses préconisations avec intérêt pour améliorer leurs produits. Sa présentation était une certaine paraphrase de ses articles de blog, aussi je n’en ferai qu’un bref résumé.

Selon lui, il convient de tester son système distribué in situ, en se concentrant sur plusieurs aspects:

  • L’incident au niveau du processus (kill -9, kill -s STOP / CONT)
  • L’incident au niveau du serveur
  • Un incident d’horloge affichant un timestamp incohérent
  • La pause liée à une garbage collection ou à une attente d’I/O.
  • La partition au niveau du réseau

Suite à cela, il prend 3 exemples : mongoDB, ElasticSearch et Aerospike. Si le premier accuse toujours certaines faiblesses déjà pointées par Aphyr dans son blog, par le passé, ElasticSearch semble sur la bonne voie. Quant à Aerospike, il affiche carton plein en terme de non-résilience…

10 trillions log lines per day — John Graham-Cumming, programmer @ CloudFlare

Sans doute le talk le plus intéressant de la conférence !

Contexte

Première blague de cette série de talks sur le fait que CloudFlare est une société de traitement de log qui fait aussi du CDN. Chez CloudFlare, 1 000 milliards de lignes de log sont produites chaque jour. Ca fait :

  • 4 millions de lignes à la seconde
  • 400 To par jour
  • et 146 Po par an.

L’échelle donne le tournis, mais le problème principal, c’est surtout comment retrouver du signal au milieu de tout ce bruit. Ou comment détecter l’incident au milieu de cette masse de lignes “normales”.

Architecture

Pour cela, CloudFlare a mis en place une architecture d’analyse de stream de logs.

  • NGinx + LuaJIT
    LuaJIT est un outillage de scripting extrêmement véloce, capable de traiter des centaines de règles de routage / filtrage en 1 ms.
    (On pourra aussi regarder le fork de NGinx : openresty)
  • Produit des messages au format Cap’n Proto avec compression LZ4.
  • Ces messages sont poussés dans un cluster Kafka, qui joue le rôle de tampon asynchrone d’alimentation (capacité de stockage ~24 heures)…
  • … de workers maison écrits en GO.
    Ces workers traitent “fonctionnellement” les messages fournis par Kafka.
    Si une anomalie est détectée…
  • Le message est conservé sous une forme plus exploitable dans des bases CitusDB (bases dédiées par client…).
    CitusDB est une implémentation de PostgreSQL orientée haute performance et haute disponibilité.
  • CitusDB offre des possibilités de sharding en natif
  • Datacenter dédié aux US à la collecte de logs de l’ensemble de leurs edge locations CDN.

Sizing

Chez CloudFlare, les servers sont des designs custom spécialement conçus par Quanta. Dans 2 U, ils font tenir 4 nœuds.

Chaque nœud représente 16 cores, 128 Go de RAM.

Cluster Kafka 40 nodes / 640 cores / 5 Po RAM15 GBps en entrée
Cluster CitusDB 5 nodes / 80 cores / 640 Go RAM60 To de disques SSD
Cluster de workers Go >100 nodes / 1 600 cores / 12,8 Po RAM

Algorithms

Bien sûr, avec des enjeux de volumétrie pareils, ils ont sélectionné les algorithmes avec minutie. Pour économiser de l’espace, ils se sont pencher sur le papier académique “Efficient computation of frequent and top-k elements in data stream” de l’UCSB. Mais il s’est révélé inefficace pour traiter les événements de longue traine. Ils se sont rabattus sur l’algorithme HyperLogLog, mis en œuvre, entre autre, par Cassandra. Enfin, CloudFlare fait énormément de contribution en open source.

Disque — Salvatore Sanfilippo aka Antirez, creator of Redis

Antirez nous présentait son nouveau projet, un message broker distribué nommé disque (prononcez disqiu).

Ce projet reprend les grands principes de Redis :

  • License BSD
  • Produit in-memory
  • Persistence disque optionnelle

Ensuite, on est dans du standard de message broker moderne :

  • Permet l’exécution de jobs asynchrones
  • API disponible
  • Acknowledge de consommation de message est explicite
  • La consommation répond à des règles :
    • livraison à au moins un client
    • on peut aussi arrêter la livraison après livraison au 1er client
  • Capacité de retry en cas de non-consommation d’un message
    • et donc TTL du message (au-delà duquel il est considéré comme caduque)
  • Réplication synchrone par défaut
  • Réplication asynchrone en option
  • Persistence sur disque en option

Les spécificités du produit :

  • Une option rarement vue : un délai avant lequel le message n’est pas poussé en livraison
  • et surtout : par design, le respect de l’ordre des messages dans la file est en mode best-effort, ce qui permet d’avoir une file unique distribuée sur le cluster avec une grande vélocité.
  • Le produit se positionne clairement sur AP dans le théorème de CAP. Le produit gère l’eventual consistency en mode best effort.

Jeremy Edberg, first SRE @ Netflix

Jeremy nous explique comment créer une architecture à microservices viable.

Pourquoi une architecture à microservices ? Parce que c’est le modèle naturel de toute société en croissance forte :

  1. on commence avec une architecture monolithique,
  2. puis on externalise quelques services,
  3. puis on passe sur une architecture à microservices… maison la plupart du temps.

Il présente déjà une marguerite qui décrit ce qu’une architecture à microservices doit prendre en compte :

  • Déploiement continu
  • Supervision et alertes
  • Configuration du réseau et du trafic
  • Découverte des services et des ressources
  • Tests automatisés
  • Sécurité

Parmi ses conseils martelés encore et encore : ne réinventez pas la roue.

Quelques petites phrases :

  • « How many of you have written software for a company that wasn’t part of the main product? »
  • « Postgres’ code is the most beautiful code you will ever read »
  • « Don’t build your own load balancer » (il cite haproxy (en bien), précise qu’il faut utiliser du « Consistent key Hash (Algorythm) »
  • « Dont build your security tools »

Dans les organisations matures, 25% du temps du développement est consommé à travailler sur l’architecture à micro-services. Et cela s’arrête souvent à “ça fait le job”. Là où des solutions communautaires existent et dans des formes plus abouties. Votre architecture existe ailleurs, des solutions existent sur étagère.

En particulier pour la sécurité : ne construisez pas votre architecture de sécurité. C’est un métier.

Côté service discovery, il écarte DNS et zookeeper (parce que c’est un SPOF [probablement en considérant une échelle de plateforme planétaire] !)

Bien sûr, il fait la part belle à la Simian Army de Netflix. Ces automates qui produisent des perturbations aléatoires sur la plateforme, pour éprouver sa robustesse :

  • Chaos monkey, qui tue des processes
  • Chaos gorilla, qui tue des datacenters entiers
  • et enfin chaos kong, qui tue des availability zones entières d’Amazon.
  • Il y a aussi latency monkey qui introduit de la latence (réseau) au sein de la plateforme

Ces 4 soldats hominidés permettent aux ingénieurs de constamment améliorer leurs architectures de routage de flux réseau vers des zones disponibles, de réplication de la donnée sur des régions multiples, etc. Et de reproduire des contextes d’incidents que les infrastructures d’Amazon Web Services ont pu connaître par le passé.

Enfin, il conclut ainsi : « break systems in production, intentionally and repeatedly in order to be sure of its resilience«