- En migrant d’AWS et DigitalOcean vers Hetzner, les coûts cloud ont été réduits de 76 % et la capacité des ressources a été multipliée par 3
- Auparavant, les deux services cloud étaient utilisés en parallèle, en s’appuyant sur la fiabilité d’AWS et la simplicité de DigitalOcean
- Après l’épuisement des crédits gratuits, les coûts d’exploitation ont dépassé 449 $ par mois, ce qui a conduit à chercher des alternatives comme Hetzner
- Pour réduire les coûts, une stack cloud autogérée a été construite en combinant Kubernetes basé sur Talos Linux, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager, etc.
- En utilisant les serveurs ARM à vCPU partagés de Hetzner et un stockage compatible S3, il a été possible de maintenir les performances et la stabilité tout en étendant fortement les ressources
- La gestion est un peu moins pratique, mais en tant que cloud alternatif en Europe, le rapport coût/performance est excellent
Contexte
- Tous les logiciels développés par DigitalSociety fonctionnent dans le cloud
- Avant la migration, l’infrastructure principale était exploitée à la fois sur AWS (services principaux, authentification, e-mail, etc.) et DigitalOcean (services légers, monitoring, Kubernetes)
- AWS a été choisi pour l’habitude acquise après plus de 15 ans d’utilisation et pour la grande stabilité de ses API
- DigitalOcean a été choisi pour son environnement Kubernetes simple, son control plane gratuit et son efficacité en matière de coûts
- Au départ, seul DigitalOcean était utilisé, mais pour un SaaS intensif en données comme tap, qui nécessitait beaucoup de ressources et des crédits supplémentaires, les crédits startup d’AWS (1 000 $) ont été mis à profit
Fin des crédits et pression sur les coûts
- Grâce à Fargate d’AWS (exécution serverless de conteneurs), l’infrastructure a pu être mise en place à faible coût au début, mais la nature intensive en données du service tap exige au minimum 2x CPU et 4 GiB de RAM pour maintenir les performances
- Avec Fargate, un conteneur de cette configuration coûte plus de 70 $ par mois, et avec deux instances de workers et le reste de l’infrastructure, le total atteint 449,50 $ par mois
- Les crédits gratuits fournis ont été épuisés en moins de six mois, ce qui est devenu une charge fixe importante pour une startup autofinancée
Recherche d’alternatives
- Afin de réduire fortement les coûts d’exploitation et de gagner en indépendance technologique, des fournisseurs cloud basés au Royaume-Uni / dans l’UE ont été recherchés
- L’attractivité tarifaire de Hetzner a convaincu l’équipe de migrer à la fois depuis AWS et DigitalOcean, malgré un environnement VPS autogéré et une complexité opérationnelle plus élevée
- Comme la majorité des services fonctionnaient déjà sur Kubernetes, un cluster Kubernetes interne a également été mis en place chez Hetzner grâce à la simplicité de déploiement de cluster offerte par Talos Linux
- Il n’existe pas de service de base de données managé équivalent à ceux d’AWS ou DigitalOcean, mais CloudNativePG a permis d’intégrer et de gérer en toute sécurité un cluster PostgreSQL dans Kubernetes (monitoring, sauvegardes, gestion des incidents, etc.)
Nouvelle stack d’infrastructure
- Hetzner : utilisation de serveurs ARM, stockage bloc, load balancers, réseau, pare-feu et stockage objet compatible S3
- Talos Linux : automatisation de l’exploitation grâce à la gestion des nœuds Kubernetes via une configuration déclarative
- CloudNativePG : déclaration du cluster de base de données dans les manifestes Kubernetes, avec sauvegardes automatiques, gestion des incidents, etc.
- Ingress NGINX Controller : gestion centralisée du routage HTTP dans le cluster
- ExternalDNS : liaison automatique du DNS aux ressources Ingress
- cert-manager : émission automatique des certificats TLS pour le HTTPS
- Toute l’infrastructure est définie comme code avec Terraform et Helm, et les déploiements automatisés via GitHub Actions concrétisent l’approche DevOps
Comparaison des coûts
- Coût mensuel avant migration : AWS + DigitalOcean = 559,36 $
- Coût mensuel après migration : Hetzner = 132,96 $ (−76 %)
- Augmentation des ressources :
- CPU : 12 vCPU → 44 vCPU (+367 %)
- RAM : 24 GiB → 88 GiB (+367 %)
- Malgré l’augmentation des ressources, le coût mensuel total est nettement inférieur
Défis et tâtonnements pendant la migration
- Les zones réseau de Hetzner ne correspondent pas totalement aux Availability Zones d’AWS
- AWS dispose de plusieurs Availability Zones par région, avec un réseau privé largement interconnecté à l’échelle de la région
- Hetzner propose plusieurs localisations sous une même zone réseau (eu-central), mais la latence réseau entre elles est importante
- En pratique, le monitoring a montré que la répartition sur plusieurs localisations entraînait des problèmes, notamment une baisse de performances
- Comme alternative, un Placement Group a été utilisé dans une seule localisation (Nuremberg) afin d’assurer la résilience grâce à une répartition physique des serveurs
- Même avec des services conteneurisés, la portabilité n’est pas si simple
- Lors du passage d’AWS ECS à Kubernetes, la modification des scripts d’automatisation de toute la configuration, en particulier pour le déploiement des fichiers de config, a pris beaucoup plus de temps que prévu
- Finalement, Kustomize a permis d’améliorer l’intégration des configurations sensibles ainsi que la gestion des fichiers de config, ce qui a renforcé la traçabilité et la facilité de revue
Conclusion
- Hetzner n’est pas un service managé facile à utiliser, mais c’est un choix très efficace pour les équipes capables d’autogérer leur infrastructure
- L’exploitation en propre permet de garder le contrôle sur les détails de la configuration tout en maximisant les performances au regard des coûts
- Cette approche a permis de poser les bases nécessaires pour continuer à développer et exploiter tap, un SaaS intensif en données, avec des coûts raisonnables et des performances stables
1 commentaires
Avis Hacker News
Je veux vraiment insister sur l’énorme gain de performance perçu quand on déploie directement sur du bare metal. Pour notre service, les performances ont doublé, avec une stabilité et une prévisibilité bien meilleures. Il y a plusieurs raisons à cela :
Faible latence : en gérant directement le réseau, on ne partage pas le réseau complexe d’un grand datacenter, ce qui réduit la latence de plus de 10x
Optimisation du cache : un déploiement optimisé pour le matériel permet d’exploiter pleinement les vraies performances des CPU récents
Utilisation de NVMe dédiés : les vitesses d’I/O disque sont énormes
Autre avantage : on a beaucoup moins besoin d’autoscaler. À prix égal, le matériel est 10 fois plus puissant et 2 fois plus rapide, donc faire tourner en pleine capacité est plus rationnel. L’ensemble du système est stable et plus simple à gérer
Plus besoin non plus de s’inquiéter de la facture S3. Il suffit de mettre des disques NVMe de 15 To dans chaque serveur et de faire tourner un cluster MinIO/garage. Nous traitons actuellement 20 GiB/s et 50 000 appels API par seconde sur un cluster de 10 nœuds. Avec S3, rien que les appels API coûteraient entre 20 $ et 250 $ par seconde, ce qui montre l’écart hallucinant
On ne paie qu’un forfait mensuel fixe
Et on profite d’un stockage rapide et bon marché, d’instances PostgreSQL volumineuses à faible coût, avec beaucoup moins de contraintes et de bricolages qu’en cloud
Même en investissant dans ce type d’architecture, on reste à un dixième du coût d’AWS
Si l’exploitation directe vous semble trop lourde, nous (https://lithus.eu) pouvons la gérer pour moitié moins cher qu’AWS, avec support DevOps inclus. Contact : adam@, voir le domaine
Contexte technique : le bare metal consiste à faire tourner les services directement sur un serveur physique, et non dans une « virtualisation (VM) »
J’aimerais vraiment qu’on dépasse cette vieille époque du « il suffit d’ajouter du matériel pour aller plus vite » et du « le coût n’a pas vraiment d’importance ». Dans ma carrière, à l’époque de .NET, j’ai tenu jusqu’à plusieurs millions d’utilisateurs avec un seul serveur en baie. Ensuite, en rejoignant une entreprise basée sur le cloud, les conteneurs et les microservices Node, j’ai vécu chaque jour le chaos des factures et des problèmes de performance, et ça me donne encore parfois des frissons
Le changement semble toujours cyclique. Quand je regarde notre entreprise, j’ai l’impression que le fait de ne pas bouger sans adopter la toute dernière techno nous place paradoxalement à l’avant-garde du mouvement vers le cloud local, l’edge et les IDC internes
Utiliser l’API S3, c’est comme éplucher un oignon. Plus on l’utilise, plus on pleure
Avec le bare metal, il faut du personnel dédié pour la gestion réseau, la sécurité, la supervision, les correctifs et les mises à jour. Le coût de ces profils spécialisés n’est rentable qu’à partir d’une certaine taille. C’est pourquoi, pour les PME, le cloud reste avantageux du point de vue sécurité et coûts d’exploitation
AWS indique lui-même dans sa documentation que, pour Lambda, l’allocation de 1 vCPU correspond en pratique à environ 50 % seulement. Le ratio s’améliore quand on augmente mémoire et CPU, mais on n’obtient pas toujours 100 % des performances
Je pense depuis longtemps qu’on peut maximiser l’efficacité avec des serveurs dédiés. J’exploite quelques nœuds chez Hetzner, et même en louant aux enchères des serveurs anciens de trois ans, on obtient des performances sans commune mesure avec les VM. Le matériel serveur est optimisé pour le nombre de cœurs et l’I/O, et la plupart des clouds surallouent le matériel. Même l’I/O disque est parfois bricolée, avec du NAS présenté comme du disque local. La plupart des startups n’ont pas besoin de cette virtualisation excessive ni de ces disques basés sur du NAS. En louant des serveurs chez Hetzner ou ailleurs, on peut aller beaucoup plus loin pour beaucoup moins cher. Je serais curieux de connaître, en Amérique du Nord (surtout au Canada), des fournisseurs au niveau de Hetzner en prix et en qualité. Je connais déjà OVH, donc si vous avez d’autres noms similaires, je suis preneur
Beaucoup de gens semblent penser qu’il faut copier immédiatement l’architecture technique de Google ou Facebook. Nous, nous tournons modestement sur des VPS européens. Pourtant, chaque nouvelle recrue — côté business comme côté développement — explique qu’il faut lancer un projet de migration vers le cloud. À chaque fois, je dois répondre quelque chose comme : « nous sommes déjà dans le cloud, et je ne vais pas vous laisser faire un projet de migration cloud juste pour votre CV »
J’ai publié des benchmarks réels comparant les performances CPU entre serveurs cloud et bare metal, si ça peut aider : https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12
J’ai récemment découvert un site qui pourrait être utile : https://vpspricetracker.com. Le concept est très impressionnant. La plupart des fournisseurs listés proposent aussi des serveurs dédiés
Si par « qualité Hetzner aux États-Unis » vous voulez dire « peu importe que ce ne soit pas une marque locale », Hetzner lui-même dispose aussi de deux datacenters aux États-Unis
Pour le Canada, quelques fournisseurs à regarder : https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/
Nous observons la même tendance. Beaucoup d’équipes migrent vers Hetzner et sont impressionnées par le rapport prix/performance, mais réalisent ensuite qu’il faut tout reconstruire pour l’exploitation de Postgres : sauvegardes, bascule, supervision, etc. Nous avons donc créé un Postgres managé qui tourne directement sur Hetzner. On garde la même optimisation matérielle, avec en plus la haute disponibilité (HA), les sauvegardes et la restauration à un instant donné (PITR). C’est open source, au plus près du matériel, et sans les pièges cachés habituels d’AWS comme les frais d’I/O ou de sortie de données. Si ça vous intéresse, voir le blog 1, 2
C’est précisément pour cela que je vois un grand attrait dans les Big Cloud, en particulier les PaaS et les SQL managés (et c’est aussi le cas des équipes de développement que je conseille). Même sans grande expérience opérationnelle, on adopte plus sereinement ces solutions parce que la sauvegarde/restauration de base de données, les correctifs, les restrictions d’accès, la gestion des ports, la détection d’anomalies ou la réponse aux attaques DoS sont prises en charge automatiquement. Politiquement comme techniquement, utiliser un grand fournisseur cloud populaire apporte un filet de sécurité psychologique
Si vous avez des problèmes avec une version auto-configurée et auto-gérée de Postgres, https://www.elephant-shed.io/ peut valoir le détour
Ce qui est amusant avec ce genre d’articles ou de commentaires, c’est qu’ils donnent rarement le contexte du conseil. Faire tourner une petite newsletter d’église sur son temps libre ou un SaaS d’entreprise à très fort trafic avec des clients dans le monde entier, ce n’est pas du tout le même cahier des charges. Sans explication sur l’environnement réel, les conseils sur le prix, la performance ou la disponibilité sont pratiquement dénués de sens. Si l’infrastructure web est devenue si complexe, c’est aussi parce que des gens aux besoins très différents se copient les uns les autres
J’ajouterais à l’idée selon laquelle « suivre des conseils sans esprit critique alors que les besoins diffèrent ne fait que compliquer la réalité ». Dans certaines entreprises, le chargé de compte cloud s’invite au déjeuner des dirigeants C-level et obtient qu’on impose AWS. Ensuite, les architectes AWS sont envoyés directement auprès de notre équipe et recommandent naturellement les options serverless les plus chères. Mais au final, il faut quand même redéployer sans cesse les images Docker OS et les gérer comme on gère les correctifs de serveurs bare metal classiques
Même mon pastebin personnel ne survivrait pas sans bare metal (je plaisante)
C’est un exemple très typique du secteur IT
Les exigences, le niveau technique, la structure de coûts et le domaine des problèmes sont complètement différents. Hetzner et AWS se ressemblent en surface parce qu’ils évoquent tous deux le cloud, mais en réalité ce sont des services totalement différents. Je dis ça pour avoir utilisé les deux
Entièrement d’accord. J’ai aussi écrit mon avis sur le sujet dans un billet de blog : https://news.ycombinator.com/item?id=45616366. En résumé : « comprenez les hébergeurs à travers une grille de prix allant du DIY à l’enterprise, et si ne pas utiliser quelque chose est plus avantageux (YAGNI), ne le choisissez pas »
Cela fait plus de 10 ans que j’exploite un SaaS sur Hetzner. Matériel entièrement dédié, clusters répartis entre les datacenters allemands et finlandais, gestion via ansible. Pour le VPN entre serveurs, j’utilise vpncloud (ce logiciel est vraiment excellent). Les frais mensuels d’hébergement sont dérisoires par rapport à AWS et consorts, et les serveurs sont bien plus rapides. L’architecture reste simple et un petit nombre de serveurs suffit. Si besoin, il suffit d’ajouter des serveurs, même si en bare metal l’extension ne se fait pas en quelques minutes : il faut planifier quelques heures ou quelques jours à l’avance. Pour la base de données, nous utilisons une architecture distribuée avec RethinkDB (bientôt migrée vers FoundationDB) afin de mieux résister aux pannes
J’exploite aussi quelque chose de similaire avec rethinkdb. En revanche, je suis curieux de savoir pourquoi vous avez choisi FoundationDB. RethinkDB est toujours maintenu et reçoit encore parfois de nouvelles fonctionnalités. Il y a plus d’utilisateurs actifs qu’on ne le pense dans la communauté Slack
Ça fait plaisir de voir qu’il y a encore des gens qui utilisent RethinkDB
Vous reliez directement les centres Hetzner DE/FI avec vpncloud ? Je pensais que Hetzner proposait lui-même ce genre de fonctionnalité à bas coût
J’ai récemment aidé plusieurs équipes à passer d’AWS à Hetzner (et Netcup), et la plus grande surprise pour elles n’a pas été le coût ni la performance en eux-mêmes, mais le fait que l’architecture devient soudainement bien plus simple quand on enlève 15 couches d’abstraction managée. Plus besoin de se demander quoi faire avec S3/EFS/FSx, les cold starts de Lambda ou les burst credits d’EBS. On déploie juste Docker sur des NVMe rapides et ça fonctionne. Il faut certes un peu plus de compétences DevOps — supervision, sauvegardes, correctifs, etc. — mais une fois automatisées, ces tâches n’évoluent pas toutes les semaines. Chez Elestio, on se concentre justement sur cette simplification, en fournissant des stacks entièrement managées de plus de 400 logiciels open source sur n’importe quel cloud (CI/CD inclus). Cela couvre aussi la production chez Hetzner ou ailleurs https://elest.io (à noter : je travaille chez Elestio, qui propose des services open source multi-cloud)
Au début de ma carrière, j’ai travaillé dans une excellente entreprise, mais nous avions besoin d’une version de Postgres que RDS ne supportait pas encore, donc j’ai dû installer Postgres moi-même sur EC2 à plusieurs reprises. C’était avant Docker, et avec le temps j’avais surtout l’impression d’accumuler des heures perdues à configurer tout ça. Dès que RDS a supporté la bonne version, tout est devenu infiniment plus simple. Je me souviens encore très bien de ces nuits à 3 heures du matin à réinstaller Postgres. Cet article est intéressant, mais au final il s’agit peut-être seulement d’économiser quelques centaines de dollars par mois. Il suffit qu’un ingénieur y consacre une heure par mois pour annuler l’économie réalisée. Et en cas d’incident soudain, une seule journée peut faire disparaître un an d’économies. Pour un projet personnel où le temps a peu de valeur, surtout si l’on a besoin de gros serveurs, exploiter du bare metal peut avoir du sens. Mais à la fin, la valeur de mon temps augmente. Par exemple, un blog Ghost en hébergement officiel coûte 10 $ par mois, alors qu’on peut en faire tourner plusieurs sur une instance Hetzner. Mais quand quelque chose casse, on finit par se demander s’il ne vaut pas mieux payer 20 $ de plus plutôt que de passer 2 ou 3 heures à réparer
Le plus gros avantage de certains serveurs dédiés Hetzner, c’est la bande passante illimitée. J’héberge un site très orienté images, et depuis la migration chez Hetzner, cela fait trois ans que je paie un tarif fixe et que je dors tranquille la nuit
Hetzner a clairement des limites quand on veut monter en échelle. Au début, nous faisions tourner plusieurs centaines de VM chez eux, et aux pics il fallait dépasser le millier. C’est là que les problèmes ont commencé : il arrivait souvent qu’on nous attribue des IP blacklistées, ce qui compliquait les connexions à AWS ou Google, surtout S3. Et à un moment, il n’y avait même plus de VM disponibles dans notre région, au point que toute nouvelle allocation était bloquée. Au final, Hetzner est excellent tant qu’on n’a pas besoin d’une montée en charge massive, mais dès qu’une vraie capacité d’extension est requise, il a fallu combiner avec d’autres services
Le fait qu’une région soit complètement à court de VM ne me semble pas propre à un cloud en particulier. GCP a connu des situations similaires il y a quelques années. Si on demande d’un coup plusieurs centaines de VM à l’heure de pointe, j’ai l’impression qu’aucun cloud ne l’encaisse bien
Le fait que Microsoft ait bloqué les services Hetzner et Scaleway est bien connu https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. Je ne savais pas qu’AWS et GCP faisaient pareil, mais ça ne me surprend pas énormément. Les Big Cloud justifient ce type de comportement anticoncurrentiel au nom de la « lutte contre le spam entrant », mais en pratique ce n’est pas vraiment le cas
Il est possible qu’on parle ici de deux réalités différentes entre les utilisateurs de matériel Hetzner réel (Server Auction, etc.) et les utilisateurs de serveurs virtuels (VM). Les serveurs physiques offrent un bien meilleur rapport qualité/prix et de meilleures performances, tandis que les VM, sans être révolutionnaires, restent moins chères que celles de la concurrence
Cette controverse concerne l’offre Hetzner Cloud (VM). L’offre cloud est relativement récente comparée aux serveurs dédiés. Beaucoup d’utilisateurs viennent surtout chez Hetzner pour la valeur de leurs serveurs dédiés
Par pure curiosité, quel type de service nécessitait des centaines à des milliers de VM, et pourquoi utiliser des VM plutôt que des serveurs dédiés ? Il semble que la plus grosse VM Hetzner monte à 48 cœurs, 192 Go de RAM et 960 Go de SSD, donc je me demande bien quel besoin justifiait ça
J’ai mes raisons d’utiliser Hetzner, mais il faut garder quelques points en tête. La disponibilité est un peu inférieure à celle d’AWS, et la diversité des régions est plus limitée. C’est pourquoi je recommande vivement de l’utiliser avec Cloudflare. Chez Hetzner, nous faisons tourner le système cœur (K8s), tandis que les données sont réparties via R2/D1/KV et Edge Durable Objects. Les données clients sont shardées par DO, ce qui permet à la fois de répartir la charge sur la base de données centrale et d’améliorer la sécurité
AWS a lui aussi connu, de manière assez surprenante, pas mal de pannes majeures. Au final, sans architecture multi-région, il est structurellement difficile d’éviter les problèmes de disponibilité
J’ai moi aussi conçu une architecture avec le cœur en serveurs dédiés chez Hetzner, du stockage redondé, et des nœuds edge dans le monde entier chez OVH, un peu comme mon propre CDN
Si les données clients sont à l’edge, alors qu’est-ce qui relève exactement du « cœur » ?