Après un premier article “Coûts de solutions cloud: la grande nébuleuse” (que vous pouvez relire ici), Frank Vanden Berghen (The TIMi Company) poursuit sa démonstration à propos du prétendu avantage qu’il y aurait de confier ses calculs et traitements “big data/data science” à des infrastructures de cloud public.

Et si le local, malgré et en dépit de tout, était une meilleure option?

Une question qui vaut la peine d’être posée: “Beaucoup de sociétés souhaitent développer une infrastructure sur un cloud public sans vraiment savoir pourquoi… Les autres sociétés le font, c’est que ça doit bien être utile, non?”. Alors, le cloud public: utile ou pas? 

L’utilité des services cloud est indéniable dans le domaine de la communication: des applications comme Signal, Whatsapp, Gmail, etc. n’auraient pas pu exister sans des infrastructures cloud bien développées.

Le consensus est un peu différent quand il s’agit de “data science” et de “big data” – qui sont les domaines d’expertise de TIMi.

Si vous migrez dans le cloud pour obtenir de meilleures performances ou afin de pouvoir traiter de plus grandes volumétries, vous allez être très déçu: notre expérience nous a montré que l’infrastructure optimale dans la “data science” (ou le “big data”) n’est presque jamais une infrastructure “cloud”.

Certes, le cloud offre la perspective d’un stockage pratiquement illimité, mais très lent, tellement lent qu’il en devient pratiquement inutilisable. Voici un exemple concret pour illustrer le propos: imaginez que vous désirez analyser le traffic du site web d’une chaîne de télévision belge bien connue. 

Vous collectez une grande table qui répertorie toutes les personnes passées sur le site web. Une colonne de cette table contient l’identifiant du visiteur (c’est-à-dire son “cookie”). Vous désirez compter combien d’utilisateurs différents sont passés sur le site web en question en une journée particulière (en SQL, cela donne « Select count(distinct(id)) from Table »). Précisons que la table à analyser se compose de neuf colonnes et d’environ quatre millions de lignes.

Voici les résultats:

– temps d’exécution pour le stockage du tableau de données dans le cloud sur Amazon S3 au format parquet, via recours  à Redshift Premium pour lire les données hors de S3 et faire le comptage: 15 minutes
– pour le stockage du tableau de données sur un SSD local au format .cgel_anatella (un format fortement compressé), en ayant recours à l’outil Anatella de TIMi: 0,21 seconde.

Frank Vanden Berghen (The TIMi Company): “Notre expérience nous a montré que l’infrastructure optimale dans la “data science” (ou le “big data”) n’est presque jamais une infrastructure cloud.”

Supposons maintenant que vous êtes une grande chaîne de supermarché belge avec environ 250 supermarchés. L’ensemble de toutes vos données de vente à l’échelle la plus fine pour deuw années d’historique (environ 1,3 milliard de transactions) consomme 24 Go d’espace disque au format .cgel_anatella. 

Cela veut dire qu’un seul disque SSD de 4 To (qui coûte 400 euros) vous permettra de stocker et de manipuler plus de… 150 années d’historique de vente. On comprend bien ici que l’argument de l’obligation d’avoir un “stockage infini dans le cloud” est un argument erroné.

Doublement erroné même puisque, d’une part, quelle chaine de supermarché possède plus de 150 années d’historique de vente? Et, d’autre part, parce que sur ce type de volumétrie, avec des outils cloud (tels que Redshift ou BigQuery), le temps d’exécution sera tellement prohibitif qu’aucune analyse sérieuse n’est possible.

On voit sur base des deux exemples ci-dessus que pour avoir les meilleures performances en matière de “data science”, il est nécessaire d’éviter les outils cloud.

On pourrait continuer ici longtemps et donner de nombreux autres exemples sur l’inefficacité du cloud – le dernier exemple en date est l’analyse d’une base de données relative à la stabilité des connexions des points d’accès Wifi intégrés aux modems d’un grand opérateur telecom belge: cette analyse est réalisée en 12 secondes sur une seule machine équipée d’Anatella alors que le cloud Amazon réalise cette analyse en plus de 20 minutes sur 200 machines/noeuds.

Ils se gardent bien de vous contredire

Ces chiffres sont des résultats tangibles et mesurés. Il n’est pas ici question d’exprimer une opinion mais plutôt de relater un fait: dans la grande majorité des cas, quand il est question de “data science”, le cloud (Amazon ou Azure) est d’une lenteur rédhibitoire par rapport à une bonne solution de data science “en local” (ou sur une infrastructure telle celle proposée par l’hébergeur Hetzner).

Pourtant, malgré ces faits avérés et certains, de nombreuses sociétés continuent de migrer leur infrastructure logicielle vers le cloud Amazon/Azure/Google dans l’espoir de “gagner en vitesse”. Le raisonnement étant que l’abondance de machines et de CPU présentes dans le cloud devrait, à première vue, permettre de gagner en vitesse par rapport à une infrastructure matérielle locale “on premise” moins pourvue en CPU et en machines.
Malheureusement, ce raisonnement n’est que très partiellement valable (voire carrément erroné): En effet, la grande majorité des calculs rencontrés en “data science” ne fonctionneront pas mieux dans le cloud, au contraire (les machines n’y sont pas adaptées).

Ce phénomène est principalement provoqué par une loi mathématique nommée “Loi d’Amdahl” [Ndlr: cette loi indique l’accélération théorique en latence de l’exécution d’une tâche à charge d’exécution constante que l’on peut attendre d’un système dont on améliore les ressources].
Vous trouverez plus de détails à ce sujet dans les deux vidéos YouTube postées par TIMi dans son propre blog (son en anglais, sous-titre en français).

En réalité, les seules sociétés qui bénéficient de cette erreur de raisonnement sont les fournisseurs cloud (Amazon, Azure, Google), pour des raisons évidentes… $$$$
Et ils se gardent bien de vous corriger!