今回は、Members Meetingで実施したデモについて改めてご紹介させていただきます。

内容としては、ユーザトラフィックによる負荷に応じて、クラウドインフラがサーバリソースを動的に増設・縮小するデモでした。






参加して実際にデモをご覧になった方には、一見簡単な動作に見えたかもしれませんが、ハイレベルで考えてみてください。必要なときのみに「クラウド」の余裕からリソースを確保。不要になったときにリソースをクラウドに解放。これがまさにクラウドな動きですね!(勝手にクラウドを形容詞として使うのがいけないよね?笑)

この動作を実現するにはF5とVMwareが提供するキーテクノロジーを利用しました。外部からVMwareのvCenterもBIG-IPも操作できるSOAP API(BIG-IPの場合これはご存じ「iControl」と呼んでいるものです)。実は、去年リリースしたホワイトペーパでBIG-IPとの連携を初めて説明しているんですよ:

http://www.f5networks.co.jp/shared/pdf/WP_VMwareVI3.pdf

ここで突然ですがアンケートです。このホワイトペーパが掲載されていたことを知っていて、読んだことがある方いらっしゃいますか?
実は読んだことがある人数が非常に少ないと思って、最も良い紹介方法としてMembers Meetingで今回デモを実施することにしたという経緯があります。

さて、Members Meetingでデモを見た、もしくはホワイトペーパを読んだところで疑問が残っているかもしれません。BIG-IPでは、モニター機能でサーバの死活監視ができるので、仮想マシンの起動が自動的に検知できるはず。そもそもなぜiControlを使う必要があるの??

私の答えはこうです。確かに、上記のような自動検知が可能です。しかし、モニターを動作させるために、少ないと言えますが、確実にBIG-IPのCPUリソースを消費します。小規模のアプリケーションならば、消費されたリソースが問題になる程度ではないと思います。一方、今回のようにVMwareとの連携ではクラウドインフラのFront EndとしてBIG-IPを採用していると想定しています。クラウドだったら、数百、数千台の仮想サーバを簡単に作成できるし、余分のリソースとしてシャットダウンしておくものを含むと何万台の仮想マシンが存在する可能性があります。BIG-IPのモニター機能だけに頼ったら、起動していないものも含めて、すべての仮想マシンに対してモニターを実行しなければなりません。仮想マシンが多くなってきたら、モニターの動作がBIG-IPの本来の仕事(ユーザトラフィックの処理)に必要なリソースへインパクトが出てしまします。

----------------------------------

ではでは、デモの動作を見てみましょう。

まず、クラウドで運用したアプリケーションは、SugarCRMのWebサーバとMySQLのDBサーバの2層構造のアプリケーションでした。SugarCRMはモダンなWebアプリケーションであり、画面を生成するためにスクリプト(Sugarの場合はPHP)を使います。従来の「Webサーバ」では、ApacheなどのWebプロセスが多くのCPUリソースを消費しますが、Sugar等のアプリケーションではPHPやMySQLへの接続のためのリソースも確保する必要があります。

そのため、スループットが低くてコネクション数が少ない場合でも、CPU使用率が上がります。つまりアプリケーションサイジングはスループットやコネクション数よりも、CPUが処理できる毎秒リクエスト数の方が重要。これはSIが良くご存じだと思いますが、これからアーキテクトを目指している方々ご注意ください。パフォーマンスボトルネックがネットワークではないところがありますからネ!

それでは、vCenterとBIG-IPの動作を見てみましょう。仮想マシンのCPU使用率を監視し、高くなった場合に何かのアクションを実行するメカニズムをvSphereが提供しています。これは「アラーム」という機能ですが、今回のデモでは仮想マシンのCPU資料率が20%を超えた際にトリガーされるアラームを作成しました。



次はアラームがトリガーされた時の動作の定義です。管理者へのメールなど、様々なアクションが定義可能ですが、今回はSOAP APIを通して細かく指定したいため、外部スクリプトを実行するアクションを定義しました。外部スクリプトとしてSOAPコマンドを簡単に生成できるためPerlを採用しました。

スクリプトのロジックは次の通りです。

1) CLIでvCenterおよびBIG-IPと接続するための引数を指定。vCenterとBIG-IPのユーザ名・パスワード、VMのリソースプール名、BIG-IPのサーバプール名、その他
2) リソースプールのCPU使用率が管理者の設定した最大値に至っていれば、仮想マシンを追加しなくて良いので、現在使用中のリソースを確認(今回は最大値を設定していないため、デモの動作には関係ありません)
3) vCenterに問い合わせ、起動していない仮想マシン名のリストを取得
4) リストの頭に載っている仮想マシンを起動し、しばらくしてから仮想マシンのIPアドレスを問い合わせ。IPアドレスの問い合わせに対して正常な返答があれば、仮想マシンのVMToolsデーモンが動作していると判断できます。従って仮想マシンの起動も正常であることも判断します
5) 仮想マシンが正常に起動された後、BIG-IPに接続し、実サーバのプールのメンバーとして追加
6) 追加したメンバーのステートをACTIVEに変更

以上が仮想マシンの追加スクリプトのロジックです。

では、負荷が無くなり、仮想マシンを自動シャットダウンする際の動作は?

ブログ投稿がもう長文になっていますので、解析を宿題にする、ということで、是非サンプルをダウンロードしてみてください。恥ずかしながらシャットダウンスクリプトのロジックにGOTO構造などの、プロフェッショナルなプログラマーが使わないようなものも入っているので、あまり厳しい目で見ないでください!(涙)

ということで、最後になりますが、今回のデモで利用したスクリプトはあくまでもサンプルです。実際にサービスで運用する場合は、ブラッシュアップすべきところがたくさんあると思います。たとえば...

・複数スクリプトの同時実行を意識したロジック(ロックの利用等 → シャットダウンスクリプトには既に入っています)
・Flapping(仮想マシンの起動と、すぐにシャットダウン)現象を抑えるために、起動する前にCPU使用率が本当に20%を超え続けているかを確認するタイマーや、起動したものをある一定時間シャットダウンしないタイマー


ではでは、今回はここまで。次回は第3回Members Meetingについての最後の投稿として、プレゼンについて少し紹介します。