Hébergement - Partie 3 : Ce que le cloud fait pour nous

Les principaux services utilisés dans nos backend

Chez BeTomorrow nous travaillons généralement au niveau PaaS. Tous nos backends sont différents mais le plus souvent ils partagent une base commune qui utilise différents services d’AWS. Bien évidemment, nous ne les utilisons pas tous, AWS c’est plus de 500 services. Voyons ça en détail et surtout ce qu’AWS nous apporte par rapport à du simple IaaS.

ELB (Elastic Load Balancer / Répartiteur de charge)

Lorsque l’application mobile fait une requête réseau, elle arrive sur le répartiteur de charge (Load Balancer). Ce composant va recevoir les requêtes et les rediriger vers nos backend. Grâce à ce composant, nous n’avons pas besoin d’augmenter la puissance de la machine, nous pouvons simplement ajouter ou retirer des instances de backends au besoin en fonction du nombre de requêtes. De plus, il gère aussi la partie chiffrement des requêtes. Nous n’avons donc plus besoin de configurer et renouveler les certificats pour le HTTPS. Ce composant est hautement disponible et entièrement géré par AWS.

ECS (Elastic Container Service)

On en a déjà un peu parlé*, c’est le système CaaS. il nous permet de déployer directement nos backend sous forme d’image Docker. Nous avons juste à lui dire où se trouve l’image que l’on veut déployer et il fait le reste. Couplé avec le Load Balancer, il offre aussi du “Rolling Update”. C’est-à-dire que lorsque nous allons déployer une nouvelle version, le système va démarrer les nouveaux backends en parallèle des anciens, attendre qu’ils soient opérationnels puis rediriger le traffic sur ces nouvelles instances avant de retirer les anciennes. Nous pouvons donc déployer nos backends sans interruption de service sans rien avoir à faire de notre côté.

S3 (Simple Storage Service)

S3 c’est le service de stockage objet. Lorsqu’on upload une photo, un avatar par exemple, c’est ici qu’on le stock. Mis à part une erreur humaine, il est quasiment impossible de perdre un objet qui se trouve sur S3.

Pour comprendre comment AWS réussi cette prouesse il faut regarder comment AWS a mis en place ses infrastructures.

AWS à mis en place une certaine hiérarchie :

• Région : On trouve au premier niveau les Régions. Ce sont des zones géographiques étendues que l’on retrouve dans plusieurs pays. Par exemple en France il y a la région Paris, en Angleterre il y a la région Irlande et Londres.

• Zone de disponibilité : Dans chaque région on retrouve des Zones de disponibilité, des AZ (Availability Zones). Il y en a généralement 3 par Région. On peut les voir un peu comme des lotissements espacés d’au moins 100 km entre eux.

• DataCenter : Enfin dans chaque AZ on retrouve plusieurs DataCenters espacés de plusieurs dizaines de mètres chacun. C’est un peu les maisons dans les lotissements, dans lesquelles nous allons retrouver les serveurs.

On est loin des DataCenter d’OVH qui ressemblent beaucoup à un ensemble de conteneurs maritimes recyclés et empilés les uns sur les autres.

Quand on met un fichier sur le service S3, il va partir dans un DataCenter situé dans une AZ de la région que l’on aura choisi. Dans un premier temps, AWS va créer 2 copies dans la même AZ puis va envoyer une copie dans une autre AZ de la région, qui va a son tour être copié 2 fois. On a donc 6 copies réparties sur 2 AZ de la région.

Aurora MySQL

Aurora MySQL est une base de données créée par AWS et compatible avec la base MySQL qui est encore maintenant une base de données très populaire. Avec ce service nous bénéficions donc d’une base compatible MySQL, qui tient même beaucoup mieux lorsque nous avons beaucoup de requêtes en même temps et qui se déploie en un clic.

Dans l’offre minimum d’AWS, cette base sera déployée dans un seul DataCenter d’une des Zone de disponibilité de la région choisie. En revanche à chaque fois qu’il y a une modification en base, il va sauvegarder cette information sur S3 qui va la copier dans une autre AZ. On peut donc très rapidement redémarrer une nouvelle base à jour dans une autre AZ en cas de défaillance de la première sans surcoût. Bien évidemment on peut aller plus loin en ayant plusieurs bases qui tournent en parallèle et laisser gérer Aurora pour basculer sur une copie en cas de coupure de la principale sans même interrompre le service.

CloudWatch

Pour nous aider à mieux comprendre ce qu’il se passe dans le code lorsqu’on rencontre un bug, nous avons besoin de journaliser différents évènements. Par exemple qu’on est bien passé dans cette fonction ou bien qu’ici le service nous a répondu qu’il ne trouvait pas le fichier etc. Mais surtout nous journalisons toutes les informations que l’on peut lorsqu’une erreur se produit. De ce fait, lorsque nos backends s’exécutent sur plusieurs serveurs, il faut aller récupérer ces journaux sur tous les serveurs et les fusionner pour avoir une lecture temporelle. CloudWatch centralise pour nous tous ces journaux et nous offre cette vue unifiée où nous pouvons revenir dans le temps pour mieux comprendre ce qu’il s’est passé. C’est aussi ici que nous allons pouvoir retrouver tout un tas de mesures sur l’état de santé globale de notre plateforme.

CloudFront (Content Delivery Network)

Lorsque nous sommes sur internet, nos requêtes passent par ce qu’on appelle “L’internet public”. Le problème c’est que potentiellement ce réseau est surchargé ou a des travaux qui nous obligent à faire des détours et ça augmente le temps de réponse. C’est un peu comme les routes nationales en France.

En parallèle de ce réseau, les fournisseurs déploient leur propre réseau qu’ils maîtrisent et dimensionnent parfaitement. On peut voir ces réseaux comme des autoroutes. Pour aller plus vite, il vaut mieux trouver le péage le plus proche pour rentrer sur ces autoroutes. CloudFront c’est un peu le péage des autoroutes d’AWS. Il permet de rentrer sur le réseau AWS par la porte la plus proche de notre position géographique.

En plus de ça, CloudFront peut aussi garder une copie localement de la réponse au niveau de cette porte. De ce fait, si un autre utilisateur réutilise cette porte, la requête n’ira même pas jusqu’à nos serveurs et sera renvoyée directement.

Ça nous permet d’avoir un site qui se charge très vite depuis n’importe où dans le monde.

La plupart des services listés ci dessus existent aussi chez OVH par exemple, en versions plus ou moins abouties. Mais les projets nous amènent souvent à utiliser d’autres services en fonction des besoins comme CloudSearch pour l’indexation, SQS pour la gestion des files d’attente, Lambda pour des traitements en réaction à des évènements et bien d’autres qui n’ont pas leur pendant chez OVH pour le moment.

Et le Serverless là-dedans, c’est quoi ?

Littéralement, Serverless veut dire qu’on ne se préoccupe pas de la machine qui fait tourner un service. En ça, les différents services listés ci-dessus sont tous Serverless ou existent aussi en version Serverless. Au mieux, on a donné une idée de capacité nécessaire pour faire fonctionner notre backend mais rien de plus. Derrière, c’est le fournisseur qui va mutualiser ses différentes machines et déployer notre backend là où il y a encore assez de place.

Aujourd’hui les gens font généralement un amalgame entre le FaaS et Serverless. En théorie c’est magique, ça permet de ne payer que lorsqu’il y a des requêtes pour économiser en coût d’infrastructure, et la charge supportée s’adapte automatiquement avec le nombre de requêtes. En pratique, ce n’est pas si simple et ça apporte tout un tas de complications qu’on verra dans un autre article.

Conclusion

On voit ici que le cloud nous permet d’aller bien plus loin qu’un simple hébergement et d’économiser à la fois du temps lors de la mise en place mais aussi lors de l’exploitation tout en ayant un service plus fiable et plus sécurisé. Mais quel est l’impact sur le coût de l’hébergement ? C’est ce que je vous propose de voir dans un article dédié à venir.