There is no cloud. It’s just someone else’s computer

Même si j’ai suivi le virage du cloud, j’ai toujours souhaité garder un pied dans l’infrastructure et le système ¹.

Je pense qu’il est indispensable de maintenir ce type de connaissances pour comprendre les problématiques de performance.

Cela me permet aujourd’hui de construire des infrastructures complètes pour des clients pour différentes raisons :

• Gros acteur public qui possède déjà une infrastructure physique et ne souhaite pas dépendre d’un cloud provider.
• Recherche de performances : des serveurs dédiés avec stockage local sont bien plus performance que les instances dans le cloud.
• Economiques : quand l’infrastructure devient conséquente, le cloud peut s’avérer très cher.

Je constate depuis le courant de l’année 2023 un virement à propos du cloud et visiblement, je ne suis pas le seul à partager ce constat :

• Les DSI reviennent sur leurs stratégies 100% cloud - 01 Mars 2024 “L’abandon du cloud a été un thème important en 2023 et il y a de fortes chances qu’il devienne une véritable tendance en 2024. Les économies sont tout simplement trop importantes pour être ignorées par un grand nombre d’entreprises”
• FinOps : les mentalités évoluent, les dépassements de budget restent - 17 Avril 2024 “7 entreprises sur 10 ne parviennent toujours pas à tenir leur budget cloud, faute de visibilité suffisante et de capacité à intégrer le contrôle des coûts dès les phases amont des projets”

David Heinemeier Hansson, créateur du framework Ruby On Rails a écris de nombreux articles à ce sujet :

• Why we’re leaving the cloud
• Our cloud exit has already yielded $1m/year in savings
• The Big Cloud Exit FAQ
• We have left the cloud
• Cloud exit pays off in performance too
• Five values guiding our cloud exit
• Hardware is fun again
• We stand to save $7m over five years from our cloud exit
• The hardware we need for our cloud exit has arrived

TL;DR :

• Ils ont déployé plusieurs serveurs physique sur deux sites séparés (4000 vCPUs, 7680GB de RAM, et 384TB de stockage NVMe)
• Ils vont économiser 7 millions 10 millions de dollars sur 5 ans.
• L’achat du matériel a été rentabilisé en 6 mois.
• Les performances sont bien meilleures.

Exemple d’architecture

Voici un exemple d’architecture que j’ai réalisé pour un client :

• 1 primaire et 5 réplicas : 2 synchrones, 2 asynchrones en cascade
• Serveur Postgres :
  • AMD EPYC 9354 32-Core / 64 threads
  • 512Go RAM DDR5
  • 5.5To de stockage NVMe utile (plusieurs millions d’IOPS)
  • Réseau en 25 Gb/s
• Sauvegarde “locale” :
  • Point In Time Recovery
  • AMD EPYC 9124 16-Core
  • 128Go DDR5
  • 15To de stockage utile en NVMe
  • Réseau en 25 Gb/s
• Sauvegarde externalisée sur équivalent S3
• Cout : environ 4000€HT/mois vs plus de 300 000$/mois sur AWS RDS. Les performances sont même meilleures grace au stockage.
• Temps de sauvegarde pour une base de 1To moins de 5 minutes pour une sauvegarde full, quelques secondes pour sauvegarde différentielle.
• Temps de restauration 5 minutes.
• Tuning Linux : RAID, Kernel…
• Tuning Postgres
• Rédaction des procédures d’installation, sauvegardes / restauration, bascules…

Bien sûr, il m’est arrivé de réaliser des architectures plus modestes :

• Sur des machines virtuelles
• Avec un pooler de connexion (PgBouncer)
• Accompagnement sur supervision : Datadog, Nagios like (Icinga, Thruk) avec check_pgactivity.