自動スケーリングのベストプラクティスを調べる

3 分

自動スケーリングの設定を作成するときに適切な方法に従っていないと、望ましくない結果につながる条件を作成する可能性があります。このユニットでは、互いと競合するルールを作成しない方法について説明します。

自動スケールの概念

自動スケール設定では、インスタンスが水平方向にスケールされます。つまり、インスタンス数を増やしてスケール "アウト" し、インスタンス数を減らしてスケール "イン" します。自動スケール設定には、インタンスの最大値、最小値、既定値があります。
自動スケールジョブでは、スケールに使用する関連付けられたメトリックを常に読み取り、スケールアウトまたはスケールインの構成済みのしきい値を超えているかどうかをチェックします。
しきい値はすべてインスタンスレベルで計算されます。たとえば、"インスタンス数が 2 で、平均 CPU 使用率が 80% を超えたときに、インスタンスを 1 つ増やしてスケールアウトする" の場合、全インスタンスの平均 CPU 使用率が 80% を超えたときにスケールアウトすることを意味します。
すべての自動スケーリングの成功と失敗は、アクティビティログに記録されます。その後、アクティビティが発生したときは常にメール、SMS、または Webhook で通知されるように、アクティビティログアラートを構成できます。

自動スケールのベストプラクティス

自動スケーリングルールを作成するときは、次のベストプラクティスを参考にしてください。

最大値と最小値が異なっており、これらの値に十分な差があることを確認する

最小値が 2 で最大値も 2 の設定があり、現在のインスタンス数が 2 の場合、スケール操作が実行されない可能性があります。インスタンスの最大数と最小数に十分な差を付けておきます。自動スケールでは、常にこれらの制限の範囲でスケールします。

診断メトリックに適切な統計を選択する

診断メトリックの場合、スケールに使用するメトリックとして、"平均"、"最小"、"最大"、"合計" の中から選択できます。最も一般的な統計は平均です。

どのメトリックの種類でもしきい値を慎重に選択する

実際の状況に基づいて、スケールアウトとスケールインに異なるしきい値を慎重に選択することをお勧めします。

スケールアウトとスケールインの条件に同じまたは近いしきい値を指定した次の例のような自動スケーリング設定は、"お勧めできません"。

スレッド数が 600 以上のときにインスタンスを 1 つ増やす
スレッド数が 600 以下のときにインスタンスを 1 つ減らす

混乱を招くと思われる動作につながる可能性のある例を見てみましょう。次の例を考えます。

最初に 2 つのインスタンスがあり、インスタンスあたりの平均スレッド数が 625 に増加したとします。
自動スケーリングによって 3 つ目のインスタンスが追加され、スケールアウトされます。
次に、インスタンスの平均スレッド数が 575 に減少したとします。
スケールインの前に、自動スケーリングでは、スケールインした場合に最終状態がどのようになるかを推定しようとします。たとえば、575 x 3 (現在のインスタンス数) = 1,725 / 2 (スケールインしたときの最終的なインスタンス数) = 862.5 スレッドです。つまり、スケールインした後も、平均スレッド数に変化がない場合や少し減少しただけである場合、自動スケールですぐにスケールアウトを再度実行する必要があります。ただし、もう一度スケールアウトした場合、プロセス全体が繰り返されて無限ループが発生します。
この状況 ("フラッピング" と呼ばれる) を避けるために、自動スケーリングでスケールインは一切行われません。代わりに、スケールダウンをスキップし、サービスのジョブが次回実行されたときに、条件が再評価されます。平均スレッド数が 575 のときに自動スケーリングが機能していないように見えるため、これは多くのユーザーを混乱させるおそれがあります。

スケールイン時の推定は、スケールインとスケールアウトのアクションが連続して交互に行われる "フラッピング" という状況を回避することを目的としています。スケールアウトとスケールインに同じしきい値を使用する場合は、この動作に留意してください。

スケールアウトとスケールインのしきい値に十分な差を付けておくことをお勧めします。たとえば、次の有効なルールの組み合わせについて考えてみます。

CPU 使用率が 80 以上のときにインスタンスを 1 つ増やす
CPU 使用率が 60 以下のときにインスタンスを 1 つ減らす

この場合、次のようになります。

最初に 2 つのインスタンスがあるとします。
全インスタンスの平均 CPU 使用率が 80 に達すると、3 つ目のインスタンスが追加され、スケールアウトされます。
時間の経過と共に、CPU 使用率が 60 に低下したとします。
自動スケールのスケールインルールにより、スケールインした場合の最終状態が推定されます。たとえば、60 x 3 (現在のインスタンス数) = 180 / 2 (スケールインしたときの最終的なインスタンス数) = 90 です。そのため、すぐにスケールアウトを再度実行しなければならないので、スケールインは実行されません。代わりに、スケールインをスキップします。
次回チェックされたときに、CPU 使用率が引き続き 50 に低下していると、再び推定が行われます。50 x 3 インスタンス = 150 / 2 インスタンス = 75 となり、スケールアウトのしきい値である 80 を下回っているため、2 つのインスタンスに正常にスケールインされます。

プロファイルに複数のルールが構成されている場合のスケーリングに関する考慮事項

プロファイルに複数のルールを設定することが必要な場合があります。複数のルールが設定されている場合、自動スケーリングルールの次のセットがサービスに使用されます。

"スケールアウト" の場合、いずれかのルールが満たされていれば、自動スケールが実行されます。 "スケールイン" の場合、すべてのルールが満たされている必要があります。

わかりやすく説明するために、次の 4 つの自動スケーリングルールがあると仮定します。

CPU 使用率が 30% 未満の場合は 1 つスケールインする
メモリ使用率が 50% 未満の場合は 1 つスケールインする
CPU 使用率が 75% を超えた場合は 1 つスケールアウトする
メモリ使用率が 75% を超えた場合は 1 つスケールアウトする

この場合、次の処理が行われます。

CPU が 76% でメモリが 50% の場合、スケールアウトします。
CPU が 50% でメモリが 76% の場合、スケールアウトします。

一方、CPU が 25% でメモリが 51% の場合、自動スケーリングでスケールインは実行されません。 CPU が 29% でメモリが 49% の場合は、自動スケールインが発生します。これは、両方のスケールインルールが true であるためです。

常に、安全な既定のインスタンス数を選択する

既定のインスタンス数は重要です。自動スケーリングで、メトリックを使用できないときにサービスがその数にスケーリングされるからです。そのため、ワークロードにとって安全な既定のインスタンス数を選択する必要があります。

自動スケールの通知を構成する

自動スケーリングでは、次のいずれかの状況が発生した場合、アクティビティログに記録されます。

自動スケールがスケール操作を発行した場合
自動スケールサービスがスケール操作を正常に完了した場合
自動スケールサービスがスケール操作を実行できない場合。
自動スケーリングサービスでスケールを決定する際にメトリックを使用できない場合
スケールを決定する際にメトリックを再び使用できるようになった (回復した) 場合。

また、アクティビティログアラートを使用して、自動スケールエンジンの正常性を監視することもできます。アクティビティログアラートを使用する以外に、正常なスケール操作が行われたときに通知されるように、自動スケール設定の通知タブで、電子メールまたは webhook の通知を構成することもできます。

自動スケーリングのベスト プラクティスを調べる