Decrypt

Comment scaler une infrastructure AWS (Amazon Web Services) ? C’est une réponse détaillée que va apporter cet article en 2 parties : les outils à utiliser pour tirer parti du dynamisme des services Amazon et le modèle d’architecture à adopter pour une infrastructure scalable. Je me base sur mes expériences tirées de plusieurs projets de production sur les AWS, à la fois dans le domaine du casual gaming (sur Facebook), dans celui des infrastructures e-commerce ou bien encore dans le cadre du SIG (Système d’Information Géographique) grand public. Il est vrai que l’expérience dans le domaine du jeu est celle qui est actuellement la plus représentative en termes de scalabilité, du fait du nombre d’utilisateurs (> 800K DAU – Daily Active User – et plus de 20M de pages vues par jour), cependant les expériences dans le e-commerce et le SIG (expérience en cours :o)) offrent également une autre vision de la scalabilité, prenant en compte des problématiques différentes de disponibilité et de gestion des données. Je vais donc tenter de brosser un tableau exhaustif des éléments à prendre en compte afin d’optimiser le dynamisme d’une infrastructure montée dans un environnement de Cloud Computing et en l’occurrence dans celui des AWS.

Les outils
Je propose des exemples d’outils que j’ai utilisés dans mes différentes expériences de production et qui m’ont convaincu par leur efficacité. Cependant, ce n’est pas tant l’outil qui est mis en valeur que la fonctionnalité sous-jacente qu’il va falloir implémenter pour tirer parti au mieux des AWS.

Différence entre une infra AWS et une infra standard
Il y a 2 éléments de réponse :

• Tout d’abord, les AWS permettent de manipuler les composants Hardware et d’Infrastructure via la code (en passant par des APIs), cela permet un dynamisme qu’il va falloir exacerber en sélectionnant convenablement ses outils. Amazon propose de plus un certain nombre de garanties techniques sur leurs services, il conviendra d’en tirer parti afin de se concentrer sur l’essentiel.
• Ensuite, une seconde partie de la réponse devrait être : « aucune ! ». Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergée « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile, au niveau des EC2 notamment, oblige à mettre en place des mécanismes qui devraient être standards.

Gestion de configuration centralisée
La possibilité d’instancier de multiples serveurs (EC2) à la volée pour répondre à un pic de charge ou des traitements ponctuels, nous oblige à utiliser un outil de gestion de configuration centralisée. L’utilité est multiple :

• Instancier rapidement une machine correspondant à un type prédéfini : serveur Web, serveur de cache, …
• Assurer l’homogénéité de la configuration de l’ensemble des instances d’un même type à tout instant.
• Capitaliser un savoir faire : les packages, configurations, services, … de chaque type d’instance est contenu dans un descripteur. Cela permet aux nouveaux venus (et aux autres) de connaitre la composition des serveurs sur la simple lecture du ou des descripteurs associés.

Puppet est une solution très intéressante pour cette tâche. L’architecture Puppet est constituée de:

• Un Puppet Master, gardien des configurations, il contient les descripteurs des packages à installer, fichiers de configuration à déposer et services à démarrer pour une nouvelle instance EC2 afin de la préparer suivant le type du ou des nœuds auxquels on l’a associée ou tout simplement pour maintenir à jour une instance existante.
• De multiples clients Puppet installés sur les instances EC2. Régulièrement, le client poll (interroge) le master afin de vérifier que sa configuration est à jour. Il est également possible de faire du push sur les clients à partir du master pour déclencher une mise à jour urgente.

Il est ainsi très simple de monter une nouvelle instance d’un type donné et d’être sûr que, d’un serveur à un autre, la configuration est complètement identique. Il est à noter que les descripteurs du Puppet Master fonctionnent sur un système de nœuds et un serveur peut faire référence à plusieurs nœuds. On obtient donc une configuration très modulaire.

Descripteur Module Puppet

Le gestionnaire de configuration centralisée est indispensable sur une infrastructure scalable qui est amenée à avoir un grand nombre d’instances dont certaines devront être montées rapidement afin de répondre aux sollicitations des utilisateurs lors des pics de charge.

« Mais… », me direz-vous, « il faut bien installer le client sur la nouvelle machine ? ». Et oui, d’autant plus qu’il y a un système de requête/acceptation de certificat entre le client et le master afin que n’importe qui ne puisse accéder aux configurations. « Très simple ! », vous répondrais-je, au lieu d’utiliser une IHM, comme Elastic Fox, afin de se connecter aux APIs des services Amazon, il suffit de s’y connecter en lignes de commande via un script qui instancie un EC2, éventuellement crée un volume EBS et l’associe, se connecte en SSH sur la nouvelle machine et installe le client, se connecte sur le master et accepte la requête de certificat, redémarre le client et « hop ! ». L’instance s’installe et se configure toute seule. Les possibilités de réactivité et de dynamisme inhérentes aux EC2 et aux AWS de manière générale nous impose cela, sinon ce serait sous exploiter l’outil, voire le més-exploiter.

Et les AMIs (instance-store root devices) ou les EBS root devices (à noter que pour ces dernier, il n’y a pas encore beaucoup de choix en termes de templates) ? Il est cependant possible de se constituer une AMI ou bien un EBS root device avec le client Puppet installé dessus (et d’utiliser éventuellement les user-data au lancement de l’instance afin de le paramétrer si une configuration « statique » sur l’AMI n’est pas suffisante). Cependant, dans un environnement de production, l’AMI ou l’EBS root device ne permettent pas de remplacer un Puppet : si il faut modifier l’AMI à chaque modification de paramétrage et redéployer les EC2… On n’a pas fini. L’AMI est un bon outil pour instancier un template de base (au sens basique), pas pour conserver une infrastructure de production en bon ordre de fonctionnement.

Pour conclure, il est même possible d’envisager une auto-scalabilité (plus complète que celle proposée par le service Auto Scaling d’Amazon basé sur CloudWatch) qui reviendrait à déclencher ce script sur le dépassement d’une valeur d’un graphe de monitoring (métrologie), instanciant donc une nouvelle machine pour supporter la période de pic, instance qui serait « terminée » suite au passage en dessous d’un autre seuil sur ledit graphe. Les possibilités sont énormes. Cependant, le coût des derniers éléments à mettre en place sur une infrastructure importante de production pour accéder à l’auto-scalabilité est conséquent (complexité exponentielle). Si on a l’opportunité, c’est un bel ouvrage, sinon se « contenter » d’une solution aisément scalable où il suffit de lancer un script manuellement (ou bien à heure fixe basé sur l’étude des métriques remontés par la métrologie, ce qui est une bonne alternative) et éventuellement d’ajouter manuellement une ou deux références dans un fichier est une alternative tout à fait respectable.

Exécution de tâches automatisées en parallèle
Du fait de la variation du nombre d’instances en fonction de la charge d’une infrastructure scalable et surtout du nombre potentiellement important desdites instances, il n’est pas envisageable d’effectuer les opérations de maintenance et de déploiement unitairement sur chaque machine (et encore pire à la main !), ce qui non seulement serait chronophage, mais de surcroît source d’erreurs. Il est alors indispensable d’utiliser des outils spécialisés dans l’automatisation et l’exécution parallèle de tâches, tel que Capistrano, dont les bénéfices sont multiples :

• Scripter un certain nombre de tâches, complexes ou non, (livraisons, backups, publication/maintenance du site, …) et de les exécuter rapidement en parallèle sur X machines en une seule commande.
• Assurer la reproductibilité d’une tâche.
• Capitaliser un savoir faire (Cf. Puppet).

Descripteur Tache Capistrano

Cet outil est très simple d’utilisation et très pratique. Il exécute des tâches en parallèle (en se connectant en SSH – n’utilisez pas la clé « root » de vos instances EC2 dans l’outil, mais une autre dédiée, c’est plus classe…) sur un ou des groupes de serveurs définis par des rôles.

C’est un complément à Puppet et non un doublon car ils n’ont pas la même cible :

Objectif
Puppet - Homogénéité de la configuration du parc de serveurs.
Capistrano - Reproductibilité des tâches et exécution en parallèle.

Mode de fonctionnement
Puppet - Pull régulier des clients (voire push du master).
Capistrano - Tâches ponctuelles (appel manuel ou par cron).

Orientation
Puppet - Objets / notions prédéfinis tels que « Package », « Service », « File », …
Capistrano - Des commandes génériques comme « upload », « download », « system », « run », …

Cible
Puppet - Infrastructure et services.
Capistrano - Services et applicatif.

A noter, Webistrano est une IHM permettant d’accéder aux fonctionnalités de Capistrano et introduisant une notion de gestion de projet par la possibilité de gérer les accès aux tâches en fonction de son profil, de tracer qui a déployé quoi sur quel serveur et d’envoyer des alertes mails sur certaines actions. Je trouve cette jointure avec la gestion de projet intéressante.

Monitoring
C’est un des éléments cruciaux d’une architecture scalable, si ce n’est le principal. Il est indispensable d’avoir à disposition des métriques afin de savoir justement quand scaler. Il permet d’identifier les points d’engorgement de l’infrastructure, d’analyser l’évolution du trafic sur votre site et d’en déduire les comportements des utilisateurs et permet également de déclencher des alertes.

Cet apport de métriques est plus représentatif de la métrologie que de la supervision. On verra que, dans le cadre d’une infrastructure sur AWS, la métrologie a une valeur ajoutée plus importante que celle de la supervision (même si cette dernière reste indispensable). A ce propos, voici un éclaircissement sur les 2 disciplines du monitoring qu’il faut identifier :

• La supervision vérifie l’état d’un hôte ou d’un service et remonte une alerte sur la détection d’un comportement anormal (temps de réponse trop long, statut NOK, …) et implique une action immédiate de la part des interlocuteurs concernés. Une alerte doit signifier que l’hôte ou le service est inutilisable (critical) ou risque de l’être (warning) et ne pas renvoyer de « simples informations » qui pollueraient la visibilité des réels incidents.
• La métrologie permet d’historiser les données, éventuellement d’appliquer un traitement ou filtre dessus, avant de les présenter sous forme de graphiques ou de reporting. Ces données permettent d’apporter un correctif à postériori au niveau développement ou paramétrage des services afin d’apporter une optimisation desdits services et également de définir les ressources à attribuer aux services au plus juste. Cet aspect du monitoring est tout aussi important car il va permettre d’améliorer le service et donc le rendu des utilisateurs (internes ou clients finaux) et également de lisser les coûts. Les résultats issus de la métrologie doivent mettre aisément en valeur les améliorations à apporter en corrélant les valeurs récupérées.

Un certain nombre existent sur le marché avec leurs avantages et inconvénients, certains plus orientés supervision, d’autres plus métrologie. On citera Centreon/Nagios, Zabbix, Cacti ou encore Munin. Personnellement, j’utilise Centreon/Nagios essentiellement pour la supervision et Cacti pour la métrologie orientée logicielle avec des graphes pré-packagés comme pour Apache, MySQL, Memcached, … Mais j’ai eu de nombreux bons écho sur Zabbix pour son exhaustivité de fonctionnalités et Munin pour sa simplicité d’utilisation.

Thread Scoreboard Apache - Yearly - 1 Day Average

Il est à noter que ces outils fonctionnent pour la plupart (Centreon, Cacti et Munin) sur RRDtool (Round-Robin Database), un outil de gestion de base de données permettant également de représenter graphiquement les données contenues dans la base. Le gros avantage tient dans le fait que le volume de données stockées est minimal même pour la conservation de plusieurs mois, voire années de données. Cela est rendu possible par le calcul de moyennes sur des périodes (de 1 minute à 1 jour) : les données récentes sont exactes, alors que les plus anciennes sont approximées. Très pratique car nous avons à la fois des métriques récentes exactes et conservons un historique, une représentation de l’évolution de notre architecture, ce qui est capital afin de visualiser l’évolution des métriques clés et de comprendre les impacts de l’évolution des composants de ladite infrastructure ou bien des applications supportées au fur et à mesure des livraisons des différentes releases.

Concernant les infrastructures de type Cloud Computing, la discipline ayant la plus forte valeur ajoutée est la métrologie, car c’est elle qui va permettre d’apporter un feed back à vos outils d’automatisation.

Gardez à l’esprit également qu’il est intéressant de pouvoir intégrer dynamiquement les nouvelles machines installées et configurées par Puppet dans l’outil de monitoring. Privilégiez donc les outils de monitoring avec une configuration modulaire, ou simple d’accès via APIs.

Gestion des logs centralisée
C’est indéniable, plus vous aurez d’instances, plus vous aurez de logs éparses sur les diverses instances. De plus, diriger tous les logs vers le daemon syslog devient problématique car tous les composants de l’infrastructure ne gèrent pas forcément bien cela (redirection, respect du protocole syslog, …), sans parler de la ou des applications/briques fonctionnelles qui peuvent loguer dans des fichiers disparates sur le serveur.

Pensez à des outils comme Syslog-NG : il est composé d’un serveur et de plusieurs clients, en fait le même outil mais avec des configurations différentes. En plus, il est capable de vérifier régulièrement des fichiers de logs (d’applications métier par exemple) et de transmettre uniquement le différentiel, même si celui-ci ne respecte pas le protocole syslog :

• Le client récupère les logs de files(fichiers)/pipe/unix-dgram/… et envoie les infos sur le réseau (tcp/udp).
• Le serveur récupère les infos du réseau (tcp/udp) et les enregistre dans des fichiers, bases de données, …

Architecture Syslog-NG

Il s’agit juste de différences minimes en termes de configuration. Le composant peut également servir de relai sur des infrastructures plus complexes en recevant les logs du réseau à partir de divers clients et en les envoyant à nouveau sur le réseau à destination d’un serveur.

Il est possible d’appliquer des filtres avant d’envoyer les logs sur le réseau pour ne faire transiter que le nécessaire et ensuite il est également possible d’en appliquer au niveau du serveur pour gérer différemment les logs en provenance des clients en fonction de leur criticité, programme émetteur, hôte d’origine, …

C’est un outil simple et non intrusif pouvant prendre en compte les logs des applications éparses sur un serveur (même si ces logs ne respectent pas le format du protocole « syslog » – il y a cependant un plus à respecter ce protocole pour avoir une meilleure précision au niveau des « facilities » et « priorities »).

De même que pour le monitoring, gardez à l’esprit qu’il est intéressant de pouvoir intégrer (et retirer) dynamiquement les nouvelles instances à gérer au niveau du système de logs.

Conclusion
Au delà des outils présentés, ce sont les fonctionnalités sous-jacentes qui sont importantes. Ce qu’il en ressort, c’est :

• Les outils comme les gestionnaires de configuration centralisée, les outils d’exécution de tâches automatisées en parallèle ou bien les gestionnaires de logs vont prendre encore plus d’importance. Il n’est plus envisageable de travailler sans sur de telles infrastructures.
• Le monitoring est toujours une valeur clé et le restera, mais la métrologie permet avec l’analyse des métriques clés définis dans son infrastructure d’alimenter les outils d’automatisation.
• L’automatisation est bien le mot clé mis en avant par les AWS : l’accessibilité des ressources Hardware ou d’Infrastructure via du code permet d’aller vers des architectures de plus en plus autonomes. Il faut cependant positionner le curseur convenablement, sachant que les dernières étapes d’une automatisation complète seront les plus coûteuses.

J’espère que ce retour d’expérience vous aura intéressé autant que j’ai eu de plaisir à travailler sur ces infrastructures. Je continuerai cet article dans une deuxième partie consacrée au modèle d’architecture à appliquer pour des infrastructures scalables.

Frédéric FAURE @Twitter @Ysance