Compartilhar via

Medir o consumo de cada locatário

  • Artigo

Como provedor de soluções, é importante medir o consumo de cada locatário em sua solução multilocatário. Medindo o consumo de cada locatário, você pode garantir que o custo das mercadorias vendidas (COGS), para fornecer o serviço a cada locatário, seja lucrativo. Nesta página, fornecemos orientação para os tomadores de decisão técnicos sobre a importância de medir o consumo e as abordagens que você pode considerar para medir o consumo de um locatário, bem como as compensações envolvidas.

Há duas preocupações principais que impulsionam a necessidade de medir o consumo de cada locatário:

  • Você precisa medir o custo real para atender a cada locatário. Isso é importante para monitorar a rentabilidade da solução para cada locatário.
  • Você precisará determinar o valor a ser cobrado pelo locatário quando estiver usando preços baseados em consumo.

No entanto, poderá ser difícil medir os recursos reais usados por um locatário em uma solução multilocatário. A maioria dos serviços que podem ser usados como parte de uma solução multilocatário não diferencia ou divide automaticamente o uso, com base na definição do locatário. Por exemplo, considere um serviço que armazena dados para todos os locatários em um único banco de dados relacional. É difícil determinar exatamente quanto espaço cada locatário usa desse banco de dados relacional, seja em termos de armazenamento ou da capacidade de computação necessária para atender a consultas e solicitações.

Por outro lado, para uma solução de locatário único, você pode usar o Gerenciamento de Custos do Microsoft no portal do Azure para obter um detalhamento de custo completo para todos os recursos do Azure que são consumidos por esse locatário.

Portanto, será importante considerar como medir o consumo ao enfrentar esses desafios.

Observação

Em alguns casos, é comercialmente aceitável ter uma perda na entrega de serviço a um locatário, por exemplo, quando você entra em um novo mercado ou região. Essa é uma escolha comercial. Mesmo nessas situações, ainda é uma boa ideia medir o consumo de cada locatário, para que você possa planejar o futuro.

Métricas de consumo indicativas

Aplicativos modernos (criados para a nuvem) geralmente são compostos por muitos serviços diferentes, cada um com diferentes medidas de consumo. Por exemplo, uma conta de armazenamento mede o consumo com base na quantidade de dados armazenados, nos dados transmitidos e no número de transações. No entanto, o consumo do Serviço de Aplicativo do Azure é medido pela quantidade de recursos de computação alocados ao longo do tempo. Se você tiver uma solução que inclua uma conta de armazenamento e recursos do Serviço de Aplicativo, combinar todas essas medidas para calcular o COGS real (custo dos produtos vendidos) poderá ser uma tarefa muito difícil. Geralmente, é mais fácil usar uma única medida indicativa para representar o consumo na solução.

Por exemplo, se uma solução multilocatário compartilhar um banco de dados relacional único, os dados armazenados por um locatário talvez sejam uma boa métrica de consumo indicativa.

Observação

Mesmo que você use o volume de dados armazenados por um locatário como uma medida de consumo indicativa, pode não ser uma verdadeira representação de consumo para cada locatário. Por exemplo, se um locatário específico fizer muito mais leituras ou executar mais relatórios da solução, mas não gravar muitos dados, ele poderá usar muito mais computação do que os requisitos de armazenamento indicariam.

Ocasionalmente, é importante medir e examinar o consumo real entre seus locatários para determinar se as suposições que você está fazendo sobre as métricas indicativas estão corretas.

Métricas de transação

Uma maneira alternativa de medir o consumo é identificar uma transação chave que seja representativa do COGS para a solução. Por exemplo, em uma solução de gerenciamento de documentos, pode ser o número de documentos criados. Isso poderá ser útil se houver uma função principal ou um recurso dentro de um sistema que seja transacional e se ele puder ser facilmente medido.

Esse método geralmente é fácil e econômico de implementar, pois normalmente há apenas um único ponto em seu aplicativo que precisa registrar o número de transações que ocorrem.

Métricas por solicitação

Em soluções baseadas principalmente em API, talvez faça sentido usar uma métrica de consumo baseada no número de solicitações de API que estão sendo feitas para a solução. Isso geralmente pode ser bastante simples de implementar, mas exige que você use APIs como a interface primária para o sistema. Haverá um custo operacional maior de implementação de uma métrica por solicitação, especialmente para serviços de alto volume, devido à necessidade de registrar a utilização da solicitação (para fins de auditoria e cobrança).

Observação

As soluções voltadas para o usuário que consistem em um SPA (aplicativo de página única) ou um aplicativo móvel que usa as APIs podem não ser adequadas para a métrica por solicitação. Isso ocorre porque há pouca compreensão pelo usuário final da relação entre o uso do aplicativo e o consumo de APIs. Seu aplicativo pode ser expansivo (faz muitas solicitações de API) ou reduzido (faz poucas solicitações de API) e o usuário não notará uma diferença.

Aviso

Armazene métricas de solicitação em um armazenamento de dados confiável projetado para essa finalidade. Por exemplo, embora Azure Application Insights possa acompanhar solicitações e até mesmo rastrear IDs de locatário (usando propriedades), ele não foi projetado para armazenar cada parte da telemetria. Ele remove dados, como parte de seu comportamento de amostragem. Para fins de cobrança e medição, escolha um armazenamento de dados que fornecerá um alto nível de precisão.

Estimar o consumo

Ao medir o consumo de um locatário, poderá ser mais fácil fornecer uma estimativa do consumo para o locatário em vez de tentar calcular a quantidade exata de consumo. Por exemplo, para uma solução multilocatário que atende milhares de locatários em uma única implantação, é razoável aproximar que o custo de atender o locatário seja apenas uma porcentagem do custo dos recursos do Azure.

Você pode considerar estimar o COGS para um locatário nos seguintes casos:

  • Você não está usando preços baseados em consumo.
  • Os padrões de uso e o custo para cada locatário são semelhantes, independentemente do tamanho.
  • Cada locatário consome uma porcentagem baixa (digamos, <2%) dos recursos gerais na implantação.
  • O custo por locatário é baixo.

Você também pode optar por estimar o consumo em combinação com métricas de consumo indicativas, métricas de transação ou métricas por solicitação. Por exemplo, para um aplicativo que gerencia principalmente documentos, o percentual de armazenamento geral usado por um locatário para armazenar seus documentos fornece uma representação próxima o suficiente do COGS real. Essa pode ser uma abordagem útil quando a medição do COGS é difícil ou quando adiciona muita complexidade ao aplicativo.

Na cobrança dos seus custos

Em algumas soluções, você pode cobrar de seus clientes o COGS pelos recursos do locatário. Por exemplo, você pode usar tags de recurso do Azure para alocar recursos faturáveis do Azure aos locatários. Você pode determinar o custo para cada locatário do conjunto de recursos dedicados a eles, além de uma margem de lucro e operação.

Observação

Alguns serviços do Azure não dão suporte a tags. Para esses serviços, você precisará atribuir os custos a um locatário, com base no nome do recurso, no grupo de recursos ou na assinatura.

A Análise de Custo do Azure pode ser usada para analisar os custos de recursos do Azure para soluções de locatário único que usam marcas, grupos de recursos ou assinaturas para atribuir custos.

No entanto, isso se tornará extremamente complexo na maioria das soluções multilocatários modernas devido ao desafio de determinar com precisão o COGS exato para atender a um único locatário. Esse método só deve ser considerado para soluções muito simples que têm implantações de recursos de locatário único ou recursos de complemento personalizados específicos do locatário em uma solução maior.

Alguns serviços do Azure fornecem recursos que permitem outros métodos de atribuição de custos em um ambiente multilocatário. Por exemplo, Serviço de Kubernetes do Azure dá suporte a vários pools de nós, em que cada locatário é alocado com um pool de nós com tags de pool de nós que são usadas para atribuir custos.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Considere o modelo de implantação de atualização que você usará.