IBM Cloud: VPCのAuto scale機能(2): Instance Groupによるポリシー制御

1. はじめに

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

2. 前回の復習

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

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

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

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

1. VPC load balancerはinstance templateと同じVPC内に存在している。
2. VPC load balancerからinstance templateでプロビジョニングするVSIに対して、Network ACLやSecurity Groupでアクセス許可が与えられている。
3. 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の選択

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

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

1. 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は後から変更可能