TP9 : High Throughput on Woodytoys

Ce TP implique à la fois une réalisation pratique, mais surtout l’observation et l’analyse de ce qui est mis en place. N’oubliez donc pas de documenter vos observations et réflexions sur votre wiki!

1. Un nouveau service Web pour WoodyToys avec Docker Stack

Docker Stack, c’est simplement Docker Compose pour Swarm. Un docker-compose.yml classique peut être lancé avec docker stack :

docker stack deploy -c docker-compose.yml <votre_stack>

Certaines éléments de configuration (dans votre docker-compose.yml) sont spécifiques au mode “docker compose” (et ne seront pas pris en compte dans le mode “docker stack”) tandis que d’autres sont spécifiques au mode “docker stack” (et ne sont alors pas pris en compte dans le mode “docker compose”).

Dans le cadre de ce TP, une directive essentielle sera replicas. N’hésitez pas à aller voir les autres configuration possibles sur la documentation officielle.

Découverte du service Web

Dans ce TP, nous allons déployer un nouveau service Web pour WoodyToys et travailler sur les possibilités d’amélioration des performances de ce service. Vous trouverez les fichiers constituant la base de travail de ce service sur cette page github

Le but du premier exercice va être d’adapter le fichier docker-compose.yml qui s’y trouve, pour qu’il puisse fonctionner avec via “docker stack” (notamment, la partie “build” qui peut-être très pratique pendant la phase de développement, mais qui n’est, bien évidemment, pas utilisable sur un swarm.

Expliquez pourquoi l’utilisation de la directive buildne convient pas dans le contexte Docker Swarm.

Commencez par prendre connaissance des fichiers et configuration composant ce service, notamment en identifiant les différents flux de données. N’hésitez pas à démarrer le service sur un de vos VPS avec docker-compose. Pour lancer la stack en local (sans swarm), vous pouvez lancer ceci:

docker compose up --build

(le –build est très pratique ici car vous permet de reconstruire vos images basé sur la version actuel de votre code)

Comme dans la vie professionnelle réelle, il est possible que vous deviez adapter voire débugger certains éléments de ce service. Normalement, vous êtes à présent assez compétents pour pouvoir vous débrouiller avec les bons outils.

N’oubliez pas de stopper vos services web existants et d’adapter votre firewall si nécessaire avant de lancer ce nouveau service. Attention aussi aux ports disponibles si vous utilisez vos VPS pour Dev Web.

Documentez sur votre Wiki les flux de données présents, en vous basant sur un schéma commenté.

Stack Woodytoys

Vous verrez qu’en utilisant ce code, vous aurez des ralentissements ‘artificiels’. Ils ont été rajoutés afin de simuler une surcharge. Nous vous demandons bien évidemment de ne pas modifier ces ralentissements volontaires, mais de tenter d’améliorer les performances par les autres moyens mentionnés plus bas. Par exemple, le serveur Flask (s’occupant de l’API) est limité à une seule connexion simultanée, le front est ‘throtlé’ et la base de données est aussi limité à une seule connexion.

Déploiement sur Swarm

  • Une fois que votre service fonctionne sur un seul VPS, adaptez le en vue de le déployer sur le swarm créé lors du TP précédent. Rappelez-vous que vous aurez besoin que les images soient publiées sur dockerhub. Pour cela, vous pouvez adapter le script build_push.sh en fonction de vos besoins et de votre manière de travailler.
  • Observez et identifiez les limitations à l’aide d’outils comme la console web ou en exécutant la commande time wget -r <votre_url>. Documentez les performances chiffrées observées. Documentez également votre campagne de mesure : vous devrez la reproduire à plusieurs reprises tout au long du TP.
  • Augmentez ensuite le nombre de ‘replicas’ (notez que vous ne devez pas arrêter le service pour mettre à jour cette configuration).
  1. Est-ce que l’augmentation du nombre de replicas résout les problèmes ? Répondez en comparant les premiers chiffres de performance observés avec des mesures effectuées après la modification. Pour chacune des trois limitations, commentez les éventuelles améliorations en étant critiques (les limitations artificielles ne sont peut-être pas représentatives de la réalité).
  2. Est-ce qu’il y des choses que vous pouvez mettre en place au niveau de Docker Swarm (outre les réplicas) pour améliorer les performances ? (Hints: healthchecks(pour l’api) et placement constraint (pour la database))

2. Mise en place d’une cache

Une solution possible pour améliorer les performance est la mise en cache des informations. Plusieurs types de stratégies existent pour la mise en cache (cfr cours théorique). Ici, nous allons utiliser la stratégie cache aside pour insérer une cache afin de réduire la charge sur la base de données.

Dans le cadre de ce TP, il vous est proposé d’utiliser Redis. Redis est une base de données NoSQL clé-valeur en mémoire, ce qui signifie qu’elle fonctionne par défaut en RAM.

Extrêmement rapide, Redis permet d’enregistrer une valeur avec un temps d’expiration, ce qui nous sera très utile pour configurer notre cache.

Cache aside

Voici un exemple de code Python permettant d’interagir avec Redis. Ce code pourra être exploité par notre API.

import redis

r = redis.Redis(host='redis', port=6379, db=0)

# Enregistre la value 'value' dans la clé 'key' pour une durée de 60 seconde
r.setex('key', 60, 'value')

# Récupère la valeur de 'key' (renvoie None si elle n'existe pas/plus)
value = r.get('key')
  • Rajoutez un service Redis dans votre docker-compose.yml.
  • Adaptez le code du backend Flask pour qu’il l’utilise (au moins pour un endpoint).
  • Relancez une campagne de mesure pour évaluer les performances.

Est-ce que cette cache améliore les performances ? de combien ?

3. CDN

Un CDN (Content Delivery Network) est un réseau de serveurs répartis géographiquement. Son objectif principal est d’accélérer la diffusion de contenu sur Internet. En utilisant un serveur géographiquement proche, le contenu est livré plus rapidement, ce qui réduit la latence et améliore l’expérience de l’utilisateur.

Les solutions habituelles de CDN (telles que Cloudflare) impliquent souvent de leur donner la gestion de la zone DNS, afin qu’ils puissent rediriger le trafic vers une copie proche (mise en cache sur un de leurs serveurs).

Pour des raisons techniques principalement (il faut notamment avoir accès à la zone du premier sous-domaine, ce qui est compliqué ici), on va partir sur l’utilisation d’un CNAME pour gérer toutes vos ressources statiques.

Une solution gratuite permettant de faire cela est ‘gcore’. Il vous faudra donc y créer un compte et suivre cette procédure.

CDN pour Woodytoys

Note: Vous n’avez besoin de le faire qu’une fois par groupe

Une fois la configuration faite sur ‘gcore’ et votre code html adapté, effectuez une nouvelle campagne de mesure pour évaluer l’impact de l’utilisation du CDN sur les performances. Documentez votre analyse sur votre Wiki.

4. Database

La base de données reste malheureusement un bottleneck important dans notre service Web. Dans le cadre de ce TP, nous n’aurons pas l’occasion de mettre en place de solution à ce niveau, mais il est intéressant de se pencher sur cette problématique.

Pouvez-vous citer et expliquer une solution pour améliorer les performances au niveau d’une DB? (une brève description et la présentation de l’un ou l’autre avantage, inconvenient, particularité, … sont suffisants)

Par exemple celle ci: