Well-Architected Framework – Performance Efficiency – Parte 2

Olá, pessoal.

Essa semana, continuaremos o assunto sobre o pilar de performance do Well-Architected Framework. Até agora nós vimos algumas práticas para selecionar os recursos que mais se adaptam a solução. Agora veremos como podemos acompanhar a evolução do Workload, verificando pontos de melhoria e utilizando novas tecnologias em nosso favor.

A primeira parte deste post, pode ser acessada aqui.

Review

Novos serviços e soluções são desenvolvidos todos os dias, e devemos saber extrair o máximo de benefícios destas novas tecnologias. Portanto, tendo a arquitetura definida, devemos experimentar diversas soluções diferentes, revisitando a seleção dos melhores recursos e configurações. Para orientar esta seleção, devemos ter métricas bem definidas, possibilitando a extração de informações sobre pontos de melhoria.

Inclusive, este review pode ser incorporado ao pipeline de CI/CD, através de alguns artifícios como benchmarking e testes de carga.

Benchmarking

O Benchmarking, é uma forma de quantificarmos a performance de determinado componente, em determinado cenário. Executando um conjunto de testes em diversos opções de recursos, podemos compará-los, identificando qual deles se adapta melhor a determinado elemento no workload. Como exemplo, podemos citar o benchmark de dois tipos de instâncias EC2, comparando qual dos dois tipos se sobressai em determinada situação.

Podemos utilizar ferramentas de terceiros, como o TPC-DS, ou criar testes de benchmark customizados. É importante executá-los diversas vezes sobre determinado contexto, sintetizando o resultado no final. Isto se faz necessário, pois o ambiente pode sofrer variações (networking, por exemplo) durante o teste, impactando no resultado final. Devemos considerar também fazer um aquecimento do ambiente antes de iniciar os testes, para evitar que o benchmark sofra impacto sobre a inicialização de algum serviço.

Testes de carga

Testes de carga (Load tests), são testes que irão expor o workload à cargas intensas, evidenciando pontos de melhoria a serem trabalhados. A recomendação é que este tipo de teste seja executado sobre um cenário similar ao existente em produção, utilizando dados sintéticos ou sobre uma cópia sanitizada (removendo dados sensíveis) dos dados deste ambiente.

Como um exemplo, e falando especificamente sobre a AWS, podemos replicar o ambiente de produção usando o CloudFormation, efetuar a carga dos dados e utilizar instâncias EC2 spot para gerar volume de acessos a esta réplica do ambiente. Depende da suite de testes, podemos replicar o ambiente diversas vezes, executar os testes em paralelo, destruindo estes ambientes no final.

Review na AWS

Na AWS, podemos utilizar o CloudFormation e o CodeDeploy para nos auxiliar na automação de testes e replicação dos ambientes. Para acompanharmos a execução destes testes, podemos utilizar as métricas e logs do Amazon CloudWatch.

Para sabermos das novas tecnologias lançadas pela AWS, devemos acompanhar diariamente o AWS Blog.

Monitoramento

Como citamos anteriormente, devemos monitorar o workload constantemente afim de identificarmos problemas de performance, preferencialmente antes que o cliente final os perceba. Identificados estes problemas, poderemos recorrer à automação para mitigá-los.

Monitoramento passivo e ativo

Podemos monitorar ativamente o workload através de simulações controladas da utilização do sistema, especialmente em seus caminhos mais críticos. Esta abordagem pode ser utilizada em todos os ambientes, especialmente para garantir que tais problemas não cheguem ao ambiente de produção.

Ou podemos monitorar passivamente, onde acompanhamos a utilização do sistema pelos usuários. Neste caso, podemos extrair diversas métricas relacionadas a experiência do usuário, variação de performance baseada na distribuição geográfica e o impacto na utilização das APIs.

Fases do monitoramento

O monitoramento, especialmente na AWS, consiste de 5 fases:

  1. Geração: Extração de métricas, definição de limites;
  2. Agregação: Consolidação de várias fontes de monitoramento;
  3. Processamento em tempo real: Reconhecimento de incidentes e resposta aos mesmos;
  4. Armazenamento: Armazenamento e gestão das políticas de retenção;
  5. Análise: Visualização e obtenção de insights.

A terceira fase, processamento em tempo real, permite a criação de alarmes e a automação de respostas a eventos indesejados de performance. Evitando a intervenção humana, evitamos também novas complicações.

É importante também utilizarmos Game Days para efetuarmos simulações, afim de identificarmos se estes alarmes estão funcionando corretamente.

Monitoramento na AWS

A principal ferramenta de monitoramento da AWS é o Amazon CloudWatch. Porém, também devemos considerar a AWS Lambda, como uma ferramenta que pode ser integrada ao CloudWatch, permitindo a automação de respostas aos eventos de performance.

Vale salientar também o Amazon EMR, que pode ser utilizado para analise de logs, e o Amazon S3, que pode ser utilizado para armazená-los com baixo custo.

Trade-offs

Quando arquitetamos um sistema, temos que identificar as prioridades e desenhar a solução de acordo com elas. Dito isto, muitas vezes temos que pesar o impacto de um aspecto, em prol de outros.

Como exemplo, podemos citar que em determinado cenário, a performance será prioritária. Para atingirmos o nível desejado, deveremos abrir mão da consistência forte e passarmos a trabalhar com consistência eventual. Ou ainda poderemos optar por baixo custo, abrindo mão de resiliência. Como falei, vai depender de cada cenário.

Em relação a performance, o guideline sugere algumas abordagens:

  • Caching: Caching é uma forma de melhorarmos a performance, porém em troca teremos situações onde os dados retornados poderão ser antigos, não consistentes com o que realmente está armazenado;
  • Particionamento: Particionamento pode aumentar a performance para escrita em um banco de dados, contudo, ele pode aumentar a complexidade do sistema, ou impactar no seu modelo de consistência (consistência eventual);
  • Compressão: Compressão pode aumentar a performance de um sistema, principalmente na transferência de dados, mas em troca teremos uma carga maior de processamento para efetuar a compressão;
  • Buffering: Podemos utilizar filas para desacoplar componentes. Isso possibilita que os produtores desta fila respondam rapidamente, evitando backpressure, delegando o processamento das mensagens recebidas para consumidores da mesma. Entretanto, o sistema poderá trabalhar com consistência eventual, pois as mensagens serão processadas em um segundo momento.

Trade-offs na AWS

O Elasticache é uma ferramenta de caching de propósito geral, já o CloudFront possibilita a entrega de conteúdo e caching mais próximos dos usuários finais, através dos Edge Locations.

Podemos considerar o SQS e o Kinesis como serviços a serem usados como buffers de mensagens.

E por fim temos a replicação do RDS, que permite a criação de réplicas de leitura, com o custo de um pequeno lag na replicação.

Conclusão

Para garantirmos que o sistema mantenha uma performance próxima aos padrões desejados, devemos monitorá-lo constantemente através de métricas, efetuando simulações para identificar e mitigar possíveis problemas e evoluí-lo utilizando tecnologias mais adequadas, conforme elas forem surgindo.

Abraços e boa semana!


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s