On aimerait bien sûr éviter d’avoir à payer pour une machine inutile. Nous allons voir qu’il y a un moyen d’avoir zéro machine tout en ayant un système de scaling automatique.
Il y a cependant un pré-requis : il nous faut un moyen de savoir quand est-ce qu’il est nécessaire de scale up de nouveau.
Chez Adenlab nous utilisons une taskqueue (MRQ) pour nos tâches récurrentes. MRQ nous permet d’aiguiller nos jobs vers des worker groups spécifiques, en fonction de la queue et/ou de la tâche elle-même. Chaque worker group est lié à un ASG, nous avons donc ici une métrique claire : pour un ASG donné, avons-nous des jobs en attente ?
Avec tout ça nous pouvons utiliser la structure d’ASG suivante :
Une petite (lire: pas chère) machine qui sera toujours up (pas auto-scalée)
Un ou plusieurs ASG, sans politique d’auto-scaling
En créant un ASG sans politique d’auto-scaling, GCE nous laissera bien scale à zéro machine si nous le voulons. Sur notre petite machine nous aurons un script qui tournera toutes les 5 minutes et qui vérifiera pour chaque worker group MRQ s’il y a des jobs à traiter.
Si c’est le cas, le script créera une politique d’auto-scaling pour le worker group concerné et le fera un premier scale-up à 1 machine. L’auto-scaler pourra ajouter des machines supplémentaires si besoin, en fonction de la métrique de base configurée (dans notre cas, l’utilisation CPU).
Ecrivons une tâche MRQ pour ce script. Déjà les imports nécessaires :
from mrq.task import Task
from google.oauth2 import service_account
from googleapiclient import discovery
import time
import re
Premièrement, nous devons configurer quelques paramètres concernant GCP :
class ScaleUp(Task):
project_name = "name of your GCP project"
zone = "europe-west1-c" # adapt your zone here
service_account_path = "service_account_credentials.json"
# groups that are not concerned by this task
groups_to_skip = ("group1",)
Ajoutez à groups_to_skip les worker groups qui ne devraient pas être auto-scalés : ajoutez au moins le groupe de la machine qui dépilera cette tâche.
Maintenant écrivons la méthode principale de notre tâche :
def run(self, params):
credentials = service_account.Credentials
.from_service_account_file(
self.service_account_path
)
self.service = discovery.build(
"compute",
"v1",
credentials=credentials,
cache_discovery=False
)
# We need to have a way to know what we want our different
# autoscaling policies to be.
# We could store them in a DB and fetch them here,
# so that it is shared with our Ansible playbooks for instance.
# For simplicity here we'll just hardcode them here:
self.autoscaler_configs = {
"group2": {
"min_replicas": 1,
"max_replicas": 10,
"cooldown": 180,
"cpu_target": 0.80
},
"group3": {
"min_replicas": 1,
"max_replicas": 8,
"cooldown": 180,
"cpu_target": 0.90
}
}
# First we need to fetch existing ASGs
self.fetch_groups()
# Next we want to know which groups currently have an autoscaler
self.fetch_autoscalers()
# Check each groups and see if we should scale them up
self.check_groups()
Voici comment récupérer les infos sur les ASG :
def fetch_groups(self):
self.groups = {}
request = self.service.instanceGroupManagers()
.list(
project=self.project,
zone=self.zone
)
while request is not None:
response = request.execute()
for asg in response['items']:
group_name = asg["baseInstanceName"]
self.groups[group_name] = {
"base_name": group_name,
"name": asg["name"],
"size": asg["targetSize"],
"link": asg["selfLink"]
}
request = self.service.instanceGroupManagers()
.list_next(
previous_request=request,
previous_response=response
)
On hydrate self.groups avec les infos des ASGs. Pour plus d’infos sur la structure des ASGs, allez voir ici.
Maintenant jetons un oeil au code que nous utiliserons pour créer un autoscaler pour un worker group donné :
def create_autoscaler(self, group):
autoscaler_config = self.autoscaler_configs[group]
config = {
"target": self.groups[group]["link"],
"name": "%s-as" % group,
"autoscalingPolicy": {
"minNumReplicas": autoscaler_config["min_replicas"],
"maxNumReplicas": autoscaler_config["max_replicas"],
"coolDownPeriodSec": autoscaler_config["cooldown"],
"cpuUtilization": {
"utilizationTarget": autoscaler_config["cpu_target"]
}
}
}
operation = self.service.autoscalers().insert(
project=self.project,
zone=self.zone,
body=config
)
wait_for_operation(operation)
Vous pouvez trouver le code de wait_for_operation dans cet exemple.
La dernière chose dont nous ayons besoin est une méthode pour scale up un ASG :
def scale_up(self, group, size=1):
if self.groups[group]["size"] > 0:
# Already scaled up
return
# Make sure we have an autoscaler
if not self.autoscalers.get(group):
self.create_autoscaler(group)
operation = self.service.instanceGroupManagers().resize(
project=self.project,
zone=self.zone,
instanceGroupManager=self.groups[group]["name"],
size=size
)
wait_for_operation(operation)
La logique finale de notre tâche est assez simple :
def check_groups(self):
# Now we have everything we need for the actual task logic:
for group in self.groups:
if group in self.groups_to_skip:
continue
if self.should_scale_up(group):
self.scale_up(group)
should_scale_down est la méthode qui doit contenir votre logique de scaling. Nous ne la fournissons pas ici, mais rappelez-vous que dans notre cas il s’agit de vérifier si nous avons des jobs en attente ou non.
Cette tâche est planifiée pour être exécutée toutes les 5 minutes. Cela est pratique pour notre cas d’usage car même si aucun job n’est en attente, un membre de l’équipe peut à tout moment exécuter une action qui entrainera la création d’un nouveau job.
On ne veut pas avoir à attendre trop longtemps avant que celui-ci soit démarré. Bien entendu pour toute action utilisateur qui crée des jobs et qui sont supposées obtenir une réponse rapidement, il nous faut une machine dédiée qui soit toujours up.
Dans la plupart des cas cependant il vaut mieux éviter d’avoir des tâches asynchrone pour les interactions utilisateurs qui ont besoin d’un feedback.
Nous pouvons donc maintenant scale up une machine quand on en a besoin et GCE prendra le relai s’il y en a besoin de plus. Mais nous avons aussi besoin d’un moyen de scale à zéro quand il n’y en a de nouveau plus besoin !
Pour cela nous avons une seconde tâche, exécutée toutes les 30 minutes, qui exécutera le même code que la première, à la différence qu’elle supprimera l’autoscaler et scalera à 0 machine s’il n’y a plus aucun job en attente.
Nous pouvons faire hériter notre nouvelle tâche de la précédente afin d’avoir à disposition les méthodes utiles pour communiquer avec GCP :
class ScaleDown(ScaleUp):
Nous avons aussi besoin de quelques nouvelles méthodes pour pouvoir scale down :
def delete_autoscaler(self, group):
autoscaler = self.autoscalers[group]
operation = self.service.autoscalers().delete(
project=self.project,
zone=self.zone,
autoscaler=autoscaler["name"]
)
wait_for_operation(operation)
def scale_down(self, group):
if self.groups[group]["size"] == 0:
# Already scaled down
return
# Delete the autoscaler so that we can scale to zero machine
if self.autoscalers.get(group):
self.delete_autoscaler(group)
operation = self.service.instanceGroupManagers().resize(
project=self.project,
zone=self.zone,
instanceGroupManager=self.groups[group]["name"],
size=0
)
wait_for_operation(operation)
def check_groups(self):
for group in self.groups:
if group in self.groups_to_skip:
continue
if self.should_scale_down(group):
self.scale_down(group)
Quand on sait qu’il n’y a plus aucun job en attente, on supprime l’autoscaler et on scale down complètement. De nouveau, should_scale_down contient la logique de scale down à implémenter.
Le côté positif de cette approche est que nous pouvons avoir plusieurs critères de scaling. Par exemple, afin d’éviter de scale up et down plusieurs fois de suite de manière trop rapprochée, on peut également vérifier qu’un certain temps s’est écoulé sans avoir de job créé avant de scale down.
