Compartir vía


Medición del consumo de cada inquilino

Como proveedor de soluciones, es importante medir el consumo de cada inquilino de la solución multiinquilino. Al medir el consumo de cada inquilino, puede asegurarse de que el coste de bienes vendidos (COGS) para la entrega del servicio a cada inquilino sea rentable. En esta página, se proporcionan instrucciones para los responsables de la toma de decisiones técnicas sobre la importancia de medir el consumo y los enfoques que puede tener en cuenta para medir el consumo de un inquilino, así como las soluciones que implica.

Hay dos problemas principales que impulsan la necesidad de medir el consumo de cada inquilino:

  • Debe medir el coste real para atender a cada inquilino. Esto es importante para supervisar la rentabilidad de la solución para cada inquilino.
  • Debe determinar la cantidad que se va a cobrar al inquilino cuando use los precios basados en el consumo.

Sin embargo, puede ser difícil medir los recursos reales que usa un inquilino en una solución multiinquilino. La mayoría de los servicios que se pueden usar como parte de una solución multiinquilino no diferencian ni desglosan automáticamente el uso, en función de la definición de inquilino que haya establecido. Por ejemplo, considere un servicio que almacena datos para todos los inquilinos en una base de datos relacional única. Es difícil determinar exactamente la cantidad de capacidad que usa cada inquilino de esa base de datos relacional, ya sea en términos de almacenamiento de datos o de los recursos de proceso necesarios para atender las consultas y solicitudes.

En cambio, para una solución de un solo inquilino, puede usar Microsoft Cost Management dentro de Azure Portal para obtener un desglose completo de los costes para todos los recursos de Azure que consume ese inquilino.

Por lo tanto, al enfrentarte a estos desafíos, es importante tener en cuenta cómo medir el consumo.

Nota:

En algunos casos, es comercialmente aceptable asumir una pérdida al entregar el servicio a un inquilino, por ejemplo, cuando se entra en un nuevo mercado o región. Es una elección comercial. Incluso en estas situaciones, sigue siendo una buena idea medir el consumo de cada inquilino, para que pueda planear el futuro.

Métricas de consumo indicativas

Las aplicaciones modernas (creadas para la nube) suelen estar compuestas por muchos servicios diferentes, cada uno con distintas medidas de consumo. Por ejemplo, una cuenta de almacenamiento mide el consumo en función de la cantidad de datos almacenados, los datos transmitidos y el número de transacciones. En cambio, App de Azure consumo del servicio se mide mediante la cantidad de recursos de proceso asignados a lo largo del tiempo. Si tiene una solución que incluye una cuenta de almacenamiento y recursos de App Service, combinar todas estas medidas para calcular los COGS (coste de bienes vendidos) reales puede ser una tarea muy difícil.

A menudo, es más fácil usar una única medida indicativa para representar el consumo en la solución. Por ejemplo, si una solución multiinquilino comparte una única base de datos relacional, los datos almacenados por un inquilino podrían ser una buena métrica de consumo indicativa.

Incluso si usa el volumen de datos almacenados por un inquilino como medida indicativa de consumo, puede que no sea una representación verdadera del consumo para cada inquilino. Si un inquilino determinado realiza muchas más lecturas o ejecuta más informes de la solución, pero no escribe muchos datos, ese inquilino podría usar mucho más proceso que los requisitos de almacenamiento.

Sugerencia

En ocasiones, debe medir y revisar el consumo real en los inquilinos para crear un modelo de línea base. Este modelo le ayuda a determinar si las suposiciones que está realizando sobre las métricas indicativas son correctas.

Métricas de transacciones

Una manera alternativa de medir el consumo es identificar una transacción clave que sea representativa del COGS para la solución. Por ejemplo, en una solución de administración de documentos, podría ser el número de documentos creados. Esto puede ser útil si hay una función o característica principal dentro de un sistema que es transaccional y si se puede medir fácilmente.

Este método suele ser fácil y económico de implementar, ya que normalmente solo hay un único punto en la aplicación que necesita registrar el número de transacciones que se producen.

Métricas por solicitud

En las soluciones basadas principalmente en API, podría tener sentido usar una métrica de consumo basada en el número de solicitudes de API que se realizan en la solución. Con frecuencia, puede ser bastante sencillo de implementar, pero requiere que use las API como la interfaz principal para el sistema. Habrá un mayor coste operativo al implementar una métrica por solicitud, especialmente para los servicios de gran volumen, debido a la necesidad de registrar el uso de solicitudes (con fines de auditoría y facturación).

Las soluciones orientadas al usuario que constan de una aplicación de página única (SPA) o una aplicación móvil que use las API pueden no ser una buena opción para aplicar la métrica por solicitud. Esto se debe a que el usuario final no entiende bien la relación entre el uso de la aplicación y el consumo de las API. La aplicación puede ser de chats (realiza muchas solicitudes de API) o de segmentos (realiza pocas solicitudes de API) y el usuario no observaría ninguna diferencia. Sin embargo, si solo necesita una idea aproximada del consumo de cada inquilino, podría ser una opción razonable.

Advertencia

Asegúrese de almacenar las métricas de solicitud en un almacén de datos confiable diseñado para este fin. Por ejemplo, aunque Azure Application Insights puede realizar un seguimiento de las solicitudes e incluso puede realizar un seguimiento de los id. de inquilino (mediante propiedades), Application Insights no está diseñado para almacenar todos los datos de telemetría. Quita los datos, como parte de su comportamiento de muestreo. Para la facturación y medición, elija un almacén de datos que le dará un alto nivel de precisión.

Estimación del consumo

Al medir el consumo de un inquilino, puede ser más fácil proporcionar una estimación del consumo del inquilino, en lugar de intentar calcular la cantidad exacta de consumo. Por ejemplo, para una solución multiinquilino que atiende a muchos miles de inquilinos en una sola implementación, es razonable la aproximación de que el coste de atender al inquilino es solo un porcentaje del coste de los recursos de Azure.

Puede considerar la posibilidad de calcular el COGS de un inquilino, en los casos siguientes:

  • No usa los precios basados en el consumo.
  • Los patrones de uso y el coste de cada inquilino son similares, independientemente del tamaño.
  • Cada inquilino consume un porcentaje bajo (por ejemplo, menos del 2 %) de los recursos generales de la implementación.
  • El coste por inquilino es bajo.

También puede optar por estimar el consumo en combinación con métricas indicativas de consumo, métricas de transacción o métricas por solicitud. Por ejemplo, en el caso de una aplicación que administra principalmente documentos, el porcentaje de almacenamiento total usado por un inquilino para almacenar sus documentos proporciona una representación lo suficientemente ajustada del COGS real. Puede ser un enfoque útil, cuando la medición del COGS sea difícil o cuando agregaría demasiada complejidad a la aplicación.

Cobro de los costes

En algunas soluciones, puedes simplemente cobrar a los clientes el COGS por los recursos de su inquilino. Por ejemplo, puede usar etiquetas de recursos de Azure para asignar recursos facturables de Azure a los inquilinos. A continuación, puede determinar el coste para cada inquilino del conjunto de recursos dedicados a ellos, además de un margen para el beneficio y la operación.

Nota

Algunos servicios de Azure no admiten etiquetas. Para estos servicios, debe atribuir los costos a un inquilino en función de otras características, como el nombre del recurso, el grupo de recursos o la suscripción.

Se puede usar Azure Cost Analysis para analizar los costes de los recursos de Azure para soluciones de un solo inquilino que usan etiquetas, grupos de recursos o suscripciones para atribuir costes.

Sin embargo, se vuelve extremadamente complejo en la mayoría de las soluciones multiinquilino modernas, debido al desafío de determinar con precisión el COGS exacto de atender a un único inquilino. Este método solo debe tenerse en cuenta para soluciones muy sencillas, soluciones que tienen implementaciones de recursos de un solo inquilino o características de complemento personalizadas específicas del inquilino dentro de una solución mayor.

Algunos servicios de Azure proporcionan características que permiten otros métodos de atribución de costes en un entorno multiinquilino. Por ejemplo, Azure Kubernetes Service admite varios grupos de nodos, donde a cada inquilino se le asigna un grupo de nodos con etiquetas de grupo de nodos, que se usan para atribuir costes.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Ten en cuenta el modelo de implementación de actualizaciones que usarás.