LANSA テンプレートにより作成されたデフォルトのスタックは、現在のリージョンのすべてのアベイラビリティーゾーン (AZ) に EC2 インスタンスを作成するためのものです。スタックが作成されると、これは簡単に 1 つの AZ を使用するよう変更できます。複数の AZ を利用することで、フォールトト・レランスは向上しますが、データベース・サーバーが存在しない AZ からデータベース・サーバーへのアクセスが遅延するという欠点があります。シドニー・リージョンを使用する場合、AZ は 2 つ存在します。ベンチマークテストでは、20% の速度向上を達成しました。これは、複数の AZ 間におけるネットワーク速度は、1 つの AZ 内の速度より遅いからです。ですから、単一の AZ 利用を選択することで、コストを抑えられる可能性があります。コストが低くなるのは、ある特定のワークロードをサポートするために実行する必要なリソースが 20% 少なくて済むからです。
この問題は、より多くの AZ が存在するリージョンでは深刻になります。例えば、バージニア・リージョンには 4 つの AZ があります。この場合、4 つの AZ のうち 3 つはデータベース・サーバーではない AZ です。ですから、シドニーの 2 つのうち 1 つ (50%) に比べると、4 つのうち 3 つ (75%) のトランザクションがより遅くなるということです。4 つの AZ により提供される重複作業は恐らく不必要であることを考えると、AZ を削除する必要があります。AZ の数を 4 から 2 へ減少させる場合でも、以下と同じ手順を使用することができます。Auto Scaling グループから AZ を削除する場合、1 つだけでなく 2 つの AZ を残すようにしてください。
スタック作成時に余分のWeb サーバーは指定しないでください。デフォルトは 0 の設定のままにします。スタックが完全に動作する状態になったら、以下の変更を行うことができます。つまり、アプリケーションを使って、これが作動していることをテストしてください。
- RDS AWS コンソール・ページに進みます。
- DB インスタンス を探し、これが実行されているゾーンを見つけます(例: ap-southeast-2a)。これが、すべての EC2 インスタンスを作成する必要がある AZ です。
- 次に EC2 AWS コンソール・ページにリストされている Auto Scaling グループに進みます。以下のように Auto Scaling グループの両方が複数の AZ にあることが分かります。
- DB Web サーバーを選択し、Auto Scaling グループの詳細を編集します。削除する必要のある AZ を識別し (例： ap-southeast-2b)、'x' をクリックします。Auto Scaling グループを保存します。
- インスタンスのタブを確認します。インスタンスが正しい AZ (例えば ap-southeast-2a) にあれば、次のステップに進みます。正しくない場合は、ap-southeast-2a に新規インスタンスが作成され、次に進む前にこれが完全に動作している状態になるまで待たなければいけません。
- DB Web サーバーのインスタンスが新規 AZ に作成中の場合は、次のステップに進まないでください。
- 次に同じ方法で他の Auto Scaling グループも修正します。これと同時に、希望の Min と Max の設定を変更して、単一 AZ の Web サーバー・インスタンスの作成が可能です。
- ap-southeast-2b の場合、ロードバランサーから未使用の AZ を削除することで、Elastic ロードバランサーを変更できます。インスタンス タブをクリックすると、ap-southeast-2b のインスタンスはおそらく 0 になっています。そうでない場合は、正しい AZ かを確認してください。AZ からのインスタンス削除が進行中である場合もあります。アクションのロードバランサーから削除をクリックします。
- 最後に、クロスゾーン・ロードバランシングが無効になるよう、Elastic ロードバランサーを修正します。
