Cómo Netflix optimiza los costos de su infraestructura de datos
(netflixtechblog.com)Debido a la estructura de infraestructura distribuida de Netflix y a su cultura interna de "libertad y responsabilidad", optimizar la eficiencia era una tarea bastante difícil, por lo que desarrollaron dashboards personalizados para ofrecer transparencia de costos y mantener el contexto relacionado con la eficiencia cerca de quienes toman decisiones.
Cómo construyeron este "dashboard de eficiencia de datos" y las lecciones aprendidas
- Entorno de la plataforma de datos de Netflix: se puede clasificar en dos categorías
-
Data at Rest: Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid
-
Data in Motion: Keystone, Flink, Mantis, Spark, Kafka, Presto
** Visibilidad de uso y costos de un vistazo **
Reúnen los costos de todas las plataformas, incluyendo información que permite desglosar cada costo en unidades significativas.
→ Unidades: tablas, índices, familias de columnas, jobs, etc.
La fuente de esta información de costos depende básicamente de la facturación de AWS clasificada por servicio y etiquetas, pero como eso por sí solo no permite distinguir por recurso/equipo, usan métodos como los siguientes.
- Plataformas basadas en EC2
→ Definen para cada plataforma las métricas de cuello de botella (bottleneck metric)
→ Por ejemplo, Kafka está limitado por la red, mientras que Spark está limitado por CPU y memoria.
→ Usan Atlas, logs de la plataforma y APIs REST para distinguir las métricas de cada recurso y asignar costos.
- Plataformas basadas en S3
→ Asignan un prefijo de S3 a cada recurso y calculan el costo por recurso con base en el precio del almacenamiento.
- Vista del dashboard
Usan un dashboard personalizado basado en Apache Druid para asignar cada costo a los equipos.
Los principales usuarios de esta información de costos son los equipos de ingeniería y datos. Se les entrega para que puedan tomar acciones basadas en ella.
Además, a los líderes de ingeniería se les ofrece una vista de nivel más alto.
Según el caso de uso, es posible agrupar y ver la información por unidad de recurso de datos o por unidad organizacional, y consultar los datos tanto en snapshots como en series temporales.
** Recomendaciones automatizadas de almacenamiento - Time to Live (TTL) **
En algunos escenarios, además de ofrecer transparencia, también proporcionan recomendaciones de optimización.
Como el almacenamiento de datos tiene mucho uso y también un gran impulso de costos (como cuando se guarda algo y luego se olvida),
automatizaron el análisis para determinar el periodo óptimo de almacenamiento (TTL) con base en los patrones de uso de los datos.
Aplicaron recomendaciones de TTL a las tablas del data warehouse de big data en S3.
- Cálculo de costos y lógica de negocio
El mayor costo en S3 proviene de las tablas transaccionales, que por lo general están particionadas por fecha.
Usando los access logs de S3 y el mapeo de prefijo S3 a partición de tabla, pueden determinar qué particiones por fecha se consultan.
Observan la actividad de acceso (lectura/escritura) de los últimos 180 días y verifican el máximo lookback.
Ese valor de lookback determina el TTL de la tabla.
Con base en ese TTL calculado, estiman el ahorro anual alcanzable.
- Vista del dashboard
Los dueños de los datos pueden ver patrones detallados de acceso, comparar el valor recomendado de TTL frente al actual y confirmar también el posible ahorro de costos.
** Comunicación y notificación a los usuarios **
Revisar los costos de datos no debería convertirse en una tarea cotidiana para los equipos técnicos, especialmente si se trata de costos de datos poco significativos.
Por eso desarrollaron una función de alertas push por email solo para los equipos con alto uso de datos, para elevar la conciencia sobre los costos de datos.
Además, envían automáticamente valores recomendados de TTL solo para las tablas con potencial de ahorro de costos.
Actualmente, estos emails se envían cada mes.
** Lecciones y desafíos **
- Identificar y mantener el metadata de cada activo es clave para la asignación de costos.
→ Para ello construyeron un repositorio de metadata llamado Netflix Data Catalog (NDC).
→ Al facilitar el acceso y la búsqueda de datos, permite gestionar tanto datos existentes como nuevos.
→ Usan NDC como punto de partida para el cálculo de costos.
- Los datos de tendencias en el tiempo son un desafío.
→ Los datos de tendencias implican una carga de gestión mucho mayor que los snapshots.
→ Debido a inconsistencias de datos y latencia de procesamiento, es difícil ofrecer una vista consistente.
→ Tuvieron que resolver dos retos.
→ - Cambios en la propiedad de los recursos: en los snapshots, los cambios de propiedad deben reflejarse automáticamente, y en la vista de series temporales incluso esos cambios deben reflejarse en el metadata.
→ - Pérdida de estado cuando ocurren problemas de datos: como el metadata de los recursos se extrae de varias fuentes mediante APIs, si falla la recolección se pierde el estado. Como estos datos son temporales, la extracción vía API por sí sola tiene límites. Deben buscar alternativas, como enviar los datos hacia Keystone.
** Conclusión **
Si se tiene una plataforma de datos altamente distribuida, crear un ciclo de retroalimentación mediante este tipo de dashboards e integrar el contexto de uso y costos puede mejorar mucho la eficiencia.
Si es posible, también conviene mejorar la eficiencia mediante recomendaciones automatizadas.
En el caso de Netflix, recomendar periodos de retención de datos mostró un ROI alto.
Con este dashboard y las recomendaciones de TTL, lograron reducir en más de 10% el almacenamiento de todo el data warehouse.
2 comentarios
Al parecer, la función de recomendaciones no era solo para los espectadores.
Está bien. Vi en algún lado una investigación que decía que, si se pudiera ver una máquina de monitoreo en tiempo real, hasta los músculos involuntarios podrían moverse, y de repente me acordé de eso.