以下の例は、いつスケール・アップやスケール・ダウンするかの実際の設定というよりは、スケーリング・イベントの起動に主に焦点が当てられています。これは、ロードの種類や適切な最大応答時間については、各アプリケーションやそれぞれのユーザーが独自のシナリオを持っているからです。アプリケーションによっては、平均応答時間が 2 秒以下に抑えられるのであれば、最大応答時間が 30 秒以上でも大丈夫な場合もあるでしょう。また別のアプリケーションでは、こういった事態が起きないよう、より早くスケールアウトする必要がある場合もあるでしょう。

オートスケーリングのデモができることが望ましいですが、Web サーバーが作動するまで 20 分の時間を要し、スケーリング・アウトとスケーリング・バックまでをデモで示すためには少なくとも 60 分が必要となります。これでは実用的ではありません。チュートリアルでは、スケーリングをマニュアルで行うデモが提供されていますので、これで十分役目を果たすでしょう。

まず初めに、予想される最大のロードを処理する大規模なデータベース・インスタンスを使用してください。これは、全システムをダウンしないとスケールアウトできないからです。EC2 インスタンス数が Auto Scaling グループ (ASG) が管理する応答時間をコントロールします。

これらのテストは、デフォルトである複数のアベイラビリティーゾーン (AZ) ではなく、単一の AZ スタックで実行されます。基本的にこれがスケーリング処理に影響を与えることはありません。警告は、純粋に EC2 インスタンス内の CPU 利用がベースになっており、別の AZ における RDS インスタンスへのアクセスの影響を受けることはないためです。もちろん、平均の応答時間は遅くなりますが、CPU の利用量はほぼ同じです。実行に 1 秒以下の遅延が見られるのみで、1 分間あたりの CPU 使用量が変わることはありません。

スケーリングは、既存のインスタンスの平均 CPU 利用により作動します。Web サーバー ASG のみがスケール・アウトするよう構成されています。ASG に既存のインスタンスが存在しない場合は、平均 CPU 利用も無いため、スケーリングは発生しません。ですから、ASG には最低でも 1 つのインスタンスが必要です。

ASG が 1 つだけではない理由は何でしょうか? 2 つ存在する目的は何でしょう? これは、データベース更新は 1 つのインスタンスで管理する必要があるからです。テーブルの変更に複数のインスタンスが関わることはできません。そうでなければ、インスタンスに格納されたデータベースの状態とRDS のテーブルの状態が一致しなくなります。列追加などのテーブル更新時は Web サーバーとデータベース・サーバーの状態が一致することが非常に重要です。ですから、テーブル更新には 1 つの Web サーバーのみが関係する必要があります。DBWebServer ASG が存在する意義はここにあります。データベース状態の変更を制御する唯一の Web サーバーのインスタンスが 1 つのみ実行されていることを確実にするためです。

CloudWatch の AWS コンソールで WebServerApp CPUAlarmHigh を 15 分 >70 から 5 分 >70 に変更します。これにより、スケーリングをより早く発生させることができます。また、WebServerApp CPUAlarmLow  を 15 分に <30 から 5 分に <30 に変更します。  

次に、両方の警告に対するスケーリング・ポリシーを、別のスケーリング・イベントを許可する前に 1200 秒 (20 分) 待つように変更します。これは、最低でもインスタンスが開始して実行されるまでにかかる時間で、CPU 使用にも良い影響を与える時間でなければなりません。

インスタンスができるだけ早く正常であると認識されるよう、ELB ヘルスチェックを減らしてください。タイムアウトは多くの応答時間以上である必要があります。可能であれば、最大応答時間よりも大きく設定してください。この例では、スケーリングをできるだけ早く発生させつつ、インスタンスを正常に保つことができる時間は 15 秒になっています。インターバルは 1 秒長く、16 秒にします。アンヘルシー・スレッシュホールドは最大値 10、ヘルシー・スレッシュホールドは最低値 2 にします。これにより、ヘルスについて考慮する必要を最小限にとどめ、インスタンスが正常になるまでの時間をかけず、ロードが不十分だった時にすぐに終了されることもなく、必要な時にASG のスケーリングが行えるようにします。

これで、ロード・テストがこの LANSA スタックで 30 の仮想ユーザーで 43 分実行されます。ここで 1 つから 3 つのインスタンスにスケールアウトされ、ロードが終了すると、徐々に 1 インスタンスに減らされていきます。

  • No labels