À mesure que les entreprises font évoluer leur stack technologique vers le cloud-native, on observe une tendance aux migrations partielles, ou aux configurations cloud hybrides, souvent comme étapes intermédiaires avant une bascule complète.
Migration cloud
Récemment, une entreprise d'e-commerce a entrepris de migrer ses applications conteneurisées d'AWS vers GCP afin de tirer parti du service Kubernetes managé de Google, GKE.
Les fichiers de son catalogue produits et ses photos étaient stockés sur S3, le service de stockage objet d'Amazon, son DNS était géré via AWS Route 53, et elle utilisait le service CDN de Cloudflare. Première étape : migrer les bases de données et déployer les applications en parallèle vers des clusters Kubernetes.
Vient ensuite l'étape suivante : passer du CDN de Cloudflare à celui de Google, tout en laissant pour l'instant les fichiers statiques sur S3. Autre contrainte : continuer à exploiter le DNS géré dans AWS Route 53.
Exemple de parcours de migration cloud par phases pour une entreprise d'e-commerce
Cet article présente, étape par étape, comment mettre en cache le contenu d'un bucket AWS S3 depuis GCP Cloud CDN à l'aide d'un load balancer et d'un network endpoint group (NEG). Pour simplifier, je ne génère pas de certificat SSL et n'ajoute pas de frontend HTTP(S), mais ce serait généralement une étape supplémentaire à prévoir.
Mise en place de la démo
- Créer un bucket S3 initial avec des fichiers de test
Créer le bucket S3 (notez son nom, qui servira plus tard à la configuration de l'en-tête Host sur le LB)
2. Téléverser les fichiers de test et modifier les métadonnées pour ajouter l'en-tête Cache-control
Fichiers d'exemple téléversés
En-tête Cache-control ajouté (requis pour le CDN)
3. Vérifier que le contenu renvoie bien les en-têtes attendus
Configurer le load balancer et le NEG sur GCP
- Ajouter ou modifier le type de backend pour choisir Internet network endpoint group
2. Sélectionner un network endpoint group (NEG) existant ou choisir create new
Remarque : il se peut que vous deviez créer le Network Endpoint Group (NEG) au préalable pour qu'il apparaisse dans le menu déroulant de la configuration backend du Load Balancer. S'il n'apparaît pas, choisissez Create Internet network endpoint group, puis rafraîchissez la page du load balancer pour qu'il s'affiche.
Sélectionnez Fully qualified domain name et saisissez le FQDN correspondant à l'emplacement de votre bucket S3 (vous pouvez aussi pointer une entrée DNS personnelle dessus, cela fonctionne tout aussi bien).
3. Activer Cloud CDN et ajouter un en-tête personnalisé (correspondant au hostname du bucket S3)
Après avoir choisi le Backend type pour le NEG externe, cochez Enable Cloud CDN, puis déployez les options en bas de page pour créer un en-tête personnalisé.
L'astuce consiste à ajouter un en-tête host personnalisé qui reprend le hostname S3, comme illustré ci-dessous.
4. Ajouter ou modifier le frontend
5. Enregistrer le load balancer et vérifier qu'il est bien associé au NEG
6. Vérifier que le contenu est bien servi et qu'il passe par le cache
Confirmer l'accès au contenu (possible aussi depuis le navigateur)
Lancez quelques tests dans un navigateur, puis consultez les logs (le plus rapide reste les logs Stackdriver), dépliez une entrée et vérifiez qu'elle provient bien du cache.
Confirmation que la mise en cache fonctionne sur le trafic du load balancer
Mettre à jour les entrées DNS pour rediriger le trafic vers Cloud CDN
Une fois que tout fonctionne comme prévu et que le contenu est bien servi depuis le cache, il ne reste plus qu'à modifier vos entrées DNS, le moment venu.
Ici, le CDN était fourni par Cloudflare et une entrée DNS cdn-environment-location.myco.com pointait vers le CNAME something.cloudflare.com. Il suffit de créer un nouvel enregistrement A pointant vers l'IP externe du load balancer Google (par exemple gcp-lb-development-cdn.myco.com), puis de modifier le CNAME pour qu'il cible cette nouvelle entrée.
Par précaution, je recommande de réduire la veille, si nécessaire, le TTL de votre entrée CDN en production : ainsi, en cas de problème lors de la modification du CNAME, vous pourrez revenir en arrière sans que la mise en cache DNS côté clients ne s'éternise.
Récapitulatif des étapes :
- Réduire le TTL du domaine CDN existant
- Ajouter un enregistrement A pointant vers l'IP du load balancer GCP
- Modifier l'enregistrement CNAME du domaine CDN existant (remplacer le FQDN Cloudflare)
- Vérifier que le contenu transite bien par Cloud CDN
Bravo, ça fonctionne ! Il ne reste plus qu'à sécuriser le tout avec un frontend HTTP(S) ;-)
Garder un œil sur les coûts des solutions cloud
Relayer les requêtes depuis Cloud CDN vers des buckets S3 est tout à fait possible, mais cela impose d'ajouter des en-têtes personnalisés, et cette opération est facturée. Aujourd'hui, le tarif est d'environ 0,75 $ pour 1 million de requêtes, plafonné à 500 $ par mois. Sur un site à fort trafic, la facture peut vite grimper.
Cela reste sans doute modeste face aux frais réglés à Cloudflare (tarifs inconnus), mais le point mérite d'être signalé. À terme, l'objectif est de migrer les fichiers statiques vers des buckets Google Cloud Storage : comme ils prennent en charge la même API S3, les modifications de code seront minimes, voire inexistantes.
En résumé
Comme vous pouvez le constater, migrer d'un fournisseur technologique à un autre n'est pas aussi intimidant qu'on pourrait le croire. Une approche plus sûre consiste néanmoins à découper le projet en phases plus courtes : vous pourrez ainsi revenir en arrière facilement en cas de souci et limiter l'impact sur l'activité.