自動スケーリングの要因を調べる
自動スケーリングのトリガーは、スケジュールに従って、またはシステムのリソースが不足しているかどうかを評価することで、行うことができます。 たとえば、CPU 使用率が増えた場合、メモリの占有率が増加した場合、サービスが受信する要求の数が急増している場合、または複数の要因の組み合わせで、自動スケールがトリガーされる可能性があります。
自動スケーリングとは
自動スケーリングは、現在の需要に基づいて使用可能なリソースを調整するクラウドのシステムまたはプロセスです。 自動スケーリングでは、"スケール アップとスケール ダウン" ではなく、"スケール インとスケール アウト" が行われます。
Azure App Service の自動スケーリング
Azure App Service の自動スケーリングでは、実行中の Web アプリのリソース メトリックが監視されます。 増加するワークロードを処理するためにその他のリソースが必要な状況を検出し、システムが過負荷になる前に、それらのリソースを確実に利用できるようにします。
自動スケーリングでは、Web サーバーを追加または削除し、それらの間に負荷を分散させることによって、環境内の変化に対応します。 自動スケーリングにより、アプリに利用されている Web サーバーの CPU パワー、メモリ、ストレージ容量が影響を受けることはなく、Web サーバーの数が変わるだけです。
自動スケーリング ルール
自動スケーリングでは、ユーザーが定義するルールに基づいて決定が行われます。 ルールでは、メトリックのしきい値を指定し、このしきい値を超えると自動スケーリング イベントがトリガーされます。 自動スケーリングでは、ワークロードが小さくなったらリソースの割り当てを解除することもできます。
自動スケーリング ルールの定義は慎重に行ってください。 たとえば、サービス拒否攻撃の結果として、受信トラフィックが大幅に増加する可能性があります。 DoS 攻撃による要求の急増を処理しようとするのは無駄なことで、大きな損害を被ります。 このような本物ではない要求は、処理するのではなく破棄しなければなりません。 より良いソリューションは、そのような攻撃中に発生する要求の検出とフィルタリングを実装し、要求がサービスに届かないようにすることです。
どのようなときに自動スケーリングを検討する必要があるか
自動スケーリングでは、サービスに対して柔軟性が提供されます。 たとえば、休暇中にビジネス アプリのアクティビティが増加/減少することが予想される場合があります。
自動スケーリングを使用すると、可用性とフォールト トレランスが向上します。 インスタンスがすぐに要求に確認応答できないため、または過負荷になったインスタンスがクラッシュしたために、サービスに対するクライアントの要求が拒否されることがないようにするのに役立ちます。
自動スケーリングは、Web サーバーを追加または削除することによって動作します。 Web アプリで各要求の一部としてリソースを集中的に使用する処理が実行される場合は、自動スケーリングは効果的なアプローチではない可能性があります。 このような状況では、手動によるスケールアップが必要な場合があります。 たとえば、Web アプリに送信される要求に、大規模なデータセットに対する複雑な処理の実行が含まれる場合、インスタンスのサイズによっては、この 1 つの要求でインスタンスの処理とメモリ容量がすべて消費されることがあります。
自動スケーリングは、長期的な増加を処理するには最善の方法ではありません。 Web アプリのユーザーが最初は少数でも、時間と共に人気が高まるかもしれません。 自動スケーリングには、リソースの監視と、スケーリング イベントをトリガーするかどうかの判断に関連する、オーバーヘッドがあります。 このシナリオでは、増加率を予測できるのであれば、時間と共に手動でシステムをスケーリングする方が、コスト効果の高いアプローチである可能性があります。
サービスのインスタンスの数も要因です。 ほとんどの時間はサービスの少数のインスタンスしか実行されないと予想されるかもしれません。 しかしながら、このような状況で、自動スケーリングが有効かどうかに関わりなく、サービスにはダウンタイムまたは可用性低下の可能性があります。 インスタンスの初期数を少なくすると、ワークロードの増加を処理する容量が少なくなり、かつ、自動スケーリングで起動するインスタンス数が多くなります。