Merge pull request #13 from mizzy/all

全体とりまとめ用プルリクエスト

.gitignore

@@ -1,4 +1,5 @@
 *.dvi
 *.log
 *.aux
-
+*.blg
+memo.txt

01.tex

@@ -1,13 +1,9 @@
 \section{はじめに}
 
-システムの大規模・複雑化に伴い，サーバの構築・運用を効率化するために，サーバ構成を宣言的なコードで記述・管理するという手法が提案され，その実装として構成管理ツールCFEngine\cite{cfengine}が1993年に登場している．その後様々な構成管理ツールが生み出されているが\cite{cmt}，2005年のPuppetの登場\cite{puppet}と2006年のAmazon EC2の登場\cite{ec2}をきっかけに``Infrastructure as Code''という概念が台頭し，``Agile infrastructure and operations''\cite{agile infrastructure}という流れが生まれている．これはアジャイル開発の手法をサーバ構築・運用に適用しようという潮流である．（ここで言う``Infrastructure''はアプリケーションを載せるための土台を意味し，OSやミドルウェアといったソフトウェアレイヤーを含む．）
+科学やビジネス領域における問題の複雑化への要求に応えるため，システムが大規模化・複雑化する\cite{survey_and_taxonomy_of_iaas}のに伴い，UNIXシェルにより書かれたプログラムに代わり，サーバの設定を宣言的なコードで扱う構成管理手法が広く提供されている．その実装として1993年にCFEngine\cite{cfengine}が登場し，その後様々な構成管理ツールが生み出されているが\cite{cmt}，2005年のPuppetの登場\cite{puppet}と2006年のAmazon EC2の登場\cite{ec2}をきっかけに``Infrastructure as Code''という概念が台頭した．この概念における``Infrastructure''はアプリケーションを載せるためのインフラを意味し，OSやミドルウェアといったソフトウェアレイヤーを含む．そして，インフラをコードで扱うことから，アジャイルソフトウェア開発\cite{agile_manifesto}と同様の手法がサーバ構築・運用にも適用できるのでは，という発想が生まれ``Agile infrastructure and operations''\cite{agile_infrastructure}という流れが生じている．
 
-この流れの中で，``Agile infrastructures and operations''を効率よく実践するためのプロセスとして，テスト駆動開発の手法をサーバ構築・運用に応用した``Test-Driven Infrastructure''\cite{test driven infrastructure with chef}というプロセスが提案されており，このプロセスを支援するテストフレームワークがいくつも登場している\cite{chefspec}\cite{rspec-puppet}\cite{cucumber-chef}\cite{minitest-chef-handler}\cite{test kitchen}\cite{rspec-system}．
+``Agile infrastructures and operations''を実践するためのプロセスとして，テスト駆動開発\cite{test_driven_development}の手法をサーバ構築・運用に応用した``Test-Driven Infrastructure''\cite{test_driven_infrastructure_with_chef}が提案されており，このプロセスを支援するテストフレームワークがいくつも登場している\cite{chefspec}\cite{rspec-puppet}\cite{cucumber-chef}\cite{minitest-chef-handler}\cite{test-kitchen}\cite{rspec-system}．これらのうち，ChefSpec\cite{chefspec}，rspec-puppet\cite{rspec-puppet}は，構成管理ツール固有の言語で書かれたコードの内容をテストするのみで，実際にコードをサーバに適用し，設定が正しく行われたかどうかまではテストしない．そのため，単体テストしては利用できるが結合テスト用途には利用できない．Cucumber-chef\cite{cucumber-chef}，minitest-chef-handler\cite{minitest-chef-handler}はChefという特定の構成管理ツールに依存している．そのため，Chef以外の構成管理ツールでは利用することができない．Test Kitchen\cite{test-kitchen}やrspec-system\cite{rspec-system}は，テスト用Virtual Machine（以降VMとする）の作成，テスト用VMへの構成管理ツールの適用，テストの実行をトータルで行う統合テストスイートであるが，標準で持つテスト実行機能は汎用性に乏しく，特定の構成管理ツールに依存しており，OSやディストリビューション毎の違いを意識したテストコードを書く必要がある．
 
-これらのうち，ChefSpec，rspec-puppetは，構成管理ツール固有の言語で書かれたコードの内容をテストするのみで，実際にコードをサーバに適用した結果はテストしない．そのため，単体テストしては利用できるが結合テスト用途には利用できない．Cucumber-chef，minitest-chef-handlerはChefという特定の構成管理ツールに依存している．そのため，Chef以外の構成管理ツールでは利用することができない．Test Kitchenやrspec-systemは，テスト用VMの作成，テスト用VMへの構成管理ツールの適用，テストの実行をトータルで行う統合テストスイートであるが，組み込みのテスト機構は汎用性に乏しく，特定の構成管理ツールに依存していたり，OSやディストリビューション毎の違いを意識したテストコードを書く必要がある．
+我々は，テストフレームワークの汎用性を高めるために，構成管理ツール特有の振る舞い，例えば，パッケージのインストールやシステムユーザの作成などを抽出，一般化し，それらをテストするためのコマンドをOSやディストリビューション毎に分離，その上でOSや実行形式の違いを吸収するレイヤーを設けることにより，汎用コマンド実行フレームワークを定義した．続いて，テストコードの記述の抽象度を高め可読性を上げるために，宣言的かつ自然言語に近い記法で汎用コマンド実行フレームワークを操作できる制御テストフレームワークを定義した．これにより，テスト対象の環境の違いを気にすることなく，直観的にテストが書ける．また，フレームワークを用途別に分離して定義することにより，制御テストフレームワークを独自の記法に変更することも容易である．例えば，本論文で提案するテストフレームワークでは，テスト記法としてRSpec\cite{rspec}を採用しているが，他のテストフレームワークに差し替えたり，あるいはまったく独自の記法に差し替えたりすることも可能である．このテストフレームワークをserverspec\cite{serverspec}と名付けた．serverspecを採用している企業も既に存在する\cite{nintendo}\cite{wantedly}．
 
-我々は，テストフレームワークの汎用性を高めるために，構成管理ツール特有の振る舞い（例えば，パッケージのインストールやシステムユーザの作成など）を抽出・一般化し，それらをテストするためのコマンドをOSやディストリビューション毎に分離，その上でOSや実行形式の違いを吸収するレイヤーを設けることにより，汎用コマンド実行フレームワークを定義した．
-
-続いて，テストコードの記述の抽象度を高め可読性を上げるために，宣言的な記法で汎用コマンド実行フレームワークを操作できる制御テストフレームワークを定義した．これにより，テストコードのメンテナンス性を高め，サーバの運用・管理コストを低減することができる．また，フレームワークを用途別に分離して定義することにより，制御テストフレームワークを独自の記法に変更することも容易である．例えば，本論文で提案するテストフレームワークでは，テスト記法としてRSpec\cite{rspec}を採用しているが，minitest\cite{minitest}に差し替えたり，あるいはまったく独自の記法に差し替えたりすることも可能である．このテストフレームワークをserverspec\cite{serverspec}と名付けた．serverspecを採用している企業も既に存在する\cite{nintendo}．
-
-本論文の構成について述べる．2章ではサーバの構成管理とテスト手法について更に詳しく述べる．3章では提案するサーバのテスト手法を詳細に述べ，4章では提案手法によりもたらされた成果を論じ，5章で結びとする．
+本論文の構成について述べる．2章ではサーバの構成管理とテスト手法について更に詳しく述べる．3章では提案するサーバテスト手法と実装について述べ，4章では提案手法の評価について論じ，5章で結びとする．

02.tex

@@ -1,45 +1,42 @@
 \section{サーバの構成管理とテスト手法}
 
-本論文で提案するストフレームワークは，サーバ構成を記述したコードのテストをいかに効率よく行うか，という観点から出発している．そこで代表的な構成管理ツールを例に，ツールと言語の特徴，テスト手法ならびに従来手法の問題点について言及する．
+本論文で提案するテストフレームワークは，構成管理ツールによりサーバ構成を記述したコードのテストをいかに効率よく行うか，という観点から出発している．そこで代表的な構成管理ツールを例に，ツールと言語の特徴，テスト手法ならびに従来手法の問題点について言及する．
 
 \subsection{CFEngineからChefへ}
 
-安価なUNIXライクOSを搭載したサーバが普及し，TCP/IPにより異なるOSを搭載したサーバ同士がネットワーク接続可能になった．これによりシステムが大規模化・複雑化し，シェルスクリプトに代わり，サーバの設定を宣言的なコードで扱う構成管理手法が提案された．その実装としてCFEngine\cite{cfengine}が登場した．
-
-2005年にはCFEngineに影響を受け発展させたPuppet\cite{puppet}が登場，2009年にはPuppetから影響を受けたChef\cite{chef}が登場している．CFEngine，Puppetは独自のDSL(Domain Specific Language)でサーバの構成を記述するが，ChefはRubyによる内部DSLで記述する．その特性ゆえ，Chefはシステム管理者よりも開発者に強く訴求し，Amazon EC2(Elastic Compute Cloud)の様な開発者自身がサーバ構築・運用を行える環境の普及とともに広まりを見せている．
+第1章で触れたCFEngineは1993年に登場した．2005年にはCFEngineに影響を受け，より抽象度と拡張性を高める形で発展させたPuppet\cite{puppet}が登場，2009年にはPuppetから影響を受け，コードのプログラマブルな側面を強めたChef\cite{chef}が登場している．
 
 \subsection{ChefからTest-Driven Infrastructureへ}
 
-CFEngineやPuppetでは，記述できることが独自DSLの範囲内に収まるため，コードは比較的簡易なものとなる．しかしChefはRubyでできることはどんなことでも記述できる．そのためシステムが複雑になるにともない，それを記述するコードも複雑になる．そこでサーバ構成を記述したコードに対し，アジャイル開発におけるテスト駆動開発のプロセスを適用する事で，効率よくコードを記述することができる，といった考えが生まれる．Test-Driven Infrastuctureという概念はChefコミュニティ周辺で発生したものであるが，それは偶然ではなく，このようなChefが持つ言語特性ゆえである．
+CFEngine，Puppetは独自のドメイン固有言語でサーバの構成を記述するが，Chefは実装言語と同じ言語を利用したドメイン固有言語，すなわちRuby\cite{ruby}という汎用プログラミング言語で記述する．その特性ゆえ，Chefはシステム管理者よりも開発者に強く訴求し，Amazon EC2\cite{ec2}の様な開発者自身がサーバ構築・運用を行える環境の普及とともに広まりを見せている．しかし，汎用プログラミング言語であるが故に，システムが複雑になるにともない，それを記述するコードも複雑になる．そこでサーバ構成を記述したコードに対し，アジャイル開発におけるテスト駆動開発のプロセスを適用する事で，効率よくコードを記述することができる，といった考えが生まれる．Test-Driven Infrastuctureという概念はChefコミュニティ周辺で発生したものであるが，それは偶然ではなく，このようなChefが持つ言語特性ゆえである．
 
 \subsection{Test-Driven Infrastructureにおけるテスト手法の分類}
 
-Test-Driven Infrastructureにおけるテストの種類は，テスト駆動開発における以下の3つに分類できる．
+Test-Driven Infrastructureにおけるテストの種類は，テスト駆動開発における以下の三つに分類できる．
 
 \begin{enumerate}
   \item 単体テスト
   \item 結合テスト
   \item 受け入れテスト
 \end{enumerate}
 
-単体テストは構成管理ツールにおける``モジュール''に対するテストで，実際にコードをサーバに適用する前の段階で行うテストである．結合テストはコードをサーバに適用した後に行うテストで，コードが期待通りにサーバの設定を行ったかどうかをテストする．受け入れテストもコードをサーバに適用した後に行うテストだが，結合テストがサーバ内部の状態をテストするホワイトボックステストなのに対し，受け入れテストはサーバの外から見た振る舞いをテストするブラックボックステストであるという違いがある．
+単体テストは構成管理ツールにおける``モジュール''に対するテストで，実際にコードをサーバに適用する前の段階で行うテストである．結合テストはコードをサーバに適用した後に行うテストで，コードが期待通りにサーバの設定を行ったかどうかをテストする．受け入れテストもコードをサーバに適用した後に行うテストだが，結合テストがサーバ内部の状態をテストするホワイトボックステストであるのに対し，受け入れテストはサーバの外から見た振る舞いをテストするブラックボックステストであるという違いがある．
 
 \subsection{従来テスト手法の問題点}
 
-単体テストツールとしてはChefにはChefSpec，Puppetにはrspec-puppetというツールが存在する．その名が示すとおり，それぞれChefとPuppet専用のツールであり，単体テストツールとしては十分であるが，実際にコードをサーバに適用した結果をテストすることはできないため，単体テストツールだけでは不十分である．
-
-結合テストツールとしては，minitest-chef-handler，Test Kitchen，rspec-systemが存在する．この内minitest-chef-handlerとTest KitchenはChefに依存したツールであり，他の構成管理ツールとともに利用することができない．Test Kitchenやrspec-systemは，テスト用VMの作成，テスト用VMへの構成管理ツールの適用，テストの実行をトータルで行う統合テストスイートであるが，ツール標準のテスト機構は汎用性に乏しく，特定の構成管理ツールに依存していたり，OSやディストリビューション毎の違いを意識したテストコードを書く必要がある．
+（1）に分類される単体テストツールとしては，ChefにはChefSpec，Puppetにはrspec-puppetというツールが存在する．その名が示すとおり，それぞれChefとPuppet専用のツールであり，サーバに対してコードを適用して設定を行うことなく，コードの整合性等のテストを行う．しかし，実際にコードをサーバに適用した結果をテストすることはできないため，単体テストツールだけではサーバのテスト手法としては不十分である．
 
-受け入れテストツールとしてはcucumber-chef，leibnizが存在するが，これらはChefに依存したツールであり，他の構成管理ツールとともに利用することができない．
+（2）に分類される結合テストツールとしては，minitest-chef-handler，Test Kitchen，rspec-systemが存在する．この内minitest-chef-handlerはテストの実装がChefに依存しており，テストの実行にChefのインストールが必要である．Test Kitchenやrspec-systemは，テスト用VMの作成，テスト用VMへの構成管理ツールの適用，テストの実行をトータルで行う統合テストスイートであるが，Test Kitchenは構成管理ツールとしてChefを利用することが前提となっている．また，Test Kitchen，rspec-systemともに，ツール標準のテスト機構は汎用性に乏しく，OSやディストリビューション毎の違いを意識したテストコードを書く必要がある．
 
-以上をまとめると表\ref{tab:comparison}のようになる．
+（3）に分類される受け入れテストツールとしてはcucumber-chef，leibnizが存在するが，これらはChefに依存したツールであり，他の構成管理ツールとともに利用することができない．
 
 \begin{table}[htb]
   \begin{center}
-    \begin{tabular}{|c|c|c|c|}
+    \caption{テストツール比較表\label{tab:comparison}}
+    \begin{tabular}{c|ccc}
       \hline
-      ツール名 & テスト種別 & ツール独立性 & OS汎用性 \\
       \hline
+      ツール名 & テスト種別 & ツール独立性 & OS汎用性 \\
       \hline
       ChefSpec              & 単体 & ×  & ○ \\
       \hline
@@ -56,9 +53,7 @@ \subsection{従来テスト手法の問題点}
       leibniz               & 受入 & ×  & ○ \\
       \hline
     \end{tabular}
-    \label{tab:comparison}
-    \caption{テストツール比較表}
   \end{center}
 \end{table}
 
-これにより，従来テスト手法では構成管理ツールからの独立性とOS・ディストリビューションの汎用性双方を満たすものが存在しないことがわかる．
+表\ref{tab:comparison}に各テストツールの比較を示す．これにより，従来テスト手法では，どのテスト種別においても，構成管理ツールからの独立性とOS・ディストリビューションの汎用性双方を満たすものが存在しないことがわかる．