Abordagens de arquitetura para gerenciamento de custos e alocação em uma solução de multilocatário

As soluções multilocatários geralmente exigem uma consideração especial ao medir e alocar custos e ao otimizar os custos. Nesta página, descrevemos algumas diretrizes importantes para que os arquitetos de solução considerem a medida, a alocação e a otimização dos custos de um aplicativo multilocatário.

Considerações e requisitos

Considere os requisitos que você tem para medir o consumo de sua solução. Isso é discutido em mais detalhes sobre como medir o consumo de cada locatário.

Finalidade da medição

É importante decidir qual é sua meta. Estes são exemplos de metas:

• Calcular um custo aproximado de mercadorias vendidas para cada locatário. Por exemplo, se você implantar um número significativo de recursos compartilhados, talvez esteja interessado apenas em uma aproximação grosseira do custo incorrido para cada locatário.
• Calcular o custo exato incorrido por cada locatário. Por exemplo, se você cobrar seus locatários pela quantidade exata de consumo que eles incorrem, precisará ter informações precisas sobre o custo dos recursos de cada locatário.
• Identificar locatários de exceção que custam significativamente mais do que outros. Por exemplo, se você fornecer um modelo de preços de taxa fixa, talvez seja necessário determinar se algum locatário está consumindo uma quantidade desproporcional de sua capacidade provisionada, para que você possa aplicar políticas de uso justo. Em muitas situações, esse caso de uso não exige uma medição precisa dos custos.
• Reduza o custo geral do Azure para sua solução. Por exemplo, talvez você queira examinar o custo de cada componente e, em seguida, determinar se você tem excesso de provisionamento para a carga de trabalho.

Ao compreender o objetivo de medir o consumo por um locatário, é possível determinar se as alocações de custo 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 compartilhados

Você poderá reduzir o custo de uma solução multilocatário movendo os locatários para a infraestrutura compartilhada. No entanto, você precisa considerar cuidadosamente o impacto do compartilhamento de recursos, como se seus locatários começarão a enfrentar o problema de vizinho barulhento.

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

Abordagens e padrões a serem considerados

Alocar custos usando marcas de recurso

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

A maneira como você usa marcas em uma solução multilocatário provavelmente será diferente, dependendo de sua arquitetura.

Em algumas soluções, você pode implantar recursos dedicados para cada locatário, como se você implantar selos 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 os 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 fragmentação, você pode implantar vários bancos de dados e espalhar seus locatários entre eles. Considere marcar os recursos com um identificador para o grupo de locatários. Talvez você não consiga alocar custos com facilidade para um único locatário, mas pode, pelo menos, restringir o custo a um conjunto de locatários ao usar essa abordagem. Você também pode usar as informações de consumo para ajudá-lo a reequilibrar locatários nos fragmentos, se observar que um fragmento específico está acumulando custos mais altos do que os outros.

Considere um exemplo de solução multilocatário criada usando o padrão Selos de Implantação e um modelo de locação particionado verticalmente. Cada selo 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 empregada aqui é a seguinte:

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

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 marca tenant-id, mas o custo dos componentes compartilhados de um selo pode ser dividido entre os locatários que são atribuídos para usar esse selo ou fragmento.

Instrumentar seu aplicativo

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 perguntas sobre medição, por exemplo:

• Aproximadamente quantas solicitações de API são feitas por locatário?
• Em quais períodos do dia os locatários específicos estão mais ocupados?
• Como os padrões de uso de locatário A são comparados aos padrões de uso do locatário B?

No Azure, essas métricas são geralmente capturadas por Application insights. Usando os inicializadores de telemetria, é possível enriquecer a telemetria capturada por Application Insights, para incluir um identificador de locatário ou outros dados personalizados.

No entanto, o Application Insights e outras soluções de registro em log e monitoramento não são apropriadas para uma medição de custo preciso ou para fins de medição. O Application Insights é projetado para dados de exemplo, especialmente quando seu aplicativo tem um alto volume de solicitações. A amostragem foi projetada para reduzir o custo de monitoramento de sua solução, pois capturar cada parte da telemetria pode se tornar caro.

Se você precisar controlar detalhes precisos sobre consumo ou uso para fins de cobrança, deverá criar um pipeline personalizado para registrar os dados necessários. Em seguida, você deve agregar os dados com base em 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.

Como usar reservas do Azure e plano de economia do Azure para reduzir custos

Reservas do Azure: as Azure Reservations permitem reduzir os custos do Azure confirmando previamente um determinado nível de gasto. As reservas se aplicam a vários tipos de recursos do Azure.

As reservas podem ser usadas com eficiência em uma solução multilocatário. Observe também as seguintes considerações:

• Ao implantar uma solução multilocatário que inclui recursos compartilhados, considere o nível de linha de base de consumo necessário para a carga de trabalho. É possível considerar uma reserva para esse consumo de linha de base e, em seguida, pagar taxas padrão para um consumo maior durante picos imprevisíveis.
• Ao implantar recursos para cada locatário, considere se é possível confirmar previamente o consumo de recursos para um locatário específico ou em 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 é possível aproveitar as reservas, mesmo se você fragmentar 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 só precisa de uma instância de um recurso específico, mas os locatários B e C precisam de dois. Em seguida, o locatário B se torna menos ocupado, portanto, você reduz a contagem de instâncias e o locatário A obtém mais ocupado, portanto, você aumenta a contagem de instâncias. Suas reservas são aplicadas aos locatários que precisam delas.

Plano de economia do Azure para computação: o plano de economia do Azure para computação é um plano flexível de economia de custos que gera uma economia significativa em relação aos preços de pagamento conforme o uso. 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. A economia se aplica a esses serviços de computação, independentemente da região, do tamanho da instância ou do sistema operacional. Para obter mais informações, consulte a Visão geral do plano de economia do Azure e a Documentação do plano de economia do Azure.

Combinar reservas e plano de economia: para otimizar ainda mais o custo e a flexibilidade, você pode combinar um plano de economia do Azure com reservas do Azure.

Antipadrões a serem evitados

• Sem controle de custos. É importante ter pelo menos uma ideia aproximada dos custos que você está incorrendo e como cada locatário afeta o custo da entrega da sua solução. Caso contrário, se os custos mudarem ao longo do tempo, você não terá nenhuma linha de base para comparação. Você também pode não conseguir prever como um crescimento de locatários afetará seus custos e rentabilidade.
• Fazendo suposições ou adivinhação. Certifique-se de que sua medição de custo seja baseada em informações reais. Talvez você não precise de um alto grau de precisão, mas até mesmo suas estimativas devem ser informadas por medidas reais.
• Precisão desnecessária. Talvez você não precise ter uma contabilidade detalhada de cada custo incorrido para cada locatário. A criação de medição de custo e processos de otimização desnecessariamente precisos pode ser uma contraproducente, o que 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 imediatas. Como os dados de medição e consumo podem ser complexos para serem processados, registre os dados necessários e, em seguida, agregue e processe os dados de forma assíncrona posteriormente.
• Usando ferramentas de monitoramento para cobrança. 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 normalmente não são boas candidatas para esse tipo de dados, especialmente quando você precisa de alta precisão.

Colaboradores

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

Autor principal:

• John Downs | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

Outros colaboradores:

• Sherri Babylon | Engenheiro de cliente sênior, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

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

Próximas etapas

• Medir o consumo de cada locatário