Cloud

Economia de custos da AWS EC2

Com base em relatórios recentes divulgados pelos principais fabricantes, o uso da computação em nuvem pública no ano de 2017 está em torno de US$ 130 bilhões. Adicionado a isso uma taxa de crescimento de cerca de 19%. Muitas empresas estão rapidamente mudando para a nuvem na esperança de obter o benefício da escalabilidade e redução de custos. Mas, logo após a migração ou a adoção inicial, estão percebendo que a economia da nuvem relacionada à economia de custos não está funcionando como esperado.

E porque isso ocorre ? Uma razão bem simples para isso, é que muitos utilizam a abordagem unica de economia, imaginando que pequenos usos, ou adoções de desligamento, ou mesmo construção automática de servidores como abordagem funcionam. E isso simplesmente não é verdade. O mindset para nuvem é totalmente diferente, e poucos percebem isso.

Muitos que hoje trabalham com nuvem, concordam que não existe uma abordagem unica para economia, ou mesmo segurança. Por quê? Devido à variedade de serviços em nuvem e possíveis arquiteturas de implantação em nuvem adotadas pelas empresas em conjunto com as particularidades de cada aplicação. Este principio embora focado neste artigo em particular para o AWS EC2 pode ser adotado para nuvens diversas de todos os fabricantes.

Por exemplo, para uma empresa que usa o AWS EC2 para sua hospedagem na nuvem, haverá ambientes diferentes, com código de produção em execução em algumas instâncias do AWS EC2, alguns outros executando testes de controle de qualidade, mais algumas instâncias do EC2 para atividades de DEV etc. Esses possíveis cenários de implantação diferentes exigem necessidades operacionais diferentes, pois a principal razão pela qual digo que uma solução de otimização de custos, não produzirá a melhor otimização possível na economia da nuvem.

Exemplo 1
Instâncias do AWS EC2 executando o código de produção. As empresas gostariam de executá-las 24/7 na maioria dos casos, porque qualquer atraso no acesso aos aplicativos resultaria em perda de receitas, que as empresas não gostariam de experimentar. Que tipo de otimização pode ser feita neste cenário?

Dimensionamento de capacidade correta
Como essas instâncias precisam ser executadas 24 horas por dia, 7 dias por semana, a primeira coisa que precisamos verificar é se esses servidores EC2 estão sendo usados ​​até a capacidade ideal? Os usuários podem ter alugado uma grande capacidade para hospedar seu aplicativo, mas o aplicativo em execução nesses servidores usando apenas 50% da CPU, o que significa que eles são muito subutilizados. Com base nos seus requisitos específicos, escolher os de tamanho apropriado eliminará alguns dos resíduos.

O dimensionamento correto é a técnica de otimização de custos mais negligenciada e menosprezada. As equipes podem se beneficiar usando ferramentas como o AWS Trusted Advisor para entender o uso de recursos e provisionar adequadamente as instâncias do EC2. Também é interessante utilizar um software de monitoramento nativo como o CloudWatch ou mesmo opções terceiras.

Instâncias Reservadas
Com base na documentação da AWS, as Instâncias do Amazon EC2 reservadas, fornecem um desconto significativo (até 75%) em comparação com o sistema de preços On-Demand. Se você tem certeza de que precisa de uma instância por um ano, as instâncias reservadas são a melhor opção, pois isso economiza uma boa quantia de dinheiro na conta do AWS EC2.

Grupos de Auto Scaling
Essa é outra opção melhor que você poderia explorar para provisionar mais instâncias do EC2 quando houver alta carga e reduzir instâncias ativas quando a carga estiver baixa. Você poderia usar esquemas diferentes fornecidos pela AWS para configurar quando a AutoScale. Mas por favor não configure o Auto Scaling puramente para ter duas instâncias porque “sua aplicação precisa”. Lembre-se, se você configura o Auto Scaling desta forma, tem algo errado com o modo que você usa a nuvem.

A combinação de “dimensionamento de capacidade correta” e “instâncias reservadas EC2 (RI)” ajudará as empresas a reduzir o desperdício nos gastos do AWS EC2. Mas, esses mesmos princípios podem ser aplicados a outros ambientes de implementação, como DEV, servidores de controle de qualidade, etc.

Exemplo 2
Diversas empresas possuem ambientes diferentes a produção, como QA / DEV ou qualquer outra configuração em que o aplicativo não seja necessário para ser executado sempre. Como essas instâncias do EC2 não precisam estar no estado ON para sempre, manténha o “Amazon EC2 RI” fora do jogo ok ? Outros ainda podem argumentar que até 70% de economia com o RI, portanto, opte por eles. Aqui estão alguns argumentos:

  • Quando você opta pelo RI, você está se inscrevendo para uma concessão de prazo predefinida, para que você tenha o ônus de uma concessão ou revenda.
  • As necessidades de capacidade de infraestrutura podem aumentar ou diminuir ao longo do tempo
  • Casos em que não há alterações frequentes nos aplicativos, a concessão de servidores por um ano inteiro em que o uso é limitado a alguns meses em um ano é um gasto desnecessário na nuvem

Sejamos honestos. Ambientes diferentes de produção muitas vezes são totalmente desconhecidos pela empresa, ou mesmo pelo time de testes, então, sinceramente, porque investir pesadamente neles ? Crie apenas quando necessários. Deste modo você verá a diferença econômica.

Dimensionamento de capacidade correta
A técnica de dimensionamento correto pode ser aplicada neste caso de configuração QA / DEV. Qualquer que seja o tipo de implantação, essa otimização sempre economiza dinheiro na conta de instâncias do EC2.

Ativar os recursos SOMENTE quando necessário:

  • Além de escolher a capacidade apropriada, outro ponto importante a observar é limitar o tempo de ativação das instâncias do EC2

Devido ao fato de que esses servidores EC2 não são necessários em execução contínua, a melhor técnica de otimização é limitar o tempo apenas ao tempo necessário, em vez de continuar executando-os, seja agendado ou sempre ligado.

Porque (a maioria dos) recursos da nuvem serão cobrados por segundo, deixando as instâncias do EC2 em funcionamento quando ninguém usá-las não ajudará na redução da fatura da AWS. Com base em um recente estudo da RightScale, somente em 2017, cerca de US $ 10 bilhões em gastos na nuvem foram desperdiçados e uma das principais razões para o desperdício foram instâncias ociosas.

Assim como praticamos a economia em nossa vida diária, desligue as luzes quando não há ninguém na sala para economizar eletricidade. Desligando os motores dos carros quando não estão dirigindo para economizar, as empresas podem economizar custos de hospedagem ao encerrar as instâncias quando ninguém acessa o aplicativo hospedado nelas e as atualiza APENAS quando os usuários usam os aplicativos.

Uma das empresas de prática comum atualmente em dia é usar os agendadores do AWS EC2 para limitar o tempo de ocorrência das instâncias do AWS EC2 a janelas específicas, como o desligamento durante a noite, ou mesmo durante o dia. Lembre-se do que falei acima, muitas empresas não sabem como utilizar ou mesmo divulgar os ambientes de testes. Embora essas soluções ajudem a salvar algumas faturas da AWS EC2, essas soluções não são ideais.

Grupos de Auto Scaling: novamente, essa NÃO é uma abordagem de otimização aplicável para essas instâncias do DEV / QA EC2, porque o caso de uso real para escalonamento automático está suportando cargas imprevisíveis e elasticidade de suporte. Exceto nos casos em que nossa exigência é testar a funcionalidade de dimensionamento automático (ou) o teste de manipulação de carga, não há necessidade de aumentar ou diminuir esses servidores, portanto, essa opção também não é aplicável aqui.

Em resumo, há uma distinção clara entre o motivo pelo qual algumas otimizações funcionam em configurações de implantação que não são de 24 horas, mas não funcionam na produção e vice-versa. As equipes precisam escolher abordagens corretas aplicáveis ​​ao meio ambiente.