構築とテストについて知ろう

連載 [第7回] :

2017年6月23日(金)

はじめに

みなさん、こんにちは。本連載では、これまでインフラエンジニアが扱う技術を一通り解説してきましたが、「実際に現場でどのようにシステムを作っているのか」をイメージするのは難しいかと思います。そこで今回はシステムを作る技術にスポットを当て、「構築とテスト」について解説していきます。最近話題になってきている構築やテストの自動化についても触れたいと思います。

また、構築とテストは新米インフラエンジニアが最初に関わることの多い業務です。今回の解説を通じて、構築とテストを行う上での全体的な知識を身に付けておきましょう。

構築とは?

構築とは、前段フェーズの「設計」を通して作成される設計書やパラメータシートに従ってハードウェアとソフトウェア（OS、ミドルウェア）の設定を行い、システムを実際に組み上げる作業です（図1）。

図1：パラメータシートの例

例えば、サーバの構築ではハードウェア設定から始まり、OSのインストール・設定、さらにミドルウェアのインストール・設定などを行いますが、誤解を恐れずに言うと「アプリケーション開発以外の全ての領域を担当する」ことになります（図2）。

図2：構築において実施する内容の例

なお、プロジェクトの規模が大きくなると構築に関わる仕事量も多くなるため、技術領域を分けて対応することもあります（図3）。

図3：インフラ構築における体制の例

構築の現場

1. 構築準備

前項で「設計書に従ってシステムを構築していく」と書きましたが、おもむろに始めるわけではありません。まずは類似の環境を用意して構築の検証や手順確認を行っていきますが、実際に確認してみると、設計ミスやソフトウェアのバグ等で上手くいかないこともよくあります。最近では類似の環境に仮想サーバやクラウド上のサーバを使用することが多くなりました。さらにメーカの検証センタ（検証用にサーバやストレージが設置されている場所）を利用する場合もあります。日常の喧騒から離れて静かな部屋で検証するのは楽しい時間です。

検証や手順確認が完了したら、「構築手順書」を作成していきます。プロジェクトによって粒度はさまざまですが、手順書通りに作業を行えば新人エンジニアでもシステムを作り上げることができます。また、構築に必要な資材（メディアやライセンス、設定ファイル・スクリプト、作業端末）もこのタイミングで準備を進めます。

2. 構築形態

ミドルウェアの構築では、インストールや設定する際に関連するサーバが必要な場合があり、構築の前後関係やスケジュールに注意が必要です。そもそも、ミドルウェアの動作形態には「サーバ単体で動くもの」と「Manager-Agent構成のもの」と2つあります。単体で動くものは対象サーバの設定ファイルで設定しますが、Manager-Agent構成のミドルウェアではそうはいきません。

例えば、監視用のミドルウェアでは監視対象のサーバにAgent、監視状況を管理するサーバにManagerをインストールします。Agentが監視データを収集してManagerへ送信しますが、複数台のサーバ間で通信が必要となるため、Manager/Agent固有の設定に加えてネットワーク周りの設定も行う必要があります。ポートの開放や各サーバ情報の登録、異なるネットワークに属する場合はスイッチやルータにも設定します。Agentから送られてきたデータをManager側で受信し、監視できる状態となれば構築は完了です（図4）。

図4：Manager-Agent構成

3. 構築環境（開発環境、検証環境、本番環境）

システムには実際にユーザが利用する環境（本番環境）以外にも、複数の環境が必要となります。プロジェクトにより呼び方は異なりますが、例えば下記のような環境があります。それぞれの環境を構築するのもインフラエンジニアの仕事です。

開発環境
アプリケーションエンジニアがアプリケーション開発を行う環境です。JDK（Java Development Kit）といった開発ツールやCVS（Concurrent Versions System）といったバージョン管理ツールを導入することでアプリケーション開発に必要な環境を整えます。時間やコストをかけずに構築するため、柔軟な対応が求められます。インフラの検証や手順確認を開発環境で実施することもあります。
検証環境
テスト環境とも呼ばれ、本番環境でアプリケーションを動かす前にテストや検証を行う環境です。テストもせずにいきなり本番環境ではアプリケーションを動かせないので、検証環境を用意します。多くの場合で本番環境よりコストを削った構成（CPUが半分、ネットワーク機器が冗長化されていない、CentOSの使用など）になり、各種設定を検証環境用にカスタマイズする必要があります。
本番環境
実際にユーザへサービスを提供する環境です。ネットワーク上に既存のシステムが稼働している場合もあるため、万が一問題があれば周辺のシステムに影響が出ます。想定外の事象が発生すれば作業は一時中断され、今後の対応を協議したうえで再開・延期される……という失敗が許されない環境です。監視システムが稼働している場合には、作業不備によるアラートが上がると、昼夜を問わずシステム管理者（運用担当者やユーザ企業担当者など）に連絡が入ります。作業部屋に取り付けられているパトランプが回り始め、警報が鳴り響くといった現場もありました。

通常は、開発環境→検証環境→本番環境と構築していきますが、プロジェクトによっては本番環境を構築してから検証環境を構築することもあります。本番環境は監視化におかれた部屋やデータセンタでの作業も多く、通常とは異なる心理状態での作業になるため、特に事前の準備が重要となってきます。

3. 構築Tips

インフラエンジニアは、様々なことに注意しながら構築を行っています。共通認識となっているためか、なかなか改めて教わる機会がないものも多くありますが、ここでは、事前に知っておくべきものを3つピックアップして紹介したいと思います。

作業ログの取得
“script”コマンドは作業ログを残すコマンドです。作業ログを残すことは非常に重要で、作業後にサーバの挙動がおかしくなった際に、自分の潔白を証明する材料にもなります。また、お客様によっては作業ログの提出を求めてくる場合もあります。サーバやネットワーク機器を操作する際に使用する“TeraTerm”にはscriptコマンドと同様にログを取得する機能があり、多くのプロジェクトではこちらを使用しています（図5）。

図5：作業ログの取得
構築資材の確認
構築に必要なパッケージやファイルを転送する際、転送モードを間違えたり、転送が不完全だったりするとデータが破損する場合もあります。それを確認するためのコマンドが”cksum”や”md5sum”です。コマンドの引数にファイルを指定することで、ファイル内容を元に計算された英数字が出力されます。これを転送前後で実行し、比較することでファイルの破損を確認します（図6）。

図6：構築資材の確認
設定差分の確認
“diff”コマンドは2つのファイルの内容を比較し、差分を出力します。構築中に設定ファイルを編集する場合は必ずバックアップを取得しますが、このバックアップファイルと編集後のファイルをdiffコマンドで比較し、変更箇所と変更内容が意図したものかどうかを確認します（図7）。

図7：設定差分の確認

4. 構築の自動化

ここまでは人手による構築について解説してきましたが、近年は構築をツールで自動化する手法に注目が集まっています。代表的なツールとしてChefやAnsible、Puppetといったものがあります。実際に私の現場でもAnsibleというワードがチラホラと聞こえてきています。

Ansibleでは、Playbookと呼ばれるファイルに処理内容を記述し、実行するだけで構築が完了します。Playbookを実行するだけなので人為的な作業ミスを防ぎ、手間も省けるため非常に魅力的です。さらにPlaybookは使い回しができるため、構築台数が数十台～数百台といった場合にも作業者の負担やコストを抑えられるといったメリットがあります（図8）。

図8：Ansibleの実行画面

こういった自動化ツールを利用するにはPythonやRubyといったスクリプト言語の基礎知識が必要となります。インフラエンジニアとしての価値を高めるためにも、OSやミドルウェアの知識だけでなく、様々なスクリプト言語も修得する必要がありそうです。

＜コラム＞プロジェクトに関わるエトセトラ：アジャイル開発とは

連載を通して、インフラエンジニアが関わる「プロジェクト」に注目し、さまざまな側面から解説していく本コラム。今回は、アジャイル型開発について解説します。

前回までは、ウォーターフォール型開発について解説してきました。ウォーターフォール型開発はフェーズ（要件定義、設計、構築、テスト）を順序立ててプロジェクトを推進する開発手法ですが、アジャイル型開発は短期間で設計、構築、テストを繰り返しながらプロジェクトを推進する手法です。小さな単位で何度も反復するため、その都度問題点を修正可能な点が大きなメリットと言えます。

しかし、何度も反復して進めることから、プロジェクト全体のスケジュールを把握し辛いというデメリットもあります。加えて、日本ではアジャイル型開発の経験者が少ないため、導入が難しいという現実もあります。

このような書き方をするとデメリットの方が際立ってしまうかもしれませんが、必ずしもウォーターフォール型開発が正解という訳ではありません。事業部門主導のシステム開発も目立ってきた昨今、プロジェクトに適した開発手法を採用していく必要があります。

（第8回へ続く）

テストとは？

テストとは、構築したシステムが設計書通りに作られているかを確認する作業です。人間が構築したものなので、設定内容が間違っている、思い込みにより設計外の設定がされているといったことも発生します。また、ソフトウェア（OS、ミドルウェア）のバグにより、想定通りの動きにならないこともよくある話です。

後述しますが、一般的にテストでは確認観点ごとに段階を分けて実施していきます。例えばサーバのテストでは、サーバ単体の設定・動作確認を実施した後にサーバ間・他システムとの動作確認、アプリケーションを実装した動作確認といった流れで品質を確保していきます。しかし、実際のプロジェクトでは同時並行で様々なテストが実施されているため、テスト環境を奪い合うといった場面も発生します。

テストの現場

1. テスト準備

テストにあたり、まずテスト計画書を準備します。テストの目的をはじめ、体制やスケジュール、観点、合格基準などを記載していきます。例えば、仮想化環境で仮想サーバを使用してサーバを構築する場合、設定値も複製されるため2台目、3台目以降の仮想サーバはテストを省略（IPアドレスなどの設定差分や動作確認は実施）することが一般的ですが、そのようなことも計画書で決めておかないと後々トラブルの元になります。

テスト計画書が準備できたら、次は実際のテスト内容を記載したテスト仕様書を作成していきます（図9）。テスト内容と手順、期待する結果、対象などが記述してあり、テストを実施する人はこの内容に従って作業を実施していくことになります。

図9：テスト仕様書の例

また、併せてテストの実施に必要な環境（通信先サーバや負荷端末など）やデータ（テスト表示用のHTML画面やDB接続を行う簡単なアプリケーションなど）も準備します。ウィルス対策製品をテストするためにテストウィルスを準備したら、自分の端末のウィルス対策製品で検知されてしまった、といった話はインフラエンジニアあるあるかもしれません。

2. テストフェーズ

さて、先に「段階を分けて実施していく」と書きましたが、具体的には”単体テスト””結合テスト””総合テスト”といった流れで実施していくのが一般的です。

単体テスト
OSやミドルウェアの設定、動作を単体でテストします。例えば、”スマートフォンのロック解除パスワードがxxxに設定されている””電源ボタンを押したら起動する”といった動作を評価すると言えばイメージしやすいかもしれません。
結合テスト
複数の機能を組み合わせた連携が可能かをテストします。再度スマートフォンの例で言うと“パソコンに入っている音楽アプリからスマートフォンへ楽曲を転送し、スマートフォンの音楽アプリでその楽曲が再生できるか”という一連の流れを評価します。実際のインフラの結合試験はプロジェクトによって内容が大きく異なりますが、非機能要件に従って設計された基本設計内容を確認するのが大きな目的です。
総合テスト
別名システムテストとも呼ばれ、本番環境で正常に動作するかを確認します。インフラエンジニアが関連する試験項目としてはシステムの性能を計る性能試験、実運用時に想定される負荷に耐えられるか検証する負荷試験などが挙げられます。

なお、ここで紹介したものはあくまでも大きな枠組みで、現場のルールやプロジェクトによって呼び方や実施内容は変わってきます。一概に「○○試験は○○をするのだ！」とは言い切れないので注意してください。

３. テストの自動化

テストにも自動化ツールが存在します。代表的なものとして”Infrataster”や”Serverspec”などが挙げられます。

Infratasterは外部からクライアントを模した動作を行い、サーバの状態を確認します。例えばクライアントから対象のサーバへHTTPリクエストを投げ、そのレスポンスからサーバの状態を確認するといったものです。

Serverspecは設定の確認に用いられることが多く、スクリプトで指定した設定ファイルや設定状態を確認し、設定が想定通りかを確認します。AnsibeでServerspecと同様のテストを行える専用ツール”AnsibleSpec”も存在します。

このようにツールによって使用場面は異なりますが、テストケースをスクリプト言語で記述してテストを行うという部分は変わりません。テストの自動化ツールには向き、不向きがあるので、テストケースに合わせて使い分ける必要があります。

構築とテスト

ここでは、私がまだ新米インフラエンジニアだった時に体験した「検証環境におけるサーバ構築の話」を紹介したいと思います。導入するサーバやOSについては個々に導入実績があったものの、ネットワーク機器との接続に実績がなかったため、問題なく接続できるかを確認する必要がありました。

まずはOSをインストールしましたが、ここでいきなりコケました。結論から言うとブートデバイスの選択を誤り、インストール後にディスプレイが真っ赤になってしまったのです。そのため時間がかかるインストール作業をもう一度行うハメになり、手順をしっかり理解していなかったことを反省しました。導入したOSはSolarisで、SVM（Solaris Volume Manager）というソフトウェアRAIDを構成し、ミドルウェアは対象外のため構築せず、ネットワーク設定を変更して構築を完了しました。

続いて検証作業です。内容はLAN結線前後のインターフェイスの状態確認、機器のLEDランプの確認、ログ出力結果の確認です。作業は粛々と進みましたが、1度だけミスをしてしまいました。インターフェイスを手動でupにする設定を忘れ、疎通が取れないという非常に単純なミスです。意外とこのような細かい作業は忘れてしまうものです。インターフェイスをupに切り替え、無事に疎通が取れたことを確認して検証作業を完了しました。

OSにもミドルウェアにも言えることですが、設定を行った人間は「正しく設定したつもり」になりがちです。この経験は「第三者によるチェックが不可欠」という教訓になりました。もちろん本番環境では再鑑者立ち合いの元での作業が大前提です。