さくらのクラウドでAuto Scaling – 「楽しいさくらのクラウド」(14)

公開日
更新日

現在、さくらのクラウドではオートスケール機能を正式リリースしております。コントロールパネルから簡単に設定可能となっており、オートスケール用の監視サーバも不要です。詳細につきましては「さくらのクラウドドキュメント オートスケール」をご確認ください。

こんにちは。さくらインターネット クラウド開発室の大喜多です。
このたび「さくらのクラウド」では、サーバへのアクセスが増加した際にサーバを自動で追加するスケールアウトと、負荷が減少した際にスケールアウトしたサーバを削除するスケールインを自動で行う「AutoScaling」のデモプログラムを公開しました。本記事では「ロードバランサ」アプライアンスと「クローン機能」を組み合わせたAutoScalingの仕組みと手順を解説します。

※デモプログラムはgithub上で公開しております。詳細は以下URLをご参照ください。
https://github.com/sakura-internet/saklient-autoscaling-demo
※デモプログラムの実行により、課金対象のリソースが作成されます。予期しない台数のサーバが作成され想定外の課金が発生した等の場合でも、弊社ではご対応いたしかねます。その点をご留意の上、実行していただくようにお願いいたします。

 

1. 今回の構成

今回は、初期状態として以下の構成を想定します。
n1

「ルータ＋スイッチ」を作成し、その配下に1台のロードバランサと1台のウェブサーバが接続されています。
ウェブサーバとは別に、デモプログラムを実行する「オートスケール用監視サーバ」を構築します。
※「ルータ＋スイッチ」の作成やネットワーク構成の操作方法については、公式マニュアルやさくらのナレッジ「ルータ＋スイッチを使ったネットワークを構築してみよう」が参考になります。
アクセスが閑散としている場合はこの構成で運用しますが、アクセスの増大により1台のウェブサーバでは捌ききれなくなった場合は平行してウェブサーバを追加し、ロードバランサによる負荷分散を図ります。
n2
このように、同一の性能を持つ機器を追加して負荷を分散させることを「スケールアウト」と呼びます。また、負荷が減少した際にスケールアウトしたサーバを削除することを「スケールイン」と呼びます。さくらのクラウドでは仮想的にスイッチやサーバを組み合わせてネットワークを作成することができるので、スケールアウトさせる場合も素早く構成が可能であり、物理環境のようにあらかじめ機材を用意する必要もありません。また、クラウドではサーバの時間課金に対応していますので、必要なときに必要な数だけスケールアウトさせ、負荷が減少した際にスケールインさせることで、コストの適正化を図ることができます。スケールアウト・スケールインによる伸縮自在なシステム構成は、クラウドのメリットをより活用することができる手法と言えます。
また、さくらのクラウドでは、これまで「スケールアウト」「スケールイン」ともにコントロールパネルから操作する必要がありましたが、今回ご紹介するクライアントライブラリ「Saklient」を活用したオートスケーリングツールを利用することで、一連の作業を完全自動化させることができます。

 

2. ロードバランサの設定

最初にロードバランサの設定を行います。作成したロードバランサは、左側のメニューから「ロードバランサ」を選択します。ここで作成済みのロードバランサの一覧が表示されるので、該当のロードバランサ行をダブルクリックします。
WS000284
ロードバランサの情報画面が表示されるので、上部の「VIP設定」タブをクリックします。VIPは外部からの接続を受け持つ仮想IPアドレス(Virtual IP address)のことで、このIPアドレスへの接続がロードバランサにより配下の複数のサーバに分散されます。
初期状態では何も設定されていないので、右下の「追加」ボタンをクリックし、VIPの追加作業を始めます。
WS000286
設定ダイアログボックスが表示されるので、ここでVIPを設定します。今回の構成例では以下の値を入力しました。

 

VIPアドレス 「ルータ＋スイッチ」で払い出されたIPアドレスのうち1個をロードバランサが受け持つ仮想IPアドレスに割り当て、そのIPアドレスを入力します。
ポート番号 仮想IPアドレスで着信を受けるポート番号を設定します。今回はロードバランシング先はウェブサーバのため「80」を設定します。
チェック間隔 実サーバの死活監視を実行する間隔を秒数で設定します。今回はデフォルトの「10」(10秒)を設定しました。

設定が完了すると、VIP設定のリストに今回設定したVIP設定が追加されます。続いて、VIPに着信した接続の振り分け先となる実サーバを設定します。VIPごとにタブが追加されるので、今回設定したVIPのタブをクリックします。
WS000290
この画面では設定済みの実サーバのリストが表示されますが、こちらも初期状態ではひとつも設定されていないので「追加」ボタンをクリックして追加を行います。
WS000291
設定ダイアログボックスが表示されるので、ここで実サーバの情報を設定します。今回の構成例では以下の値を入力しました。

 

IPアドレス ロードバランシング先のサーバ(今回はルータ＋スイッチ配下のウェブサーバ)のIPアドレスを設定します。
監視方法 IPアドレス、ポート番号で指定したロードバランシング先サーバの監視方法を設定します。この監視設定で異常のあるサーバは振り分け先から除外されます。今回はウェブサーバなので監視方法に「http」を指定し、監視対象パスとレスポンスコードはそれぞれ「/」と「200」を設定しました。

設定が完了すると、VIP設定のリストに今回設定したVIP設定が追加されます。
WS000294
なお、ロードバランサはコントロールパネルでの一連の設定後に実際のロードバランサに設定を投入する仕組みとなっているので、「反映」ボタンをクリックして設定内容を反映させます(まだ起動していない場合は電源操作メニューより「起動」を選択してください)。
設定完了後、仮想IPアドレスとして設定したIPアドレスに接続すると、実サーバとして登録した1台のウェブサーバからの応答としてウェブページが表示されます。

 

3. 1台目のウェブサーバの作成・設定

 

ウェブサーバ作成時の留意点

1台目のウェブサーバをコントロールパネルから作成します。サーバ作成時に留意すべき事項は以下の通りです。
・サーバは、前項で作成した「ルータ＋スイッチ」に接続してください
・サーバには

autoscaling-demo

タグを付与してください

 

DSR方式対応のための設定変更手順

さくらのクラウドで提供するロードバランサはDSR方式で動作するため、ロードバランシング先のサーバではループバックアドレスに仮想IPアドレスを設定する必要があります。1台目のウェブサーバでは、クローンにより追加するウェブサーバのテンプレートも兼ねてこの設定を投入しておきます。
※以下の例では、CentOS6系を想定した手順とします。

 

sysctl.confへの設定追加

ループバックアドレスに設定した仮想IPアドレスでARPリクエストに応答しないようにカーネルパラメータを設定します。/etc/sysctl.confファイルに以下の2行の設定を追記します。

 

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

設定後、"sysctl -p"コマンドで設定を反映します。

lo:0デバイスの作成

新たにlo:0デバイスを作成し、仮想IPアドレス(今回の構成例では203.0.113.8)を設定します。/etc/sysconfig/network-scripts/ifcfg-lo:0ファイルを新規に作成し、以下の内容を記載します。

 

DEVICE=lo:0
IPADDR=仮想IPアドレス
NETMASK=255.255.255.255

設定後、"ifup lo:0"コマンドで設定を反映します。

また、本項で解説しました設定変更を簡単に行えるスタートアップスクリプト「lb-dsr」をリリース致しましたので、こちらをご活用いただけると幸いです。

 

その他の設定

サーバとして必要なサービスの起動設定やコンテンツ、データの転送を行います。今回の例ではウェブサーバのため、Apacheを動作させ、コンテンツを公開ディレクトリに転送させておきます。

 

4. オートスケール用監視サーバの準備

ウェブサーバをモニタリングしてAutoScalingさせるプログラムを実行させるサーバを用意します。今回の例ではクラウド上にサーバを作成して実行しています。
コントロールパネルからサーバを作成し、以下の手順に沿ってセットアップします。
※以下手順は「さくらのクラウド」上にCentOS6.7のパブリックアーカイブを使用して作成した仮想サーバにて動作確認している手順になります。

 

rbenvのインストール

デモプログラムはRuby 2.1.4で動作するため、rbenvを使用して指定バージョンをインストールできるようにします。
rbenvインストールに必要な依存パッケージをインストールします。

# yum install -y openssl-devel readline-devel zlib-devel

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

# git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
# echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
# echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
# exec $SHELL -l
# rbenv --version
rbenv 1.0.0-19-g29b4da7
# git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

Ruby 2.1.4をインストールします。

# rbenv install -v 2.1.4
# rbenv rehash
# rbenv versions
  2.1.4
# rbenv global 2.1.4

Ruby 2.1.4がインストールされていることを確認します。

# ruby -v
ruby 2.1.4p265 (2014-10-27 revision 48166) [x86_64-linux]

 

Saklientとデモプログラムのインストール

デモプログラムではさくらのクラウドをAPI経由でコントロールするために
Saklientと呼ばれるライブラリを使用していますので、bundlerでインストールします。

 

# gem install bundler
# cd /usr/local/src/
# git clone https://github.com/sakura-internet/saklient-autoscaling-demo.git
# cd saklient-autoscaling-demo/
# bundle install --path vendor/bundle

 

デモプログラムの設定

デモプログラムを動作させるための設定を行います。
config.yml.sampleをコピーしてconfig.ymlファイルを作成します。

# cd /usr/local/src/saklient-autoscaling-demo/config
# cp config.yml.example config.yml

config.ymlファイルを以下の通り書き換えます。

# vi config.yml

 

# コントロールパネルより作成したAPIキーを指定してください
# https://secure.sakura.ad.jp/cloud/iaas/#!/pref/apikey/ より作成できます
token: [ACCESS TOKEN]
secret: [ACCESS TOKEN SECRET]

# リソースを作成するゾーンを指定してください
# tk1a(東京第1), is1a(石狩第1), is1b(石狩第2), tk1v(Sandbox)
zone: [ZONE ID]

# 作成したサーバ,スイッチ,ロードバランサのリソースIDを指定してください
base_server_id: [ウェブサーバのリソースID]
swytch_id: [ルータ＋スイッチのリソースID]
lb_id: [ロードバランサのリソースID]

 

4. ウェブサーバを追加(スケールアウト)してみる

これまでの作業で冒頭の図の通りの最小構成の準備が整いましたので
AutoScalingデモプログラムを起動します。

# cd /usr/local/src/saklient-autoscaling-demo/
# bundle ex ./bin/demo
searching servers
searching base server
searching source disk
searching swytch
searching loadbalancer
[monitor][YYYY-MM-DD XX:XX:XX] ***** start *****
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => []

実際にオートスケールする様子を確認するには、サーバに負荷をかける必要があります。
本プログラムではCPU-TIMEを監視しているため、CPUに負荷をかける例を紹介します。
ウェブサーバにログインした上で以下のコマンドを実行します。

# openssl speed

デモプログラムは5分間隔でCPU-TIMEを監視し、スケールアウト・スケールインを行います。
下記はCPU-TIME上昇を検知しオートスケールアウトが行われた場合の表示例です。

# bundle ex ./bin/demo
searching servers
searching base server
searching source disk
searching swytch
searching loadbalancer
[monitor][YYYY-MM-DD XX:XX:XX] ***** start *****
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.036666666667]
[monitor][YYYY-MM-DD XX:XX:XX] sum_time => 0.036666666667
[monitor][YYYY-MM-DD XX:XX:XX] ave_time => 0.036666666667
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.036666666667]
[monitor][YYYY-MM-DD XX:XX:XX] sum_time => 0.036666666667
[monitor][YYYY-MM-DD XX:XX:XX] ave_time => 0.036666666667
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.66]
[monitor][YYYY-MM-DD XX:XX:XX] sum_time => 0.66
[monitor][YYYY-MM-DD XX:XX:XX] ave_time => 0.66
[monitor][YYYY-MM-DD XX:XX:XX] <>
add a server to loadbalancer
[monitor][YYYY-MM-DD XX:XX:XX] <>
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.58333333333]
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.036666666667]

 

スケールアウト前の構成

mod-WS000295

 

スケールアウト後の構成

mod-WS000296
監視対象のウェブサーバの負荷が下がると、スケールアウトしたサーバを自動的に削除します(オートスケールイン)。

[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.043333333333, 0.046666666667]
[monitor][YYYY-MM-DD XX:XX:XX] sum_time => 0.09
[monitor][YYYY-MM-DD XX:XX:XX] ave_time => 0.045
[monitor][YYYY-MM-DD XX:XX:XX] >> scale in start <> scale in end <<
スケールイン後の構成

mod-WS000295
いかがでしたでしょうか。APIを活用いただくことでこのような作業も自動化することができますので、是非この機会に試していただければと思います。