[Dossier] BigData : Cloud versus On Premises

1. Objectif de l’étude

Le BigData est l’un des domaines où le Cloud est en forte croissance (cette démarche allant de pair avec le Machine Learning et l’IoT). Les fournisseurs de Cloud, étant conscients des perspectives financières, sont en train de se lancer dans une véritable course à l’armement sur ce terrain.

AWS, Azure, Google et IBM proposent tous une gamme de produits permettant la réalisation de projets BigData dans le Cloud.

Cette étude vise à :

  • Comparer les implémentations BigData “On Premises” et dans le Cloud
  • Lister les points d’attention
  • Établir dans quel cas il est pertinent d’opter pour l’un ou l’autre

2. Synthèse

cloud-vs-on-premise

Il y a extrêmement peu de bonnes raisons d’implémenter aujourd’hui un projet BigData on premises.

Le BigData dans le Cloud permet :

  • L’agilité : On peut démarrer un cluster le temps de réaliser une analyse ou une expérience et s’en débarrasser une fois celle-ci terminée, ce qui n’est pas concevable en “On premises” où les délais d’approvisionnement peuvent être de plusieurs semaines. Dans le Cloud, il n’y a pas de CapEx, on ne paye que pour les ressources qu’on consomme. Il est possible si on le souhaite, de lancer un cluster Hadoop de 1000 noeuds pour une heure. Ici aussi, rien de comparable n’existe “on premises”
  • L’élasticité : Si un cluster est utilisé de façon irrégulière, il est possible d’en réduire facilement la taille, ou de l’arrêter entièrement.

L’inquiétude sur la sécurité du BigData dans le Cloud n’est ni plus ni moins légitime que pour tout autre projet dans le Cloud i.e : à l’heure d’aujourd’hui il est devenu difficile de démontrer que la sécurité de l’infrastructure du Cloud provider est moins sécurisée que son propre Datacenter.

Toutefois, on peut toujours préférer le “on premises” pour certains cas, même si les fournisseurs Cloud cherchent à les adresser. Quelques exemples :

  • Si le reste de l’infrastructure n’est pas dans le Cloud, le transfert des données vers le Cloud peut poser problème: Il existe toutefois toujours des moyens de transférer des gros volumes de données soit en one-shot, soit en continu
  • Si les données sont confidentielles, on peut ne pas vouloir les exporter vers un fournisseur de service Cloud : Les fournisseurs Cloud s’engagent toutefois fortement en apportant des garanties en termes de sécurité des données, et disposent de nombreuses certifications. La plupart disposent de datacenters Européens, et vont en ouvrir en France en 2017 si ce n’est pas déjà fait.
  • Si on souhaite procéder à un tuning ou à une configuration particulière du cluster, qui ne serait pas supportée par le Cloud provider

L’un dans l’autre, la recommandation sera donc d’implémenter les projets BigData dans le Cloud plutôt qu’on premises, sauf si une contre-indication particulière se présentait.

3. Le bigdata : Définition des termes utiles

Le terme « bigdata » peut signifier beaucoup de choses pour différentes personnes.

Sans chercher à être exhaustif, ce chapitre vise à clarifier les termes qui seront utiles à la compréhension du reste du document.

Par BigData, on entend une analyse de données couvrant au moins deux des 3 aspects suivants (“les trois V”) :

  • Velocity : La vitesse (typiquement en nombre d’événements par secondes) à laquelle l’ingestion de la donnée doit se faire
  • Variety : La diversité des données (sources, formats, …)
  • Volume : La quantité de données stockées

Un traitement BigData est typiquement constitué des 4 phases suivantes :

  • Ingestion
  • Stockage
  • Analyse
  • Affichage

De nombreuses solutions de BigData existent, mais Apache Hadoop est clairement le leader aujourd’hui.

Hadoop est initialement une implémentation open source de concepts issu de la recherche Google (Google File System (Octobre 2003) qui, comme son nom l’indique, est un système de fichier distribué & Map Reduce (Décembre 2004) qui est une façon de traiter les données de façon massivement parallèle, compatible avec des volumes importants).

L’idée est que pour adresser les problématiques apportées par le BigData, on peut :

  • Découper son volume de données en plusieurs parties,
  • Les placer sur un filesystem distribué sur plusieurs serveurs (HDFS dans le cas d’Hadoop)
  • Exécuter les traitements d’une certaine façon (Map Reduce) de façon massivement parallèle sur chaque partie de la donnée, en utilisant le compute du serveur stockant la partie en question (notion de localité)

Un cluster Hadoop est composé de plusieurs nœuds (de quelques-uns à des dizaines de milliers de noeuds), et utilise classiquement des serveurs “de commodité”.

cloud-vs-on-premise-1

Hadoop est devenu la plateforme de facto pour faire du BigData, sa popularité étant due, notamment, au fait que :

  • Il est open source, donc ne nécessite pas de payer une licence
  • Il dispose d’un très large écosystème
  • Il est accessible dans de nombreux langages (Pig Latin, Hive / SQL, Scala, Java, Python, R…)
  • Il permet de faire du traitement en batches aussi bien qu’en micro-batches ou en flux
  • Des distributions commerciales avec du support existent (HortonWorks, Cloudera)
  • Il a été adopté par tous les fournisseurs de solutions Cloud.

Il faut noter qu’Apache Spark est de plus en plus utilisé sur Hadoop à la place de MapReduce :

  • Spark travaillant en mémoire, il est en effet beaucoup plus rapide que MapReduce (parfois par un facteur 100)
  • Il dispose de nombreuses librairies permettant de faire :
  • du requêtage SQL sur les données,
  • du machine learning,
  • du traitement en flux (alors que MapReduce ne permet de faire que du batch)

4. BigData On premises : Se préparer à gérer les complexités

Hadoop est un écosystème complexe et son installation en datacenter impose un certain nombre de challenges, notamment :

  • La maîtrise technique de la stack applicative, et le choix de la distribution et / ou des différents composants
  • Le capacity planning selon les 3 axes : Compute, Storage, Network
  • L’architecture, selon un modèle top-down (datacenters, salles techniques, racks, en pensant à la répartition des serveurs et des switches dans les racks)

L’un des composants centraux de Hadoop est HDFS, le système de fichiers distribué. HDFS gère lui-même la réplication des données et leur localisation au sein du cluster (“topology awareness” : il va éviter de placer les réplicas d’une données dans des serveurs d’un même rack, par exemple). Il est donc recommandé d’utiliser les disques locaux des serveurs, et de les configurer en mode JBOD pour en tirer le maximum de performance, la sécurisation des données étant gérée par HDFS.

L’un des autres composants centraux d’Hadoop est la localité du compute et du storage, i.e : quand on va lancer un job celui-ci va s’exécuter dans la mesure du possible sur un serveur qui a les données sur ses disques locaux afin d’éviter de devoir les rappatrier par le réseau. Il est donc important de bien considérer le ratio “storage / compute” des noeuds : trop peu de stockage par serveur signifie qu’on va devoir avoir beaucoup de noeuds (ce qui augmente le TCO de l’infrastructure), trop de stockage sur chaque noeud nuira à la capacité à paralléliser les traitements (ou induira beaucoup de transit réseau).

En résumé, on se retrouve à devoir arbitrer entre la performance et le TCO de l’infrastructure.

On privilégie le stockage local d’une part, on souhaite avoir des performances maximales d’autre part : Hadoop est donc habituellement installé sur des serveurs physiques dédiés, ce qui complique le provisionning car il ne s’agit pas de créer une VM mais bien d’acheter un serveur, de le faire livrer en datacenter, de l’installer etc.

L’augmentation de la capacité d’un cluster Hadoop est toutefois relativement simple : elle se fait en ajoutant des noeuds, ce qui fait grandir en parallèle la capacité de stockage et de compute. Il faut toutefois noter que l’ajout ou la suppression d’un noeud signifie un trafic important pour la réplication des données (ce trafic étant potentiellement inter-datacenters).

Avoir un cluster Hadoop “on premises” signifie avoir un coût important aussi bien en CapEx (on a un investissement initial lors de l’achat du matériel) qu’en OpEx (il faut assurer l’administration quotidienne de l’infrastructure). Le BigData est un domaine bouillonnant et les versions des logiciels se succèdent rapidement (Spark a plus ou moins une release par mois). Les analyses BigData sont aussi souvent utilisées dans les domaines de l’innovation (marketing) et du traitement de l’information temps réel (adtech, fintech, …) où elles sont utilisées pour obtenir un avantage compétitif. Il est donc souvent important de pouvoir bénéficier rapidement des évolutions techniques apportées par les nouvelles versions des stacks logicielles BigData, ce qui donne de la charge aux équipes Opérations.

La plupart des études s’accordant sur le fait que les infrastructures des fournisseurs Cloud sont plus sécurisées que les autres Datacenters, il est difficile d’utiliser l’argument sécuritaire pour justifier une implémentation BigData on premises.

Le mode de fonctionnement “on premises” n’est donc à privilégier que si :

  • On est sûr qu’on aura un taux d’usage important de l’infrastructure (on ne bénéficie pas de capacité d’élasticité en “on premises”, le hardware devant dans tous les cas être acheté)
  • Des contraintes externes entrent en jeu (réglementaires, par exemple)
  • On a besoin de composants qui ne sont pas disponibles sur le Cloud (mais il serait peut-être plus pertinent de les substituer par des composants jouant le même rôle sur le Cloud. En outre les catalogues d’outils BigData des fournisseurs Cloud s’étoffent rapidement)

5. Bigdata dans le Cloud : Une aide au démarrage non-négligeable 

Le Cloud offre certains avantages uniques qui le rendent particulièrement attractifs pour les projets BigData.

Déjà, les différents providers fournissent toute la mécanique nécessaire pour adresser les 4 étapes du pipeline BigData :

cloud-vs-on-premise-2

Ensuite, le fait de traiter les serveurs comme des ressources jetables permet de réduire significativement le TCO de le l’infrastructure : On ne va payer que ce qui est nécessaire car on pourra lancer un cluster le temps d’une expérience, et le détruire une fois celle-ci terminée. On pourra utiliser des fonctions d’autoscaling pour permettre à un cluster d’avoir juste assez de nœuds pour traiter la charge, ni plus ni moins.

Une démonstration d’élasticité extrême dans le Cloud : Une société du domaine de la santé a pu exécuter un workload estimé à 39 ans de temps de compute en 9h seulement en utilisant les quelques 87000 cores d’instances virtuelles dans le Cloud, pour un coût de 4232 USD. Ils avaient estimé que cela leur couteraît quelques 40 millions USD pour obtenir 50000 cores et réaliser ce workload on premises. Difficile de rivaliser avec ceci en “on premise”.

Les implémentations d’Hadoop dans le Cloud doivent toutefois être adaptées pour permettre cette elasticité, car autrement l’ajout ou la suppression de noeuds provoqueraient la réplication d’importants volumes de données au travers du réseau. En pratique on n’utilisera donc pas HDFS avec le stockage interne des instances du cluster Hadoop, mais on s’appuyera sur la solution de stockage répliqué du Cloud provider (par exemple S3 dans le cas d’AWS ou BLOB Storage dans le cas d’Azure). Le fait de découpler le compute et le stockage des données fait qu’on peut librement ajouter ou enlever des noeuds, ou même lancer un nouveau cluster s’appuyant sur les données déjà présentes.

5.1 . Localisation des données

Le Cloud peut donc sembler idéal pour les projets BigData, mais il reste la problématique de l’envoi des données vers le Cloud. Quand la plateforme applicative est hébergée dans le Cloud, aucun problème. De même, pour les données “fil de l’eau” (clickstreams, remontée de sondes, logs, etc), les services d’ingestion des Cloud providers fonctionnent bien. Le problème se pose quand l’application n’est pas hébergée dans le Cloud, ou quand on a déjà un vaste volume de données qu’il faut amener vers le Cloud.

Ce problème est bien entendu bien connu des Cloud providers, qui l’adressent à minima avec la possibilité d’établir une liaison dédiée du datacenter où l’application et les données résident vers le Cloud où on veut procéder à son analyse. Certains permettent d’envoyer les données par l’intermédiaire d’un media physique tel qu’un disque dur ou une clé USB. Pour des volumes plus important (des teraoctets), AWS propose le service SnowBall : une appliance qui sécurise (physiquement, mais aussi par chiffrement) jusqu’à 80 TB de données qui seront alors envoyés par coursier jusqu’aux datacenters d’AWS.

cloud-vs-on-premise-3

Pour des volumes encore plus importants (des petaoctets), AWS propose SnowMobile : Un camion se déplace jusqu’au datacenter, les données (jusqu’à 100 petaoctets !) y sont transférées par le réseau puis le camion retourne jusqu’au datacenter d’AWS où les données seront transférées vers S3. Il faut noter que transférer 100 Po prendrait autrement 20 ans avec une ligne dédiée à 1 Gbps). Il est certain que, BigData ou pas, peu de clients auront des besoins aussi extrêmes, mais si c’est le cas AWS propose une solution.

cloud-vs-on-premise-4Quand tout le reste a échoué, il reste le camion. AWS SnowMobile.

5.2. Sécurité

La sécurité reste souvent un argument contre le Cloud. Non pas que le Cloud soit moins sécurisé qu’un autre datacenter, mais parce que la sécurité de l’infrastructure est de la responsabilité du provider. Les Clouds providers en sont bien conscients et communiquent largement sur les qualités en termes de sécurité de leur infrastructure. Ils cherchent aussi à obtenir les certifications les plus contraignantes, qui leur ouvrent la porte de certaines industries (santé, finance, défense, etc)

De mon point de vue, la sécurité du Cloud ne devrait pas constituer un frein à son adoption dans les projets BigData. Il faut toutefois bien prendre en compte :

  • Les aspects réglementaires, en particulier lorsqu’on choisit la région où on va monter son infrastructure BigData
  • L’utilisation du chiffrement des données quand cela est nécessaire
  • et bien entendu les bonnes pratiques de sécurité de tout projet Cloud : Les providers Cloud assurant la sécurité du Cloud, les clients assurant la sécurité dans le Cloud

Laisser un commentaire