Utilisez un seul gros serveur (2022)

• L’essentiel du débat n’est pas monolithique vs microservices, mais de déterminer si un système distribué vaut sa valeur au regard de la surcharge de développement et d’exploitation
• Un serveur moderne unique dispose de dizaines à centaines de cœurs, de mémoire à l’échelle du To et d’E/S à plusieurs dizaines ou centaines de Gbit/s, avec une marge de performance suffisante pour la plupart des services web
• Des benchmarks réels montrent qu’un seul serveur peut assurer des traitements haute performance comme Nginx à 500 000 RPS, PostgreSQL à 70 000 IOPS, NoSQL à 1 million d’IOPS, encodage 4K à 75 FPS
• Le cloud améliore la commodité et la disponibilité, mais sa prime tarifaire est importante et doit être évaluée en termes de retour sur investissement
• Les architectures cloud native et serverless ne deviennent avantageuses en coût que lorsque les schémas d’usage sont extrêmement variables
• Mais la prime de coût du serverless et des micro-VM est élevée, et si la charge est continue et prévisible, la montée en charge verticale est plus économique
• La disponibilité peut être largement assurée avec une redondance primaire/secondaire (ou 2×2) et des combinaisons de matériel hétérogènes, tandis qu’une stratégie consistant à ne distribuer que le CDN et les sauvegardes est raisonnable

---

Vue d’ensemble : la valeur d’« un gros serveur » face aux systèmes distribués

• Le cœur du débat « monolithique vs microservices » réside dans l’évaluation de la valeur réelle, en temps développeur et en coûts, de l’adoption d’un système distribué
• Les logiciels modernes fonctionnent sur la virtualisation des serveurs et diverses couches d’abstraction, et même le « serverless » ou le « bare metal » reposent au final sur des ressources de serveurs physiques
• Les serveurs d’aujourd’hui offrent une excellente efficacité coût/performance, bien supérieure à ce qu’on imagine souvent
  • Par rapport au passé, les spécifications ont énormément progressé en nombre de cœurs, bande passante mémoire, lignes PCIe et stockage NVMe, et de nombreux services peuvent atteindre leur QPS cible sans distribution

La puissance du matériel serveur

• Le serveur d’exemple de Microsoft Azure embarque 2 CPU serveur AMD de 3e génération, pour un total de 128 cœurs et 256 threads
• Un seul serveur peut atteindre environ 4 TFLOPs de performance de calcul, soit davantage que des supercalculateurs du début des années 2000
• Avec 16 emplacements DDR4-3200 par socket, l’évolutivité mémoire monte jusqu’à 8 To, et même des circuits d’achat pratiques permettent 1 To de RAM
• Au total, 128 lignes PCIe Gen4 permettent d’ajouter 30 SSD NVMe et des cartes réseau à 50–100 Gbit/s pour du stockage et du réseau hautes performances

Ce qu’un tel serveur unique permet de faire (benchmarks à l’appui)

• Il est possible d’atteindre 400–800 Gbit/s de transmission vidéo, 1 million d’IOPS NoSQL, 70 000 IOPS PostgreSQL, 500 000 RPS avec Nginx
• On observe aussi un fort débit sur des tâches intensives en CPU, mémoire et E/S, comme la compilation du noyau Linux en 20 secondes ou l’encodage x264 4K à 75 FPS

Comparaison des coûts de location et d’achat des serveurs

• OVHCloud : un serveur 128 cœurs / 512 Go de RAM peut être loué pour environ 1 318 $ par mois
• Hetzner : un serveur 32 cœurs / 128 Go de RAM est proposé à 140 € par mois, avec des tarifs variables selon la taille
• AWS m6a.metal : un serveur 96 cœurs physiques / 768 Go de RAM coûte 8,29 $ de l’heure, soit environ 6 055 $ par mois, ce qui illustre une forte prime cloud
• En achetant directement chez Dell un serveur de spécifications comparables pour environ 40 000 $, l’investissement peut être amorti par rapport au cloud en environ 8 mois
• À débit identique en serverless, on estime une prime de coût de 5,5× par rapport aux instances et de 25× par rapport à un hébergement à bas coût

Pourquoi les systèmes distribués ont-ils autant séduit ?

• Par le passé (autour de 2010), les limites des CPU, de la mémoire et du stockage imposaient à grande échelle de combiner plusieurs serveurs
• Mais avec les gros serveurs modernes, les SSD NVMe et une bande passante mémoire élevée, les limites de traitement sur nœud unique ont fortement progressé, alors que les VM et conteneurs restent conçus à l’échelle de petites ressources serveur

Quand un seul gros serveur suffit

• La plupart des services web sous 10k QPS tiennent sur une seule machine, et les services simples peuvent même monter jusqu’à un million de QPS
• Même pour le streaming vidéo, il est réaliste d’avoir le control plane sur un seul serveur, et des benchmarks ainsi que des tableaux de performance génériques permettent d’estimer la bonne taille de serveur
• Hors cas particuliers, une configuration avec serveur principal et serveur de secours suffit aussi pour garantir la disponibilité

« Plus haut » plutôt que « plus large » : préférer quelques gros serveurs à une grande flotte de petits

• Même lorsqu’un cluster est nécessaire, quelques gros serveurs impliquent une surcharge de coordination O(n) plus faible qu’une multitude de petits serveurs
  • En d’autres termes, à long terme, il est plus efficace de réduire le nombre de serveurs et d’en augmenter la capacité
• Dans les environnements serverless ou à base de conteneurs éphémères, cette surcharge relative devient particulièrement importante
• Le point faible est le point de défaillance unique, mais il peut être largement atténué avec une architecture primaire/secondaire (dans des DC différents)
• Pour plus de robustesse, une configuration 2×2 (2 serveurs dans le DC principal + 2 dans le DC secondaire) et des déploiements sur du matériel et des constructeurs différents permettent d’éviter les pannes corrélées
• En location, la diversification des modèles de serveurs peut réduire le risque de pannes en chaîne liées à des disques ou SSD issus du même lot

Les avantages et les limites du cloud

• Le cloud brille par sa disponibilité, sa rapidité de reprise et sa simplicité opérationnelle, et il peut être légitime de payer cette prime tarifaire
  • Il permet un redémarrage rapide dans la limite du budget, sans indisponibilités prolongées, et donne accès à de vastes pools de ressources gérés comme une grille
  • Les fournisseurs de serveurs loués sont moins chers, mais ont des limites en matière de qualité, de réseau ou de support premium
• En revanche, les offres cloud poussent souvent des architectures dépendantes du fournisseur comme les VM autoscalées, le serverless ou les bases HA managées ; il faut donc rester vigilant sur les coûts et la complexité
• La gestion d’un trafic massif n’est pas, en soi, la principale raison d’adopter du cloud native, et il existe de nombreux cas où un seul gros serveur permet de servir des millions d’utilisateurs simultanément

Coût des pointes de charge et critère des charges bursty

• Quelqu’un doit provisionner pour le pic, donc le coût du pic finit toujours par être facturé quelque part dans la chaîne d’approvisionnement
• Pour des charges bursty et temporaires (par exemple une grosse simulation ponctuelle), le serverless / l’autoscaling est économique, mais pour des charges continues et prévisibles, l’exploitation fixe d’un gros serveur est plus efficace en coût
• En tirant parti d’engagements d’un an, d’instances spot ou de négociations commerciales, le coût des instances peut encore baisser, ce qui creuse davantage l’écart de prime avec le serverless

Évaluation quantitative de la « prime cloud »

• Le serverless computing comme AWS Lambda peut entraîner une prime de coût de 5 à 30× par rapport à un serveur équivalent
• Hypothèse : si un serveur à 8,2944 $/heure fournit 1k QPS et 768 Go de RAM, le remplacer par Lambda à débit égal reviendrait à environ 46 $/heure, soit une prime de 5,5×
• On estime une prime de 25× par rapport à la location OVH, et avec seulement 5 % de taux d’utilisation, un hébergement à bas coût devient déjà plus économique que le serverless
  • Avec des contrats longue durée ou des instances spot, l’écart de prime peut encore augmenter
• Même si le QPS varie, la conversion en mémoire-temps donne des multiplicateurs de prime similaires, et l’essentiel est d’adapter l’échelle du serveur à la taille réelle de la charge

Objections et malentendus fréquents

• « Avec le cloud, plus besoin d’équipe d’exploitation » : seul l’intitulé change en Cloud Ops ; il faut toujours des compétences en documentation, traçabilité des changements et gestion des dépréciations, ce qui peut même augmenter les coûts humains
• « Avec le cloud, plus besoin d’appliquer les mises à jour de sécurité » : certaines tâches sont externalisées, mais seulement dans des domaines faciles à automatiser ; les audits de bibliothèques et la vérification des configurations restent nécessaires
• « Le cloud rassure grâce à sa haute disponibilité » : la complexité supplémentaire crée de nouvelles fragilités, et même une redondance entre régions ou fournisseurs n’élimine pas complètement les pannes corrélées
• « Le cloud accélère le développement » : l’agilité initiale est un vrai atout, mais il faut surveiller le point d’inflexion des coûts pour basculer au bon moment
• « Notre trafic est très bursty » : dans ce cas, le serverless et l’autoscaling sont adaptés
• « Et le CDN ? » : la réduction de latence et de bande passante fait partie des éléments qu’il est indispensable d’acheter en mode distribué, tout comme les sauvegardes

Monolithique vs microservices et structure serveur

• Le « gros serveur » est naturellement associé à une architecture monolithique, mais il est aussi possible d’exécuter des microservices sous forme de plusieurs conteneurs sur une seule machine
  • Toutefois, la surcharge de communication inter-processus, de déploiement et d’observabilité reste pénalisante même sur un hôte unique, ce qui réduit fortement le bénéfice réel au regard de la complexité
• Pour les phases initiales ou les structures de petite à moyenne taille, un monolithe ou un petit nombre de services est plus avantageux en termes de simplicité opérationnelle

Conclusion

• Dans la majorité des cas, choisir la montée en charge verticale (un seul gros serveur) est plus simple et plus économique qu’une mise à l’échelle horizontale ou une architecture centrée sur le cloud
• En combinant redondance primaire/secondaire, matériel hétérogène et externalisation du CDN/des sauvegardes, on peut obtenir une fiabilité pragmatique tout en gardant un avantage net en coût total de possession (TCO) dans les environnements à charge continue
• À condition de mettre en place une stratégie solide de redondance matérielle, l’approche du « gros serveur unique » constitue un choix très adapté à des services réels