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

#1. はじめに
[IBM Cloud: VPCのAuto scale機能(1): Instance Templateによるプロビジョニング](https://qiita.com/testnin2/items/9c1d04b31e20941b51fb)の続きです。前回は`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の作成

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/528fd59a-172f-2007-7539-433e47c531f8.png)

##4.1  名前、リソースグループ、タグ、リージョンの選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/8975fc8e-dd99-0a95-1098-b3f7ea518125.png)

##4.2 instance templateの選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/cba7ab26-0c39-26d6-a114-2c5665e4e077.png)

##4.3 subnet/load balancerの選択
subnetは複数ゾーンにまたがって選択可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/0fb5a99b-d970-8f22-7f57-6bf4938ff8e8.png)
load balancerの選択はオプション。ここでの`Application port`はバックエンドサーバーへの接続ポート番号です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/6ecdb3fd-71d5-9324-fc59-37ef2c6c1279.png)


##4.4 scaling methodの選択

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/8ab387fe-8dc0-a654-0277-c7411d30cc40.png)

0から100を選択可能。今回は0を選択してプロビジョニングします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/cf293d48-6ac1-51e1-d65d-e45de7145200.png)


2) Dynamic scaling method

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/6f0dcc94-eda0-4c29-3e33-eacad1c8f56f.png)

集計期間:
> 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%であった場合、 

```math

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

```

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

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

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

##5.1 Instance Group作成直後の状態
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/aa7d5ef9-82e7-2817-7478-2cd346f97caa.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/837812fe-ac15-4209-b47b-66f43eed20f1.png)

##5.2 Group sizeを0から4に変更
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/eed28553-5ab0-d2b7-0336-d0bc525c5036.png)

##5.3 変更後確認
サーバー数が4になっている。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/4bf791c3-da7c-ae94-6297-389375e5f86b.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/e272f0f4-3dfb-fd1d-3a9e-8832a2cb098d.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/6677607c-3351-827d-9703-4390d5e00ca5.png)


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

https://cloud.ibm.com/docs/vpc?topic=vpc-creating-auto-scale-instance-group&locale=en

- 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を削除しようとしたらエラーになる。
メッセージの内容はおかしいが、近々修正されるとのこと。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/f275a1c7-3456-31f5-5ee6-867a01970859.png)


- Instance GroupのVSIを停止(Customer PortalからStopping状態にする）したら、新たなVSIが起動する。一方で、停止したVSIは(Static scaling methodで設定した4台を保つために）削除される。
- Stop前の状態 <br> ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/ec05cab4-d5e2-e2e7-28a7-8420fd6be4ed.png)
- Stop後の状態<br> ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/d3e79b0a-60c0-eb68-8d1f-a85abd919e8c.png)

- Instance Groupのscaling methodは後から変更可能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/dc15a2cf-bb76-bb84-8534-bbdcda04ef87.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/dc88b3a5-be5f-9575-43ff-85bf2695c958.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/3eaa7a55-c12c-1d88-00c9-92bf5c0f7cdb.png)