Microsoft Azure のAutoscale アーキテクチャ
NetScaler Consoleは、Azure DNSまたはAzure Load Balancer（ALB）を使用してクライアントのトラフィック分散を処理します。
Azure DNS を使用したトラフィック分散
次の図は、Azure トラフィックマネージャーをトラフィックディストリビューターとして使用して DNS ベースの自動スケーリングがどのように行われるかを示しています。
DNS ベースの自動スケーリングでは、DNS はディストリビューション層として機能します。Azure トラフィックマネージャーは Microsoft Azure の DNS ベースのロードバランサーです。トラフィックマネージャーは、NetScaler Console自動スケーリンググループで使用可能な適切なNetScalerインスタンスにクライアントトラフィックを転送します。
Azureトラフィックマネージャーは、FQDNをNetScaler ADC インスタンスのVIPアドレスに解決します。
注
：DNSベースの自動スケーリングでは、NetScalerコンソールAutoscale グループの各NetScalerインスタンスにパブリックIPアドレスが必要です。
NetScaler Consoleは、クラスターレベルでスケールアウトまたはスケールインアクションをトリガーします。スケールアウトがトリガーされると、登録された仮想マシンがプロビジョニングされ、クラスターに追加されます。同様に、スケールインがトリガーされると、NetScaler VPX クラスターからノードが削除され、プロビジョニングが解除されます。
Azure Load Balancer を使用したトラフィック分散
次の図は、Azure ロードバランサーをトラフィックディストリビューターとして使用して自動スケーリングがどのように行われるかを示しています。
Azure Load Balancerは、クラスターノードへの配布層です。ALBはクライアントトラフィックを管理し、NetScaler VPX クラスターに配信します。ALBは、アベイラビリティーゾーン全体でNetScaler Console自動スケーリンググループで使用可能なNetScaler VPXクラスターノードにクライアントトラフィックを送信します。
注:
パブリック IP アドレスは Azure Load Balancer に割り当てられます。NetScaler VPX インスタンスでは、パブリックIPアドレスは必要ありません。
NetScaler Consoleは、クラスターレベルでスケールアウトまたはスケールインアクションをトリガーします。スケールアウトがトリガーされると、登録された仮想マシンがプロビジョニングされ、クラスターに追加されます。同様に、スケールインがトリガーされると、NetScaler VPX クラスターからノードが削除され、プロビジョニングが解除されます。
NetScaler コンソールAutoscale グループ
Autoscaleグループは、NetScaler インスタンスのグループで、アプリケーションを単一のエンティティとして負荷分散し、設定されたしきい値パラメータ値に基づいて自動スケーリングをトリガーします。
リソース グループ
リソースグループには、NetScaler 自動スケーリングに関連するリソースが含まれます。このリソースグループは、自動スケーリングに必要なリソースを管理するのに役立ちます。詳細については、「 リソースグループの管理」を参照してください。
Azure バックエンド仮想マシンスケールセット
Azure 仮想マシンスケールは、同じ VM インスタンスの集合です。VM インスタンスの数は、クライアントのトラフィックに応じて増減できます。このセットは、アプリケーションに高可用性を提供します。詳しくは、「 仮想マシンスケールセット」を参照してください。
アベイラビリティゾーン
アベイラビリティーゾーンは、Azure リージョン内の独立した場所です。各リージョンは複数のアベイラビリティーゾーンで構成されています。各アベイラビリティーゾーンは 1 つのリージョンに属しています。各アベイラビリティーゾーンには、1 つの NetScaler VPX クラスターがあります。詳細については、「 Azure のアベイラビリティーゾーン」を参照してください。
可用性セット
可用性セットは、NetScaler VPX クラスターとアプリケーションサーバーの論理的なグループです。可用性セットは、クラスター内の複数の分離されたハードウェアノードにNetScalerインスタンスを展開するのに役立ちます。可用性セットを使用すると、Azure内でハードウェアまたはソフトウェアに障害が発生した場合でも、信頼性の高いNetScaler Console自動スケーリングが可能になります。詳細については、「 可用性セット」を参照してください。
次の図は、可用性セットの自動スケーリングを示しています。
Azureインフラストラクチャ（ALBまたはAzureトラフィックマネージャー）は、クライアントトラフィックを可用性セット内のNetScaler Console自動スケーリンググループに送信します。NetScaler Consoleは、クラスターレベルでスケールアウトまたはスケールインアクションをトリガーします。
オートスケーリングの仕組み
次のフローチャートは、自動スケーリングのワークフローを示しています。
NetScaler Consoleは、Autoscale eがプロビジョニングしたクラスターから1分ごとに統計情報（CPU、メモリ、スループット）を収集します。
統計情報は、設定しきい値に対して評価されます。統計に応じて、スケールアウトまたはスケールインがトリガーされます。統計が最大閾値を超えると、スケールアウトがトリガーされます。統計が最小閾値を下回ると、スケールインがトリガーされます。
スケールアウトがトリガーされた場合：
-
新しいノードがプロビジョニングされます。
-
ノードがクラスタに接続され、構成がクラスタから新しいノードに同期されます。
-
ノードはNetScalerコンソールに登録されています。
-
新しいノードの IP アドレスは Azure トラフィックマネージャーで更新されます。
スケールインがトリガーされた場合：
-
削除するノードが特定されました。
-
選択したノードへの新しい接続を停止します。
-
接続がドレインするまで指定した期間待機します。DNS トラフィックでは、指定された存続時間（TTL）期間も待機します。
-
ノードはクラスターから切り離され、NetScaler コンソールから登録が解除され、Microsoft Azure からプロビジョニングが解除されます。
注
アプリケーションをデプロイすると、すべてのアベイラビリティーゾーンのクラスターに IP セットが作成されます。次に、ドメインとインスタンスの IP アドレスが Azure トラフィックマネージャーまたは ALB に登録されます。アプリケーションを削除すると、ドメインとインスタンスの IP アドレスが Azure トラフィックマネージャーまたは ALB から登録解除されます。次に、IP セットが削除されます。
オートスケーリングのシナリオの例
次の設定を使用して、単一のアベイラビリティーゾーンに asg_arn という名前のAutoscaleグループを作成したとします。
-
選択されたしきい値パラメータ — メモリ使用量。
-
メモリに設定されている閾値の上限:
-
最小制限値:40
-
最大制限:85
-
-
総再生時間 — 2 分
-
クールダウン期間 — 10 分
-
プロビジョニング解除中の待機時間 — 10 分。
-
DNS の存続時間 — 10 秒。
[Autoscale] グループが作成されると、[Autoscale] グループから統計が収集されます。Autoscaleポリシーは、Autoscaleイベントが進行中かどうかも評価します。自動スケーリングが進行中の場合は、そのイベントが完了するのを待ってから、統計情報を収集します。
イベントのシーケンス
-
メモリ使用量が T2のしきい値制限を超えています。ただし、スケールアウトは指定された総再生時間に対して違反しなかったため、トリガーされません。
-
スケールアウトは、2 分間（総再生時間）にわたって最大しきい値を超過したあと、 T5 でトリガーされます。
-
ノードプロビジョニングが進行中であるため、 T5 ～ T10 間の違反に対しては何の措置も取られませんでした。
-
ノードは T10 でプロビジョニングされ、クラスタに追加されます。クールダウン期間が開始されました。
-
クールダウン期間が原因で、 T10-T20 間の違反に対する処置は実行されていません。この期間により、Autoscale グループのインスタンスが有機的に増加することが保証されます。次のスケーリング決定をトリガーする前に、現在のトラフィックが安定し、現在のインスタンスのセットで平均化するのを待機します。
-
メモリ使用量は T23で最小閾値制限を下回ります。ただし、スケールインは指定された総再生時間に対して違反しなかったため、トリガーされません。
-
スケールインは、最小しきい値を2分間（総再生時間）連続して超過した後、 T26にトリガーされます 。クラスタ内のノードは、プロビジョニング解除のために識別されます。
-
NetScaler Consoleは既存の接続の流出を待っているため、 T26-T36間の違反に対するアクションは実行されませんでした 。DNS ベースの自動スケーリングでは、TTL が有効です。
注
：DNSベースの自動スケーリングでは、NetScaler Consoleは指定された有効期間（TTL）の間待機します。次に、ノードのプロビジョニング解除を開始する前に、既存の接続がドレインするのを待機します。
-
ノードのプロビジョニング解除が進行中であるため、 T37-T39 間の違反に対しては何の措置も取られませんでした。
-
ノードは T40 でクラスタから削除され、プロビジョニング解除されます。
ノードのプロビジョニング解除を開始する前に、選択したノードへのすべての接続がドレインされました。したがって、クールダウン期間は、ノードのプロビジョニング解除後にスキップされます。