今回から2回に分けてWakameの基本的な使い方を説明します。前提の知識としては、Amazon Web Servicesのアカウント(AWSアカウント)をお持ちでAWS Management Console等を使い、仮想マシンの起動を行ったことがある方を対象としています。
Amazon EC2へのアクセスやAWSアカウントの準備については、過去の特集「はじめてのAmazon EC2&S3 ~これからの新サービスの公開の形~」を参考になさるか、以下のオンラインの記事を参考にしてください。
システムをスケールアウトさせるための考え方
まず、Amazon Auto Scalingがそうであるように、WakameもAMI(Amazon Machine Image)の単位でインスタンスを起動することになります。
システムを起動するために必要な全てのサービスを1つのAMIに詰め込み、そこにWakameのMasterとAgentをインストールしておきます。
単一AMIを複数起動し、設定を調整することでスケールアウトするようにしておく
Amazon EC2上でスケールアウトさせるための原則として以下の通りに運用することとしています。
- インスタンスを起動する際には、同じ1つのAMIを元にする
- Wakameは、そのインスタンス上に必要なサービスを起動する・しないを制御する
- Wakameは、必要であればそのサービスの設定を書き換える
そのため、AMIにインストールされたサービスは、基本的にWakameや最低限必要なサービス以外は、OSの準備完了と同時に自動起動しないようにinit.dの設定をオフにしておきます。
代わりに、Wakameはスタートアップスクリプトを自ら制御しに行きます。
人手でやるのであれば、/etc/init.d以下のスタートアップスクリプトを順序良く実行していくことになります。
必要なときに自らインスタンスを起動することでスケールアウトする
Wakameのマスターが必要なタイミングでAmazon Web Servicesへ通信し、自分と同じAMIを自ら指定してインスタンスを起動します。
MasterからAmazon EC2のインスタンスを起動する際には、User Dataという領域を使って、インスタンスに初期値を与えることができます。
これによって、Agentが既に起動しているMasterと連携するために必要な情報を与えることができるのと同時に、Masterが複数起動してくることを防ぎます。
上図のところまで起動すると、あとはMasterからAgentに通信して、新たなインスタンス上に何を起動すべきかを指示できるようになります。
Webサーバの追加を手動で実現するための例
これらをWakameを使わずに、Webサーバの追加を手動で実行してみましょう。
最初のインスタンスはElasticFoxや、AWS Management Consoleを利用して最初のインスタンスを起動した状態から始めます。
Masterが起動するサーバ上から指示することを前提として記述するため、部分的にリモートで指示する手順もあります。
この程度の手動手順である場合は、実際にシステム管理者がそのサーバにログインして実行する方が効率的ですが、今回はWakameによる構成管理の視点でとらえていただければ幸いです。
コマンドラインからインスタンスを起動する
AMIを指定し、新しいインスタンスを起動します。
新しいインスタンスの起動に成功したかを確認し、引き続きSSH接続ができるかも調べる必要があります。
新しいインスタンスを起動すると、インスタンスID(i-xxxxxxxx)が返ってくるので、これを指定してインスタンスの状態をチェックします。
インスタンスが起動すると以下のように、ステータスがrunningになるほか、アクセスするためのIPアドレスも取得できます。
さっそくSSHを試して接続できるかを確認してみてください。
接続ができない場合は、インスタンスの起動が完了していてもネットワーク系のサービスまで立ち上がっていないことを示しています。
Webサーバを起動する
SSHコマンドを利用し、リモートコマンド実行をします。
SSHコマンドはあらかじめ秘密鍵認証を設定しておき、インタラクティブなパスワード問い合わせを無くしておく必要があります。
ここでも、正しくWebサーバが起動したかを確認する必要がありますので、pidの有無をもってプロセスの起動ができたことを確認します(本来であれば、サービスが開始していることを確認するのが良いでしょう)。
以下のように、起動したサービスのPIDが存在するかを確認します。
ロードバランサーの設定を変更する
Webサーバの起動までは確認できたところで、ロードバランサー(apacheのmod_proxy_balancerで代用します)にこの新しいWebサーバを利用するように設定しましょう。
新しい設定ファイル(new_httpd.conf)に書き換えて、ロードバランサーを再起動することにします。
設定する前に、新しいインスタンスのIPアドレスを取得します。
そのIPアドレスをもとに、mod_proxy_balancerの設定ファイルを用意します。
設定ファイルを転送します。
転送が完了したら、ロードバランサーを再起動します。
Wakameがあればここまでの手順を管理できる
Wakameはこれらの手順を各サーバ上で適宜実行するための仕組みを持っています。
今回は、Wakameのデモ用にAMIを用意しましたので、これで一連の操作方法を見ていくことにします。
Wakameのデモ環境準備と設定
デモ環境では、以下のサービス群を立ち上げ、最終的にRailsのトップページが確認できるところまでが機能として含まれています。
まず、デモ用AMIを用いてインスタンスの起動を行います。AWS Management ConsoleのAMIメニューから、ami-c25eb9abのデモ用AMIを選び、Launchをクリックします。検索テキストフォームへ"wakame"とタイプすると簡単に目的のAMIを見つけ出せます。
Instancesメニューへ移動すると、先ほどLaunchした仮想マシンの状態を確認できます。アイコンが緑色になると仮想マシンの起動が始まり、しばらくするとSSH接続が可能になります。
起動したインスタンスの行をクリックすると、画面の下半分へ起動した仮想マシンの詳細情報が表示されます。"Public DNS"の部分に表示されているホスト名をコピーし、ターミナル上へペーストします。
ubuntuユーザとしてSSH接続を行い、root権限を取得します。
ここから、デモ環境の設定変更へ進みます。以下の作業を行います。
- WakameがAWSへ問い合わせする際に使う、Access Key ID、Secret Access Keyの設定
- Elastic IPの取得
- MySQL用EBSボリュームの準備
Access Key ID と Secret Access Keyについては、Amazon Web ServicesのAccess Identifiersのページから確認できます。
/home/wakame/corelib/wakame/lib/configuration.rb にAmazon Access KeyとSecret Keyを書き込む箇所がありますので、そこへ書き込みます。
Elastic IPをAWS Management Consoleから取得し、/home/wakame/corelib/wakame/lib/service.rb の下記の行へ書き込みます。
MySQL用EBSボリュームを確保します。ec2-api-toolsを使っても同等なことができますが、必要な手順を自動化したrakeタスクも用意してあります。
最後に出てくるvol-xxxxxxxx の文字列を/home/wakame/corelib/wakame/lib/service.rbファイルの@ebs_volumeへ割り当てます。
これで、Wakameのデモ用の設定が完了しました。MasterとAgentのプロセスを再起動し、設定内容を反映させます。
Clusterの起動
以下のコマンドで、現在のClusterの状態を表示させることができます。
Clusterの項目には、Masterが認識しているサービスの一覧が表示されています。以下の図にあるように、依存関係を含めたサービスの一覧図を内部的にも持っています。キャラクタベースのインタフェースでは表示することが難しいため、リスト状に表示しています。
また、下部にはAgentsという項目があり、現在Masterが把握しているAgentの情報が表示されます。
現在のバージョンでは、wakameadm status コマンドがMasterの内部を把握する唯一の方法なので、操作のたびにstatusコマンドで状態の変化をみることになります。
以下のコマンドで、サービス全体の起動を行うことができます。
このコマンドは、サービスの一覧図通りに下段からサービスを順番に立ち上げ、ロードバランサが立ち上がるまでの調整を行います。launch_clusterコマンドを走らせた後、すぐにstatusコマンドを走らせ状態の変化を見てみます。
各サービスの起動がスケジュールされると、それぞれにユニークなIDが割り振られます。また、サービスの起動状態も把握していますので、右側に状態が表示されています。起動が完了するとONLINEと表示され、起動待ちの物はOfflineとなっているのがstatusコマンドから分かります。
上段に位置するサービス(Apache_APPとApache_LB)は立ち上げに入っておらず、下段のサービスの立ち上げが完了するのを待っています。MySQL_Master は、"Starting..."という表示が示すとおり、起動している最中です。図で表すと、以下のような状態です。Agentが立ち上がったと判断すると、Masterへサービスが立ち上がったという知らせが行き、次の立ち上げ手順へ移ります。
これら一連の手順を繰り返すと、全体の起動が完了し表示が以下のように変わります。
ここまでで、全てのサービスが一つのインスタンスで起動され、次の図のような状態になります。
では、今度はブラウザからHTTPの疎通を確認してみます。http://aaa.test/ というVirtual Hostがapache.confに書かれていますので、aaa.testがElastic IPを指すようにhostsファイルを書き換えてください(Windowsから確認する場合は、"C:\WINDOWS\system32\drivers\etc\hosts"を書き換えます)。
hostsファイルに下記1行を追記してください。
http://aaa.test/ で、Railsのトップページが表示されます。
http://aaa.test/balancer-manager でApache2.2のproxy balancer モジュールの状態を確認するページを表示できます。上のページを数回リロードすると、リクエストがApache_WWWとApache_APPのサービスへ割り振られているのを確認できます。
次は、Apache_APPを別の仮想マシン上で起動させアプリケーションサーバがスケールする状態を試してみます。
サービスを増やす
サービスを増やすには、propagate_serviceコマンドを使います。
Apache_APPに二種類のインスタンスが現れました。ONLINEのApache_APPは従来の物ですが、OfflineのApache_APPはAgentの割り当てを待っている状態です。ここからは場合によって、仮想マシンの確保に数分待つ必要があります。WakameがEC2の仮想マシンのリクエストを行っており、その新しい仮想マシンの中で立ち上がったAgentとMasterの間で通信が確立されるまでは、statusコマンドの内容に変化がありません。
無事新しい仮想マシンが認識され、最終的にApache_APPが二つになった状態では、以下の表示内容になります。
wakameadmが返している状態は下図の通りです。
http://aaa.test/balancer-manager の変化も確認してみます。
増えたApache_APPサーバがバランス先の対象として認識されるよう、ロードバランサ側の設定ファイルが更新されていることを確認できます。Railsのトップページをリロードすることで、リクエストがきちんとバランスされていることも確認できます。
サービスを移動する
Wakameには、もう一つ大きなオペレーションがあります。サービスのサーバ間の移動です。
一つのイメージから起動する様にデザインされているため、始まりはいつも一つの仮想マシンにすべてのサービスが詰め込まれた状態になります。負荷を分散させるためには、サービスを実行する仮想マシンを増やすだけでは不十分で、詰め込まれたサービスを外出しし、最初の仮想マシンで稼働するサービスの数を減らすことも必要です。
そのための機能がサービスのサーバ間の移動機能で、migrate_serviceコマンドを走らせることで実行できます。引数にはpropagate_serviceコマンドとは異なり、サービスのインスタンスを特定するハッシュ文字列を渡す必要があります。
すると、稼働中のApache_WWWサービスが、Migrating... となり、新しく確保されたOfflineと表示されている新しいApache_WWWサービスへ切り替わろうとします。ここでもまた、仮想マシンの確保が発生するので、数分待つことになります。
完了すると、3台目の仮想マシンが立ち上がり、そこへApache_WWWが移動していることを確認できます。
ロードバランサの画面では、WWW向けのIPアドレスが変わっていることを確認できます。
サービスを終了する
最後に、サービス群全体を終了させてみましょう。
shutdown_clusterコマンドを実行することで、今まで起動・増殖させてきたサービス全体を停止させます。この場合も、各サービスの依存関係を参照しており、launch_clusterコマンドの場合とは逆に上段から順番にサービスを停止させていきます。
最後に、この回の最初のstatus表示になったらshutdown処理の完了です。
まとめ
今回は実際に動作するサーバ構成を元に、コマンドラインベースでWakameの主要な動作を説明しました。コマンドラインをきっかけにするのではなく、時間や負荷率の条件に応じてサービスを増やしたり移動させたりする動作を引き起こすことで、自動的なスケールアウトを実現することになります。
次回は、より複雑な例として、Wakameが本領を発揮するデータベース(MySQL)のスケールアウトについて解説します。