approach.tex

%% -*- coding: utf-8-unix -*-

\chapter{課題に対するアプローチ}
\label{chap:approach}

% なぜ「テスト」が必要なのか? という話をいれるか?

大規模化・複雑化するネットワークでは、検証環境での手作業によるテストや人
による多重レビューによってサービス影響や問題点を完全に洗い出すのは、時間
的・リソース上の制約によって困難である(\ref{chap:problem-setting}章)。こ
うした課題に対して、本プロジェクトは以下のようなアプローチで対応を試みる。
\begin{description}
 \item[テストを自動化する] 自動化することにより、人力ではできない速度で、
            人力では見きれない範囲(パターン)をテストする。
 \item[実機・実際のシステムをもとにテストをする] 本番環境をどこまで検証
            環境で再現するかというリソース問題は残るが、テスト対象ネット
            ワークとしては特定のソフトウェア/ハードウェアを区別しない。
            一般的かつ実際に使用しているネットワークを自動テスト可能にす
            る。
\end{description}


\section{自動テストの基礎知識}
\label{sec:latedge-test-automation}

 % NetTester機能拡張検討
 % \url{https://drive.google.com/file/d/0B2eRR_JxYJA5TmhaeWItNF93Um8/}
 % ITHD技術交流会資料
 % \url{https://drive.google.com/drive/folders/0B2eRR_JxYJA5OFkzUFlveVlObWc}
 % ool意見交換会1019
 % \url{https://drive.google.com/drive/folders/0B2eRR_JxYJA5NHcxX0ZuTm9ZTEk}

  \subsection{自動テストの一般的な動向}
  \label{sec:popular-test-automation}

ソフトウェア開発では、システム(アプリケーション)の自動ビルド・自動デプロ
イ・自動テストがおこなわれる。特に近年では CI/CD や DevOps といった形で
ノウハウやベストプラクティスの蓄積・共有、ツールや環境の整備といった取り
組みをすることが一般的になった。

また、クラウドサービスへのシフトを背景に、アプリケーション(ソフトウェア)
だけでなくシステム基盤についても、ソフトウェアによる構築や制御が可能になっ
てきた。ソフトウェアによってシステム基盤全体を制御するという考え方は、
\begin{itemize}
 \item IaC (Infrastrucure as Code)
 \item SDx (Software Defined Anything)
 \item SDI (Software Defined Infrastructure)
 \item SDDC (Software Defined Data Center)
\end{itemize}
など様々なコンセプトで実現されるようになってきている。

CI/CDやDevOpsなどの取り組みは、ソフトウェアの範囲だけでなく、ソフトウェ
アによって制御可能なシステム基盤を含めたシステムあるいはサービス全体で取
り組まれるようになっている。こうした取り組みでは、アプリケーションとシス
テム基盤全体の構築・運用を最適化し、システムの利用者への価値提供、すなわ
ちサービス価値を最大化することをねらっている。

  \subsection{「ふるまい」のテスト}
  \label{sec:behavior-test}

  % サービスのテストとは? →二重の円の図
  % なぜトップダウンにやるべきなのか
  % (無駄なテストをさける/DHHのはなし:高宮さんTremaday沖縄資料, TDD/BDDまわりの話)
  % \url{https://3.basecamp.com/3088280/buckets/867009/uploads/317155391}

    \paragraph{基本的な考え方}
\ref{sec:popular-test-automation}節で取り上げたように、CI/CDといった開発・
運用プロセスの取り組みがソフトウェア開発分野を中心におこなわれている。本
プロジェクトではそうした考えかたをシステム基盤(ネットワーク)の構築・運用
に適用していく。ネットワークのテストを自動化するにあたって、独自の手法や
考えかたを考案するのではなく、すでにあるソフトウェアの自動テストなどで確
立されたベストプラクティスやツールなどを応用する。再発明を回避するために、
既存の考えかたやノウハウを活用しながら、ソフトウェア開発とシステム基盤
(ネットワーク)が同じ手法でシームレスに開発・運用できるような状況を作りだ
すことが効果的だと考える。

本プロジェクトでは、ネットワークをBDD(Behavior Driven Development)の考え
かたをもとにテストすることを考えた。BDDはTDDから派生した開発手法で、開発
するソフトウェアに期待される「ふるまい」に対するテストであ
る~\cite{wikipedia-bdd}。BDDではソフトウェアに期待される「ふるまい
(Behavior)」、複数の機能を連結したend-to-end でのインテグレーションテス
トが中心となる(\figref{fig:test-difference})。

\begin{figure}[h]
 \centering
 \begin{minipage}[c]{0.45\columnwidth}
  \centering
  \includegraphics[width=\columnwidth]{img/test-difference.png}
  \caption{インテグレーションテストとユニットテスト}
  \label{fig:test-difference}
 \end{minipage}
 \begin{minipage}[c]{0.45\columnwidth}
  \centering
  \includegraphics[width=\columnwidth]{img/test-difference2.png}
  \caption{ユニットテストの課題}
  \label{fig:test-difference2}
 \end{minipage}
\end{figure}

\begin{wrapfigure}{r}{16zw}
 \vspace*{-\intextsep}
 \includegraphics[width=16zw]{img/bdd-cycle.png}
 \caption{BDDサイクル\cite{bdd-cycle-figref}}
 \label{fig:bdd-cycle}
\end{wrapfigure}

    \paragraph{ユニットテストを中心にしたテストの課題}
通常、テストコードは直接的に金銭的報酬を発生させるものではなく、システム
の開発においては、テストによる品質担保とテスト対象(プロダクト)とのバラン
スを適切に保つ必要がある。

ユニットテスト(詳細化された機能単位のテスト)では、個々の機能としての動作
は確認できる。しかし、複数の機能を組合せ・連結して最終的にどのような動作
をするか、という要求仕様との対応が結びつけにくい
(\figref{fig:test-difference2})。したがって、テストの目的を見失いやすい
という課題がある。

そのため、ユニットテストを中心としたテストでは、往々にして「ユニットテス
トをもれなく作成すること」「テストカバレッジを100\%にすること」が目的化
されがちである。しかしもちろん、個々のユニットテストがパスしても、最終的
にテスト対象となる製品が(利用者が求める)仕様を満たさなければ価値がない。

    \paragraph{BDDのねらい}
仕様(spec)に基づいたインテグレーションテストを最初におこなうようにするこ
とで、次のようなメリットがある。
\begin{itemize}
 \item テストの目的を明確にする
 \item 実際的なテストができる
 \item 無駄なテストをおこなわない
\end{itemize}

BDDでは、まずインテグレーションテスト(仕様上期待されるふるまい)について
のテストを実施する。テストに問題があった場合、詳細化したユニットテストに
分割して内部動作を確認し、原因を切り分ける(\figref{fig:bdd-cycle})。

インテグレーションテストがパスすれば詳細なテストを省略し、インテグレーショ
ンテストで失敗した場合にユニットテストを実施して原因の切り分け・修正をお
こなう。こうすることによって、不要なユニットテストの実装・実行にともなう
開発効率の低下を回避する。また、最終的にシステム(ソフトウェア)の利用者に
対して価値を提供しているか(期待される仕様を満たすか)どうかを基準にテスト
する。

インテグレーションテストでは、テスト対象とするシステム(ソフトウェア)の最
終的なふるまいをテストするため、仕様とテストシナリオがほぼ直接対応する。
したがって、BDDのテストシナリオを記述する作業は製品が満たすべき仕様を具
体的に定義したものとなる。BDDでは最終的に製品が満たすべき仕様に着目し、
テスト対象が実現すべき価値の観点で無駄なテストを減らすことを想定している。

 \section{理想像とプロジェクトのターゲット}
 \label{sec:desired-and-target}

 % 理想的にはどうなってほしいのか
 % ここではどこらへんをおとしどころにするか

  \subsection{テストしたいネットワークの「ふるまい」}
  \label{sec:behavior-to-test}
  % ネットワークの「ふるまい」とは何か?
  % 動的なテスト, 静的なテストとは何か?

\ref{sec:behavior-test}節に示したとおり、本プロジェクトではBDDの考えかた
にそって、ネットワークの「ふるまい」をテストする。ネットワークのふるまい
として、大きく下記の2点を考える。
\begin{itemize}
 \item 静的なふるまい
 \item 動的なふるまい
\end{itemize}

    \paragraph{静的なふるまい}
ネットワークが定常状態にあるときに、end-to-end でどのような通信ができる
か(end-to-endの通信試験: \figref{fig:test-static})。ネットワークに求めら
れる最も基本的な機能は、必要なノード間/アプリケーション間で通信ができる
ことである。静的なふるまいとして、ネットワークの状態が変わらない
\footnote{一定のトポロジ/一定の状態、例えば、通常利用していて特にイベン
トが発生していない状況}ときに、アプリケーションレベルでの通信が実現でき
ること(できないこと)を確認する。
% 図をいれる: net_tester/examples readme にいれたやつ。
\begin{figure}[h]
 \centering
 \includegraphics[scale=0.5]{img/test-static.png}
 \caption{ネットワークの静的なふるまいのテスト}
 \label{fig:test-static}
\end{figure}

このような通信試験においては、
\begin{itemize}
 \item 適切な場所(物理的・論理的な位置)にノードを設置する
 \item なるべく実際的な(実際利用されたときに発生するトラフィックに近い)
       テストトラフィックを発生させる
\end{itemize}
ことがポイントとなる。

    \paragraph{動的なふるまい}
ネットワークは、耐障害性・拡張性を保証するために、ネットワーク機器間で相
互に制御情報を交換し、動的にネットワーク全体のトラフィック制御をおこなう
\footnote{例えば、ある機器に障害が発生し、その機器でトラフィックが中継で
きないと(周囲の機器が)判断した場合、その機器を中継しないようにネットワー
クのトラフィック転送ルールが再構成される。}。こうしたネットワーク自身の
状態変化がともなう状況を、「動的なふるまい」ととらえる。

定常状態にあったネットワークで、イベントに対して動的なふるまいが発生する
と、ネットワークの状態\footnote{トポロジ、あるいはNW機器の持つ状態(経路
情報, Acitve/Standbyなどの状態など)}が別の定常状態へと変化する。状態変化
の過程では、利用しているネットワーク機器の機能や仕様により、テストトラ
フィックパスが変更され、一時的に転送が中断/再開したりする。動的なふるま
いのテストは、こうした状態遷移中の通信状況を確認するものである
(\figref{fig:test-dynamic})。
% 図をいれる: net_tester/examples readme にいれたやつ。
\begin{figure}[h]
 \centering
 \includegraphics[scale=0.5]{img/test-dynamic.png}
 \caption{ネットワークの動的なふるまいのテスト}
 \label{fig:test-dynamic}
\end{figure}

動的なふるまいのテストでは、テスト対象ネットワークでの状態変化イベント発
生、イベントをまたいだテストトラフィック生成や通信状況の判断がポイントと
なる。

  \subsection{ネットワークの自動テストと運用プロセス}
  \label{sec:network-test-and-process}

  % 既存の(ソフトウェア開発の)ツールや方法論が応用できること
  % だれに対して、どのようなメリットを提供するか?

\ref{chap:problem-setting}章で解説したように、現状ネットワークのテストは
人手によるところが多く、それがボトルネックになって網羅性やスケール性が低
い。ここでは、もし仮に、現状では人手に頼らざるをえないネットワークの操作
が機械的に・自動実行できるとしたらどのような構築・運用プロセスをとること
ができるかについて検討する。

ソフトウェアによってネットワークの操作が自由にできる(操作の自動化ができ
る)ようになると仮定する。このとき、ネットワークに対する構築や運用につい
ても、ソフトウェア開発でおこなわれているベストプラクティスやノウハウがそ
のまま応用できるようにしたい(\ref{sec:behavior-test}節)。これによって、
\figref{fig:desired-cicd-process}のようなかたちでシステムの自動構成・自
動テスト、本番システムデプロイというCI/CDプロセスを実現させることができ
る。
\begin{itemize}
 \item システム(ネットワーク)で実現すべき要求を定義する
 \item 要求をコード化する
       \begin{itemize}
        \item 要求を実現するためのコード(ネットワーク設計/実装)
        \item 要求を確認するためのコード(ネットワークが満たすべき「ふる
              まい」: ネットワーク上で実現されるべき通信やネットワーク自
              身の動作)
       \end{itemize}
 \item 検証環境で自動構築・自動テストをおこなう
       \begin{itemize}
        \item テストが失敗したら原因を分析し、コードを修正・再テストをおこなう
       \end{itemize}
 \item 自動テストがすべてパスしたら本番環境へのデプロイをおこなう
\end{itemize}

% 図をいれる: ぐるぐるまわす図
\begin{figure}[h]
 \centering
 \includegraphics[scale=0.5]{img/desired-cicd-process.png}
 \caption{ネットワークのCI/CDプロセス}
 \label{fig:desired-cicd-process}
\end{figure}

ネットワーク(に限らずシステム基盤)では、ハードウェア製品を多用するため、
本番環境とまったく同等の検証環境を整備することは通常難しい。しかし、性能
面・拡張性をある程度スコープ外とし、仮想アプライアンスなどを利用すること
で、小規模でも機能的には同等の環境を整備しやすくなった。仮想化技術の応用
を含めて、機器/環境をソフトウェアで制御できる範囲はひろがっている。従来
は手作業で実施していた操作が自動化可能になるにともない、まず自動構築の技
術・ツール・ノウハウが発展しつつある。本プロジェクトは、そこに(ネットワー
クの)テストという構成要素を補い、上記のようなシステム基盤のCI/CD実現を促
進させることを狙っている。

 \section{ネットワークテストシステムの検討}
 \label{sec:discuss-network-test}

 % OOD発表資料p.4-5 「6個の構成要素」の話。ここでターゲットにするものは何か?
 % ネットワークの操作を自動化するために必要なことは?
 % テストの自動化のためにどういった機能コンポーネントが必要か?

ネットワークのテストを自動化するにあたって、現状手作業でおこなっている操
作を機械的に実行できるようにしなければならない。本プロジェクトでは、ネッ
トワークのテストに必要な操作を\figref{fig:features-of-network-testing}・
\tabref{tab:test-functions}のように分類している。

\begin{figure}[h]
 \centering
 \includegraphics[scale=0.5]{img/features-of-network-testing.png}
 \caption{ネットワークテスト自動化のための機能要素}
 \label{fig:features-of-network-testing}
\end{figure}

\begin{table}[h]
 \caption{NWテスト自動化に必要な機能要素}
 \label{tab:test-functions}
 \begin{tabularx}{\linewidth}{l|l|X}
  \hline
  No. & 要素 & 役割 \\ \hline
  \hline
  1 & NW機器を設定・操作する & テスト対象ネットワークにあるNW機器の設定を変更する \\ \hline
  2 & サーバリソースを設定・操作する & テスト対象ネットワークにある物理サーバ・仮想サーバのリソース操作などをおこなう \\ \hline
  3 & トポロジを操作する & テスト対象ネットワークのトポロジをソフトウェアによって操作する \\ \hline
  4 & テスト用ノードを配置する & テスト用のノードを生成し、テスト対象ネットワークの指定した箇所に配置(接続)する \\ \hline
  5 &テスト用ノードを操作する & テスト用のノードを操作し、テストトラフィックの生成をおこなう\\ \hline
 \end{tabularx}
\end{table}

    \paragraph{テスト対象NW内ノード操作}
\tabref{tab:test-functions} No.1,2 はテスト対象ネットワークを構成する機
器(ハイパーバイザなど仮想化基盤の管理・操作を含む)である。このような、機
器を操作するため技術・ツールなどは既に多数存在しているため、本プロジェク
トでは注力しない。(既存の技術やツールを応用する;
\ref{sec:related-research}節)

    \paragraph{トポロジ操作}
\tabref{tab:test-functions} No.3 はテスト対象ネットワークのトポロジ(物理
結線を含む)の操作である。障害試験(リンクダウンなど)や環境の構成拡張・縮
小(ノードの追加・削除などトポロジ変更)などの理由で、ネットワークトポロジ
そのものの変更が発生する。このような場合に、ネットワークのふるまいをテス
トするために必要となる。

\ref{sec:difficulty}節で示したように、特に物理的な構成要素の操作は自動化
が難しい。\lopj では、OpenFlow スイッチを応用したテスト対象ネットワーク
の物理トポロジ構成・操作についての実証実験を実施した。本プロジェクトでは
そこで実証した技術を応用してテスト対象ネットワークの物理トポロジ操作をお
こなう。

    \paragraph{テスト用ノード操作}
\tabref{tab:test-functions} No.4,5 はテスト用ノードの操作である。ネット
ワークテストでは、テストトラフィックを送受信することで、ネットワークが問
題なく動作しているかどうかを確認する。テストトラフィックの送受信には、テ
スト対象ネットワークを構成する機器(すでに環境にあるNW機器やサーバ)を利用
できる。しかし、ログ取得やテスト用ツール準備などの都合から、何らかのテス
ト用ノード(PCなど)を別途用意することが多い\footnote{特に新規構築の場合は、
サーバ等テスト対象とするノードが利用できない(存在しない)状態でネットワー
クのテストをおこなうこともある。}。こうしたテスト用ノードを利用したテス
トには以下のような問題がある。
\begin{itemize}
 \item テスト用ノード(機器台数)の上限
 \item テスト用ノードを操作する人(担当者人数)の上限
 \item 分散して作業することによる、テスト全体の状況を把握することの難しさ
 \item テスト用ノードのセットアップ(IPなど)の手間
 \item テスト用ノードの配置(テスト対象NWへの接続)の手間
\end{itemize}

トポロジ操作同様に、\lopj では、Linux Namespace を利用したテスト用ノード
の生成・集中制御とOpenFlow スイッチを応用したテスト用ノード配置について
の実証実験をおこなった。本プロジェクトではそこで実証した技術を応用して、
より実用的なテストユースケース(テストシナリオ)の実現をおこなう。

 \section{基本的なアイディア}
 \label{sec:basic-tester-idea}

  % このプロジェクトでは、
  % 「ネットワークテストシステム」としてどういったシステムを作ろうとしたのか?
  % NetTester の基本的なアイディアというか、
  % そもそものパッチパネルベースにテストをやるっていう話

  % https://drive.google.com/file/d/0B2eRR_JxYJA5TmhaeWItNF93Um8/view
  % にある「もうちょっと一般化」くらいの粒度でいれてもいいかもしれない。

\ref{sec:discuss-network-test}節でネットワークテスト自動化のために必要な
機能要素について解説した。それをもとに、ネットワーク「テスタ」に求められ
る機能要求について解説する。要求については \lopjtech も参照のこと。

ネットワークのテスト自動化では、従来手作業でおこなっていたのと同等の操作
を、ソフトウェアにより自動的かつプログラマブルに実現したい。そのために、
テスト対象ネットワークの物理トポロジを、テストシナリオに応じて動的に再構
成したり、テスト用のノードを動的に接続したりする
(\figref{fig:basic-idea})。そこで、様々なノード間をつなぎ合わせる機能を
準備する(\tabref{tab:test-functions} No.3,4)。

% patch model の基本的な概念図をいれる
% net-tester readme にある最初の図くらいのやつでよい。
\begin{figure}[h]
 \centering
 \includegraphics[scale=0.5]{img/basic-idea.png}
 \caption{テスターの基本アイディア}
 \label{fig:basic-idea}
\end{figure}

\lopj では、OpenFlowスイッチを利用して物理パッチパネル相当のシステムを実
現した(\figref{fig:poc-l1patchpj}, \tabref{tab:test-functions})。また、
シンプルなテストユースケース(L3/物理・論理構成パターンを網羅したフルメッ
シュping)でテスト自動化の有効性を確認した。

\begin{figure}[h]
 \centering \includegraphics[scale=0.5]{img/poc-l1patchpj.png}
 \caption{\lopj PoCで実装・実証した機能要素} \label{fig:poc-l1patchpj}
\end{figure}


   % 「テスタ」に求められることは何か?
   % "patch panel" model – NetTester
   % \url{https://3.basecamp.com/3088280/buckets/867009/documents/208275139}
   % いるか??

 本プロジェクトは、\lopj の結果をもとに、NetTester~\cite{nettester} とい
 うテストツールを開発した。NetTester については
 \ref{chap:nettester-design}章・\ref{chap:nettester-usage}章で解説する。
 また、NetTesterをつかったネットワークテストのユースケース実証については
 \ref{chap:poc-target-design}章・\ref{chap:poc-scenario-dev}章で解説する。


%%% Local Variables:
%%% mode: yatex
%%% TeX-master: "main.tex"
%%% End: