Le badbuzz DigitalOcean : les erreurs du « tout cloud public » (et du fournisseur unique)

Cet article a été publié il y a 4 ans 10 mois 14 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Cela ne vous aura certainement pas échappé sur Twitter (et vu le succès de ma micro-analyse, j’imagine que vous avez certainement vu passer le sujet), un des membres d’une petite entreprise, qui propose une application à destination des entreprises (avec quelques candidats au bullshit bingo dans la description Twitter), alerte que son hébergeur est en train de la tuer parce qu’il a bloqué l’intégralité de son infrastructure. Et soit-disant qu’il n’a aucun moyen de contourner. Et là, on va toucher à un problème trop récurrent sur le web actuel, la dépendance à l’hébergeur.

Digital Ocean est peu connu de ce côté de l’atlantique, mais c’est un hébergeur assez populaire en Amérique du Nord, notamment pour ses tarifs, un peu à l’image d’un OVH en Europe, la qualité en plus (troll gratuit, si on a pu avoir des soucis avec eux chez LBN, en tant que client particulier globalement j’ai pas grand chose à redire). Et donc pour une raison que j’ignore parce que j’ai la flemme de creuser, cette jeune société basée à Paris héberge toute son infrastructure chez eux. Tout va pour le mieux dans le meilleur des mondes.

Et là, patatras, vendredi 31 mai, l’un des membres de la société vient se plaindre sur Twitter que com compte a été bloqué, ainsi que toutes les ressources associées, et que ça va le tuer (enfin sa société). En soi oui, c’est possible, si tu perds toutes les données de ton entreprise, qui sont celles qui te font vivre (enfin celles sur lesquelles tu bâtis ton service, vendu aux entreprises), ben t’as plus rien à vendre, et donc, si les comptes sont en flux tendus, ça devient vite un gros, gros problème. Mais pourquoi donc Digital Ocean (que je vais abrévier DO) a-t-il coupé le compte d’une entreprise qui à priori n’a rien à se reprocher, au moins d’un point de vue technique ?

How @DigitalOcean just killed our company @raisupcom. A long thread for a very sad story. pic.twitter.com/uOFCDRoYJ6

— Nicolas Beauvais (@w3Nicolas) May 31, 2019

Nicolas explique très bien dans son thread, en temps normal son application nécessite cinq droplets, nom donné par DO pour ses instances de machines virtuelles à la demande (comme EC2 sur AWS), qui tiennent différents rôles, et du stockage objet pour les média (et il en a beaucoup, mais comme on paie à la consommation, pas de souci). Seulement pour entretenir la base de données qui est au cœur de l’application, afin d’en garantir les performances, régulièrement une dizaine de droplets supplémentaires sont démarrés pour exécuter du code Python qui s’occupe des opérations de maintenance. Les droplets sont ensuite détruits, puisqu’il n’auront plus d’utilité jusqu’à la prochaine fenêtre de maintenance. Rien de choquant dans une telle architecture, c’est même l’avantage de ces mécaniques chez les fournisseurs de « Cloud » modernes, on crée et utilise des ressources uniquement dans une fenêtre de temps utile, plutôt que de réserver et payer en permanence des ressources qui ne sont pas exploitées (gaspillage toussa). Mais apparemment ce comportement a été détecté comme malveillant, avec pour conséquence de bloquer l’accès à toutes les ressources, ce qui inclut les sauvegardes de données et d’architectures (je ne sais pas comment sont sauvegardés les média sur le stockage objet de DO, ni comment on peut procéder à une restauration).

Pourtant DO promet lui-même de pouvoir déployer « de un à plusieurs milliers » de droplets sur son site :

Et sur le papier, DO n’est pas ultra regardant sur le comportement des instances, tant qu’ils ne sont pas alertés d’abus, généralement au niveau du réseau, quand le trafic est douteux, tous les grands fournisseurs se protègent aussi bien en entrée qu’en sortie. Ici rien de la sorte, à part que les dix droplets créés « attaquent » le droplet qui s’occupe de la base de données, mais c’est du trafic interne, dans le même subnet à priori (facilite le déploiement et la configuration, surtout pour un travail très temporaire). C’est donc étrange qu’un tel blocage ait eu lieu. Rapidement contacté, l’hébergeur a d’abord débloqué le compte, avant de le rebloquer 4h plus tard en refusant ce coup-ci toute discussion, comme très souvent avec de grosses sociétés, David contre Goliath mais c’est Goliath qui met une patate de forain à la fin.

A cause du bruit que ça a fini par faire, DO a finalement restauré le compte (pour combien de temps ?) et promet d’analyser les raisons qui ont poussé leur système à procéder à un tel blocage, mettant en péril l’existence même de la petite société. Au-delà de la nécessaire opération de communication, il n’y a rien de choquant là-dedans, s’il y a un dysfonctionnement qui peut engager à ce point là responsabilité de l’hébergeur, ils vont tout faire pour le corriger, car on sait à quel point un hébergeur aime n’être responsable de rien, encore plus aux US qu’ailleurs.

Une confiance à limiter, une stratégie de catastrophe à revoir

Tous les hébergeurs vous promettent haute disponibilité des infrastructures, intégrité des données, sécurité, et on entend souvent qu’on ne peut avoir que deux des trois. Concernant la disponibilité et l’intégrité, vous avez la possibilité de déployer sur plusieurs « régions » qui correspondent à des centre de données distincts et relativement éloignés géographiquement, et les données du stockage objet sont répliqués sur ces différentes zones.Tout ça est transparent ou presque, le déploiement d’instances sur plusieurs zones doit être de votre fait, ce n’est pas automatique (il y a des contraintes au niveau réseau difficiles à contourner), pour le stockage par contre aucun souci c’est transparent.

Et surtout, ça suppose que vous n’ayez aucun problème avec le compte, et comme on l’a vu ici, dès que le compte est bloqué, tout est bloqué. Il y a donc ici une forte dépendance à un seul hébergeur, et surtout, aucune stratégie de sortie n’a été envisagée, ce qui veut dire qu’il n’existe aucune copie à minima des données base et media (le code des applications est certainement stocké dans une forge git quelconque, donc facile à redéployer), en clair, ce type de catastrophe n’a jamais été envisagé. En même temps, DO est un acteur reconnu, populaire, aux services fiables, pratiques (API, toussa), performants, relativement abordables, donc aucune raison de douter de leur professionnalisme n’est-ce pas ?

Le problème de la facilité d’utilisation de leurs services, c’est que ça a du attirer pas mal de mauvais utilisateurs, qui se sont amusés à déployer du temporaire pour attaquer d’autres infrastructures, ce qui a du pousser DO à mettre en place des mécaniques pour tenter de détecter et de bloquer ces abus, à l’image de certains types d’attaques réseau (rebond sur UDP, SYN ACK, DDoS…). Je ne peux que soupçonner un tel mécanisme étant donné le profil de l’activité (démarrer une dizaine d’instances qui exécute du code qui tape sur une autre machine dont les consommations de ressources explosent tout d’un coup). Et c’est dommage dès lors de faire la pub sur « des milliers » si une dizaine suffit à se faire bannir du système.

Donc même en étant un client payant, il faut toujours se méfier de son fournisseur, quel qu’il soit, et d’autant plus quand une grosse partie de ses opérations est confiée à des robots. Vous pouvez toujours parler d’intelligence artificielle pour améliorer les choses (et j’aime pas ce mot, remember), il faudra toujours des humains pour traiter les cas à la marge, qui ne pourront jamais être évités.

Une stratégie qui coûte cher

Et c’est bien le souci, l’argent. Le coût du stockage objet des 500k+ media est assez bas, et inclut pourtant la réplication dans plusieurs centres de données. Je n’ai pas la volumétrie exacte, mais conserver une copie de ces media sur un stockage plus classique, ou un stockage objet d’un autre hébergeur, en miroir, coûte à minima le double. Et il reste ensuite la base de données, là aussi, compliqué sans avoir la volumétrie mais le stockage rattaché aux droplets est un poil plus cher, même en trouvant un moyen de compresser les sauvegardes, pas évident de limiter la dépense.

Ce genre de stratégie est donc compliqué à mettre en place, pas d’un point de vue technique, c’est très, très rarement un problème, mais surtout d’un point de vue financier. Reste alors à faire un calcul savant sur les risques qu’il y a à perdre l’intégralité de son activité sur une telle connerie, et prendre la décision d’investir un peu plus dans un plan de secours, qui peut aller jusqu’à (re)déployer l’intégralité de l’infrastructure chez un autre hébergeur. Ici, ça pourrait être facile, tout repose sur des machines virtuelles a priori Linux qui sont simples à reproduire ailleurs, reste le stockage objet qui pourrait demander un peu plus de boulot, pas tant pour la mise en place ou la population, que pour la mise à jour des liens dans l’application.

C’est moins le cas quand on commence à utiliser beaucoup de services intégrés, la mode étant au « serverless », ce qui veut dire qu’on est encore plus dépendant de son hébergeur car chacun a sa propre méthode pour arriver à ses fins, ses propres services spécifiques, et donc il peut être très difficile voire impossible de transférer ça sur un nouvel hébergeur, ou alors doit être pensé pour être adaptable sur une architecture plus classique. Beaucoup plus de boulot, donc plus de temps, donc plus d’argent, quand la technique tape dans le porte-monnaie, on en revient toujours au même. Le piège est donc de ne pas chercher à tout pris le moins cher, mais bien d’intégrer les risques, en pensant toujours au pire même si on vivra toujours le meilleur.

La réponse du Cloud Hybride et de l’Infrastructure as Code ?

L’infrastructure as Code, pour la faire court, permet de décrire tous les éléments constitutifs de l’infrastructure dans un ou plusieurs fichiers, qu’on balance ensuite à un outil, soit générique, comme Terraform, soit spécifique à un fournisseur (CloudFormation pour AWS), qui s’occupe de déployer ces éléments. Ce type de pratique permet de conserver et de versionner cette description, et surtout de l’adapter très simplement à un autre fournisseur si le besoin s’en fait sentir. Ça permet d’améliorer ses chances de pouvoir déménager ou redéployer en urgence une infrastructure de zéro si une catastrophe majeure comme celle vécue ici survient. Je commence moi-même à mettre les mains dedans pour pouvoir assumer mon futur rôle d’intégrateur (et que intégrateur, quand je faisais un peu de tout jusqu’ici), et j’avoue que c’est très intéressant. Couplé à un Ansible pour s’occuper ensuite de la configuration des machines virtuelles (et Chef en plus chez LBN, pour gérer les accès, les outils de bases, la configuration du monitoring…), vraiment il faut s’y intéresser, même si c’est pour déployer une seule machine, ça permet d’en saisir les concepts, et la puissance.

Quant au cloud hybride, c’est un peu le sujet à la mode ces trois dernières années, après les premières déconvenues de gros comptes qui ont voulu tout « mettre dans le cloud » avant de voir à la fois les problèmes de réactivité et les soucis de facturation qui deviennent réels à mesure que l’infrastructure devient monstrueuse. Il s’agit de reposer à la fois sur des éléments hébergés « chez soi » que sur un hébergeur public, en utilisant des deux cotés les mêmes technologies. C’est d’autant plus facile que de plus de sociétés même modestes (et pour rappel, la France compte une majorité de PME, et pas d’entreprises multinationales) peuvent avoir accès à des réseaux fibres de plus en plus performants, et la montée en puissance de services « managés » basés sur Kubernetes, pour ne prendre que cet exemple, permettent d’agréger les deux types de ressources pour les exploiter via une interface unique, permettant du coup, au-delà de segmenter ce qui doit être stocké à l’extérieur de ce qui doit rester à l’intérieur, de s’affranchir si besoin de cet hébergeur qui devient vite un problème quand ses mauvais penchants viennent vous embêter un peu trop.

On a notamment IBM qui s’est offert RedHat qui propose pas mal d’outils reposant sur RedHat Enterprise Linux  et OpenShift (sa surcouche maison de Kubernetes, si vous trouvez déjà Kubernetes pénible OpenShift c’est pire, mais c’est beaucoup plus sécurisé). Si vous êtes un windowsien convaincu et avez besoins de VMs classiques, avec VMWare qui permet d’agréger plusieurs « datacenters » dans une même interface Vsphere, vous pouvez coupler un cluster hébergé chez un prestataire et un cluster sur site (« on premise », parce qu’on adore les anglicismes dans l’informatique). Avec un OVH qui propose du Private Cloud reposant justement sur ce type de solution, et même un AWS qui a annoncé se lancer sur ce type de produits récemment, vous avez au moins deux possibilités.

Le pognon, toujours le pognon

Globalement j’ai pas de problèmes avec l’argent, mais c’est un problème qui a trop souvent été mis sous le tapis sur le web. C’est malheureusement une réalité qui revient souvent trop tard sur la table, à force de chercher à tout prix à économiser des centimes, on se retrouve à payer des milliers, voire ici à devoir mettre la clé sous la porte (ça ne sera peut-être pas le cas vu que c’est restauré, mais dans les contrats clients on a souvent des pénalités en cas de non-respect des engagements — si seulement on avait ça pour le grand public, avec les fournisseurs d’accès et les opérateurs mobiles…). Il est donc nécessaire de mettre la priorité sur la couverture de risques plutôt que les rentrées faciles, un point compliqué quand on démarre une activité avec une levée de fonds et que les requins investisseurs attendent leur sandwich à la fin du trimestre.

Ça m’a rappelé une autre affaire, il y a deux ans, où OVH a perdu une baie complète de disques durs à cause d’un souci avec leur refroidissement liquide (et la paresse consistant à laisser du matériel qui n’est pas conçu pour se faire arroser par une fuite plutôt que de l’installer où il fallait, sur le principe du « ça fonctionne on touche pas »). Ça a touché des milliers de sites utilisant une offre d’hébergement mutualisée, un produit très peu cher (on parle de maximum 90€ TTC par an). Les restaurations ont été faites sur plusieurs jours sur une baie neuve avec des données nécessairement un peu anciennes, il y a donc eu pour certains perte de données. Et on a vu des personnes, qui opéraient une boutique en ligne sur cette offre, se plaindre d’avoir perdu masse d’argent et commencer à demander des dédommagements à OVH pour ces pertes engendrées. Oui, des gens qui ont basé leur activité sur une offre à 7€ par mois dont les engagements sont très faibles se plaignent à leur hébergeur de ne pas avoir fait le nécessaire pour assurer la disponibilité de leur principale source de revenus. Nous avons plusieurs clients « modestes » chez LBN en ce sens que leur boutique en ligne n’est pas énorme, mais ils déboursent un peu plus que 7€ pour garantir leur activité (on est plus près de 700€, et l’infra est petite). Et des interruptions trop fréquentes peuvent amener à des pénalités que l’on doit payer, autant dire que si on avait pas la conscience professionnelle pour nous, on aurait le portefeuille (vous voyez on y revient toujours).

Si vous êtes amenés donc à construire votre activité sur le web avec un besoin fort d’hébergement extérieur, il est nécessaire de s’assurer que tous les éléments, et notamment les situations de crises majeures comme celle qu’a vécu notre jeune pousse de l’analyse stratégique, soient bien pesés et pris en compte, aussi bien pour l’aspect financier que pour technique. À bon entendeur…