1. はじめに

IBM Cloud: VPCのAuto scale機能(1): Instance Templateによるプロビジョニングの続きです。前回はInstance Templateを作成するところまでで終わりましたが、今回は Instance Groupを作ってポリシーに応じてサーバーが増減するように構成したいと思います。

2. 前回の復習

最初にInstance Templateを作成する。Instance Templateは増減させるVSIの雛形を定義したものであり、ここで利用するImageやプロファイル（vCPU数やメモリ量）やSSH鍵などを指定する。
次に、このInstance groupを作成する。Instance groupは、Instance Templateを特定のルールを元に増減させるためのルールを定める。

前回Instance Templateを作成したので、今回はInstance groupを作成します。

3. VPC Load Balancerの事前作成と構成

Auto scale機能において、load balancerの選択はオプションですが、自動的に増減するサーバーに対して割り振りを行うことが必要になることを考えると、ほとんどのユースケースでload balancerが必須になると思われます。以下が利用の前提となります。

VPC load balancerはinstance templateと同じVPC内に存在している。
VPC load balancerからinstance templateでプロビジョニングするVSIに対して、Network ACLやSecurity Groupでアクセス許可が与えられている。
VPC load balancer内にFront-end listener（クライアントからのアクセスに対してLoad Balancerがどういうポートやプロトコルでlistenするか？）やBack-end pool（バックエンドサーバーへの接続プロトコルや割り振りメソッド、ヘルスチェックなど）が事前に作成されている。これは、VPC load balancerとAuto scale機能の連携は、単にBack-endのサーバーを自動的に追加・削除することだけに限るからであり、VPC Load Balancerが稼働するために必要な設定は別途実施しておく必要があります。

4. Instance groupの作成

4.1 名前、リソースグループ、タグ、リージョンの選択

4.2 instance templateの選択

4.3 subnet/load balancerの選択

subnetは複数ゾーンにまたがって選択可能。

load balancerの選択はオプション。ここでのApplication portはバックエンドサーバーへの接続ポート番号です。

4.4 scaling methodの選択

Static scaling method
UIもしくはCLI/APIから利用者が静的にサーバー数の増減を選択する方法です。

0から100を選択可能。今回は0を選択してプロビジョニングします。

Dynamic scaling method

事前に定義された閾値に応じてサーバー数の増減を選択する方式です。

集計期間:

Aggregation window(seconds) : For a dynamic group, this value determines the time period that the instance group manager monitors each instance and determines the average utilization.

クールダウン期間:

Cooldown period (seconds): For a dynamic group, the period of time in seconds to pause further scaling actions after scaling has taken place.

メトリックタイプ:
CPU 使用率 (%)、RAM 使用率 (%) 、「ネットワークインバウンド (Mbps) 、ネットワークアウトバウンド (Mbps) のいずれかのメトリックを選択できる。仮に、仮にCPU使用率をメトリックとして選択していてその閾値(Average Target Utilization)が70%であったとする。もしすでに４台のサーバーが稼働しており、その平均CPU使用率がそれぞれ80%, 70%, 65%, 85%であった場合、


\frac{(80\% + 70\% + 65\% + 85\%)}{70\%} = 4.29

なので、切り上げされて5台プロビジョニングされるというロジックらしい。

5. Instance Groupの確認と設定変更

以下は、Static scaling methodを使って確認した結果です。
Group sizeは0でプロビジョニングしています。

5.1 Instance Group作成直後の状態

5.2 Group sizeを0から4に変更

5.3 変更後確認

サーバー数が4になっている。

6. その他仕様、制約事項について

Instance groupで定義されたsubnetはランダムに選択される。

When an instance group scales up to create an instance, a subnet is selected randomly from the subnets that are defined for the instance group.

FIFO(First In/First Out)でインスタンスは増減するので、削除される時は一番古いサーバーが削除される。

When an instance group scales down to remove instances, it uses a first in first out (FIFO) strategy. The oldest instances are deleted first.

Secondary network interfaceはサポートされていない。

Secondary network interfaces are not supported. Only one, primary network interface for an instance template is supported in an instance group.

floating IPはサポートされていない。

A primary IP address or floating IP addresses assigned to the primary interface is not supported.

data volumeはサポートされていない。

Attached data volumes are not supported.

Instance GroupでプロビジョニングしたVSIを削除しようとしたらエラーになる。
メッセージの内容はおかしいが、近々修正されるとのこと。
Instance GroupのVSIを停止(Customer PortalからStopping状態にする）したら、新たなVSIが起動する。一方で、停止したVSIは(Static scaling methodで設定した4台を保つために）削除される。
Stop前の状態
Stop後の状態
Instance Groupのscaling methodは後から変更可能