1.はじめに
元々別記事の一部だったのですが、少し長くなってしまったのでまとめました。
実際に私が検証環境を構築した事例につきましては、以下の元記事にまとめてありますのでご参照ください。
新米エンジニアがクラウド(AWS)上での検証環境構築に挑戦してみた
インフラ屋さんの業務の中で、アプライアンス(製品)の機能検証は欠かすことのできないフェーズだと思います。
- アプライアンスの実際の挙動を確認したい
- この設計でちゃんと動くのか試したい
- お客さんに提案する前に使い心地を試してみたい
といった場面では、規模の大小はどうあれまず間違いなく機能検証を実施しますよね。
ですが実機でこの機能検証を行うためには、色々と面倒な準備が必要です。
ざっと思いついたものだけでも、以下のようなものがありました。
他にもあるよ！って方はご指摘ください。
2.実機で検証をするためには...
2.1.検証スペースの確保
何はともあれ、まずは検証を行うための場所を確保する必要がありますね。
マシンルームや検証ルームを探し、机(必要ならラックなど)を予約する必要がありますが、いつも空いてるとは限りません。
もし全て埋まっていたら(まあさすがになかなか無いとは思いますが)、空くまで待ちです。
2.2.対象のアプライアンス本体の準備
検証するんですから当たり前ですね。これが無ければ始まりません。
しかし、例えばファイアウォールのような一般的(?)な機器ならまだいいですが、今回の私のように少しマイナーな機器を検証しようと思うと、持っている人を社内で探したり、業者に発注して取り寄せたり、レンタルしたりする必要が出てきます。
時間も手間もコストもかかります。
2.3.検証に使用するその他機器(PC/サーバー、ネットワーク機器など)の準備
さすがにアプライアンス単体で検証を行うことは少ないのではないでしょうか。
他にもハブやスイッチなど、色々と機材の準備をする必要があるケースがほとんどだと思います。
ここでも検証用機材を確保する必要が出てきますし、もし無かったらまた色々と手間がかかります。
また、ご自身で色々な機材を所持、管理しているならともかく、不特定多数の社員で共有している検証機などではそれがきちんと動くという保証もありませんし、バージョンが何世代も前だったりすることもあるでしょう。
PINGで疎通確認を行うためだけに複数のPCをわざわざ準備するのもナンセンスです。
2.4.機能検証
ようやく本番です。
環境を整え、検証環境を設計して、設計通りに機器を組み上げたら、いよいよ待望の機能検証に入れます。
思い返してみればただアプライアンスを試してみたいだけなのですが、ここに辿り着くまででも既に結構なリソースを消費してしまっています。
ですが、このように苦労して環境を整えてもまだ終わりではありません。
2.5.時間・空間の制約
当然ですが、基本的に検証はこれらの機材を設置した検証ルームでやることになりますよね。
もし急な会議やら出張やら何やらで遠出してしまったら、その間検証はストップです。
準備した検証環境だって無制限にいつまでも使えるわけではありませんし、時間を無駄にするのは避けたいですね。
もしかしたら会社によっては、せっかく家で仕事が出来る環境なのに検証のためだけにわざわざ出勤している、なんて方もいるかもしれません。
もちろんリモート接続して遠隔で検証できるようにする猛者もいらっしゃるとは思いますが、その設定をするのにも手間暇は確実にかかります。
2.6.検証が終わった後の片づけ
「そんなことまで面倒くさがるなんて」と怒られるかもしれませんが（笑）
しかし、一通り検証が終わった後に山と積まれた機器を片付けなければいけないのは、地味に嫌ではないでしょうか。少なくとも私は好きではありません。
ここにかかる手間と時間も無駄と言えば無駄ですよね。
3.クラウドで検証環境を構築するメリット
では、クラウドで検証環境を構築するとこれらの問題がどう解決されるかを見ていきます。
3.1.検証スペースの確保
当然不要です。
3.2.対象のアプライアンス本体の準備
後述する制約はありますが、基本的にGUI上で簡単に準備できます。
インスタンスを作るだけなので、数分で完了します。
3.3.検証に使用するその他機器(PC/サーバー、ネットワーク機器など)の準備
これも同様に簡単に準備できますし、もちろん壊れてて使えないなんてことはありません（笑）
3.4.機能検証
検証そのものについても大分やりやすくなるはずです。
コンソールケーブルをカチカチ抜き差しする必要もありませんし、よくある物理層での問題(ケーブル抜けてる・壊れてるなど)が発生してしまうこともありません。
ブラウザでタブを増やすだけで各アプライアンスのGUI画面を立ち上げ、簡単に管理できます。
ただし、検証環境の設計には多少クラウドならではのノウハウが必要になります。
これについては私が実際に検証環境を構築した別記事でまとめていますのでそちらをご参照ください。
クラウド(AWS)上でバーチャルアプライアンスの機能検証を行ってみた
3.5.時間・空間の制約
クラウドの良いところですね。
もちろんいつでも・どこでも(ネット環境さえあれば)検証を行うことができます。
個人的にはこれが一番のメリットじゃないかなと思ってます。
3.6.検証が終わった後の片づけ
ワンクリックで終了です。
重たい機材を抱えてうろうろする必要はありません。
4.クラウドで検証環境を構築するデメリット
いかがでしょうか。
実機で検証を行うのに比べると、大分楽だと思いませんか？
ですがもちろん良いことばかりでもありません。
クラウドならではの注意点もありますので、ご紹介します。
4.1.金銭的コスト
クラウドなので、当然お金がかかります。
基本的に従量課金ですので、きちんとインスタンスの管理をしないと大変なことになってしまう可能性もゼロではありません。
私は怖がりなので、全てのインスタンスが定時で全てシャットダウンされるようにしていますが、それでもNATゲートウェイで一度失敗しました。
ですがAWSでは初回登録から一年間の間は無料枠がありますので、それを有効に活用すれば経済的に済ませることは十分可能かと思いますし、検証機をわざわざ購入したりレンタルするよりはずっと安上がりになるかと思います。
またアプライアンスによっては、
- ソフトウェア料金が込み
- BYOL(Bring Your Own Lisence)
の2種類が存在します。
前者は通常のEC2の使用料金にソフトウェアの使用料が上乗せされているもので、従量課金で使えます。やはり少々値段は高くなってしまいますね。
それに対し、後者はソフトウェアのライセンスを自前で用意しておけば、後はEC2の使用料のみで使うことができるというものです。
別ルートでライセンスを用意することができるなら当然後者のほうが安くなりますので、検討の価値はあると思います。
ちなみに私は後者の方法をとっています。
4.2.アプライアンスの制約
検証したいアプライアンスがバーチャルアプライアンスとしてクラウド上に存在しなければ、当然検証なんて不可能です。
AWSでは、AWSMarketPlaceというオンラインストアで様々なベンダーのバーチャルアプライアンスが展開されています。
ここにまだ追加されていないアプライアンスであれば、残念ながら使うことは出来ません。
日々新しいアプライアンスはどんどん追加されていますので、それを待つしかないですね。
4.3.ミスった時の復旧
実機であれば何かミスってアクセスできなくなってしまってもコンソールから復旧できますが、クラウドではどうしようもなくなってしまいます。
私もインスタンス内部でOSのファイアーウォールの設定をミスったりルーティングテーブルの設定をミスったりして、永遠にアクセスできないサーバーをいくつか作ってしまいました。
そういう時はスパッと諦めて新しいインスタンスを作りましょう。
簡単に作って簡単に潰せるのがクラウドの良いところでもあります。
4.4.設計のノウハウ
何度か触れていますが、クラウド内部で検証環境を構築するにはいくつかコツがあります。
それに関しては別記事に詳しくまとめてありますのでそちらをご参照ください。
クラウド(AWS)上でバーチャルアプライアンスの機能検証を行ってみた
4.5.学習コスト
まあこれも考え方によってはデメリットと言えなくもないかと思うので一応入れておきますが、個人的にはクラウドに関する技術を学んで損をすることはないと思います。
インフラエンジニアの方ならなおさらです。
おわりに
ここではクラウド上に検証環境を構築するメリット・デメリットをざっくりと紹介させていただきました。
実は私はこの検証環境構築を行うまでAWSのことは何一つ知らなかったのですが、実際に手を動かして検証環境を作っていくうちに色々と詳しくなったように思います。
もし今まで一度もクラウドに触れたことがない、という方がいらっしゃいましたら、ここからスタートするのもありなのではないでしょうか。
勉強になりますよ。
もしこの記事を読んで少しでも興味をお持ちになられたなら、是非ご自身でも試してみてほしいと思います。
それでは、また。