Antipatrón Vecino ruidoso

  • Artículo
  • 7 minutos para leer

Los sistemas multiinquilino comparten recursos entre inquilinos, lo que significa que la actividad de un inquilino puede afectar negativo al uso del sistema por parte de otro inquilino.

Descripción del problema

Al compilar un servicio para que lo compartan varios clientes o inquilinos, se puede compilar para que sea multiinquilino. Una de las ventajas de los sistemas con múltiples inquilinos es que los recursos se pueden agrupar y compartir entre los inquilinos, lo que suele reducir los costos y mejorar la eficacia. Sin embargo, si un solo inquilino usa una cantidad desproporcionada de los recursos disponibles en el sistema, el rendimiento general del sistema puede verse afectado. El problema del vecino ruidoso se produce cuando el rendimiento de un inquilino se degrada debido a las actividades de otro.

Considere un sistema multiinquilino de ejemplo con dos inquilinos. Los patrones de uso del inquilino A y los del inquilino B coinciden, lo que significa que, en horas punta, el uso total de recursos supera la capacidad del sistema:

La ilustración que muestra el uso de recursos de dos inquilinos. El inquilino A consume el conjunto completo de recursos del sistema, lo que significa que al inquilino B le aparecen errores.

Es probable que la solicitud del inquilino que haya llegado primero tenga prioridad y que el otro inquilino sufra el problema del vecino ruidoso. También puede darse el caso de que el rendimiento de ambos inquilinos se vea negativamente afectado.

El problema de vecino ruidoso se llega a producir incluso cuando cada inquilino individual consume cantidades relativamente pequeñas de la capacidad del sistema, pero el uso de recursos colectivos de muchos inquilinos da como resultado un pico en el uso general:

Ilustración con tres inquilinos, cada uno los cuales consume menos que el rendimiento máximo de la solución. En total, los tres inquilinos consumen todos los recursos del sistema.

Esto puede suceder si hay varios inquilinos que tienen patrones de uso similares o si no se ha aprovisionado suficiente capacidad para la carga colectiva en el sistema.

Procedimiento para corregir el problema

Los problemas de vecinos ruidosos son un riesgo inherente en los sistemas con varios inquilinos y no es posible eliminar completamente la posibilidad de verse afectado por un vecino ruidoso. Sin embargo, tanto los clientes como los proveedores de servicios pueden dar ciertos pasos para reducir la probabilidad de que aparezcan problemas de vecinos ruidosos o para mitigar sus efectos cuando se observan.

Acciones que pueden realizar los clientes

Acciones que pueden realizar los proveedores de servicios

  • Supervisar el uso de recursos del sistema, tanto el general como el de cada inquilino. Configurar alertas para detectar picos en el uso de recursos y, si es posible, configure la automatización para mitigar automáticamente los problemas conocidos mediante el escalado vertical u horizontal.
  • Aplicar la gobernanza de los recursos, con el fin de evitar que un solo inquilino acapare el sistema y reduzca la capacidad disponible para el resto. Para ello se puede aplicar una cuota, a través del patrón de limitación o del patrón de limitación de velocidad.
  • Considerar la posibilidad de aprovisionar más infraestructura. Esto podría implicar la realización de un escalado vertical mediante la actualización de algunos de los componentes de la solución, o bien la realización de un escalado horizontal mediante el aprovisionamiento de particiones adicionales, si se sigue el patrón de particionamiento, o stamps, si se sigue el patrón de stamps de implementación.
  • Considerar la posibilidad de permitir que los inquilinos compren capacidad reservada o aprovisionada previamente. Esto proporciona a los inquilinos mayor certeza de que la solución controla adecuadamente su carga de trabajo.
  • Considerar la posibilidad de usar ciertos métodos para suavizar el uso de recursos:
    • Si hospeda varias instancias de una solución, considere la posibilidad de volver a equilibrar los inquilinos entre las distintas instancias o stamps. Por ejemplo, considere la posibilidad de colocar inquilinos con patrones de uso predecibles y similares, en varios stamps, ya que ello puede reducir los picos de uso.
    • Considerar la posibilidad de tener, o no, procesos en segundo plano o cargas de trabajo que consumen muchos recursos que no tengan límite de tiempo. Ejecute estos elementos de forma asincrónica en momentos de menos actividad, con el fin de conservar la capacidad máxima de los recursos para cargas de trabajo con un tiempo limitado.
  • Considerar la posibilidad, o no, de que los servicios proporcionen controles para mitigar los problemas de vecinos ruidosos. Por ejemplo, si usa Kubernetes, considere la posibilidad de usar límites de pod y, si usa Service Fabric, considere la posibilidad de usar las funcionalidades de gobernanza integradas.
  • Si procede, considere la posibilidad de restringir las operaciones que pueden realizar los inquilinos. Por ejemplo, impedir que los inquilinos ejecuten operaciones que ejecutarán consultas en bases de datos de gran tamaño. Esto reduce el riesgo de que los inquilinos realicen acciones que podrían afectar negativamente a otros inquilinos.
  • Si procede, considere la posibilidad de proporcionar un sistema de calidad de servicio (QoS). Cuando se aplica QoS, se da más prioridad a algunos procesos o cargas de trabajo que a otros. Al factorizar QoS en el diseño y la arquitectura, puede asegurarse de que las operaciones de prioridad alta tienen prioridad cuando hay presión sobre los recursos.

Consideraciones

  • En la mayoría de los casos, los inquilinos individuales no pretenden causar problemas de vecinos ruidosos. Es posible que ni siquiera sean conscientes de que sus cargas de trabajo provocan dichos problemas a otros usuarios.
  • Sin embargo, también es posible que los inquilinos usen las vulnerabilidades de los componentes compartidos para atacar a un servicio, ya sea de forma individual o mediante la ejecución de un ataque de denegación de servicio distribuido (DDoS).
  • Independientemente de la causa, es importante tratar estos problemas como problemas de gobernanza de recursos y aplicar cuotas de uso, limitaciones y controles de gobernanza para mitigar el problema.

    Nota

    Asegúrese de que informa a los clientes sobre cualquier limitación que aplique o sobre las cuotas de uso del servicio. Es importante que controlen de forma confiable las solicitudes con error y que no se sorprendan por las limitaciones o cuotas que se puedan aplicar.

Procedimiento para detectar el problema

Desde la perspectiva del cliente, el problema de vecino ruidoso normalmente se manifiesta en forma de solicitudes de servidor con errores o de solicitudes que tardan mucho tiempo en completarse. En concreto, si la misma solicitud se realiza correctamente en otras ocasiones y parece que se produce un error de forma aleatoria, es posible que haya un problema de vecino ruidoso. Las aplicaciones cliente deben registrar los datos de telemetría para realizar un seguimiento tanto de la tasa de éxito como del rendimiento de las solicitudes a los servicios, y las aplicaciones también deben registrar las métricas de rendimiento de línea base para poder realizar comparaciones.

Desde la perspectiva de un servicio, el problema de vecino ruidoso puede aparecer de varias maneras:

  • Picos en el uso de los recursos. Es importante tener un conocimiento claro del uso normal de los recursos de la línea base y configurar la supervisión y las alertas para detectar picos en el uso de recursos. Asegúrese de tener en cuenta todos los recursos que puedan afectar al rendimiento o la disponibilidad del servicio. Entre ellos se incluyen métricas como el uso de la memoria y de la CPU servidor, E/S de disco, uso de base de datos, tráfico de red y métricas expuestas por servicios administrados, como el número de solicitudes y las métricas de rendimiento sintéticas y abstractas, como las unidades de solicitud de Azure Cosmos DB.
  • Errores al realizar una operación para un inquilino, incluso cuando el inquilino no use una gran parte de los recursos del sistema. Este patrón puede indicar que el inquilino sufre el problema de vecino ruidoso. Considere la posibilidad de realizar un seguimiento del consumo de recursos por parte del inquilino. Por ejemplo, si usa Azure Cosmos DB, considere la posibilidad de registrar las unidades de solicitud que se usan en cada solicitud y agregue el identificador del inquilino como dimensión a la telemetría, con el fin de que pueda agregar el consumo de unidades de solicitud a cada inquilino.