La facturation Google Cloud Platform Suivi et optimisations
L’Equipe.fr a migré en décembre 2018 sur GCP à partir de son hébergeur traditionnel historique.
Outre les aspects techniques un changement notable a été pour nous le suivi de la facturation, cet article fait le point sur ce qu’on a appris.
Nous sommes passés d’une facturation traditionnelle et prévisible (un fixe mensuel couvrant un certain nombre de machines avec un peu de débordement sur du stockage et de la bande passante sortante) à un système que l’on peut faire évoluer facilement et qui est donc à suivre régulièrement.
Le système de billing Google est public, pratique à consulter et transparent mais pas toujours simple à bien comprendre dans le détail.
Toutes les infos se trouvent ici
https://cloud.google.com/pricing/?hl=fr
Pour des machines qui vous sont propres vous payez selon le nombre de CPU et la mémoire disponible. Donc on ne réserve pas des serveurs mais une quantité de CPU et de ram !
On dispose d’un simulateur en ligne très pratique
Un exemple :
$0.031611 / vCPU hour
et pour la ram $0.004237 / GB hour
Google considère dans son calculateur que les mois font 730 heures, donc pour une machine 8 vcpu / 30 Go de ram
$0.031611 * 8 * 730 + $0.004237 * 30* 730 = 277 $ par mois.
A noter que les prix diffèrent selon la zone où vous prenez ces ressources.
Pour les systèmes managés, dans notre cas Cloud SQL et Redis, la facturation se fait de la même manière mais pour Cloud SQL la taille du disque compte aussi.
L’usage que vous faites de votre base SQL ne compte pas dans la facturation. Autant d’insert/update/select que vous voulez !
Sur l’interface on peut grouper ou filtrer par projets (ex prod et preprod) et ensuite détailler par produit (Compute Engine, CloudSQL, Redis, Stackdriver… donc en séparant les ressources VM et les produits managés comme CloudSQL)
On trouve le montant consommé sur le mois en cours et une estimation pour le mois complet.
Sur le graphique ci dessus, groupé par produit, on obtient la consommation séparée entre Compute Engine, Cloud SQL, Stack Driver…
On peut aussi filtrer par SKU. Là on va détailler les ressources (réservées ou pas) en séparant cpu et ram, le réseau (egress par zone), le stockage, les licences, les logs… On est au niveau le plus fin.
Petite astuce pour savoir combien vous payez de bande passante sortante de GCP, il faut sélectionner tous les SKU de type egress
Une fois votre archi définie, vous pouvez donc penser qu’il est assez simple d’anticiper votre facture de fin de mois.
La bande passante sortante est un peu à part car pas forcément connue (notre ancien hébergeur nous donnait juste un débit au 95 percentile donc pas de volume), il faut donc faire une estimation (qui s’est avérée bonne !).
Optimiser sa facture
Je vois 6 axes :
Réduire le nombre de serveurs
Optimiser les capacités des serveurs
Réserver les ressources sur un ou trois ans
Profiter des remises pour haute utilisation (sustained)
Eteindre temporairement des serveurs
Passer sur des services managés ou sur GKE
Réduire le nombre de serveurs
Nous étions partis sur des hypothèses prudentes en reprenant le même nombre de serveurs que sur notre ancienne plate forme.
Notre idée consistait, une fois passés sur GCP, à observer le comportement de nos serveurs et quand on aurait suffisamment de recul, voir si on pouvait optimiser.
Dans notre cas, on est passés assez vite de 10 serveurs fronts à 8 puis une semaine après à 6.
Une fois arrivé au niveau bas jugé un peu critique, la solution consiste à mettre un minimum “confortable” puis à mettre en place de l’auto scaling par groupe de serveurs. L’Equipe.fr ayant un très fort trafic (1,5 milliard de pages vues / mois) on peut penser que 4 fronts + de l’auto scaling serait une bonne solution.
Optimiser les capacités des serveurs
Certaines machines peuvent nécessiter la ram que vous aviez prévue mais sous utiliser la cpu ou l’inverse.
Dans notre cas on a observé que nos 2 Varnish avaient besoin d’un peu plus de ram que les 30 Go de départ par contre leur cpu était sous utilisée. On a donc passé ces machines de 8 cpu / 30 Go à 6 cpu / 34 Go ce qui fait gagner environ 15 € /mois par machine.
NB pour les machines “custom” on n’est pas tout à fait libre de son choix
La ram doit être comprise entre 0,9 Go et 6,5 Go par CPU.
Pour nos machines back qui étaient initialement en 8 cpu / 30 Go ram et qui avaient manifestement trop de cpu idle, on voulait 4 cpu mais on ne pouvait donc monter qu’à 4*6,5=26 Go de ram ce qui était par contre un peu juste. On a en conséquence pris 5 cpu / 30 Go
Attention le tarif des ressources change pour les machines custom
https://cloud.google.com/compute/pricing?hl=fr#custommachinetypepricing
puis aller sur le simulateur de coût
https://cloud.google.com/products/calculator/?hl=fr#
Réserver les ressources sur un ou trois ans
C’est le moyen le plus radical pour diminuer sa facture
https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts?hl=fr
A noter quand même que si cette réservation est très simple à faire et donne droits à des remises, elle est payante.
J’ai mis quelques temps à bien comprendre la ligne que l’on voit quand on détaille les coûts par SKU
Commitment v1: Cpu in EMEA for 3 Year : cet item est juste un coût de réservation. Il est un peu curieux que Google fasse payer cette possibilité. Et ce coût n’est pas mentionné quand on réserve d’ailleurs !
On voit ci dessous que nous avons fait sur notre prod 3 réservations.
Je conseille de garder un peu de marge en pensant que vous pourrez peut être optimiser et réduire vos ressources.
NB Les réservations se font par projet sans possibilité de transfert entre projets !
Profiter des remises pour haute utilisation (sustained)
Plus vous laissez vos machines allumées (en général pour la prod on n’éteint jamais !) plus vous obtenez de ristourne
Attention on peut lire “jusqu’à 60 % de remise” mais c’est juste sur le 4eme quart donc au total une machine utilisée un mois complet bénéficie de 30 % de réduction.
Donc pour un projet qui ne change pas ses ressources sur un mois vous avez une courbe typique comme ci dessous avec 4 paliers
Eteindre temporairement des serveurs
C’était une option envisagée pour notre preprod mais on perd alors les remises pour haute utilisation et on introduit un peu de complexité à automatiser ce process.
On a finalement jugé que le jeu n’en valait pas la chandelle.
Passer sur des services managés ou sur GKE
Les actions listées ci dessus vont vous permettre d’optimiser votre existant, pour réduire plus nettement votre facture, une piste à explorer est d’utiliser plus de services managés de GCP mais ceci implique des changements dans vos applicatifs.
Exports Big Query et Data Studio
L’interface de billing est assez complète mais si vous voulez partager certains indicateurs sans donner accès à tout le monde à l’interface de billing, Data Studio est la bonne solution.
A noter qu’on peut mettre des labels sur les machines par exemple si on veut répartir les coûts entre différents projets à des fins analytiques.
Les coûts de bande passante
Si vous voulez connaître vos coûts de bande passante sortante de GCP vous devez sélectionner tout ce qui est egress dans les SKU.
A noter que le coût du Go sortant de GCP vers vos CDN par exemple est assez élevé (8c le Go) comparativement à un tarif CDN bien négocié.
Certains CDN (comme Fastly ou Akamai mais selon votre offre) ont des accords avec Google qui vous permettront de payer cette bande passante sortante à votre prix CDN et non celui de Google. Si vous avez beaucoup de bande passante comme L’Equipe, c’est un point à ne pas négliger.
Conclusion
Avoir toutes ces données de facturation est très intéressant mais les suivre au jour le jour prends du temps. Pas de là à avoir un poste FinOps à temps plein mais prévoyez quelqu’un dans vos équipes pour au moins surveiller au quotidien. Je recommande aussi d’activer les alertes sur les montants consommés pour réagir plus vite.
Enfin il vous faudra définir les rôles de billing dans votre organisation. Qui donne les accès, qui a accès à quel projet… Cette partie demande un peu de temps au départ mais est obligatoire.
