REX

Retours d’expériences Big Data en entreprise
YSANCE - ARKENA
LES ENJEUX D’UNE PLATEFORME BIG DATA TEMPS RÉEL POUR ARKENA
CONTEXTE
Arkena, commercialise une plateforme permettant de distribuer des contenus audio et vidéo sur tous les écrans
(Streaming Web, Mobile, Box, B2B, etc.)
Ces contenus sont transmis via plusieurs technologies, en particulier un CDN internet qui repose sur de nombreux
serveurs à travers le monde. Ces serveurs génèrent de très grande quantité de logs, actuellement utilisés pour
monitorer le CDN, mais aussi pour déterminer la facturation client selon l’usage.
Avec l’augmentation du nombre des clients et de la volumétrie diffusée, l’architecture en place de collecte et traitement
de ces logs (Rsyslog, Postgresql, Java), ne permettait plus d’assurer les services attendues (Supervision,
Alerting, Analyse et facturation).
Arkena souhaitait donc remplacer ce système par une architecture hautement scalable, facile à maintenir et disposant
d’un faible TCO.
ENJEUX TECHNIQUES
• Collecte et stockage des logs en temps réel (+ de 60 000 logs par seconde)
• Archivage des logs sur au moins 3 ans
• Calcul au fil de l’eau de plus de 300 KPI (Mise à jour toutes les minutes)
• Mise à disposition de ces indicateurs via des appels API REST
• Garantir que chaque ligne de log sera intégrée une et une seule fois
• Remplacer Rsyslog par une solution plus fiable pour la collecte et la centralisation des logs depuis 30 datacenters
et en garantissant l’acquittement de réception de chaque log.
• Offrir un très haut niveau de disponibilité, des mécanismes de reprises sur erreur et une forte capacité de montée
en charge
ARCHITECTURE
L’architecture mise en place par Ysance est de type “Lambda” et repose sur trois stacks techniques :
Spark pour les traitements temps réel, MapReduce pour les traitements Batch et Elasticsearch pour la couche
présentation.
• Vitesse : La couche temps réels reposent sur Apache Spark, et calculent les KPI sur une fenêtre de temps d’une
minute (agrégation de 3,6M de logs / mn). L’objectif est d’alimenter au plus vite la couche de restitution avec des
indicateurs qui ne nécessitent pas de retraiter l’ensemble de l’historique des données.
• Batch : La couche Batch vise à créer une vision définitive, et si nécessaire corrigée des données traitées par la
couche de vitesse (en cas d’arrivée trop tardive, de redémarrage du process temps-réel, …), ainsi qu’à calculer les
KPI nécessitant de traiter un historique de données plus long. (dans le cas de la dimension temps, les aggrégats
à l’heure, journée, semaine, mois, …) Elle repose sur le moteur MapReduce, au travers de Hive ou de développement
spécifiques Java.
• Présentation : La couche de présentation réconcilie les données traitées par la couche vitesse et la couche
batch, et permet ainsi d’analyser et d’aggréger dans un même dashboard des données issues de Spark et de
Hive. Cette couche repose sur Elasticsearch, qui offre la possibilité d’appliquer des aggrégats au requêtage, et
permet ainsi de sommer, de compter distinctement, etc… sur l’ensemble des données, avec des temps de réponse
inférieurs à la seconde.
• Transport : La couche transport repose sur Apache Flume. L’objectif est de collecter en streaming l’ensemble
des lignes de logs vers la plateforme Hadoop, sans provoquer de blocage applicatif. La communication entre les
agents Flume présents sur les edge et ceux qui écrivent sur le cluster Hadoop est effectuée par appel RPC / Avro.
Document réalisé par la Société Corp Events - Janvier 2015
130