dotScale 2014
19 May 2014Introduction
Première édition de dotScale, petit frère des dotConférences. Encore une fois, ça avait lieu dans un endroit magnifique, qu'est le théatre de Paris. La salle était loin d'être complétement remplie, ce qui permet à chacun de s'installer où il le souhaite. Et c'est tant mieux, car comme souvent dans ce genre de théatre, toutes les places ne sont pas égales. Et pour peu que vous ayiez envie d'être installé confortablement et de prendre des notes sur votre laptop, ça devient compliqué.
Néanmoins, j'ai pu me trouver une place dans l'une des loges VIP sur la gauche de la scène, ce qui me donnait une vue parfaite et plongeante sur les présentations.
Retour d'expérience sur healthcare.gov
Robert Kennedy, employé Google, nous a fait le deuxième retour d'expérience de la conférence. Il est allé aidé le projet healthcare.gov, dont vous avez sans doute déjà tous entendu les déboires. Je ne connaissais pas le détail technique de pourquoi ça s'était cassé la gueule, et c'était intéressant d'avoir ce retour de cette horror story vue de l'intérieur.
Le projet complet de réforme du système de santé repose sur le bon fonctionnement du site web. Le fait que le site soit dans les choux pour une durée indeterminée dès le jour de son lancement à fait les unes des journaux.
Globalement le site était dispo, il pouvait recevoir du traffic, mais il était complétement instable. Plusieurs éléments de son archit étaient des SPOF et il n'était pas conçu pour scaler aisement.
Au moment où notre gars est intervenu, ils avaient une nouvelle deadline, quelques mois plus tard, où le site allait devoir ouvrir, à plus de monde encore, et donc faire face à un afflux encore plus important.
La majorité des problèmes ne venaient pas réellement de mauvais choix techniques, mais plus de problèmes humains. Le projet avait été splitté en une douzaine de modules différents commandés à autant d'agences différentes. Chacune faisait son affaire dans son coin, avec des niveau de qualité différents, mais surtout personne n'était en charge de faire fonctionner les modules ensemble. L'idée était que si chacun faisait correctement son travail, alors tous les bouts allaient magiquement s'emboiter à la fin. Comment dire ? non.
Ils n'avaient pas non plus de monitoring centralisé des modules. Certains avaient fait leurs propres outils (en console, en web view, sous forme d'export régulier) mais la plupart n'avait absolument aucune idée de si leur système était up ou down à part en vérifiant manuellement. L'une des premières choses qu'ils ont mis en place a été d'aggréger en une vue simplifie les infos les plus importantes qu'ils avaient : nombre de requetes, % d'erreurs et consommation CPU. Ils l'ont enrichi au fur et à mesure avec les datas qu'ils arrivaient à récupérer des différents modules.
A chaque fois que le site était down, il leur fallait quand même aller voir chaque responsable un par un en leur demandant si leur partie était bien opérationnelle.
D'un point de vue archi, leur infra n'est pas trop déconnante. Un frontal web qui tape vers un gateway qui s'occupe de l'authentication, et si ok renvoie vers la couche métier. Celle-ci s'occupe d'aggréger des résultats de service de plein d'API d'autres ministères et organismes pour calculer ce à quoi l'internaute à droit. Le processus métier étant long et complexe, dans certains cas les internautes doivent le faire en plusieurs fois, le temps que leur demande soit manuellement traitée. Il faut donc sauvegarder dans un coin l'état de leur demande pour qu'ils puissent y retourner plus tard. Ils stockent donc tout ça dans une DB en xml.
Apparemment, ils avaient un système de cache mal configuré là dedans qui créait dans certains cas plus de requetes qu'il n'en absorbait. Rajoutons à cela qu'ils ont eu besoin de stocker des fichiers, beaucoup de fichiers, ils ont donc commandé des serveurs pour ça, et les X modules se sont mis à écrire dessus jusqu'à remplir le serveur. Ils en ont donc rachetés de nouveaux, et rebelote. Au final, ils avaient 19 serveurs de stockage de fichiers où les X modules qui constituent l'application écrivaient leurs infos. Chacun de ces 19 serveurs était un SPOF car il contenait potentiellement des infos nécessaires à tous les modules... Rajoutons à cela que si l'un deux plante, ils n'ont aucune procédure automatique pour les ramener à la vie (et bien sur aucune redondance), du coup il fallait manuellement se connecter sur les machines pour remonter le filesystem manuellement. Et bizarrement, on ne pouvait pas remonter les machines dans n'importe quel ordre, il fallait forcément les remonter dans un certain ordre, sans que l'on sache pourquoi, mais au moins on connait l'ordre... ça faisait un peu vaudou...
Ensuite, l'une des histoires les plus intéressantes de toute la conf est celle du jour où ils ont pu voir sur leurs outils que toutes les requetes entrantes retournaient des erreurs, et que la latence moyenne avait baissée de 200ms à 10ms. Comme ils n'avaient toujours pas d'outils vraiment précis pour isoler le problème, ils ont déduit qu'il y avait un soucis avec la DB (la DB est généralement la partie qui cause la plus grande latence, si celle-ci droppe à 0, ça veut dire qu'elle n'est sans doute plus sollicitée).
Comme d'hab, il font manuellement le tour de tout le monde pour leur demander si leur système est up. Les gars de la DB s'apercoivent que depuis 10h30 le matin, toutes leurs requetes en DB leur retournent une permission denied error.
J'ai oublié de le dire précédemment, mais pour faciliter encore les choses, les différentes agences sont réparties à 3 endroits des USA différents, et ont une pieuvre de conf-call allumée en permanence pour discuter. Voyant l'erreur, ils demandent donc aux deux autres permanences s'ils ont modifié quelque chose à 10h30 ce jour là. Silence. Non, non, personne n'a rien changé.
En fait, il y a bien un développeur qui a changé les droits d'accès de l'user principal en vu d'un processus de batch qui allait arriver, mais au lieu de mettre à jour les anciens droits, il a simplement écrasé les anciens par les nouveaux, rendant l'accès initial à la base impossible. Plutot que de dire "Oui c'est moi, j'ai du me tromper, venez m'aider à régler", il a préféré ne rien dire en esperant que ça passe inaperçu et qu'on ne sache pas que c'était lui. Manque de bol, ils ont réussi à retrouver que c'était lui et... ils l'ont viré.
Et c'est là toute la différence de culture entre, par exemple, Google et la cellule du gouvernement en charge de mettre en place le site. A Google, on aurait dit "Mince, je crois que j'ai fait une connerie, le site est en rade, que quelqu'un qui maitrise vienne vite m'aider". Là, ils savent que s'ils se font chopper à faire une erreur, ils se font virer. Au final, plus personne ne veut prendre d'initiative car dans le cas où ils se trompent, ils ont tout à y perdre.
Notre speaker disait que lui il avait le beau role, vu qu'il venait de l'exterieur pour aider, même s'il se plantait, au pire il retournait travailler à Google et eux restaient avec leur problème, ca n'avait pas la même pression que sur les autres. Au final, tout le monde était donc incité à ne rien faire, par peur des représailles en cas d'échec. Alors que dans l'équipe, il y avait des gens très compétents, qui savaient très bien comment faire, mais qui ne voulaient pas prendre le risque.
Au final ils se retrouvaient donc dans une situation où ils viraient les gens les plus compétents parce qu'ils se trompaient parfois, et gardaient des gens qui ne faisaient rien de peur de se tromper. Si déjà ce genre de comportement est en vigueur dans la société en situation normale, il est exacerbé en situation de stress comme c'était le cas ici. Si les devs n'ont pas la liberté d'essayer, de se tromper, et de demander de l'aide, alors le jour où il se passe vraiment quelque chose de grave, tout le monde est démuni parce que personne ne veut prendre de risques. Et finalement, qui est-ce qui passe pour un incompétent aux yeux du monde ? La société/ministère, pas les développeurs internes.
Cette histoire est celle qui m'a le plus marquée parce que c'est celle qu'on retrouve (à plus petite échelle) bien trop souvent. Le fiasco qu'à été healthcare.gov et l'ampleur que ça a pris dans les médias sont de bons exemples pour expliquer les dérives qu'impliquent de telles cultures.
La suite du talk était un ensemble d'autres WTF sur le projet. C'est toujours bon à prendre, donc je le rajoute ici :
Ils avaient par exemple l'un de leur module qui avait bien un système de reporting de ses erreurs mais, il y a avait en fait toujours des erreurs, si bien que plus de la moitié des composants étaient toujours au rouge. Mais bon, le parcours critique semblait quand même fonctionner donc on oubliait un peu les indicateurs et le rouge devenait normal. Sauf le jour où il y a vraiment eu un problème, il est passé inapercu dans la masse. Impossible de se logguer en ssh sur les machines, un des serveurs était passé en read-only, plus aucune écriture dans la DB n'était possible. Ils n'ont jamais compris d'où le bug venait, et ils ont pris du temps à le remarquer, et encore plus à le corriger.
Ils avaient aussi eu des soucis de configuration de leur Load Balancer qui envoyait la moitié des requetes dans le warp, vers des IP qui n'existaient pas.
Globalement pourquoi ce projet a tourné à la catastrophe ? Parce que personne n'avait de vision générale de tous les éléments, personne n'était là pour les faire fonctionner ensemble, chacun faisait sa partie dans son coin en se disant que "si je suis les specs, il ne peut rien m'arriver de mal".
Ils ont mis en prod directement le jour de la sortie, sans faire de pre-prod avant. Le grand saut directement. Bien sur ça a planté, et s'en est suivi une grande période de stress pour toute l'équipe. Déjà qu'il était difficile de faire les choses correctement en période normale, c'était encore plus dur en stress. L'inaction était récompensée, car si on cassait quelque chose, on se faisait virer, mieux valait ne rien faire. Chaque équipe était dans son silo, sans partager ni ses informations sur son module, ni les responsabilités. Le management les incitait même à cela, pour qu'ils se concentrent sur leur sujet, sans se laisser distraire par les autres. Ils faisaient aussi bien trop confiance aux produits "tout fait". Après tout, il suffit d'aller acheter une DB au magasin Oracle et de la poser dans l'archi et tout marche, non ?
Bon, le point positif, c'est qu'ils ont quand même beaucoup appris de cette expérience et qu'ils vont changer leur culture de l'IT pour la suite, pour ne pas avoir de second épisode comme celui-ci.
Scaling One Direction
Entre plusieurs talks de présentation d'outils extraordinaire, on a eu le droit à un petit REX très intéressant.
L'histoire est ici celle de l'équipe en charge de réaliser l'infra qui devait supporter live stream video du concert de 7h des One Direction. Un boys band est un très bon exemple des problèmatiques de scaling : il y a des millions de fans à travers le monde qui vont tous faire la même chose en même temps en fonction de ce que fait le groupe sur scène.
Ici la problèmatique n'était pas vraiment le streaming live de 7h de vidéo à plusieurs dizaines de millions de personnes à travers le monde. C'est pas quelque chose de facile, mais ça a déjà été fait avant.
Non, la difficulté vient d'autre part. Pendant le concert étaient diffusées, toutes les 10 minutes, des questions sur le groupe, auxquelles les fans devaient répondre avec l'appli mobile dédiée. En terme de pic de charge ça veut dire que pendant 9 minutes il ne se passe rien, puis en 1 minutes l'infra doit absorber des dizaines de millions de hits concentrés. Puis silence radio à nouveau pendant 9 minutes. Et nouveau pic. Et ça, pendant 7h.
Après chaque question, des stats étaient affichées en temps réel sur scène, avec le pays où les fans avaient le mieux répondu aux questions, et à la fin du concert, LE fan absolu, celui qui avait répondu bon à toutes les questions depuis le début, et le plus vite possible avait son nom affiché sur écran géant et droit à un petit mot du groupe. La classe.
Bon, et comment on fait l'infra pour ça ? Déjà on estime ce qu'on pense recevoir comme hits. On se prends une marge basse et une marge haute, et on calcule les machines qu'il va nous falloir pour absorber ça. Ensuite on calcule combien ça coute, et là on s'évanouie parce que c'est énorme. Mais comme on a ces 9 minutes d'inactivité, on sait qu'on peut diminuer la facture par 10 si seulement on ne commissionne des machines que durant les tranches où on en a besoin.
Citation très importante à ce moment : "Scaling is as much getting bigger and bigger than getting smaller and smaller in a short period of time".
Ensuite, deuxième étape pour savoir sur quelle stack partir, ils sont allé voir le métier pour savoir exactement les métrics dont ils allaient avoir besoin. Il a fallu convaincre la BI (mais avec la simulation de la facture c'était pas dur), que garder toutes les données (nom, prénom, age, etc) de tous les participants c'était inutile, et qu'on n'en avait besoin que pour le top 10 à afficher à la fin. Ensuite, on n'a pas besoin de savoir exactement qui a répondu quoi, on a juste besoin de savoir combien de personnes ont répondu juste ou faux à une question, leur tranche d'age (séparée en 3) et leur pays.
Sachant cela, les archi ont laissé tombé les bases SQL et sont partis sur du memcache. L'event étant un oneshot, il n'y a pas d'intéret à garder les données après coup, donc une base inmemory est adaptée. Les écritures sont rapides et simple, mais on est limité à une structure clé/valeur.
Ils ont alors commencé à trouver la meilleure manière de nommer leurs clées pour répondre à ce besoin spécifique. La logique de nommage étape par étape est la suivante :
Comme il ne leur faut que le nombre de bonnes et mauvaises réponses à chaque question, ils ont créés des clés nommées q1wrong, q1right, q2wrong, q2right pour stocker les bonnes/mauvaises réponses aux questions 1 et 2.
Bon, ça faisait quand même beaucoup d'écritures en séquence sur la même clé, du coup ils ont opéré un sharding manuel. Ils généraient un nombre random entre 1 et 100 qu'ils suffixaient à la clés : q1wrong42, q2right67, etc. Ainsi, les écritures étaient un peu réparties et ce n'était pas toujours la même plage mémoire qui trinquait.
Ensuite ils devaient gérer la tranche d'age de l'utilisateur (séparée en 3 buckets possibles), ils l'ont donc rajouté dans la clé : q1age2wrong66, q2age3right01.
Il doivent aussi connaitre les scores par pays, et là ca se complique. Certains pays sont largement plus représentés que d'autres, donc ajouter simplement le nom du pays à la clé ferait encore trop d'écriture sur les mêmes clés. Ils ont donc défini les pays qu'ils pensaient être les plus représentés ('uk', 'us', 'unknown'). Et si le pays de l'appelant est dans cette liste, il rajoutent un nouveau sharding numérique entre 1 et 15. Si c'est un autre pays (donc moins représenté), il ne font un sharding que sur 1 à 3.
Au final, leur archi-one shot a tenue. On ne sait pas exactement combien de memcache répliqués étaient utilisées mais je doute que tout tienne sur un seul (ou peut-etre que si ?).
Après l'évenement, ils sont donc allé feter ça au bar pour la soirée et la facture des boissons était plus élévée que leur facture de cloud. Ce qui est un bon indicateur de réussite de scaling !
Consul
Mitchell Hashimoto, le créateur de Vagrant nous a parlé de son dernier projet : Consul.
Consul cherche à régler le problème de la découverte et de la configuration de machines dans un réseau. Pour pouvoir gérer son infra au mieux, on a besoin de savoir où se trouvent (ip) les différents serveurs, s'ils sont up ou down, et comment ils sont configurés. On doit aussi pouvoir en ajouter ou en enlever au système et que les autres soient au courant. Généralement pour cela on utilise un serveur centralisé qu'on peut interroger pour répondre à ces questions mais que se passe-t'il quand ce serveur là est down ?
Consul permet de répondre à toutes ces questions par un système distribué et hautement disponible. Il n'a pas pu nous dire pourquoi et comment Consul était si hautement disponible, parce que sinon il allait en parler pendant des heures, mais nous a juste indiqué que c'est la priorité numero 1 : que les infos soient toujours dispos même si des noeuds tombent. Chaque serveur fait tourner en local une instance du système, donc même s'il est coupé du réseau, il possède quand même un cache des infos et il se resynchronise avec le reste dès que la connection revient.
Chacunes de ces instances distribuées expose une API dispo en curl/dig qui permet de récupérer l'ip d'une machine à partir de son nom (ou vice-versa). L'API permet aussi de savoir si la machine est up (par défaut il ne retourne que des services ups, mais on peut taper sur un autre endpoint pour avoir la totalité des services). Avec quelques simples appels curl on peut aussi récupérer la config de telle ou telle machine.
Comme je disais plus haut, le mode de fonctionnement est local par défaut (chaque machine possède les infos de la totalité du réseau) mais se synchronise en cas de changement. Un (ou plusieurs) datacenters peuvent être identifiés comme maitre de la donnée, où les autres se tournent pour avoir des infos plus fraiches.
Et bien sur, il existe une console web pour voir tous les noeuds, leur dispo et leur config, mais aussi un outil en ligne de commande pour intéragir avec eux.
Connaissant la qualité de Vagrant, Consul a l'air très prometteur.
Flynn
Jeff Lindsay nous a présenté un truc assez flou où à la fin de la présentation on ne savait pas si le projet dont il parlait existait réellement ou non. Il faut dire que les speakers avaient comme consigne de ne pas faire de conférences commerciales, donc parfois c'était assez flou.
Bref, Jeff Lindsay a un CV assez impressionant d'ops chez Digital Ocean, dotCloud, la NASA, et Twilio.
L'histoire qu'il nous raconte est celle d'une société qui commence son proto et l'héberge sur heroku. Tout est facile, en quelques clics on choisit ce qu'on installe et tout est disponible directement.
Mais quand la société grandit et qu'elle a besoin de scaler, elle va vite atteindre les limites d'heroku. Avec de la chance, toute la stack technique dont elle a besoin est fournie par heroku, mais si jamais ce n'est pas le cas elle est obligée de tout migrer sur une nouvelle infra, et de rattraper un gros retard from scratch en réecrivant tout sous Chef ou Puppet.
Et ça arrive souvent. Les serveurs évoluent, les besoin techniques aussi, on a besoin d'ajouter de nouveaux noeuds, ou de splitter des noeuds existants, ou de merge plusieurs noeuds ensemble. Il faut mettre une API en frontal, rajouter des load balancers, du cache, des master/slaves, etc. Sans parler des serveurs annexes qui gravitent autour : le repo git, le master chef, l'outil de bug report, le jenkins, etc. Forcément, au bout d'un moment on va avoir plein de machines un peu partout.
Et si on n'avait plus besoin de machines finalement ? Et si tout ce qui nous intéressait c'était les services qui tournent dessus ?
Flynn, l'outil développé par le monsieur essaie d'abstraire la notion de serveurs pour se concentrer sur les modules qui tournent dessus. A base de containers dockers un peu partout, il fourni un outil pour développer son propre heroku-like privé. La notion même de host disparait, et tout ce qui nous intéresse sont les process.
C'était une idée vachement intéressante et qui fait voir les choses sous un autre angle, mais le projet n'est qu'à l'état d'embryon actuellement.
Lightning Talks
Après la pause déjeuner, on a eu le droit à une sessions de lightning talks.
Le premier nous a parlé de son projet Nephorider qui permet de dresser une carte graphique des différentes machines d'un cloud : qui est relié à quoi, avec quelle ip, etc. Ils fonctionnent avec plusieurs providers, mais essentiellement Amazon, Rackspace et Google Compute Engine. Son talk parlait surtout des différentes API que ces trois fournisseurs exposent pour obtenir les infos nécessaires à la conception de son graph.
Chez AWS, il faut une cinquantaine de requetes, pour questionner toutes les régions, toutes les zones et aggréger toutes les infos. Chez Rackspace, on se limite à une vingtaine. Chez Google il en faut 3-4 parce que leur API permet de sélectionner les clés que l'on désire, et permet d'aggréger plusieurs requetes en une seule, et de les chainer avec un seul appel. Ca c'est de l'API !
Peter Szilagyi, le suivant nous a parlé de son projet Iris. J'ai eu un peu de mal à suivre exactement de quoi il retournait mais de ce que je comprends c'est un projet de messaging au sein d'une infra, de manière à faire communiquer des nodes ou groupes de nodes de même nature les uns avec les autres. Ca peut aussi bien être du broadcast générique que du pub/sub que du classique request/reply ou du stream d'un node à un autre. C'est resté assez flou.
Finalmeent Steeve Morin (@steeve) nous a parlé de boot2docker, qui utilise un kernel linux le plus petit possible, juste suffisant pour lancer docker et qui permet ainsi d'avoir une instance docker complete (kernel, OS, docker) pour seulement 53mo, et qui se lance la première fois en 3s, téléchargement de l'iso inclus. Vu que la stack initiale est read-only, on peut même booter depuis une clé USB. Un projet intéressant.
openZFS
Premier talk d'un haut niveau technique par Matt Ahrens, j'ai un instant eu peur que toutes les confs soient de cet acabit, mais c'était plutot l'exception.
Il nous parle des filesystems en général et d'openZFS en particulier. Comme dans pas mal de systèmes, il y a toujours un tryptique où on ne peut choisir que deux points parmis trois et pour les filesystems le choix se porte entre rapide, sûr et bon marché. Il nous parle d'un problème courant dans les datacenters où certains disques d'une baie sont moins performants que d'autres, et qu'on a beau les remplacer par des neufs, c'est toujours celui qui est à la même place qui souffre. Comme c'est du matériel mine de rien assez fragile, il suffit qu'il y ait des vibrations à cet endroit dans la pièce (à hauteur de voix parce qu'on est obligé de crier dans un datacenter à cause du bruit) et la tete de lecture se décale et crée des incohérence dans les données écrites sur le disque.
Généralement ces incohérences sont corrigées par le software qui va lire le disque, mais openZFS prends un autre partie en gérant ce genre de problèmes au niveau hardware. Les données sont écrites à plusieurs endroits dans le filesystem afin d'assurer une redondance et donc une meilleure intégrité des données. Ils font aussi des checksums de ce qu'ils écrivent afin de s'assurer de l'intégrité de la donnée. Un serveur qui utilise openZFS peut bien crasher d'un coup, les données sont assurées d'être écrites correctement, les disques ne peuvent pas se retrouver dans des états instables qui nécessittent de passer un coup de fsck.
openZSF est fait pour tourner sur du commodity hardware, des tas de disques bons marchés sur lesquels on replique la donnée et on se moque si l'un est plus lent que les autres ou non, il suffira alors de le changer si nécessaire, et on ne perdre pas l'intégrité de notre donnée.
Aujourd'hui, pour le même prix on peut avoir une capacité de stockage un million de fois supérieur à ce qu'on avait il y a 20 ans. Ce n'est donc pas intéressant de faire travailler du software pour régler des soucis d'incohérence et d'intégrité de donnée, il vaut mieux assurer ce travail au plus près du hardware pour avoir le moins de transit de donnée.
Note: Comme je disais en intro, ce talk était très technique, donc désolé si j'ai compris des trucs de travers, les experts pourront corriger.
Will PHP be hype again ?
Fabien Potencier (@fabpot), de Symfony nous a parlé de PHP. Il a commencé par évacuer les trolls d'entrée de jeu en disant que lui aussi, même s'il fait du PHP tous les jours, il n'aime pas le langage. Mais qu'il aime PHP pour la plateforme que c'est. Grand écosystème, facile de contribuer, server-side language qui a été pensé dans une optique de web dès le début et une pltéhore de frameworks disponibles (WordPress, Drupal, Joomla, Magento entre autres).
Le problème majeur de PHP est qu'il n'a jamais été pensé pour scaler. Toute nouvelle requete doit repasser par tout un cycle de traitement et de recompilation. Sur Symfony, ils essaient de déplacer certaines éléments de logique qui étaient initialement réexecutés à chaque requete, pour les déplacer à l'initialisation de PHP, histoire de gagner en performance. Ils se heurtent à pas mal de soucis inhérents à la conception initiale de PHP, comme par exemple le fait qu'une seule requete ne puisse être traitée en entrée à chaque fois et qu'une seule réponse ne puisse être retournée (ie. echo renvoie direct dans le corps de la réponse).
Bref, il est confiant que PHP puisse redevenir hype à nouveau ("après tout, c'est bien arrivé à Javascript"), grâce à la communauté qu'il a déjà derrière lui.
SaltStack
Thomas S. Hatch nous a parlé de nos infrastructures. On a plein de machines, déployées à travers le monde, qui communiquent les unes avec les autres. Pour réussir à scaler correctement, il faut aller vite; le scaling est essentiellement une question de vitesse. Et bien sur, chaque infra est différente et il n'y a pas de formule magique qui marche dans tous les cas.
Il y a donc différentes manières de considérer ses machines. Certains les voient comme des animaux domestiques, à qui on demande d'effectuer des taches, et qui reviennent avec le résultat. D'autres les chouchoutent comme des pierres précieuses, en les configurant aux petits oignons, mais de manière tellement précise qu'on n'ose plus y toucher de peur de briser quelque chose. De plus les voient aussi comme du bétail, un gros troupeau sans intelligence individuelle mais qui réagit à des ordre de déploiement supérieurs.
Mais la solution évoquée par le speaker est de les voir comme une armée de minions. On peut les diriger, leur donner des ordres, et compter sur eux pour faire ce qui est juste à un moment donnée pour arriver au but indiqué.
L'automatisation passe essentiellement par la communication entre les entités. Et vu la taille des architectures dont on parle, cette communication ne peut être qu'asynchrone, on ne peut pas attendre d'avoir la réponse aux questions qu'on a posées avant de passer à la suite. Si on rajoute à cela que tout ces systèmes ne parlent pas la même langue (différents protocoles, différentes implémentation, différents OS), il est impératif de trouver une manière de normaliser la communication.
Il a ensuite rapidement évoqué SaltStack, son produit qui serait une solution proposée à ce problème (http://www.saltstack.com/). Pour lui la solution passe par une modularisation (separation of concerns) des composants, et une abstraction par couche (pour simplifier chaque partie au maximum), mais surtout l'architecture doit être data-driven et non pas language-driven. Toute la configuration de qui parle avec qui pourquoi doit se trouver dans des fichiers de confs et pas dans des scripts d'un langage ou d'un autre. Ca permet de ne pas être bloqué avec un outil et de ne pas pouvoir en changer (un gars de WikiMedia dans une autre conf évoquait justement qu'ils restaient sur un vieil outil à cause des 20.000 lignes de code de déploiement qu'ils avaient dessus à cause du coup de migration).
Au final, il a peu parlé de sa solution et je ne sais pas trop ce qu'elle fait mais son analyse était intéressante.
And let's not forget Security
Alison Gianotto, alias @snipeyhead nous a fait un tour d'horizon et une piqure de rappel sur la sécurité informatique. C'est sujet récurrent dans à peu près toutes les conférences où je vais, mais c'est aussi un sujet tellement vaster qu'un peu d'évangélisation ne fait jamais de mal.
Elle a commencé par énoncer deux principes qu'il faut garder en tête à chaque fois que l'on tente de se protéger. Tout d'abord il est impossible d'anticiper tous les risques. Et deuxièmement, il est futile d'essayer de mitiger tous les risques. Sur ce premier constat pessimiste, on enchaine en se mettant dans la peau du hacker et de pourquoi il fait ça ?
Généralement c'est pour du profit, pour voler ou revendre des informations personnelles, des numéros de carte bleue, des informations secrètes. Ca peut aussi être tout simplement pour le fun, ou pour de l'hacktivisme. Parfois c'est par vengeance, ou pour de l'espionnage industriel. Il ne faut pas oublier tout le blackhat SEO (compromettre des sites pour faire monter son propre google juice).
Nos infrastructures sont aujourd'hui bien plus grandes qu'il y a 10 ans. Les infiltrations sont sans doute aussi nombreuses en proportion, mais la quantité de donnée volée est bien bien supérieure. On a eu plusieurs mega-breaches ces dernières années (ie. 10+ millions d'identitées récupéréres) : Adobe, PSN, etc.
Alors on essaie de se protéger, mais souvent ce qui semble une bonne idée de l'extérieur amène en fait plus de risques qu'initialement. C'est par exemple le cas de forcer ses utilisateurs à utiliser des mots de passes résistants en les forçant à suivre des règles drastiques (des chiffres, des lettres, des caracteres spéciaux, et devoir le changer régulièrement). Au final, le pass est tellement difficile à retenir que les utilisateurs vont le noter sur un post-it, et incrémenteront un numero tous les 3 mois.
Nos archis couvrent une telle surface que les intrusions peuvent venir de bien plus d'endroits qu'avant. Monitorer tout cela et se protéger devient très difficile. Sans compter qu'on fait face à une force de frappe qui est virtuellement illimitée : réseau de machines infectées qui peuvent bruteforcer ou DDOS. Ca coute beaucoup plus cher à une boite de se protéger de ces intrusions que cela ne coute à un attaquant (on peut louer des serveurs dans le cloud à la force de frappe énorme pour peu de sous).
Mais continuons à être pessimistes : les hackers ne sont pas nos seuls ennemis dans cette battaille. Nous sommes nous-même bien souvent la première faille du système. Nos systèmes devraient suivre le principe de CIA (rien à voir avec l'agence), c'est à dire : Confidentiality, Integrity and Availability.
Confidentiality signifie que l'accès aux données sensibles doit être limitée. 2 factor authentication, et destruction des anciennes données régulièrement. L'Integrity assure que l'information que l'on récupère est correcte et qu'elle n'a pas été modifiée. Et finalement Availability pour assurer que les personnes qui ont l'accès peuvent accéder à leurs infos à tout moment.
Elle a fini par quelques conseils génériques et une checklist de 20 items à faire tout de suite si ce n'est pas déjà fait. Tout d'abord, il faut étudier tous les composants de notre infra, et pour chacun étudier les chances qu'il puisse être la cible d'une attaque, et l'impact si jamais il venait à être compromis. Ensuite, il faut bien évidemment avoir un monitoring, comme toujours, de toutes les requetes et des comportements étranges. Et finalement, il faut lister tous les appels que l'ont fait vers des third party (API externes, progiciels, etc) pour identifier l'impact si l'un d'eux vient à tomber ou devient compromis.
Finalement, la vingtaine d'items à faire au plus vite :
Faire participer sa team à un jeu de CTR (Capture the Flag). Ce sont des jeux organisés en ligne où le but est de réussir à s'introduire dans des serveurs spécialements prévus à cet effet, mais utilisant des failles communes dans beaucoup de systèmes. C'est en se mettant à la place de l'attaquant qu'on voit toutes les informations intéressantes que l'on peut laisser derrière nous dans notre dev qui sont autant de levier pour assister une intrusion. Elle donne l'exemple typique de laisser le mode debug activé en prod, qui souvent laisse une stacktrace par défaut, et parfois même affiche les lignes de code incriminées : révélant au grand jour les login/password de la DB.
Ce conseil est rarement appliqué, mais est pour elle primordial : il faut mettre la sécurité sur la table dès le début du projet et ne jamais l'oublier. Ne jamais se dire que cela viendra dans un second temps, plus tard, comme une couche de vernis à appliquer sur un projet terminé. C'est quelque chose qui se passe à tous les étages et qui doit être gardé dans un coin de la tête de tous les acteurs du projet.
Liste toutes les potentielles cibles d'attaque exterieure : les frontaux publics, les bases de données, etc. Y attribuer une valeur de criticité s'ils tombent et une valeur de confiance qu'ils peuvent résister.
Avoir identifié à l'avance les conséquences du fail des third parties sur lesquels on se repose. Que faire si cette brique disparait du système, si on ne peut pas leur faire confiance. Est-ce que tout est bloqué, ou est-ce qu'on a un fallback en mode dégradé ?
Très important ! Faites confiance à votre instinct. Si quelque chose vous parait étrange, il y a de fortes chances que ce ne soit pas normal.
Gardez les systèmes le plus simples possibles. S'ils sont déjà complexes à comprendre en situation normale, une situation irrégulière d'intrusion risque de passer inaperçue.
Augmenter la transparence. Ne développez pas de système en boite noire, partagez la connaissance du fonctionnement de chaque outil au sein de l'équipe. Plus il est connu comment les choses fonctionnent, moins on risque de créer des failles par ignorance.
Automatisez tout. L'erreur est humaine, et les taches répétitives doivent êtres automatisées, ici aussi pour éviter d'insérer une faille par inadvertance.
Logguez presque tout. En gros, il faut tout logguer pour pouvoir déceler des comportements suspects, mais il ne faut jamais logguer les informations critiques comme les mots de passe ou les numeros de carte de crédit ou de sécurité sociale.
Utiliser le principe du least privilege par défaut : bloquez l'accès à tout le monde sauf à une whiteliste plutot que d'ouvrir tout et ne blacklister que certains points d'entrée/utilisateurs.
Ne gardez que l'information dont vous avez réellement besoin. Inutile de remplir des To de logs qui n'ont aucune valeur pour vous mais pourraient en avoir pour un attaquant.
Utilisez du two-factor authentication. C'est très simple à faire et il y a plein d'APIs disponibles pour aujourd'hui.
Prévoyez un plan de recovery en cas de crash, ou en cas de suspiscion d'intrusion, mais surtout TESTEZ LE !
Préparez toute la paperasse légale, faites les bonnes dépositions auprès des bons organismes pour indiquer le type de données que vous stockez, pourquoi et pour combien de temps. C'est long et laborieux, mais le jour où vous serez au grand jour pour une faille, ça limitera les dégats sur votre image.
Si vous utilisez un framework, utilisez ses mécanismes de validation/sanitization des inputs, ne développez pas les votre.
Faites faire des tests d'intrusions de l'intérieur, avec la connaissance du système, mais aussi de l'extérieur, sans connaissance du système, pour avoir deux points de vue différents.
Faites attention aux alerts. Si vous avez des erreurs régulières sur votre monitoring mais arretez d'y prêter attention, vous ne remarquerez pas l'erreur importante le jour où elle aura de la valeur.
Et le plus important : devenez un ambassadeur de la sécurité passionné, pour en parler à vos utilisateurs et à votre équipe.