Noms des auteurs :

• De Henau Dudley
• Gendebien Jonas
• Clarembaux Robin

Date de réalisation : mai 2025

La directive build n'est pas adaptée à Docker Swarm car elle nécessite que le fichier Dockerfile soit présent localement sur chaque noeud du cluster. Cela rend le déploiement complexe, car il faudrait s'assurer que tous les noeud disposent exactement du même contexte de build. Il est préférable d'utiliser une image déjà construite et poussée sur un registre Docker.

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

1. L'utilisateur accède au site → envoie une requête HTTP.
2. NGINX reçoit la requête et renvoie le frontend.
3. L'utilisateur interagit avec l'interface → requête API envoyée.
4. NGINX transmet la requête à l'API.
5. Si besoin, l'API interroge MySQL.
6. MySQL répond à l'API.
7. L'API renvoie la réponse à NGINX.
8. NGINX renvoie la réponse finale à l'utilisateur.

Stack Woodytoys

• Documentez l'adaptation du service afin de le faire tourner sur Swarm. Modifications :
• Suppression des directives restart.
• Remplacement des build: par des image:.
• Création d'un réseau pour connecter les services entre eux.

-Documentez vos observation et analyses des limitations, en détaillant les performances chiffrées observées.

Tests réalisés pour évaluer les limites de performance de la stack déployée sur Docker Swarm.
Les captures d’écran suivantes illustrent les résultats observés.

---

Temps de réponse moyen : ~15 secondes.
Le service reste utilisable mais lent.

---

Lors de deux connexions simultanées :

• Le premier client reçoit sa réponse en ~15 sec.
• Le second client subit un délai d’environ ~30 sec.

Conclusion : la stack ne supporte pas bien la concurrence sans optimisation.

---

Après mise en place d’une redondance (réplicas du service backend) :

• Les performances s’améliorent nettement.
• Le temps de réponse se stabilise.
• Les requêtes simultanées sont mieux traitées.

---

Avec Redis :

• Les ressources déjà demandées sont servies quasi instantanément.
• La charge sur MySQL est fortement réduite.

Conclusion : l’ajout d’un cache est très efficace pour améliorer les performances et l’expérience utilisateur.

Pour évaluer les performances du service WoodyToys déployé sur Docker Swarm, nous avons réalisé une campagne de mesure simple basée sur des outils en ligne de commande. Le but était de mesurer les temps de réponse HTTP dans différents scénarios.

• wget : pour simuler une requête client HTTP.
• time : pour mesurer le temps total d’exécution de la commande.

Nous avons utilisé la commande suivante :

time wget l'ipDunVPS/api/produits

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é).

Oui et non.

• Avant : 1 client → ~15 s ; 2 clients → 2e client à ~30 s.
• Après ajout de réplicas : 2 clients → tous les deux à ~15 s.

→ Amélioration : le service reste disponible même avec plusieurs clients.
→ Limite : le temps de réponse reste élevé (~15 s), donc la performance brute ne s'améliore pas.

• Limitation 1 (charge simultanée) : corrigée partiellement grâce aux réplicas.
• Limitation 2 (latence DB) : non corrigée, les requêtes vers MySQL restent lentes.
• Limitation 3 (pas de cache) : corrigée uniquement après ajout de Redis.

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))

• Healthchecks (pour l’API) : permettent de vérifier si le service est réellement prêt avant de recevoir du trafic. Cela évite d’envoyer des requêtes à une API lente ou en cours de démarrage.
• Placement constraints (pour la base de données) : permettent de forcer le placement de la base sur une machine plus performante (avec plus de RAM ou un disque plus rapide), ce qui peut réduire le temps de réponse.

• Ajout d’un nouveau service redis dans le fichier docker-compose.yml, sans utiliser l’image de base Redis par défaut.
• Modification du code woo.py au niveau de l’endpoint /api/products/last :
  • Ajout d’une vérification dans Redis avant de faire la requête SQL.
  • Si la donnée est présente dans Redis, elle est renvoyée directement.
  • Sinon, elle est récupérée depuis MySQL puis stockée en cache.

• Lorsqu’un client a déjà demandé la ressource :
  • Temps de réponse moyen : < 0.5 s.
• Sans cache (avant) : ~15 s.

• Oui, le cache améliore considérablement les performances.
• Gain estimé : de 15 s à 0.5 s → amélioration d’environ 30x.
• La charge sur la base de données est réduite.
• Réduction des temps de réponse pour tous les utilisateurs suivants.

Conclusion : l’ajout de Redis est très efficace pour les données souvent consultées.

• Un compte a été créé sur le service CDN de cloudflare.
• Un enregistrement CNAME a été ajouté dans la zone DNS pour pointer vers le CDN.
• Le but était de faire passer les requêtes statiques (images, JS, CSS) par le CDN pour améliorer les performances.

Citer et expliquer sur votre Wiki 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)

Description
La réplication consiste à copier les données d'une base principale (master) vers une ou plusieurs bases secondaires (replica/slave). Les requêtes en lecture peuvent être déportées vers les replicas, ce qui allège la charge sur la base principale.

Avantages

• Scalabilité en lecture : plusieurs serveurs peuvent répondre aux requêtes de lecture.
• Haute disponibilité : si le master tombe, un replica peut prendre le relais (avec une bascule manuelle ou automatique).

Inconvénients

• Latence de synchronisation : les données ne sont pas toujours à jour instantanément sur les replicas.
• Complexité de gestion : il faut configurer et surveiller la réplication (ex. avec MySQL Replication ou PostgreSQL Streaming Replication).