構成管理ミドルウェアはシステム管理者となる
複数サーバを管理するシステム管理の経験をお持ちの方は、
前回、
これまで比較的変化が少なかったサーバ構成に、
例えばAmazon EC2で自動化を行おうとした場合、
- 1.作業の同期化・
非同期化をコントロールしなければならない - 複数の仮想マシンに対する並列的な処理と、
手続きが重要な部分では直列的な処理ができること - Amazon EC2のWeb APIは受動的な呼び出ししかなく、
処理も非同期で行われるため、 適宜Web APIにアクセスして確認できること
- 複数の仮想マシンに対する並列的な処理と、
- 2.アプリケーションの設定値を動的に変更しなければならない
- 仮想マシンへのアクセスに必要な情報
(IPアドレス・ ホスト名など) が動的に決まるものに対応できること
- 仮想マシンへのアクセスに必要な情報
これらの点を考慮しつつとなれば、
Wakameは、
クラウド型ホスティング上での構成管理に求められるもの
Amazon EC2ではWeb APIへアクセスし、
この時、
ここで重要なのは、
処理の同期化・非同期化のコントロール
Amazon EC2のWeb APIには仮想マシンの状態を取得するものが用意されています。しかし現時点のWeb APIでは受動的な呼び出ししかサポートされておらず、
そのため、
実際には、
この例から分かるように、
並列処理による効率化と、直列処理による確実化
Amazon EC2上ではWeb APIの呼び出しだけで仮想マシンを数十台?数百台確保し、
複数台のマシンでサービスを実現する場合、
そして、
図1のような構成の場合、

Amazon EC2では、
サーバ群の起動・
設定の変更と反映
さて、
次は、
次のページでは、
Wakameのアーキテクチャ概要
Wakameは、
- 非同期型ワークフローのサポート
- 作業の並列化
本節ではそうした機能を踏まえ、
Master-Agent構成を取る
Wakameは、
実際の通信トポロジとしては、
Agentは各仮想マシンに1つずつ配置されます。こうした構成は米国Engine Yard社からリリースされているnaniteやVertebraのデザインを参考にしています。

Agentの役割は、
受け付ける指令は以下のようなものになります。
- Apacheなどのデーモン用スタートアップスクリプトを呼び出せ
- 監視を開始せよ、
終了せよ
Masterの役割は、
Amazon EC2に特化した部分ですと、
- 補足:
- 現在のバージョンにはMasterに待機系を持たせる機能がありませんが、
将来のバージョンでサポートする予定です。
サービスの定義を記述する
システムの設計者は、
現在のバージョンでは、

Resource
Resourceとは、
リスト1静的コンテンツを配信するApacheプロセスを起動・
class Apache_WWW < Wakame::Service::Resource
# Apacheの起動処理
def start(svc, action)
cond = ConditionalWait.new { |cond|
cond.wait_event(Wakame::Event::ServiceOnline) { |event|
event.instance_id == svc.instance_id
}
}
# PidFileを元にしたプロセスモニタリングの開始をAgentに指示
request = action.actor_request(svc.agent.agent_id,
'/service_monitor/register', svc.instance_id, :pidfile, '/var/run/apache2-www.pid').request
# 起動スクリプトの呼び出しをAgentに指示
request = action.actor_request(svc.agent.agent_id,
'/daemon/start', "apache_www", 'init.d/apache2-www').request
# Event::ServiceOnlineがやってくるまで待つ
cond.wait
end
# Apacheの終了処理
def stop(svc, action)
cond = ConditionalWait.new { |cond|
cond.wait_event(Wakame::Event::ServiceOffline) { |event|
event.instance_id == svc.instance_id
}
}
# 終了スクリプトの呼び出しAgentに指示
request = action.actor_request(svc.agent.agent_id,
'/daemon/stop', 'apache_www', 'init.d/apache2-www').request
# Event::ServiceOfflineがやってくるまで待つ
cond.wait
# プロセスモニタリングの停止をAgentに指示
request = action.actor_request(svc.agent.agent_id,
'/service_monitor/unregister', svc.instance_id ).request
end
end
Cluster
サービス全体の定義を行うデータ構造で、
class WebCluster < Wakame::Service::ServiceCluster
def initialize(master)
super(master) { |c|
# サービスの定義を追加
c.add_resource(Apache_WWW.new)
c.add_resource(Apache_APP.new)
c.add_resource(Apache_LB.new)
c.add_resource(MySQL_Master.new)
# 依存関係の指定
c.set_dependency(Apache_WWW, Apache_LB)
c.set_dependency(Apache_APP, Apache_LB)
c.set_dependency(MySQL_Master, Apache_APP)
}
end
end
Instance
ResourceおよびClusterは、
作業を並列処理するための仕組み
ここまでで、
以下の図は、

Event
Masterは、
Eventの例としては、
- Clusterの状態が変わったとき
(ClusterStatusChanged) - サービスが起動/終了したとき
(ServiceOnline/ ServiceOffline) - Agentが認識されたとき
(AgentMonitored/ AgentUnmonitored) - Agentが数秒ごとに定時連絡をしてきたとき
(AgentPong)
Action
Wakameでは、
Action内部は基本的に直列処理となっており、
このようにして、
作業の呼び出し方
Actionを起動する方法はいくつかあります。
- wakameadmコマンドによるMasterへのメッセージ送信
- Masterの内部に設定されたスケジューラ
- Agentから報告されたメッセージ
最初(1)のコマンドは、
次に(2)のスケジューラですが、
最後に(3)ですが、
次回予告
次回は、