Performances du matériel nu par rapport aux machines virtuelles dans le cloud : une comparaison pratique

Le marketing autour des infrastructures cloud met l'accent sur la flexibilité, la portée mondiale et les services gérés. La comparaison des performances entre les machines virtuelles cloud et le matériel bare metal n'apparaît que rarement dans ces supports marketing, car elle n'est pas favorable aux machines virtuelles cloud pour les charges de travail soutenues et prévisibles.

Cet article explique pourquoi les machines virtuelles dans le cloud ne sont pas aussi performantes que les serveurs physiques, comment voir ces différences dans ton propre environnement, les types de tâches où le cloud est vraiment plus efficace, et à partir de combien de dépenses mensuelles les serveurs physiques deviennent le choix le plus rentable.

Temps volé par le processeur : le coût caché des performances

C'est quoi le temps volé par le processeur ?

Le temps volé au processeur, c'est le pourcentage de temps où le vCPU d'une machine virtuelle attend que l'hyperviseur le planifie sur un cœur physique. Quand plusieurs machines virtuelles partagent un serveur physique, leurs vCPU se disputent le temps processeur physique. Quand ta machine virtuelle veut s'exécuter mais que l'hyperviseur sert une autre machine virtuelle, ce temps d'attente s'accumule sous forme de temps volé.

Le temps volé est visible sous Linux dans la colonne « st » de la sortie top ou mpstat. Sur une machine virtuelle cloud en bon état et peu sollicitée, le temps volé peut être de 0 à 2 %. Sur un hôte cloud très sollicité pendant les heures de pointe, un temps volé de 10 à 30 % n'est pas rare et signifie que votre application reçoit 70 à 90 % du CPU sur lequel elle pense fonctionner.

Comment le vol de temps affecte les applications

L'impact du vol de temps n'est pas pareil pour tous les types de charge de travail :

• Les applis sensibles à la latence (API, bases de données, traitement en temps réel) : le temps volé ajoute directement au temps de réponse. Une requête de base de données de 10 ms avec 15 % de temps volé prend 11,5 ms. Sous une charge soutenue, la latence p99 (les 1 % de requêtes les plus longues) grimpe de façon disproportionnée parce que le temps volé n'est pas réparti de manière égale.
• Traitement par lots (ETL, sauvegardes, génération de rapports) : le temps volé rallonge la durée totale du job de manière proportionnelle. Un job ETL de 2 heures sur une machine virtuelle avec 20 % de temps volé prendra 2,5 heures.
• Charges de travail basées sur le débit (traitement de fichiers, transcodage) : le débit baisse proportionnellement au pourcentage de vol.

Sur du matériel nu, le temps volé est zéro par définition. Le processeur n'est pas partagé. Le code de l'application s'exécute quand le système d'exploitation le planifie, pas quand un hyperviseur donne la permission.

L'effet du voisin bruyant

Comment les infrastructures partagées créent de la variabilité

Un voisin bruyant, c'est quand un autre locataire du même serveur physique ralentit ta application. Ça affecte pas juste le CPU :

• Pression sur la mémoire : les hyperviseurs utilisent des pilotes de ballon mémoire pour récupérer de la RAM auprès des machines virtuelles quand la mémoire physique de l'hôte est limitée. La mémoire allouée à ta machine virtuelle peut être réduite sans avertissement, ce qui déclenche un échange de données par le système d'exploitation.
• E/S réseau : les cartes réseau physiques sont partagées. Une machine virtuelle qui transfère des fichiers volumineux peut saturer la bande passante des cartes réseau partagées, ce qui ralentit le débit réseau pour toutes les machines virtuelles sur le même hôte.
• E/S de stockage : le stockage en bloc dans le cloud (EBS, disque persistant) passe par une structure réseau partagée. Les E/S intensives des locataires voisins ralentissent les IOPS pour tous ceux qui partagent ce cluster de stockage.

Les fournisseurs de cloud mettent en place des contrôles (crédits d'E/S, limites de bande passante, systèmes de crédits CPU) qui limitent l'impact des voisins bruyants. Ces contrôles limitent aussi vos propres performances de pointe. Les instances t3 sur AWS utilisent des crédits CPU : excellentes performances moyennes avec une capacité de pointe, mais les charges de travail intensives en CPU épuisent les crédits et ralentissent à la valeur de base.

Bande passante mémoire sur les machines virtuelles Bare Metal vs Cloud

La bande passante mémoire est souvent le goulot d'étranglement pour les charges de travail liées aux bases de données et à l'analyse, mais les spécifications des machines virtuelles cloud ne mentionnent généralement pas la bande passante mémoire. Pourquoi ? Parce que les machines virtuelles cloud partagent les canaux mémoire du serveur physique avec d'autres machines virtuelles, donc la bande passante disponible par machine virtuelle n'est qu'une fraction du total du matériel physique.

Un serveur physique avec DDR5-4800 en configuration 4 canaux a une bande passante maximale théorique d'environ 153 Go/s. Sur un hôte physique exécutant 4 machines virtuelles, la bande passante mémoire effective de chaque machine virtuelle approche les 38 Go/s dans des conditions idéales. En cas de contention, elle diminue encore davantage.

Sur le serveur dédié Extreme d'InMotion, toute la bande passante DDR5 de 153 Go/s est réservée à ta charge de travail. Pour les tâches d'analyse qui scannent de gros ensembles de données, cette différence est le principal facteur d'amélioration des performances lors de la migration du cloud vers le bare metal.

E/S de stockage : réseau ou NVMe direct

Architecture de stockage en bloc dans le cloud

AWS EBS, Google Persistent Disk et Azure Managed Disks sont des systèmes de stockage en réseau. Ta machine virtuelle envoie des requêtes d'E/S par blocs via le réseau interne du centre de données à un cluster de stockage. Ça ajoute environ 0,5 à 2 ms de latence par opération d'E/S par rapport au stockage local, et limite le nombre maximal d'IOPS et le débit en fonction du niveau de provisionnement du volume.

Type de stockage	Latence typique	Lecture séquentielle	IOPS aléatoires	Coût
AWS EBS gp3 (provisionné)	0,5-1 ms	1 000 Mo/s (max.)	16 000 IOPS (max.)	0,08 $/Go/mois + frais IOPS
AWS EBS io2 Block Express	0,1-0,2 ms	4 000 Mo/s	256 000 IOPS (max.)	0,125 $/Go/mois + 0,065 $/IOPS fournis
InMotion NVMe direct)	0,05-0,1 ms	5 000 à 7 000 Mo/s	500 000 à 1 million d'IOPS	Inclus dans le coût du serveur

La différence de prix est énorme. Pour avoir 3,84 To de stockage AWS EBS gp3, ça coûte environ 307 $ par mois juste pour le volume, sans compter le provisionnement IOPS. Le même NVMe de 3,84 To est inclus dans le serveur dédié Extreme InMotion Hostingpour moins cher. Le stockage connecté au cloud n'est pas au même prix que NVMe local.

Différences de performance du réseau

Latence pour les utilisateurs finaux

Les serveurs cloud et dédiés ont tous les deux des caractéristiques de latence qui dépendent surtout de la distance physique par rapport aux utilisateurs finaux et de la qualité du routage réseau. Les fournisseurs de services cloud ont un avantage en termes de distribution mondiale : AWS, Google et Azure ont des régions sur tous les continents, tandis InMotion Hosting des centres de données à Los Angeles et Amsterdam.

Pour les applis qui servent surtout les utilisateurs en Amérique du Nord et en Europe de l'Ouest, les centres de données d'InMotion couvrent les principales bases d'utilisateurs. Los Angeles est super pratique pour les utilisateurs nord-américains ; Amsterdam sert les utilisateurs d'Europe de l'Ouest avec une faible latence et respecte les exigences de l'UE en matière de résidence des données. Les applis qui ont besoin d'être présentes en Asie du Sud-Est, en Australie ou en Amérique du Sud peuvent avoir besoin d'une couche CDN ou d'un déploiement cloud réparti géographiquement.

Prévisibilité vs performance de pointe

La bande passante du réseau cloud est souvent limitée par les restrictions de pointe au niveau de l'instance et la capacité partagée de la carte réseau. Un c5.2xlarge sur AWS offre jusqu'à 10 Gbit/s de bande passante réseau, avec une mention « Jusqu'à 10 Gbit/s », ce qui veut dire un accès ponctuel à 10 Gbit/s, mais avec un débit réel plus bas et soumis à la gestion du trafic.

Les serveurs dédiés d'InMotion ont un port 1 Gbit/s et tu peux passer à un port illimité garanti à 10 Gbit/s. Le débit garanti de 10 Gbit/s, c'est pas pareil que le « débit pouvant atteindre 10 Gbit/s ». Pour les applis qui ont besoin d'un transfert à haut débit constant (streaming vidéo, distribution de gros fichiers, ingestion de données), le débit garanti est super utile.

Référence : temps de réponse des requêtes de base de données

Une comparaison pratique de la latence des requêtes de base de données p50 et p99 sur des machines virtuelles cloud par rapport à du matériel nu pour un PostgreSQL de taille moyenne (ensemble de travail de 50 Go, mélange de requêtes OLTP standard) :

Environnement	Latence p50	Latence p99	Utilisation du processeur (moyenne)	Notes
AWS RDS db.r5.2xlarge	4 ms	45 ms	N/A (géré)	Charge réseau vers le point de terminaison RDS
AWS EC2 r5.2xlarge (64 Go)	3 ms	38 ms	3 à 12 %	Overhead de stockage EBS + temps volé
InMotion Advanced (64 Go DDR4, NVMe)	2,5 ms	12 ms	0%	NVMe local, pas de temps volé
InMotion Extreme (192 Go DDR5 ECC, NVMe)	1,8 ms	8 ms	0%	Ensemble complet de travail dans le pool de tampons

C'est au niveau de la latence p99 que la différence est la plus marquée. Les 1 % de requêtes les plus problématiques sur l'infrastructure cloud sont affectées par des pics de temps volé et la variabilité du réseau de stockage. Sur le matériel nu, les performances p99 restent proches des performances médianes, car aucune de ces sources de variabilité n'est présente.

Les avantages des machines virtuelles dans le cloud

Une comparaison honnête montre les domaines où l'infrastructure cloud est vraiment plus performante que les serveurs dédiés bare metal :

• Auto-scaling : l'infrastructure cloud s'adapte horizontalement en quelques minutes. Ajouter un serveur bare metal prend des heures, voire des jours, pour être prêt.
• Distribution mondiale : 15 à 30 régions cloud contre 2 centres de données InMotion. Les applications qui ont besoin d'être présentes sur plusieurs continents profitent de la présence mondiale du cloud.
• Services gérés : RDS , ElastiCache, Lambda et d'autres services gérés similaires soulagent les équipes qui n'ont pas de personnel dédié à l'infrastructure.
• Charges de travail intermittentes : un job batch qui tourne 2 heures par semaine coûte quelques centimes sur les instances cloud spot. Un serveur dédié coûte le même prix, qu'il tourne 1 heure ou 720 heures par mois.

Prendre la décision

• Si votre charge de travail est continue et nécessite des performances prévisibles, les serveurs dédiés bare metal sont plus avantageux en termes de coût et de performances.
• Si ta charge de travail change beaucoup et de façon imprévisible, la flexibilité du cloud peut valoir le coût supplémentaire.
  • Si tu dépenses plus de 300 $ par mois en cloud computing pour une charge de travail stable : fais la comparaison bare metal.
• Si la variabilité de la latence p99 affecte les accords de niveau de service (SLA) de votre application, le temps de vol nul de Bare Metal s'attaque à la cause profonde du problème.