Tirez le maximum du système dont vous disposez

• L’article évoque l’expérience de l’auteur dans la gestion des performances de Postgres au sein d’une application SaaS, où la base de données avait du mal à supporter la charge.
• L’équipe de l’auteur a procédé à une montée en charge verticale en remplaçant la base de données par une instance plus grande chaque fois qu’elle devenait trop sollicitée. Mais comme ils utilisaient déjà la plus grande instance disponible, ils étaient sur le point d’atteindre un état de surcharge.
• Deux solutions possibles ont été proposées : shardiser les écritures sur des clusters de bases de données indépendants, et découper le monolithe en plusieurs services interconnectés (microservices).
• Les deux solutions augmenteraient la capacité et offriraient des options intéressantes en matière de tolérance aux pannes et de résilience opérationnelle, mais elles accroîtraient fortement la complexité.
• L’auteur affirme que le véritable coût de l’augmentation de la complexité est l’attention qu’elle exige, ce qui complique ensuite toutes les décisions techniques.
• L’auteur suggère qu’avant d’augmenter fortement la complexité, il existe généralement une possibilité de « tirer » un peu plus de performances du système existant en ajustant la charge de travail, en optimisant les performances ou en complétant le système d’une manière ou d’une autre.
• Dans leur cas, en optimisant des requêtes lourdes, en ajustant les paramètres de Postgres et en déportant certaines requêtes en lecture seule coûteuses vers une base de données répliquée, ils ont réduit l’utilisation maximale hebdomadaire du CPU de la base de données de 90 % à 30 %.
• L’auteur conclut que la complexité est parfois nécessaire et inévitable, mais qu’il est préférable d’en retarder l’augmentation aussi longtemps que possible et d’extraire d’abord autant de performances que possible du système existant.

[GN⁺]

Avis Hacker News

• L’article souligne l’importance d’exploiter au maximum le potentiel du système existant avant d’envisager un remplacement ou une mise à niveau.
• Il suggère que les équipes devraient tirer parti de ce qu’elles ont déjà, même si ce n’est pas parfait, et trouver des moyens d’atteindre leurs objectifs avec les ressources existantes.
• Il aborde l’idée de concevoir l’application de manière à éviter les jointures dans la base de données, en suggérant que le stockage est peu coûteux et que tout devrait être dénormalisé puis mis à jour dans les transactions.
• L’usage d’UUID est proposé pour éviter les hot partitions et permettre une montée en charge horizontale, plutôt que de dépendre d’entiers qui peuvent finir par poser problème.
• Un exemple concret est partagé, où une équipe a fortement amélioré les performances de son système en changeant son approche de résolution du problème au lieu d’ajouter davantage de matériel ou de complexité.
• L’article déconseille de découper d’un seul coup un monolithe en plusieurs services connectés, et propose plutôt d’identifier la séparation qui aura l’impact le plus important.
• Il insiste sur l’importance d’optimiser les requêtes dans les applications web construites sur un ORM, où il existe souvent une grande marge d’amélioration.
• Il met en garde contre la charge mentale et la complexité liées au travail sur des systèmes de microservices, qui entraînent souvent des temps d’arrêt et de la confusion.
• Il distingue l’efficacité (minimiser les pertes et éviter la complexité) de l’optimisation (utiliser des algorithmes spécialisés au prix d’une complexité supplémentaire).
• Il partage des inquiétudes concernant la migration vers une infrastructure plus complexe, en suggérant que ce n’est peut-être pas la solution miracle attendue par tous.
• Il défend la simplicité plutôt que la complexité, surtout lorsque les ressources sont limitées et que le système n’est pas particulièrement critique.
• Enfin, l’article évoque le sharding par tenant (client) comme solution potentielle aux problèmes de scalabilité.