Gerenciando custos na AWS: A jornada do Nubank

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.SUMMIT
Gerenciando Custos na AWS:
A jornada do Nubank
Arthur Basbaum
Cloud Financial Mgmt
AWS
CMP202
Luis Diniz
Business Architect
Nubank
Brunno Santos
Software Engineer
Nubank

A nuvem mudou a forma como os times de
TI & Finanças colaboram

Modelo tradicional de compras de TI
Engenheiros
Compras

Modelo tradicional de compras de TI Computação em Nuvem

Será necessário investir tempo e recursos
Coletar dados
Processar &
Analisar Executar
Olá

Boas intenções nunca funcionam,
você precisa de bons mecanismos
para fazer qualquer coisa acontecer
Jeffrey P. Bezos
Founder and Chief Executive Officer
Amazon.com, Inc.

SUMMIT © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Cloud Financial Management (CFM) Framework
FinOps
pessoas, processos
& ferramentas
Otimizar
Custos
elasticidade, right
sizing e modelos de
pagamento
Visibilidade
alocação de
custos, relatórios
e métricas
Previsibilida
de
budget e forecast

Estabeleça uma cultura de transparência de
custos e prestação de contas para garantir
a correta visibilidade dos seus gastos
deve ser feito logo no início para dar mais
controle à medida que seu consumo cresce
na AWS
Visibilidade

1º Pilar: Visibilidade
Cloud Financial Managament Framework
Estratégia para
Consolidação de
contas
Relatórios de
custos
Métricas de
sucesso
Alocação de custos
(tags)

AWS Organizations: Estratégias de Consolidação
Unidade de negócios Ciclo de vida Projeto

AWS Organizations: Estratégias de Consolidação
TAGS
Cost allocation tags
Ambiente
Projeto
Time
Application ID
Centro de Custo

Usando tags para visibilidade e chargeback
Stakeholder Nome da Tag Exemplo Descrição Mandatório Contas
Finanças Centro de Custos 4374
Centro de custo responsável por esses
recursos
Sim Todas
Finanças e TI Ambiente Dev Tipo de ambiente Sim Todas
TI Responsável Ricardo Pessoa responsável por esses recursos Sim Todas
TI Contato 1425365xxxx
Telefone e email do responsável pelos
recursos
Não Todas
Finanças Projeto Aurora Nome do projeto Não Apenas PROD
TI Data_Validade Fev 2020 Data esperada para encerramento do projeto Não Todas
Segurança e TI Suporte Time Alfa Time responsável por suportar esses recursos Sim Apenas PROD
https://aws.amazon.com/answers/account-management/aws-tagging-strategies/

Conhecendo o AWS Cost Explorer
AWS Cost Explorer permite que a sua organização
tenha visibilidade sobre o seu padrão de consumo,
como por exemplo mapear os principais serviços mais
utilizados e identificar anomalias ou gastos
inesperados.
• Custo mensal ou diário, por serviço, linked
account, tags, região e etc
• Horas utilizadas de EC2 por tipo de instância,
linked account, tags e modelo de preço
• Relatórios para gerenciamento de Instâncias
Reservadas: Cobertura e Utilização
Todas essas funcionalidades também podem ser
acessadas através da API do Cost Explorer.

Agrupe por: tipo de máquina, linked
account, modelo de compra, região,
serviço entre outros…
Período a ser analisado,
assim como formato
diário ou mensal
Custo (acima, agrupado por tipo de
máquina e consumo em horas (abaixo)
Filtros para remover dados
que não são relevantes
para a sua análise
Você também pode exportar para csv
Opções avançadas, excluir valores
relacionados a créditos, refunds,
suporte e etc
Tudo isso também pode ser acessado através da API do Cost Explorer
© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.

O que é sucesso para a sua organização?
Métricas relacionadas a AWS
% máquinas desligadas (elasticidade)
% cobertura Instâncias Reservadas (RI)
% horas RI utilizadas
$ economizado
$ recursos sem tags
# recursos idle
Métricas relacionadas ao seu negócio
$ por Usuário ou Transação
$ por Impressão ou Click
$ por Aplicação ou Unidade de Negócio
$ por Receita gerada
$ por desenvolvedor (benchmarking)
# horas por $ investido

Faça você mesmo: relatórios customizados

Utilize nossa rede de parceiros

Garanta que a sua organização pague o
mínimo necessário para manter seu
negócio funcionando
Identificação de recursos subutilizados e
desperdício, revisão de arquiteturas para
que seja possível combinar a demanda de
capacidade com a necessidade do negócio
Otimizaçã
o de
Custos

2º Pilar: Otimização de Custos
Escolha tamanho
adequado para
suas máquinas
Maximize
elasticidade
Explore os
modelos preço
disponíveis
Serverless

On Demand (OD)
Demanda instável, ainda
desconhecida
Pague apenas pelo o que
você usar
Pague por segundo sem
compromisso
Instâncias Reservadas (RI)
Demanda estável, uso
previsível
Até 75% mais barato que
o modelo OD
Compromisso de 1 ou 3 anos e
receba um desconto significativo
Spot
Demanda flexível,
stateless
Aprox. 90% mais barato
que o modelo OD
Capacidade ociosa, baixo
custo e sem compromisso
Modelos de Preço da AWS

Instâncias Reservadas (RI): Características
Modelos de Preço da AWS
No Upfront
Partial Upfront
All Upfront
Amazon EC2
Amazon RDS
Amazon Redshift
Amazon ElastiCache
Amazon Elasticsearch Service
Amazon DynamoDB
Amazon CloudFront
1 ano (payback 7–9 meses)
3 anos (payback 10–18 meses)

Instâncias Reservadas: Padrão vs Conversível

Instancias reservadas Linux, regionais e com tenancy
shared terão seus descontos aplicados automaticamente
entre todos os tamanhos da família reservada, dentro da
mesma região
Instâncias Reservadas: Flexibilidade Automática
1x c4.8xlarge 1x64 fator normalização
=
=
=
16x c4.large 16x4 fator normalização
Disponível para EC2 Linux e Amazon RDS MySQL, MariaDB, PostgreSQL e Amazon Aurora

Instâncias Reservadas: Guia de Economia
MaisMenos
Pagamento No Upfront Partial Upfront All Upfront
Duração (Anos) 1 3
Sist. Operacional Não-Linux Linux/Unix
Instância Antigas Gerações Novas Gerações
Tipo Conversível Padrão
$ Economia $

Benchmark: On Demand, RI e Spot mix
RI OD SP RI OD Spot RI OD Spot
Enterprise tradicional Varejo Media

Recomendação de Instâncias Reservadas
• Disponível para payer e linked account
• Recomendação para os seguintes serviços:
• Amazon EC2 (Padrão e Conversível)
• Amazon RDS
• Amazon Redshift
• Amazon ElastiCache
• Amazon Elasticsearch
AWS Cost Explorer: Recomendação de RI

Relatório de Instâncias Reservadas (RI)
• Relatório de cobertura de RI – quantas horas de
EC2 estão cobertas por RI vs Spot e On Demand
• Relatório de utilização das RIs existentes,
incluindo economia atingida – qual o % de
horas utilizadas e quanto isso representou em
economias (custo OD menos custo RI)
• Relatórios com Amortização de RI
• Disponível para reservas do Amazon EC2,
Amazon RDS, Amazon Redshift, Amazon
ElastiCache, e Amazon Elasticsearch
AWS Cost Explorer: Relatório de Utilização das RIs

Busque aperfeiçoar o processo de forecast
criando maior precisão no planejamento
financeiro da sua organização
Importante que o time financeiro tenha
visibilidade sobre os investimentos com a
AWS e esteja preparado para projetar custos
futuros de acordo com o crescimento do
negócio
Previsibilida
de

3º Pilar: Previsibilidade
Forecast
(novas demandas)
Forecast
(atual)
Budget

AWS Budgets

Forecast: AWS Cost Explorer

Forecast: Novas Aplicações e Projetos
Precificar
(budgets?)
Validar quando
será implementado
Validar arquitetura
(right sizing?)

Estabeleça de forma gradual (porém firme) a
ideia de que todos são responsáveis pelos
custos gerados, desenvolva automação
para garantir controle em escala
FinOps

4º Pilar: FinOps
AutomaçãoCultura orientada a
custos
Parceria entre TI e
Finanças

Engenheiros FinançasFinOps
Reativo Proativo Data Insight
Não me mostre quanto foi gasto,
me mostre o % consumido com
relação ao budget planejado
Crie confiança,
Eu tenho um plano de investimentos
e estou monitorando isso
Parceria entre Finanças e TI é fundamental para o
sucesso dessa atividade

Se você quer que algo aconteça, simplifique

Quem é o Nubank? Cartão de crédito suportado
por uma experiência
completamente digital e
sem agências
Um programa de
recompensas
completamente diferente
de todas as experiências
no mercado brasileiro
Nossa própria versão
de uma conta
bancária, mais simples
e inteligente
Nubank hoje é o maior banco digital do
ocidente e nasceu para eliminar a
complexidade e possibilitar que seus clientes
tenham melhor controle sobre seu dinheiro
$480 M de investimento recebido
8.5 M de clientes
30M já aplicaram para o cartão de crédito
4.8M de contas abertas
Eleita a empresa mais inovadora da América Latina

Jornada Nubank – desenvolvendo gestão de custos de
nuvem em um ambiente de hypergrowth
2015/2016: Primeiras
compras de RIs, muito
conservadoras, realizadas
por engenheiro que tinha
alguma experiência com
RIs
2017.1: Financeiro começa a
demandar métricas/visibilidade
de custos de AWS e pedir
explicações para desvios
2017.2: Contratamos
alguém para cuidar de
custos de AWS full time
2018.1: Low hanging fruits
(RIs e recursos idle).
Logo depois deep dive em
temas mais complexos,
right sizing de Amazon
EC2, DynamoDB e S3,
revisão de tags
2018.2: Maior demanda
por previsibilidade de
custos (melhoria no
processo de budget)
Migração para Kubernetes
e perda de visibilidade
automática de custos
Para onde estamos indo?
• Desafios de
escalabilidade, foco em
performance e
estabilidade

Métricas de Sucesso
Métricas de negócio: Custo por cliente é a principal métrica que
utilizamos para avaliar sucesso das iniciativas de otimização de custos
• Com o crescimento de outros produtos, passamos a acompanhar
também custo por cliente de produtos específicos
Métricas AWS:
• Cobertura de RIs por tipos de recursos: serviços, kafka, datomic
• % de recursos untagged: principalmente para tags de SQUAD
• % de serviços dentro da recomendação de rightsizing

Agenda
1) Criação da disciplina de gestão de custos de AWS no Nubank
2) Primeira fase de otimização estruturada
3) Evolução dos processos financeiros
4) Gestão de custos com infraestrutura rodando Kubernetes
5) Próximos passos da jornada

Custos com AWS começou a crescer demais,
chamando atenção do time de finanças

FinOps em ação: Time financeiro começou demandar
bastante tempo da engenharia
Como funciona o custo de AWS? Conseguimos negociar desconto por volume?
O que são RIs? Qual é a vantagem de antecipar o pagamento?
Quanto estamos gastando por equipe?
Quem está contribuindo mais para esse aumento de custo?
Quanto devemos gastar de AWS no próximo ano?
Quanto gastamos por cliente?
Você pode me ajudar a entender os custos de AWS para esse novo produto?

Primeiro passo foi dar visibilidade e accountability
sobre os recursos utilizados na AWS
Custos cresciam, mas sem
visibilidade dos drivers
Tags definidas com base na
arquitetura da infraestrutura
Environment: ambiente ao qual o
recurso estava relacionado (produção,
testes, analytics, etc)
Service: microsserviço ao
qual o recurso está
dedicado
Squad: equipe
responsável pelo
recurso
Shard: grupos de recursos de
infraestrutura para atender um
determinado grupo de clientes

Automatização nos ajudou a aumentar proporção de custos taggeados1 de
~70% para ~90% em 3 meses
1 Considerando apenas recursos taggeáveis e tag de SQUAD
Service
Environment
Shard
Squad
Implementamos e automatizamos as tags para todos
os recursos possíveis, por meio de receitas de deploy

Enquanto evoluíamos nas tags, buscamos contratar
alguém para focar 100% na gestão de custos de AWS
Dificuldade de definir o perfil: deveria ser um
engenheiro de software? Alguém de finanças? Um
analista de negócios?
Definiu-se um Business Architect, cuja principais
atribuições seriam:
• Gestão dos custos e comunicação com Finanças para
facilitar entendimento de variações e alocação de
custos no negócio
• Planejar e executar ações de otimização de custo:
RIs, rightsizing, avaliação de elasticidade,
desperdícios, etc
• Acompanhamento de questões contratuais

AWS tem grande interesse em ajudar os clientes a otimizar custos – apoio em
todo o processo desde definição da estratégia de tags até a identificação dos
problemas
1 mês de onboarding com materiais internos,
públicos e equipe AWS
• 2 Sessões de imersão
com SA da AWS
• Conversas constantes com equipe AWS
• Vídeos re:Invent
• Treinamentos internos
• Apoio Dedalus (parceiro AWS)
Objetivo: conhecer pricing model dos serviços que
utilizamos e como identificar oportunidades
Início das
atividades
de
otimização
de custos
Após contratação, houve necessidade de investir
tempo na preparação para assumir o trabalho

Ferramentas / bases utilizadas Iniciativas priorizadas
Relatórios AWS
Cost Explorer
Planilhas
Impacto em preço:
- Compra de capacidade reservada (RI)
Impacto em uso:
- Acompanhamento próximo às equipes do
Nubank (30% das equipes correspondiam a
~90% do custo)
- Mudança na arquitetura de infraestrutura
(kubernetes)
Impacto em visibility/accountability:
- Eliminar tag “shared”
- 100% de recursos com tag “squad”
Decidimos também contratar a Cloudability para acelerar execução das iniciativas e
proporcionar acompanhamento mais autônomo por parte dos times
Primeira atividade foi um diagnóstico para priorização

Estratégia para EC2
Premissa gerais:
- Comprar apenas RIs “Convertible”
- Reservar apenas 1 ano
- Utilizar “Region” vs. AZ
Grupos de análise:
- Instâncias que seriam afetadas pelo
kubernetes
- Instâncias de datomic
- Instâncias de Kafka
- Instâncias de Zookeeper
Ferramentas utilizadas
Para EC2, desenvolvemos nossa própria ferramenta
Para os demais serviços (RDS, Elasticache e
Redshift), seguimos recomendações da
Cloudability, com target de 80% da capacidade
Compra de RI: ferramenta própria para planejamento
de RIs de EC2 e Cloudability para demais serviços

Estamos mantendo um nível de cobertura de reservas
próximo a 80%, com 100% de utilização

Processo Tipos de oportunidade Como identificamos
• 8 squads priorizados: um engenheiro
definido como ponto focal em cada
• Reuniões mensais para identificar
oportunidades e acompanhar execução
• Preparação prévia para reuniões:
• Entendimento do contexto de
negócio do time
• Principais serviços AWS
• Principais microserviços do time
(identificados via tags)
• Construção de dashboard
customizado no Cloudability
• Premissa inicial: otimizar sem risco de
prejudicar a operação
Análise única para todos os times:
• Instâncias não utilizadas
• EBS órfãos
Análise específica para cada time:
• Instance size ou número de
instâncias superprovisionados
• Tabelas DynamoDB
superprovisionadas
• Ausência de lifecycle policy no S3
• Código não otimizado
• AVG CPU 7 dias < 10%
• EBS com State = “Available”
• Max CPU diário / por hora e
comparação entre shards
• Comparar uso vs. capacidade
provisionada vs. Throttles
• Entrevistas / S3 Analytics
• Entrevistas com engenheiros
Acompanhamento dos times: reuniões mensais para
priorizar iniciativas e acompanhar execução

Utilizamos bastante a ferramenta para detecção de
anomalias do Cloudability

Cobrança sobre desvios do orçamento de AWS nos
levou a criar um processo mais elaborado
Orçamento top-down com
base no custo por cliente e
estimativa de otimização
Acompanhamento
principalmente por custo de
cada equipe
Orçamento bottom-up com
inputs da engenharia,
finanças, growth e produtos
Acompanhamento
principalmente por
ambientes e shards

Estruturação do budget em pedaços da infraestrutura
Ambiente de produção Ambiente analítico
Staging
Testes automatizados
Shard1
Shard2
ShardN
Global
Monitoramento
ProjetosdeInfra
...
Segurança
Serviços “horizontais”
Dentro de cada bloco, o custo pode ser alocado para diferentes equipes e produtos

Construção do budget envolve inputs de diversas
áreas, revisado a cada trimestre
Crescimento orgânico
Crescimento inorgânico
Budget de AWS
Projeção de # clientes
Projeção de # funcionários
Novos projetos de tecnologia
Novos produtos e features
Otimizações (RIs, right-sizing)
Experimentação
Projeção de métricas de uso

Após novo budget, precisão de forecast melhorou de
30% de desvio para 5-10% por semestre
Quarter/Year Mês 1 Mês 2 Mês 3
Q3/2018 99.5% 99.6% 91.5%
Q4/2018 99.5% 94.5% 80.9%
Q1/2019 99.42%
OKR: Build a 3 months forecast for AWS
monthly costs with 90% of accuracy

Migração para Kubernetes tinha como principal
objetivo ganho de produtividade de engenharia
Melhorar velocidade de deploys: subir container vs. subir instância EC2
● Ciclo de iteração de desenvolvimento mais rápido
● Mais velocidade para se recuperar de incidentes
● Processo de atualização de infraestrutura mais rápido

Expectativa era que também houvesse melhoria na
utilização de recursos, impactando custos
Situação anterior Expectativa Kubernetes
m4.2xlarge
Aplicação 1
m4.xlarge
Aplicação
2
m4.large
Aplicação
3
m4.2xlarge
Aplicação 1
m4.xlarge
Aplicação 2
m4.large
Aplicação 3
35%
CPU
80%
CPU
50%
CPU
80%
CPU
Exemplo ilustrativo
Instância
EC2
Container

Antes Agora
Migração conservadora: mantida quantidade de
recurso das máquinas que os serviços rodavam

Custos na verdade aumentaram:
incompatibilidade JAVA
Testes em staging → redução de custos de 30% com Kubernetes
Testes em prod → redução de custos também de 30%, mas com graves problemas de performance
● Hipótese principal é a incompatibilidade da versão JAVA que estávamos utilizando (JDK 8) com
configurações de containers
● Incompatibilidade prejudica scaling dos containers (request = limit)
Solução temporária para o problema de performance levou a aumento dos custos em 25% para a
nova infraestrutura
● Há um projeto hoje para atualização do JDK que utilizamos

● Deploys 3x mais rápidos (Economizando entre 40 e 60 horas por dia de todo time de
engenharia - temos 50+ deploys diários) além de redução do MTTR
● Redução do tempo de atualização da infraestrutura pela metade (economizando $80k
por atualização)
● Ciclo de desenvolvimento e iteração mais rápido, maior sentimento de produtividade
Apesar dos custos, continuamos a migração, uma vez
que os principais objetivos foram atingidos

Migração para Kubernetes impossibilitou visualização
e alocação de custos por tags
Situação anterior Kubernetes
tag = Equipe A
Aplicação 1
tag = Equipe B
Aplicação 2
tag = Equipe C
Aplicação 3
tag = Equipe
Platform
Aplicação 1
Aplicação 2
Aplicação 3
Instância
EC2
Container
Uma instância EC2
suporta uma tag, mas
agora possui serviços
de múltiplas equipes

Cloudability nos ajudou a coletar dados de custos e
uso de containers, mas perdemos automação

Além da visualização de custos, foi necessário
mudanças também no processo de rightsizing

Processo anterior de rightsizing (análises)
Processo:
- Coletar dados de reports da AWS
- Realizar tratamento dos dados
- Para cada equipe:
- Criar Dashboards no Cloudability para
visualizar e analisar tendências
- Avaliar maiores oportunidades entre os
serviços da equipe
- Organizar e realizar apresentação para
engenheiros da equipe
Problemas:
Perda de dados após migração para
Kubernetes
Processo não escalável
- Número crescente de equipes
- Novos serviços surgindo o tempo todo

Processo:
- Participar da apresentação das análises
- Reservar tempo para executar as
recomendações:
- Revisar recomendações
- Criar Pull Request para trocar os workloads de
cada serviço em cada shard
- Mergear Pull Request após outros engenheiros
terem revisado alterações
- Rodar comando de atualização de infra para
enviar mudanças para produção
Processo anterior de rightsizing (implementação)
Problemas: fricção no processo
- Ações não eram priorizadas porque tomava muito
tempo para serem realizadas
- Execução das recomendações levava até 60 dias
após a primeira reunião

Utilizamos Prometheus e Thanos para coletar dados
de uso

Script para automatizar etapas de rightsizing
Com automação desses passos, conseguimos reduzir a fricção do processo e
o ciclo de rightsizing passou de ~45–60 dias para ~7–14 dias
- Coletar dados de reports da AWS
- Realizar tratamento dos dados
- Criar Dashboards no Cloudability para
visualizar e analisar tendências
- Avaliar maiores oportunidades entre os
serviços da equipe
- Organizar e realizar apresentação para
engenheiros da equipe
- Criar Pull Request para trocar os workloads
de cada serviço em cada shard
- Mergear Pull Request após outros
engenheiros terem revisado alterações
- Rodar comando de atualização de infra
para enviar mudanças para produção
- Rodar comando
$ nu service right-size [nome do serviço]
- Mergear Pull Request após outros
engenheiros terem revisado alterações
- Rodar comando de atualização de infra
para enviar mudanças para produção

Output do script de rightsizing: PR alterando
workload conforme utilização real
Recomendação:
workloads para cada
shard conforme
padrão de uso
Workload
atual

Processo de rightsizing antes x depois
$ nu service right-size [service name]

Jornada de otimização não é linear

Custo de AWS por cliente Nubank (index ago/2017 = 100)
Out/17: Lançamento
da NuConta
Jan-Mar/18: Início de
otimizações com
squads
Out-Nov/18:
Migração para
Kubernetes
Abr/19: Recorde de
número de novos
clientes em um mês
Dez/18: Lançamento
do cartão de débito
Mar/19: Preparação
para aumento no ritmo
de crescimento
Fev/19: Lançamento
de Empréstimos
Pessoais
~90 serviços 250+ serviços

Melhorar processo de rightsizing para abranger outras partes da
infraestrutura (Amazon DynamoDB, Datomic, Kafka) e considerar
escalamento horizontal
Criação de serviço para apagar automaticamente recursos não utilizados
Possibilitar que times vejam custos de AWS na ferramenta padrão de BI,
em conjunto com todos os dados de negócio
Com clara alocação e visibilidade para equipes de produtos, há maior
incentivos para que liderem ações de otimização de custos
Desafio: garantir que RIs estejam corretamente alocadas, uma vez que
controlamos tudo via tags; automatizar integração com custos de k8s
Foco agora é em garantir escalabilidade das ações de
otimização de custos
Melhorar
visibilidade das
equipes
Automatizar
processos de
otimização de
custos

Para o futuro, esperamos utilizar instâncias Spot
Principais desafios:
● Permitir mais flexibilidade nas configurações dos clusters de Kubernetes
(aceitar grande diversidade de tipos e tamanhos de instâncias)
● Alterar nossas receitas de deploy para considerar instâncias spot e definir
fallbacks

• Onde sua org
está na
jornada de
custos?
Identificar
• Como medir
sucesso?
Quantificar
• Quais são os
quick wins?
Priorizar
• Teste e
realize a
atividade
Executar
• Valide os
retornos
esperados
Medir
Comece devagar, experimente, celebre as vitórias e automatize tudo o que for possível
Busque apoio da AWS e da nossa rede de parceiros

Obrigado!
Arthur Basbaum
Cloud Financial Mgmt
AWS
basbauma@amazon.com
Luis Diniz
Business Architect
Nubank
Luis.diniz@nubank.com.br
Brunno Santos
Software Engineer
Nubank
Brunno.santos@nubank.com.br
Por favor, responda a pesquisa
ao final da sessão no app. Ao
finalizar, passe no Help Desk e
retire seu brinde!

Gerenciando custos na AWS: A jornada do Nubank

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Gerenciando custos na AWS: A jornada do Nubank

Semelhante a Gerenciando custos na AWS: A jornada do Nubank (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Gerenciando custos na AWS: A jornada do Nubank