NSX Advanced Load Balancer は柔軟性に優れたファブリック アーキテクチャです。SE やアプリケーション サーバなどのさまざまなリソースは、負荷とキャパシティの要件に基づいて、オンデマンドでスケール アップおよびスケール ダウンできます。
パブリック クラウド エコシステムに柔軟性に優れたワークロード自動スケーリング機能がある場合、NSX Advanced Load Balancer では、その機能を利用するほか、NSX Advanced Load Balancer で収集したメトリックに基づいた動作管理もします。
NSX Advanced Load Balancer には、次のスケーリング機能があります。
NSX Advanced Load Balancer SE のキャパシティが制限に到達したら（十分に活用されていなければ）トラフィックを処理するロード バランシング インスタンスが増える（または減る）よう、仮想サービスをスケーリングする SE を増やし（または減らし）ます。
適切なサイズのバックエンド プールでトラフィックを処理できるように、アプリケーション サーバ プールをより多くの(または少ない)アプリケーション インスタンスにスケーリングします。
どちらのタイプのスケーリングでも、NSX Advanced Load Balancer を使用して負荷とキャパシティを測定した結果に基づいて、事前設定した NSX Advanced Load Balancer ポリシーによる自動実行ができます。
エコシステムとの連携
NSX Advanced Load Balancer では、すべてのエコシステムで前述の自動スケーリング機能をサポートしています。このセクションでは、次のパブリック クラウドに関連する統合に関する考慮事項について説明します。
Amazon Web Services
Microsoft Azure
仮想サービスのスケーリング
トラフィック処理の最大キャパシティは SE ごとに異なり、通常は 1 秒あたりのトラフィック スループットまたは SSL トランザクションを単位として測定されます。SE キャパシティは、SE 仮想マシンのサイズ（vCPU の数、またはメモリ）、トラフィックのタイプ、SE が機能しているエコシステムなど、さまざまなパラメータに相関しています。
デフォルト構成では、仮想サービスは単一の SE に配置されます。ただし、SE が仮想サービスのトラフィックを処理するのに十分でない場合は、追加された SE に仮想サービスをスケール アウトできます。ここでは、複数の SE が仮想サービスのトラフィックを処理します。
仮想サービスのスケール アウトまたはスケール インは、手動または自動で実行できます。
仮想サービス配置の自動スケーリングの場合は、次のいずれかの SE パラメータを使用してしきい値を構成し、そのしきい値から外れたら仮想サービスを新しい SE にスケール アウトしたり、スケール バックして SE を減らしたりしなければならなくなるようにします。
SE の CPU 使用率
SE によって提供されるバンド幅 (Mbps)
SE によって提供される 1 秒あたりの接続数 (CPS)
1 秒あたりのパケット数 (PPS)
仮想サービスのスケーリングの詳細については、 仮想サービスのスケーリング を参照してください。
アプリケーション サーバのスケーリング
仮想サービスのロード バランシングに加えて、トラフィックの負荷を処理するのに十分なキャパシティがアプリケーション インスタンス層で使用可能であることを確認することが重要です。
パブリック クラウド インフラストラクチャは使用量またはアップタイムに基づいて課金されるため、リソースをオンデマンドでスケーリングする機能とともに、使用量に基づいて十分なキャパシティを確保することが重要です。
パブリック クラウドは自動スケーリング機能を提供します。自動スケーリング サーバのテンプレートは、仮想マシンの生成と構成に使用できます。スケール アウトまたはスケール インは、手動で行うか、特定の負荷条件に基づいて実行できます。
関連する機能は次のとおりです。
Amazon Web Services：Amazon EC2 自動スケーリング
Microsoft Azure：仮想マシン スケール セット
NSX Advanced Load Balancer とパブリック クラウドとの統合
NSX Advanced Load Balancer による自動スケーリング グループのサポートには、次の 2 つのバリエーションがあります。
パブリック クラウドによって管理される自動スケールの決定。
NSX Advanced Load Balancer によって管理される自動スケールの決定。
パブリック クラウドによって管理される自動スケールの決定
このメソッドによる自動スケーリングでは、適切な自動スケーリング グループが NSX Advanced Load Balancer Controller のサーバ プールに追加されます。コントローラで自動スケーリング グループを追跡します。仮想マシン インスタンスがグループに追加またはグループから削除されると、NSX Advanced Load Balancer ではその仮想マシンをプール メンバー リストから追加または削除します。
この方法にすると、NSX Advanced Load Balancer ではトラフィック要求を、必要な仮想マシン インスタンスに分散します。
プールのスケール インまたはスケール アウトは、自動スケール グループに関連付けられているポリシーに基づいて制御され、コントローラはこの操作に影響しません。
NSX Advanced Load Balancer によって管理される自動スケールの決定
このメソッドによる自動スケーリングでは、仮想マシン インスタンスのスケーリングに関する決定を NSX Advanced Load Balancer で引き継ぎます。また、パブリック クラウドの自動スケール グループが NSX Advanced Load Balancer サーバ プールに追加されます。
コントローラに自動スケール ポリシーが作成され、プールに関連付けられます。この自動スケール ポリシーには、NSX Advanced Load Balancer でサポートする広範なメトリックとアラートに基づいて、スケールアウトとスケールインのイベントをトリガするためのパラメータとしきい値もあります。
しきい値を超えると、コントローラはパブリック クラウドと通信してスケールアウトまたはスケールイン操作を開始し、プール メンバーシップも管理します。
この方法の主な利点は、パブリック クラウドで使用可能なメトリックと比較して、スケーリングの決定を実行するためにはるかに豊富なメトリック セットを使用する機能です。
サーバ ガベージ コレクション パラメータ
NSX Advanced Load Balancer でスケールインが決定されるたびに、すでにダウンしているサーバがスケールイン対象に選択されます。
また、ダウンしたサーバは、構成済みの遅延の後、NSX Advanced Load Balancer によるガベージ コレクションの対象となります。遅延パラメータを構成するには、autoscale_policy オプションの下で delay_for_server_garbage_collection を使用します。
AZ 対応の自動スケーリング
スケール インの間は、NSX Advanced Load Balancer 自動スケールにより、異なった AWS アベイラビリティ ゾーン間でのサーバのバランスが確保されます。たとえば、プールにサーバが 4 台（AZ1 と AZ2 のそれぞれにサーバが 2 台）あり、サーバ 2 台のスケールインが行われる場合は、サーバが 2 台（AZ ごとに 1 台）残ります。
この機能は、AWS でのみ使用できます。
NSX Advanced Load Balancer との自動スケール統合の構成
パブリック クラウドを使用した自動スケール グループの構成の詳細については、次のセクションを参照してください。
Amazon Web Services（パブリック クラウドによって管理される自動スケーリング）：NSX Advanced Load Balancer と AWS 自動スケーリング グループとの統合
Amazon Web Services（NSX Advanced Load Balancer によって管理される自動スケール）：『VMware NSX Advanced Load Balancer インストール ガイド』のトピック「NSX Advanced Load Balancer での AWS サーバ自動スケーリングの構成とメトリック収集」を参照してください。
Microsoft Azure：『NSX Advanced Load Balancer インストール ガイド』の「NSX Advanced Load Balancer と Azure 仮想マシン スケール セットとの統合」を参照してください。
