Comment Netflix optimise les coûts de son infrastructure de données
(netflixtechblog.com)En raison de l’architecture d’infrastructure distribuée de Netflix et de sa culture interne de « liberté et responsabilité », l’optimisation est une tâche assez difficile. L’entreprise a donc développé des tableaux de bord sur mesure afin d’offrir de la transparence sur les coûts et de placer le contexte lié à l’optimisation au plus près des décideurs.
Comment ce « tableau de bord d’efficacité des données » a été créé, ainsi que les enseignements tirés
- Environnement de la plateforme de données de Netflix : peut être classé en deux catégories
-
Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid
-
Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto
** Visibilité de l’usage et des coûts en un coup d’œil **
Les coûts de toutes les plateformes sont agrégés, en conservant les informations permettant de les découper en unités pertinentes.
→ Unités : table, index, column family, job, etc.
La source de ces informations de coût repose essentiellement sur les données de facturation AWS classées par service et par tag, mais cela seul ne permet pas de distinguer les ressources ou les équipes. Les méthodes suivantes ont donc été utilisées :
- Plateformes basées sur EC2
→ Définition, pour chaque plateforme, des métriques de goulot d’étranglement (bottleneck metrics)
→ Par exemple, Kafka est limité par le réseau, tandis que Spark est limité par le CPU et la mémoire.
→ En s’appuyant sur Atlas, les logs de plateforme et les API REST, les métriques sont distinguées pour chaque ressource et les coûts sont attribués en conséquence.
- Plateformes basées sur S3
→ Un préfixe S3 est attaché à chaque ressource, puis le coût par ressource est calculé sur la base du prix du stockage
- Vue du tableau de bord
Utilisation d’un tableau de bord personnalisé basé sur Apache Druid pour attribuer chaque coût aux équipes.
Les principaux utilisateurs de ces informations de coût sont les équipes d’ingénierie et data, afin qu’elles puissent agir à partir de ces données.
En complément, une vue de plus haut niveau est fournie aux responsables engineering.
Selon le cas d’usage, il est possible d’afficher les données groupées par ressource data ou par organisation, et de les consulter sous forme de snapshots ou de séries temporelles
** Recommandations automatisées de stockage - Time to Live (TTL) **
Dans certains scénarios, l’objectif va au-delà de la transparence et inclut aussi des recommandations d’optimisation.
Le stockage de données est très utilisé et présente un fort effet d’inertie des coûts (on stocke puis on oublie),
l’analyse permettant de déterminer automatiquement la durée optimale de conservation (TTL) a donc été automatisée à partir des modèles d’usage des données.
Les recommandations TTL ont été appliquées aux tables d’entrepôt big data sur S3
- Calcul des coûts et logique métier
Les plus gros coûts S3 proviennent des tables transactionnelles, généralement partitionnées par date
Les logs d’accès S3 et le mapping entre préfixes S3 et partitions de tables permettent de déterminer quelles partitions datées sont consultées.
Les activités d’accès (lecture/écriture) sur les 180 derniers jours sont examinées afin d’identifier la durée maximale de lookback.
Cette durée de lookback détermine la valeur TTL de la table.
À partir de ce TTL calculé, les économies annuelles réalisables sont estimées
- Vue du tableau de bord
Les propriétaires des données peuvent visualiser en détail les modèles d’accès, comparer la valeur TTL recommandée à la valeur actuelle, et voir les économies potentielles
** Communication et sensibilisation des utilisateurs **
La consultation des coûts data ne doit pas devenir une tâche quotidienne pour les équipes techniques, surtout lorsqu’il s’agit de coûts sans réelle valeur.
Une fonctionnalité d’alerte par e-mail a donc été développée pour sensibiliser uniquement les équipes ayant une forte consommation de données.
De plus, des recommandations TTL sont automatiquement envoyées uniquement pour les tables présentant un potentiel d’économies.
À l’heure actuelle, ces e-mails sont envoyés chaque mois
** Enseignements et défis **
- Identifier et maintenir les métadonnées de chaque actif est essentiel pour l’allocation des coûts
→ Pour cela, un référentiel de métadonnées appelé Netflix Data Catalog (NDC) a été construit
→ Il facilite l’accès et la recherche de données, ce qui permet de gérer aussi bien les données existantes que les nouvelles
→ NDC est utilisé comme point de départ du calcul des coûts
- Les données de tendance dans le temps sont un défi
→ La gestion des données de tendance est bien plus lourde que celle des snapshots
→ Il est difficile de fournir une vue cohérente en raison des incohérences de données et de la latence de traitement
→ Deux problèmes ont dû être résolus
→ - Changement de propriété des ressources : dans les snapshots, les changements de propriété doivent être reflétés automatiquement, tandis que dans les vues en série temporelle, même ces changements doivent être pris en compte dans les métadonnées
→ - Perte d’état en cas de problème de données : les métadonnées des ressources étant extraites via API depuis diverses sources, un échec pendant la collecte entraîne une perte d’état. Comme ces données sont temporaires, l’extraction par API seule a ses limites. Il faut envisager des alternatives, comme l’envoi des données vers Keystone
** Conclusion **
Lorsqu’on dispose d’une plateforme de données hautement distribuée, un tel tableau de bord peut considérablement améliorer l’efficacité en créant une boucle de feedback et en unifiant le contexte d’usage et de coût.
Lorsque c’est possible, il faut aller plus loin avec des recommandations automatisées pour améliorer l’efficacité.
Dans le cas de Netflix, la recommandation sur la durée de rétention des données a montré un ROI élevé.
Grâce à ce tableau de bord et aux recommandations TTL, l’espace de stockage de l’ensemble du data warehouse a pu être réduit de plus de 10 %.
2 commentaires
Il s’avère que les fonctionnalités de recommandation n’étaient pas réservées aux seuls spectateurs.
C’est sympa. J’ai vu quelque part une étude disant que si l’on pouvait observer un appareil de surveillance en temps réel, on pouvait aussi faire bouger des muscles involontaires, et cela m’y a soudain fait penser.