大規模システム構築に求められる自動化とChefの基本的な考え方とは

システム構築・運用の問題

近年、HadoopやOpenStackといった大規模分散基盤が注目を集めています。それに伴い多数のサーバーを構築・運用する機会のある方も増えてきているのではないでしょうか。
筆者も以前、数百台のHadoopクラスタ構築を担当したことがあり、構築台数の多さと作業の煩雑さに愕然としました。特に以下の点が問題でした。

（1）設定ミスにより膨大な作業が発生するリスクがある

検証環境の構築で、当初筆者は同じようなサーバーの構築を何度も行っていました。同じ作業を何度も繰り返していると、すぐに作業がマンネリ化し集中力が続かなくなり、設定ミスが多くなりました。その様な設定ミスが致命的な場合は、切り分け作業や設定の見直し作業が発生します。最悪の場合、全サーバの設定を確認することも考えられます。

（2）全体の待ち時間が大きな時間のロスになる

パッケージのインストールなどは待ち時間が10分程度かかり、ちょっとした待ち時間が数多く発生します。これは、全体で大きな時間のロスになります。一方で、待ち時間中に別作業を行うにしても、数分～数十分の待ち時間しかなければなかなか集中できません。

これらの作業は余計な作業を生み出すリスクを伴うだけでなく、作業者のモチベーション低下を招きます。

図1：大規模環境を構築する際に発生しやすい設定ミス（クリックで拡大）

大規模システムに限らず、システム構築・運用業務に携わっている方はサーバの増設やテスト環境の作成などで、同じ様な作業を何度も行うことがあると思います。上記（1）、（2）の問題は、構築・運用に携わる方々にとって共通の問題ではないでしょうか。

もしかすると、シェルなどのスクリプトを用意すれば解決できると考えた方もいらっしゃると思います。1人の人間が一貫してシステム構築・運用を担当する場合は、それでよいかもしれませんが、複数人で組織的に行っていく場合には問題があります。スクリプトの作り方などのルールを定めていない状態で作られたスクリプトは属人的なものになりがちですし、作った本人以外には使いにくいものです。再利用されずに必要な人間が毎回作成することになり作業の重複が生まれます。

では、構築作業をより効率的に行うためにはどうすればよいのでしょうか。

人手作業が原因によっておこる上記（1）、（2）の問題を解決するために、組織的に活用できる何らかの仕組みを導入する必要があります。そのアプローチの1つが、自動構築フレームワークの導入です。

そこで本連載では、“Facebookの採用など実績があり”、“インストーラが便利で簡単に試せる”オープンソースソフトウェアのChefを紹介します。

Chefとは、自動構築のためのOSSフレームワーク

Chefとは、米国のOpscode社が中心となって開発を進めている自動構築のためのフレームワークです。このフレームワークに沿って、Chef用の言語でシステムの状態を定義することで、Chefがシステムをその通りの状態にしてくれます。
また、共通の言語で定義することで、他のシステム構築・運用でも流用が可能になるため、誰かが一度行った構築・運用ノウハウを活用できるといったメリットがあります。

Chefの重要なコンセプト、“システムの状態をコードで管理する”についてもう少し掘り下げて説明しましょう。

例えば“ソフトウェアAがインストールされており、サービスが立ち上がった状態”をコードで定義します。そしてソフトウェアAを導入するサーバが複数台あった場合、ソフトウェアAのコードを各サーバに設定することで1つのコードで複数台のサーバにおけるソフトウェアAの状態を定義することができます。

図2：Chefはシステムの状態をコードで管理する（クリックで拡大）

“状態をコードで定義する”とは具体的にどういうことなのか、イメージしやすいように簡単な例をご紹介しておきましょう。以下に示すように設定ファイルの様になっており、“owner”や“group”の値をします。詳細は第2回でご紹介します。

remote_file "/etc/httpd/conf/httpd.conf" do
    source "httpd.conf"
    owner "root"
    group "root"
    mode "0644"
    action :create
end

因みに、上記の例では /etc/httpd/conf/httpd.confファイルの状態を定義しています。

これまで各サーバに対し各々行っていたOSの設定や、ソフトウェアの設定をコード化して管理することで、下記のメリットが得られます。

（1）コード化した状態を他のシステム構築・運用にも流用できる

フレームワークに沿って作成したコードは、Chefを導入した他のシステム構築でも利用できます。同じようなシステムを構築する場合、既存のコードをカスタマイズすることでシステムの状態を定義しChefで構築・運用できます。

（2）繰り返し作業を集約できる

構築するサーバ台数が多いと、設定ファイルの値が少しだけ異なる同じような構成のサーバの構築でも、毎回同じ作業を繰り返すことになります。Chefでコード化して管理できるようになれば、共通部分と個別部分でコードを分けることができるため、共通部分は1つのコードを用意するだけで済み繰り返し作業を集約できます。

（3）システムの状態を容易に確認できる

手作業であれば設定ファイルの設定値やファイルの権限などを確認するには、対象となる全サーバにログインして確認する必要があります。設定管理は一貫してChefで行う運用であれば、コードを参照することで設定値などを確認できます。

Chefを使用する環境

Chefを使用して構築・運用できる環境は、現状、UNIX/Linux系OSが中心です。Windows系OSもサーバ系で開発が進んでいます。Opscode社の下記のページが参考になります。

＞　System Requirements

Chefの用語

次章以降で使用しますので、必要に応じて参照して下さい。Chefの用語で“システムの状態をコード化したもの”をレシピと言います。 Chef自体もそうですが、Chefの用語には調理に関連したものが多いようです。

Chefの仕組み

Chefの基本的な仕組みは構築・運用対象マシンにレシピとChefプログラムをデプロイし、Chefプログラムがレシピに基づいて人手の代わりの構築・運用を行う、という流れです。

Chefのアーキテクチャは、大きく分けて2つのタイプがあります。1つ目が、単体プログラム（スタンドアロン）で使用するタイプ（図3-A）、2つ目がClient/Server構成で使用するタイプ（図3-B）です。2つのタイプの大きな違いは、レシピを配布・管理する機能の有無です。

（1）スタンドアロンタイプ（図3-A）

スタンドアロンタイプでは、ノードごとに割り当てるレシピを使用者が直接配布します。配布したレシピを指定し、chef-soloを実行するとchef-soloがレシピに基づいて構築・設定を行います。

（2）Client/Server タイプ（図3-B）

Client/Serverタイプは、レシピやノードの管理を行うChef Serverとレシピに基づいて構築を行うchef-clientによって構成されています。

図3：スタンドアロンタイプ（A）とClient/Server タイプ（B）（クリックで拡大）

Chef Serverでレシピを適用するまでのおおまかな流れは以下の通りです。

ステップ１：Chef Serverサイド

• （a）Chef Serverにレシピを格納する
• （b）Chef Serverでノードとレシピの設定を行う

ステップ２：chef-client（ノード）サイド

• （c）chef-clientを実行すると、chef-clientはサーバにリクエストを送信し自身に設定されたレシピを取得する
• （d）chef-clientは取得したレシピに基づいて、構築・設定を行う

スタンドアロンタイプとClient/Serverタイプのポイントと注意点は、表の通りです。

chef-soloは、使用するまでの準備がChef Serverに比べ容易であり、簡単に試せます。レシピを書いてみたい方は、chef-soloで試してみて下さい。（インストール方法については、第2回で紹介いたします。）

Chef Serverはサーバを用意する必要がありますが、Opscode社が提供するインストーラを使用すればこちらもインストール自体は簡単にできます（その後の設定作業が少しだけ面倒です）。

Chefを使ってうれしいことは？

Chefを導入すると、以下の効果を期待できます。

• 構築・運用コストの削減
• 構築のやり直しがきく
• 作業時間の短縮
• 構築・運用ノウハウの共有

第1回は、自動化の必要性とChefの概要やシステムをコードで定義することの考え方について記載しました。第2回では、chef-soloと呼ばれる単体プログラムを使用して、実際にレシピを書いて試す方法をご紹介します。レシピの説明を通して、Chefの機能についても紹介していきますので、第2回をお楽しみに！

※記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。