Comment les gens gèrent-ils leurs instances Amazon RDS ? En production, je veux évidemment utiliser Amazon RDS avec une configuration de réplication maître-esclave. Malheureusement, cela entraîne des coûts substantiels pour introduire quelque chose de similaire dans un environnement de développement/qa, alors que nous nous efforçons de garder le dev/qa aussi proche de la production que possible. Comment gérez-vous un tel cas dans vos activités quotidiennes ?
Réponses
Trop de publicités?CAVEAT : Je n'utilise pas les services d'Amazon, et je ne sais pas de combien de "coûts supplémentaires" nous parlons, donc ce ne sont que des conseils généraux...
Je suppose que la vraie question est "Avez-vous besoin que Dev soit un miroir exact de la production ?" - Ma réponse serait "Oui, ou du moins aussi proche que possible".
L'avantage de faire en sorte que Dev et Prod soient des miroirs exacts l'un de l'autre (au niveau de l'infrastructure, sinon des données) est que vous pouvez tester les aspects de basculement et de tolérance aux pannes de votre environnement de production en provoquant des pannes dans Dev. Cela peut valoir le coup, au moins pendant un certain temps, pour vous prouver que les choses basculeront/réapparaîtront comme vous l'attendez.
À mon avis, le coût permanent en vaut la peine, car il vous permet de faire ce genre de tests régulièrement. Si vous ne testez pas régulièrement votre stratégie de tolérance aux pannes et de récupération, il y a de grandes chances qu'elle ne fonctionne pas le jour où vous en aurez besoin. En conséquence, ma suggestion est de Spring pour le coût le plus élevé, et de le justifier auprès des bureaux exécutifs en leur montrant un plan de test de tolérance aux pannes/récupération et de récupération. s'en tenir à ce plan à intervalles réguliers.
L'un des avantages de l'identité des environnements de développement et de production, qui ne se traduit pas nécessairement aussi bien dans les environnements Amazon/Cloud, est que vous avez également la possibilité de retirer la grande poignée rouge et de transférer les opérations de production sur cette infrastructure de développement si un météore frappe votre centre de données principal. Si je devais un jour retirer la grande poignée rouge, je suis sûr que nous pourrions continuer à fonctionner (bien qu'à une capacité réduite) jusqu'à ce que nous puissions reconstruire l'environnement de production.
Utilisez vos snapshots nocturnes de PROD, et instaurez une micro instance ou similaire pour programmer le démarrage et l'arrêt des instances RDS DEV pendant les heures de travail, disons entre 0700 et 1900. Utilisez l'AWS CLI. Cela réduira de moitié votre coût d'exploitation et vous donnera accès à une copie RDS presque à jour.