Review: Práticas de Right Sizing na AWS
Tenha o dimensionamento correto dos seus recursos
Quando falamos de práticas de Right Sizing estamos falando de um processo que consiste em:
- Combinar tipos e tamanhos de instância com os requisitos de desempenho e capacidade da carga de trabalho com o menor custo possível;
- Analisar os recursos já implementados e a identificar oportunidades que habilitem a redução do seu tamanho sem comprometer a capacidade e outros requisitos do uso destes recursos.
Right Sizing deve ser uma prática essencial para qualquer time de Infraestrutura
Prática que permite a otimização contínua para se ter a dimensão e o custo certo.
É muito comum que times de Infraestrutura recém chegados do universo on-premisses, que acabem ignorando essa prática ao migrar seu Workload para a nuvem. Geralmente as empresas utilizam o método chamado de “lift and shift” que basicamente é pegar sua configuração atual dos seus recursos on-premises e provisiona-los do mesmo tamanho na nuvem.
Right Sizing e FinOps
Right Sizing se torna ainda mais importante por ser uma prática de FinOps, que é um modelo operacional para gerenciar os custos dos serviços na Nuvem. Para isso, a prática reúne profissionais de tecnologia, negócios e finanças com um novo conjunto de processos. De modo geral, a jornada do FinOps possui três fases iterativas: informar, otimizar e operar.
Informar
Esta é a primeira fase da jornada do FinOps, capacitando organizações e equipes com visibilidade, alocação, benchmarking, orçamento e previsão. A natureza sob demanda e elástica da nuvem, juntamente com preços e descontos personalizados, torna necessário uma visibilidade precisa e oportuna para decisões inteligentes. A alocação precisa de gastos na nuvem com base em tags, contas ou mapeamentos de negócios permite chargeback e showback. As partes interessadas em negócios e finanças também querem garantir que estejam gerando o retorno do investimento (ROI), mantendo o orçamento e prevendo com precisão os gastos, evitando surpresas.
Otimizar
Depois que as organizações e equipes são capacitadas, elas precisam otimizar sua presença na nuvem. Os provedores de nuvem oferecem vários mecanismos para esta otimização. Onde as capacidades por demanda são as mais caras neste quesito, então para incentivar o planejamento avançado de reservas e o aumento do comprometimento, os provedores de nuvem oferecem descontos para compromissos que normalmente envolvem cálculos complexos para fazer o uso de Instâncias reservadas (RI). Além disso, equipes e organizações podem otimizar o ambiente dimensionando e automatizando o direito de desativar qualquer uso desnecessário de recursos.
Operar
As organizações começam a avaliar continuamente os objetivos de negócios e as métricas que estão rastreando em relação a esses objetivos e como estão em alta. Avalie o alinhamento dos negócios em velocidade, qualidade e custo. Qualquer sucesso organizacional só é possível se a organização construir uma cultura de FinOps que envolva um Centro de Excelência (CoE) em Custo de Nuvem construído em torno de stakeholders comerciais, financeiros e operacionais que também definam a governança apropriada.
Right Sizing e AWS Well-Architected
Caso você não conheça esse Framework da AWS, vale a leitura: https://aws.amazon.com/pt/architecture/well-architected/
Além de tudo o que já falamos, essa prática faz parte do pilar de redução de custos do AWS Well-Architected Framework, deixando claro que uma boa arquitetura deve considerar o dimensionamento correto e a revisão contínua dos recursos, para projetar e operar sistemas confiáveis, seguros, eficientes e econômicos na nuvem.
Além do Right Sizing, temos outros pilares importantes:
- Right Sizing
- Increase Elasticity
- Leveraging the right Pricing Model
- Leveraging the right Storage Class
- Mechanisms for Optimisation
E não é por acaso que o Right Sizing é o primeiro pilar da redução de custos, pois ele se aplica para tudo quando falamos de computação em nuvem, instâncias, banco de dados e outros recursos e serviços; sempre respeitando a premissa de se utilizar e provisionar o recurso de acordo com o que precisamos.
Vamos exemplificar!
No nosso exemplo, aplicaremos o Right Sizing em uma instancia de EC2 com valores hipotéticos:
1 — Temos uma instancia m4.4xlarge ao custo de $1,72 por hora
2 — Após o monitoramento das métricas da instancia, verificou-se que a mesma poderia ser reduzida para a m4.large ao custo de $0.215 por hora, ou seja, uma redução de 87% no custo por hora da instancia.
Fonte: Leverage Rightsizing to Maximize Savings on AWS
Outro fato importante é que a AWS está em constante evolução, seja na ampliação dos seus Data Centers, seja na evolução de Hardware. Essa evolução sempre resulta em melhores preços para os seus clientes, trazendo novas famílias de instâncias.
Isso é tão comum, que essas novas instâncias e mudanças de famílias já ocorreram mais de 80 vezes desde a sua fundação. Por isso devemos estar atentos às métricas e antenados em acompanhar as novas gerações de máquinas, pois sempre haverá oportunidade de ganho em performance e na redução de custos.
Isso fica ainda mais evidente no exemplo abaixo:
Fonte: Leverage Rightsizing to Maximize Savings on AWS
Observando a tabela da esquerda acima vemos instâncias da família C (otimizada para cpu) e M (balanceada para uso geral) onde as novas gerações são mais baratas, já na tabela da direita temos uma recomendação da AWS onde ela fala para sempre considerar utilizar maquinas da família T que também é de uso geral como as M, porem com a diferença que é indicada para aplicações que possuem picos de utilização, é baseado em créditos de uso de CPU, ou seja se você não tem necessidade que a maquina sempre tenha o uso intenso de CPU ela é uma boa pedida pois possui um valor abaixo e ainda possuem a mesma performance, mas baseada agora em créditos que geralmente cobrem parte de um horário comercial por exemplo, e que se em um certo período houve baixa utilização não prevista você consegue acumular estes créditos.
Boas Práticas de Rightsizing
- Comece Simples e identifique recursos ociosos (Idle), começar em ambientes não críticos como os de desenvolvimento e homologação;
- Agregar instancias por tags e ASG’s (Auto scalling groups);
- Verificar o tradeoff nas cadencias de rightsizing, Contínuo vs Agendado;
- Mensure e teste várias vezes antes de realizar redimensionamento;
- Custos de ROI devem incluir custos de ferramentas terceiras;
- Aplicar as lições aprendidas dos Rightsizing realizados em novos workloads;
Boas Práticas para Instâncias EC2 e RDS
1 — Right Sizing usando dados de performance:
Analise os dados de desempenho para dimensionar corretamente suas instâncias do EC2.
- Identifique instâncias e subutilização, as principais métricas a serem procuradas são o uso da CPU e o uso da memória;
- Identifique instâncias com um uso máximo da CPU e menos de 40% de memória em um período de um mês.
Essas são as instâncias em que você deseja realizar o Right Size para reduzir custos.
Para instâncias EC2 otimizadas, lembre-se do seguinte:
- Concentre-se em dados de instância recentes;
- Ignore famílias de instâncias que podem ser estouradas (tipos de instância T2) porque essas famílias são projetadas para executar tipicamente em baixas porcentagens de CPU por períodos significativos de tempo.
Para instancia otimizadas para storage (tipos de instância I2 e D2), onde o recurso principal é IOPS alto de dados, concentre-se em IOPS para verificar se as instâncias estão com excesso de provisionamento. Lembre-se do seguinte para instâncias otimizadas para storage:
• Instâncias de tamanhos diferentes têm classificações de IOPS diferentes, então verifique e adapte para cada tipo de instância e seu uso. Comece com o tipo de instância otimizada para armazenamento mais comumente usada.
• Os valores máximos de Network In e Network Out são medidos em bytes por minuto. Use a fórmula a seguir para converter essas métricas em megabits por segundo: Maximum Network In (ou Network Out) x 8 (bytes em bits) / 1024/1024/60 = Número de Mbps
• Observe como as métricas de porcentagem de I/O e CPU são alteradas durante o dia e se há picos que precisam ser acomodados.
O Right Size em relação à memória, se você achar que a utilização máxima de memória em um período de um mês é inferior a 40%. A AWS fornece scripts de amostra para monitorar a utilização de memória e espaço em disco nas instâncias do EC2 executando Linux. Você pode configurar os scripts para reportar as métricas ao Amazon CloudWatch.
Ao analisar dados de desempenho para instâncias de RDS, concentre-se nas seguintes métricas para determinar se o uso real é menor que a capacidade da instância:
• Utilização média da CPU;
• Utilização máxima da CPU;
• RAM mínima disponível;
• Número médio de bytes lidos do disco por segundo;
• Número médio de bytes gravados no disco por segundo;
2 — Right Size com base nas necessidades de uso:
Ao monitorar o desempenho atual, identifique as seguintes necessidades e padrões de uso para poder tirar proveito de possíveis opções de right size:
• Estado estacionário — a carga permanece em um nível relativamente constante ao longo do tempo, e você pode prever com precisão a provável carga computacional. Para esse padrão de uso, você pode considerar Instâncias Reservadas, o que pode fornecer economias significativas.
• Variável, mas previsível — a carga é alterada, mas em um cronograma previsível. O Auto Scaling é adequado para aplicativos que possuem padrões de demanda estáveis com variabilidade horária, diária ou semanal. Você pode usar esse recurso para aumentar ou diminuir a capacidade do Amazon EC2 quando tiver um spike no tráfego ou flutuações previsíveis no tráfego.
• Desenvolvimento / QA / Homolocação e Produção — os ambientes geralmente são usados apenas durante o horário comercial e podem ser desativados durante a noite, fins de semana e feriados. Você precisará adicionar uma marcação de tags para identificar estas instâncias.
• Temporário — para workloads temporários com horários de início flexíveis e que podem ser interrompidos, considere a utilização de uma instância spot do Amazon EC2 em vez de usar uma instância on-demand.
3 — Right Size, desativando instâncias ociosas:
A maneira mais fácil de reduzir custos operacionais é desativar as instâncias que não estão mais sendo usadas. Se você encontrar instâncias inativas por mais de duas semanas, é seguro interrompê-las ou mesmo encerrá-las. Antes de encerrar uma instância inativa por duas semanas ou menos, considere:
• Quem é o proprietário da instância?
• Qual é o impacto potencial de encerrar a instância?
• Quão difícil será recriar a instância se você precisar restaurá-la?
A interrupção de uma instância do EC2 mantém operacionais os volumes EBS conectados. Você continuará sendo cobrado por esses volumes até excluí-los. Se você precisar da instância novamente, poderá reativá-la facilmente. A finalização de uma instância, no entanto, exclui automaticamente os volumes EBS anexados e requer esforço para re-provisionar caso a instância seja necessária novamente. Se você decidir excluir um volume EBS, considere armazenar um snapshot do volume para que ele possa ser restaurado mais tarde, se necessário.
Outra maneira simples de reduzir custos é interromper as instâncias usadas durante horas em que essas instâncias não estão em uso e, em seguida, iniciá-las novamente quando o uso for necessário. Supondo uma semana de trabalho de 50 horas, você pode economizar 70% ao interromper automaticamente as instâncias fora do horário comercial. Muitas ferramentas estão disponíveis para automatizar o agendamento, incluindo o Amazon EC2 Scheduler, o AWS Lambda e o AWS Data Pipeline, além de ferramentas de terceiros, como Rundeck (via desenvolvimento de script), CloudHealth e Skeddly.
4 — Right Size, selecionando a família de instância correta:
Você pode dimensionar corretamente uma instância migrando para um modelo diferente na mesma família de instâncias ou migrando para outra família de instâncias. Ao migrar na mesma família de instâncias, você só precisa considerar vCPU, memória, taxa de transferência de rede e armazenamento efêmero. Uma regra geral boa para instâncias do EC2 é que, se o uso máximo da CPU e da memória for inferior a 40% em um período de um mês, você poderá reduzir com segurança a máquina pela metade. Por exemplo, se você estivesse usando um EC2 c4.8xlarge, poderia mudar para um c4.4xlarge, que economizaria US $ 190 a cada 10 dias.
Ao migrar para uma família de instâncias diferente, verifique se o tipo de instância atual e o novo tipo de instância são compatíveis em termos de tipo de virtualização, rede e plataforma:
• Tipo de virtualização — as instâncias devem ter o mesmo tipo de virtualização Linux AMI (PV AMI versus HVM) e plataforma (EC2-Classic versus EC2-VPC). Para mais informações, consulte Tipos de virtualização AMI do Linux.
• Rede — algumas instâncias não são suportadas no EC2-Classic e devem ser iniciadas em uma nuvem privada virtual (VPC). Para obter mais informações, consulte Tipos de instância disponíveis apenas em uma VPC
• Plataforma — se o seu tipo de instância atual suportar AMIs de 32 bits, selecione um novo tipo de instância que também suporte AMIs de 32 bits (nem todos os tipos de instância do EC2). Para verificar a plataforma da sua instância, vá para a tela Instâncias no console do Amazon EC2 e escolha Mostrar / ocultar colunas, arquitetura.
Quando você redimensiona uma instância do EC2, a instância redimensionada geralmente tem o mesmo número de volumes de armazenamento de instância que você especificou quando iniciou a instância original. Você não pode anexar volumes de armazenamento de instância a uma instância depois de iniciá-la; portanto, se você deseja adicionar volumes de armazenamento de instância, será necessário migrar para um novo tipo de instância que contenha o maior número de volumes.
5 — Right Size em instâncias de banco de dados RDS:
Você pode dimensionar as instâncias do banco de dados ajustando a memória ou a CPU para cima ou para baixo à medida que os requisitos de desempenho e capacidade mudam. A seguir estão algumas coisas a considerar ao escalar uma instância de banco de dados:
• O armazenamento e o tipo de instância são dissociados. Quando você aumenta ou diminui a instância de seu banco de dados, o tamanho do armazenamento permanece o mesmo e não é afetado pela alteração.
• Você pode modificar separadamente sua instância RDS para aumentar o espaço de armazenamento alocado ou melhorar o desempenho alterando o tipo de armazenamento (como SSD de uso geral para SSD IOPS provisionado).
• Antes de escalar, verifique se possui o licenciamento correto para os mecanismos comerciais (SQL Server, Oracle), especialmente se você trouxer sua própria licença (BYOL).
Resultados
Abaixo segue um resultado da aplicação das boas práticas de Right Size em EC2 no nosso ambiente de desenvolvimento entre agosto e dezembro de 2019, utilizando praticamente todos recursos mencionados anteriormente como a redução de recursos das instâncias, remoção de instâncias que não são mais utilizadas, desligamento das instâncias fora do horário comercial entre outros:
Podemos observar uma queda significativa mês a mês, entre Agosto/2019 a Dezembro/2019 tivemos uma queda de praticamente 60% no custo mensal total. o gráfico ainda nos demonstra da importância da prática do Right Sizing ser recorrente e como as reduções foram ocorrendo nos meses subsequentes, portanto sempre precisamos checar oportunidades de ajustes e ficar atentos a reduções nos nossos ambientes que são vivos e constantemente atualizados.
Ferramentas de Right Sizing
Existem algumas ferramentas que nos auxiliam na analises do rightsizing, a própria AWS nos fornece serviços internos que são:
- AWS CloudWatch: é um serviço de monitoramento e observação, coleta dados de monitoramento e operações na forma de logs, métricas e eventos, oferecendo uma visualização unificada dos recursos, dos aplicativos e dos serviços da AWS.
- AWS Trusted Advisor: realiza análise de recursos e relatórios sobre quaisquer recursos subutilizados ou superutilizados. Por exemplo, no Amazon EC2 Trusted Advisor realiza análises sobre a utilização da CPU e o tráfego de rede durante um período de tempo.
- AWS Compute Optimizer: recomenda recursos ideais do AWS Compute para as suas cargas de trabalho para reduzir custos e melhorar o desempenho usando machine learning para analisar métricas de utilização histórica.
Conclusão
O Right Sizing é a maneira mais eficaz de controlar os custos da nuvem. Envolve a análise contínua das necessidades e padrões de desempenho e uso da instância — e, em seguida, desativa as instâncias inativas e as instâncias com excesso de aprovisionamento ou com a baixa utilização no seu workload.
Como suas necessidades de recursos estão sempre mudando, o Right Size deve se tornar um processo contínuo para obter continuamente a otimização de custos.
Você pode tornar o Right Size um processo tranquilo, estabelecendo um cronograma para cada equipe, aplicando a marcação de tags para todas as instâncias e aproveitando os recursos das ferramentas que a AWS disponibiliza.
Por Rodrigo Barros
