Abordagens arquitetônicas para gerenciamento e alocação de custos em uma solução multilocatária

As soluções multilocatárias geralmente exigem consideração especial quando você mede e aloca custos e quando otimiza custos. Nesta página, descrevemos algumas orientações importantes para os arquitetos de soluções considerarem sobre a medição, alocação e otimização de custos para um aplicativo multilocatário.

Principais considerações e requisitos

Considere os requisitos que você tem para medir o consumo de sua solução. Isso é discutido com mais detalhes em Medir o consumo de cada inquilino.

Finalidade da medição

É importante decidir qual é o seu objetivo. Seguem-se exemplos de objetivos:

• Calcule um custo aproximado dos bens vendidos para cada inquilino. Por exemplo, se você implantar um número significativo de recursos compartilhados, talvez só esteja interessado em uma aproximação aproximada do custo incorrido para cada locatário.
• Calcule o custo exato incorrido por cada inquilino. Por exemplo, se cobrar aos seus inquilinos a quantidade exata de consumo em que incorrem, precisa de ter informações precisas sobre quanto custam os recursos de cada inquilino.
• Identifique inquilinos atípicos que custam significativamente mais do que outros. Por exemplo, se você fornecer um modelo de preço de taxa fixa, talvez seja necessário determinar se algum locatário está consumindo uma quantidade desproporcional de sua capacidade provisionada, para que possa aplicar políticas de uso justo. Em muitas situações, este caso de uso não requer medição precisa de custos.
• Reduza o custo geral do Azure para a sua solução. Por exemplo, você pode querer examinar o custo de cada componente e, em seguida, determinar se você provisionou demais para a carga de trabalho.

Ao entender o objetivo de medir o consumo por um inquilino, você pode determinar se as alocações de custos precisam ser aproximadas ou altamente precisas, o que afeta as ferramentas específicas que você pode usar e as práticas que você pode seguir.

Componentes partilhados

Talvez seja possível reduzir o custo de uma solução multilocatária movendo locatários para uma infraestrutura compartilhada. No entanto, você precisa considerar cuidadosamente o impacto do compartilhamento de recursos, como se seus locatários começarão a experimentar o problema do vizinho barulhento.

Você também precisa considerar como medir e alocar os custos dos componentes compartilhados. Por exemplo, você pode dividir uniformemente o custo entre cada um dos locatários que usam o componente compartilhado. Ou, você pode medir o uso de cada locatário para obter uma medição mais precisa do consumo de componentes compartilhados.

Abordagens e padrões a considerar

Alocar custos usando tags de recursos

O Azure permite-lhe aplicar etiquetas aos seus recursos. Uma tag é um par chave-valor. Você usa tags para adicionar metadados personalizados. As tags são úteis para muitas operações de gerenciamento e também são úteis para analisar o custo do seu consumo do Azure. Depois de aplicar tags, você pode determinar os custos associados a cada tag.

A maneira como você usa tags em uma solução multilocatária provavelmente será diferente, dependendo da sua arquitetura.

Em algumas soluções, você pode implantar recursos dedicados para cada locatário, como se implantar Carimbos de Implantação dedicados para cada locatário. Nessas situações, fica claro que qualquer consumo do Azure para esses recursos deve ser alocado para esse locatário e, portanto, você pode marcar seus recursos do Azure com a ID do locatário.

Em outras situações, você pode ter conjuntos de recursos compartilhados. Por exemplo, ao aplicar o padrão de compartilhamento, você pode implantar vários bancos de dados e distribuir seus locatários entre eles. Considere marcar os recursos com um identificador para o grupo de locatários. Talvez você não consiga alocar facilmente os custos a um único locatário, mas pode, pelo menos, restringir o custo a um conjunto de locatários, quando usar essa abordagem. Você também pode usar as informações de consumo para ajudá-lo a reequilibrar os inquilinos entre os fragmentos, se notar que um fragmento específico está acumulando custos mais altos do que os outros.

Considere um exemplo de solução multilocatária criada usando o padrão Deployment Stamps e um modelo de locação particionado verticalmente. Cada carimbo de implantação inclui um servidor Web compartilhado e bancos de dados fragmentados. As marcas podem ser aplicadas a cada um dos componentes do Azure, conforme mostrado no diagrama a seguir.

A estratégia de marcação aqui utilizada é a seguinte:

• Cada recurso tem uma stamp-id tag.
• Cada banco de dados fragmentado tem uma shard-id tag.
• Cada recurso dedicado a um locatário específico tem uma tenant-id tag.

Com essa estratégia de marcação, é fácil filtrar as informações de custo para um único selo. Também é fácil encontrar o custo dos recursos específicos do locatário, como o custo total do banco de dados para o locatário C. Os componentes compartilhados não têm uma tenant-id tag, mas o custo dos componentes compartilhados para um carimbo pode ser dividido entre os locatários que são designados para usar esse carimbo ou fragmento.

Instrumente a sua aplicação

Em situações em que você não tem uma relação direta entre um recurso do Azure e um locatário, considere instrumentar seu aplicativo para coletar telemetria.

Sua camada de aplicativo já pode coletar logs e métricas que são úteis para responder a perguntas sobre medição, por exemplo:

• Aproximadamente quantas solicitações de API são feitas por locatário?
• Que horas do dia os inquilinos específicos estão mais ocupados?
• Como os padrões de uso do locatário A se comparam aos padrões de uso do locatário B?

No Azure, essas métricas geralmente são capturadas pelo Application Insights. Usando inicializadores de telemetria, você pode enriquecer a telemetria capturada pelo Application Insights, para incluir um identificador de locatário ou outros dados personalizados.

No entanto, o Application Insights e outras soluções de registro e monitoramento não são apropriados para medição precisa de custos ou para fins de medição. O Application Insights foi projetado para dados de amostra, especialmente quando seu aplicativo tem um grande volume de solicitações. A amostragem foi projetada para reduzir o custo de monitoramento de sua solução, porque a captura de cada peça de telemetria muitas vezes pode se tornar cara.

Se você precisar rastrear detalhes precisos sobre consumo ou uso para fins de faturamento, crie um pipeline personalizado para registrar os dados necessários. Em seguida, deve agregar os dados, com base nos seus requisitos. Os serviços do Azure que podem ser úteis para essa finalidade incluem Hubs de Eventos, para capturar grandes volumes de telemetria, e Stream Analytics, para processá-los em tempo real.

Usar as Reservas do Azure e o plano de economia do Azure para reduzir custos

Reservas do Azure: as Reservas do Azure permitem que você reduza seus custos do Azure ao se comprometer previamente com um determinado nível de gastos. As reservas aplicam-se a vários tipos de recursos do Azure.

As reservas podem ser usadas de forma eficaz em uma solução multilocatário. Observe as seguintes considerações:

• Ao implantar uma solução multilocatária que inclua recursos compartilhados, considere o nível de consumo de linha de base necessário para a carga de trabalho. Você pode considerar uma reserva para esse consumo de linha de base e, em seguida, pagaria taxas padrão por consumo mais alto durante picos imprevisíveis.
• Ao implantar recursos para cada locatário, considere se você pode se comprometer previamente com o consumo de recursos para um locatário específico ou em todo o seu portfólio de locatários.

As Reservas do Azure permitem que você defina o escopo de suas reservas para aplicar a um grupo de recursos, uma assinatura ou um conjunto de assinaturas. Isso significa que você pode aproveitar as reservas, mesmo que reduza sua carga de trabalho em várias assinaturas.

Os escopos de reserva também podem ser úteis quando você tem locatários com cargas de trabalho imprevisíveis. Por exemplo, considere uma solução na qual o locatário A precisa apenas de uma instância de um recurso específico, mas os locatários B e C precisam de duas. Em seguida, o locatário B fica menos ocupado, então você reduz a contagem de instâncias e o locatário A fica mais ocupado, aumentando a contagem de instâncias. As suas reservas são aplicadas aos inquilinos que delas necessitam.

Plano de poupança do Azure para computação: o plano de poupança do Azure para computação é um plano flexível de poupança de custos que gera poupanças significativas em relação aos preços pré-pagos. Você concorda com um contrato de um ou três anos e recebe descontos em serviços de computação qualificados. Esses serviços incluem máquinas virtuais, hosts dedicados, instâncias de contêiner, funções premium do Azure e serviços de aplicativo do Azure. As economias se aplicam a esses serviços de computação, independentemente da região, tamanho da instância ou sistema operacional. Para obter mais informações, consulte Visão geral do plano de economia do Azure e Documentação do plano de economia do Azure.

Combinar reservas e plano de poupança: para otimizar ainda mais os custos e a flexibilidade, pode combinar um plano de poupança do Azure com as Reservas do Azure.

Antipadrões a evitar

• Não rastreando custos. É importante ter pelo menos uma ideia aproximada dos custos que você está incorrendo e como cada locatário afeta o custo de entrega de sua solução. Caso contrário, se os seus custos mudarem ao longo do tempo, não tem uma linha de base com a qual comparar. Você também pode não ser capaz de prever como um crescimento de inquilinos afetará seus custos e lucratividade.
• Fazer suposições ou adivinhar. Certifique-se de que sua medição de custos seja baseada em informações reais. Você pode não precisar de um alto grau de precisão, mas mesmo suas estimativas devem ser informadas por medições reais.
• Precisão desnecessária. Talvez não seja necessário ter uma contabilidade detalhada de todos os custos incorridos para cada locatário. Construir processos de medição e otimização de custos desnecessariamente precisos pode ser contraproducente, porque adiciona complexidade de engenharia e cria processos frágeis.
• Medição em tempo real. A maioria das soluções não precisa de medições de custos atualizadas. Como os dados de medição e consumo podem ser complexos de processar, você deve registrar os dados necessários e, em seguida, agregar e processar os dados de forma assíncrona posteriormente.
• Utilização de ferramentas de monitorização para faturação. Conforme descrito em Instrumentar seu aplicativo, certifique-se de usar ferramentas projetadas para monitoramento e medição de custos. As soluções de monitoramento de aplicativos geralmente não são boas candidatas para esse tipo de dados, especialmente quando você precisa de alta precisão.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• John Downs - Brasil | Engenheiro de Software Principal

Outros contribuidores:

• Sherri Babilônia | Engenheiro de Clientes Sênior, FastTrack for Azure
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

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

Próximos passos

• Meça o consumo de cada inquilino