Capturando e visualizando métricas em uma aplicação multi-tenant SaaS na AWS

Por Anubhav Sharma, arquiteto sênior de soluções de parceiros — AWS SaaS Factory  e Tod Golding, principal arquiteto de soluções de parceiros — AWS SaaS Factory, traduzido ao Português por Cesar Augusto Kuehl, arquiteto de soluções na AWS Brasil.

Os padrões de atividade e consumo dos clientes (tenants) em um ambiente de software como serviço (SaaS) geralmente são difíceis de avaliar em um ambiente multi-tenant.

O número de tenants em seu sistema, a natureza variável de suas cargas de trabalho e o fato de que parte ou toda a infraestrutura de tenants pode ser compartilhada tornam especialmente difícil determinar como os tenants estão usando sua aplicação SaaS.

Como provedor de SaaS, é essencial ter uma visão clara de como os tenants estão consumindo seu sistema. Ser capaz de modelar o perfil funcional e operacional dos tenants e dos tiers (planos) de tenants é fundamental para a evolução das estratégias comerciais e técnicas de uma organização de SaaS.

Embora o valor da captura de métricas seja fácil de entender, instrumentar e divulgar esses dados exigem que as equipes invistam na criação da infraestrutura e dos mecanismos que possam permitir a captura e análise dessas métricas.

Neste post, veremos o papel que as métricas desempenham em uma aplicação baseada em SaaS e nos aprofundaremos em uma solução que fornece toda a infraestrutura que suportará a ingestão, agregação e análise de métricas de SaaS.

Também exploraremos estratégias para instrumentar sua aplicação SaaS para publicar métricas. O objetivo aqui é destacar o valor e a importância das métricas. Isso lhe dará uma perspectiva melhor de como essa solução funciona em seu ambiente e fornecerá uma vantagem inicial na implementação de métricas de SaaS na Amazon Web Services (AWS).

Por que as métricas são importantes

As métricas desempenham um papel vital no sucesso de um negócio de SaaS. Eles capacitam as equipes técnicas e comerciais a reunir informações valiosas sobre como os tenants estão usando e colocando a carga no sistema.

Esses dados fornecem às equipes comerciais, operacionais e arquiteturais uma visão das métricas que desempenham um papel vital na definição da direção técnica e estratégica de sua oferta de SaaS.

Do ponto de vista da equipe de negócios, as métricas podem ajudar a determinar quais recursos estão sendo usados pelos tenants ou pelos tiers de tenants. Eles também fornecem uma visão rápida sobre o impacto e a adoção de novos recursos do produto. Os gerentes de produto podem usar essas ideias para influenciar a estratégia geral do produto e as prioridades de negócios.

As métricas também podem ter uma influência significativa na arquitetura de um ambiente SaaS. Esses dados permitem que os arquitetos de SaaS criem uma visão mais rica de como os tenants estão impondo carga ao sistema e como o sistema está respondendo à constante evolução das cargas de trabalho de vários tenants.

As equipes de operações de SaaS podem usar esses dados para avaliar a integridade geral do sistema a qualquer momento e identificar gargalos que podem ser criados por tenants individuais ou tiers de tenants.

Construindo uma arquitetura de métricas

Para ajudar a ilustrar como você pode implementar métricas em seu próprio ambiente, criamos um exemplo solução, disponível no GitHub, que captura, armazena e exibe métricas de SaaS.

Esse diagrama fornece uma visão de alto nível da arquitetura dessa solução.

Figura 1 – Arquitetura de métricas de alto nível.

O fluxo dessa solução é bem simples. À esquerda do diagrama, você verá que os tenants estão consumindo uma aplicação SaaS. À medida que consomem diferentes funcionalidades e recursos da sua aplicação, eles acionarão a publicação de eventos de métricas.

A seguir, você verá que usamos serviços comuns da AWS para ingerir e agregar esses eventos de métricas. O Amazon Kinesis Data Firehose está na frente desse processo de ingestão, fornecendo uma forma escalável e serverless (sem servidor) de ingerir eventos de métricas.

Sua aplicação pode publicar esses eventos diretamente no Kinesis Data Firehose ou pode simplesmente usar o gerenciador de métricas que criamos como parte dessa solução para simplificar esse esforço. Usamos Java para implementar esse gerenciador de métricas de amostra, mas você pode optar por criar sua própria biblioteca que se alinhe melhor à sua linguagem/stack.

Depois que os dados são ingeridos no Kinesis Data Firehose, eles são transmitidos para o Amazon Redshift. O Data Firehose consegue isso por meio de sua integração direta com o Amazon Redshift, mas primeiro transmite os dados para um bucket do Amazon Simple Storage Service (Amazon S3).

Depois que os dados chegam ao S3, o Data Firehose emite um comando COPY do Amazon Redshift para carregar dados do seu bucket do S3 em uma tabela de métricas dentro do Amazon Redshift. Nesse modelo, o Amazon Redshift se torna o repositório de dados para todas as métricas, suportando uma variedade de ferramentas de business intelligence (BI) que podem ser usadas para analisar as tendências de suas aplicações SaaS.

A última peça do quebra-cabeça é o Amazon QuickSight, que se baseia nos dados de métricas do Amazon Redshift, permitindo que você crie visualizações personalizadas das tendências e atividades dos tenants. Presumivelmente, cada setor em sua empresa poderia usar o QuickSight para criar painéis que atendam às suas necessidades específicas.

Instrumentando sua aplicação

Depois de instalar a infraestrutura de métricas, você precisa analisar como instrumentará sua aplicação SaaS para capturar e publicar métricas.

Para obter as métricas detalhadas necessárias para uma empresa de SaaS, você precisará começar identificando os fluxos de trabalho e os recursos em sua aplicação que representam oportunidades de capturar métricas. Como parte desse exercício, você precisará pensar em quais tipos de métricas (latência de pesquisa, contagem de resultados, uso de dados, duração da consulta) se encaixam melhor no cenário que você está instrumentando.

Vamos começar examinando um exemplo de uma aplicação multi-tenant que usaremos para capturar métricas de tenants. O diagrama na Figura 2 fornece uma visão de uma aplicação que usa o Amazon DynamoDB para gerenciar seus dados. O serviço depende de uma camada de acesso a dados (DAL) para gerenciar o acesso a esse banco de dados.

Você notará que este exemplo adiciona instrumentação de métricas em diferentes camadas dentro da aplicação. A interface do usuário (UI) publica uma métrica para indicar que a página Atualizar Produto foi usada. Em seguida, o serviço de back-end captura o tempo necessário para atualizar um produto dentro da tabela do DynamoDB.

Para esse fluxo, pode haver várias partes do nossa aplicação que precisam ser instrumentadas.

Isso lhe dá uma ideia de como isso pode funcionar conceitualmente. No entanto, vamos ver o que significa introduzir essas chamadas de instrumentação de métrica no código de um de nossos microsserviços. O objetivo é tornar essa instrumentação o mais leve e não invasiva possível.

Para conseguir isso, criamos um gerenciador de métricas que pode ser usado para publicar métricas sem adicionar muito código à sua solução. Também criamos um exemplo de cliente que usa o gerenciador de métricas para publicar as métricas. O código completo do gerenciador de métricas e do exemplo de cliente está disponível no GitHub.

Abaixo está um trecho de código desse exemplo de cliente. Aqui, você pode ver como ele captura e publica métricas sem adicionar muita complexidade ao seu código:

Figura 2 — Instrumentando sua aplicação SaaS.

Você notará que este exemplo adiciona instrumentação de métricas em diferentes camadas dentro da aplicação. A interface do usuário (UI) publica uma métrica para indicar que a página Atualizar Produto foi usada. Em seguida, o serviço de back-end captura o tempo necessário para atualizar um produto dentro da tabela do DynamoDB.

Para esse fluxo, pode haver várias partes do nossa aplicação que precisam ser instrumentadas.

Isso lhe dá uma ideia de como isso pode funcionar conceitualmente. No entanto, vamos ver o que significa introduzir essas chamadas de instrumentação de métrica no código de um de nossos microsserviços. O objetivo é tornar essa instrumentação o mais leve e não invasiva possível.

Para conseguir isso, criamos um gerenciador de métricas que pode ser usado para publicar métricas sem adicionar muito código à sua solução. Também criamos um exemplo de cliente que usa o gerenciador de métricas para publicar as métricas. O código completo do gerenciador de métricas e do exemplo de cliente está disponível no GitHub.

Abaixo está um trecho de código desse exemplo de cliente. Aqui, você pode ver como ele captura e publica métricas sem adicionar muita complexidade ao seu código:

public class sampleclient { 
       private static final MetricsPublisher metricPublisher = MetricsPublisherFactory.getPublisher(jwtTokenManager); 
       public static void main(String[] args) throws Exception { 
             metricPublisher.publishMetricEvent(new ExecutionTimeMetric(100L), jwtToken, new HashMap<>()); 
       } 
}

Neste exemplo, você verá que capturamos o tempo de execução usando a classe ExecutionTimeMetric. Em seguida, chamamos uma instância do MetricPublisher para publicar a métrica. Você pode imaginar um código semelhante sendo instrumentado dentro da sua camada de acesso a dados, onde você captura a hora de início e término da sua consulta e a usa para registrar seu tempo de execução.

Outra coisa importante a ser observada é que o jwtTokenManager e o jwtToken estão sendo passados para o MetricsPublisher. Em uma aplicação SaaS típica, seu jwtToken tem informações de usuário/tenant como parte de claims (informações) personalizadas.

O MetricsPublisher aceita o jwtToken e extrai as informações do tenant dessas claims personalizadas. Isso não significa apenas que os detalhes do tenant são capturados como parte de cada métrica, mas também garante que os desenvolvedores de aplicações não precisem passar detalhes do tenant como parte de cada chamada de métrica.

Por fim, use o último argumento de PublishMetricEvent para transmitir qualquer informação adicional relacionada às métricas como um par de chaves-valor.

A ideia aqui é criar uma biblioteca reutilizável que todos os seus serviços usem de forma consistente para publicar métricas.

Estruturando seus eventos de métricas

Como parte dessa solução, criamos um formato universal de métrica destinado a representar cada um dos diferentes eventos de métrica você talvez queira publicar. A Figura 3 fornece uma visão geral do conteúdo que seria colocado em um evento de métricas.

Figura 3 — Mensagem métrica JSON.

O atributo “type” pode ser usado para categorizar as métricas como “Aplicação”, “KPIs de negócios”, “Infraestrutura” e assim por diante. Como estamos visando métricas em nível de aplicação, por enquanto, defina como “Application”.

Os campos “workload” e “context” podem oferecer suporte a vários casos de uso. Por exemplo, em um ambiente baseado em microsserviços, você pode usar o campo “workload” para capturar o nome da aplicação, como ProductApplication, enquanto o campo “context” captura valores mais detalhados sobre a funcionalidade, como ProductService ou CatalogService em nosso exemplo.

O objeto “tenant” é usado para capturar informações do tenant. O contexto do tenant é usado para associar os tenants às métricas emitidas. Isso nos permite criar uma visualização mais rica através das lentes de cada tenant.

O atributo “metric” é usado para capturar os dados de métricas que precisam ser emitidos. É importante ter uma unidade de medida consistente para as métricas emitidas — as métricas de armazenamento, por exemplo, geralmente são capturadas em megabytes — para que a métrica emitida possa usar “MB” ou “Megabytes” como unidade. No entanto, ele precisa ser consistente em todas as métricas capturadas.

Você pode enviar informações adicionais no campo “metadata”, que também pode ser usado para criar várias visualizações. Nesse cenário, estamos enviando “resource” para capturar os serviços da AWS para os quais a métrica foi capturada e “user” para capturar o usuário interagindo com o sistema.

Ingerir e agregar dados

Agora que entendemos como as métricas são capturadas e publicadas, vamos ver como esses dados serão ingeridos e agregados.

Em nossa solução, o stream do Amazon Kinesis Data Firehose está configurado para publicar os dados no Amazon Redshift. No entanto, o Amazon Redshift depende do arquivo JSONPaths que especifica como analisar e mapear dados JSON. A Figura 4 mostra o arquivo JSONPath usado para mapear o conteúdo JSON das métricas.

Figura 4 — Arquivo JSONPath para métricas JSON.

Depois que os dados chegam ao stream do Kinesis Data Firehose, eles são temporariamente armazenados em um bucket do S3 antes que o comando COPY do Amazon Redshift os consuma.

Esta tabela mostra como as métricas são representadas na tabela de métricas do cluster Amazon Redshift.

Figura 5 — Métricas na tabela do Amazon Redshift.

Uma coisa a observar é que o objeto “metadata” é armazenado como uma string JSON em uma única coluna. Isso é feito pensando na extensibilidade futura, permitindo que os desenvolvedores adicionem quaisquer dados relevantes que possam ajudá-los a criar visualizações personalizadas pertinentes aos seus ambientes

O ponto chave aqui é que agora temos uma representação universal de nossas métricas que abrange a atividade, o consumo e muito mais dos tenants. Os dados também incluem o identificador e os tiers do tenant. Com essas peças prontas, podemos criar painéis que nos permitem fazer perguntas importantes sobre o sistema sob a ótica dos tenants e tiers de tenant.

Visualizações métricas de SaaS

Agora que ingerimos os dados, podemos usar o Amazon QuickSight para criar visualizações interessantes dos dados. As visualizações que você criar dependerão diretamente da natureza dos dados que você escolher publicar e de como você agrupa essas métricas.

Para dar uma ideia melhor de como essas métricas podem se transformar em visualizações relevantes, nosso exemplo de solução cria várias visualizações que são alimentadas pelos mesmos dados de métricas. Essas visualizações fornecem alguns exemplos concretos de como esses dados podem ser usados para analisar as tendências em seu ambiente SaaS.

Você pode consultar nosso repositório de métricas e analytics (analíticas) do GitHub para obter instruções passo a passo sobre como configurar o QuickSight e criar alguns exemplos de visualizações.

Ao analisar esses exemplos de visualizações, você verá como criamos visualizações específicas para uma experiência multi-tenant. Esses painéis oferecem mecanismos para avaliar as tendências de todos os tenants, tenants individuais e tiers de tenants. Os dados também abrangem recursos, consumo de recursos e assim por diante.

À medida que você começar a aplicar isso ao seu próprio ambiente, as diferentes partes da sua equipe começarão a determinar qual visualização desses dados é mais valiosa. Você também descobrirá que, à medida que mais métricas forem publicadas, surgirão mais consumidores e casos de uso que criarão mais demanda por novas métricas.

Executando a solução de exemplo

Agora que você já viu os conceitos principais, pode explorar as partes móveis dessa solução instalando e executando a infraestrutura de métricas em sua própria conta da AWS. Os detalhes sobre como criar o ambiente podem ser encontrados no README do repositório no GitHub.

Esse arquivo README também orienta você pelas etapas para implantar as soluções usando um script do AWS CloudFormation que provisiona todos os elementos da arquitetura descritos acima. O script de configuração oferece uma variedade de opções para personalizar a experiência.

Esse repositório vem com um gerador de métricas para gerar métricas de exemplo e testar seu deployment (implantação). O arquivo README também contém as instruções sobre como usar esse gerador de métricas.

Configurar o Amazon QuickSight é um pouco mais complicado, já que seus painéis não podem ser totalmente configurados por meio do CloudFormation. No entanto, seguindo as instruções documentadas no arquivo README, você terá uma conta do Amazon QuickSight configurada corretamente com a fonte de dados necessária criada para acessar dados de métricas dentro do seu cluster do Amazon Redshift.

No entanto, você ainda precisará criar o painel manualmente, consultando as figuras apresentadas dentro do arquivo README.

Não subestime o valor e o impacto das métricas

No início deste post, falamos sobre a importância das métricas em um negócio de SaaS. Falamos sobre o valor que isso agrega do ponto de vista técnico e de negócio, mas a realidade é que só demos uma ideia superficial do que você pode alcançar.

Muitos provedores de SaaS desejam correlacionar o consumo dentro de sua aplicação SaaS com os tenants. As empresas querem entender a lucratividade por tenant, mas a única maneira de conseguir isso é coletando métricas relacionadas ao consumo entre tenants e distribuindo seu custo da AWS com base nesse consumo.

Recentemente, a equipe do AWS SaaS Factory trabalhou com a CloudZero, uma parceira de tecnologia avançada da AWS, e a ajudou a criar uma solução de SaaS que fornece uma maneira de determinar o custo por cliente coletando métricas e mapeando-as de acordo com seus custos da AWS.

Os provedores de SaaS também podem prever consumos futuros, detectar anomalias e fazer projeções de negócios com base em métricas coletadas ao longo de um período de tempo. Depois de coletar as métricas em um repositório central, você pode usar as habilidades de aprendizado de máquina nos serviços da AWS, como Amazon QuickSight, Amazon Forecast e Amazon SageMaker, para fornecer insights sobre essas métricas.

Conclusão

Neste post, discutimos a importância de coletar métricas úteis para o sucesso de uma organização SaaS e como essas métricas podem ser usadas para capacitar várias equipes em sua organização. As métricas podem fornecer informações valiosas que ajudam ainda mais a impulsionar seus negócios de SaaS na direção certa e proporcionam uma vantagem competitiva.

É importante observar que a arquitetura de referência apresentada aqui é uma das muitas maneiras de alcançar o mesmo objetivo. Por exemplo, alguns clientes podem escolher o Amazon S3 ou o Amazon CloudWatch em vez do Amazon Redshift para armazenar métricas. Pode haver vários fatores técnicos e de negócio em sua organização que podem influenciar sua escolha de tecnologia.

Independentemente de quais serviços da AWS você escolher, a arquitetura de referência que apresentamos aqui pode ajudá-lo a atingir suas metas fornecendo uma abordagem central para coleta e visualização de métricas.

Sobre o AWS SaaS Factory

O AWS SaaS Factory ajuda organizações em qualquer estágio da jornada de SaaS. Seja para criar novos produtos, migrar aplicações existentes ou otimizar soluções de SaaS na AWS, podemos ajudar. Visite o AWS SaaS Factory Insights Hub para descobrir mais conteúdo técnico e comercial e melhores práticas.

Os criadores de SaaS são incentivados a entrar em contato com seu representante de conta para obter informações sobre modelos de engajamento e trabalhar com a equipe do AWS SaaS Factory.

Inscreva-se para se manter informado sobre as últimas notícias, recursos e eventos de SaaS na AWS.

—

Este conteúdo foi traduzido para Português do blog original em inglês (link aqui).

Tradutor: Cesar Augusto Kuehl, arquiteto de soluções  – AWS Brasil

Revisores: Rodrigo Peres e Rafael Weffort, arquitetos de soluções – AWS Brasil