All Your Base 2015 partie 1 : Conférences de la matinée

  • posté le
  • par ESENS

Vendredi 8h30 GMT, après une petite marche au travers du quartier d'Islington, j'arrive au Barbican Centre ou se tient la ALLYourBase 2015. Le programme en a été entièrement révélé depuis quelques temps déjà, et les conférences sont très diversifiées, certaines plus orienté administration, d'autres plus développement, la plupart porte néanmoins sur des technologies NoSQL. Grand absent de la conférence, Oracle, mon domaine de prédilection, dont on entendra à peine parler durant la journée. C'était donc l'occasion pour moi, malgré mes 10 ans passés d'expérience de ramer un peu techniquement et de voir ce qui se fait ailleurs.

Découverte des lieux

Situé à proximité de la City, l'endroit est une construction typique des années 70, c'est à dire un gros bloc de béton, qui se révèle beaucoup plus sympathique une fois les portes passées, avec notamment un magnifique jardin intérieur attenant au hall d'accueil de la conférence sur lequel je reviendrai dans le deuxième article. Le Barbican Centre est un des plus grands complexes culturels d'europe, il contient des halls d'expositions et de conférence, des cinémas, théatres et salle de concerts.

Dans le hall, une dizaine d'exposants entre les buffets de viennoiseries. C'est apparemment à la mode, j'ai vu pas moins de deux clusters de raspberries pi, dont un chez IBM pour lequel j'ai eu droit à une démonstration de tolérance aux pannes... un peu ratée, le retrait de la moitié des noeuds n'ayant pas vraiment été toléré justement, même si une fois tous les pis rebranchés le système s'est remis en route tout seul.

A priori il vaut mieux pas en enlever plus de 4. Et si possible pas celui du milieu.

D'autres exposants présentaient leurs produits, j'ai vu MySql où l'un des intervenants m'a détaillé les cas où il recommanderait Oracle plutôt que MySQL (apparemment le nombre de cas est directement correlé à l'éventuelle présence d'un commercial Oracle sur le stand), Riak qui avait également leur cluster raspberry et CouchBase où un compatriote m'a présenté une interessante solution de database cache local à destination des applications mobiles. Je suis passé rapidement sur les autres stands qui m'interessaient un peu moins, et au stand librairie, ou parmi une sélection largement liée au sujet de la conférence on pouvait bien sûr se procurer les livres des différents intervenants à un prix intéressant. Puis vers 9h30 les conférences commencent par la présentation des sponsors. Ils nous est également rappelé que la conférence est "Harrassment free". Nous sommes invités à signaler tout comportement inconvenant. En témoigne certains événements récents lors de conférences dans le monde du jeu vidéo notamment, c'est en effet un problème du monde IT qu'on ne peut ignorer. Personnellement si je salue bien évidemment l'initiative, je déplore surtout qu'il existe encore des personnes à cause desquelles on soit obligé de prendre ce type de mesures.

Les conférences du matin

9h40 : Getting data out of databases: a surprisingly tricky problem

Par Martin Kleppmann

Pour cette première présentation, j'avoue que le titre m'avait intrigué. Sortir des données,je ne vois pas où est le problème : un bon select, un spool des données, ou alors un outil style datapump si il y a vraiment beaucoup à récupérer, et c'est réglé. J'étais donc très curieux, et j'en suis sorti complètement passionné. D'abord parce qu'il faut dire que Martin Kleppmann est un excellent orateur, et ensuite parce que Kafka, le logiciel qu'il nous a présenté est un concept à l'image de sa présentation simple et efficace. Il s'agit moins d'extraire des données que de synchroniser d'autre mise en forme de la donnée à partir d'une base source. Dans le monde Oracle, le projet tout entier tourne autour d'une unique base qui fait à peu près tout le travail, la problématique suggérée ne se présente pas vraiment. A l'inverse dans les technologies du Web il est courant d'avoir une architecture plus modulaire ou la base de données peut être secondée par un cache, différent types d'index, qui sont gérés par d'autres logiciels. Le but de Kafka est de recevoir dans une file d'attente le journal des modifications de la base de données pour que ces différentes applications puissent se mettre à jour en lisant cette file d'attente. Le principe est très simple, mais puissant : Les consommateurs en place depuis longtemps se mettent à jour très rapidement, et grâce à un système de log compaction, il est même possible de construire par exemple un index neuf, à jour de toute la base. Kafka joue le rôle des redo logs sous Oracle, mais de manière modulaire et sans les contraintes d'un log circulaire. En conclusion, et je crois que je reviendrais souvent sur ce point, le gros avantage que je trouve à Kafka par rapport à un redo log classique et sa modularité. De plus le fait qu'il permette de reconstruire la totalité de la base permet d'ajouter et de retirer très facilement caches, indexes,... indépendamment de la base et simplifie ainsi le développement.

Vous pouvez retrouver les slides de cette présentation ici.

10h25 : Charity Majors : Upgrade your database: without losing your data, your perf or your mind

Par Charity Majors

Encore un sujet qui me parle puisqu'il me ramène directement aux quelques migrations de version Oracle sur lesquelles j'ai pu travailler, et l'invariable galère qui à chacune s'est associée. Très humoristique, la présentation de Charity s'est divisée en deux parties : Comment évaluer le rapport risque / bénéfice d'une migration de base de données, et deuxième partie comment faire en sorte qu'elle se passe le "moins mal" possible (Ici ne pas parler de mieux possible tient plus de l'expérience que du pessimisme). Charity illustre sa présentation avec des poneys, des arc en ciels et un exemple basé sur MongoDB. Pour le rapport risque bénéfices, on reste concis :

  • Parmi les avantages d'une migration : Nouvelles fonctionnalités, corrections de bugs, meilleures performances, fin de support sur la version, ...
  • Parmi les inconvénients : Probabilité non négligeable d'absolument tout casser.

Le risque opérationnel est également à prendre en compte : la maturité de la base de donnée, la criticité des données et la maturité de l'entreprise. Une jeune entreprise avec une petite base de contacts peu remplie et sans trop de fonctionnalité complémentaire ne prendra pas les mêmes risques à mettre à jour qu'une banque d'investissement avec ses données comptables. Enfin les benchmarks et documentations fournisseurs sont à prendre avec circonspection, d'autant plus si on a une utilisation inhabituelle de la base. Il est fort probable que l'éditeur ne fasse pas de test pour des bases de la taille de celle de FaceBook par exemple.

L'avis de Charity sur les benchmarks éditeurs : sans ambiguïté.Voir l'image sur TwitterCTr2TIxXIAAUeD2.jpg:large

Pour l'implémentation, on commence par un minimum vital : Lire les releases Notes, mesurer les risques et faire les tests unitaires. Et c'est là que la présentation va devenir magique pour moi, car à mon grand regret sur celles que j'ai faites, le travail pré-migration n'est jamais allé beaucoup plus loin. Le résultat comparatif des tests doit être identique tant au niveau des données, que des tris et du comportement (code erreurs, par exemple). Pour ce qui est des performances, rien ne vaut un test à charge de production, et surtout faire et refaire ses propres benchmarks surtout si on a un usage inhabituel. Enfin tester tous les programmes clients. Ce dernier point me parait évident de mon point de vue de développeur, mais je peux comprendre que les DBAs n'aient pas cette priorité en tête. En fait la présentation de Charity et évidemment pleine de bon sens, mais se heurte à la réalité des budgets, des séparations d'équipes (le devops est encore loin d'être la norme dans beaucoup de secteurs) et du manque d'intérêt des utilisateurs finaux, qui sont pourtant ceux qui paient. Et si comme elle nous le dit au début de son speech, une migration doit être transparente pour les utilisateurs, pourquoi alors est-ce qu'ils paieraient pour quelque chose qui ne va rien changer pour eux ? C'est là qu'est tout le problème : en plus de savoir évaluer le risque, il faut aussi savoir l'expliquer à l'utilisateur non technicien, afin qu'il ait cette visibilité sur le gain attendu.

11h25 Scaling MySQL at Facebook

Par Rongrong Zhong

Cette fois on rentre dans la technique, puisque Rongrong Zhong est venue nous expliquer comment adapter Mysql au stockage d'une base telle que celle de FaceBook. Pour cette conférence je ne vais pas trop entrer dans le détail car c'était plutôt pointu et aussi parce qu'il faut le reconnaitre, les sociétés comme FaceBook ont des problèmes de base de données qu'elles sont les seules à avoir. Rongrong nous a introduit à WebScaleSQL qui est une initiative poussée par quelques grosses sociétés pour adapter MySQL à une utilisation distribuée pour de très très grosses bases de données. Dans le cas de FaceBook on parle du stockage des utilisateurs, de leurs pages et de leur timelines entre autre. 60 millions de requêtes, 2,5 milliards de lectures et 11,5 millions d'écritures par seconde et un petit bonjour à tous ceux qui pense que MySQL est toujours réservé à des petits projets avec un volume réduit. Pour les détails techniques mieux vaut voir directement la conférence, il est en gros question de réorganiser le stockage des données logiquement et de défragmentation des stockage, dans le but d'augmenter les lectures en continu. Rongrong nous a parlé également des systèmes de caches qui interface les programmes clients avec cette base. En effet aucun accès direct n'est fait sur la base, toutes les applications passent par des bases de données intermédiaires ou des caches. Pour moi cette présentation offre surtout la possibilité d'entrevoir la complexité induite par une base de données de taille inhabituelle. Elle démontre aussi la puissance de l'Open Source : D'un projet sur lequel il y a 10 ans personne n'aurait déployé sa production, FaceBook a fait une base qui répond tout à fait à leur besoin, pourtant complètement hors du commun en terme de volumétrie et de performance.

11h55 From antiquated to engineer: Today's DBA

Par Laine Campbell

La présentation de Laine Campbell est elle aussi assez amusante, avec quelques références à Charity Majors, tout à fait à propos puisque les deux sujets se recoupent. Aucun sujet technique ici, il est question des métiers de DBA d'hier et d'aujourd'hui, de la multiplication des outils à maintenir, des différents types de base de données parfois utilisés conjointement là où auparavant tronait une unique base de données toute puissante sur les besoins des clients qui gravitent autour. Il revient sur le rôle croissant d'expert technique et le glissement vers les rôles d'investigation/résolution auparavant réservés au développeur, et nous permet de mieux comprendre les besoins qui ont engendré le mouvement devops. Pour marquer cette différence, Laine crée une distinction de métier : on est passé de DataBase Administrator à DataBase Engineer, dont le rôle n'est plus de préserver la base de donnée des développeurs, mais plutôt de les aider à en tirer le meilleur parti.

Cette phrase résume parfaitement l'évolution du rôle vis à vis des autres intervenants.

Cette présentation se veut le reflet de l'évolution du métier d'administrateur de base de données. Laine commence par nous décrire le métier de DBA tel qu'il l'a exercé il y a 20 ans, avant de passer à ce qu'il est aujourd'hui. Enfin je dirais ce qu'il est encore et sera peut être demain, car de mon expérience personnelle certains DBA n'ont visiblement pas eu beaucoup le temps de changer leurs habitudes depuis les années 90. Encore une fois on se rend compte que tous les secteurs d'activités n'évoluent pas à la même vitesse, et ce qui devient un standard dans l'économie numérique reste souvent un avenir hypothétique mal compris dans certains secteurs plus conservateurs. J'ai quand même eu un peu l'impression de faire un voyage dans le futur depuis le début de cette matinée.

12h25 Break your database before it breaks you

Par Matt Ranney

On pourrait croire que le défi est de taille pour Matt Ranney de nous tenir attentif alors que l'heure du déjeuner s'approche, mais le buffet du matin et de la pause de la matinée ont visiblement été suffisant pour mantenir les esprits loin des estomacs. Nous allons donc voir comme Uber à découvert dans la douleur qu'il était souvent utile de casser volontairement une partie de son infrastructure pour voir ce qu'il se passe, et ce avant que l'infrastructure décide de le faire elle-même.

Le postulat de base de Matt Ranney

En introduction Matt nous présente l'architecture très changeante du SI d'Uber. De nombreuses technologies ont été mises en places puis parfois écartées en 6 ans d'évolution, introduisant d'autant plus de bonne raisons de planter, mais en même temps s'adaptant rapidement aux évolutions de besoin. On comprend ici que selon Matt il ne faut pas être trop conservateur pour éviter le plantage, parce que de toute façon il arrivera. Le problème est surtout de savoir gérer ces plantages qui peuvent avoir des conséquences fâcheuses dans la vie réelle. En l'occurence chez Uber le plantage du service dispatch ne permet plus de distribuer les courses. L'application devient inutilisable. Matt nous présente ensuite un cas pratique, où une architecture distribuée basée sur le modèle Maître / Esclave de PostGreSQL et restée down pendant quasiment 36 heures. On pourrait penser que le fait de passer sur un autre type d'architecture (décentralisée avec Ryak dans le cas présent) était une bonne solution, celle ci a pourtant amené d'autres problèmes plus difficile encore à investiguer. Le fait est que rien ne remplace un plan de test en condition réelles, si l'on veut être prêt à réagir. Les tests de backup, de bascule ou de failover, qui consiste à tester une architecure de secours, sont d'après mon expérience une préoccupation entrée dans les habitudes de la profession. Le problème commun à tous ces tests selon moi c'est qu'ils sont en général planifiés des semaines à l'avance. Quel peut être la valeur d'une simulation de crise quand tous les intervenants sont prévenus, qu'ils ont une astreinte prévue ce jour là, que la bascule sur l'infra de secours se fait alors que la principale est parfaitement fonctionnelle ? Reconnaissons qu'il y a quand même très peu de chance que l'incident réel se passe dans ces conditions. L'intervention de Matt vaut autant pour les développeurs, car nous avons nous mêmes tendance à nous appliquer sur le fonctionnement normal en ignorant complètement le comportement de nos programmes quand tout se détraque.

 
"Une erreur est apparue, veuillez contacter le développeur, il adore jouer aux devinettes"

Je ne parle pas de concepts de failover compliqués mais d'exemples simple et trop fréquents : Logs incomplet ou non datés, code retours abscons, messages d'erreurs un peu léger. Peut être en plus de nos tests unitaires et tests de chaîne devrions nous réfléchir à des tests de support d'incident.

Fin de la matinée

Cette dernière conférence conclue une matinée déconcertante mais enrichissante. Déconcertante car on est loin des concepts habituels de mon domaine d'expertise, et que pas encore un seul bout de code SQL n'est venu poindre le bout du nez, mais enrichissante car la plupart des interventions étaient suffisament théoriques pour que j'y trouve des applications dans mon travail quotidien. Une question me taraude néanmoins alors que nous sortons pour le "lunch" : Mais nos belles bases relationnelles avec nos requêtes d'aggrégation à rallonge, c'est du passé où quoi ?

Le compte rendu des conférences de l'après-midi est ici. Vous pouvez trouver les vidéos de chaque conférence là.

PARTAGER CET ARTICLE

Nos derniers articles Tech

VOIR TOUS NOS ARTICLES