Como a Netflix torna os custos da infraestrutura de dados mais eficientes
(netflixtechblog.com)Devido à estrutura de infraestrutura distribuída da Netflix e à cultura interna de "liberdade e responsabilidade", a otimização era uma tarefa bastante difícil. Por isso, a empresa desenvolveu dashboards personalizados para oferecer transparência de custos e manter o contexto relacionado à eficiência próximo de quem toma decisões.
Como esse "dashboard de eficiência de dados" foi criado e os aprendizados obtidos
- Ambiente da plataforma de dados da Netflix: pode ser classificado em duas categorias
-
Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid
-
Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto
** Visibilidade de uso e custos em um só lugar **
Os custos de todas as plataformas são agregados, incluindo informações que permitem decompor cada custo em unidades significativas.
→ Unidades: tabelas, índices, column families, jobs etc.
A fonte dessas informações de custo depende basicamente dos dados de billing da AWS classificados por serviço e tags, mas isso sozinho não permite distinguir por recurso/equipe, então foram usados métodos como os seguintes:
- Plataformas baseadas em EC2
→ Definir, por plataforma, métricas de gargalo (bottleneck metric)
→ Por exemplo, Kafka é limitado por rede, enquanto Spark é limitado por CPU e memória.
→ Usar Atlas, logs da plataforma e APIs REST para distinguir métricas por recurso e alocar custos
- Plataformas baseadas em S3
→ Atribuir um prefixo S3 a cada recurso e calcular o custo por recurso com base no preço de armazenamento
- Dashboard View
Usando um dashboard personalizado baseado em Apache Druid, cada custo é atribuído a uma equipe.
Os principais clientes dessas informações de custo são as equipes de engenharia e de dados, para que possam agir com base nelas.
Além disso, líderes de engenharia recebem uma visão de nível mais alto.
Dependendo do caso de uso, é possível visualizar os dados agrupados por unidade de recurso de dados ou por unidade organizacional, tanto em snapshots quanto em séries temporais
** Recomendação automatizada de armazenamento - Time to Live (TTL) **
Em alguns cenários, a solução vai além da transparência e também oferece recomendações de otimização.
Como o armazenamento de dados tem alto uso e grande inércia de custo (dados ficam guardados e acabam sendo esquecidos),
foi automatizada uma análise que determina o período ideal de armazenamento (TTL) com base nos padrões de uso dos dados.
A recomendação de TTL foi aplicada a tabelas do data warehouse de big data no S3
- Cálculo de custos e lógica de negócio
Os maiores custos de S3 vêm de tabelas transacionais, que normalmente são particionadas por data
Usando logs de acesso do S3 e o mapeamento de prefixo S3 para partição de tabela, é possível determinar quais partições por data foram acessadas.
Observando a atividade de acesso (leitura/escrita) dos últimos 180 dias, é possível identificar o maior período de lookback.
Esse período de lookback determina o valor de TTL da tabela.
Com base nesse TTL calculado, é estimada a economia anual viável
- Dashboard View
Os donos dos dados podem ver padrões detalhados de acesso aos dados e comparar o valor recomendado de TTL com o valor atual, além de verificar a economia potencial
** Comunicação e divulgação para os usuários **
Verificar custos de dados não deve se tornar uma atividade cotidiana das equipes técnicas, especialmente quando se trata de custos de dados sem sentido.
Por isso, foi desenvolvida uma função de notificação por e-mail direcionada apenas às equipes com maior uso de dados, para aumentar a conscientização sobre custos de dados.
Além disso, recomendações automáticas de TTL são enviadas apenas para tabelas com potencial de redução de custos.
Atualmente, esses e-mails são enviados mensalmente
** Lições e desafios **
- Identificar e manter os metadados de cada ativo é importante para a alocação de custos
→ Para isso, foi construído um repositório de metadados chamado Netflix Data Catalog (NDC)
→ Isso facilita o acesso e a busca de dados, permitindo gerenciar tanto dados existentes quanto novos
→ O NDC é usado como ponto de partida para o cálculo de custos
- Dados de tendência ao longo do tempo são desafiadores
→ Dados de tendência têm um custo de gerenciamento muito maior do que snapshots
→ Devido a inconsistências de dados e latência de processamento, é difícil fornecer uma visão consistente
→ Foi necessário resolver dois desafios
→ - Mudança de ownership dos recursos: no snapshot, as mudanças de ownership devem ser refletidas automaticamente; já na visualização de séries temporais, até mesmo essas mudanças precisam ser refletidas nos metadados
→ - Perda de estado quando ocorrem problemas de dados: como os metadados dos recursos são extraídos de várias fontes via API, falhas durante a coleta causam perda de estado. Como esses dados são transitórios, há limites no uso apenas de extração via API. É preciso buscar alternativas, como enviar os dados para o Keystone
** Conclusão **
Se você tem uma plataforma de dados altamente distribuída, criar um loop de feedback com esse tipo de dashboard e integrar o contexto de uso e custo pode melhorar bastante a eficiência.
Sempre que possível, a eficiência deve ser aumentada por meio de recomendações automatizadas.
No caso da Netflix, recomendar o período de retenção de dados mostrou um ROI elevado.
Com esse dashboard e as recomendações de TTL, foi possível reduzir em mais de 10% o espaço de armazenamento de todo o data warehouse.
2 comentários
Pelo visto, os recursos de recomendação não eram só para os espectadores.
Legal. Vi em algum lugar uma pesquisa dizendo que, se for possível observar uma máquina de monitoramento em tempo real, até músculos involuntários podem se mover; isso me veio à cabeça de repente.