3.7 オートスケールを利用するには？

（2016年時点での内容をアーカイブとして掲載しているため、一部の掲載内容が最新情報とは異なる場合がありますので、ご了承ください。最新のIBM Cloudのアップデート情報は[IBM Cloud アップデート情報](https://www.ibm.com/cloud-computing/jp/ja/cloud-update/) や [柔らか層本](https://ibm.ent.box.com/v/ibmcloud-yawaraka)をご参照ください。）

概要
SoftLayerのオートスケールは、仮想サーバーのCPU使用率やネットワーク帯域等の負荷状況に応じ、サーバー台数を動的に増減できるサービスです。 ここでは、オートスケールの注文と利用方法をご紹介いたします。

オートスケールの機能はカスタマーポータル上で注文が可能です。 オートスケールには、ルールの設定や、利用する仮想サーバーの設定、ロードバランサーの設定等、非常に多くの設定項目がありますので、ここで詳細にご紹介いたします。 以降では、具体的な事例として、ウェブ・サーバーが2台稼働している環境で、CPU負荷に応じて最大5台までオートスケールさせる設定を例に注文画面の流れに沿って設定内容をご紹介いたします。
 

オートスケールの事前準備
オートスケール用のイメージ・テンプレート作成

オートスケールにて仮想サーバーを増強する際に、通常のOSイメージのほか、予め用意したイメージ・テンプレートを利用することができます。 たとえばウェブ・サーバーをオートスケールする場合には、ウェブ・サーバーの設定や、基本的なセキュリティの設定等が完了しているイメージが利用できるので便利です。

イメージ・テンプレートを利用したサーバーの作成方法については、3.2 サーバーのクローンを作るには？で解説しています。

ローカル・ロードバランサーの注文

オートスケールの機能は、ローカル・ロードバランサーと連動して、サーバーが増設された場合に自動で負荷分散されます。 ローカル・ロードバランサーの注文後、「Service Group」を予め設定しておく必要があります。 ローカル・ロードバランサーの導入方法の詳細については、3.3.1 ローカル・ロードバランサーを使うには？を参照してください。 オートスケールでは、NetScalerと連携することはできません。 (2014/11現在)
 

オートスケールを注文するには？
オートスケールの注文は、カスタマーポータルの「Devices」->「Auto Scale」をクリックし、「Auto Scale」画面右上の「Add Auto Scale Group」をクリックします。


オートスケール・グループの設定
オートスケールの設定では、次の画面のようにグループの設定を最初に行います。 アスタリスク(*)のついている項目は必須入力項目になります。 ここでは設定項目中、特に重要な赤枠で強調した項目について解説いたします。



Termination Policy

「Termination Policy」は、仮想サーバーが削減される優先順位を決める設定項目です。 選択肢の中の「Closest to next Charge」は、次の課金のタイミングが最も近い仮想サーバーから削減されるため、費用を節約することができるのですすめです。 たとえば、サーバーの起動から1時間20分が経過しているAサーバーと、50分経過が経過しているBサーバーがあった場合、Bサーバーは10分後には次の課金が発生してしまうので、課金が発生しないように、Bサーバーが削減されます。

「Termination Policy」選択肢は次の3項目です。
「Closest to next charge」: 次の課金が一番近い順に削減します
「Newest」: 作成日時が新しい仮想サーバーから削減します
「oldest」: 作成日時が古いサーバーから削減します

Cooldown Period

「Cooldown Period」は、仮想サーバーの増減後一定の時間内は仮想サーバーの増減判定をさせないようにする設定です。 たとえば、短時間で負荷が増減し、サーバーが増えたり減ったりと稼働が落ち着かないような場合、サーバー削減時のクールダウン時間を長めに設定しておくことで、安定した運用が可能になります。 逆に、急激に負荷が増大するようなケースでは、サーバー増強時のクールダウン時間を短めに設定しておくことで、短時間で仮想サーバーの増強が始まります。 実際の負荷の発生状況に応じてチューニングが必要になる設定項目です。
「Cooldown Period」の設定は、グループ全体の設定と、後述のポリシーにて増強時と削減時に個別の設定することが可能です。 ポリシー単位でグループ全体の設定を利用するか、個別の設定を利用するかの選択が可能です。
 

オートスケールで増強するサーバーの設定
グループの設定に続き、負荷が増大した時に自動で追加される仮想サーバーの設定を行います。 仮想サーバー設定は、注文画面を下方にスクロールし、「Member Configuration」画面で行います。 以下で設定項目中、重要な項目についてご紹介いたします。



Operating System

「Operating System」にて、増強する仮想サーバーのOSを選択することができます。 SoftLayerで用意されているOSイメージ「Select Operating System」のほか、SoftLayerで用意しているイメージテンプレート「Select Public Image」や、ユーザーが作成したイメージテンプレート「Select Private Image」を指定することが可能です。

ユーザーが作成したイメージ・テンプレートを利用する場合、「Select Private Image」を選択し、直下のセレクトボックスで利用するイメージを選択します。 今回は、あらかじめ用意しておいたイメージ・テンプレートを利用しています。

Post-Install Script

「Post-Install Script」は、サーバーが増強される際に自動で適用するスクリプトを指定することができます。 予め作成しておいたプロビジョニング・スクリプトや、専用のスクリプトを指定することが可能です。 たとえばウェブサーバーの場合、最新のコンテンツを自動で引き込むようなスクリプトを利用することで、どのサーバーでも最新のコンテンツを表示するように構成することが可能です。
プロビジョニング・スクリプトの詳細は、1.2.2 設定スクリプトの自動実行で解説しています。
 

オートスケール・ポリシーの設定
このポリシーは、仮想サーバーを増減させる条件をまとめたオートスケールの肝となる重要な設定項目です。 ポリシーは、「Policy Details」、「Triggers」、「Action」から構成され、「Policy Details」で、「Cooldown Period」を設定し、「Triggers」でサーバー増減の条件を設定し、「Action」でサーバーの増減方法を設定します。

ポリシーの作成は、注文画面をさらに下方にスクロールし、「Policies」画面内の「Add Policy」をクリックして行います。

今回は、CPUの負荷状況により仮想サーバーを増減させる設定を行います。 具体的には、以下の2つのポリシーを作成します。

負荷増大時のルール

 サーバーの増強の基準：CPU負荷が平均80%を超える状態が10分以上継続した時
 クールダウン時間の設定：グループ全体設定(3分)を利用
 仮想サーバーの増強台数：サーバーを1台ずつ増やす

負荷軽減時のルール

 サーバー削減時の基準：CPU負荷が平均30%未満となる状態が10分以上継続した時
 クールダウン時間の設定：グループ全体設定(3分)を利用
 仮想サーバーの削減台数：サーバー総数を2台にする

上記のクールダウン時間の3分の設定は、後述の動作確認用に短く設定した数値です。

Cooldown Period

クールダウン時間の設定をします。 グループ全体の共通設定を利用するほか、「Use Custom」を選択することで個別にクールダウン時間を設定することが可能です。

今回は、グループ共通の設定を利用するので、「Use Group Cooldown」を選択します。

「Cooldown Period」選択肢は次の2項目です。
「Use Group Cooldown」: groupの共通クールダウン時間を利用します
「Use Custom」: 個別にクールダウン時間を指定します

Triggers

仮想サーバーを増減するためのトリガー(発生条件)を設定します。 トリガーは、CPUやネットワークの負荷状況を条件とすることができるほか、特定の時間帯や、日時を指定した増減を設定することも可能です。 「add Watch」をクリックすると、トリガー内に新たな条件を追加することが可能です。 この場合、複数の条件が成立(and条件)した際にサーバーの増減をさせる。 といった内容になります。
また、「Add Trigger」をクリックするとポリシー内に複数のトリガーを指定することが可能です。 この場合、ポリシー内のいずれかのトリガー条件が成立(or条件)した際に、サーバーの増減をさせる。 といった内容になります。


トリガーに時刻を指定した場合、設定時刻はUTC(世界協定時)になっていますので注意が必要です。

今回は、CPUの負荷状況によってサーバーを増減させるため、「if my」を選択したうえで、個別条件にCPUを選択し、各種値を入力しています。

「Triggers」選択肢は次の3項目です。
「if my」: 仮想サーバー増減の条件に、CPUや、ネットワークリソースの負荷状況を指定できます。
「Every」: 仮想サーバー増減の条件に、曜日(複数可能)と時刻を指定できます。 毎週月曜日の9:00に増強する。 等の設定が可能です。
「Exactly on」: 仮想サーバー増減の条件に、日時を指定できます。 たとえば、2014/11/26 09:00 といった指定が可能です。

設定に表示される時刻は、UTC(世界協定時)のため、日本時間を指定する場合は、マイナス9時間する点が注意です。

Action

仮想サーバーの増減方法を設定します。 想定される負荷状況に応じ、以下の3つの項目から選択することが可能です。

「Action」選択肢は次の3項目です。 「Scale group to quantitiy(absolute)」:増減した結果、トータルで何台にするか？という指定方法です。
「Scale group to quantitiy」: 指定台数ずつサーバーを増減させます。
「Scale group to percentage」: 現状のサーバー台数に対し増減させる台数を比率(%)で指定することが可能です。

今回の設定では、サーバー増強時には、「Scale group to quantitiy」を選択し、1台ずつ増強させ、サーバー削減時には、「Scale group to quantitiy(absolute)」を選択し削減後の台数を2台にする。 という設定を行います。
 

ロードバランサーの設定
今回の例では、ロードバランサーの設定を行います。 設定画面の最下部の「Local Load Balancers」画面内の、「Add Load Balancer」をクリックし行います。

「Virtual IP」で、予め作成しておいたローカル・ロードバランサーのVIPを指定します。 これによって「Service Group」は、ロードバランサーで作成している内容が自動的に反映されます。 選択項目の中から設定する「Service Group」を選択します。
HTTPS(443)を利用する場合等、複数の「Service Group」を利用する場合には、画面左下の「Add Load Balancer」をクリックします。

ここまでの設定で、「Add Scale Group」の設定が完了しました。 「Add Group」をクリックしオートスケールの設定を確定させます。 これにより自動的に「Active」となります。

次の図は、「Active」になった直後の「Active Device」画面です。 「minimum member count」で設定した台数の仮想サーバーが作成されます。 「Start Date」が空欄になっていますが、サーバーの作成が完了するまでに、数分程度かかります。

次の画面は、ローカル・ロードバランサーの詳細画面です。 作成されたサーバーは、自動的にローカル・ロードバランサー配下に設置されることが確認ができます。


オートスケールの動作確認
ここでは、上記で設定したオートスケールの設定で実際にオートスケールを動作させ、サーバーが増減する様子を確認します。 サーバーの起動から、クールダウン時間が経過した後、負荷をかけ始めます。 今回は、負荷の与え方として、各サーバーにSSHログインし、yes >> /dev/nullコマンドを利用し、CPU使用率を100%近くまで上昇させます。 ここから、トリガーで設定した10分が経過するとサーバーの増設が始まります。

2台のサーバーに負荷をかけ10分が経過すると、1台増設が始まった様子が次の画面のように確認できます。

さらにアクティブなサーバー全てに負荷をかけていくと、設定どおり1台ずつサーバーが増強されていき、「maximum member count」で設定した5台まで増設されます。 さらに負荷をかけ続けても6台目の仮想サーバーは作成されません。

最大値の5台までサーバーが増強されたので、yes >> /dev/nullコマンドを停止し、負荷をかけるのを中止します。 クールダウン時間＋トリガーで設定した時間が経過した後、削減ポリシーの「Scale group to quantitiy(absolute)」の設定どおり、一気に2台まで台数が減ることが確認できます。 次の図は、サーバー削減後の「Active Device」の画面です。 サーバー台数が2台になったことが確認できます。

また、残ったサーバーが、先頭や、最後に作成されたサーバーではなく、1台目のサーバーと、3台目のサーバーであることが確認できます。 これは、ターミネート・ポリシーにて、「Closest to next charge」 (次の課金が一番近い順に削減)を選択し、削減が始まったタイミングで課金直前のサーバーが削除されたためです。
 

オートスケールの応用
KVSのクラスタメンバーの増強に利用する

オートスケールの機能は、ウェブサーバーだけではなく、ロードバランサーと連携する必要のないRiak等のKVSのクラスタメンバーの増減にも利用可能です。 次の図は、初期構成時にRiakのノードを3台用意し、負荷が増大した際には、5台に増強するイメージ図です。 増強ルールのActionで、「Scale group to quantitiy(absolute)」を選択し、台数に5を設定することで、増強時の台数を指定することが可能です。



仮想サーバー台数の比率で増減させる方法

オートスケールは、仮想サーバーの増減を比率(%)で設定することも可能です。 比率の設定は、サーバー総数に対する比率で増減しますので、たとえば比率を10%とした場合、仮想サーバーが負荷分散の配下で30台動作していれば、30台の10%である3台が増設されることになります。 総数が40台だった場合は、4台が一度に増設されますので、稼働規模に対し適切なサーバーの増設を行うことができます。

オートスケール時にサーバーを自動設定する方法

オートスケールの設定で、「Post-Install Script」を指定し、サーバーの初期化を行うことができます。 次の図は、Softlayerのオブジェクト・ストレージにウェブ・サーバー用の最新のコンテンツを配置しておき、サーバー増強時にCloudFuseでオブジェクト・ストレージのコンテナをマウントし、最新のコンテンツを自動的に引き込んでいる図です。

CloudFuseを利用したオブジェクト・ストレージのマウント方法は、5.1 オブジェクト・ストレージを利用するには？をご参照お願いします。

CentOS環境で、図の内容を自動で行うためには、次のような、スクリプトを作成し、「Post-Install Script」として登録しておきます。 下記の例は、最新のコンテンツを引き込む手順をスクリプトで実行する場合の例です。 最新のコンテンツをオブジェクト・ストレージから、オートスケールで新規に追加されたサーバーにコピーします。
下記のcloudfuseコマンドは、オブジェクト・ストレージをファイルシステムとしてマウントするソフトウェアです。
 
```
〜中略〜

# 1.オブジェクトストレージをマウントします。
cloudfuse /mnt/wwwcontent

# 2.最新のコンテンツをコピーします。
cp -rf /mnt/wwwcontent/m-SJC-container01/www/* /var/www/html/

# 3.httpdを起動します。
service httpd start

# 4.次回起動時に、httpdを自動で起動するように設定します。
chkconfig httpd on
```