マネージドなコンテナ実行環境の普及に伴い、Configuration Managementツールを利用する必要がある現場は少なくなったが、Configuration Managementツール自体の必要性はまだ失われていない。また、モバイルコンピューティングやエッジコンピューティングの普及に伴い、Configuration Managememntツール自体のあり方も今後変化していくと考えられる。
本予稿では、Configuration Managemantツールの役割を整理し、Configuration Managementツールの今後のあるべき姿を検討する。それにより導きだされた、Configuration Managementツールを3層で構成する方式を提案し、その中で中心的な役割を果たすポリシー定義用中間言語について考察する。
類する言葉してはサーバープロビジョニングという用語の方が日本語で多く見られるが、英語ではConfiguration Managementと呼ばれることが多い。
Configuration Managementとは、Burgess、Couchらによると1、「予め定義されたポリシーとガイドラインに従い、事前に決められたビジネス上の目的を達成するよう、ネットワーク接続されたマシンの振る舞いを制御するプロセスである」と述べられている。
Configuration Managementツールとは、その名の通りConfiguration Managementを行うためのソフトウェアである。
代表的なものとして、CFEngine, Puppet, Chef, SaltStack, Ansibleなどがある。特に、後発のChef, Ansible, Puppet, SaltStackをまとめてCAPSと呼ぶこともある。
Configuration Managementツールは「予め定義されたポリシーとガイドラインに従い、事前に決められたビジネス上の目的を達成するよう、ネットワーク接続されたマシンの振る舞いを制御する」ためのツールである。このことから、Configuration Managementツールには以下の2つの役割があると捉えられる。
実際、先にあげた代表的なConfiguration Managementツールは、この2つの役割を持っている。それぞれのツールの違いは、「ポリシー定義」と「振る舞いの制御」の2つに関する実装の違いとも言える。
Configuration Managementツールの役割のひとつして「ポリシーの定義」を先に挙げた。ポリシーの定義は、何からの言語を用いて行うことになる。Configuration Managementツールの文脈で言語に言及する場合、ポリシー定義用言語と実装言語が混同されることがあるので注意が必要である。
Configuration Managementツールに採用されているポリシー定義用言語は、大別すると独自言語、YAMLのような簡易言語、プログラミング言語の3つにわけられる。ポリシー定義用言語としては、YAMLが最も人気があるように見受けられる。Configuration ManagementツールではAnsibleが今でも人気があるが、YAMLを採用していることが一因と考えられる。
また、Configuration Managementツールではないが、Infrastructure as Codeに関連するツールとしては、KubernetesもYAMLを採用している。
従来のConfiguration Managementツールの利用対象者であったシステム管理者は、プログラミングを行わない人が多いため、YAMLのような簡易言語が好まれる傾向にあると思われる。
また、YAMLのような簡易言語は変数やロジックがないため、記述を簡易にできメンテナンスしやすい、といった点も好まれる一因と考えられる。（ただし、変数やロジックがない、というのは欠点でもあり、それを補う手法が同時に使われているケースもある。）
一方、クラウドの普及により、システム管理者だけではなくアプリケーション開発者もサーバーインフラを触るようになった。このような人達は、簡易言語や独自言語よりも、慣れ親しんでいるプログラミング言語を好む傾向にある。
いずれにせよ、どの言語がポリシー定義用言語として最適なのかは、利用する人や組織が置かれている環境、利用者のスキル、好み等に依存するため、一概に決めることはできない。
Configuration Managementツールのもうひとつの役割である「振る舞いの制御」を行う方法も、ポリシー定義用言語同様、様々である。
例えば、ChefやPuppetはサーバー/エージェント型の構成をとっており、中央のサーバーで管理されたポリシーを各マシンに配布、適用して振る舞い制御を行う。また、サーバー/エージェント型としてだけではなく、スタンドアローンで実行することもできる。
サーバー/エージェント型は、ポリシーの配布、サーバー/エージェント間の接続や認証、マシン制御の実行方法やタイミングなどをツールに任せることができる、というメリットがある。反面、サーバープロセスやエージェントプロセスの監視をどうするか、サーバーとエージェントの初期接続時の認証情報をどのように受け渡すか、などといった点を考慮する必要がある。
一方、スタンドアローンで制御を行う場合は、常駐プロセスがないため、サーバー/エージェントのプロセス監視や接続時の認証については考える必要はない。反面、ポリシー定義コードをどのように配布し、どのようなタイミングでポリシー適用を行うのかを、自ら決める必要がある。
Ansibleはエージェントレスで、スタンドアローンで制御したり、リモートマシンに対してSSHで接続して制御したりすることもできる。これもChefやPuppetのスタンドアローン型と同様のメリット/デメリットがある。
また、モバイルデバイスやエッジデバイスの普及に伴い、多様なデバイスへの対応、転送容量削減、メモリ容量節約、実行速度の向上、自律制御といった観点から、別の制御実装が求められることも考えられる。
さらに、現在のConfiguration Managementツールは、記述されたポリシーを逐次解釈して制御を行うインタプリタ型だが、制御用コードを生成して実行するコンパイラ型の方が望ましいケースも考えられる。
このように、ポリシー定義用言語と同様、振る舞い制御の実装についても、サーバーマシンが置かれている環境や、どのように管理を行いたいか、といった前提条件によって適した制御方法が異なるため、どの振る舞い制御実装が最適かを一概に決めることはできない。
ポリシー定義用言語も振る舞い制御実装も、条件によりベストなものが異なる、という前提に立つと、様々なポリシー定義用言語や振る舞い制御実装が存在する、ということは好ましいことである。
しかし、既存のConfiguration Managementツールは、ポリシー定義言語と振る舞い制御が密結合している。そのため、用途に適したポリシー定義用言語や振る舞い制御実装を備えたツールが存在しない場合、ポリシー定義用言語部分も振る舞い制御部分も一から実装する必要がある。また、あるツールのポリシー定義用言語だけ差し替えて振る舞い制御実装のみ利用する、といったことも不可能である。
ポリシー定義用言語と振る舞い制御実装が密結合していると、部分的に再利用できないため、開発に無駄が生じる。そこで、多様なポリシー定義用言語と振る舞い制御実装に対応しつつも、開発コストを抑えるために、ポリシー定義用言語と振る舞い制御の実装を分離することを提案する。提案方式はLLVMに着想を得ている。
LLVMは以下の図のような3層モデルになっており、各種言語用フロントエンドが、その言語で書かれたコードをLLVM IRという中間言語に変換、その後LLVMが中間言語に最適化処理などを施し、最終的には各CPUアーキテクチャ用のバックエンドが、そのアーキテクチャで実行可能なバイナリコードを生成する。
LLVMの「3層モデル」「中間言語」という概念をConfiguration Managementツールに応用すると、以下の図のようになる。
Optimizer部分で何をするのか、という点については現在のところアイデアはないが、Optimizeする必要がなければ、そのままバックエンドに渡す形となる。また、右端の制御実行は、逐次実行型の場合は中間言語を解釈してそのまま実行することをイメージしているが、そうではなく制御実行コードを吐き出す、という形も考えられる。
このような形にすることで、利用者は用途に適したポリシー定義言語や振る舞い制御実装を選択できる。また、用途に合うポリシー定義言語や振る舞い制御実装が存在しない場合に、ポリシー定義用言語のみ、あるいは振る舞い制御実装のみ開発する、といったことも可能となる。
3層構造のConfiguration Managementツールにおける中間言語は、各種ポリシー定義用言語とN対1で対応するものであるので、中間言語自身もポリシー定義用言語であると言える。そのため、中間言語はポリシー定義用言語に適した性質を備えている必要がある。
ポリシー定義用言語に適した言語とは何か、についてはまだ十分考察できていないが、今のところ考えていることをリストアップする。
今後、この考察を更に深めていく予定である。これらに対する意見や、こういったアプローチで考察すると良いのでは、といった助言があればぜひ頂きたい。