Fujitsu Cloud Direct当社が提供するサービスを法人のお客様へ直接販売するサイトです。

この記事は、ニフクラブログで2019-12-12に公開された記事を移転したものです。 こんにちは、FJcloud-V(旧ニフクラ)テクニカルアカウントチームです。

FJcloud-V(旧ニフクラ)の「オートスケール」はご存知でしょうか。

あらかじめ設定したサーバー負荷の しきい値（閾値）を基に、自動でサーバーを追加/削除する機能です。 予想困難なタイミングでアクセスピークが発生するようなシステムにおいて有効な機能です。

「オートスケール」で追加されたサーバー(以降、スケールアウトサーバー)は、以下のタイミングで自動で削除されます。

• サーバー負荷低減時のスケールイン
• スケールアウトサーバーに設定されている有効時間(寿命)を超過したとき

そのため、永続保管したいデータ(ログファイル等)が存在する場合、オブジェクトストレージやNAS等、サーバー外部への退避が必要です。

そこで今回はOS機能のスタートアップスクリプトを使用し、スケールアウトしたWebサーバーのシスログをNAS上へ保存する手順の検証を実施してみました。

また、「オートスケール」はカスタマイズイメージを使用してスケールアウトするため、 イメージ元サーバーの設定を変更する場合は、カスタマイズイメージを最新化する必要があります。

設定変更のメンテナンス作業を効率化するTipsとして、カスタマイズイメージ取得と「オートスケール」組み込みをバッチ化する方法もご紹介します。

前提条件

本ブログは、以下の前提知識がある方を想定しています。

• FJcloud-V(旧ニフクラ)の基本的なコントロールパネルの操作、サービスを利用する知識 (サーバー作成、ネットワーク構築など)
• Linuxの基本的な操作、知識

利用リソース

※リソースのアクセス制限に関しては、FJcloud-V(旧ニフクラ)のファイアウォール等を用いて適切に設定の上実施しています。

・リソースの名称は以下のように設定しています。

※イメージ取得の日時でイメージ名を設定し、スケールアウトサーバーのリソース名はイメージ名に応じて決定します。

・検証に使用したソフトウェアのバージョン情報は以下の通りです。

検証準備

① ファイアウォールグループの作成

設定項目や設定値は省略させて頂きます。

※作成方法は、以下を参照してください。

クラウドヘルプ（ファイアウォールグループの新規作成）

クラウドヘルプ（ファイアウォール：ルールの追加）

② サーバーの作成

今回はCentOSを使用しているため、SSHキーの作成が必須となります。ここでは設定項目や設定値は省略させて頂きます。

※作成方法は、以下を参照してください。

クラウドヘルプ（SSHキー）

クラウドヘルプ（サーバーの作成）

③ NASの作成

ここでは、設定項目や設定値は省略させて頂きます。

※作成方法は、以下を参照してください。

クラウドヘルプ（NAS：NASファイアウォールグループの作成）

クラウドヘルプ（NAS：NASの作成）

④ ロードバランサー(L4)の作成

ここでは、設定項目や設定値は省略させて頂きます。

※作成方法は、以下を参照してください。

クラウドヘルプ（ロードバランサーの作成）

⑤ イメージ元サーバーの設定

Apacheをインストールします。

# yum -y install httpd
# systemctl enable httpd
# systemctl restart httpd
# systemctl status httpd

検証実施

① イメージ元サーバの設定

1．NASのマウント ログを保存するためNASをマウントします。

※/nasをマウントポイントとします。

# yum -y install nfs-utils
# mkdir /nas
# mount -t nfs4 [NASのプライベートIPアドレス]:/ /nas
# vi /etc/fstab
------------------------------------------------------------- 
[最終行に追加]
[NASのプライベートIPアドレス]/                            /nas      nfs     defaults        0 0
------------------------------------------------------------- 

続いて、スケールアウト時、NASのマウント処理がタイムアウトする場合の対策としてネットワークサービスのスリープ設定(/etc/sysconfig/network)を行います。

※スリープする時間は環境によって調整が必要となります。

# vi /etc/sysconfig/network
------------------------------------------------------------- 
[以下の設定を追加]
NETWORKDELAY=120
------------------------------------------------------------- 

2．シェルスクリプトの作成

スケールアウト時に実行するスタートアップスクリプトを作成します。

ここでは、スケールアウトサーバーを管理しやすくするため、ホスト名をグローバルIPに変更しています。

変更したホスト名毎に、NAS上でディレクトリを作成しログファイルを退避する動作となります。

※イメージ元サーバーの再起動時にホスト名を変更しないようにグローバルIPで条件分岐させています。

# vi [任意のディレクトリ]/LogSync.sh
------------------------------------------------------------- 
#! /bin/bash

GIP=`ip addr list ens160 | grep "inet " | cut -d' ' -f6 | cut -d/ -f1`
SOURCEGIP=[イメージ元のサーバーのグローバルIP]

if [ ${GIP} !=  ${SOURCEGIP} ]; then
  hostnamectl set-hostname $GIP
fi

DIRNAME=/nas/`date "+%Y%m%d"`/`uname -n`

if [ ! -d $DIRNAME ]; then
  mkdir -p $DIRNAME
fi

rsync -au /var/log/ $DIRNAME/
------------------------------------------------------------- 
# chmod 700 [任意のディレクトリ]/LogSync.sh
# ls -l [任意のディレクトリ]/LogSync.sh

作成したスクリプトをcronに登録し、定期実行させます。

※今回の検証では、10分間隔でログ退避していますが、負荷減少時のスケールインや寿命の設定によってスケールアウトサーバーが自動削除されるタイミングによっては、 ログ取得できない時間帯が発生します。必要に応じて、cronでの定期実行間隔の調整や、シスログサーバー等の収集方式を検討してください。

# crontab -e
-----------------------------------------------------------------------------------
[以下の設定を追加]
*/10 * * * * root /[任意のディレクトリ]/LogSync.sh
-----------------------------------------------------------------------------------
# crontab -l

3．ユニットファイルの作成

ここでは、ユニットファイルを作成しサーバー起動時のサービスを定義します。

# vi /etc/systemd/system/startup.service
※下記の設定値で作成

# systemctl daemon-reload
# systemctl enable startup.service
# systemctl restart startup.service
# systemctl status startup.service

② カスタマイズイメージの作成

※カスタマイズイメージの作成方法は、以下を参照してください。

クラウドヘルプ（サーバー：イメージ保存）

③ オートスケールの作成

1. 1.「オートスケール作成」を押下します。
2. 2.「OSイメージ」を選択します。
3. 3.「タイプ」を選択します。
4. 4.項目を入力し「サーバー設定へ」を押下します。
5. 5.項目を入力し「スケジュール設定へ」を押下します。
6. 6.「確認へ」を押下します。
7. 7.「作成する」を押下します。
8. 8.オートスケールが作成されたことを確認します。
9. 9.スケールアウトサーバーが作成されたことを確認します。

※FJcloud-V(旧ニフクラ)の仕様として、オートスケールを作成するとスケールアウトサーバーが生成されます。

※オートスケールの作成方法は、以下も参照してください。

クラウドヘルプ（オートスケール：作成）

④ スケールアウト

ここではスケールアウトサーバー#1に疑似的にCPUに負荷をかけて、サーバーをスケールアウトさせます。

1．以下コマンドで、スケールアウトサーバーに負荷をかけます。

# yes > /dev/null &

2．以下コマンドでCPU使用率を確認します。

# vmstat -t 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- -----timestamp-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st                 JST
 5  0      0 181880   2084 166476    0    0   213    24  582  908  3  1 95  1  0 2019-11-21 19:22:57
 5  0      0 181944   2084 166468    0    0     0     0  349   81 100  0  0  0  0 2019-11-21 19:22:58
 9  0      0 181944   2084 166468    0    0     0     0  290   58 100  0  0  0  0 2019-11-21 19:23:00
     ・
     ・
     ・
   以下略

※本検証では10分以上CPU使用率が80%超過した場合にスケールアウトします。

3．スケールアウトサーバー#2が作成されたことを確認します。

※上記で実施した疑似的な負荷発生のためのコマンドで実行しているプロセスはkillします。

⑤ スケールアウトサーバーの確認

ここでは、スケールアウトサーバー#2にログイン後、以下を確認します。

1．スタートアップスクリプトの起動を確認します。

# systemctl status startup.service

2．ホスト名が変更されているか確認します。

# uname -n
------------------------------------------------------------- 
スケールアウトサーバーのグローバルIP
------------------------------------------------------------- 

3．NAS上にディレクトリが作成されているか確認します。

# ls -l /nas/[yyyymmdd]/
-------------------------------------------------------------
/nas/[yyyymmdd]/スケールアウトサーバーのホスト名
-------------------------------------------------------------

4．NAS上にホスト名毎にログファイルが同期されているか確認します。

# ls -l /nas/[yyyymmdd]/[ホスト名]
-------------------------------------------------------------
【出力例】
total 5164
drwxr-xr-x 2 root   root      4096 Dec 13  2018 anaconda
drwx------ 2 root   root      4096 Dec 13  2018 audit
-rw------- 1 root   root    170797 Nov 21 19:13 boot.log
・
・
・
【省略】
-------------------------------------------------------------

5．作業PCでブラウザーを開き、ロードバランサーのIPに対してhttpアクセスします。

※事前にテスト用コンテンツを配備して確認しています。

6．スケールアウトサーバーのApacheのアクセスログから正しくロードバランサーに組み込みされたことを確認します。

# tail -f /var/log/httpd/access_log
------------------------------------------------------------- 
 [21/Nov/2019:20:16:29 +0900] "GET / HTTP/1.1" 200 112 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 

(KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
 [21/Nov/2019:20:16:29 +0900] "GET /favicon.ico HTTP/1.1" 200 - "http://xxx.xxx.xxx.xxx/" "Mozilla/5.0 (Windows NT 6.3; 

Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
------------------------------------------------------------- 

問題なく、スケールアウトとスタートアップスクリプトの動作を確認できました。

これで、本検証は終了となります。

Tips

ここでは、検証実施②、③をスクリプト化したものを紹介します。

イメージ元サーバーを変更した際に、 オートスケールで利用するカスタマイズイメージを最新化する作業が、FJcloud-V(旧ニフクラ)CLIを組み込んだシェルスクリプトを実行するだけとなり、コントロールパネルでの作業は不要となるため、作業の簡略化が期待できます。

※本スクリプトをcronに登録することで定期処理として自動化することができます。

「FJcloud-V(旧ニフクラ)CLI」実行に必要なツールをダウンロードします。

# wget https://cloud.nifty.com/api/sdk/NIFCLOUD_api-tools.zip
# unzip ./NIFCLOUD_api-tools.zip
# chmod +x ./NIFTY_Cloud_api-tools/bin/*
# yum install java-1.8.0-openjdk
# yum install java-1.8.0-openjdk-devel

カスタマイズイメージとオートスケールの作業をスクリプト化します。

# vi [任意のディレクトリ]/AutoScaleUpdate.sh
-------------------------------------------------------------
#!/bin/bash

###ニフクラCLI実行定義###
export JAVA_HOME=xxxxxxxxxx
export NIFTY_CLOUD_HOME=xxxxxxxxxx
export PATH=$PATH:$NIFTY_CLOUD_HOME/bin
export NIFTY_ACCESS_KEY_ID=xxxxxxxxxx
export NIFTY_SECRET_KEY=xxxxxxxxxx
export NIFTY_CLOUD_URL=xxxxxxxxxx

###変数###
SERVERNAME=[イメージ元のサーバー名]
NEWIMAGE=[作成するイメージ名]
SCALENAME=[作成するオートスケール名]

###イメージ新規作成###
nifty-create-image $SERVERNAME --name $NEWIMAGE --region-name east-2 --availability-zone east-21
sleep 30

###イメージID取得(配列に格納)###
changearray=(`nifty-describe-images -o self |grep $NEWIMAGE`)

###既存のオートスケール削除###
nifty-delete-auto-scaling-group $SCALENAME
sleep 30

###新規のイメージでオートスケール作成###
nifty-create-auto-scaling-group $SCALENAME --scaling-trigger "resource=Server-cpu,upper-threshold=80,breach-duration=600" --scaleout-condition and --min-size 1 --max-size 2 --change-in-capacity 1 --image-id "${changearray[1]}" --instance-type e-medium --group AutoScaleWebFW --load-balancer "name=AutoScaleLB,lb-port=80,instance-port=80" --instance-lifecycle-l

imit 18000 --scaleout 600
sleep 5
-------------------------------------------------------------

# chmod 700 [任意のディレクトリ]/AutoScaleUpdate.sh
# ls -l [任意のディレクトリ]/AutoScaleUpdate.sh

※本スクリプトはメンテナンス等、サービスが停止している状況を想定として作成しています。

# sh [任意のディレクトリ]/AutoScaleUpdate.sh

任意のカスタマイズイメージ名で作成されているか確認します。

作成したイメージを使用して、オートスケールが作成されているか確認します。

【注意点】

※カスタマイズイメージ取得毎に料金が発生します。

※オートスケールを削除すると、対応するスケールアウトサーバーが同時に削除されるため、 古いスケールアウトサーバーが削除されてから新たに作成されるまでの間、スケールアウトサーバーが存在しない時間帯が発生します。

まとめ

ログやホスト名の他にもイメージ元サーバーで固定値として設定しているものについては、スケールアウトサーバー側で別途、動的に設定変更するような検討が必要になります。

スタートアップスクリプトを組み込むことにより、オートスケール使用時の動的な設定変更にも対応できることを確認しました。今回はスケールアウト時の動作の一例として、ログファイルの退避を扱いましたが、パッケージ更新や簡単な設定変更の際にも対応できます。

ただしスタートアップスクリプトを変更する場合は、再度イメージ取得とオートスケール組み込みが必要になります。 上記Tipsのスクリプトでは、オートスケール再作成まで実施しているため、実行完了後にスケールアウトサーバーへ設定変更が反映されます。

本検証が、オートスケールを使用する上で参考になれば幸いです。

注意事項

• 本記事については検証結果の１つとなります。実際に検討される場合は、事前にそれぞれの要件を鑑みて実装するか確認してください。
• 検証目的のため、https通信を実装していません。実際に検討される場合は、適切な設定のもと実施してください。
• OS上の操作についても記載していますが、FJcloud-V(旧ニフクラ)ではOS以上はご利用者様の責任範囲となりますのでご留意ください。