Rendimiento de bare metal frente a máquinas virtuales en la nube: una comparación práctica

El marketing de la infraestructura en la nube se centra en la elasticidad, el alcance global y los servicios gestionados. La comparación del rendimiento entre las máquinas virtuales en la nube y el hardware físico rara vez aparece en ese material de marketing, ya que la comparación no favorece a las máquinas virtuales en la nube para cargas de trabajo sostenidas y predecibles.

Este artículo trata sobre los mecanismos específicos por los que las máquinas virtuales en la nube tienen un rendimiento inferior al de los servidores físicos, cómo medir esas diferencias en tu propio entorno, las categorías de carga de trabajo en las que la nube realmente sale ganando y el nivel de gasto mensual en el que los servidores físicos se convierten en la opción económicamente más acertada.

Tiempo de robo de CPU: el coste oculto del rendimiento

¿Qué es el tiempo de robo de CPU?

El tiempo de robo de CPU mide el porcentaje de tiempo que la vCPU de una máquina virtual espera a que el hipervisor la programe en un núcleo físico. Cuando varias máquinas virtuales comparten un servidor físico, sus vCPU compiten por el tiempo de CPU físico. Cuando la máquina virtual quiere ejecutarse, pero el hipervisor está atendiendo a otra máquina virtual, ese tiempo de espera se acumula como tiempo de robo.

El tiempo robado se puede ver en Linux en la columna «st» de la salida de top o mpstat. En una máquina virtual en la nube en buen estado y con poca carga, el tiempo robado puede oscilar entre el 0 % y el 2 %. En un host en la nube con mucha carga durante las horas punta, no es raro que el tiempo robado sea del 10 % al 30 %, lo que significa que tu aplicación está recibiendo entre el 70 % y el 90 % de la CPU en la que cree que se está ejecutando.

Cómo afecta el tiempo robado a las aplicaciones

El impacto del tiempo robado no es uniforme en todos los tipos de carga de trabajo:

• Aplicaciones sensibles a la latencia (API, bases de datos, procesamiento en tiempo real): el tiempo robado se suma directamente al tiempo de respuesta. Una consulta a la base de datos de 10 ms con un 15 % de tiempo robado tarda 11,5 ms. Bajo una carga sostenida, la latencia p99 (el 1 % peor de las solicitudes) se dispara de forma desproporcionada porque el tiempo robado no se distribuye de manera uniforme.
• Procesamiento por lotes (ETL, copias de seguridad, generación de informes): el tiempo robado prolonga la duración total del trabajo de forma proporcional. Un trabajo ETL de 2 horas en una máquina virtual con un 20 % de tiempo robado tarda 2,5 horas.
• Cargas de trabajo basadas en el rendimiento (procesamiento de archivos, transcodificación): el rendimiento disminuye proporcionalmente al porcentaje de robo.

En el metal desnudo, el tiempo de robo es cero por definición. El procesador no se comparte. El código de la aplicación se ejecuta cuando el sistema operativo lo programa, no cuando un hipervisor concede permiso.

El efecto del vecino ruidoso

Cómo la infraestructura compartida genera variabilidad

El término «vecino ruidoso» describe la situación en la que la carga de trabajo de otro inquilino en el mismo servidor físico degrada el rendimiento de tu aplicación. Esto afecta a más que solo la CPU:

• Presión de memoria: los hipervisores utilizan controladores de globo de memoria para recuperar RAM de las máquinas virtuales cuando la memoria física del host está limitada. Es posible que la memoria asignada a tu máquina virtual se reduzca sin previo aviso, lo que provocaría el intercambio del sistema operativo.
• E/S de red: las tarjetas NIC físicas son compartidas. Una máquina virtual que realiza transferencias de archivos de gran tamaño puede saturar el ancho de banda de la tarjeta NIC compartida, lo que degrada el rendimiento de la red para todas las máquinas virtuales del mismo host.
• E/S de almacenamiento: el almacenamiento en bloque en la nube (EBS, disco persistente) atraviesa una estructura de red compartida. Las E/S intensivas de los inquilinos adyacentes degradan las IOPS para todos los inquilinos que comparten ese clúster de almacenamiento.

Los proveedores de servicios en la nube implementan controles (créditos de E/S, límites de ancho de banda, sistemas de créditos de CPU) que limitan el alcance de los vecinos ruidosos. Estos controles también limitan tu propio rendimiento máximo. Las instancias t3 en AWS utilizan créditos de CPU: excelente rendimiento medio con capacidad de ráfaga, pero las cargas de trabajo intensivas en CPU agotan los créditos y reducen la velocidad hasta el nivel básico.

Ancho de banda de memoria en máquinas físicas frente a máquinas virtuales en la nube

El ancho de banda de la memoria suele ser el cuello de botella para las cargas de trabajo de bases de datos y análisis, pero las especificaciones de las máquinas virtuales en la nube no suelen incluir el ancho de banda de la memoria. El motivo: las máquinas virtuales en la nube comparten los canales de memoria del servidor físico con otras máquinas virtuales, por lo que el ancho de banda disponible por máquina virtual es una fracción del total del hardware físico.

Un servidor físico con DDR5-4800 en configuración de 4 canales tiene un ancho de banda máximo teórico de aproximadamente 153 GB/s. En un host físico que ejecuta 4 máquinas virtuales, el ancho de banda de memoria efectivo de cada máquina virtual se aproxima a los 38 GB/s en condiciones ideales. En caso de conflicto, se reduce aún más.

En el servidor dedicado Extreme de InMotion, los 153 GB/s de ancho de banda DDR5 están dedicados por completo a tu carga de trabajo. Para los trabajos de análisis que escanean grandes conjuntos de datos, esta diferencia es el principal factor que impulsa la mejora del rendimiento al migrar de la nube al hardware físico.

E/S de almacenamiento: conectado a la red frente a NVMe directo

Arquitectura de almacenamiento en bloque en la nube

AWS EBS, Google Persistent Disk y Azure Managed Disks son sistemas de almacenamiento conectados a la red. Tu máquina virtual envía solicitudes de E/S por bloques a través de la red interna del centro de datos a un clúster de almacenamiento. Esto añade aproximadamente entre 0,5 y 2 ms de latencia por operación de E/S en comparación con el almacenamiento local, y limita el máximo de IOPS y el rendimiento en función del nivel aprovisionado del volumen.

Tipo de almacenamiento	Latencia típica	Lectura secuencial	IOPS aleatorias	Coste
AWS EBS gp3 (aprovisionado)	0,5-1 ms	1000 MB/s (máx.)	16 000 IOPS (máx.)	0,08 $/GB/mes + tarifas IOPS
AWS EBS io2 Block Express	0,1-0,2 ms	4000 MB/s	256 000 IOPS (máx.)	0,125 $/GB/mes + 0,065 $/IOPS aprovisionadas
InMotion NVMe directo)	0,05-0,1 ms	5000-7000 MB/s	500 000-1 millón de IOPS	Incluido en el coste del servidor

La comparación de costes es significativa. Proporcionar 3,84 TB de almacenamiento AWS EBS gp3 cuesta aproximadamente 307 dólares al mes solo por el volumen, sin contar el aprovisionamiento de IOPS. Los mismos 3,84 TB de NVMe se incluyen en el servidor dedicado Extreme InMotion Hostinga un coste menor. El almacenamiento conectado a la nube no tiene un precio que pueda competir con NVMe local.

Diferencias en el rendimiento de la red

Latencia para los usuarios finales

Tanto los servidores en la nube como los servidores dedicados tienen características de latencia determinadas principalmente por la distancia física a los usuarios finales y la calidad del enrutamiento de la red. Los proveedores de servicios en la nube tienen una ventaja de distribución global: AWS, Google y Azure operan en regiones de todos los continentes, mientras que InMotion Hosting centros de datos en Los Ángeles y Ámsterdam.

Para aplicaciones que prestan servicio a usuarios concentrados en Norteamérica y Europa Occidental, las ubicaciones de los centros de datos de InMotion cubren las principales bases de usuarios. Los Ángeles llega eficazmente a los usuarios norteamericanos; Ámsterdam presta servicio a los usuarios de Europa Occidental con baja latencia y cumple los requisitos de residencia de datos de la UE. Las aplicaciones que requieren presencia en el sudeste asiático, Australia o Sudamérica pueden necesitar una capa CDN o una implementación en la nube distribuida geográficamente.

Previsibilidad frente a rendimiento máximo

El ancho de banda de la red en la nube suele estar sujeto a límites de ráfagas a nivel de instancia y a la capacidad compartida de la NIC. Una instancia c5.2xlarge en AWS proporciona hasta 10 Gbps de ancho de banda de red etiquetado como «Hasta 10 Gbps», lo que significa acceso de ráfaga a 10 Gbps con un rendimiento real sostenido inferior y sujeto a la gestión del tráfico.

Los servidores dedicados de InMotion incluyen un puerto de 1 Gbps con la opción de actualizar a un puerto ilimitado de 10 Gbps garantizados. Los 10 Gbps garantizados son una especificación diferente de «hasta 10 Gbps de velocidad máxima». Para aplicaciones que necesitan una transferencia sostenida de gran ancho de banda (transmisión de vídeo, distribución de archivos de gran tamaño, ingesta de datos), el ancho de banda garantizado tiene un valor operativo.

Punto de referencia: latencia de consultas a bases de datos

Comparación práctica de la latencia de las consultas a las bases de datos p50 y p99 en máquinas virtuales en la nube frente a máquinas físicas para PostgreSQL de tamaño medio (conjunto de trabajo de 50 GB, combinación de consultas OLTP estándar):

Medio ambiente	Latencia p50	p99 Latencia	Robo de CPU (promedio)	Notas
AWS RDS db.r5.2xlarge	4 ms	45 ms	N/A (gestionado)	Sobrecarga de red al punto final RDS
AWS EC2 r5.2xlarge (64 GB)	3 ms	38 ms	3-12 %	Sobrecarga de almacenamiento EBS + tiempo robado
InMotion Advanced (64 GB DDR4, NVMe)	2,5 ms	12 ms	0%	NVMe local, sin robo de tiempo
InMotion Extreme (192 GB DDR5 ECC, NVMe)	1,8 ms	8 ms	0%	Conjunto completo de trabajo en el grupo de búferes

La latencia p99 es donde la diferencia es más pronunciada. El 1 % de las solicitudes con peor rendimiento en la infraestructura en la nube sufren picos de tiempo de robo y variabilidad de la red de almacenamiento. En el hardware físico, el rendimiento p99 se mantiene cercano al rendimiento medio, ya que no existe ninguna de esas fuentes de variabilidad.

Ventajas de las máquinas virtuales en la nube

Una comparación honesta reconoce las categorías en las que la infraestructura en la nube realmente supera a los servidores dedicados bare metal:

• Autoescalado: la infraestructura en la nube se escala horizontalmente en cuestión de minutos. Añadir un servidor físico requiere entre horas y días para su aprovisionamiento.
• Distribución global: entre 15 y 30 regiones en la nube frente a dos ubicaciones de centros de datos de InMotion. Las aplicaciones que requieren presencia en varios continentes se benefician de la presencia global de la nube.
• Servicios gestionados: RDS , ElastiCache, Lambda y otros servicios gestionados similares eliminan la carga operativa de los equipos que no cuentan con personal dedicado a la infraestructura.
• Cargas de trabajo intermitentes: un trabajo por lotes que se ejecuta 2 horas a la semana cuesta unos céntimos en instancias spot de la nube. Un servidor dedicado cuesta lo mismo tanto si se ejecuta 1 hora como 720 horas al mes.

Tomar la decisión

• Si tu carga de trabajo se ejecuta de forma continua y requiere un rendimiento predecible: los servidores dedicados bare metal ganan en coste y rendimiento.
• Si tu carga de trabajo varía de forma drástica e impredecible, la flexibilidad de la nube puede justificar el coste adicional.
  • Si gastas más de 300 dólares al mes en computación en la nube para una carga de trabajo estable: ejecuta la comparación de bare metal.
• Si la variabilidad de la latencia p99 está afectando a los SLA de tu aplicación: el tiempo de robo cero de Bare Metal aborda la causa raíz.