Qu'est-ce qu'un «vCPU» et quelles sont ses performances?

Les fournisseurs de serveurs cloud annoncent souvent leurs instances comme ayant un certain nombre de «vCPU», abréviation de CPU virtuel. Quelle performance pouvez-vous attendre de cela par rapport à un CPU normal?

La différence entre les cœurs et les threads

Il est important de comprendre la distinction entre un thread de traitement et un cœur de processeur. Les processeurs auront un nombre défini de cœurs qui gèrent l'exécution des programmes. Mais même les tâches très intensives n'utilisent pas 100% du CPU tout le temps; les programmes doivent souvent attendre les lectures de la mémoire à partir du cache L3, de la RAM et des disques, et vont souvent se mettre en veille en attendant l'arrivée des données. Pendant ce temps, le cœur du processeur est inactif.

La solution à ce problème est appelée «hyperthreading» ou «multithreading simultané». Plutôt que d'exécuter un ensemble de tâches à la fois, le processeur est capable de gérer plusieurs threads. Actuellement, presque tous les processeurs haut de gamme d'Intel ou d'AMD prennent en charge deux threads par cœur.

Selon l'application, l'hyperthreading peut donner une accélération théorique de 100%, si les deux threads attendent des lectures de mémoire et ne sont pas en conflit l'un avec l'autre. Dans la plupart des cas, l'hyperthreading donne un gain de vitesse d'environ 30% par rapport à l'absence d'hyperthreading. Dans certains cas, cependant, lorsque deux threads sont épinglés à 100% et exécutés sur le même cœur, cela peut provoquer des ralentissements alors qu'ils se battent pour les ressources du processeur.

Qu'est-ce qui fait un vCPU?

Les vCPU sont à peu près comparables à un seul thread de traitement, mais ce n'est pas exactement une comparaison juste.

Dites que vous louez un c5.large instance d'AWS avec 2 vCPU. Votre application s'exécutera avec de nombreuses autres sur un grand serveur. Vous pouvez réellement louer l'intégralité du serveur avec une instance AWS Bare Metal, qui vous donne un accès direct au processeur. Si vous louez quelque chose de plus petit que cela, votre accès est géré via AWS Nitro.

Nitro est un hyperviseur, qui gère la création et la gestion des machines virtuelles s'exécutant sur le serveur lui-même. C'est pourquoi vous louez un «serveur virtuel» et non un rack dans un centre de données. Nitro est ce qui fait fonctionner EC2; il est alimenté en partie par du matériel dédié, de sorte que le ralentissement de l'exécution dans un environnement virtualisé devrait être minime.

Nitro décide des threads auxquels affecter votre machine virtuelle en fonction de la puissance de traitement nécessaire, un peu comme le fait un planificateur de tâches dans un environnement de bureau normal. Avec 2 processeurs virtuels, le pire des cas est que votre application s'exécute sur un seul cœur et reçoit les deux threads de ce cœur. Si vous maximisez vraiment votre instance, vos threads peuvent entrer en conflit et provoquer des ralentissements mineurs. Il est difficile de dire exactement comment l'hyperviseur AWS fonctionne, mais il est probablement sûr de supposer que ce scénario est largement atténué avec une bonne gestion des threads de la part de Nitro.

Donc, dans l'ensemble, vous pouvez probablement vous attendre à des performances comparables à un thread CPU normal, sinon un peu mieux. La distinction n'a pas beaucoup d'importance de toute façon, car la plupart des instances EC2 seront livrées avec des multiples de 2 vCPU. N'oubliez pas qu'une instance 4 vCPU n'est pas un serveur 4 cœurs – elle émule vraiment un serveur 2 cœurs, exécutant 4 threads de traitement.

La vitesse de traitement du vCPU dépendra davantage du matériel réel sur lequel il fonctionne. La plupart des processeurs de serveur seront des Intel Xeons, car ils constituent la majorité du marché. Les serveurs bas de gamme peuvent exécuter un matériel plus ancien qui est un peu daté par rapport aux normes d'aujourd'hui. Les instances T3a d'AWS utilisent les processeurs AMD EPYC à nombre de cœurs élevé, fonctionnent un peu plus lentement, mais coûtent moins cher car le matériel est beaucoup moins cher par cœur.

Instances éclatables

Les instances AWS T2 et T3 sont «éclatables», ce qui convient mieux aux applications qui n'ont pas besoin d'être exécutées à 100% tout le temps.

Par exemple, le t3.micro l'instance a 2 vCPU, mais sa vitesse de base est de 10% d'un vCPU normal. En réalité, le t3.micro n'a que 0,2 vCPU, ce qui est en fait la façon dont Google Cloud Platform annonce leur f1-micro les instances.

Mais le t3.micro n’est pas seulement 90% plus lent dans l’ensemble; il est autorisé d'éclater au-delà de la vitesse de base pendant de courtes périodes, un peu comme le fonctionnement de la fréquence turbo sur un ordinateur ordinaire. Sauf que le facteur limitant ici n'est pas thermique, mais combien vous êtes prêt à payer.

Pour chaque heure pendant laquelle l'instance s'exécute en dessous de la vitesse de base, vous accumulez des crédits CPU, qui sont utilisés pour faire éclater l'instance pendant une minute. le t3.micro en particulier accumule 6 crédits CPU par heure qu'il s'exécute en dessous de la vitesse de base. Mais lorsque la puissance de traitement est nécessaire, les crédits CPU sont consommés pour dépasser la vitesse de base.

Ceci est bien adapté aux applications basées sur des micro-services, qui doivent répondre aux demandes lorsqu'elles se produisent, mais reste inactive jusqu'à ce que le prochain utilisateur demande quelque chose. Les services qui doivent tout le temps croquer les chiffres sont mieux adaptés aux serveurs traditionnels.

Cela permet à AWS d'exécuter plus d'instances T2 par serveur que ce dont le serveur serait normalement capable, ce qui permet de réduire les coûts. Par exemple, chaque rack de leur centre de données peut contenir un système à 48 cœurs avec 96 threads de traitement. Cela pourrait être utilisé pour 96 unités vCPU d'instances C5, mais les instances T2 sont capables de partager des cœurs et de s'exécuter à moins de 20% de la vitesse de base de base, de sorte qu'AWS peut exécuter plusieurs d'entre eux à partir du même serveur.