# Laboratoire n° 2 : compte-rendu

Gildas Houlmann
Thibaud Franchetti

## Tâche 1

### Coûts mensuels estimés
#### DB
instance: 12.41$
Storage: 2.3$
Total: 14.71$

### Comparaison des coûts

Pour une instance EC2 `t3.micro` avec 20 GB de stockage, le calcuteur estime les coûts mensuels à 6.75$\. Soit plus de 2x moins cher qu'une instance RDS.

### EC2 ou RDS ?

Comme vu précédemment, une instance EC2 sera meilleure marchée. Néanmoins, cela implique de gérer soi-même les maintenances de l'OS et du SGBD, les sauvegardes, la réplication, la scalabilité etc. Cela nécessite un temps de main d'oeuvre pour le service IT de l'entreprise et donc représente un coût non négligeable.

Dans une instance RDS, ces tâches sont gérées (moyennement parfois un supplément) par AWS, il est donc moins nécessaire de s'en préoccuper une fois celles-ci configurées. Sans compter l'aspect sécurité qui, dans une petite équipe généraliste, sera probablement en deçà de ce que propose AWS.

Cependant, pour une utilisation peu critique de la base de données, les coûts réduits et la plus grande flexibilité offerte par l'instance EC2 en font une bonne option.

### Endpoint Address
houlmann-drupal.cfctxlvbo57k.us-east-1.rds.amazonaws.com

## Tâche 2

$databases['default']['default'] = array (
  'database' => 'drupal',
  'username' => 'DrupalDbAdmin',
  'password' => 'DrupalDbPass',
  'prefix' => '',
  'host' => 'houlmann-drupal.cfctxlvbo57k.us-east-1.rds.amazonaws.com',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);

## Tâche 3


## Tâche 4
AZ: us-east-1b

Nom DNS du load balancer: houlmann-loadBalancer-694231874.us-east-1.elb.amazonaws.com

Adresses IP liées au nom DNS:
2 adresses sont retournées par la commande `nslookup`:
- 52.4.161.126
- 52.87.102.36

### Logs d'accès
Dans cet extrait des logs d'accès de apache (`/var/log/apache2/access.log`), on voit les accès fait par les health checks du load balancer:

## Tâche 5

### Diagramme de topologie

### Coûts estimés
Avec l'outil https://calculator.s3.amazonaws.com/index.html, on obtient un coût mensuel de 49.82\$.

## Tâche 6
3 tests différents ont été menés. Un premier avec une charge très faible, ensuite un avec une charge démesurée, puis un avec une charge critique juste suffisante pour avoir une partie des requêtes sans réponses.

NOTE: Un problème non résolu causait le load balancer à ne pas fonctionner correctement lors de requêtes vers `/drupal`, nous avons donc envoyé nos requêtes de test vers `/drupal/`, qui renvoie aussi le contenu de la page mais le load balancer fonctionne correctement pour traiter ces requêtes.

### Premier test - faible charge
Pour ce premier tests, nous avons utilisé JMeter pour simuler un utilisateur envoyant 5 requêtes au load balancer.
On constate dans les logs que les 2 instances se sont partagé les 5 requêtes (2 d'un côté, 3 de l'autre).

Nous avons pu observer une latence de l'ordre dde 200ms avant les réponses de ces requêtes. Toutes ont reçu une réponse positive (200 OK)

### Second test - charge démesurée
Pour ce second test, nous avons configuré 800 utilisateurs sur JMeter, qui ont envoyé 10 requêtes chacun sur le load balancer. La durée de montée en charge est de 0.05 secondes

Les requêtes défilaient en continu dans les logs des deux machines. Après à peine quelques secondes, la plupart (environ 70%) des requêtes recevaient une erreur 500, et celles qui recevaient une réponse positive (200) subissaient une latence variable pouvant aller jusqu'à 11 secondes.

### 3ème test - charge critique
Pour ce dernier test, nous avons cherché la charge critique à partir de laquelle les serveurs ne fonctionnent plus de manière satisfaisante. Celle-ci se situe autour de 300 utilisateurs, avec une durée de montée en charge 4x plus grande que pour le test précédent, ce qui laisse plus de temps au serveur pour traiter les requêtes.

Durant ce test, la grande majorité des requêtes recevaient une réponse avec un délai inférieur à une demi-seconde, et environ 5% recevaient une erreur 500. Certaines requêtes subissaient un délai anormalement long (plusieurs secondes), mais elles étaient rares.

Nous avons déterminé qu'il s'agit du point de bascule à partir duquel l'application ne serait plus utilisable de manire confortable.

### Monitoring
Les deux instances ont été monitorées pendant les tests. On observe bien sur ces graphiques le second test effectué à 12:15 et le 3ème à 12:25.
Les deux instances présentent des données de monitoring semblables

### Adresse du load balancer
Peu importe la charge subie par le load balancer, il adresses retournées par un `nslookup` sur celui-ci sont toujours les mêmes.

## Tâche 6 - archive à supprimer
3 tests différents ont été menés. Un premier avec une charge très faible, ensuite un avec une charge démesurée, puis un avec une charge critique juste suffisante pour avoir une partie des requêtes sans réponses.
### Premier test - faible charge
Pour ce premier tests, nous avons utilisé JMeter pour simuler un utilisateur envoyant 5 requêtes au load balancer.
Étonnament, les 2 instances ont reçu 5 requêtes, comme on peut le voir dans ces logs:
Nous avons pu observer une latence de l'ordre d'une centaine de millisecondes avant les réponses de ces requêtes.

### Second test - charge démesurée
Pour ce second test, nous avons configuré 1000 utilisateurs sur JMeter, qui ont envoyé des requêtes en continu pendant environ une minute sur le load balancer.
Les requêtes défilaient en continu dans les logs des deux machines. Durant ce test, la plupart (environ 80%) des requêtes ne recevaient pas de réponses, et celles qui en recevaient subissaient une latence de l'ordre de une à 3 secondes environ.

### 3ème test - charge critique
Pour ce dernier test, nous avons cherché la charge critique à partir de laquelle les serveurs ne fonctionnent plus de manière satisfaisante. Celle-ci se situe autour de 300 utilisateurs.
Durant ce test, environ la moitié des requêtes recevaient une réponse avec une latence d'environ une seconde, et l'autre moitié ne recevait pas de réponses. Nous avons déterminé qu'il s'agit du point de basule à partir duquel le site web n'est plus utilisable pour un utilisateur.

### Monitoring
Les deux instances ont été monitorées pendant les tests. On observe bien sur ces graphiques le premier test effectué à 00:15, le second test à 00:20 et le 3ème à 00:25.
Les deux instances présentent des données de monitoring semblables

### Adresse du load balancer
Peu importe la charge subie par le load balancer, il adresses retournées par un `nslookup` sur celui-ci sont toujours les mêmes.

### Comment mieux tester
Les tests effectués vérifient le fonctionnement de base du load balancer, c'est-à-dire la résistance à la charge. Pour tester plus exactement, il faudrait effectuer les mêmes tests avec une seule instance dans le Target Group, ou plus d'instances.
Pour tester le load balancer de manière plus efficace, il faudrait aussi simuler une activité continue, irrégulière et imprévisible comme le comportement de vrais clients humains.

## Annexe - mots de passe des différents serv
mdp root mysql = P@\$\$w0rd
mdp root instance ubuntu = toor
mdp user Mysql \'drupal\' = lapurd
username admin du site = admin
mdp admin du site = P@$$w0rd
username admin instance DB = DrupalDbAdmin
mdp admin instance DB = DrupalDbPass
user dans rds = db_user
mdp user dans rds = db_user_pass