Ateliers MySQL Conference (matin)

La conférence annuelle de MySQL se lance avec la journée de tutoriels. Des sessions de 3 heures, organisées par des experts d'un secteur. Pour garder les équipes de nexen Services à la pointe, j'ai suivi les sessions de 'Scaling High Availability Architecture', animé par le coloré Jeremy Cole.
La session commence par un historique de l'évolution temporelle des architectures Web, depuis la version sur un hébergement partagé jusqu'aux architectures finales et évolutives. Jeremy fait l'analogie avec le développement humain, partant du stade de nouveau-né jusqu'à la fin vingtaine, où les optimisations intiales qui fonctionnaient sont maintenant la source même du ralentissement, et où la moindre erreur aliène votre communauté, et assure la mort de la compagnie.

La solution préconisée est alors le partitionnement. C'est à dire savoir diviser les lots de données en une sous-groupes autonomes, de plus petite taille, et facile à gérer. Plusieurs solutions sont proposées : par clé fixe, par clé dynmique ou encore par utilisateur. Plusieurs choix sont possibles lors du choix de ces clés, et ils sont directement liés à l'application qui est montée. Faire des partitions par utilisateurs peut être valide ou bien être remplacée par une optimisation par groupe. Un découpage intelligent doit être faît en fonction des coûts : le mieux est de monter une fonction de coût, qui mesure ce que coûte une interaction d'un utilisateur et de réorganiser les partitions en fonction de cette fonction. C'est une approche basée sur le principe que 20% des utilisateurs va générer 80% de la charge, et que ceux qui utilisent le service tous les 6 mois sauront attendre un peu avant de retrouver leur vieux comptes.

Jeremy signale le projet HiveDB, www.hivedb.org, un outil Java pour gérer des partitions de manières souples. En effet, si le partitionnement des données est facile, tout les partitionnements suivantes sont plus dures. Avant de partitionner, il faut donc se préparer pour les suivantes, et HiveDB promet de faire cela. C'est un des premiers projets Open Source qui se lance sur ce type de sujet, et, s'il n'est pas encore parfait, il est surement meilleur que ce qui pourrait être réalisé à la main. Quand j'aurai le temps, je vais étudier cette solution.

Ensuite, la session se poursuit avec une collection d'architecture de réplications : un serveur, plusieurs serveurs, des serveurs relais (très pratiques pour soulager le maître initial, ou pour pallier les retards et les coûts pour les grandes distances), les relations maîtres à maître, (qui ont la côte), et les anneaux de maîtres (qui sont fortement décriés).

Les réplications à deux maîtres sont recommandées pour mettre en place un système facile de réprise sur erreur. Les deux maîtres se surveillent mutuellement, peuvent se remplacer, et ne posent pas autant de problèmes de cohérence que des anneaux de maîtres. De plus, le maître secondaire peut facilement servir de relais pour les esclaves en soulageant le maître principal, et le tout fonctionne aussi même si les maîtres sont éloignés. C'est donc une architecture qui a la cote actuellement.

Une très bonne session, avec un intervenant expérimenté et intéressant. La session a simplement été un peu trop courte, et manquait de quelques exemples. Le domaine est particulièrement compliqué, et les solutions sont encore réalisées au cas par cas. Je ne crois pas qu'on puisse facilement trouver des motifs répétables de solutions, et il faut encore réfléchir aux architectures, et les tester avant d'avoir une solution complète. Il y a encore de beaux jours pour les experts MySQL.

Outre la session, j'ai déjà rencontré Guiseppe Maxia, qui est mon MySQL Buddy, Rolan Bouman et Sheeri Kritzer. La blogosphère MySQL est au complet ici.

A plus tard.