さくらのクラウドでAuto Scaling

重要

saklient は廃止となりました。
本記事で紹介している「AutoScaling」の代替となる、さくらのクラウドの「オートスケール」につきましては以下のマニュアルをご確認ください。

オートスケール

目次

[更新: 2022年06月24日]

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

※デモプログラムはgithub上で公開しております。詳細は以下URLをご参照ください。

https://github.com/sakura-internet/saklient-autoscaling-demo

※デモプログラムの実行により、課金対象のリソースが作成されます。予期しない台数のサーバが作成され想定外の課金が発生した等の場合でも、弊社ではご対応いたしかねます。その点をご留意の上、実行していただくようにお願いいたします。

1. 今回の構成

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

auto-scaling-01.png

「ルータ＋スイッチ」を作成し、その配下に1台のロードバランサと1台のウェブサーバが接続されています。

※「ルータ＋スイッチ」の作成やネットワーク構成の操作方法については、公式マニュアルやさくらのナレッジ「 ルータ＋スイッチを使ったネットワークを構築してみよう 」が参考になります。

アクセスが閑散としている場合はこの構成で運用しますが、アクセスの増大により1台のウェブサーバでは捌ききれなくなった場合は平行してウェブサーバを追加し、ロードバランサによる負荷分散を図ります。
auto-scaling-02.png

このように、同一の性能を持つ機器を追加して負荷を分散させることを「スケールアウト」と呼びます。また、負荷が減少した際にスケールアウトしたサーバを削除することを「スケールイン」と呼びます。さくらのクラウドでは仮想的にスイッチやサーバを組み合わせてネットワークを作成することができるので、スケールアウトさせる場合も素早く構成が可能であり、物理環境のようにあらかじめ機材を用意する必要もありません。また、クラウドではサーバの時間課金に対応していますので、必要なときに必要な数だけスケールアウトさせ、負荷が減少した際にスケールインさせることで、コストの適正化を図ることができます。スケールアウト・スケールインによる伸縮自在なシステム構成は、クラウドのメリットをより活用することができる手法と言えます。

また、さくらのクラウドでは、これまで「スケールアウト」「スケールイン」ともにコントロールパネルから操作する必要がありましたが、今回ご紹介するクライアントライブラリ「Saklient」を活用したオートスケーリングツールを利用することで、一連の作業を完全自動化させることができます。

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

最初にロードバランサの設定を行います。作成したロードバランサは、左側のメニューから「ロードバランサ」を選択します。ここで作成済みのロードバランサの一覧が表示されるので、該当のロードバランサ行をダブルクリックします。

auto-scaling-03.png

ロードバランサの情報画面が表示されるので、上部の「VIP設定」タブをクリックします。VIPは外部からの接続を受け持つ仮想IPアドレス(Virtual IP address)のことで、このIPアドレスへの接続がロードバランサにより配下の複数のサーバに分散されます。

状態では何も設定されていないので、右下の「追加」ボタンをクリックし、VIPの追加作業を始めます。

auto-scaling-04.png

設定ダイアログボックスが表示されるので、ここでVIPを設定します。今回の構成例では以下の値を入力しました。

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

設定が完了すると、VIP設定のリストに今回設定したVIP設定が追加されます。続いて、VIPに着信した接続の振り分け先となる実サーバを設定します。VIPごとにタブが追加されるので、今回設定したVIPのタブをクリックします。

auto-scaling-05.png

この画面では設定済みの実サーバのリストが表示されますが、こちらも初期状態ではひとつも設定されていないので「追加」ボタンをクリックして追加を行います。

auto-scaling-06.png

設定ダイアログボックスが表示されるので、ここで実サーバの情報を設定します。今回の構成例では以下の値を入力しました。

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

設定が完了すると、VIP設定のリストに今回設定したVIP設定が追加されます。

auto-scaling-07.png

なお、ロードバランサはコントロールパネルでの一連の設定後に実際のロードバランサに設定を投入する仕組みとなっているので、「反映」ボタンをクリックして設定内容を反映させます(まだ起動していない場合は電源操作メニューより「起動」を選択してください)。

設定完了後、仮想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″コマンドで設定を反映します。

その他の設定

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

4. AutoScaling用監視サーバの準備

ウェブサーバをモニタリングして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/#!/apikey/top/ より作成できます
  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] << scale out start >>
add a server to loadbalancer
[monitor][YYYY-MM-DD XX:XX:XX] << scale out end >>
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.58333333333]
[monitor][YYYY-MM-DD XX:XX:XX] cpu_times => [0.036666666667]

スケールアウト前の構成

auto-scaling-08.png

スケールアウト後の構成

auto-scaling-09.png

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

[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 << removing a server removing a lb_server [monitor][YYYY-MM-DD XX:XX:XX] >> scale in end <<

スケールイン後の構成

auto-scaling-10.png

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