AWSEC2インスタンスの自動スケーリングの混乱
ですから、最初に私はAWSにまったく慣れていないので、我慢してください。
1つのインスタンスを数か月間実行してきましたが、トラフィックの急増が大きくなり、ときどき過負荷になるため、インスタンスを自動スケーリングする必要があります。
それで、私がこれまでにしたことを見てみましょう。皆さんは、私がどこで失敗したのか、そして私が別の方法で何をしなければならないのかを教えてくれます。
- 最初に、メインインスタンスが1つあるロードバランサーを作成しました。これを「インスタンスA」と呼びます。
- 次に、CPU負荷を監視する「インスタンスA」で2つのCloudWatchアラームを作成しました。次に「インスタンスA」の画像を作成しました
- 次に、新しく作成したAMIにリンクする起動構成を作成しました。
- 次に、自動スケーリンググループを作成し、それをロードバランサーにリンクし、以前に設定した2つのスケーリングアラームも設定しました。
- AutoScalingグループの最小値を0に、最大値を3に設定しました。これは、元のインスタンス（インスタンスA）が容量を超えたときにのみインスタンスの起動を開始するためです。
したがって、基本的には、元のインスタンスを常に実行する必要があります。次に、容量を超え始めたら、Auto Scaling Groupがインスタンスの起動を開始し、LoadBalancerがインスタンス間で負荷を分散するようにします。ここでの私の考えは正しいですか？
その他の重要な質問。
元のインスタンスにコードとデータを変更する場合、起動構成で使用するイメージを再作成する必要がありますか？
DNS名とIPで何をダウンさせる必要がありますか？現在Route53を使用していますが、ロードバランサーを指すようにしていますか？それだけですか？
みんなありがとう！
あなたの質問を調べてみましょう。
したがって、基本的には、元のインスタンスを常に実行する必要があります。次に、容量を超え始めたら、Auto Scaling Groupがインスタンスの起動を開始し、LoadBalancerがインスタンス間で負荷を分散するようにします。ここでの私の考えは正しいですか？
はいと言いますが、いくつか予約があります。私が正しく理解していれば、「メイン」インスタンスを自動スケーリンググループの外に配置しました。理論的には、自動スケーリングによって元のインスタンスが強制終了されないことが保証されます。私が言及したいことがいくつかあります：
- AutoScalingの可能性を十分に活用していません。 Auto Scalingを使用すると、セットアップをスケーリングできるだけでなく、制限を確保することもできます。何らかの理由で「メイン」インスタンスが停止した場合、自動スケーリングポリシーは実行されません。インスタンスを
min-sizeが1の自動スケーリンググループに保持すると、自動スケーリングによって障害が発生したインスタンスが自動的に置き換えられます。 - 自動スケーリングの場合、復元力のあるシステムを構築する方法であるため、インスタンスを「使い捨て」として扱うことが多くの場合ベストプラクティスです。常に利用可能であるために1つのインスタンスに依存しないでください。
- 自動スケーリンググループの終了ポリシーを設定して、常に最新のインスタンスを最初に終了するようにすることができます。これにより、「メイン」インスタンスが（正常である限り）保持されます。私の以前のコメントはまだ当てはまります。
元のインスタンスにコードとデータを変更する場合、起動構成で使用するイメージを再作成する必要がありますか？
noと言いますが、それは設計上の問題です。イメージはサーバーの状態を記述している必要がありますが、コードの配布を担当するべきではありません。緊急のバグのためにアプリケーションを更新する必要があるが、サーバーに高負荷がかかっている状況を考えてみてください。メインサーバーの更新、AMIの作成、起動構成の更新、自動スケーリングされたサーバーの強制終了により、最新のAMIで再生成できるようになりましたか？魅力的なソリューションのように聞こえますか？それに対する私の答えはno（再び）です。ソースコードのバージョン管理と展開の戦略を調べてください（私はRails開発者の60％で、たとえばgitとcapistranoを使用しています）。
あなたのアプローチもうまくいく状況があり、ここには多くの中間点があります（Chefおよびuserdataスクリプトも調べることをお勧めします）。 Chefのおかげで、私自身は実際にカスタムAMIを使用することはめったにありません。
DNS名とIPで何をダウンさせる必要がありますか？現在Route53を使用していますが、ロードバランサーを指すようにしていますか？それだけですか？
基本的に、はい。自動スケーリンググループを作成するときに、新しいインスタンスにアタッチする必要があるロードバランサーを選択できます。 Auto ScalingのGUIはまだ使用していませんが、どこかにあると確信しています。そうでない場合でも、CLIはそれをサポートします。 Route53レコードをELBaliasにポイントすると、基本的にはそれだけです。
追加の質問への回答（2014/02/23）：
Railsを使用して開発している場合は、デプロイに Capistrano を強くお勧めします。これにより、アプリの特定のバージョンを好みのバージョン管理システム（gitなど）に取り込んで、複数のサーバーにデプロイできます。特定の環境で。そこにはたくさんのチュートリアルがありますが、Ryan Batesの改訂された（そしてプロの）Railscastは非常に簡潔ですが、両方を見るには彼のWebサイトへのサブスクリプションが必要です。他のチュートリアルのほとんどは、あなたも同様に進むことができます。 AMIと、gitリポジトリの一時的なクローンをプルし、ローカルのCapistranoコマンドを実行してアプリを実行する起動スクリプトを使用して、新しいサーバーを起動します。これにより、後で、実行中のすべてのサーバーに1つのコマンドでCapistranoを使用してアプリケーションの新しいバージョンをデプロイすることもできます。
Capistranoには、他にもいくつかの利点があります。たとえば、サーバーのすべてまたは1つだけで特定のタスクを実行し、展開をロールバックできます。これは、gitだけでは実現が非常に困難です。