Infrastructures Big Data : une troisième voie est possible

Pour soutenir leurs applications Big Data, les entreprises ont aujourd’hui le choix entre deux voies. Soit recourir aux principaux clouds proposés par Microsoft, Amazon ou encore Google. Des infrastructures qui associent des capacités de stockage et de calcul à des technologies propriétaires et compliquent – voire rendent impossible - la réversibilité. Soit s’appuyer sur des technologies plus standards pour concevoir une infrastructure capable de répondre aux enjeux de la Big Data : performance et volume.

Sans surprise, les entreprises qui nous consultent depuis quelques années pour infogérer leurs infrastructures Big Data et les fiabiliser ont opté pour la deuxième option. Mais les bilans qu’elles nous dressent ont une fâcheuse tendance à se ressembler. Surdimensionnés, onéreux et complexes à maintenir, ces projets Big Data ont souvent laissé un goût amer… Et cherchent encore leur modèle : celui qui permettra a minima d’équilibrer les investissements et les bénéfices issus de la valorisation des données.

Péché originel des projets Big Data : miser sur des pétaoctets de données

À l’origine de ces désillusions, un même raisonnement, une même conception inadaptée. Car ces infrastructures, inspirées par celles des géants du web, ont été d’abord pensées pour accueillir de larges volumes de données – nous parlons ici de pétaoctets (Po) – avec des niveaux de disponibilité très élevés, et cela à une époque où le stockage coûtait plus cher qu’aujourd’hui. Le résultat ? Des architectures qui empilent les serveurs et des serveurs qui accueillent directement les disques de stockage, un des principes de ce modèle étant de disposer d’au moins 3 copies des données. Ce « modèle de référence » d’architecture Big Data s’est vite heurté à la réalité des entreprises – celles qui ne sont pas des GAFAMs…

De quelle « réalité » parlons-nous ici ? Si les entreprises, convaincues que leurs données valent de l’or, se sont d’abord ruées sur les grandes capacités, leurs besoins réels sont tout autres. Les entreprises n’ont pas des Po de données à engranger ; le projet Big Data moyen avoisine plutôt les 50 To. Ce qui, tout le monde peut le comprendre, change radicalement la donne en matière de conception d’infrastructure.

Ce péché originel – la quête des Po – et le fait que les compétences Big Data ne courent pas les rues ont conduit les clients à s’en remettre aux grands cabinets de conseil. Lesquels ont joué la carte de la sécurité en recommandant les architectures héritées des grands acteurs du web. À la décharge des clients et des cabinets de conseil, reconnaissons qu’il est bien délicat – pour ne pas dire hasardeux – d’évaluer les volumes de données requis dans les projets Big Data.

Repenser le modèle d’infrastructure Big Data

Face à cette réalité, nous nous sommes lancés il y a 5 ans déjà dans un vaste chantier R&D. L’objectif : repartir d’une page blanche pour dessiner une architecture Big Data moderne. Qu’entendons-nous par « moderne » ? À nos yeux, 3 principes doivent s’appliquer.

• Proposer du stockage à l’usage, pour faciliter une évolutivité fine de la capacité, par paliers, donc avec une lisibilité claire des incréments et des budgets associés.
• Dissocier stockage et puissance de calcul, donc ne pas loger les disques dans les serveurs, cela afin de conserver une architecture souple et évolutive, mais toujours performante et disponible.
• Garantir la réversibilité, l’idée ici consistant à ne pas s’enfermer dans du code propriétaire, même si, soyons honnêtes, des adaptations seront toujours nécessaires.

Nos travaux d’alors – nous sommes en 2016 – nous conduisent à acter que la solution passe par un stockage forcément distribué et sur support Flash qui, contrairement à quelques idées reçues, ne s’avère pas moins fiable dans nos tests que le stockage mécanique. Le prototype conçu par notre R&D nous apporte bien les performances attendues mais s’avère complexe à opérer. Pas si simple de réinventer un système qui atteigne les performances requises pour des projets Big Data sans placer de stockage dans les serveurs. C’est à ce moment que notre route croise celle de PureStorage et de sa solution Flashblade.

Flashblade, une baie qui cache un réseau

En concevant Flashblade, PureStorage a poursuivi des objectifs semblables aux nôtres et avec un état d’esprit très proche : en l’occurrence, partir d’une feuille blanche pour fournir une solution de stockage affichant un rapport coût/capacité maîtrisé et une performance élevée sans contraindre à distribuer le stockage dans les nœuds de calcul. Résultat, un châssis qui accueille des unités de stockage Flash sous la forme de lames, l’ensemble s’appuyant sur une architecture réseau intégrée (ce qui, au passage, génère de grosses économies côté câblage).

En résumé, si la solution s’apparente à une baie de stockage, dans les faits elle se rapproche davantage d’un réseau de stockage intégré. En quelque sorte, un NAS avec les performances d’un SAN distribué. Soit… exactement ce que nous cherchions à concevoir mais réalisé ici dans une approche évidemment plus industrielle.

Soyons francs, une telle architecture peut interroger ceux qui sont en quête d’une solution Big Data sur au moins sur 3 points :

• « La solution se présente sous une forme centralisée (une baie) là où les architectures Big Data renvoient à des architectures distribuées… »
  • En apparence, oui. Sauf que les baies Flashblade intègrent un réseau de stockage. Côté performance, nous avons mesuré que chaque lame peut envoyer 4 à 5 Go/s (soit 30-40 Gbps) vers les serveurs.
  • Ajoutons aussi que recourir à une solution centralisée peut questionner si les volumes se comptent en pétaoctets. Mais pour des téraoctets, même par centaines, (soit la réalité des volumes de la grande majorité des projets Big Data), ce choix n’a rien de déraisonnable.

• « La solution exploite du stockage Flash. Bien raisonnable pour du Big Data ? »
  • Là encore, pour des pétaoctets, le choix pourrait être questionné. Mais pour des téraoctets, les lames Flash s’avèrent pertinentes pour la performance comme pour le coût, d’autant plus en 2023.

• « Un projet Big Data doit forcément exploiter HDFS, or, la solution Flashblade parle d’abord NFS »
  • La Big Data et les suites Hadoop sont en effet associés au protocole HDFS qui reste incontournable lorsque chaque nœud doit pouvoir récupérer des données d’un autre nœud. Mais les suites Hadoop sont aussi conçues pour fonctionner avec des disques locaux. Et lorsque Flashblade met son contenu à disposition des serveurs via NFS, les applications Big Data y accèdent comme… à des disques locaux.
  • La solution FlashBlade permet aussi de stocker et accéder aux données en mode objet avec le protocole S3, qui est disponible nativement dans les outils Hadoop, plus performant que HDFS et avec des fonctionnalités supplémentaires notamment concernant la taille maximale des objets ainsi que leur accès facilité par des outils tiers. Ce protocole est annoncé comme le successeur de HDFS.

Anticipons enfin une autre remarque possible : « Cette solution ne s’inscrit pas dans les recommandations formulées habituellement par les cabinets de conseil ». Oui, et nous assumons le fait que ce choix peut sembler « exotique ». Rappelons simplement que les investissements - souvent très lourds - qui ont découlé de ces recommandations ont conduit à des impasses, avec des projets qui n’ont jamais permis de valoriser les données à la hauteur des attentes initiales.

Faut-il persister ? À chacun de répondre.

Comment budgetbox capitalise sur ses données de parcours clients

Certains ont déjà tranché, comme budgetbox, qui nous a accordé sa confiance. L’entreprise aide les distributeurs comme les marques à engager les consommateurs tout au long d’un parcours éminemment omnicanal. Parmi les solutions proposées, un moteur de recommandation produit. Des recommandations pertinentes… À condition de capitaliser sur les millions d’activités enregistrés au quotidien. En 3 années, budgetbox a ainsi emmagasiné plusieurs téraoctets de données sur les parcours clients.

Après une période de POC durant laquelle l’entreprise a pu comparer la performance de sa plateforme existante avec celle proposée par Oxeva, la bascule est actée. « La solution d’Oxeva nous permet de décorréler le calcul et le stockage. Nous pouvons donc ajouter du stockage sans toucher au calcul et inversement, observe Hugo Martineau, responsable du pôle Infrastructure de budgetbox. C’est très pratique pour l’évolutivité de la plateforme, et dans un contexte Big Data cela fait une vraie différence ».