Skip to main content

Scalabilité

Scalabilité et Résilience du Cloud-Challenge​

Le retour d'expérience du premier cloud-challenge a fait remonter un besoin de rendre l'application scalable à une charge conséquente et résiliente aux différents crashs possibles. Pour celà un redis contenant l'état des conteneurs à été ajouté au cloudmapper et l'admin-server. Les conteneurs possèdent alors tous le même état et peuvent etre lancés en parallèles. Si un conteneur tombe, un autre peut être lancé, et charger l'état du précédent.

Fonctionnement​

Dans les deux cas, l'object contenant l'état de session (state) des micro-service est rendu en chaine de caractère puis stocké dans le redis. Les objects étants construits de la sorte :

{
    [key_account: string] : [Team: object]
    ... 
}

Ils sont stockés en différentes clé/valeur correspondantes au key_account du compte AWS.

Pour avertir les conteneurs d'un changement d'état, un mecanisme de Pub/Sub est mis en place. Tous les conteneurs sont subscribers au même channel et à chaque changement, un message est envoyé pour les prévenir.

Architecture​

alt text

  1. Au démarrage d'un conteneur, l'état présent dans le redis est chargé s'il existe.

  2. L'état est changé dans le cycle de vie d'un conteneur

  3. Ce même conteneur met à jour l'état distant et envoie un message sur le channel.

  4. Les autres conteneurs recoivent le message et mettent à jour leur état avec celui distant, pour avoir la dernière version.

Infrastructure et Terraform​

Le redis est initialisé à l'aide du terraform de l'architecture principal supportant l'applicatif du Cloud-Challenge. Sur AWS, c'est un Elasticache for Redis en single node dans une seule zone de disponibilité. Pour des raisons de temps de developpement et de coût, le redis n'est pas hautement disponible. Pour des raisons de sécurité, son security group n'accepte que le flux provenant de l'ECS.