De quelles performances votre serveur cloud a-t-il vraiment besoin?

La plupart des fournisseurs de cloud divisent leurs offres par le nombre de cœurs de processeur et la quantité de RAM. Avez-vous besoin d'un grand serveur multicœur, ou d'une flotte entière d'entre eux? Voici comment procéder pour mesurer les performances réelles de votre serveur.

Votre application doit-elle «évoluer»?

Il est très courant que les startups technologiques soient attirées par une architecture «évolutive», c'est-à-dire que vous construisez votre architecture de serveur de telle sorte que chaque composant de celle-ci puisse évoluer pour répondre à n'importe quelle quantité de demande.

C'est génial et tout, mais si vous ne rencontrez pas cette quantité de trafic dans le monde réel, il peut être exagéré (et plus cher) de construire une architecture évolutive dans le but d'augmenter jusqu'à un million d'utilisateurs si vous ne gérez que quelques milliers.

Vous souhaiterez privilégier la création d'une bonne application par rapport à la création d'une infrastructure exceptionnelle. La plupart des applications fonctionnent étonnamment bien avec seulement quelques serveurs standard faciles à gérer. Et, si votre application réussit, votre croissance se produira probablement au cours de quelques mois, vous donnant suffisamment de temps (et d'argent) pour travailler sur votre infrastructure.

Une architecture évolutive est toujours une bonne chose à construire, en particulier sur des services comme AWS où la mise à l'échelle automatique peut être utilisée pour réduire et économiser de l'argent pendant les heures creuses.

Vous devez planifier la charge de pointe

La chose la plus importante à garder à l'esprit est que vous ne planifiez pas autour de la charge moyenne, vous planifiez autour de la charge de pointe. Si vos serveurs ne peuvent pas gérer votre charge de pointe pendant midi, ils n'ont pas atteint leur objectif. Vous devez vous assurer que vous mesurez et comprenez la charge de votre serveur au fil du temps, plutôt que de simplement regarder l'utilisation du processeur en un seul instant.

L'architecture évolutive est utile ici. Être capable de faire tourner rapidement une instance ponctuelle (ce qui est souvent beaucoup moins cher) pour alléger une partie de la charge de vos serveurs principaux est un très bon paradigme de conception et vous permet de réduire considérablement les coûts. Après tout, si vous n'avez besoin que de deux serveurs pendant quelques heures par jour, pourquoi payer pour le faire fonctionner pendant la nuit?

La plupart des grands fournisseurs de cloud ont également des solutions évolutives pour des conteneurs comme Docker, qui vous permettent de faire évoluer les choses automatiquement, car votre infrastructure peut être dupliquée plus facilement.

Quelles sont les performances de votre serveur?

C'est une question difficile à répondre exactement; les applications et les sites Web de chacun sont différents et l'hébergement de serveur de chacun est différent. Nous ne pouvons pas vous donner de réponse exacte sur le serveur qui correspond le mieux à votre cas d'utilisation.

Ce que nous pouvez faire est de vous dire comment procéder par vous-même pour expérimenter ce qui fonctionne le mieux pour votre application particulière. Cela implique d'exécuter votre application dans des conditions réelles et de mesurer certains facteurs pour déterminer si vous êtes surchargé ou sous-chargé.

Si votre application est surchargée, vous pouvez faire tourner un deuxième serveur et utiliser un équilibreur de charge pour équilibrer le trafic entre eux, comme le service Elastic Load Balancer d'AWS ou Fastly's Load Balancing. S'il est considérablement sous-chargé, vous pourrez peut-être économiser quelques dollars en louant un serveur moins cher.

L'utilisation du processeur

L'utilisation du processeur est probablement la mesure la plus utile à considérer. Il vous donne un aperçu général de la surcharge de votre serveur; si votre utilisation du processeur est trop élevée, les opérations du serveur peuvent s'arrêter.

L'utilisation du processeur est visible dans topet les moyennes de charge des 1, 5 et 15 dernières minutes sont également visibles. Il obtient ces données de /proc/loadavg/, afin que vous puissiez vous connecter à un fichier CSV et le représenter graphiquement dans Excel si vous le souhaitez.

La plupart des fournisseurs de cloud auront cependant un bien meilleur graphique pour cela. AWS a CloudWatch, qui affiche l'utilisation du processeur pour chaque instance sous les métriques EC2:

Google Cloud Platform affiche un joli graphique sous l'onglet "Surveillance" dans les informations sur l'instance:

Dans les deux graphiques, vous pouvez ajuster les échelles de temps pour afficher l'utilisation du processeur au fil du temps. Si ce graphique atteint constamment 100%, vous voudrez peut-être étudier la mise à niveau.

Gardez à l'esprit, cependant, que si votre serveur a plusieurs cœurs, l'utilisation du processeur peut toujours être «surchargée», tandis que le graphique est loin d'être à 100%. Si votre utilisation du processeur est épinglée à près de 50% et que vous disposez d'un serveur double cœur, il est probable que votre application soit principalement à un seul thread et ne voit aucun avantage en termes de performances.

Utilisation de la RAM

L'utilisation de la RAM est moins susceptible de fluctuer beaucoup, car il s'agit principalement de savoir si vous en avez assez pour exécuter une certaine tâche.

Vous pouvez afficher rapidement l'utilisation de la mémoire dans top, qui affiche la mémoire actuellement allouée pour chaque processus dans la colonne "RES", ainsi que l'affichage de l'utilisation en pourcentage de la mémoire totale dans la colonne "% MEM".

Vous pouvez appuyer sur Shift + M pour trier par% MEM, qui répertorie les processus les plus gourmands en mémoire.

Remarque, mémoire la vitesse affecte la vitesse du processeur dans une certaine mesure, mais ce n'est probablement pas le facteur limitant, sauf si vous exécutez une application qui nécessite du métal nu et les vitesses les plus rapides possibles.

Espace de stockage

Si votre serveur manque d'espace, il peut bloquer certains processus. Vous pouvez vérifier l'utilisation du disque avec:

df -H

Cela affiche une liste de tous les périphériques connectés à votre instance, dont certains peuvent ne pas vous être utiles. Cherchez le plus gros (probablement /dev/sda1/), et vous pouvez voir combien est actuellement utilisé.

Vous devez utiliser efficacement la rotation des journaux et vous assurer que rien ne crée de fichiers excédentaires sur votre système. Si tel est le cas, vous souhaiterez peut-être le limiter à ne stocker que les derniers fichiers. Vous pouvez supprimer les anciens fichiers en utilisant find avec des paramètres de temps, attachés à un travail cron qui s'exécute une fois par heure:

0 * * * * find ~/backups/ -type f -mmin +90 -exec rm -f {} ;

Ce script supprime tous les fichiers du ~/backups/ dossier de plus de 90 minutes (utilisé pour un serveur Minecraft qui effectuait des sauvegardes de 1 Go + toutes les 15 minutes, remplissant un SSD de 16 Go). Vous pouvez également utiliser logrotate, qui obtient le même effet plus élégamment que cette commande écrite à la hâte.

Si vous stockez une tonne de fichiers, vous pouvez envisager de les déplacer vers un service de stockage géré comme S3. Ce sera moins cher que d'avoir des disques connectés à votre instance.

Vitesse réseau

Il n'y a pas un excellent moyen de surveiller cela nativement, donc si vous voulez obtenir une bonne sortie en ligne de commande, installez sar de sysstat:

sudo apt-get install sysstat

Activez-le en modifiant /etc/default/sysstat et en définissant «ENABLED» sur true.

Cela surveille votre système et génère un rapport toutes les 10 minutes, en les faisant tourner une fois par jour. Vous pouvez modifier ce comportement en modifiant la crontab sysstat à /etc/cron.d/sysstat.

Vous pouvez les collecter une moyenne du trafic réseau avec le -n drapeau:

sar -n DEV 1 6

Le, dirigez-le vers tail pour une sortie plus agréable:

sar -n DEV 1 6 | tail -n3

Il affiche une moyenne de paquets et de kilo-octets envoyés par seconde sur chaque interface réseau.

Il est cependant plus facile d'utiliser une interface graphique pour cela; CloudWatch a une statistique «NetworkIn» et «NetworkOut» pour chaque instance:

Vous pouvez ajouter une étiquette dynamique avec une fonction SUM, qui affiche le réseau total en octets pour une période de temps donnée.

Il est difficile de juger si vous surchargez ou non votre réseau; la plupart du temps, vous êtes limité par d'autres facteurs, par exemple si votre serveur peut ou non répondre aux demandes, avant de vous soucier de l'utilisation de la bande passante.

Si vous êtes vraiment préoccupé par le trafic ou souhaitez diffuser des fichiers volumineux, vous devriez envisager d'obtenir un CDN. Un CDN peut alléger la charge de votre serveur et vous permettre de servir des supports statiques très efficacement.