Optimisation coûts RDS PostgreSQL sur AWS

Question

on a un rds postgresql énorme (db.m5.8xlarge) qui nous coûte un bras. on l'utilise beaucoup mais pas 100% du temps surtout pas la nuit ou le week end. les métriques cloudwatch montrent qu'on est à 30% d'utilisation cpu en moyenne avec des pics à 70% mais le reste est bas. on cherche à réduire la facture sans casser la prod
-- Exemple de requêtes lourdes
SELECT count(*) FROM large_table WHERE created_at < NOW() - INTERVAL '1 day';
UPDATE another_large_table SET status = 'processed' WHERE id IN (SELECT id FROM some_queue);

gay-monique · Answer

L'option Aurora Serverless v2 est faite pour ça si votre base est compatible. Ça scale la capacité (et le coût) en fonction de la charge. Pour du M5.8xl, ça peut être une belle économie. Mais il faut tester la compatibilité avec vos requêtes complexes.

simon-marcel · Answer

Ou alors tu regardes les Reserved Instances (RI) si l'usage moyen est prévisible mais pas constant. Tu paies un engagement pour 1 ou 3 ans et ça réduit beaucoup le coût horaire. Si t'es à 30% d'utilisation CPU mais que tu ne peux pas réduire la taille de l'instance, une RI est souvent rentable. Fais les calculs c'est souvent bluffant.

alphonse-pons · Answer

Y'a aussi la possibilité de "downscaler" la nuit/weekend avec un script lambda ou via des runbooks SSM. Tu peux passer d'un m5.8xl à un m5.2xl ou moins puis "upscaler" le matin. Faut gérer la fenêtre d'indisponibilité par contre c'est un reboot.

jeannine07 · Answer

serverless v2 j'ai un peu peur des migrations et des perfs sur nos requêtes complexes. Les RI on y a pensé mais on est pas sûr de l'engagement 3 ans. le downscaler c'est intéressant. combien de temps ça prend pour un m5.8xl ?

gay-monique · Answer

Le downscale/upscale d'une instance RDS ça prend entre 5 et 15 minutes généralement, dépendant de la taille et de la charge. Y'a un redémarrage de la DB à chaque fois. Faut bien valider les fenêtres de maintenance et les impacts sur les apps.

simon-marcel · Answer

Pour les RI, même sur un an, ça peut valoir le coup. Fais une analyse des coûts sur les 6 derniers mois. Si tu es toujours sur cette instance, même à 30% CPU, c très probable qu'une RI te fasse économiser pas mal. Et tu peux revendre les RI sur le marketplace si tu changes d'avis.

qandre · Answer

Une autre piste si vous avez beaucoup de lecture, c'est de passer certaines requêtes sur des read replicas. Ça décharge l'instance primaire et permet potentiellement de réduire sa taille. Ça aide pas pour les updates par contre. Et si t'as des requêtes très spécifiques qui bouffent beaucoup, analyse les avec Performance Insights pour voir si y'a pas moyen d'optimiser le SQL directement.

alphonse-pons · Answer

oui performance insights c'est clé. un index manquant ou une requête mal écrite peut faire sauter un cpu même sur une grosse instance. ça vaut le coup d'investir un peu de temps là-dedans avant de scaler.

jeannine07 · Answer

on a quelques read replicas mais pas tous les services les utilisent. faudra qu'on regarde ça de plus près. je vais commencer par les RI sur 1 an et le downscaler la nuit/WE. thx pour les idées c'est super utile

Optimisation coûts RDS PostgreSQL sur AWS

Commentaires

Laisser une réponse

Guide Complet pour la Gestion des Logs en Environnement DevOps

Explication pas à pas du programme GO hello world

Les attaques TeamPCP : Votre pipeline CI/CD est la nouvelle ligne de défense

Rejoindre la communauté