こんにちは、ニフティのいちかくと申します。
今回、ライターの中でも唯一ニフティクラウドの中の人ということで、新機能の紹介や既存機能の使い方を中心にちょっとした裏話等も交えながらご紹介していければと思っています。
よろしくお願いいたします。
ということで、初回はニフティクラウドのオートスケール機能のご紹介です。
はじめに
ニフティクラウドには、サーバーの負荷に応じて自動的にサーバーのスケールアウト、縮退を行う「オートスケール」という機能があります。
今回は、このオートスケールについて、設定から実際の動きを中心に、裏側の話も交えながらご紹介したいと思います。
クラウドならではの機能ですので、なかなか試しづらい、取っつきにくいというところがあるかと思いますので、この記事でイメージを掴んでいただき設定の際の参考になればと思います。
オートスケールとは？
サーバーの負荷が高くなったらサーバーを増やして負荷分散、逆に負荷が低くなったらサーバーを外してリソースを平準化。
このようなスケールアウト、縮退は通常人力でやるものですが、これを自動でやってくれるのがオートスケールになります。
うまく使う事ができればリソースコントロールを自動化して、運用負荷を下げることが可能です。
オートスケールは使い方にもよりますが、以下のようなメリット・デメリットがあります。
メリット
・自動でスケールアウト・縮退→リソース管理から開放
・負荷曲線とコスト曲線が一致→インフラコストが変動費に
・サーバーが廃却できる、しかも自動で
デメリット
・自動で増えたり減ったりするので、それに合わせたシステムの構築が必要
・前準備がそれなりに手間がかかる、閾値等の設定をミスるとちゃんと増えてくれなかったりします・・・
→ただ、手間をかけてやるだけのリターンは得られると思います
・想定外のアクセス、サーバーが増えすぎちゃって料金が大変なことに・・・
→一応サーバー数上限のリミットはかけられます。
オートスケールを設定してみる（前提知識と構成）
ではさっそく設定を・・・、といきたいところですが、具体的な手順に入る前にまず前提知識と今回設定する構成についてです。
前提知識
このエントリーでは、ニフティクラウド上で以下の操作ができることを前提としています。
・コントロールパネルの基本的な操作
・コントロールパネルからのサーバー作成・設定、ロードバランサー作成・設定
・サーバーへのログイン、ＯＳの設定
構成
今回は以下の構成でオートスケールを設定してみます。
・CentOS 5.3 64bit Server モデルを使用します。
・Apache を使用し、簡単な Web サーバーをロードバランサーにぶら下げ、スケールアウトさせてみます。
オートスケールを設定してみる（前準備）
では、さっそくオートスケールを設定していきます。
スケールアウトの元になる種イメージの作成、スケールアウトしたサーバーをぶら下げるロードバランサーの設定など、まずは前準備からになります。
スケールアウト元イメージの作成
スケールアウトする際の元となる種イメージを作成します。
スケールアウト時はここで作成したイメージをコピー、電源ON、ロードバランサー組み込みまでを自動で行います。
１．サーバーの作成
コントロールパネルからサーバーの作成を行います。
詳細は割愛しますが、今回は以下の内容で作成を行います。
・OS イメージ
CentOS 5.3 64bit Server モデルを選択します。
・タイプ・料金選択
種イメージ作成用ですのでMini/従量を選択、種イメージができた後は電源を落として費用を抑えましょう。
※スケールアウトするサーバーのタイプはオートスケールの方で設定します。
ここはあくまで種イメージを作るためのサーバータイプ、料金の選択になります。
２．サーバーの設定
サーバーが上がってきたら、サーバーにログインして設定を行っていきます。
※この設定を忘れると正常にスケールアウトしてくれませんので必ず設定しましょう。
・net-snmp のインストール
サーバーの負荷状態監視は SNMP を使用して行いますので、net-snmp をインストールします。
# yum -y install net-snmp
# chkconfig snmpd on
・snmpd.conf の設定
/etc/snmp/snmpd.conf をエディタで開き、以下を一番最後の行に追記します。
rocommunity niftycloud 10.100.0.14 .1.3.6.1.
rocommunity niftycloud 10.100.8.15 .1.3.6.1.
rocommunity niftycloud 10.100.16.13 .1.3.6.1.
disk / 10000
・iptables の設定
監視サーバーからの SNMP(161/udp) と、インターネットからの Apache(80/tcp) を許可します。
/etc/sysconfig/iptables をエディタで開き、以下の行を追記します。
-A RH-Firewall-1-INPUT -s 10.100.0.14 -i eth1 -p udp -m udp --dport 161 -j ACCEPT
-A RH-Firewall-1-INPUT -s 10.100.8.15 -i eth1 -p udp -m udp --dport 161 -j ACCEPT
-A RH-Firewall-1-INPUT -s 10.100.16.13 -i eth1 -p udp -m udp --dport 161 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
※-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited より上に追記します。
※iptables の設定を誤ると、サーバーにログインできなくなる可能性がありますので十分ご注意ください。
・snmpd、iptables の再起動
最後に、snmpd と iptables を再起動し、設定内容を反映させます。
# service snmpd restart
# service iptables restart
以上で、オートスケールに必要なサーバーの設定は完了です。
以下のページにも設定方法と実際に監視対象となる OID や、Windows Server の設定方法が細かく記載されていますので参考にしてください。
http://cloud.nifty.com/snmp/
３．アプリケーションのインストール
今回は、Apache を立ち上げて簡単な Web サーバーとして動作させてみます。
CentOS 5.3 64bit Server モデルを選択しているのでデフォルトでインストールされています。
・Apache がインストールされているかどうかの確認方法
# yum list httpd
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.averse.net
* updates: mirror.averse.net
* addons: mirror.averse.net
* extras: mirror.averse.net
Excluding Packages in global exclude list
Finished
Installed Packages
httpd.x86_64 2.2.3-22.el5.centos installed
インストールされていない場合は、以下のようにインストールを行います。
・Apache のインストール
# yum -y install httpd
・Apache の起動設定
サーバー起動時に Apache が起動するように設定します。
# chkconfig httpd on
・Apache の起動
# service httpd restart
・Web ページの配置
適宜、Web ページを配置しましょう。
今回は、Apache のマニュアルに対して負荷がけをしてみますので、このままページは配置せずに進みます。
Web ブラウザから http://サーバーのグローバルIPアドレス/manual/ にアクセスして、以下のようなマニュアル画面が閲覧できることを確認します。
４．イメージの最終確認
オートスケール用の設定、アプリケーションの設定が完了しました。
あとはイメージ化を行うだけですが、設定が誤っていた場合、設定しなおして再度イメージ化（525かかります・・・）が必要になりますので、念には念を入れて設定が誤っていないか確認しましょう。
サーバーを再起動して、以下の点を確認しましょう。
・snmpd が起動していること
可能であれば、もう一台別のサーバーから SNMP のアクセスを許可し、以下 snmpwalk コマンドで応答が返って来ることを確認できると完璧です。
# snmpwalk -v 2c -c niftycloud サーバーのプライベートIPアドレス .1.3.6.1
・iptables の設定が誤っていないこと
・Apache が起動していること、Web ページがインターネットから閲覧できること
以上が確認できれば問題は無いはずです。
５．イメージ化
サーバーを停止して、イメージ化を実施します。
・サーバーの停止
・イメージ化
サーバーの停止が確認できたら、サーバーをチェックして「イメージ化」を実行します。
・イメージ化の実行
イメージ名を入力、サーバーを残すにチェックを入れてOKボタンをクリックします。
「イメージ化元のサーバーを残す」設定にしておいた方が、設定間違い、アプリケーションのアップデートの際にあとあと楽です。
「残さない」にした場合イメージ化は瞬時に終わりますが、設定間違い、アプリケーションのアップデートの際は、イメージから再度サーバーを作成する必要があります。
イメージ化にはディスクの使用容量にもよりますが数十分かかります。気長に待ちましょう。
イメージ化の進捗状況はOSイメージ→カスタマイズから確認できます。
ロードバランサーの作成
イメージ化をしている間にロードバランサーの作成をしてしまいましょう。
ロードバランサーの作成では特に注意する点はありません。
ここも詳細は割愛しますが、今回は Apache (80/tcp) を使用しますので、待ち受け(80/tcp)→宛先(80/tcp) で作成します。
サーバーはぶら下げる必要はありません。
オートスケールを設定してみる（本設定）
ここからいよいよオートスケールの作成に入ります。
コントロールパネルのオートスケールメニューからオートスケール作成ボタンをクリックします。
すべて後から変更できますので、分からない項目はそのままでもかまいません。
基本設定
オートスケール名とロードバランサーだけ最低限設定しておきましょう。
・サーバーの最小台数、最大台数
サーバーが増えすぎても、減りすぎても困ると思いますので、ここでリミットを設定できます。
・ロードバランサー
前準備で作ったロードバランサーを選択しましょう。
スケールアウトしたサーバーはここで選択したロードバランサーに自動で組み込まれます。
・スケールアウト開始間隔、縮退開始間隔
トリガーが発動してからすぐにスケールアウトしたい場合は 0 を、しばらく様子見したい場合は 10 以上を選択します。
サーバー設定
前準備で作った種イメージと、スケールアウトしたサーバーのタイプを選択します。
・イメージの選択
前準備で作成した種イメージを選択します。
・有効時間
スケールアウトしたサーバーは、ここで設定された時間が経過すると削除されます。
今回はデフォルトのままで進みます。有効時間が必要な理由は後ほど・・・。
ちなみに、有効時間切れでサーバーが削除されて 0 台になってしまう場合は、1 台スケールアウトしてから削除処理が走ります。・サーバータイプ
スケールアウトするサーバーのサーバータイプを選択します。
料金は選択したタイプの従量料金になります。
トリガー設定
監視項目、閾値、長さを選択、「追加」ボタンをクリックしてトリガーを設定します。
選択できる監視項目は以下の通りです。
・サーバーのＣＰＵ使用率
・サーバーのメモリ使用率
・サーバーのネットワーク流量
・ロードバランサーのネットワーク流量
それぞれの閾値と長さを指定して、５条件まで設定できます。
監視対象はスケールアウトしているサーバー全体の平均値になりますので、スケールアウトすると使用率は下がっていきます。
今回はスケールアウトの実験をしたいので CPU 使用率 1% 以上でスケールアウトするようにしてみます。
スケジュール設定
スケールアウトが発動する期間を限定することができます。
例えば、夜間だけ、週末だけ、月初だけといったような設定が可能です。
今回はこのまま何も設定せずにすすみたいと思います。
設定する場合は、「追加」ボタンをクリックします。
crontab と同じ要領で日時を指定できます。
↓の例では 20:00 ～ 2:00 の間のみスケールアウトするような設定になります。
確認
「作成する」ボタンをクリックすると設定は完了です。
しばらくすると基本設定の「最小台数」で設定した台数分のサーバーが上がってきます。
オートスケールの動き
設定直後
設定してしばらくすると、最小台数分のサーバーが作成されます。
作成されたサーバーは、オートスケール一覧のサーバータブから確認できます。
今回は最小台数１台設定なので、１台だけ作成されているのが確認できます。
作成されたら、サーバーにログインして種イメージ作成時と同じ状態であること、ロードバランサーの VIP からページが閲覧できることを確認しましょう。
スケールアウト
それでは実際に負荷をかけて、スケールアウトするかどうか試して見ましょう。
今回は ab を使用して、ページに大量アクセスをしてＣＰＵ負荷を上げてみます。
# ab -n 1000000 -c 100 http://ロードバランサーのIPアドレス/manual/
・サーバーの top の状況
Tasks: 151 total, 3 running, 148 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 0.7%sy, 0.0%ni, 93.3%id, 0.7%wa, 1.3%hi, 2.7%si, 0.0%st
Mem: 510732k total, 215520k used, 295212k free, 12120k buffers
Swap: 2152700k total, 0k used, 2152700k free, 64196k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3739 apache 15 0 230m 7160 1408 S 0.3 1.4 0:00.03 httpd
3788 apache 15 0 230m 7160 1408 S 0.3 1.4 0:00.04 httpd
3790 apache 15 0 230m 7160 1408 S 0.3 1.4 0:00.05 httpd
3797 apache 15 0 230m 7160 1408 S 0.3 1.4 0:00.04 httpd
3815 apache 15 0 230m 7160 1408 S 0.3 1.4 0:00.05 httpd
この状態でしばらく待つと、スケールアウトが実行されます。
スケールアウトの様子はオートスケール一覧のサーバータブから確認できます。
↑一台増えているのが確認できます。
また、ログタブでもアラーム、スケールアウトの開始・完了を確認することができます。
↑アラームの発生とスケールアウト開始・完了が確認できます。アラームとスケールアウト開始が同時なので、順番が逆になっちゃってますが・・・（汗）
スケールアウトした状態で、ページが閲覧できることを確認しましょう。
縮退
スケールアウトは確認できましたので、ab を停止し、縮退されるかどうか試してみましょう。
・サーバーの top の状況
top - 15:49:18 up 1:09, 1 user, load average: 0.01, 0.02, 0.00
Tasks: 70 total, 3 running, 67 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 510732k total, 162620k used, 348112k free, 15980k buffers
Swap: 2152700k total, 0k used, 2152700k free, 81112k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
11 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
15 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
16 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
この状態でしばらく待つと、縮退が実行されます。
縮退の様子は、スケールアウトと同様オートスケール一覧のサーバータブから確認できます。
↑一台になっているのが確認できます。
スケールアウトと同様にログタブでもアラームの解消、縮退の開始・完了を確認することができます。
↑今回のケースでは、一度３台までスケールしたあと１台まで縮退しています。
スケールアウトと同様、縮退した状態でも、ページが閲覧できることを確認しましょう。
ちなみに、縮退する際は shutdown 処理が実行されますので、終了処理が必要なアプリケーションは shutdown スクリプトで実装しておくことをおすすめします。
ちょっと裏側の話
サーバーが増える仕組み
トリガー発動してから、サーバーが増えるときの裏側の動きは
１．サーバーをコピー
２．電源ＯＮ～サーバーが上がるまで待機
３．ロードバランサーに組み込み
という動きになっています。
オートスケールはトリガーが発動してから組み込むまでのスピードが重要です。
全体としては５分程度で完了する処理ですが、この中で最も時間がかかっている処理はどれだと思いますか？
１のサーバーコピーを予想される方が多いかと思いますが、実際には２が一番時間を要しています。
電源ＯＮしてからサーバー、アプリケーションが上がってくるまで、だいたい３、４分程度でしょうか、１のサーバーコピーは数秒で完了します。
通常のサーバーコピーは、イメージの大きさにもよりますが数十分程度はかかります。
これでは負荷の変化には到底追いつけません。
オートスケールのコピーは特殊なコピーを使用しており数秒で完了します。
技術要素は諸事情により詳しくは書けませんが、コピーオンライトと同じ考え方になります。
じゃあ、なんで通常のサーバーコピーもそれを使わないの？という声が聞こえてきそうですが、やはりトレードオフとなるデメリットが存在します。
なんで有効時間があるのか？
上記で触れたデメリットが、この有効時間に関わっています。
オートスケールでコピーしたサーバーは、様々な制約（すみません、これも諸事情により詳しくは書けません・・・）があるため、永続的に使用するのには適していません。
このため、有効時間を設けて、一定時間が経過するとサーバーが自動的に消える仕組みになっています。
通常のサーバーコピーにこの特殊なコピーを使わないのも上記の制約があるためです。
なんでＳＮＭＰなのか？
VMware なんだから、パフォーマンスデータはわざわざ SNMP なんかにしなくても外から取れるでしょ・・・。
そう、そうなんです。取れるんです。
できれば SNMP の設定といった煩わしさを無くして、こっちで行きたいんです・・・。
が、実は VMware から取得できるパフォーマンスデータと、ゲストＯＳ内部のＣＰＵ、メモリ使用率といったデータは合致しません。
VMware から取得できるパフォーマンスデータは、ホストから割り当てたリソースの情報であって、ゲストＯＳから見た場合の使用率は、必ずしもホストから割り当てられたものとイコールとは限らないのです。
値の正確性と、設定の煩雑さとどっちを取るかというところでかなり迷いましたが、やはりスケールするためのトリガー・閾値である以上正確性を確保すべきと考えこちらを取りました。
その分、設定の煩雑さといったところが犠牲になっています。
まとめ
以上、オートスケールの設定から実際の動きまでを紹介してみましたが、いかがでしたでしょうか。
アプリケーション、システムの整合性を取るためにはオートスケール前提の設計、実装が必要になってくるのがハードルが高いところでしょうか。
使い方によっては、リソース管理の負担を大幅に減らしてくれるクラウドならではの機能となっていますので、ぜひ試してみていただければと思います。
