製品と開発でAmazonRDSインスタンスを維持するための戦略
Amazon RDSインスタンスをどのように管理していますか？本番環境では、マスタースレーブレプリケーションのセットアップを実行しながらAmazonRDSを使用したいと考えています。残念ながら、これは開発/ QA環境に同様のものを導入するためにかなりのコストがかかりますが、dev/qaを可能な限りprodに近づけるように努めています。日々の取引でそのようなケースをどのように処理しますか？
毎晩のPRODスナップショットを使用し、マイクロインスタンスなどを使用して、稼働時間内（たとえば、0700〜1900）にRDSDEVインスタンスをプログラムでスピンアップおよびスピンダウンします。AWSCLIを使用します。これにより、実行コストが半分になり、ほぼ最新のRDSコピーにアクセスできるようになります。
警告：私はAmazonのサービスを利用しておらず、私たちが話している「追加費用」がどれくらいかわからないので、これは単なる一般的なアドバイスです...
本当の質問は「DevがProductionの正確なミラーである必要がありますか？」だと思います。 -私の答えは「はい、または少なくとも実用的に近い」です。
DevとProdを相互に正確にミラーリングすることの利点（データに関してではなくてもインフラストラクチャに関して）は、Devで障害を誘発することにより、本番環境のフェイルオーバーとフォールトトレランスの側面をテストできることです。これは、少なくともしばらくの間、物事が期待どおりにフェイルオーバー/フェイルバックすることを自分自身に証明するために、コストに見合う価値があるかもしれません。
私の意見では、そのようなテストを定期的に行うことができるので、継続的なコストの価値もあります。フォールトトレランスとリカバリの戦略を定期的にテストしないと、必要な日に機能しない可能性が高くなります。結果として、私の提案は、より高いコストのために湧き出て、障害/回復テストの計画を示し、定期的にその計画に固執することによって、それを執行部に正当化することですスケジュール。
開発と本番が同一であるという利点の1つは、Amazon/Cloud環境にも変換されない可能性があります-流星がメインのデータセンターに衝突した場合、Big Red Handleをプルして、本番オペレーションをその開発インフラストラクチャに移動するオプションもあります-My非クラウドの世界には、本番環境とまったく同じように見えるVMWare開発環境があります。その大きな赤いハンドルを引っ張らなければならなかった場合、本番環境を再構築できるようになるまで、（容量は減りますが）実行を続けることができると確信しています。