Optimisation RDS multi-AZ faut que ça crache moins
Membre depuis le 02/09/2024
salut la communauté
on a une base de données mysql sur rds multi-az et la facture amazon est salée. on cherche des pistes pour réduire les coûts sans non plus casser la prod. on a besoin du multi-az pour la dispo mais y a pas moyen de faire des économies dessus ? genre on utilise à peine 10% du cpu de l'instance primaire et la secondaire tourne à vide quasi. c'est du db.m5.large. toute astuce est bonne à prendre
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
Commentaires
paul43
Membre depuis le 29/12/2024
yo
le multi-az double le coût de l'instance c'est normal. si tu peux te permettre une petite interruption lors d'un crash, une option c'est de passer en single-az et de mettre en place des snapshots réguliers ou d'utiliser une réplica en read-only dans une autre az que tu peux promouvoir manuellement en cas de pépin. c'est moins cher mais moins "auto-failover"
lombard-benjamin
Membre depuis le 24/10/2024
si tu veux garder le multi-az, le plus évident c'est de réduire la taille de l'instance. si tu es à 10% d'utilisation cpu sur un m5.large, tu peux ptete descendre sur un m5.medium ou même un t3.large (attention les burstables) si ton workload est pas trop critique en perfs sur la durée
theodore66
Membre depuis le 02/09/2024
la réduction de taille j'y ai pensé mais j'ai peur de manquer de ram sur des pics inattendus. le passage en single-az est risqué, on préfère garder le multi-az. y'a pas des options genre "pause" la secondaire ou un truc du genre ?
paul43
Membre depuis le 29/12/2024
non y'a pas de "pause" pour la secondaire multi-az, elle doit être synchro en permanence. par contre, regarde les reserved instances. si tu t'engages sur 1 ou 3 ans, tu peux faire de grosses économies même en multi-az. ça réduit pas la taille mais le prix unitaire
dominique07
Membre depuis le 27/06/2024
et si tu n'as pas besoin d'un failover ultra rapide, tu peux utiliser un cluster Aurora Serverless v2. ça gère l'auto-scaling et le multi-az de manière plus fine et tu payes à l'usage réel. ça peut être significativement moins cher si ton workload est très variable
lombard-benjamin
Membre depuis le 24/10/2024
une autre piste c'est d'optimiser tes queries sql. si tes requêtes sont lentes et mal indexées, elles surchargent le cpu pour rien. ça peut paraître évident mais c'est souvent la source de surdimensionnement d'instance
theodore66
Membre depuis le 02/09/2024
ok les reserved instances je vais regarder ça de près pour voir la réduction. Aurora Serverless v2 c'est une piste intéressante mais ça demande plus de refonte. pour les queries on y travaille mais c'est un chantier long. la reserved instance me semble le plus rapide à mettre en place avec un impact direct. merci pour les tips !