Get best of the week

Évaluation des métriques de charge du serveur intégré

Travaillant dans l'une des plus grandes banques du pays, j'ai dû faire face à la tâche d'évaluer l'efficacité de l'utilisation des ressources d'environ 16 000 serveurs. La tâche a été formulée très simplement - il était nécessaire de développer une méthodologie pour évaluer les métriques de charge du serveur pendant une période. Idéalement, la charge du serveur par période doit être estimée en utilisant un ou plusieurs (pas plus de 8) nombres.

Quelques mots sur les fonctionnalités d'utilisation des serveurs virtuels


Les grandes organisations (en particulier les banques) ont un zoo hétéroclite d'applications héritées déployées sur différents serveurs à l'aide d'une variété de technologies de virtualisation. Un cloud privé est une technologie prometteuse, mais en réalité, les grandes organisations utiliseront longtemps diverses plates-formes de virtualisation pour déployer une variété d'applications.

À mesure que les plateformes de virtualisation évoluent, il arrive un moment où personne dans l'entreprise ne peut comprendre l'efficacité avec laquelle les ressources sont utilisées. Même les outils de surveillance les plus avancés ne fournissent pas de réponse à cette question en raison de divers scénarios d'utilisation du serveur. Par exemple, un service peut avoir un serveur de rapports qui ne sera entièrement chargé que pendant une période de temps limitée. Dites 3-4 heures à la fin du mois. Dans des scénarios réels, personne n'alloue dynamiquement des ressources pour de tels serveurs - c'est difficile techniquement et organisationnellement. Les ressources sont allouées spécifiquement pour la charge de serveur périodique maximale, bien que cela arrive rarement.

En résumé, dans les grandes organisations, les ressources de la batterie virtuelle sont dépensées de manière extrêmement inefficace.

Ci-dessous, je propose une méthodologie avec laquelle vous pouvez facilement justifier l'augmentation et la diminution des ressources allouées au serveur virtuel, quel que soit le scénario.

Méthodologie


Pour évaluer la charge des ressources, il est nécessaire de collecter des statistiques de différents compteurs; pour évaluer la charge des ressources, différentes métriques seront utilisées. Classiquement, les compteurs peuvent être divisés en 2 types (selon le taux de changement): «rapide» et «lent». Un bon exemple de compteur «rapide» est le compteur de charge du processeur (% CPU). Un exemple de compteur lent est le pourcentage d'espace libre sur le disque dur (% FreeSpace).
L'évaluation des compteurs lents consiste à calculer la valeur extrême (minimum ou maximum) de la métrique pour la période. Cette approche permet (par exemple, lors de l'évaluation de l'espace libre sur le disque) d'estimer la ressource disponible et, si nécessaire, d'allouer des volumes supplémentaires ou de réduire les volumes actuels.

Pour les compteurs rapides, une approche différente est utilisée. Les inconvénients de l'utilisation de métriques intégrales simples (moyenne, maximum, minimum et médiane) pour évaluer la dynamique de tels compteurs sont bien décrits ici . Les inconvénients communs incluent le manque d'informations sur l'augmentation des charges (moyennes et maximales). Si nous prenons la valeur maximale de la période comme une métrique intégrale, la présence de valeurs aberrantes (par exemple, le chargement instantané du processeur jusqu'à 100% au démarrage du programme) ne donnera pas d'informations objectives.

Dans l' articleIl est proposé d'utiliser le quantile de 0,9 pour estimer la métrique rapide (il s'agit d'une valeur qui indique le niveau en dessous duquel se situe la valeur observée dans 90% des échantillons). Avec une charge de serveur uniforme selon cette métrique, nous pouvons estimer correctement la charge moyenne du processeur. Mais cette approche présente les mêmes inconvénients - le manque d'informations sur l'augmentation des charges (moyennes et maximales).

Ci-dessous, à titre d'illustration, le graphique hebdomadaire et quotidien du compteur% CPU. La valeur maximale du compteur sur les graphiques était de 100%.





Le graphique montre que dans la période indiquée, il y a une augmentation de la charge, qui dure environ 3 heures. Pour ce compteur, diverses mesures ont été calculées pour la semaine. La figure 2 montre que la médiane (ligne verte, valeur 5%), la moyenne (jaune, valeur 12%) et le quantile 0,9 (rouge, valeur 27%) filtrent le changement de charge et les informations le concernant sont perdues.

En tant que développement de l'idée des quantiles, je voudrais proposer l'idée de déplacer les quantiles. Il s'agit d'un analogue de la moyenne mobile.mais le quantile 0.9 est utilisé comme fonction de fenêtre. De plus, nous utiliserons 2 quantiles glissants pour estimer le niveau du contre - rapide avec une courte période (1 heure) et lent avec une longue période (24 heures). Un quantile rapide filtrera les émissions instantanées et fournira des informations sur les pics de charge. Un quantile lent vous permettra d'estimer la charge moyenne.

Comme vous pouvez le voir sur les graphiques, les quantiles mobiles de 0,9 sont des caractéristiques dynamiques (marron - rapide, violet - lent). Par souci de simplicité, il est proposé d'utiliser le statut du compteur en tant que métriques:

  • la valeur quantile maximale avec une période de 1 heure, qui indique la charge maximale continue du serveur pour la période,
  • la valeur quantile moyenne avec une période de 24 heures, qui montre la charge moyenne du serveur pour la période.

Sur le graphique, la valeur maximale du quantile rapide est la ligne noire à 85%, la valeur moyenne du quantile lent est la ligne rose à 30%.

Ainsi, lors de l'analyse de la charge des ressources du serveur (selon le compteur% CPU), si nous prenons la moyenne du mois (12%) comme métrique, nous pouvons prendre une décision erronée de réduire les ressources allouées. La double mesure quantile à déplacement rapide / lent (85 et 30%) montre qu'il y a suffisamment de ressources allouées, mais pas d'excédents.

Décision


La mise en œuvre de l'évaluation de l'efficacité de l'utilisation des ressources a été décomposée en 3 tâches:

  1. collecte de données
  2. élaboration d'une méthodologie d'évaluation
  3. mise en œuvre de la méthodologie dans l'architecture actuelle

Ci-dessus, j'ai examiné la tâche 2 de cette implémentation, ci-dessous nous parlerons un peu de la troisième tâche.

Les données ont été collectées dans la base de données ClickHouse. Cette colonne SGBD est idéale pour stocker des données de séries chronologiques. Cela a été discuté en détail lors du Meetup ClickHouse du 5 septembre 2019. Une comparaison de ClickHouse avec d'autres SGBD de séries chronologiques peut être trouvée ici .
À la suite de la collecte des données, nous avons formé plusieurs tableaux dans lesquels les données étaient organisées ligne par ligne (les valeurs de chaque compteur étaient écrites sur une ligne distincte). Et, bien sûr, il y avait des problèmes avec les données brutes.

Le premier problème est l'inégalité des intervalles entre les entrées de compteur. Par exemple, si la période d'enregistrement standard du compteur était de 5 minutes, il y avait parfois des lacunes et l'enregistrement suivant était supérieur à 5 minutes (jusqu'à 20 minutes) du précédent.

Le deuxième problème est que parfois les données du compteur arrivent 2 fois ou plus (avec des valeurs différentes) avec le même horodatage.

Et le troisième problème - ClickHouse n'a pas de fonctions de fenêtre.

Pour résoudre le premier problème, vous pouvez utiliser ASOF JOIN. L'idée est assez simple - pour chaque compteur de chaque serveur, créer une table uniformément avec des intervalles de temps également remplis. L'utilisation d'ASOF JOIN permet de remplir les valeurs de la nouvelle table avec les valeurs les plus proches de la table de données brutes (des options de remplissage similaires à ffill et bfill peuvent être configurées).

La solution au deuxième problème est l'agrégation avec le choix de la valeur maximale à un instant donné.

Pour résoudre le troisième problème, plusieurs solutions ont été envisagées. Tout d'abord, le script Python a été rejeté en raison de performances insuffisantes. La deuxième solution - copier des données brutes dans une base de données MSSQL, calculer des métriques et recopier - semblait trop compliquée à mettre en œuvre. MSSQL possède également des fonctions de fenêtre, mais aucune fonction d'agrégation n'est requise. On pourrait être perplexe et écrire votre propre fonction SQL CLR. Mais cette option a été rejetée en raison d'une complexité excessive.

Une solution de travail pourrait être un script SQL pour ClickHouse. Un exemple de ce script est donné ci-dessous. Par souci de simplicité, j'ai cherché à calculer uniquement le quantile rapide pour un seul compteur pour plusieurs serveurs. La solution n'a pas l'air très simple et pas très pratique, mais ça marche.

En conséquence, un rapport de test a été créé dans PowerBI pour démontrer la méthodologie.





Conclusion


En conclusion, je voudrais spéculer sur le développement de la solution. Si vous regardez la solution du point de vue des entrepôts de données, vous pouvez voir que la tâche de créer un entrepôt de données (entrepôt de données) à partir d'une couche de données brutes (zone de transit) est ainsi résolue. Vous pouvez discuter de l'architecture, mais pour ClickHouse en tant que base de données de colonnes, la normalisation n'est pas critique (ou peut-être même nuisible).

La poursuite du développement du référentiel se traduit par la création de tables agrégées (jour \ semaine \ mois) avec différentes durées de vie (TTL). Cela évitera un gonflement excessif du stockage.
L'étape suivante peut consister à utiliser les données pour l'analyse prédictive.

PS

Le code et les données pour les tests sont affichés ici .

More articles:


All Articles