TP: Scaling

Principe

  • Surveiller le nombre de calculs en cours sur chaque worker
  • Démarrer un nouveau worker si les workers sont trop chargés
  • Arrêter un worker si les workers non sont pas assez sollicités

Point de rupture

On suppose que l’API doit mettre moins de 10s à répondre à une requête de chiffrement/déchiffrement. Déterminez, de manière théorique en fonction de vos déploiements, au bout de combien de requêtes de chiffrement simultanées l’API ne répondra plus correctement. Effectuez un test de charge pour vérifier votre modèle théorique.

Instrumentation de worker

Une version légèrement modifiée du worker est disponible dans la branche tp-scaling du dépôt des applications. Cette version assure qu’un worker ne peut pas effectuer du simulation de chiffrement/déchiffrement simultanées afin de simuler la consommation de ressource CPU.

Ajouter deux compteurs Prometheus à worker:

  • un compteur de chiffrement/déchiffrement démarrés et un compteur de chiffrement/déchiffrement terminés;
  • ces compteurs seront globaux à chaque worker (i.e. il ne dépendront ni de la clé, ni de l’opération).

Contrôleur de worker

Créer une nouvelle application workercontroller. Celle-ci va gérer les instances de worker.

Ajouter le client kubernetes (lien pour Java) à votre application. Configurer celle-ci pour qu’elle puisse se connecter depuis le cluster (exemple en Java). Un début d’application en Java est fourni dans le dépôt des applications, dans la branche tp-scaling.

Le répertoire kubernetes contient du fichiers de déploiement: un pour créer une service account et un rôle associé afin de pouvoir utiliser kubernetes de puis un conteneur déployé en interne et un pour lancer un job de test. Adapter ces deux fichiers et déployer le job pour vérifier que vous pouvez récupérer la liste des pods de votre déploiement de worker (en l’affichant dans le log de votre worker-controller) et effectuer un scale up du déploiement de l’API.

Remarque: il peut être nécessaire de changer le nom du déploiement dans le code du workercontroller. Dans ce cas il faudra reconstruire l’image docker, la pousser sur votre registre privé et changer la configuration du job pour utiliser cette nouvelle version.

Modifier ensuite votre contrôleur de worker pour

  1. Requêter chacun des pods worker pour récupérer les valeurs des compteurs de chiffrement/déchiffrement. En déduire le nombre moyen d’opérations en cours par worker.
  2. Si cette moyenne dépasse un seuil max (fixé par configuration du contrôleur) augmenter le nombre de workers. Essayer de réfléchir à une augmentation du nombre de workers dépendant de l’importance du dépassement.
  3. Si cette moyenne est au contraire sous un seuil min, diminuer le nombre de workers
  4. Répéter les étapes 1 à 3 à intervalle régulier (fixé par configuration du contrôleur).

On déploiera le contrôleur comme un déploiement étant donné qu’il doit fonctionner en continu.

Faire un test de charge et vérifier que votre contrôleur déclenche bien la création de nouvelles instances.