Douglas Picolotto

Olá, pessoal! Tudo bem?

Hoje vamos falar sobre o último pilar da nossa série sobre o Well-Architected Framework, o Cost Optimization Pillar. Este pilar possui as melhores práticas para tirarmos o máximo da infraestrutura, atendendo a demanda, com o menor custo possível.

Princípios de Design

• Adotar um modelo de consumo: Ambientes de nuvem permitem que utilizemos apenas os recursos necessários para manter os requisitos do negócio, variando conforme a necessidade, impactando diretamente em seu custo;
• Avaliar a eficiência global do sistema: Medindo a eficiência do sistema, ou seja, o valor entregue versus o custo para entregar este valor, podemos avaliar os ganhos ao mexermos em alguma destas duas dimensões (valor e custo);
• Parar de gastar com operações de datacenter: Na nuvem não precisamos nos preocupar com custos de infraestrutura (instalações, energia elétrica, etc), pois o provedor de nuvem faz toda essa gestão para nós, permitindo que mantenhamos o foco no negocio e nos clientes;
• Analisar e atribuir despesas: Podemos facilmente identificar e atribuir custos à área de negócio responsável;
• Utilizar serviços gerenciados para reduzir custos: Provedores de nuvem oferecem uma série de serviços gerenciados que podemos utilizar para suprir a necessidade de nós mesmos os provisionarmos. Devido a sua escala global e muitas vezes a opção de pagar só pelo tempo utilizado, eles podem a sair mais baratos.

Abaixo falaremos um pouco sobre a utilização de recursos economicamente viáveis, evidenciando cada aspecto apresentado no guideline.

Recursos economicamente viáveis

A recomendação no guideline é definirmos um padrão arquitetural para nosso workload, e refinar suas configurações e tipos de recursos baseados em métricas extraídas do mesmo. Além disso, os tópicos abordados sobre economia de recursos:

• Provisionamento apropriado: Devemos provisionar a quantidade ótima de recursos para a plena operação do workload, nem mais, nem menos. Na AWS, os serviços gerenciados possibilitam facilmente modificações na capacidade (inclusive de forma automática), para ajustar-se a demanda. Podemos também otimizar o aproveitamento de recursos agregando aos mesmos múltiplos sub-recursos. Como por exemplo, múltiplos bancos de dados a uma instância do RDS;
• Dimensionamento correto: O dimensionamento correto implica em utilizarmos o recurso com menor custo, mas que atenda efetivamente a demanda e as necessidades do negócio;
• Opções de compra: Na AWS, temos várias opções de compra para EC2 (on-demand, spot, reserved, fleet), com custos variados. Devemos utilizar a que mais se adapte ao nosso negócio;
• Seleção geográfica: Não selecionar a mesma região para operarmos o workload, pode impactar no custo, pois existe um preço pela transferência entre datacenters. É importante também avaliarmos qual região iremos utilizar, para garantir a melhor experiência para os usuários da solução, com o menor custo possível (o custo pode variar de região, para região);
• Serviços gerenciados: Se avaliarmos o custo por hora de um serviço gerenciado, comparando ao provisionamento manual de tal serviço (como um banco de dados MySQL), podemos concluir que o serviço gerenciado é mais caro do que a solução manual, porém, esse valor pode ser ilusório, visto que além do custo dos recursos, teremos o custo da administração da estrutura e o tempo de profissionais alocados. Energia que poderia ser facilmente convertida em atividades para agregar valor ao produto. Por isso, sempre que possível, serviços gerenciados são a recomendação;
• Otimização de transferência de dados: Por fim, devemos ficar atentos quanto ao custo em transferência de dados. Precisamos utilizar estratégias para reduzi-lo, como a utilização de CDNs e conexões dedicadas (para nuvem híbrida).

Alguns serviços recomendados na AWS são:

• Amazon CloudWatch: Permite coletarmos métricas e logs, facilitando a identificação de otimizações em recursos à serem feitas;
• Trusted Advisor: Faz análises sobre os recursos provisionados dando indicações sobre otimizações a serem feitas;
• Cost Explorer: Possibilita a análise dos custos de todos os recursos provisionados, facilitando a identificação de padrões na utilização dos mesmos e áreas a serem otimizadas;
• Amazon Route 53: Quando temos a solução provisionada em múltiplas regiões, o Route 53, permite configurarmos a resolução do DNS para responder a região com a menor latência para o usuário;
• Amazon CloudFront: Permite a entrega de conteúdo estático e dinâmico com menor latência aos usuários, através da estrutura de pontos de presença (Edge Locations) da AWS;
• AWS Lambda: Permite a utilização de recursos computacionais, pagando apenas pelo que é usado (sem ociosidade);
• Spot/Reserved instances: Dependendo do padrão de utilização de instâncias EC2, podemos utilizar instâncias reservadas ou instâncias spot para reduzir consideravelmente o custo destes recursos.

Corresponder capacidade e demanda

Outro ponto importante a ser considerado quando falamos em custo, são as estratégias para adequarmos a capacidade provisionada e a demanda. Devemos sempre atender a demanda com o menor custo possível, evitando desperdiçar recursos, já que, na nuvem, pagamos pelo que usamos. Dependendo do cenário, temos algumas opções para tratar esta relação:

• Baseado em demanda: Dependendo do tempo de adequação da capacidade necessário (warm up) e das variações no padrão da demanda, podemos utilizar a capacidade elástica dos recursos da nuvem, para escalarmos determinado componente, afim de manter a resposta do sistema. De forma automática, isso geralmente ocorre usando o Auto Scaling. Esse modelo é o mais comum atualmente;
• Baseado em buffer: Em cenários onde a resposta de determinado serviço não for necessariamente imediata, temos a opção de usar um mecanismo de mensagens entre um produtor e consumidor, com o custo de adição de um pouco de complexidade. Esta estratégia tende a eliminar backpressure caso os consumidores não tenham a capacidade de processar o fluxo entregue pelos produtores, além de manter a estabilidade do sistema;
• Baseado em tempo: Quando o padrão da demanda é consistentemente previsível (como picos ocorrendo sempre em determinado horário, blackfriday, etc), podemos variar a capacidade no momento exato ou antecipadamente, evitando delays devido a inicialização de recursos.

Alguns dos serviços sugeridos pelo guideline para atendermos cada cenário citado, seguem abaixo:

• AWS Auto Scaling: O Auto Scaling permite o ajuste da capacidade de recursos com base nas variações da demanda, evitando custos desnecessários;
• Elastic Load Balancing: Pode ser utilizado para distribuir a carga entre diversos recursos (Containers/EC2), permitindo a escala automática dos mesmos;
• Amazon CloudWatch: Pode ser usado para identificarmos variações na demanda através de métricas, permitindo a resposta automática a estas variações;
• Amazon SQS/Amazon Kinesis: São serviços de mensagens gerenciados que podem ser usados para desacoplar produtor e consumidor;
• AWS Lambda: FaaS é o modelo que tende a ser mais econômico em muitos cenários, justamente por ser cobrado pelo tempo utilizado, sem cobrar por recursos ociosos. Portanto é uma excelente opção para utilizarmos como consumidor de mensagens;
• Amazon EC2 Spot Instances: Como no mercado de ações, permite que façamos lances de preços sobre os recursos computacionais da AWS, possibilitando grande economia em alguns cenários;

Continua…

Por hoje era isso, pessoal! O encerramento será no próximo post.

Abraços e boa semana!