構成管理ミドルウェアはシステム管理者となる

複数サーバを管理するシステム管理の経験をお持ちの方は，構成管理のためのツールを日常的に利用しているかと思います。自作の物である場合もあるでしょうし，商用・無償を含む多くのパッケージもすでに存在しています。構成管理のツールとして単純な例は，makeとsshを組み合わせたものがあげられると思います。サーバのホスト名のリストを用意しておき，それらに対してssh接続し，必要なコマンドを順番に走らせることができれば十分に作業の効率化に貢献します。

前回，Wakameがターゲットとしているクラウド型ホスティングでは，APIによるサーバ・仮想マシンの管理ができることで作業の自動化可能な範囲が飛躍的に広がったということを説明しました。

これまで比較的変化が少なかったサーバ構成に，ダイナミズムが加わりました。そのため，新たな課題が表面化することになります。

例えばAmazon EC2で自動化を行おうとした場合，課題が大きく2つあります。

1．作業の同期化・非同期化をコントロールしなければならない

• 複数の仮想マシンに対する並列的な処理と，手続きが重要な部分では直列的な処理ができること
• Amazon EC2のWeb APIは受動的な呼び出ししかなく，処理も非同期で行われるため，適宜Web APIにアクセスして確認できること

2．アプリケーションの設定値を動的に変更しなければならない

• 仮想マシンへのアクセスに必要な情報（IPアドレス・ホスト名など）が動的に決まるものに対応できること

これらの点を考慮しつつとなれば，先に述べたmakeとsshの組み合わせだけで実現したいとは思わないでしょう。少なくともダイナミックな構成管理というものには，最低限必要とされる汎用的な処理がありそうです。

Wakameは，これらの従来のホスティング環境には無かった課題を乗り越えるためのフレームワークを整備し，手順を自動化することを目指しています。言わば，あたかも「システム管理者」として機能するのが理想です。

クラウド型ホスティング上での構成管理に求められるもの

Amazon EC2ではWeb APIへアクセスし，仮想マシンの調達を行います。

この時，仮想マシンが使える状態になるまでの時間にはばらつきが出ることもしばしばです。5分以内で完了する場合もあれば，運悪くAmazonのデータセンタ内の負荷が高い場合10分以上かかってしまう場合もあります。起動しようとするマシンイメージファイルのサイズにも相関があるようです。

ここで重要なのは，処理が非同期で実行されているために，いつ終わるか分からないということです。

処理の同期化・非同期化のコントロール

Amazon EC2のWeb APIには仮想マシンの状態を取得するものが用意されています。しかし現時点のWeb APIでは受動的な呼び出ししかサポートされておらず，状態の変化を能動的に通知してくる仕組みはありません。

そのため，処理が終わったことを受けて次の手順に移るためには，都度Web APIを通じて状態の変化を監視し，仮想マシンの状態が起動完了を示すまで待つというような工夫が必要になります。

実際には，さらにそこからOSが起動するのでsshなどのアプリケーションレベルのアクセスが可能になるにはさらに時間がかかります。Web APIを通じた状態の監視の他に，アプリケーションレベルの通信が可能な状態であるかも監視することになります。

この例から分かるように，クラウド型ホスティングの管理では処理の同期化と非同期化が要求されます。同期的な処理を実行していくモデルだけの構成管理ツールでは手順を自動化しづらいケースが存在することが分かっていただけると思います。

並列処理による効率化と，直列処理による確実化

Amazon EC2上ではWeb APIの呼び出しだけで仮想マシンを数十台?数百台確保し，大規模にサービスを開始することも可能です。

複数台のマシンでサービスを実現する場合，Webサーバやデータベースサーバ，バッチサーバなどと処理や役割に応じて小グループ化することが多いと思われます。

そして，役割を持ったグループ間には依存関係があり，立ち上げや終了の作業には順番があります。アプリケーションサーバが動くためにはデータベースサーバが必要ですし，ロードバランサが動作するためにはアプリケーションサーバの数とIPアドレスが決まっていないといけないのです。

図1のような構成の場合，ロードバランサの設定の完了までの面倒を見ようとすると，下の段に属するアプリケーションサーバや静的コンテンツ用のWebサーバのIPアドレスが決定されないことには，ロードバランサの起動が先に完了したとしてもリクエストの振り分けの設定まで終わらせることができません。

Amazon EC2では，仮想マシンに対するIPアドレスが動的に割り当てられます。IPアドレスが割り当てられるタイミングは，仮想マシンの調達を要求してすぐではなく，実際にOSが起動できる状態になってからです。したがって，IPアドレスを知ろうとすると，その仮想マシンがきちんと起動してくるまで待つ必要があります。

サーバ群の起動・サービスの開始までを自動化しようとするケースを想定してみましょう。仮想マシンの台数が大量にある場合，作業手順が同じサーバに対しては並列に接続し，同じコマンドの呼び出しを行うことで全体の作業時間を短縮することができます。一度に並列処理をする中に，先ほどのIPアドレスを知るというような，直列処理が求められるのです。

設定の変更と反映

さて，ここまでで作業の並列処理と直列処理を織り交ぜて，手順として効率的かつ確実に実行する必要があることが把握できたかと思います。

次は，そうした手順を実行していく中で，各サーバの設定を変更する必要が出てきます。仮想マシンが追加されると，その仮想マシン上で動くサーバを利用するように隣接するサーバの設定を変更する必要があります。つまり，サーバの構成図から隣接するサーバに対して，設定ファイルを動的に書き換え，その設定ファイルを読み直すようサーバに通知しなければなりません。動的にサーバ台数を変化させられる様サーバ群を構成するためには，台数が変化しゆく部分の設定内容を更新するだけでなく，その機能に依存する部分がある場合，別のサーバで稼働中のサービスに対してもきちんと反映できるよう手順を踏む必要があります。

次のページでは，これら直列・並列的な処理，サーバ間をまたぐ設定内容の変更を可能にするWakameの概要についてお話しします。