"c'est dingue, la BdD MySQL ou PostgreSQL sur mon VPS pourtant surdimensionné rame !!" Effectivement, c'est un mauvais choix....Pourquoi ? Car la plupart des VPS (ex OVH, Scaleway et autres..) utilisent des disques durs réseaux de type Block Storage (ex AWS EBS) qui ont une latence (réseau) beaucoup plus grande que des disques SSD NVMe attachés localement. Et au final, les écarts de performance sont très importants : Burak Yücesoy a écrit un article très détaillé là-dessus (cf commentaire). Malgré les optimisations, il estime que le rapport de performance est d'environ x3 en faveur des disques locaux. "Oui, mais justement le block storage, c'est bien pratique : on peut l'attacher à un autre VPS, en faire des snapshots, changer sa taille à la volée.." Tout cela est vrai, mais au détriment de la performance. "Comment, dans le cas de disques physiques, assurer la haute disponibilité et reprise d'activité de la DB sans perte ?" Par la réplication synchrone et asynchrone au niveau de la BdD. C'est complexe à mettre en place et à maintenir, c'est pourquoi la plupart des opérateurs Cloud proposent des bases de données managées *avec des disques locaux* incluant la gestion de serveurs replica.

Dans de nombreux projets où j'interviens, la #performance base de données est un point de tension : forte charge lors des pics de trafic qui aboutissent à de la contention sur le nœud principal, et donc des latences inacceptables pour les utilisateurs. Pourtant, une optimisation simple reste souvent sous-utilisée : router les requêtes de lecture vers des réplicas. Plusieurs approches permettent de le faire proprement : - l’utilisation d’un proxy intelligent comme #ProxySQL, - ou l’exploitation des endpoints “Primary” et “Reader/Replica” proposés nativement par les opérateurs cloud de DB managées (ex #AWS #RDS) L’intérêt est double : D’abord, la #performance : répartir les requêtes de lecture réduit considérablement la pression sur l’instance primaire, qui peut se concentrer sur les opérations d’écriture et de transactions critiques. Les réplicas absorbent le reste, améliorant le débit global et la réactivité de l’application, surtout lors des montées en charge. Ensuite, le #coût. Sur RDS, augmenter la capacité du nœud principal peut devenir rapidement onéreux. Exploiter des réplicas moins coûteux permet de scaler horizontalement pour les lectures sans basculer sur une classe d’instance plus large. De plus, ces replicas sont souvent existants pour des raisons de haute disponibilité mais non exploités, ce qui engendre un gâchis. ProxySQL va encore plus loin en appliquant des règles intelligentes, du caching ou du failover automatique, ce qui permet un usage plus efficace des ressources existantes. Au final, router intelligemment les lectures vers des réplicas est un levier simple pour alléger le nœud principal, absorber plus de trafic et réduire la facture cloud, tout en gagnant en disponibilité. Une optimisation pragmatique, efficace et accessible dans la plupart des architectures modernes. La difficulté, comme bien souvent est organisationnelle : méconnaissance des développeurs et/ou de l'équipe infra chacun considérant ce sujet comme hors de leur sphère d'expertise...

#OpenTelemetry Collector : l'ombre d'un doute.. OpenTelemetry (Otel) est un ensemble open source de standards, bibliothèques et outils permettant de collecter, corréler et exporter des données de télémétrie (traces, métriques, logs, profiles) afin de faciliter l’observabilité des applications et systèmes. Dans une chaîne d’observabilité, l’OpenTelemetry Collector reçoit, transforme et exporte les données de télémétrie depuis les applications avec un protocole standardisé (OTLP), tandis que le backend (ex. stack Grafana LGTM, Datadog, Dynatrace, New Relic, Splunk, Elastic , Honeycomb ... ) les stocke, analyse et visualise pour l’observation et le diagnostic. La promesse pour les utilisateurs est d'utiliser un Collector neutre et standardisé et de le conserver même en cas de changement de backend, et ainsi éviter des opérations lourdes de décomissionnement, déploiement, etc.. Or je viens de voir 2 contenus (sources plus bas): - Datadog explique que le composant logiciel OpenTelemetry-Collector-contrib n'est pas destiné à être utilisé tel quel en production, et doit être repackagé (de façon assez complexe) - Grafana Labs recommande clairement d'utiliser son agent Alloy pour faire office de collecteur opentelemetry Mais donc... cela veut dire qu'il faudrait utiliser le collecteur de l'éditeur de votre backend or c'est exactement ce que OTel était censé éviter !! J'y vois un glissement de narratif et une prise en main d'Otel par les éditeurs... Est-ce du FUD ? Oui bien est-ce que le opentelemetry-collector-contrib n'a pas le même niveau de qualité que celui des éditeurs ? Qu'en pensez-vous ? Avez-vous le même sentiment ? PS : Ce post traite bien uniquement du composant Opentelemetry Collector et pas des SDK OpenTelemetry d'instrumentation des langages (Java, .Net, C++, Python, Golang, PHP..) -- Sources Datadog : https://lnkd.in/eYztZjgi Grafana Labs: https://lnkd.in/e8CYSAyc Recommandation Otel-collector-contrib : https://lnkd.in/exUsTacf Schema Otel : https://lnkd.in/eA4nPknH

Votre site web est trop lent ? 4 actions pour améliorer le temps de chargement : 1) Placer un #CDN (Content-Delivery Network) devant votre site C'est assez simple et parfois gratuit (cf #Cloudflare) La plupart de vos ressources statiques (images, css, js...) devraient être mises en #cache, les #bots et les attaques seront filtrés ; votre serveur #Origine est soulagé et répond plus rapidement 2) Corriger les "#CacheControl" et dissocier les "Set-Cookies" Des "cache-control" non maîtrisés (hello "no-store" !) peuvent empêcher la mise en cache de vos ressources statiques au niveau du CDN et/ou des navigateurs. Rappel : les CDN ne mettent pas en cache les pages qui délivrent des #Cookies ou certaines extensions de fichiers par défaut (mais on peut toujours créer des #CacheRule avec doigté). 3) Activer Cloudflare Cache Reserve En supposant que le Cache-Control : #max-age soit pertinent ( je vois souvent 4h !) , le CDN ne gardera pas pour autant vos fichiers si votre traffic est insuffisant ou si un #POP (Datacenter local du CDN) manque d'espace de stockage Je vois parfois des clients (tenter de) monter des infras mondiales de "chauffage" de cache CDN pour contrer ce phénomène localisé d' #éviction Meilleure solution : activer l'option "payante" pour garantir que vos ressources statiques restent en cache jusqu'à 1 mois dans les POPs en question. 4) Mettre en place Cloudflare Images Cette solution (payante) est radicale : directement stocker vos images dans l'ensemble des POPs de votre CDN. Même si le cache local est vide, vos images sont présentes localement grâce à une synchro mondiale orchestrée par le CDN, et donc délivrées très rapidement à vos visiteurs. Bonus : le CDN peut opérer des transformations sur les images (changement de taille ou de résolution, ajout d'un filigrane...) en soulageant votre serveur Origine. Contrainte : il faut modifier vos URLs d'images, ou bien les ré-écrire en périphérie (grâce à des Workers par exemple) Et vous, avez-vous d'autres conseils ? Avez-vous des retours d'expérience à partager ?

2025 et toujours ce "statefile" #Terraform fragile et monolithique.... Pas l'impression qu'#Opentofu avance véritablement sur ce sujet....