A otimização de custos na nuvem é o processo de redução de seus gastos gerais com nuvem, identificando recursos mal gerenciados, eliminando desperdícios, reservando capacidade para descontos mais altos e dimensionando os serviços de computação com o tamanho certo.
Os fornecedores de nuvem oferecem às organizações escalabilidade ilimitada e custos de TI mais baixos, cobrando apenas pelos recursos que você usa. Mas, a verdade sobre os preços é que os clientes de nuvem são cobrados pelos recursos que encomendam, independentemente de usá-los ou não. Em um relatório recente, How to Identify Solutions for Managing Costs in Public Cloud IaaS, os analistas do Gartner estimam que até 70% dos custos em nuvem são desperdiçados.
O fato por trás desse número é que nós (humanos) não podemos otimizar os custos da nuvem em escala. Não importa quantas pessoas você designe para essa tarefa, os resultados não corresponderão aos de uma poderosa plataforma baseada em IA.
Humanos podem fazer otimização de custos em pequena escala, por exemplo, quando há poucas cargas de trabalho em execução na nuvem, mas rapidamente, à medida que a demanda por nuvem cresce, nós perdemos o controle.
Não se deixe enganar: otimizar os custos com nuvem é difícil e complexo
Vamos expor a seguir os principais motivos pelos quais a otimização de custos com nuvens está além da escala humana. Antes de qualquer coisa, vamos começar com os métodos mais usados para otimizar os custos com a nuvem:
- Rightsizing (computação e armazenamento)
- Compromisso de longo prazo (ou seja, instâncias reservadas – RIs)
- Parar e Excluir (recursos ociosos ou desnecessários)
Aparentemente, cada método é simples, mas assim que você começar a se aprofundar em cada tarefa e entender o que é realmente necessário para tirar o máximo proveito disso, além do fato de que tudo deve ser feito continuamente, talvez você entenda o raciocínio por trás da nossa ousada declaração acima.
- Um dimensionamento eficaz de recursos requer análises complexas
Para otimizar verdadeiramente uma carga de trabalho na nuvem, o mais importante é garantir que você esteja redimensionando a computação da carga de trabalho para o tamanho com o custo mais efetivo, evitando riscos de desempenho.
Ao dimensionar uma carga de trabalho para um novo tipo de instância ou tamanho da VM, você precisa garantir que todas as métricas de computação (Memória, CPU), armazenamento (IOPS) e taxa de transferência de rede sejam consideradas com precisão, incluindo seus picos e médias.
Ao dimensionar corretamente uma carga de trabalho, você deve considerar os picos históricos das cargas de trabalho e aplicar os padrões da indústria, como o uso de diferentes níveis de percentis de picos, sempre que isso fizer sentido. Por exemplo, considere o dimensionamento mais agressivo para o 90º percentil de picos para carga de trabalho que não seja de produção ou desenvolvimento, enquanto aplica um dimensionamento 95º ou absoluto mais conservador aos picos (por exemplo, 100%) para cargas de trabalho de produção.
Você também precisa pensar no período de tempo a considerar no rightsizing (por exemplo: período de observação / período de amostragem), ao tomar a decisão de dimensionamento. Tudo vai depender da carga de trabalho e do desempenho cíclico que você prefere considerar, ou não. Por exemplo: você pode querer considerar os últimos sete dias para cargas de trabalho mais elásticas, enquanto para cargas de trabalho menos elásticas talvez use um período mais longo, como os últimos 90 dias.
As duas últimas abordagens permitirão essencialmente desbloquear a elasticidade que a nuvem oferece. Não é a elasticidade uma das razões pelas quais você mudou para a nuvem? Certamente, você deseja aproveitar o máximo possível, caso contrário, você não está usando a nuvem corretamente e pagará por isso.
- Escalar entre diferentes tipos de famílias não é fácil. A maioria das ferramentas evita
Isso fica ainda mais difícil ao tentar alternar entre diferentes famílias de tipos de instância na AWS. Ao escalar entre famílias, há vários fatores e limitações que devem ser levados em consideração, como os drivers ENA (Rede) e NVMe, limitações impostas por instâncias do tipo AMI (HVM ou PV), garantindo que a computação suporte a camada de armazenamento (EBS otimizada, por exemplo), bem como limites de cota nas contas da nuvem, etc.
A propósito, a mudança entre tipos de família é tão complexa que a maioria das ferramentas de otimização de nuvem não tenta fazê-lo, preferindo escalar apenas dentro da mesma família (alerta de spoiler: a Turbonomic não é uma delas). O downsizing de escala dentro da mesma família é o que está dobrando a capacidade e os custos.
Também é importante entender os benefícios exatos que cada tipo de instância oferece (geração antiga versus nova geração) tanto para capacidade quanto para custo. Por exemplo, na imagem abaixo, você notará que a oferta m5.large oferece mais memória que a m4.large, mas custa um pouco menos. Isso é muito comum na AWS, pois eventualmente ajuda a afastar os clientes com hardware de geração mais antiga ao longo do tempo. Mas nem sempre é o caso …
Você deve ter notado no exemplo acima que m4.large e m5.large fornecem a mesma quantidade exata de vCPU (2), mas isso significa que a velocidade da vCPU será a mesma? A resposta é não. Mesmo se você tomar uma decisão de escalar baseando-se em uma única métrica como a vCPU (não deveria!), como é que você sabe qual é o melhor tipo de instância a ser usado para garantir que a CPU esteja obtendo exatamente o que precisa?
Para determinar a velocidade do clock da CPU em nuvens públicas, você deve usar a ECU (EC2 Compute Unit – ECU) da Amazon ou a ACU (Azure Compute Unit – ACU). Você já tentou determinar a velocidade real da vCPU de um tipo de instância de nuvem usando ACU ou ECU? Dica: não é muito amigável ao ser humano.
Por fim, a maneira mais precisa para dimensionar corretamente uma carga de trabalho, especialmente de missão crítica, requer uma percepção da demanda de aplicativos, coletando e analisando métricas importantes de aplicações, como heap, threads e tempos de resposta, ao determinar qual capacidade deve ser dimensionada. Se você dimensionar corretamente uma carga de trabalho baseada em Java com base nas métricas vCPU ou vMem, poderá entrar em um caminho espinhoso.
- Você precisa de um time grande para gerenciar as RI (Reserved Instance) em escala
O RI é uma das melhores maneiras de reduzir custos em nuvens públicas. Em alto nível, as RIs permitem que os usuários desfrutem de descontos significativos em comparação com os preços sob demanda (até 75% na AWS e 72% no Azure), fazendo compromisso de longo prazo para um período de 1 ou 3 anos, para uma certa quantidade de capacidade pré-paga.
Para aproveitar realmente a economia que as RIs oferecem, você deve se assegurar de utilizar o seu pool de RI no nível mais alto possível, escalando as cargas de trabalho para tipos de instâncias que correspondam às suas RIs existentes, caso contrário você estará perdendo dinheiro duas vezes: primeiro, quando não estiver usando uma RI, a qual você já pagou, o que significa que está deixando dinheiro na mesa; e a segunda é quando você tem uma carga de trabalho em execução usando a oferta On-Demand / PAYG enquanto houver um RI que possa ser usada.
O gerenciamento de RI é ainda mais complexo quando você possui mais de uma conta na nuvem. Você sabia que pode compartilhar e usar o RI entre contas da AWS no mesmo grupo de cobrança? Você já considerou a complexidade de fazer isso, quando possui mais de uma conta da AWS?
Comprar novas RIs e gerenciá-las se tornará incontrolável em escala. Considerando o fim do contrato de RI, as alterações dinâmicas na demanda das cargas de trabalho, entender os custos entre os diferentes tipos e termos da RI e, ao mesmo tempo, tentar atingir as metas da organização para a cobertura da RI, tornam essas tarefas impossíveis. Há vários casos de empresas que tinham equipes de especialistas em nuvem e em finanças designados para essas atividades em período integral, que não conseguiram atingir seus objetivos.
Como descrito acima, o gerenciamento de RI e o dimensionamento de cargas de trabalho são métodos complicados. Se você combinar os dois, rapidamente perceberá que é quase impossível fazer as duas coisas em paralelo (não apenas para humanos, mesmo para a maioria das ferramentas de otimização de nuvem).
- Não se esqueça da otimização de armazenamento
Outro aspecto que requer otimização constante é o armazenamento usado pelas VMs. Os fornecedores de nuvem oferecem várias camadas de armazenamento, cada uma com seus próprios recursos. Por exemplo, na AWS, os volumes EBS são oferecidos em quatro camadas io1, gp2, st1 e sc1, cada uma oferecendo um nível diferente de IOPS, taxa de transferência, tamanhos, modelo de burst (possibilidade de dar ao usuário uma maior velocidade por um espaço definido de tempo) e custo. Para aproveitar totalmente alguns dos benefícios, a instância deve estar usando um tipo de instância otimizado para EBS.
O aspecto interessante das modificações da camada EBS é que, em geral, isso pode ser feito sem tempo de inatividade para a instância, mas ainda existem várias limitações que devem ser consideradas ao alternar entre camadas e elas diferem se o volume for de raiz ou de dados. Há também um limite que requer aguardar 6 horas entre as modificações.
Há também o aspecto de poder modificar a capacidade de IOPS de uma camada EBS (em vez de modificar para uma nova camada), mas é necessário dimensionar o tamanho do volume.
- Gerenciar o desperdício com nuvem em escala é desafiador
Os recursos da nuvem pública são “utilitários”, você paga pelo que usa, assim como a eletricidade. Por exemplo, se você sair de casa para passar férias, é preciso garantir que as luzes não estão acesas, se ninguém estiver em casa.
Na nuvem, há duas áreas com as quais você deve se concentrar para reduzir o desperdício:
- Identificar e suspender cargas de trabalho inativas ou suspender cargas de trabalho após o expediente (normalmente sem produção), por exemplo, suspender uma carga de trabalho entre 18h e 6h trará economia de 50%; e
- Identificar e excluir o armazenamento desassociado. Isso pode adicionar dezenas de milhares de reais por mês à conta da nuvem, dependendo da camada de volumes, tamanho e quantidade total de volumes desassociados.
Muitas organizações optam por usar scripts simples para suspender e retomar VMs com base em uma programação, mas em algum momento, conforme o ambiente muda, a manutenção e a atualização desses scripts se tornarão um esforço demorado.
O problema de armazenamento desassociado é bastante comum. Muitos usuários destroem instâncias e às vezes se esquecem de excluir volumes associados, e as empresas serão cobradas por esses volumes, independentemente de serem usados ou não.
- Espere, tem mais …
Otimize não apenas VMs básicas (IaaS). Você provavelmente executa mais do que apenas VMs na nuvem, se estiver utilizando PaaS de banco de dados, como RDS ou SQL no Azure, ou mesmo aproveitando os serviços de contêiner gerenciado, como EKS ou AKS, precisará ser capaz de coletar métricas, analisar os dados e executar ações. Você precisa entender as nuances de cada serviço PaaS para realmente otimizá-lo.
A otimização eficaz às vezes significa não fazer nada e às vezes demanda uma série de ações. Por exemplo, os seres humanos podem ver uma métrica de carga de trabalho exceder um limite e tentar escalar, mas isso nem sempre é a coisa certa se a instância estiver usando uma computação ou armazenamento em burst. Uma série de exemplos de ações significaria dimensionar uma instância com RI para um tipo de instância OD com bom custo-benefício, apenas para liberar o RI, para que possa ser usado em uma instância que se beneficiará mais dele.
Conclusão
Nenhum ser humano pode otimizar as cargas de trabalho na nuvem de forma eficaz em escala, porque é muito complexo, demorado e deve ser feito continuamente se você realmente deseja otimizar seus custos na nuvem daqui para frente.
Os especialistas em nuvem são caros, será um desperdício de tempo e dinheiro tentar contratar especialistas para otimizar. Será mais lógico designar o especialista em nuvem para ajudar na inovação dos negócios e se concentrar nas atividades de geração de receita, e deixar que uma plataforma corporativa comprovada faça a otimização. Uma solução adequada permitirá reduzir o número de especialistas em nuvem necessários para operar sua nuvem, melhorar a produtividade da equipe de Cloud Ops e ajudar a aumentar a proporção de VMs / Admin.
Tem um projeto em mente? A Leadcomm é uma empresa especializada em performance de aplicações corporativas e segurança de dados sensíveis, que atua há mais de 20 anos focada na distribuição e integração de soluções inovadoras.
Disponibilize a visão analítica do seu ambiente virtualizado de forma totalmente automatizada e em tempo real. Gerencie o consumo de recursos de hardware dos workloads virtualizados e garanta a melhor distribuição dos mesmos, baseado em conceito de oferta, demanda e preço.
Os desafios para estruturação e execução do seu projeto podem ser superados com o acompanhamento de uma consultoria experiente, para desenvolver uma estratégia e um planejamento adequados, que oriente tanto as decisões referentes às soluções técnicas e conceituais, visando atender as necessidades corporativas com o melhor retorno sobre o investimento. Fale conosco.
Comments are closed.
Comentários