FUJITSU Cloud Service K5
IaaS 設計・構築ガイド（デザインパターン・実装サンプル集）

オートスケール(負荷分散構成)


要求事項

Webサービスの可用性、および拡張性を考慮した構成をK5上で実現したいといった要求事項に対応するパターンです。
Webサービスの場合、サービスにアクセスできなくなる原因として、サーバダウンや、急なトラフィック増によるリソース不足が想定されます。
本パターンは、このようなサービス提供の機会損失を防ぐためのパターンです。

また、コストの面でも、必要な時に必要な仮想サーバしか使わないため、以下のような要求事項に対応します。

  • 最初は小規模で業務を始め、後から拡大したい（スモールスタート）
  • 負荷の変動が大きいが、予想される最大負荷に合わせると負荷が低い状態の運用コストが高くなるため、
    ベースを負荷の低い状態に合わせたい
  • 仮想サーバ異常時の復旧処理と、負荷上昇時の追加処理を共通にしたい



対応するK5デザインパターン概要

K5では、拡張性向上としてオートスケーリング機能があります。
また、性能向上と可用性向上として負荷分散機能があります。
この2つを組み合わせることで、サーバダウンや、急なトラフィック増によるリソース不足 (CPU、メモリ) にも
対応可能なWebサービスを構築することができます。

以下では、2台の仮想サーバの負荷が高い状態(※) になった場合に、イメージから仮想サーバを起動して、
起動した仮想サーバを 負荷分散機能 で自動で組み込む設定例を記載します。

※正確には、heatテンプレートに設定する AutoScalingGroup 内の仮想サーバの平均負荷が、
設定したしきい値より高い状態になった場合



構造 (イメージ図)



実装サンプル

本パターンでは、シングルAZ構成で、負荷分散かつオートスケールに対応した以下のサンプルについて記載します。

autoscale_template_sample.yaml.html



１．テンプレート設定内容

　(1) オートスケールのテンプレートの設定内容
　　　オートスケールのテンプレートでは、それぞれのセクションに以下の内容を設定します。

セクション
内容
heat_template_version"2013-05-23" で固定
descriptionテンプレートの説明を記載する。省略も可。
省略する場合は、descriptionセクションごと削除する。
parameters同じテンプレートを複数回配備する際に、変更の可能性がある項目（フレーバー、キーペアなど）とデフォルト値を設定する。
この値は、resourcesセクションで参照される。
resourcesオートスケールで制御する以下のようなリソースを定義する。
- 仮想サーバ (フレーバー、最小台数、最大台数、配備先のサブネット等)
- ロードバランサー (性能タイプ、インターネットからのアクセス可否、配備先のサブネット等)
- 負荷監視 (CPU使用率のしきい値、監視時間、異常とする検知数等)
- 状態監視 (仮想サーバで起動する httpd等にアクセスして、httpd等の稼働を監視)
- スケール処理 (負荷監視や状態監視でアラームがあがった場合の仮想サーバの増減処理)
outputsテンプレートを使ったスタックの作成/更新後に表示する内容を記載する。省略も可。
省略する場合は、outputsセクションごと削除する。

　(2) 本パターンのテンプレートの設定内容
　　　本パターンのテンプレートでは、以下の内容を設定します。

  • parameters セクション
    parameters セクションのパラメータ名は、任意に設定可能です。
パラメータ名
設定値
内容
az"jp-east-1b"AZを設定
subnet-id(IDを設定)仮想サーバやロードバランサーを配備する サブネットID を設定
param-image-id(IDを設定)仮想サーバの イメージID を設定
param-flavor"S-1"仮想サーバの フレーバー を設定
key-name"cdp_keypair2"仮想サーバにログインするための キーペア を設定
autoscale-security-group"SG_default", "SG_Web_Local", "SG_Maintenance"仮想サーバ用セキュリティグループを 名称 で設定
lb-security-group("SG_default","SG_LB_Local"の ID を設定)ロードバランサー用セキュリティグループを ID で設定
※ロードバランサー用のセキュリティグループは名称では設定できません
lb-name(任意の名称)ロードバランサー名 を設定

  • resources セクション
    resources セクションのリソース名は、任意に設定可能です。
    resources セクションで、以下のリソースタイプを用いて、オートスケール用のリソースを設定します。

    • スタック作成/更新時に仮想サーバとロードバランサーを作成するリソースタイプ
      FCX::AutoScaling::AutoScalingGroup
      FCX::AutoScaling::LaunchConfiguration
      FCX::ExpandableLoadBalancer::LoadBalancer

    • 仮想サーバの 負荷監視(CPU使用率等) や、仮想サーバの 状態監視(ヘルスチェック) で
      アラームをあげるリソースタイプ
      OS::Ceilometer::Alarm

    • 何らかのアラーム検知時に、仮想サーバに対して、
      スケールアウトやスケールイン、異常となった仮想サーバの復旧等のスケール処理をするリソースタイプ
      FCX::AutoScaling::ScalingPolicy

リソース名
リソースタイプ
設定内容
備考
基
本
設
定
web-server-groupFCX::AutoScaling::
AutoScalingGroup
オートスケールするサーバ群の
グループ化設定		スタック作成/更新時に、
仮想サーバの起動設定 "launch_config" と
ロードバランサーの起動設定 "fj-elb" に従って
仮想サーバとロードバランサーを作成
launch_configFCX::AutoScaling::
LaunchConfiguration		仮想サーバの起動設定
fj-elbFCX::ExpandableLoadBalancer::
LoadBalancer		ロードバランサーの起動設定
ア
ラ
ー
ム
設
定
cpu_alarm_highOS::Ceilometer::Alarmスケールアウトの契機となる
CPU使用率の条件設定		CPU使用率 50%超過 で "web_server_scaleout_policy" を実行
cpu_alarm_lowOS::Ceilometer::Alarmスケールインの契機となる
CPU使用率の条件設定		CPU使用率 15%未満 で "web_server_scalein_policy" を実行
elb_status_abnormalOS::Ceilometer::Alarmヘルスチェックの条件設定ヘルスチェックで異常検知 で "web_server_recovery_policy" を実行
ス
ケ
ー
ル
設
定
web_server_scaleout_policyFCX::AutoScaling::
ScalingPolicy		仮想サーバの
スケールアウトポリシー		アラーム検知時に仮想サーバを 1台追加
web_server_scalein_policyFCX::AutoScaling::
ScalingPolicy		仮想サーバの
スケールインポリシー		アラーム検知時に仮想サーバを 1台削除
web_server_recovery_policyFCX::AutoScaling::
ScalingPolicy		異常仮想サーバの
自動復旧用ポリシー		アラーム検知時に仮想サーバを 1台追加し、
異常となった仮想サーバ削除

※OS::Ceilometer::Alarm の設定と FCX::AutoScaling::ScalingPolicy の設定は、一対となるように作成してください。
※１つの FCX::AutoScaling::ScalingPolicy の設定を、複数の OS::Ceilometer::Alarm の設定で共用することはできません。



　(3) resources セクションの設定内容詳細
　　　オートスケールの基本的な設定を行うリソースと、アラーム設定とアラーム検知時の実行内容のリソースのペアの設定内容を記載します。

　　　　- 基本的な設定を行うリソース
　　　　　web-server-group、launch_config、fj-elb

　　　　- CPU使用率が高い場合のアラーム設定と、アラーム検知時の実行内容
　　　　　cpu_alarm_high、web_server_scaleout_policy

　　　　- CPU使用率が低い場合のアラーム設定と、アラーム検知時の実行内容
　　　　　cpu_alarm_low、web_server_scalein_policy

　　　　- ヘルスチェックで仮想サーバの異常を検知するアラーム設定と、アラーム検知時の実行内容
　　　　　elb_status_abnormal、web_server_recovery_policy


　　(3-a) 基本的な設定を行うリソース

  • web-server-group
    • リソースタイプ FCX::AutoScaling::AutoScalingGroup を設定
    • プロパティ LaunchConfigurationName で、指定するリソースから、仮想サーバの設定を読み込んで仮想サーバ群を作成
    • プロパティ LoadBalancerNames で、指定するリソースから、ロードバランサーの設定を読み込んでロードバランサーを作成
プロパティ
設定値
内容
AvailabilityZones{get_param: az}AZの設定を get_resource で参照
LaunchConfigurationName{get_resource: launch_config}仮想サーバの設定を get_resource で参照
MinSize"2"最小2台で設定
MaxSize"6"最大6台で設定
VPCZoneIdentifier{ get_param: subnet-id }仮想サーバを配備する サブネット を指定
HealthCheckGracePeriod"120"ロードバランサーによるヘルスチェックを 有効 に設定
HealthCheckType"ELB"ヘルスチェックは "ELB" で固定
Cooldown"750"次のスケール処理を行わない時間を 750秒(12分) で設定
LoadBalancerNames{get_resource: fj-elb}ロードバランサーの設定を get_resource で参照

プロパティ
設定値
内容
ImageId{ get_param: param-image-id }仮想サーバの イメージID を設定
InstanceType{ get_param: param-flavor }仮想サーバの フレーバー を設定
KeyName{ get_param: key-name}仮想サーバの キーペア を設定
SecurityGroups{get_param: autoscale-security-group}仮想サーバの セキュリティグループ "SG_Web" を設定
BlockDeviceMappingsV2以下の子項目を設定仮想サーバにアタッチするブロックストレージで起動ディスクを設定
子
項
目
source_type"image"イメージから作成するため "image" を設定
destination_type"volume"ブロックストレージでの利用とする "volume" を設定
boot_index"0""0" の場合、アタッチするボリュームを起動ディスクに指定
device_name"/dev/vda"仮想サーバの OS 内のデバイス名を指定 (必ず連番に指定)
volume_size"40"容量を設定
uuid{get_param: param-image-id}イメージID を設定
delete_on_terminationtrue仮想サーバを削除した時に合わせてディスクを削除するよう設定
UserData(スクリプト)起動後に実行するスクリプトを設定

  • fj-elb
    • リソースタイプ FCX::ExpandableLoadBalancer::LoadBalancer を設定
    • ロードバランサーの作成に必要な情報を設定
    • ロードバランサーに割り当てるセキュリティグループは、
      セキュリティグループ/ファイアーウォール併用パターン に記載の "SG_LB" とします
    • リソースタイプが FCX::AutoScaling::AutoScalingGroup のリソースから参照されます
プロパティ
設定値
内容
Subnets{ get_param: subnet-id }ロードバランサーを配備するサブネット
SecurityGroups{ get_param: lb-security-group }ロードバランサー のセキュリティグループ "SG_LB" を設定
Listeners以下の子項目を設定ロードバランサーのリスナーの設定
子
項
目
LoadBalancerPort"80"ロードバランサーが待ち受けする ポート番号 を設定
InstancePort"81"転送先の仮想サーバの ポート番号 を設定
Protocol"HTTP"ロードバランサーが待ち受けする プロトコル を設定
InstanceProtocol"HTTP"転送先の仮想サーバの プロトコル を設定
HealthCheck以下の子項目を設定ヘルスチェック設定
子
項
目
Target"HTTP:81/index.html"仮想サーバの 81/tcp で /index.html を取得
HealthyThreshold"3"仮想サーバが回復したと判断するアクセス成功回数を 3回 と設定
UnhealthyThreshold"3"仮想サーバが停止したと判断するアクセス失敗回数を 3回 と設定
Interval"10"ヘルスチェックの実施間隔を10秒 に設定
Timeout"5"タイムアウトを 5秒 に設定
Version"2014-09-30"固定値
Scheme"internal"内部用ロードバランサーとして "internal" を設定
LoadBalancerName{ get_param: lb-name }ロードバランサー名



　　(3-b) CPU使用率が高い場合のアラーム設定と、アラーム検知時の実行内容

  • cpu_alarm_high
    • リソースタイプ OS::Ceilometer::Alarm を設定
    • 以下では、CPU使用率 (fcx.compute.cpu_util) の 1分間 (period) あたりの 平均値 (statistic:avg) が、
      しきい値50% (threshold) を 1度 (evaluation_periods) でも超えた (comparison_operator:gt) 場合に、
      web_server_scaleout_policy を実行する (alarm_actions) という設定をしています
    • 最小台数の 2台で稼働している仮想サーバが、1台が CPU使用率 40%、もう 1台が CPU使用率 70% で 1分間経過すると、
      CPU使用率の平均が 55%でしきい値を超えるため、スケール処理が実行されます
プロパティ
設定値
内容
meter_namefcx.compute.cpu_util
仮想サーバのCPU使用率を監視するアラームを設定
statistic"avg"統計種別：使用率は avg（平均値） を測定
period"60"監視間隔を 60秒間 で設定
evaluation_periods"1"アラーム判定回数（しきい値超えの回数）を 1回 で設定
threshold"50%"しきい値を 50% で設定
alarm_actions{ get_attr: [web_server_scaleout_policy, AlarmUrl] }しきい値超えと判定した際に行うアクション
matching_metadata{'metadata.user_metadata.groupname':
{get_resource: 'web-server-group'}}		メタデータ検索条件（監視対象を設定）
comparison_operator"gt"条件判定式で gt：より大きい場合 を設定

  • web_server_scaleout_policy
    • 上記のリソースタイプ OS::Ceilometer::Alarm のリソース cpu_alarm_high でアラーム検知時に実行する内容を、
      このリソースに、リソースタイプ FCX::AutoScaling::ScalingPolicy で設定します
    • OS::Ceilometer::Alarm と FCX::AutoScaling::ScalingPolicy は、一対になるように設定します
プロパティ
設定値
内容
AdjustmentTypeChangeInCapacity仮想サーバの増減タイプ
"ChangeInCapacity" の場合、
"ScalingAdjustment" で指定した数を追加/削除する
AutoScalingGroupName{ get_resource: web-server-group }スケーリングポリシーを設定するスケーリンググループを get_resource で設定
ScalingAdjustment"1"仮想サーバの増減数 を、1台追加 で設定



　　(3-c) CPU使用率が低い場合のアラーム設定と、アラーム検知時の実行内容

  • cpu_alarm_low
    • リソースタイプ OS::Ceilometer::Alarm を設定
    • 以下では、CPU使用率 (fcx.compute.cpu_util) の 1分間 (period) あたりの 平均値 (statistic:avg) が、
      しきい値15% (threshold) を 1度 (evaluation_periods) でも下回った (comparison_operator:lt) 場合に、
      web_server_scalein_policy を実行する (alarm_actions) という設定をしています
    • 仮想サーバ がスケールアウトして 3台稼働している場合、1台が CPU使用率 22%、2台が CPU使用率 10% で 1分間経過すると、
      CPU使用率の平均が 14%でしきい値を下回るため、スケール処理が実行されます
プロパティ
設定値
内容
meter_namefcx.compute.cpu_util
仮想サーバのCPU使用率を監視するアラームを設定
statistic"avg"統計種別：使用率は avg（平均値） を測定
period"60"監視間隔を 60秒間 で設定
evaluation_periods"1"アラーム判定回数（しきい値超えの回数）を 1回 で設定
threshold"15"しきい値を 15% で設定
alarm_actions{ get_attr: [web_server_scalein_policy, AlarmUrl] }しきい値超えと判定した際に行うアクション
matching_metadata{'metadata.user_metadata.groupname':
{get_resource: 'web-server-group'}}		メタデータ検索条件（監視対象を設定）
comparison_operator"lt"条件判定式で lt：より小さい場合 を設定

  • web_server_scalein_policy
    • 上記のリソースタイプ OS::Ceilometer::Alarm のリソース cpu_alarm_low でアラーム検知時に実行する内容を、
      このリソースに、リソースタイプ FCX::AutoScaling::ScalingPolicy で設定します
    • OS::Ceilometer::Alarm と FCX::AutoScaling::ScalingPolicy は、一対になるように設定します
プロパティ
設定値
内容
AdjustmentTypeChangeInCapacity仮想サーバの増減タイプ
"ChangeInCapacity" の場合、
"ScalingAdjustment" で指定した数を追加/削除する
AutoScalingGroupName{ get_resource: web-server-group }スケーリングポリシーを設定するスケーリンググループを get_resource で設定
ScalingAdjustment"-1"仮想サーバの増減数 を、1台削除 で設定



　　(3-d) ヘルスチェックで仮想サーバの異常を検知するアラーム設定と、アラーム検知時の実行内容

  • elb_status_abnormal
    • リソースタイプ OS::Ceilometer::Alarm を設定
    • 以下では、異常な仮想サーバ数 (fcx.loadbalancing.instance.unhealthy) の 1分間 (period) あたりの 最小値
      (statistic:min) が、しきい値1回 (threshold) を 1度 (evaluation_periods) でも上回った (comparison_operator:ge)
      場合に、web_server_scalein_policy を実行する (alarm_actions) という設定をしています
プロパティ
設定値
内容
meter_namefcx.loadbalancing.instance.unhealthyヘルスチェックのアラームを設定
statistic"min"統計種別：異常となった仮想サーバ数を数えるよう、"min"を指定
period"60"監視間隔を 60秒間 で設定
evaluation_periods"1"アラーム判定回数（しきい値超えの回数）を 1回 で設定
repeat_actionstrueアクション繰り返し※ヘルスチェック機能を使用する場合は"true"を指定
threshold"1"しきい値となる異常仮想サーバの数を指定、'1' なら、1台でも異常となればスケールアウト
alarm_actions{ get_attr: [web_server_recovery_policy, AlarmUrl]}しきい値超えと判定した際に行うアクション
matching_metadata{ 'resource_id': {get_param: lb-name}}メタデータ検索条件（監視対象を設定）
comparison_operator"ge"条件判定式で ge：以上 を設定

  • web_server_recovery_policy
    • 上記のリソースタイプ OS::Ceilometer::Alarm のリソース elb_status_abnormal でアラーム検知時に実行する内容を、
      このリソースに、リソースタイプ FCX::AutoScaling::ScalingPolicy で設定します
    • OS::Ceilometer::Alarm と FCX::AutoScaling::ScalingPolicy は、一対になるように設定します
プロパティ
設定値
内容
AdjustmentTypeChangeInCapacity仮想サーバの増減タイプ
"ChangeInCapacity" の場合、
"ScalingAdjustment" で指定した数を追加/削除する
AutoScalingGroupName{ get_resource: web-server-group }スケーリングポリシーを設定するスケーリンググループを get_resource で設定
ScalingAdjustment"1"仮想サーバの増減数 を、1台追加 で設定



２．テンプレートの配備


　　テンプレートを配備すると、テンプレートで設定した内容でシステムが構築されます。
　　テンプレートの配備については、テンプレート配備パターン の実装サンプル　１ (2) スタックの作成　を参照してください。



メリット・効果

負荷分散機能、オートスケール機能を利用した場合のメリット・効果は以下の通りです。

  • 仮想サーバ群の自動拡張・縮小によるリソースの最適化と運用コスト抑制
  • 負荷分散とオートスケールによる拡張性向上
  • 仮想サーバ復旧処理と仮想サーバ拡張処理の共通化による運用・保守性向上



注意事項

  • 本パターンは2016年7月時点のK5(IaaS)で動作検証しています。

  • スタックを作成すると、リソースの配備が行われます。一覧を取得した際にエラーが発生していないか都度確認してください。

  • スタックを作成するユーザのロールには、"cpf_systemowner" 権限が必要です。

  • オートスケールで配備される仮想サーバは、スケールイン等により削除されることがあるため、内部データの永続的な保持はできません。
    そのため、仮想サーバ上のアプリケーションは、APIの応答や外部のDBを活用して、状態を保持しないステートレスな実装にする必要があります。

  • オートスケールで配備するシステムについて、構成変更や、セキュリティの状態の最新化等のシステム運用内容を検討してください。
    • 仮想サーバにセキュリティパッチをあてた状態にしたい場合は、
      リソースタイプ FCX::AutoScaling::LaunchConfiguration の ImageId で指定している仮想サーバのイメージを、
      セキュリティパッチが適用された状態のイメージに置き換える必要があります。
      詳細は オートスケールのシステムの運用について を参照してください。

    • オートスケールさせる構成を変更したい場合、例えば現状が最小2台最大6台のところを、
      最小5台最大7台等に変更したい場合についても、
      同様に オートスケールのシステムの運用について を参照してください。

  • 仮想サーバ上のミドルウェアとアプリケーションの起動には時間がかかる場合があります。
    そのため、事前に起動時間を測定し、以下の設定を行う必要があります。
    • 仮想サーバ増設のしきい値を越えた後、仮想サーバ増設が完了するまでは、次の増設を行わないように、
      Cooldown 時間 を適切に設定してください。
      Cooldown 時間 の設定による挙動については、
      Cooldown 時間 の設定例について を参照してください。

    • 仮想サーバの起動完了前にロードバランサーサービスのヘルスチェックが動作すると、異常と誤判定されてしまいます。
      そのため、仮想サーバの起動完了前にヘルスチェックが動作しないよう、
      HealthCheckGracePeriod 時間 を適切に設定してください。
      HealthCheckGracePeriod 時間 の設定による挙動については、
      HealthCheckGracePeriod 時間 の設定例について を参照してください。

    • 負荷の上昇を検知してから、仮想サーバが起動するまでの時間差を考慮して、
      仮想サーバを増設するためのしきい値を、余裕を持たせて設定してください。

    • 仮想サーバのスケールアウトとスケールインのしきい値は、検証の上、適切に設定してください。
      スケールアウトとスケールインのしきい値が近い値の場合、頻繁にスケール処理で仮想サーバの増減設が行われてしまう等、
      期待するスケール処理と異なる動きとなる場合があります。

    • これらの設定の詳細については、「HEATテンプレート解説書」の
      「Heat Orchestration Template reference リソースタイプ詳細」から、「Auto Scaling」を参照してください。

  • 自動復旧機能が動作した場合に追加される仮想サーバ数は、ヘルスチェック機能を使用するスケーリンググループに
    設定されるスケーリングポリシーに従います。自動復旧が行われると仮想サーバの数は以下の式のようになります。

「自動復旧前のスケーリンググループ内で起動している仮想サーバの数」＋
「スケーリングポリシーに設定されている追加する仮想サーバの数」－
「ヘルスチェックで異常とされた仮想サーバの数」

  • 異常を検知した仮想サーバを削除した結果、スケーリンググループで設定した仮想サーバの最小数を下回ることがあります。
    その場合、設定されている最小数まで自動的に仮想サーバが追加されます。



その他

オートスケールのシステムの運用について

　　オートスケールのシステムでは、仮想サーバはテンプレートで指定したイメージから作成されます。
　　起動中の仮想サーバにセキュリティパッチをあてたり、ミドルウェアを導入したり、データを投入しても、ヘルスチェック等のオートスケールの処理によって、
　　その仮想サーバが削除されることがあります。

　　　※オートスケールでは、仮想サーバを起動する台数のみ設定できます。
　　　※起動した仮想サーバは自動で入れ替わる可能性があり、連続して動作しつづけるとは限りません。

　　そのため、仮想サーバに何らかの変更をしたい場合は、テンプレートに設定している仮想サーバのイメージ自体を変更する必要があります。


　(1) オートスケールのシステムのイメージ入れ替え方法

　　　仮想サーバのイメージは、リソースタイプ FCX::AutoScaling::LaunchConfiguration の ImageId で指定しています。
　　　仮想サーバのイメージを変更するには、以下の手順で、ImageId を新しいイメージに変更する方式を推奨します。

■前提

  1. テンプレート201605版（プライベートイメージ201605版）が稼働中とします。
  2. テンプレート201605版で作成されたロードバランサーに対して、DNS の CNAME でサービス用の FQDN が付与されているものとします。

■変更手順

  1. プライベートイメージ201605版から仮想サーバを構築します。
  2. 仮想サーバにセキュリティパッチを適用する等の必要な変更を行います。
  3. 変更をした仮想サーバから、プライベートイメージ201606版を作成します。
  4. テンプレート201605版（プライベートイメージ201605版）から、
    parametersセクションに設定した ImageId のデフォルト値 を プライベートイメージ201606版 に変更して、
    テンプレート201606版（プライベートイメージ201606版）を作成します。
  5. テンプレート201606版を使って、システムを構築（スタック作成）します。
  6. テンプレート201606版で構築したシステムの動作確認を行います。
  7. テンプレート201606版で作成されたロードバランサーに対して、DNS の CNAME でサービス用の FQDN が付与して、
    サービスをテンプレート201605版から切り替えます。
  8. テンプレート201605版を削除（スタック削除）します。


　　なお、テンプレートから構築したシステムの作成と削除については、テンプレート配備パターン の実装サンプルの スタックの作成/削除 を参照してください。

　　 - スタックの作成
　　 - スタックの削除


　(2) 仮想サーバの最小台数と最大台数の変更方法

　　　仮想サーバの最小台数と最大台数は、リソースタイプ FCX::AutoScaling::AutoScalingGroup の MinSize と MaxSize で指定しています。
　　　仮想サーバの最小台数と最大台数を以下のように変更する場合は、スタックの更新 で変更することができます。

■前提

  1. テンプレート201605版（プライベートイメージ201605版）が、最小2台、最大6台で稼働中とします。
  2. 仮想サーバの台数を、最小5台、最大7台に変更するものとします。

■変更手順

  1. テンプレート201605版（プライベートイメージ201605版）から、MinSize を 2台 から 5台に、MaxSize を 6台 から 7台に変更して、
    テンプレート201606版（プライベートイメージ201606版）を作成します。
  2. テンプレート201606版を使って、システムを変更（スタック更新）します。
  3. テンプレート201606版で変更したシステムの動作確認を行います。


　　なお、テンプレートから構築したシステムの更新については、テンプレート配備パターン の実装サンプルの スタックの更新 を参照してください。

　　 - スタックの更新


　(3) スタックの作成/削除と、スタックの更新 の使い分けについて

　　　(1) の仮想サーバのイメージでは、スタックの作成/削除 の手順を記載しました。
　　　これに対して (2) の 仮想サーバの最小台数と最大台数では、スタックの更新 の手順を記載しました。

　　　テンプレートをどちらの手順で修正するかについては、プロパティが スタックの更新 により変更可能か、
　　　システムの入替が必要か、システムを入れ替える前に動作確認が必要か を考慮して決定してください。

※基本的には、スタックの作成/削除 を推奨します。


■プロパティがスタックの更新により変更可能か

　　　「HEATテンプレート解説書」 の 「付録 A リソースタイプのロパティ一覧」 の「A.1 AutoScaling」 で、
　　　「変更可能」 欄が "○" のプロパティについては、スタックの更新 で変更することができます。
　　　「変更可能」 欄が "空白" のプロパティについては、スタックの作成/削除 で変更することを推奨します。

　　　「変更可能」 欄が "空白" のプロパティに対して、スタックの更新 で変更を行うことも処理としては可能ですが、
　　　内部的にはそのプロパティに関連する仮想サーバやロードバランサー等のリソースが削除され、新しく作成される動きになります。
　　　そのため、稼働中のシステムに対して大きな影響がありますので、「変更可能」 欄が "空白" のプロパティに対しては、
　　　スタックの作成/削除 で変更することを推奨します。

　　　「変更可能」 欄が "○" のプロパティであれば、スタックの更新 で変更しても、
　　　稼働中のシステムに対してシステムの作り直し等の大きな影響を与えることはありません。

※2016年7月時点の注意事項2-12 で、
　「オートスケールにおいて、テンプレートで作成したスタックを更新すると、
　　すでに配備されているリソースが削除され、再構築されます」　という記載があります。
　そのため、変更可能なプロパティでも、実際に変更可能か、必ず動作確認をしてください。


■システムの入替が必要か／システムの入替前に動作確認が必要か

　　　新しいシステムについて、動作確認した後に入れ替えるといった運用形態としたい場合には、スタックの更新 は利用せずに、
　　　スタックの作成/削除 でシステムを変更することを推奨します。



Cooldown 時間 の設定例について

　　スケール処理によって仮想サーバが起動された後は、次のスケール処理が不必要に連続して起動されないように、Cooldown時間を設定します。

スケール処理によって仮想サーバが起動された直後は、まだ十分に負荷が分散されないため CPU使用率のしきい値越え状態が発生することがあります。
このような場合に、次のスケール処理が起動されないようにするため、Cooldown時間を設定します。

　　仮想サーバが OS起動時の処理等で CPU使用率が上がってしまった場合でも、Cooldown 時間内に CPU使用率が正常化すれば、
　　次のスケール処理は動きません。

■適切な Cooldown 時間を設定した例



　　Cooldown 時間が適切に設定されていないと、OS起動時の処理等で仮想サーバの CPU使用率が上がってしまった場合に次のスケール処理が動き、
　　下図のように、MaxSize で設定した台数まで次々と仮想サーバを作成する 動きになります。

■Cooldown 時間が短すぎる設定の例



HealthCheckGracePeriod 時間 の設定例について

　　仮想サーバが作成されて、OSが起動した後は、仮想サーバが正常に稼働しているか監視するヘルスチェックが動きます。
　　ヘルスチェックは、OSが起動してから、HealthCheckGracePeriod で指定した時間が経過した後に開始されます。

　　HealthCheckGracePeriod の設定と、Cooldown 時間と、仮想サーバが正常に稼働した時点とのタイミングにより、
　　以下のようにオートスケールでスケール処理する／しないの挙動が変わります。

パターン
CooldownHealthCheck
GracePeriod		オートスケールの挙動備考
パターン1　後　 　後　 スケールアウトしない 望ましい設定
パターン2　前　 　後　 スケールアウトしない たまたま問題なく動いているだけで、
設定上は問題あり
パターン3　後　 　前 スケールアウトしない
パターン4　前　 　前　延々とスケールアウト NG設定



■パターン1：Cooldown 時間の完了と HealthCheckGracePeriod 時間の完了がともに仮想サーバが正常稼働後となるパターン



■パターン2：Cooldown 時間の完了が仮想サーバが正常稼働後より 前 となるパターン

※パターン2 では、ヘルスチェック上はたまたま正常に動きますが、Cooldown 時間が経過した後、
CPU負荷の方で条件が満たせば、スケール処理が動きます。



■パターン3：HealthCheckGracePeriod 時間の完了が仮想サーバが正常稼働後より 前 となるパターン

※パターン3 では、ヘルスチェックで異常があったことが記録に残ります。
後々、ヘルスチェックの異常が起きたかどうかを確認する際などで、上記の異常検知により、誤った状況判断をしてしまう可能性があります。
そのため、たまたま、上記のイメージのように動きますが、設定上は不適切です。



■パターン4：Cooldown 時間の完了と HealthCheckGracePeriod 時間の完了がともに仮想サーバが正常稼働より 前 となるパターン

新しい仮想サーバが作成され、ヘルスチェックで異常となった仮想サーバが削除されます。
仮想サーバが削除されることで、MaxSize に台数が達しないため、延々と仮想サーバの作成/削除が繰り返されることになります。



関連資料

  • FUJITSU Cloud Service K5 マニュアル
    http://jp.fujitsu.com/solutions/cloud/k5/document/
    • サービスご紹介資料
    • IaaS 機能説明書
    • IaaS サービスポータルユーザーズガイド
    • IaaS APIユーザーズガイド
    • IaaS APIリファレンスマニュアル
    • IaaS HEATテンプレート解説書

(2016年7月検証)